On Thu, 27 Oct 2005, Iljitsch van Beijnum wrote:
2. Use an 8 byte IP SHIM6 header in the base protocol specification for packets that require specific SHIM6 processing by the receiver, and allow optimizations on this, including that of a zero-length header, to be an experimental protocol extension.I have no problem with a shim header for demultiplexing in cases where demultiplexing would otherwise be very hard or impossible. For instance, in the case of several extension headers, an explicit shim header makes it possible to indicate which headers see modified addresses and which headers see unmodified addresses unambiguously.However, I think it's a very bad idea to have a shim header in EVERY packet with rewritten addresses, because there are cases where the shim context can be determined from information that's already in the packet unambiguously so an extra header is unnecessary.Mandating a shim header first and then optionally allow it to be suppressed is useless in practice: we need have the capability to have the shim header suppressed as a mandatory part of the inital base spec.
I have to echo Iljitsch here. The possibility to do away with an extension header in the data packets (I don't care what the shim signalling looks like if it isn't piggybacked in the data packets) is one of the most important features of shim6 in my opinion.
Putting that as an experimental feature, to be defined later etc. is not acceptable IMHO. This needs to be used and supported from day one.
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. If we need to define it separately, I'd suggest we publish the whole shim6 spec as experimental first.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings