IPv6 Hop-by-Hop Options Processing Procedures
draft-ietf-6man-hbh-processing-20

[Ballot comment]
Thank you for addressing my DISCUSS, and also addressing my comments.

I initially balloted DISCUSS, and then moved to NoObj once my DISCUSS was addressed, and am now balloting YES.

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

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

[Ballot comment]
Thank you to Behcet Sarikaya for the GENART review.

Thank you for addressing my DISCUSS feedback.

** What is the relationship between the guidance found in this document and the filtering guidance in RFC9288?

[Ballot comment]
Thank you for the sensible and sensitive work done in this document. The IETF community needs to continue to allow the Internet and IP to move forward.

Thanks for addressing my previous blocking DISCUSS ballot as well as many (if not all) of my COMMENTS see:
https://mailarchive.ietf.org/arch/msg/ipv6/UW5M-7RN1P3EJknROH9-3tf8I1s/

[Ballot comment]
Thanks for working on this specification. Thanks for Brian Trammell for the TSVART review.

I have no issues here from transport protocol point of view, however, I am supporting Roman's discuss as I would also like to know what is classified as reasonable exception.

[Ballot comment]
(I realized I had forgotten to capture one point while transcribing my notes. This updated ballot adds one more point, right at the end.)

This document uses a lot of words to say what is ultimately a fairly simple message. It's also an important message, so I think it's worth the time to communicate it clearly; hence the effort put into this review. (The quote attributed to Pascal, to the effect of "I am sorry I have written you a long letter, I did not have time to write you a short one" might apply here.)

As far as I can tell, the spec's TL;DR is:

Routers:

- SHOULD process HbH options as long as they can do so without compromising
  forwarding rate.
- If it would compromise forwarding rate, they should triage the HbH
  options they process. (Details of triage not specified other than
  letting the operator configure HbH options to respect/ignore.)
- Can ignore the whole HbH header by default, or can process it but use
  configuration to control what individual HbH options are processed.
- MUST NOT drop a packet just because it contains a HbH header.
- SHOULD make the list of HbH options that are processed configurable.

- Concerning the RA option, if processing it at all,
- "MUST protect itself from infrastructure attack".
- Shouldn't bother the control plane for an RA that has no Value field
  of interest.

Hosts when receiving:

- SHOULD process HbH headers, and process all options within
- But may choose not to process them (e.g. constrained hosts)
- For any HbH header not processed, they MUST (Section 5.1) behave as if
  it wasn't present.
 
Hosts when sending:

- SHOULD "use a method that is robust".
- MAY include more than one HbH option.

I feel fairly strongly that this document would be more valuable if it were less expository, more prescriptive, and shorter -- "crisper", if you like. However, my concerns don't rise to the level of blocking publication, so I've captured some specific and potentially actionable points in comments, and I understand that the authors' preferences may not be the same as mine, or that they may not have the appetite for a large rewrite. On the other hand, if you're up for the challenge, I'm willing to contribute more effort.

Note that not all of my comments are of that nature, many relate to correctness and accuracy -- so even if you completely disagree with my editorial point of view, please look over the rest of them.

## COMMENT

### Section 3, cut-and-paste error?

  *  control plane: IPv6 routers exchange control information through
      the control plane.  This processes the management and routing
      information exchanged with other routers. 

So far so good.

                                                Routers process fields
      contained in packet headers.  However, they do not process
      information contained in packet payloads.

This sentence is a verbatim copy of a sentence in the definition of "forwarding plane". Is it a cut-and-paste error? It doesn't seem relevant to a definition of the control plane.

### Section 4, rewrite for clarity, add informative reference

The pronouns and determiners in the last couple of paragraphs make it hard to nail down what they mean. I think a simple rewrite to add more specificity would help. Assuming I've understood your meaning correctly, something like this,

OLD:
  "Transmission and Processing of IPv6 Extension Headers" [RFC7045]
  clarified how intermediate nodes should process Extension Headers.
  This document is generally consistent with [RFC7045], and was raised
  as an issue for discussion when [RFC2460] was updated and replaced by
  [RFC8200].  This document updates [RFC8200] as described in the next
  section and consequently clarifies the description in Section 2.2 of
  [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174].

  The document defines a set of procedures for the Hop-by-Hop Options
  header that are intended to make the processing of Hop-by-Hop options
  practical in modern transit routers.  The common cases are that some
  Hop-by-Hop options will be processed across the Internet, while
  others will only be processed within a limited domain [RFC8799]
  (e.g., where a specific service is made available in that network
  segment that relies on one or more Hop-by-Hop options).

NEW:
  "Transmission and Processing of IPv6 Extension Headers" [RFC7045]
  clarified how intermediate nodes should process Extension Headers.
  The present document is generally consistent with [RFC7045], and
  addresses an issue that was raised for discussion
  when [RFC2460] was updated and replaced by
  [RFC8200].  This document updates [RFC8200] as described in the next
  section and consequently clarifies the description in Section 2.2 of
  [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174].

  This document defines a set of procedures for the Hop-by-Hop Options
  header that are intended to make the processing of Hop-by-Hop options
  practical in modern transit routers.  The common cases are that some
  Hop-by-Hop options will be processed across the Internet, while
  others will only be processed within a limited domain [RFC8799]
  (e.g., where a specific service is made available in that network
  segment that relies on one or more Hop-by-Hop options).

Since you allude to "an issue that was raised for discussion", it also wouldn't go amiss to provide an informative citation to the relevant list thread.

### Section 5.1, use the RFC 8200 words

Suggested rewording, both for correctness and to use the language of RFC 8200:

OLD:
  [RFC8200] also requires that a Hop-by-Hop Options header only appear
  once in a packet.

NEW:
  [RFC8200] also requires that a Hop-by-Hop Options header appear at most
  once in a packet.
 
### Sections 5.1, 5.1.1, clarity

You juxtapose a quote from RFC 8200 that says (my paraphrase, with BCP 14 keyword added to be provocative) "routers SHOULD NOT process the HbH header unless explicitly configured to do so", next to a new requirement that "clarifies that a configuration could control whether processing skips any specific" HbH option. I'll paraphrase that one too, again inserting a BCP 14 keyword, as "routers MAY instead process the HbH header by default while allowing configuration to disable specific options."

I guess those two things are compatible, but I had to do too much work to extract that interpretation and I'm not even confident that's really what you're trying to say. Can you confirm that it is?

As a follow-up, if my paraphrase is right, how do you reconcile Section 5.1 where you say "Routers SHOULD process the Hop-by-Hop Options header" with (my paraphrase of) RFC 8200? You might reply that I've changed the meaning of Section 5.1 by omitting "using the method defined in this document", but if so I think you should rephrase the Section 5.1 language for clarity, as in,

OLD:
  Routers SHOULD process the Hop-by-Hop Options header using the
  method defined in this document

NEW:
  Routers that process the Hop-by-Hop Options header SHOULD do so
  using the method defined in this document.
 
On the other hand, if you intend that "Routers SHOULD process the Hop-by-Hop Options header", I think you have more work to do in Section 5.1.1, as discussed above.

