Subject: HBH Option Header Configuration (draft-hinden-6man-hbh-processing)

From: Bob Hinden <[email-masked]>
Date: Tue, 8 Jun 2021 13:06:31 -0700

Gorry and I are going over the comments received on draft-hinden-6man-hbh-processing-01, thanks very much for your comments, it is very helpful.  We are working on respond to them.

One issue that is common to several questions is what does configuration mean regarding HBH Option headers.    Our draft and in hindsight RFC8200 is not clear what this means.   The note in Section 4 of RFC8200:

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

This can be interpreted to mean a configuration flag allowing/disallowing processing of a HBH Option Header, or specific configuration for each HBH Option type.

draft-hinden-6man-hbh-processing-01 says:

  This document updates [RFC8200] that a
  node MUST process the first Option in the Hop-by-Hop Header in the
  Fast Path and MAY process additional Hop-by-Hop Options if configured
  to do so.

Several people asked if we are proposing to remove the ability to not process the HBH Option Header.

We have discussed this and conclude that yes, we are proposing to require all nodes to examine and process the first HBH Option in the Fast Path.   Not just drop packets with HBH Option Headers.  This change needs to be made clearer in the draft.

If it is allowed to not process any HBH Options, then we don’t see any purpose for this draft.   We do want to require that a router examine and process one HBH Option in the Fast Path.

We note that while RFC8200, and it’s predecessors, didn’t call it out specifically, if did infer that a node would have code and/or configuration for each possible HBH Option Type.   Otherwise, it wouldn’t say:

  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:

and there would be no reason for the two high order bits in the Option Type that describe the action.  The draft doesn’t change this.

We do note that per option configuration could be set to not support any options, that would be allowed, but it would require a router to follow the two high order bits in the Option type that control if the packet should be dropped or forwarded for at least the first option, and any other options that it was configured to support.

Comments?

Bob & Gorry

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 8 Jun 2021 21:18:23 +0100

Bob Hinden wrote on 08/06/2021 21:06:
> We have discussed this and conclude that yes, we are proposing to
> require all nodes to examine and process the first HBH Option in the
> Fast Path.   Not just drop packets with HBH Option Headers.  This
> change needs to be made clearer in the draft.
[...]
> Comments?

yep - it's 26 years too late to close this particular stable door.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Jun 2021 08:48:52 +1200

> yep - it's 26 years too late to close this particular stable door.

I wouldn't say it exactly like that, but I think the requirement is
totally unrealistic. To be precise:

"However, it
is to be expected that high-performance routers will either ignore it
or assign packets containing it to a slow processing path.  Designers
planning to use a hop-by-hop option need to be aware of this likely
behaviour."

[https://www.rfc-editor.org/rfc/rfc7045.html#section-2.2]

(Standards wonk comment: Since RFC8200 does not obsolete or update
RFC7045, this draft would need to formally update RFC7045 for this
reason. Which I would object to...)

Regards
   Brian

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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 8 Jun 2021 14:05:37 -0700

> totally unrealistic. To be precise:
I agree.

> planning to use a hop-by-hop option need to be aware of this likely

Yes, that is the why when sending options from a host, we'd never
assume that *all* nodes in the path are going to process any of them.
The assumption we're making is that routers in the path that need to
process the option will process them, and those that don't need to
process them will forward (in the fast path) instead of just dropping
them. For example, in FAST the hop by hop option is really directed to
the first hop router of the local network and/or the ingress router of
a remote network-- any other routers in the path don't need to process
it and can ignore it (either by skipping the option with 00 in high
order bits, or by ignoring the HBH EH altogether).

Tom

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Jun 2021 07:10:42 +0000

Agree with Brian and all;

Even more water went through the bridge since RFC 7045 and 8200 clarified that HbH can be ignored.
In my field, RFC 9008 has modified the behavior of RPL routers to allow the RPL (HbH) option to leak in the internet and changes the RPI Option Type.  
https://www.ietf.org/archive/id/draft-pthubert-detnet-ipv6-hbh-01.html encourages the use of the HbH OH for DetNet because the use of the OH is expected to be simpler with less constraints on whether the option header leaks beyond the "DetNet domain". 
All in all, the HbH OH and IPv6 as a whole have become a lot more usable because of the must -> may in section 4.3 of RFC 8200. Your draft can continue on that path in which case I'll welcome and support it. But going backwards cannot work.

Keep safe;

Pascal

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: mardi 8 juin 2021 22:49
> To: Nick Hilliard <[email-masked]>; Bob Hinden <[email-masked]>
> Cc: IPv6 List <[email-masked]>
> Subject: Re: HBH Option Header Configuration (draft-hinden-6man-hbh-
> processing)
> 
> I wouldn't say it exactly like that, but I think the requirement is totally
> unrealistic. To be precise:
> 
> "However, it
> is to be expected that high-performance routers will either ignore it or
> assign packets containing it to a slow processing path.  Designers planning
> to use a hop-by-hop option need to be aware of this likely behaviour."
> 
> (Standards wonk comment: Since RFC8200 does not obsolete or update RFC7045,
> this draft would need to formally update RFC7045 for this reason. Which I
> would object to...)
> 
> Regards
>    Brian
> 
> >
> > Nick
> >

---

From: Fernando Gont <[email-masked]>
Date: Wed, 9 Jun 2021 17:12:35 +0000

Hello, Bob,

On Tue, 2021-06-08 at 13:06 -0700, Bob Hinden wrote:
> Gorry and I are going over the comments received on draft-hinden-
> 6man-hbh-processing-01, thanks very much for your comments, it is
> very helpful.  We are working on respond to them.
> 
> One issue that is common to several questions is what does
> configuration mean regarding HBH Option headers.    Our draft and in
> hindsight RFC8200 is not clear what this means.   The note in Section
> 4 of RFC8200:
> 
> This can be interpreted to mean a configuration flag
> allowing/disallowing processing of a HBH Option Header, or specific
> configuration for each HBH Option type.

IMO, the above meanns "unless you have been explicitly configured
otherwise, feel free to skip/ignore the HbH header".

That relieves intermmediate systems from having to process HbH header,
which in some cases might be unnfeasible.

>   Fast Path and MAY process additional Hop-by-Hop Options if

IMO, it's hard to enforce that requirement -- if at all possible.

1) You're assuming there is a fast-path -- maybe there isn't such a
thing.

