Re: A long HBH Options question

[Bob Hinden <[e-mail]>]

Ron,

> On Aug 21, 2018, at 12:16 PM, Ron Bonica <[e-mail]> wrote:
> 
> Folks,
> 
> 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?
> 
> 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.

If a router isn’t looking at HBH headers, they are indeed meaningless as is the HBH header itself.  If the router is processing HBH headers, then they have the defined meaning.

Not sure I understand what you are asking.

Bob