[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