### Section 5.2, first HbH option

The first couple of paragraphs appear to privilege the first HbH option compared to the rest. Is this deliberate? Can you help me understand why, if so?

For example,

  A router configuration needs to avoid vulnerabilities that arise when
  it cannot process the first Hop-by-Hop option at full forwarding
  rate.  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.

When I unpack this, how is it different from (my text):

  A router configuration needs to avoid vulnerabilities that arise when
  processing of a Hop-by-Hop option would prevent it from forwarding at
  full forwarding rate.  A router SHOULD process Hop-by-Hop options, if
  configured to do so, providing that these do not adversely impact the
  aggregate forwarding rate.

The primary change in my rewrite was to cut

  A router SHOULD NOT therefore be configured to process the
  first Hop-by-Hop option if this adversely impacts the aggregate
  forwarding rate. 
 
As far as I can tell the rewrite is semantically the same, but I'm concerned that I have missed something, otherwise, why would you have put in that special mention of the first option? :-(

One interpretation I came up with after reading it a few times is that what you mean is something like "when it cannot process even a single Hop-by-Hop option at full forwarding rate". Does that get at your intent? I appreciate that practically speaking, most forwarding code will go through the options serially starting with the first, but not only is that not a requirement, but in some of your other text you drive home the message that the order of processing is not guaranteed. So, I think you should be careful to separate that assumption from what you're trying to specify.

This is only one example. Another is the first paragraph,

  A source creating packets with a Hop-by-Hop Options header SHOULD use
  a method that is robust to network nodes processing only the first
  Hop-by-Hop option that is included in the packet, or that forward
  packets without the option being processed (see Section 6.1).
 
I would've expected something more like,

  A source creating packets with a Hop-by-Hop Options header SHOULD use
  a method that is robust to network nodes selectively processing only
  some of the
  Hop-by-Hop options that are included in the packet, or that forward
  packets without the option(s) being processed (see Section 6.1).

As it is, a close reading of the sentence tells me it's fine if the method is *not* robust to network nodes that process only the second option, for example.

This isn't a full scrub of the section, e.g. the fourth paragraph has "further" (after what? The first? The last one successfully processed?)

### Section 5.2, including more than one HbH option

I found "A source MAY, based on local configuration, include more than one Hop-by-Hop option" peculiar, given that there's never been a restriction on that in the past (has there?), i.e. you're granting permission for something that was always allowed, so... thanks? I think I see what you're doing, which is to subtly throw shade on the idea of including more than one HbH option, but if you want to do that, why do it subtly? E.g., you could go whole hog with something like

  A source SHOULD NOT include more than one Hop-by-Hop option, although
  it MAY do so based on local configuration. In the latter case it might
  wish to restrict the size...

### Section 5.2, clarity

