At 9:45 AM -0700 6/15/00, Erik Nordmark wrote:
> > 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.
At the point in time at which one looks at a Next Header field and
determines that its value is unknown, that field is at some known offset
from the packet start (known to the node doing the inspection, that is).
The packet (or as much of it as will fit) will be sent back to the source
in the ICMP error message, and the offset will point to the troublesome
Next Header field in that returned packet.
>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).
The receiver would have decrypted and decompressed the packet in order to
examine the Next Header field. At that point, the location of the Next
Header field is known. The location of the Next Header field *has* to be
known in order to determine that it contains an unknown/unsupported value,
doesn't it?
>My assumption is that the offset is undefined both past ESP headers and
>when it doesn't fit in the first fragment.
The offset is always defined in the context of the packet (or partial
packet) returned in the ICMP error message.
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