2) What if there are multiple HbH?

3) What about the option size? e.g., if the first option is, say 512
bytes long, maybe you just can't do that.

4) If processing other options is a MAY, is there any point in
supporting multiple options in HbH?

> change needs to be made clearer in the draft.

While other might disagree, even if the IETF were to manage to progress
this to an RFC, for the reasons specified above I really doubt this
would have any impact on real devices.

OTOH, we'd have a bunsh of things co-existing:

1) rfc2460 implementations, which aim to process all HbH
2) Deployed reality which drops HbH
3) RFC8200 implementations -- which ignore HbH unless required
4) draft-hinden-6man-hbh-processing, which would only process part of
   it.

If I had any reason for even thinking about using HbH options, the
above would certainly drive me away of that.

> We do note that per option configuration could be set to not support
> any options, that would be allowed, but it would require a router to
> follow the two high order bits in the Option type that control if the
> packet should be dropped or forwarded for at least the first option,
> and any other options that it was configured to support.

At least for infrastructure devices, that's not doable.

I find it very hard for an operator to even consider processing HbH
options (*), unless they have a very specific requirement to do so (say
RSVP).

(*) Some might extrapolate that to EHs in general :-) , but I won't get
into that. ;-)

Thanks,
- -- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jun 2021 06:49:21 +0000

On Thu, 2021-06-10 at 11:56 +0800, [email-masked] wrote:
> Add one more co-existing policy:
> 4) draft-hinden-6man-hbh-processing, which would only process part
> of it.
> 5) draft-ietf-opsec-ipv6-eh-filtering, in which the processing policy
> for the packets with HBH EH is DROP or IGNORE

No need to add anything extra: -- that's part of the deployed reality.

Thanks,
- -- 
Fernando Gont

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Jun 2021 11:56:13 +0800

Add one more co-existing policy:
1) rfc2460 implementations, which aim to process all HbH
2) Deployed reality which drops HbH
3) RFC8200 implementations -- which ignore HbH unless required
4) draft-hinden-6man-hbh-processing, which would only process part of it.
5) draft-ietf-opsec-ipv6-eh-filtering, in which the processing policy for the packets with HBH EH is DROP or IGNORE

Best Regards,
Zhenqiang Li

[email-masked]
 
From: Fernando Gont
Date: 2021-06-10 01:12
To: [email-masked]; [email-masked]
Subject: Re: HBH Option Header Configuration (draft-hinden-6man-hbh-processing)
 
Hello, Bob,

 

 

 

 

 

 

 
 
Thanks,
- -- 
Fernando Gont

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Jun 2021 03:29:14 +0000

On Fri, 2021-06-11 at 11:13 +0800, [email-masked] wrote:
> So, list item No.2 is not accurate, the deployed reality is DROP or
> IGNORE.
> List item No.5 is not only the deployed reality, but also the
> standard behavior explicitly stated in a WG document.

There's quite a bit of a difference between a standard behavior or an
operational practice.

- -- 
Fernando Gont

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jun 2021 11:13:02 +0800

So, list item No.2 is not accurate, the deployed reality is DROP or IGNORE.
List item No.5 is not only the deployed reality, but also the standard behavior explicitly stated in a WG document.

Regards,
Zhenqiang Li

[email-masked]
 
From: Fernando Gont
Date: 2021-06-10 14:49
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Re: HBH Option Header Configuration (draft-hinden-6man-hbh-processing)

 
Thanks,
- -- 
Fernando Gont