> Every extension header has a Next Header field somewhere, and that
> field has some offset from the start of the packet, so what's the
> problem?
I think the stated problem is that extension headers past an ESP header
it offset might not be well defined. For instance, ESP + destination options
where the dstops header has an unknown next header field.
Imagine an ESP algorithm that does compression (and encryption).
Is the implementation supposed to determine at what offset
the offending next header value "lived" in the packet that was received
(i.e. in the encrypted and compressed packet).
Or is the implementation supposed to derive some pseudo offset from
the begining of the decrypted packet?
Similar things might appear (but less severe) when there is a fragment header
before the header which has an unknown next header field.
I suspect many implementations remove the fragment header when the reassembly
is done, which means that the next header offset the implementations
return in ICMP errors would be off by the size of the fragmentation header.
However, if the offending next header field doesn't fit in the first fragment
then what should the correct offset be in an ICMP payoad type unknown?
My assumption is that the offset is undefined both past ESP headers and
when it doesn't fit in the first fragment.
Erik
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
