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

[Warren Kumari <[e-mail]>]

On Wed, May 29, 2024 at 8:17 PM, Bob Hinden <[e-mail]> wrote:

> Warren,
>
> Comments below.
>
> Bob & Gorry
>
> On May 29, 2024, at 2:59 PM, Warren Kumari via Datatracker <noreply@ietf.
> org> 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.
>

Yup, that would work. Mostly I don't want people to think that the "a
router MUST NOT drop a packet solely because it contains an Extension
Header carrying Hop-by-Hop options" prohibits a router implementation is
not allowed to have a filter which matches on HbH.
For example, this should still be allowed…:
filter protect-old-legacy-routers {
    term vendor_foo_falls_over_on_hbh {
        from {
            extension-header hop-by-hop;
        }
        then discard;
    }
}


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


Ok, thanks.


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

Thank you!


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


Awesome, thank you!


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


Ta!


> Nits:
>
> Thanks, we will fix..
>


Ta!

Thank you, and apologies again for the lateness of the ballot.
W


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