OLD:
  If a router is unable to process any Hop-by-Hop option (or is not

NEW:
  If a router is unable to process a given Hop-by-Hop option (or is not

### Section 5.2, sense of "any" is underdetermined

  This document modifies this behaviour for the "01", "10", and "11"
  action bits, so that 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".  It also modifies the behaviour for the "10" and "11"

Is "any Hop-by-Hop option" supposed to mean "any given HbH option" or is it supposed to mean "no HbH option"? I think it's the former, in which case, I suggest the change.

### Section 5.2, clarity, standalone patch

  This document modifies this behaviour for the "01", "10", and "11"
  action bits, so that 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". 
... 
  The modified text for "01", "10", and "11" values is:

      01 - MAY discard the packet. Nodes should not rely on routers
            dropping these unrecognized Option Types.

      10 - MAY discard the packet
...
      11 - MAY discard the packet
...

And as a reminder (to me, at least!), 00 is:

      00 - skip over this option and continue processing the header.
     
I had to go over this several times before I finally worked out that the modified text for the three values quoted above is not actually in conflict with the SHOULD in the first quoted paragraph. While puzzling over it, I also noticed that even though all three values are modified to permit discard, only the first includes the sentence "Nodes should not rely on routers dropping these unrecognized Option Types".

It seems to me that even though it would make the document more verbose, and isn't strictly mandatory for technical correctness upon careful reading, it would be helpful for clarity to spell things out more explicitly, as in,

NEW:
  The modified text for "01", "10", and "11" values is:

      01 - SHOULD behave as specified for 00, but MAY discard the packet
            if so configured.

      10 - SHOULD behave as specified for 00, but MAY discard the packet
            if so configured and, regardless of whether or not the
            packet's Destination Address was a multicast address, and if
            the packet was discarded, MAY send an ICMP Parameter
            Problem, Code 2, message to the packet's Source Address,
            pointing to the unrecognized Option Type.

      11 - SHOULD behave as specified for 00, but MAY discard the packet
            if so configured and, only if the packet's Destination
            Address was not a multicast address, and the packet was
            discarded, MAY send an ICMP Parameter Problem, Code 2,
            message to the packet's Source Address, pointing to the
            unrecognized Option Type.

  Nodes should not rely on routers dropping unrecognized Option Types.
 
I added a SHOULD clause for each. I also added "if so configured" to the MAY parts, it's unclear to me if that's overreach or helpful clarification of intent since I don't know if you intended the MAY to cover other cases too. Finally, I factored out the "should not rely on" sentence so that it doesn't appear to apply only to the 01 case.

Apart from simple readability, the other argument I'd give in favor of making this change (or one like it) is that in this kind of patch-type approach to updating a base document (which is what this is, despite the fact you haven't used OLD/NEW blocks), it's desirable for the patched base document to at least potentially stand alone.

### Section 5.2, "a multicast address", plus RFC 2119 keyword

I have two concerns about

  When a node sends an ICMP message in response to a packet with a
  multicast address, this could be exploited as an amplification
  attack.  This is particularly problematic when the Source Address is
  not valid (which can be mitigated to varying degrees by using a
  reverse path forwarding (RPF) check).  A node SHOULD only send ICMP
  messages in response to a packet with a multicast address when this
  is enabled for the specific Source Address and/or the group
  Destination Address.

The first concern is that when you write "a packet with a multicast address", it's not clear, until one reads the final sentence, that you mean either the source address or the destination address. I suggest spelling it out explicitly. The second concern is that although your intent with "SHOULD only" is clear enough, it doesn't fit the RFC 2119 definition of SHOULD. A possible rewrite to cover both concerns is,

NEW:
  When a node sends an ICMP message in response to a packet with a
  multicast source or destination address, this could be exploited as
  an amplification
  attack.  This is particularly problematic when the Source Address is
  not valid (which can be mitigated to varying degrees by using a
  reverse path forwarding (RPF) check).  A node SHOULD NOT send ICMP
  messages in response to a packet with a multicast source or
  destination address unless this
  is enabled for the specific Source Address and/or the group
  Destination Address.
 
(You could use "and/or" wherever I have put "or", but in my view it's not necessary, after all, it's not "xor".)

### Section 5.2, expository paragraph needed?

Is this paragraph doing any necessary work?

  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.  Generating an ICMP message
  incurs additional router processing.  Reception of this message is
  not guaranteed, routers might be unable to be configured so that they
  do not generate these messages, and they are not always forwarded to
  the source.  The motivation here is to loosen the requirement to send
  an ICMPv6 Parameter Problem message when a router forwards a packet
  without processing the list of all options.

I can see how it might've been needed during working group development of the document, but if I imagine I'm an implementor reading this spec, I'm not sure what I do with it. As far as I can tell the whole thing can be condensed down to "you might not get an IMCP parameter problem if one of your options isn't recognized, but then again that was always true"... and because of "that was always true", you could leave it out without harm.

### Section 5.2.1

      The function of a Router Alert Option can result in the processing
      that this specification is proposing to eliminate, that is, to
      instruct a router to process the packet in the control plane.
     
I don't think this specification is solely proposing to protect the control plane, it's also trying to protect the forwarding plane from option lists that are too heavyweight to be processed at line rate in the fast path. (Bullets 3 and 4 in the second bullet list in Section 4.)

Fortunately, a rewrite to correct this is as simple as removing one definite article.

NEW:
      The function of a Router Alert Option can result in processing
      that this specification is proposing to eliminate, that is, to
      instruct a router to process the packet in the control plane.

### Section 5.2.2, inappropriate RFC 2119 keyword

The final paragraph of this section is the single sentence,

  The actions of the lookup table SHOULD be configurable by the
  operator of the router.

But the previous paragraph told me that said lookup table is "a possible approach". It seems weird to me to use an RFC 2119 keyword to mandate behavior specific to "a possible approach". If I were you, I'd use lowercase "should", and I would combine this paragraph with the preceding one.

### Section 6, "simple to process" isn't actionable

  *  New Hop-by-Hop options SHOULD be designed to ensure the router can
      process the options at the full forwarding rate.  That is, they
      should be simple to process (see Section 5.2).

I don't see anything in Section 5.2 that tells me how to make an option simple to process. If you think it does explain that, please help me understand how. Otherwise, I think you should remove the cross-reference.

For that matter, even with the suggested change, this bullet point makes me a little bit sad because it feels isomorphic to the famous "don't write bugs" advice. (See also RFC 9225.) But, ¯\_(ツ)_/¯

### Section 8, forcing packets to the slow path can also harm the control plane

  Security issues with including IPv6 Hop-by-Hop options are well known
  and have been documented in several places, including [RFC6398],
  [RFC6192], [RFC7045] and [RFC9098].  The main issue, as noted in
  Section 4, is that any mechanism that can be used to force packets
  into the router's control plane can be exploited as a Denial-of-
  Service attack on a transit router by saturating the resources needed
  for router management (routing protocols, network management
  protocols, etc.) and cause the router to fail or perform sub-
  optimally.

There is a related but not identical issue, which is that in many routers, some resources are shared between the control plane and the slow path -- you nod to this in your definition of "slow path" in Section 3. Even if packets are forced only into the slow path, but not the control plane, that can still work as a denial of service attack against the control plane. I suppose we might get into an ontological debate about what exactly "the control plane" is in this context and whether the paragraph as written already encompasses it, but I think it would be better to err on the side of completeness even if it requires a bit more verbosity. The fix I propose is simple enough, though: s/control plane/slow path or control plane/.

### Section 8, misleading bullet points

I think these two bullet points are misleading in a couple of ways:

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

  *  Additional Hop-by-Hop options MAY be included, based on local
      configuration.  Nodes only process these additional Hop-by-Hop
      options if configured to do so.

The first bullet, by focusing on "a single Hop-by-Hop option", implies that if multiple options were included, the packet might not be forwarded. I think that's not right, per my understanding of the document.

The second bullet's second sentence ("only process... if") appears to be a case of "the exception proves the rule" that nodes commit to processing the first Hop-by-Hop option. But this is also not right. For that matter, it's not clear whether "nodes" in that sentence refers to destination or intermediate nodes. I have assumed the latter.

A rewrite might be,

NEW:
  *  The document sets an expectation that if a packet includes a
      Hop-by-Hop Options header that packet will be forwarded across the
      network path.

  *  A source MAY include one or more Hop-by-Hop options. Whether
      any of these options is processed, and if so which and how many,
      is dependent on the configuration of intermediate nodes.

[Ballot discuss]
** Section 6.  There appears to be a mismatch in the combination of normative guidance:

  Any new Hop-by-Hop option that is standardized that does not meet
  these criteria MUST include in the specification a detailed
  explanation why this cannot be accomplished and to show that there is
  a reasonable expectation that the option can be proceed at full
  forwarding rate.

This text is preceded by a bulleted list of five items which each contain a SHOULD clause.  What does it mean for a “SHOULD” statement to meet or not meet a criteria?  Whether it implements the guidance in the bullet list or not, an implementation will be conformant.

[Ballot comment]
Thank you to Behcet Sarikaya for the GENART review.

** What is the relationship between the guidance found in this document and the filtering guidance in RFC9288?

[Ballot comment]
Many thanks to Peter Yee for his reviews. 

Section 8, paragraph 4: Nit:  Echoing a concern that Peter Yee raised, I feel like this paragraph could be restructured a little to make it clear that this concern is not specific to this draft.  My suggestions is to change the first sentence to: 'Although this is not specific to this draft, it should be noted that Internet protocol processing needs...'.  And then remove the second to last sentence in the paragraph.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-6man-hbh-processing-17

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

Many thanks for this writeup. It is well written and a nice read to explore the wonderful opportunities and associated deep dark secrets embodied with HbH options.

In the COMMENTS section i have added a series of comments with additional context.

I hope this review and the various observations provide a way to help improve the document.

One question i had at the end of reading the draft, is if a transit node may for performance optimization reorder, whiteout changing or removing options that are enclosed within the HbH header? Why? Maybe a particular implementation is interested in a subset of options and prefers to see them at the beginnings of the HbH header for hardware optimization when steering the packet through the available internet paths?

G/


#DETAILED COMMENTS
#=================

13   This document specifies procedures for how IPv6 Hop-by-Hop options
14   are processed in IPv6 routers and hosts.  It modifies the procedures
15   specified in the IPv6 Protocol Specification (RFC 8200) to make
16   processing of the IPv6 Hop-by-Hop Options header practical with the
17   goal of making IPv6 Hop-by-Hop options useful to deploy and use in
18   the Internet.  When published, this document updates RFC 8200.


The word "practical" in this context can be improved for clarity and precision. A better word might be "efficient" or "feasible," which conveys the intention to make the processing of IPv6 Hop-by-Hop Options more manageable and effective in real-world deployments.

similar use of the word practical was observed in the introduction section also.

117   *  Fast Path: A path through a router that is optimized for
118       forwarding packets.  The Fast Path might be supported by
119       Application Specific Integrated Circuits (ASICs), a Network
120       Processor (NP), or other special purpose hardware.  This is the
121       usual processing path within a router taken by the forwarding
122       plane.

The word "usual" in this context is appropriate, but "typical" or "standard" might be better choices to convey the intended meaning more clearly.

139   NOTE: [RFC6192] is an example of how designs can separate control
140   plane and forwarding plane functions.  The separation between
141   hardware and software processing described in [RFC6398] does not
142   apply to all router architectures.  However, a router that performs
143   all or most processing in software might still incur more processing
144   cost when providing special processing for Hop-by-Hop options.

How about a slight rewrite of the section to enhance its readability:

"Note: [RFC6192] provides an example of how designs can separate control plane and forwarding plane functions. The separation between hardware and software processing described in [RFC6398] does not apply universally to all router architectures. However, routers that perform all or most processing in software may still incur higher processing costs when providing special handling for Hop-by-Hop options."

163   *  If a subset of packets in a flow were to include Hop-by-Hop
164       options, this could introduce a potential to increase the number
165       of re-ordered packets and the re-ordering distances of the packets
166       delivered to the destination.  This might result when the
167       Extension Header was included in only some packets, or if a
168       specific Hop-by-Hop option required different processing for some
169       packets in a flow.  Significant reordering of the packets
170       belonging to a flow can impact the performance of upper layer
171       protocols and needs to be avoided.

It took me few times reading this section to fully grasp the intent.
I tried to slightly reword the section for convenience:

"If a subset of packets within a flow includes Hop-by-Hop options, this may lead to an increased number of reordered packets and greater reordering distances for packets delivered to the destination. Such reordering could occur if the Extension Header is included only in some packets, or if a specific Hop-by-Hop option necessitates different processing for certain packets within the flow. Significant reordering of packets within a flow can negatively impact the performance of upper-layer protocols and should therefore be avoided.
"

173   *  Packets could include multiple Hop-by-Hop options.  Too many
174       options could make the previous issues worse by increasing the
175       resources required to process them.  The total size of the options
176       determines the number of header bytes that might need to be
177       processed.  Measurements [Cus23a] show that the probability of
178       successful transmission is currently higher for packets that
179       include Options when it results in a short total Extension Header
180       (EH) Chain size (e.g., less than 40 bytes).

s/previous/aforementioned/

217   The main issues remain:

s/issues/concerns/

285   "Transmission and Processing of IPv6 Extension Headers" [RFC7045]
286   clarified how intermediate nodes should process Extension Headers.
287   This document is generally consistent with [RFC7045], and was raised
288   as an issue for discussion when [RFC2460] was updated and replaced by
289   [RFC8200].  This document updates [RFC8200] as described in the next

For clarity maybe 'this document' should be more explicit that it is about draft draft-ietf-6man-hbh-processing-17 and not about RFC7045, which was what i understood when i first read this section, and had to re-read the text again. i tried too come up with an text blob to clarify this, but i couldn't unfortunately

331   It is expected that the Hop-by-Hop Options header will be processed
332   by the destination.  Hosts SHOULD process the Hop-by-Hop Options

Earlier in the document it was mentioned that the destination address is multicast, and that there may be multiple destinations that process the packet. The text here seems to imply that there is only a single destination. Hence maybe

s/destination/destination(s)/

469   DISCUSSION

Is this section intended like this for the rfc-to-be, or is this to trigger discussions somewhere in the WG?

516   A possible approach to implementing this is to maintain a lookup
517   table based on Option Type of the IPv6 options that can be processed
518   at full forwarding rate.  This would allow a router to quickly
519   determine if an option is supported and can be processed.  If the
520   option is not supported, then the router processes the option as
521   described in Section 5.1 of this document.

Do we need this paragraph? Can it be left out (i do not have strong feelings if section remains though)? Implementers will do whatever they do to comply with their technology to select/identify those options they are instructed to process

534   *  New Hop-by-Hop options SHOULD be designed to ensure the router can
535       process the options at the full forwarding rate.  That is, they
536       should be simple to process (see Section 5.2).

I am not sure that the keyword here is 'simple to process'. It seems that the requirement is that it can be processed in 'fast path by hardware' maybe?

563   The general issue of robust operation of packets with new Hop-by-Hop
564   options is described in Section 6.1 below.

s/issue/concern/

568   Recent measurement surveys (e.g., [Cus23a]) show that packets that
569   include Extension Headers can cause the packets to be dropped by some
570   Internet paths.  In a controlled domain, routers can be configured or
571   updated to provide support for any required Hop-by-Hop options.

in an earlier part of the text the term 'limited domain' was used. Would using this term be appropriate here also?

573   The primary motivation of this document is to make it more practical
574   to use Hop-by-Hop options beyond such a single domain, with the

Same as the previous comment. Is the text suggesting a limited domain is intended.

[Ballot comment]
# Jim Guichard, RTG AD, comments for draft-ietf-6man-hbh-processing-17. All comments provide indits line numbers from v-17 of the document.

84   An IPv6 packet includes Hop-by-Hop options by including a Hop-by-Hop
85   Option header.  The current list of defined Hop-by-Hop options can be
86   found at [IANA-HBH].  The focus for this document is to set the
87   minimum requirements for router processing of Hop-by-Hop options.

Jim> The previous paragraph says that the document has the goal of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6 routers and hosts. However, the above does not mention hosts (?). Is this just an omission in the text or is the focus only for routers and therefore the previous paragraph is inaccurate? Please clarify.


111   *  control plane: IPv6 routers exchange control information through
112       the control plane.  This processes the management and routing
113       information exchanged with other routers.  Routers process fields
114       contained in packet headers.  However, they do not process
115       information contained in packet payloads.

Jim> Are the last two sentences accurate in the context of a control plane definition? While both sentences are true they do not seem relevant to the control plane.

309   When a packet includes one or more Extension Headers, the Next Header
310   field of the IPv6 Header does not identify the transport protocol.

Jim> Wouldn’t it be better to say ‘what’ the Next Header field indicates rather than what it ‘does not’. There are lots of things it ‘does not’ indicate.

[Ballot discuss]
# Éric Vyncke, INT AD, comments for draft-ietf-6man-hbh-processing-17

Thank you for the work put into this document. The very first drafts of this work were raising my eyebrows as they put limits put on the IPv6 evolution, this version is much more palatable.

Please find below blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), one nit.

