On 28-okt-2005, at 12:42, Pekka Savola wrote:
Otherwise the firewalls, packet filters etc. will just discard all of these packets with the extension header because they don't have the logic to skip over them or parse them.
Well obviously we expect the makers of these products to update their stuff.
In the mean time, our main concern here should be that the presence of any type of filtering leads to consistent results. If all shim packets are filtered that isn't so bad, because it then just seems that the correspondent doesn't support the shim so the session remains in backward compatible mode. The situation where the shim seems to be working but doesn't is much more destructive.
So if firewalls were to discard data packets carrying the shim ext header, they would have discarded the shim context establishment packets, so no shim context at all, so those data packets with the shim ext header will never be generated anyway, right?
I assume that the method of establishing the shim context is still open:
- if it's done by adding an extension header to data packets, or
- if it would be done by sending separate "shim control packets" (e.g., with TCP, UDP, or whatever, or even plain extension headers without any data), then my concern still applies.
No, I think we pretty much agree that the shim signalling would have to happen in separate packets. Unless I misremember we didn't even discuss this issue in the interim meeting.
The part that we're not completely agreeing on is whether all rewritten packets should have a shim header for demultiplexing. (This shim header would have the same protocol number as the shim signalling packets but otherwise be formatted completely differently.)
Erik has proposed a mechanism to allow demultiplexing based on the protocol and flow label fields. However, in the meeting it was proposed to simply use an explicit header instead. I think that makes lots of sense in the cases where demultiplexing would otherwise be impossible or difficult, but the discussion that I started was about having this header when demultiplexing without the header is NOT problematic.
I do NOT want that shim6 would require piggybacking on data packets either to establish the context or rehome.
I don't think in the case of data packets with rewritten addresses that are otherwise indistinguishable from data packets with the original addresses (i.e., when there is a session between A1 and B1 and a session between A2 and B2 and then a failure between A1 and B1 packets between A2 and B2 may either be the first session with rewritten addresses or the second with the original addresses) and/or when there are additional intermediate headers so it's not obvious which onces come "before" the shim and which ones come "after" it should be considered "piggybacking". In IPv6 a protocol chain is part of the base mechanism so there is no reason not to use extra headers when they are appropriate. (Obviously things would have been much better if there had been a standard header format so implementations would be able to skip unknown headers, but I guess we'll have to fix that in IPv7.) Since the fact that the shim signalling worked indicates that the shim header isn't filtered this should work without trouble.