> Just as you said, I don't think it is meaningful to consider how an
> icmp6 error packet against an encrypted packet should be. Is this
> really your practical concern, or do you have another example of this
> kind of problem?
Not really.
ESP is just an example, that there are headers where an offset to the
erroroneus value makes no sense. When such "problems" are uncovered, I
just ask myself: is the specification truly clean?
I just have architecture where extension headers can be defined and
implemented in loadable handlers, ESP being one of them, means that
the next header field must be returned by the handler in some way,
because it does not occur in packet (after ESP). Thus the API of such
handlers now has to be changed to return the offset for the ICMP in
addition to actual next header value, for the case where the next
header is unknown. (Or have some flag to tell that no offset is
available, and assume all other headers follow the default IPv6 ext
header layout...)
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
