Re: A long HBH Options question

[Ole Troan <[e-mail]>]

Ron,

> According to RFC 8200:
> 
>  "The Option Type identifiers are internally encoded such that their
>   highest-order 2 bits specify the action that must be taken if the
>   processing IPv6 node does not recognize the Option Type:
> 
>      00 - skip over this option and continue processing the header.
> 
>      01 - discard the packet.
> 
>      10 - discard the packet and, regardless of whether or not the
>           packet's Destination Address was a multicast address, send an
>           ICMP Parameter Problem, Code 2, message to the packet's
>           Source Address, pointing to the unrecognized Option Type.
> 
>      11 - discard the packet and, only if the packet's Destination
>           Address was not a multicast address, send an ICMP Parameter
>           Problem, Code 2, message to the packet's Source Address,
>           pointing to the unrecognized Option Type."
> 
> Also according to RFC 8200:
> 
> "While [RFC2460] required that all nodes must examine and
>   process the Hop-by-Hop Options header, it is now expected that nodes
>   along a packet's delivery path only examine and process the
>   Hop-by-Hop Options header if explicitly configured to do so."
> 
> So, let's assume that:
> 
> - A packet contains an HBH option and the high-order bits of the HBH Option type are "10".
> - The packet traverses Router A and Router B on route to its destination
> - Router A is not configured to process HBH options
> - Router B is configured to process HBH options
> - Neither Router A nor Router B recognize the HBH option contained by the above-mentioned packet.
> 
> I think that RFC 8200 requires the following behavior:
> 
> - Router A forwards the packet to Router B, without examining the HBH Options header
> - Router B discards the packet, because it doesn't recognize the option.
> 
> Is this the required behavior? If so, does this behavior cause cognitive dissonance for anybody else?

Expected behaviour.
You might recall we had this exact discussion a few years ago.
A consequence of relaxing the HBH processing rules is that mandatory options no longer has the “safety catch”, and that not configuring every router on the path to process it, would be a configuration error.
E.g. take the jumbo HBH option. It’s pretty obvious that it’s a configuration error, and router A wouldn’t be able to forward those packets anyway.

> I am thinking that the "act" bits are meaningless in the HBH extension header. This discussion may also be applicable to draft-herbert-ipv6-update-dest-ops.

I hope not, but feel free to bring enlightenment.

Cheers,
Ole