Hi, Fred,
On 7/2/2013 8:06 AM, Templin, Fred L wrote:
Hi Joe,
It occurred to me that the SEAL header has an available byte
that could be used as an offset to branch to the end of the
extension header chain without having to parse all other
extension headers in between. If that's not good enough
then I don't know what else to say, because we have already
established that some form of fragmentation is necessary.
Please don't answer if it is uncomfortable to do so, Joe,
but are you against seeing IPv6 move forward?
I'm not, but this won't help.
I had thought about this as a possibility for a new IP option, i.e., one
that jumps to the end of the options. However, that option would need to
be updated by any code that added an intermediate header, and I'm not
sure how that would work.
IP already puts all the options that a router should be looking at in
one place - by design. The problem here is that routers want to look
further. In IPv4, there's a notion of the base header, option headers,
and a payload. In the 'old days', the payload was the transport header,
so it was easy to know where to look to find port numbers.
Those days have changed. There are many protocols that add 'shim' layers
between IP and transport, or other places in the conventional stack.
That's part of why IPv6 designed its headers as chained - to make it
easier to support shim layers without redesigning IP and without
limiting the space available for such layers.
So we have a tension between the many folks who want to insert these
shims and DPI devices. The DPI devices want to do less work than an
endpoint to find the transport information, but that may or may not be
feasible using the current IPv6 structure.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