Special thanks to Jen Linkova for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Bernie Volz, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-6man-hbh-processing-16-intdir-telechat-volz-2024-05-12/ (I share some concerns of Bernie and am hoping that the authors will address them as seen in the change log for -17)

Please note that János Farkas is the IoT directorate reviewer (at my request) and you may want to consider this iot-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/reviewrequest/19466/

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

## Section 5.1

Unsure whether adding a reference to [I-D.ietf-6man-eh-limits] is adequate here. If authors want to keep it, then it is a normative reference and not informative. Suggest removing this part. See also my similar comment in section 1.

## Section 5.2

Also use  [I-D.ietf-6man-eh-limits] in a normative way, i.e., this reference must be normative and not informative. Same reasoning in section 6.

The last two paragraph are about mcast packets, isn't it covered by RFC 4443 ? This RFC 4443 should probably be an informative reference and if the process of RFC 4443 is modified, then this I-D should also formerly update RFC 4443.

[Ballot comment]

# COMMENTS (non-blocking)

As a side note, I appreciate John Scudder's summary of this I-D.

## Section 1

Definining a procedure for host(s) to handle HbH is already a little weird in my mind. Moreover, section one is limiting to routers `The focus for this document is to set the minimum requirements for router processing of Hop-by-Hop options` i.e., no mention of host. Should the abstract be updated ?

