Subject: A long HBH Options question

From: Ron Bonica <[email-masked]>
Date: Tue, 21 Aug 2018 19:16:55 +0000

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.

                                                                   Ron

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Aug 2018 22:08:32 +0200

Ron,

> 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

---

From: Bob Hinden <[email-masked]>
Date: Tue, 21 Aug 2018 13:34:22 -0700

Ron,

> On Aug 21, 2018, at 12:16 PM, Ron Bonica <[email-masked]> wrote:
> 
> Folks,
> 
> According to RFC 8200:
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Aug 2018 11:24:32 +1200

Hi Ron,
On 2018-08-22 07:16, Ron Bonica wrote:
...
> Is this the required behavior? 

Definitely. A is configured to ignore HBH. B is configured to examine HBH
and therefore applies the discard rule.

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

Not in the least.

> I am thinking that the "act" bits are meaningless in the HBH extension header.

Why? They will apply if and only if the forwarding node is configured
to process HBH.

Think about the limited domains model. If the HBH header in question is
used in the source domain, all the routers in that domain will be configured
to support HBH *and* will recognise the header. But if the packet leaves
the domain, let's assume that all the transit routers it encounters
are configured to ignore HBH (for speed), so the packet will be delivered
to a destination site. Assume that this destination site supports HBH
but not the header in question. Then the discard rule will apply.

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Tue, 21 Aug 2018 16:45:03 -0700

On Tue, Aug 21, 2018 at 4:24 PM, Brian E Carpenter
<[email-masked]> wrote:
> ....

Brian,

I agree with your example, however I don't see that limited domains
are relevant here. Intermediate nodes may or may not support HBH;
that's a protocol requirement that is independent of the environment
that the protocol runs in. For instance, a site may very well have
devices from different vendors that vary in support of HBH. The only
case that I can think of where a limited domain might be relevant, as
a mechanism to isolate information specific to a domain, is if someone
deploys an experimental or proprietary option that they don't want
leaked to the outside world.

Tom

>     Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Aug 2018 11:46:04 +1200

> leaked to the outside world.

Exactly right.

   Brian

---

From: Jen Linkova <[email-masked]>
Date: Wed, 22 Aug 2018 14:01:05 +1000

> 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

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 22 Aug 2018 15:14:22 +0100

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

This looks like a reasonable interpretation of what would happen.  It 
probably shouldn't cause too much cognitive dissonance: HBH is a 
troubled mechanism on real-life networks because of the scale 
differences between forwarding planes and management planes, so you have 
to make allowances for the occasional raised eyebrow.

> I am thinking that the "act" bits are meaningless in the HBH

yes, probably.  It would not be hard to envisage situations where a 
router would choose to discard a packet with a HBH header and not return 
an ICMP reply, even if this were requested by the option type.

Nick