Re: A long HBH Options question

[Jen Linkova <[e-mail]>]

On Wed, Aug 22, 2018 at 5:16 AM, Ron Bonica <[e-mail]> wrote:
> 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 see what you mean ;) But IMHO this is intended behavior.
Let me give you an example:
- let's  say I run a network and going to use some HBH option. That
option must be understood by the router (so it can not skip it).
My plan is to use it within my administrative  domain where I make
sure that *all* routers are configured to process HBH.
If I have routers configured otherwise, it's a configuration error on my side.
So I do not care that some routers in Internet might ignore the
instructions from the highest two bits (most likely I have a filter at
the edge blocking HBH).

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

Well, they used to be (when HBH was expected to be processed by all
router) quite meaningful instructions. Now the scope of the
instructions is limited to routers you configure, not to the whole
Internet.

-- 
SY, Jen Linkova aka Furry