[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Design decisions made at the interim SHIM6 WG meeting



Hi Pekka,

El 28/10/2005, a las 11:52, Pekka Savola escribió:

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.


ok, let's first be very concise of what is being considered here:
- in general data packets won't carry any shim extension header, because in general, they will use the ulids as locators, so no need to demux. - the case where they carry the extension header if after an outage when the locators carried differ from the ulids used in this shim context

so there is not that all data packets of shim enabled communications will carry the extension header, but only those communications that have suffered and outage.

Putting that as an experimental feature,

the porposal is not to put is as an experimental feature, like an exprimental track spec, but as an extension to the basic spec, i.e. not to included in the base spec

to be defined later etc. is not acceptable IMHO. This needs to be used and supported from day one.


the problem here is that the actual solution does looks somehow complex and hacky at this point in time, and in order to understand how complex and hacky it would be we rather see it fleshed out in a draft

In particular, it seems to require overloading both the flow label and the next header fields to carry other information that they were designed to.

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.

but remember that the extension header included in data packets that need it, it is the same used for shim control signaling, in particular, for establishing the shim context. 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?

regards, marcelo


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