On Fri, 28 Oct 2005, Iljitsch van Beijnum wrote:
On 28-okt-2005, at 13:58, Pekka Savola wrote:[...] Since the fact that the shim signalling worked indicates that the shim header isn't filtered this should work without trouble.The last sentence does not follow. Firewalls may accept just fine packets with a shim6 extension header but no data, but could (and I'd expect many WOULD) drop packets with shim6 ext header WITH data.Why??
A site administrator may be able to specify in the firewall rules that a particular next-header type should be accepted.
1) Specifying such a rule is safe if it's known that the firewall would only accept packets with a particular header type if there is no proceeding header.
2) Specifying such a rule would result in completely open firewall policy if the firewall cannot parse the next headers but would accept packets if there was one.
I don't think there are many acl implementations which are smart enough to parse TCP/UDP ports, etc. after the extension headers.
But if that's true: all the more reason to support suppressing the shim header for rewritten packets. :-)
Exactly.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings