Re: A long HBH Options question

["C. M. Heard" <[e-mail]>]

On Tue, 21 Aug 2018 19:16:55 +0000, Ron Bonica wrote:
> [ … ] let's assume that:
>
> - A packet contains an HBH option and the high-order bits of the HBH
>   Option type are "10" [could also be "01" or "11']
>
> - 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?

Yes.

> If so, does this behavior cause cognitive dissonance for anybody else?

It sure does.

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

The "act" bits are not exactly meaningless, but only the encoding "00"
will elicit consistent behavior from nodes that  comply with RFC 8200
and don't recognize the option. To me, it would seem quite odd if the
designer of any new HbH option were to choose an encoding with
"act" bits other than "00". For already allocated options, any encoding
other than "00" will not have the results expected by those who
designed the options assuming that the rules in RFC 2460 would be
followed. Thus, that the maintainers of existing HbH options with the
"act" bits other than "00" should probably re-examine the option
encoding in light of the change wrought by RFC 8200. Here is the list:

0x63  RPL (RFC 6553, PS)
0x6D  MPL (RFC 7731, PS)
0xC2  Jumbo Payload (RFC 2675, PS)
0xEE  IP_DFF (RFC 6971, Experimental)

The ROLL WG has in fact taken this step with the RPL option, though for
reasons independent of the change made in RFC 8200. The thinking
behind the original design in RFC 6553 was that it was undesirable for
the RPL option to escape from the RPL domain in which it was originated,
so "act" was set to "01" to force nodes external to the domain to
silently discard escaped packets. That thinking has been revised, and
there is a document in last call that will deprecate the existing
code point and get a new one (probably 0x23) with "act" set to "00".

A re-examination of already allocated destination options would be
called for if the change proposed in draft-herbert-ipv6-update-dest-ops
were to be implemented. Here is that list:

0xC9  Home Address (RFC 6275, PS)
0x8A  Endpoint Identification (DEPRECATED)
0x8B  ILNP Nonce (RFC 6744, Experimental)
0x8C  Line-Identification (RFC 6788, PS)

The Home Address option would actually not be affected by the
proposed change in draft-herbert-ipv6-update-dest-ops since it
isn't allowed to appear appear before a Routing Header. I have
not examined the others, however.

Mike Heard