I was about to raise a discuss on the topic of [I-D.ietf-6man-eh-limits] as it is not guaranteed at all that this document has IETF consensus. Strongly suggest removing this paragraph.

## Section 3

`IPv6 routers exchange user data` it is not always user-related data, i.e., how is telemetry qualified ? I.e., suggest using user or applications data.

`Routers process fields contained in packet headers.` should be qualified into "packet layer-3 headers" (as opposed to HTTP headers). (both for forwarding and control planes).

## Section 4

`control/management components`, should the management component be introduced in the terminology section ?

`This might result when the Extension Header was included in only some packets, or if a specific Hop-by-Hop option required different processing for some packets in a flow.`  while I do not disagree with the statement, this I-D is about HbH, so please remove the mention of 'extension header' in general.

`Measurements [Cus23a] show that the probability of successful transmission is currently higher for packets that include Options when it results in a short total Extension Header (EH) Chain size (e.g., less than 40 bytes)` while I do like this study and similar ones, "successful transmission" should probably be qualified by "over the public global Internet". If based on a study, then I am unsure whether 'e.g.' should be replaced by 'i.e.' ?

`This could protect against a Denial-of-Service attack on the router [RFC9098]` this should be less assertive, e.g., 'This may be done to protect against ...'

`practical in modern transit routers` are not all routers 'transit' ? I.e., remove 'transit' in this sentence ?

## Section 5.1

`Routers SHOULD process the Hop-by-Hop Options header using the method defined in this document. If a router does not process the Hop-by-Hop Options header, it MUST ` I am unsure how to interpret the normative language in this paragraph: the first SHOULD renders the rest non-normative in my reading, i.e., the MUST later in the paragraph could be ignored. Furthermore, the SHOULD should have a "bypass" clause, i.e., an explanation about when the SHOULD can by bypassed. I was about to raise a DISCUSS on this topic.

`It is expected that the Hop-by-Hop Options header will be processed by the destination.` please use 'destination(s)' as this could be a multicast packet.

`Hosts SHOULD process the Hop-by-Hop Options header in received packets.` actually it is 'nodes' as routers can also be the destination (notably when using routing headers but not only).

## Section 5.1.1

SHould this section use normative language ?

What is meant by 'identifiers' in `process the identifiers of individual Option Types`?

## Section 5.2

The 4th paragraph starting with `If a router is unable to process further Hop-by-Hop options` is probably useless as it is plain RFC 8200 processing.

Should there be a justification or explanation about `MAY discard the packet. Nodes should not rely on routers dropping these unrecognized Option Types.`

## Section 6.1

What is meant by 'domain' in `beyond such a single domain`?

Unsure about the usefulness of the whole section, the document could be lighter and possibly more efficient without it.

## Section 8

This section mentions both "denial-of-service" and DDOS. Is there a difference wrt to HbH threat ?

As noted in the 4th paragraph (starting with `Finally, the document notes that Internet protocol processing needs to be robust to malformed/malicious protocol fields.`), this threat is not limited to HbH, so, I wonder whether it should be in this I-D.

Rather than using 'restrictions' in `The document added restrictions to any future new Hop-by-Hop` let's use recommendations per section 6.

# NITS (non-blocking / cosmetic)

## Section 8

