In your previous mail you wrote:
it seems to me that there is at least one situation in which ipv6
extension headers should be skipped - before a packet is sent back
within an icpmv6 error message, the kernel must be sure that it is not
an icmp error message.
=> this was already discussed. The general idea was/is it doesn't matter
because it is expensive and in some cases impossible to verify the
offending packet is an icmp error message then if the trivial check
for an ICMP error fails then you may return an ICMPv6 error.
Just don't forget to apply the ICMPv6 rate limit on it...
i think there are many other situations in which low-level network programs
need to access payload data without processing extension headers.
=> I don't understand how you may both access payload data and
no process extension headers because it is the processing of extension
headers which gives the position (and the kind) of payload data.
Would you like to parse incomming packets twice, the first time in order
to find extension headers, the second time in order to process them?
An implementation may do this but this is not required... and this
couldn't work easily with ESP header.
2) provide a standard macro that returns protocol id of the upper
layer protocol and the offset of the payload from the beginning of
the packet, to be included in the next version of
draft-ietf-ipngwg-rfc2292bis.
=> I disagree. What you want seems to be a wildcard raw socket and
this is not a standard feature for many good reasons. If you need
to look at inside incoming packets before their processing then
something like BPF is a better solution.
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
