Re: Conflicting requirements for sending ICMPv6 and EH scan?

[Fernando Gont <[e-mail]>]

Hello, Tom,

On 24/5/19 16:58, 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."

IN the context of your message, Linux would be okay in this respect (but
se below), since the spirit is mostly that when you process a packet,
you act on each EH in the order they were included in the packet. IN
this sense, the code you are referring to is peeking on the packet (or
simply "parsing the EH chain"), as opposed to "processing the EH chain"
(similar as what a FW would do when meaning to enforce filters on
layer-4 values).


> 
> 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."

At least theory, a node might not be able to comply with this
requirement. As noted in
https://www.ietf.org/archive/id/draft-gont-6man-rfc6564bis-01.txt , it
is not really possible to parse past unknown EHs.



> 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.

In this context, I wouldn't call this "process", but "peeking" at the
packet -- or just parsing it.

One would assume that ICMPv6 errors will never employ newly-specifed
EHs, and hence you'd be able to parse the EH chain. That's what I expect
in the real world.

Specs-wise, and strictly (theoretically) speaking, an ICMPv6 error might
use unknown EHs, and hence you might be unable to tell what's the uper
layer protocol.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492