Unmatched trailing " in `single Hop-by-Hop option that packet will be forwarded across the network path."`.

[Ballot comment]
This document uses a lot of words to say what is ultimately a fairly simple message. It's also an important message, so I think it's worth the time to communicate it clearly; hence the effort put into this review. (The quote attributed to Pascal, to the effect of "I am sorry I have written you a long letter, I did not have time to write you a short one" might apply here.)

As far as I can tell, the spec's TL;DR is:

Routers:

- SHOULD process HbH options as long as they can do so without compromising
  forwarding rate.
- If it would compromise forwarding rate, they should triage the HbH
  options they process. (Details of triage not specified other than
  letting the operator configure HbH options to respect/ignore.)
- Can ignore the whole HbH header by default, or can process it but use
  configuration to control what individual HbH options are processed.
- MUST NOT drop a packet just because it contains a HbH header.
- SHOULD make the list of HbH options that are processed configurable.

- Concerning the RA option, if processing it at all,
- "MUST protect itself from infrastructure attack".
- Shouldn't bother the control plane for an RA that has no Value field
  of interest.

Hosts when receiving:

- SHOULD process HbH headers, and process all options within
- But may choose not to process them (e.g. constrained hosts)
- For any HbH header not processed, they MUST (Section 5.1) behave as if
  it wasn't present.
 
Hosts when sending:

- SHOULD "use a method that is robust".
- MAY include more than one HbH option.

I feel fairly strongly that this document would be more valuable if it were less expository, more prescriptive, and shorter -- "crisper", if you like. However, my concerns don't rise to the level of blocking publication, so I've captured some specific and potentially actionable points in comments, and I understand that the authors' preferences may not be the same as mine, or that they may not have the appetite for a large rewrite. On the other hand, if you're up for the challenge, I'm willing to contribute more effort.

Note that not all of my comments are of that nature, many relate to correctness and accuracy -- so even if you completely disagree with my editorial point of view, please look over the rest of them.

## COMMENT

### Section 3, cut-and-paste error?

  *  control plane: IPv6 routers exchange control information through
      the control plane.  This processes the management and routing
      information exchanged with other routers. 

So far so good.

                                                Routers process fields
      contained in packet headers.  However, they do not process
      information contained in packet payloads.

This sentence is a verbatim copy of a sentence in the definition of "forwarding plane". Is it a cut-and-paste error? It doesn't seem relevant to a definition of the control plane.

### Section 4, rewrite for clarity, add informative reference

The pronouns and determiners in the last couple of paragraphs make it hard to nail down what they mean. I think a simple rewrite to add more specificity would help. Assuming I've understood your meaning correctly, something like this,

OLD:
  "Transmission and Processing of IPv6 Extension Headers" [RFC7045]
  clarified how intermediate nodes should process Extension Headers.
  This document is generally consistent with [RFC7045], and was raised
  as an issue for discussion when [RFC2460] was updated and replaced by
  [RFC8200].  This document updates [RFC8200] as described in the next
  section and consequently clarifies the description in Section 2.2 of
  [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174].

  The document defines a set of procedures for the Hop-by-Hop Options
  header that are intended to make the processing of Hop-by-Hop options
  practical in modern transit routers.  The common cases are that some
  Hop-by-Hop options will be processed across the Internet, while
  others will only be processed within a limited domain [RFC8799]
  (e.g., where a specific service is made available in that network
  segment that relies on one or more Hop-by-Hop options).

NEW:
  "Transmission and Processing of IPv6 Extension Headers" [RFC7045]
  clarified how intermediate nodes should process Extension Headers.
  The present document is generally consistent with [RFC7045], and
  addresses an issue that was raised for discussion
  when [RFC2460] was updated and replaced by
  [RFC8200].  This document updates [RFC8200] as described in the next
  section and consequently clarifies the description in Section 2.2 of
  [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174].

  This document defines a set of procedures for the Hop-by-Hop Options
  header that are intended to make the processing of Hop-by-Hop options
  practical in modern transit routers.  The common cases are that some
  Hop-by-Hop options will be processed across the Internet, while
  others will only be processed within a limited domain [RFC8799]
  (e.g., where a specific service is made available in that network
  segment that relies on one or more Hop-by-Hop options).

Since you allude to "an issue that was raised for discussion", it also wouldn't go amiss to provide an informative citation to the relevant list thread.

### Section 5.1, use the RFC 8200 words

Suggested rewording, both for correctness and to use the language of RFC 8200:

OLD:
  [RFC8200] also requires that a Hop-by-Hop Options header only appear
  once in a packet.

NEW:
  [RFC8200] also requires that a Hop-by-Hop Options header appear at most
  once in a packet.
 
### Sections 5.1, 5.1.1, clarity

You juxtapose a quote from RFC 8200 that says (my paraphrase, with BCP 14 keyword added to be provocative) "routers SHOULD NOT process the HbH header unless explicitly configured to do so", next to a new requirement that "clarifies that a configuration could control whether processing skips any specific" HbH option. I'll paraphrase that one too, again inserting a BCP 14 keyword, as "routers MAY instead process the HbH header by default while allowing configuration to disable specific options."

I guess those two things are compatible, but I had to do too much work to extract that interpretation and I'm not even confident that's really what you're trying to say. Can you confirm that it is?

As a follow-up, if my paraphrase is right, how do you reconcile Section 5.1 where you say "Routers SHOULD process the Hop-by-Hop Options header" with (my paraphrase of) RFC 8200? You might reply that I've changed the meaning of Section 5.1 by omitting "using the method defined in this document", but if so I think you should rephrase the Section 5.1 language for clarity, as in,

OLD:
  Routers SHOULD process the Hop-by-Hop Options header using the
  method defined in this document

NEW:
  Routers that process the Hop-by-Hop Options header SHOULD do so
  using the method defined in this document.
 
On the other hand, if you intend that "Routers SHOULD process the Hop-by-Hop Options header", I think you have more work to do in Section 5.1.1, as discussed above.

### Section 5.2, first HbH option

The first couple of paragraphs appear to privilege the first HbH option compared to the rest. Is this deliberate? Can you help me understand why, if so?

For example,

  A router configuration needs to avoid vulnerabilities that arise when
  it cannot process the first Hop-by-Hop option at full forwarding
  rate.  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.

When I unpack this, how is it different from (my text):

  A router configuration needs to avoid vulnerabilities that arise when
  processing of a Hop-by-Hop option would prevent it from forwarding at
  full forwarding rate.  A router SHOULD process Hop-by-Hop options, if
  configured to do so, providing that these do not adversely impact the
  aggregate forwarding rate.

The primary change in my rewrite was to cut

  A router SHOULD NOT therefore be configured to process the
  first Hop-by-Hop option if this adversely impacts the aggregate
  forwarding rate. 
 
As far as I can tell the rewrite is semantically the same, but I'm concerned that I have missed something, otherwise, why would you have put in that special mention of the first option? :-(

One interpretation I came up with after reading it a few times is that what you mean is something like "when it cannot process even a single Hop-by-Hop option at full forwarding rate". Does that get at your intent? I appreciate that practically speaking, most forwarding code will go through the options serially starting with the first, but not only is that not a requirement, but in some of your other text you drive home the message that the order of processing is not guaranteed. So, I think you should be careful to separate that assumption from what you're trying to specify.

This is only one example. Another is the first paragraph,

  A source creating packets with a Hop-by-Hop Options header SHOULD use
  a method that is robust to network nodes processing only the first
  Hop-by-Hop option that is included in the packet, or that forward
  packets without the option being processed (see Section 6.1).
 
I would've expected something more like,

  A source creating packets with a Hop-by-Hop Options header SHOULD use
  a method that is robust to network nodes selectively processing only
  some of the
  Hop-by-Hop options that are included in the packet, or that forward
  packets without the option(s) being processed (see Section 6.1).

As it is, a close reading of the sentence tells me it's fine if the method is *not* robust to network nodes that process only the second option, for example.

This isn't a full scrub of the section, e.g. the fourth paragraph has "further" (after what? The first? The last one successfully processed?)

### Section 5.2, including more than one HbH option

I found "A source MAY, based on local configuration, include more than one Hop-by-Hop option" peculiar, given that there's never been a restriction on that in the past (has there?), i.e. you're granting permission for something that was always allowed, so... thanks? I think I see what you're doing, which is to subtly throw shade on the idea of including more than one HbH option, but if you want to do that, why do it subtly? E.g., you could go whole hog with something like

  A source SHOULD NOT include more than one Hop-by-Hop option, although
  it MAY do so based on local configuration. In the latter case it might
  wish to restrict the size...

### Section 5.2, clarity

OLD:
  If a router is unable to process any Hop-by-Hop option (or is not

NEW:
  If a router is unable to process a given Hop-by-Hop option (or is not

### Section 5.2, sense of "any" is underdetermined

  This document modifies this behaviour for the "01", "10", and "11"
  action bits, so that 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".  It also modifies the behaviour for the "10" and "11"

Is "any Hop-by-Hop option" supposed to mean "any given HbH option" or is it supposed to mean "no HbH option"? I think it's the former, in which case, I suggest the change.

### Section 5.2, clarity, standalone patch

  This document modifies this behaviour for the "01", "10", and "11"
  action bits, so that 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". 
... 
  The modified text for "01", "10", and "11" values is:

      01 - MAY discard the packet. Nodes should not rely on routers
            dropping these unrecognized Option Types.

      10 - MAY discard the packet
...
      11 - MAY discard the packet
...

And as a reminder (to me, at least!), 00 is:

      00 - skip over this option and continue processing the header.
     
I had to go over this several times before I finally worked out that the modified text for the three values quoted above is not actually in conflict with the SHOULD in the first quoted paragraph. While puzzling over it, I also noticed that even though all three values are modified to permit discard, only the first includes the sentence "Nodes should not rely on routers dropping these unrecognized Option Types".

It seems to me that even though it would make the document more verbose, and isn't strictly mandatory for technical correctness upon careful reading, it would be helpful for clarity to spell things out more explicitly, as in,

NEW:
  The modified text for "01", "10", and "11" values is:

      01 - SHOULD behave as specified for 00, but MAY discard the packet
            if so configured.

      10 - SHOULD behave as specified for 00, but MAY discard the packet
            if so configured and, regardless of whether or not the
            packet's Destination Address was a multicast address, and if
            the packet was discarded, MAY send an ICMP Parameter
            Problem, Code 2, message to the packet's Source Address,
            pointing to the unrecognized Option Type.

      11 - SHOULD behave as specified for 00, but MAY discard the packet
            if so configured and, only if the packet's Destination
            Address was not a multicast address, and the packet was
            discarded, MAY send an ICMP Parameter Problem, Code 2,
            message to the packet's Source Address, pointing to the
            unrecognized Option Type.

  Nodes should not rely on routers dropping unrecognized Option Types.
 
I added a SHOULD clause for each. I also added "if so configured" to the MAY parts, it's unclear to me if that's overreach or helpful clarification of intent since I don't know if you intended the MAY to cover other cases too. Finally, I factored out the "should not rely on" sentence so that it doesn't appear to apply only to the 01 case.

Apart from simple readability, the other argument I'd give in favor of making this change (or one like it) is that in this kind of patch-type approach to updating a base document (which is what this is, despite the fact you haven't used OLD/NEW blocks), it's desirable for the patched base document to at least potentially stand alone.

### Section 5.2, "a multicast address", plus RFC 2119 keyword

I have two concerns about

  When a node sends an ICMP message in response to a packet with a
  multicast address, this could be exploited as an amplification
  attack.  This is particularly problematic when the Source Address is
  not valid (which can be mitigated to varying degrees by using a
  reverse path forwarding (RPF) check).  A node SHOULD only send ICMP
  messages in response to a packet with a multicast address when this
  is enabled for the specific Source Address and/or the group
  Destination Address.

The first concern is that when you write "a packet with a multicast address", it's not clear, until one reads the final sentence, that you mean either the source address or the destination address. I suggest spelling it out explicitly. The second concern is that although your intent with "SHOULD only" is clear enough, it doesn't fit the RFC 2119 definition of SHOULD. A possible rewrite to cover both concerns is,

NEW:
  When a node sends an ICMP message in response to a packet with a
  multicast source or destination address, this could be exploited as
  an amplification
  attack.  This is particularly problematic when the Source Address is
  not valid (which can be mitigated to varying degrees by using a
  reverse path forwarding (RPF) check).  A node SHOULD NOT send ICMP
  messages in response to a packet with a multicast source or
  destination address unless this
  is enabled for the specific Source Address and/or the group
  Destination Address.
 
(You could use "and/or" wherever I have put "or", but in my view it's not necessary, after all, it's not "xor".)

### Section 5.2, expository paragraph needed?

Is this paragraph doing any necessary work?

  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.  Generating an ICMP message
  incurs additional router processing.  Reception of this message is
  not guaranteed, routers might be unable to be configured so that they
  do not generate these messages, and they are not always forwarded to
  the source.  The motivation here is to loosen the requirement to send
  an ICMPv6 Parameter Problem message when a router forwards a packet
  without processing the list of all options.

I can see how it might've been needed during working group development of the document, but if I imagine I'm an implementor reading this spec, I'm not sure what I do with it. As far as I can tell the whole thing can be condensed down to "you might not get an IMCP parameter problem if one of your options isn't recognized, but then again that was always true"... and because of "that was always true", you could leave it out without harm.

### Section 5.2.1

      The function of a Router Alert Option can result in the processing
      that this specification is proposing to eliminate, that is, to
      instruct a router to process the packet in the control plane.
     
I don't think this specification is solely proposing to protect the control plane, it's also trying to protect the forwarding plane from option lists that are too heavyweight to be processed at line rate in the fast path. (Bullets 3 and 4 in the second bullet list in Section 4.)

Fortunately, a rewrite to correct this is as simple as removing one definite article.

NEW:
      The function of a Router Alert Option can result in processing
      that this specification is proposing to eliminate, that is, to
      instruct a router to process the packet in the control plane.

### Section 5.2.2, inappropriate RFC 2119 keyword

The final paragraph of this section is the single sentence,

  The actions of the lookup table SHOULD be configurable by the
  operator of the router.

But the previous paragraph told me that said lookup table is "a possible approach". It seems weird to me to use an RFC 2119 keyword to mandate behavior specific to "a possible approach". If I were you, I'd use lowercase "should", and I would combine this paragraph with the preceding one.

### Section 6, "simple to process" isn't actionable

  *  New Hop-by-Hop options SHOULD be designed to ensure the router can
      process the options at the full forwarding rate.  That is, they
      should be simple to process (see Section 5.2).

I don't see anything in Section 5.2 that tells me how to make an option simple to process. If you think it does explain that, please help me understand how. Otherwise, I think you should remove the cross-reference.

For that matter, even with the suggested change, this bullet point makes me a little bit sad because it feels isomorphic to the famous "don't write bugs" advice. (See also RFC 9225.) But, ¯\_(ツ)_/¯

### Section 8, forcing packets to the slow path can also harm the control plane

  Security issues with including IPv6 Hop-by-Hop options are well known
  and have been documented in several places, including [RFC6398],
  [RFC6192], [RFC7045] and [RFC9098].  The main issue, as noted in
  Section 4, is that any mechanism that can be used to force packets
  into the router's control plane can be exploited as a Denial-of-
  Service attack on a transit router by saturating the resources needed
  for router management (routing protocols, network management
  protocols, etc.) and cause the router to fail or perform sub-
  optimally.

There is a related but not identical issue, which is that in many routers, some resources are shared between the control plane and the slow path -- you nod to this in your definition of "slow path" in Section 3. Even if packets are forced only into the slow path, but not the control plane, that can still work as a denial of service attack against the control plane. I suppose we might get into an ontological debate about what exactly "the control plane" is in this context and whether the paragraph as written already encompasses it, but I think it would be better to err on the side of completeness even if it requires a bit more verbosity. The fix I propose is simple enough, though: s/control plane/slow path or control plane/.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-6man-hbh-processing-15, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-04-29):

From: The IESG
To: IETF-Announce
CC: 6man-chairs@ietf.org, draft-ietf-6man-hbh-processing@ietf.org, ek.ietf@gmail.com, furry13@gmail.com, ipv6@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IPv6 Hop-by-Hop Options Processing Procedures) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'IPv6 Hop-by-Hop Options Processing
Procedures'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-04-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies procedures for how IPv6 Hop-by-Hop options
  are processed in IPv6 routers and hosts.  It modifies the procedures
  specified in the IPv6 Protocol Specification (RFC8200) to make
  processing of the IPv6 Hop-by-Hop Options header practical with the
  goal of making IPv6 Hop-by-Hop options useful to deploy and use in
  the Internet.  When published, this document updates RFC8200.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5554/

# Internet AD comments for draft-ietf-6man-hbh-processing-14
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

### S5.1

* I'm having a hard time understanding how:

  - this section has normative language about process EHs,
  - this section says draft-eh-limits contains further requirements
  - draft-eh-limits is presently NOT a normative dependency

  I know we might not want to tie this document to draft-eh-limits, but in
  order to make that argument I kinda feel like it'll be necessary to
  clarify the difference.

  Given a quick scan of draft-eh-limits, which is listed as a BCP, I think
  it suffices to change "further requirements" to something like
  "additional recommendations"? I think that might underscore that
  draft-eh-limits is all SHOULD (and we probably need to clarify that the
  MUSTs in draft-eh-limits apply to nodes complying with the BCP).

  Thoughts?

### S6

* I don't know what it would mean to a specification author that a "[n]ew
  Hop-by-Hop [option] SHOULD be designed expecting that a router may drop
  packets containing the new Hop-by-Hop option".

  I think it's the intend *use* of the option that should be designed to
  understand it may be dropped, rather than the option itself?

## Comments

### S5.2

* "which can be mitigated when using a reverse path forwarding (RPF) check"

  My gut reaction is that this might be more specifically written as "which
  can be mitigated to varying degrees by using a reverse path forwarding
  (RPF) check."

  This is because it depends upon where along the path the first the uRPF
  check is done.  A spoofing source might be able to DoS a ~neighbor within
  the "zone of uRPF" (blast radius) from the triggered router's perspective.

## Nits

### S4

* "many types network path" -> "many types of network paths"

* "into the the processor" -> "into the processor"

* "could cause adversely impact router operation"
  "could adversely impact router operation" or
  "could cause adverse impact router operation"

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The draft has been discussed extensively and received thoughtful reviews from many working
group participants (Acknowledgments section includes a long list of names).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing out of ordinary.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No threats of appeals or extreme discontent have been expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are no yet confirmed implementations of the proposed changes to RFC8200 described in this document.
However as the document defines guidelines for implementors, not a new protocol, it might be too early to expect implementations.
The document also provides recommendations on defining new Hop-by-hop options and
Section 6.1 reports that at least one recently defined option
(RFC9268) complies with those recommendations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document defines rules for processing IPv6 Hop-by-Hop options, and doesn't really have any
content in scope of other IETF WGs or external organisations.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document does not require any formal expert reviews.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

This document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document doesn't contain any such sections.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd believes that the document is very much needed. The extension headers,
especially Hop-by-Hop one and its processing by routers is a topic being constantly discussed at IETF.
This document brings the idustry one step closer towards making Extension Headers useful and deployable.
The document's goal is to specify realistic and deployable processing rules for Hop-by-Hop Options header.
In the shepherd's opinion, the document is clearly written, complete and correctly designed.
After two WGLCs and extensive reviews, the document is ready for the responsible Area Director's review.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The shepherd reviewed the lists provided in [6] and didn't identified any issues with this document.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status of the document is Standards Track. This is a proper status as it updates RFC8200 which is Internet Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors are not aware of any IPR claims except for one already filled for the draft (https://datatracker.ietf.org/ipr/5554/).

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The draft has two authors and, as of Feb 2024, both of them are still willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are informational references to obsolete documents (RFC1883 and RFC2460) but this is intentional,
as those references are used to explain the history of IPv6 extension headers processing rules.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The document contains 4 normative references and all of them shall be read to understand or implement
the proposed changes (one might argue that the reference to the IANA registry for all existing Hop-by-Hop options might be considered an Informative,
but the content of that registry is required to implement, for example, Section 5.2.2 of the document.

In the shepherd's opinion, no informative references need to be normative instead.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No such references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updated RFC8200. That fact is correctly reflected in the document metadata.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document doesn't define any actions for IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No future allocations are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The draft has been discussed extensively and received thoughtful reviews from many working
group participants (Acknowledgments section includes a long list of names).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing out of ordinary.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No threats of appeals or extreme discontent have been expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are no yet confirmed implementations of the proposed changes to RFC8200 described in this document.
However as the document defines guidelines for implementors, not a new protocol, it might be too early to expect implementations.
The document also provides recommendations on defining new Hop-by-hop options and
Section 6.1 reports that at least one recently defined option
(RFC9268) complies with those recommendations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document defines rules for processing IPv6 Hop-by-Hop options, and doesn't really have any
content in scope of other IETF WGs or external organisations.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document does not require any formal expert reviews.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

This document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document doesn't contain any such sections.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd believes that the document is very much needed. The extension headers,
especially Hop-by-Hop one and its processing by routers is a topic being constantly discussed at IETF.
This document brings the idustry one step closer towards making Extension Headers useful and deployable.
The document's goal is to specify realistic and deployable processing rules for Hop-by-Hop Options header.
In the shepherd's opinion, the document is clearly written, complete and correctly designed.
After two WGLCs and extensive reviews, the document is ready for the responsible Area Director's review.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The shepherd reviewed the lists provided in [6] and didn't identified any issues with this document.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status of the document is Standards Track. This is a proper status as it updates RFC8200 which is Internet Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The authors are not aware of any IPR claims except for one already filled for the draft (https://datatracker.ietf.org/ipr/5554/).

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The draft has two authors and, as of Feb 2024, both of them are still willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are informational references to obsolete documents (RFC1883 and RFC2460) but this is intentional,
as those references are used to explain the history of IPv6 extension headers processing rules.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The document contains 4 normative references and all of them shall be read to understand or implement
the proposed changes (one might argue that the reference to the IANA registry for all existing Hop-by-Hop options might be considered an Informative,
but the content of that registry is required to implement, for example, Section 5.2.2 of the document.

In the shepherd's opinion, no informative references need to be normative instead.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No such references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updated RFC8200. That fact is correctly reflected in the document metadata.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document doesn't define any actions for IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No future allocations are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The draft has been discussed extensively and received thoughtful reviews from many working
group participants (Acknowledgments section includes a long list of names).

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing out of ordinary.


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No threats of appeals or extreme discontent have been expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are no yet confirmed implementations of the proposed changes to RFC8200 described in this document.
However as the document defines guidelines for implementors, not a new protocol, it might be too early to expect implementations.
The document also provides recommendations on defining new Hop-by-hop options and
Section 6.1 reports that at least one recently defined option
(RFC9268) complies with those recommendations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document defines rules for processing IPv6 Hop-by-Hop options, and doesn't really have any
content in scope of other IETF WGs or external organisations.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document does not require any formal expert reviews.


7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

This document does not contain a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document doesn't contain any such sections.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd believes that the document is very much needed. The extension headers,
especially Hop-by-Hop one and its processing by routers is a topic being constantly discussed at IETF.
This document brings the idustry one step closer towards making Extension Headers useful and deployable.
The document's goal is to specify realistic and deployable processing rules for Hop-by-Hop Options header.
In the shepherd's opinion, the document is clearly written, complete and correctly designed.
After two WGLCs and extensive reviews, the document is ready for the responsible Area Director's review.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The shepherd reviewed the lists provided in [6] and didn't identified any issues with this document.


11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status of the document is Standards Track. This is a proper status as it updates RFC8200 which is Internet Standard.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

TBD

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

TBD

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are informational references to obsolete documents (RFC1883 and RFC2460) but this is intentional,
as those references are used to explain the history of IPv6 extension headers processing rules.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The document contains 4 normative references and all of them shall be read to understand or implement
the proposed changes (one might argue that the reference to the IANA registry for all existing Hop-by-Hop options might be considered an Informative,
but the content of that registry is required to implement, for example, Section 5.2.2 of the document.

In the shepherd's opinion, no informative references need to be normative instead.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available to anyone.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No such references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updated RFC8200. That fact is correctly reflected in the document metadata.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document doesn't define any actions for IANA.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No future allocations are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/