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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Brian E Carpenter
> Sent: mardi 8 juin 2021 22:49
> To: Nick Hilliard <[e-mail]>; Bob Hinden <[e-mail]>
> Cc: IPv6 List <[e-mail]>
> Subject: Re: HBH Option Header Configuration (draft-hinden-6man-hbh-
> processing)
> 
> On 09-Jun-21 08:18, Nick Hilliard wrote:
> > 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.
> 
> 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
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------