Re: Conflicting requirements for sending ICMPv6 and EH scan?

[Mikael Abrahamsson <[e-mail]>]

On Fri, 24 May 2019, Tom Herbert wrote:

> Hello,
>
> I am updating the references in Linux stack from RFC2460 to RFC8200. I
> came across the ipv6_skip_exthdr function which contains a long, and
> somewhat apologetic, comment that this function is purposely walking
> over all the IPv6 extension headers for the purpose of locating the
> transport layer protocol and hence violates RFC2460 (RFC8200):
>
> "Therefore, extension headers must be processed strictly in the order
> they appear in the packet; a receiver must not, for example, scan
> through a packet looking for a particular kind of extension header and
> process that header prior to processing all preceding ones."
>
> The need for this function arises from the requirement of RFC4443:
>
> "(e) An ICMPv6 error message MUST NOT be originated as a result of
>       receiving the following:
>
>       (e.1) An ICMPv6 error message."
>
> So, for instance, if we are sending an ICMP error because of a problem
> with an extension header, we need to walk (process) the  other
> extension headers to determine if the transport is ICMPv6 and if it is
> then not send the error.
>
> The comment is over fourteen years old! I would like to resolve
> somehow as not being a violation of standard. Any ideas how to do
> that?

Is this ipv6_skip_exthdr only used as a sanity check when having decided 
to send an ICMP6v6 error message, or is it used in other cases as well?

-- 
Mikael Abrahamsson    email: [e-mail]