[IPv6]Re: Warren Kumari's Discuss on draft-ietf-6man-hbh-processing-18: (with DISCUSS and COMMENT)

[Bob Hinden <[e-mail]>]

Warren,

Comments below.

Bob & Gorry

> On May 29, 2024, at 2:59 PM, Warren Kumari via Datatracker <[e-mail]> wrote:
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-6man-hbh-processing-18: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Apologies for the late-breaking DISCUSS.

:-(    

> 
> I am unclear on the following text:
> "If a router does not process the Hop-by-Hop Options header, it MUST forward
> the packet normally based on the remaining Extension Header(s) after the
> Hop-by-Hop Option header (i.e., a router MUST NOT drop a packet solely because
> it contains an Extension Header carrying Hop-by-Hop options).".
> 
> As noted in the document, many networks do not currently follow this behavior,
> and it appears that in some cases this is because the network has chosen to
> filter packets with Hop-by-Hop options. It is unclear to me if this is intended
> to prohibit this behavior. Operators may need to perform this filtering -- for
> example, their "border" router may need to filter packets containing HbH
> options to protect interior devices which have not yet been upgraded (or
> similar). I'm **assuming** that you are not trying to prohibit vendors
> providing the ability to filter HbH packets, but this is not clear.

The draft is attempting to reduce this behavior (dropping packets because they contain the HBH options), and to make it the default to forward packets with HBH option headers instead of dropping the packet.

Note that RFC8200 doesn’t mention dropping packets, just not processing the options based on local configuration:

   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.

We do understand, that nodes will continue to do this and that an IETF specification can’t change that.   What do you suggest?    

We could say something to the effect that some nodes will drop packets containing HBH options to protect other routers who can’t process them safely.   Or something similar.   

> 
> I don't really understand the interplay between Section 5.1.1 (Configuration
> Enabling Hop-by-Hop Header Processing) and Section 5.2 (Hop-by-Hop Options
> Processing). S 5.1.1 notes that "Section 4 of [RFC8200] allows a router to
> control its processing of IPv6 Hop-by-Hop options by local configuration." and
> that "it is now expected that nodes along the path only examine and process the
> Hop-by-Hop Options header if explicitly configured to do so.", but Section 5.2
> says: "A router SHOULD NOT therefore be configured to process the first
> Hop-by-Hop option if this adversely impacts the aggregate forwarding rate." The
> "[a] router SHOULD NOT ..." text sounds like it is trying to change the default
> from "nodes along the path only examine and process the Hop-by-Hop Options
> header if explicitly configured to do so" into "they normally should, unless
> this adversely impacts the aggregate forwarding rate.". If that is the intent,
> this should be clearer.

Yes, we can make that clearer, I can see how it is confusing.  

Looking at the text, the second paragraph in 5.2 should probably be moved the earlier section 5.1.1 about configuration.  That paragraph is saying don’t create configuration to process an option if it can’t be done at full forwarding rate.  Or maybe it is obvious and should be removed.

> 
> Actually, I find really difficult to figure out what *exactly* has changed from
> RFC8200. Section 5 says "This section describes several changes to [RFC8200].",
> but the actual changes are not particularly clear (modulo the "Option Type
> identifiers" changes, which are nice and clear).

RFC8200 doesn’t say a lot about processing HBH options except for:

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

   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 draft is expanding on these two paragraph on how HBH options should be processed (basically Section 5).    We could add some text that says that clearly.

BTW, Section 6 is clear that it is updating Section 4.8 of [RFC8200].

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

Many of comments you raised below were also raised in other IESG reviews, especially John Scudders.   The authors are working on an update that resolves them.
> 
> I initially had this as part of the DISCUSS, but moved it to a comment instead.
> I find this bit of text ambiguous (or at least unclear): "A router SHOULD NOT
> therefore be configured to process the first Hop-by-Hop option if this
> adversely impacts the aggregate forwarding rate.  A router SHOULD process
> additional Hop-by-Hop options, if configured to do so, providing that these
> also do not adversely impact the aggregate forwarding rate." This could be read
> as: 1: The router should be configured to skip the first HbH option, but should
> process the additional ones. 2: The router should process the first HBH option,
> but unless there is explicit configuration it should ignore the rest. The
> "SHOULD NOT" vs "SHOULD" and double-negatives makes this hard to read, and also
> makes it sounds like there are expected to be a number configuration knobs here
> (First vs Subsequent HbH options).
> 
> A similar problem occurs here:
> "If a router is unable to process any Hop-by-Hop option (or is not configured
> to do so), it SHOULD behave in the way specified for an unrecognized Option
> Type when the action bits were set to "00" " I'm assuming you mean "If a router
> either unable (or configured) to not process any Hop-by-Hop option ..." ?
> 
> and then again here:
> "If a router is unable to process further Hop-by-Hop options (or is not
> configured to do so), the router SHOULD skip the remaining options using the
> "Hdr Ext Len" field in the Hop-by-Hop Options header. " I think that the
> document would benefit greatly from some clarity here -- I'm assuming that the
> intent is only a single configuration knob, but it's really not clear...


> Is this duplication, or is there a meaningful difference in these two sentences
> (destination vs host): "It is expected that the Hop-by-Hop Options header will
> be processed by the destination. Hosts SHOULD process the Hop-by-Hop Options
> header in received packets."?
> 
> I don't really understand some of the SHOULDs in Section 6 -- e.g: "New
> Hop-by-Hop options SHOULD be designed to ensure the router can process the
> options at the full forwarding rate." -- what router? I have a Cisco 2509
> sitting in a rack in my basement. It has very different processing
> characteristics to an M40 or modern Cisco or a Linux box, and they way that
> they process HbH packets differs wildly. I agree with the sentiment, but not
> how this is worded. I think that this should be clarified, or at least the
> SHOULD should become a should...

The Uppercase SHOULD/MUST was changed to lower case based on Roman Danyliw's review.  That is in -18 we just published.

> 
> Nits:

Thanks, we will fix..


> 1: "The reason behind this includes:" - reasons, include?
> 2: "or that forward packets" - forwards.
> 3: "The Router Alert Option [RFC2711] is an exception that can result in
> processing in the control plane, see Section 5.2.1." - perhaps "that can
> require processing by the control plane"? Or perhaps I don't understand what
> this is trying to say. 4: "When an ICMP Parameter Problem, Code 2, message is
> delivered to the source, the source can become aware that at least one node on
> the path has failed to recognize the option." - I don't have a suggestion, but
> "the source can become aware" make it sound like this is an information leakage
> issue, and not the actual intent of the ICMP Code. 5: "The Router Alert Option
> could have a potential for use with new functions that have to be processed in
> the control plane." - "The Router Alert Option could potentially be used by new
> functions that have to be processed in the control plane." ? 6: "An
> implementation that does recognize the Router Alert Option, SHOULD verify that
> a" - drop the comma. 7: The document sets an expectation that if a packet
> includes a single Hop-by-Hop option that packet will be forwarded across the
> network path."  - there is a random closing quote. 8: "If a subset of packets
> in a flow were to include Hop-by-Hop options, this could introduce a potential
> to increase the number" - could potentially ?
> 
> 
>