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