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

[Warren Kumari via Datatracker <[e-mail]>]

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.

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.

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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