Re: Conflicting requirements for sending ICMPv6 and EH scan?

[Ole Troan <[e-mail]>]

Tom,

> The rfc4443 text you are quoting is from section 2.4. That deals with processing rules for ICMP messages. That is, you already know you have received an ICMP at that point. 
> 
> If you are looking at the corner case where someone sends you an ICMP message with an unparsable extension header chain, then you have to treat that as any other packet with unknown headers. 
> 
> Ole, here is an example scenario:
> 
> A host receives a packet with a destination option whose type is unrecognized by the host. The high order bits of the option type indicate that an ICMP error should be sent in response to receiving an unknown option. But, per the text quoted from RFC4443, we are not permitted to send the ICMP error if the received packet was itself an ICMP error packet. At this point, we're only processing the destination options, so we don't know yet whether or not the received packet is ICMP-- the only way to determine that is to parse the packet beyond the destination options EH to find the transport protocol.

But in the general case you cannot. And probably shouldn't either.
In this case the stack cannot know that it has received an ICMP message and the provisions in RFC4443 do not apply.

Is there any case where an ICMP error message can include extension headers before the ICMP header?

If we allow that, you could indeed imagine a (very constructed) case, where host A sends host B an unparsable header chain ICMP, and host B responds with a different unparsable header chain ICMP.

Best regards,
Ole