IPv6 Minimum Path MTU Hop-by-Hop Option
draft-ietf-6man-mtu-option-15

Thank you for the work on this document.

Many thanks to Bernard Aboba for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/Xo9yYxkzEBBDQnEhFvhnnHm-e5M/ , and thanks to the authors for replying to him.

I wonder if it wouldn't be useful to have the diagrams the authors have sketched up (in https://mailarchive.ietf.org/arch/msg/art/HKwq8_wLbwXU6iS9ahLBoVcI6Mc/) in an appendix of the document - that might require some additional descriptive text around them, but I think they would be helpful.

Francesca

In Sections 1 and 2, you refer to "this draft", e.g.:

  The purpose of this draft is to improve the situation ...

When published, this won't be a draft.  I suggest changing both to "document".

[Result of my DISCUSS:] Some of the SHOULDs in Section 6 make me uneasy as used here, but it seems like they were done this way in RFC 8200 as well, so this is possibly the wrong place to get that fixed.  I'll let the sponsoring AD make the final call on this.

While experimentation is good, I also share the concerns voiced by Bernard Aboba (https://datatracker.ietf.org/doc/review-ietf-6man-mtu-option-13-artart-lc-aboba-2022-03-09/) that this experiment repeats the failure of RFC 1063

   If the MTU of the link is less than the Min-PMTU,
   it rewrites the value in the option data with the smaller value.

Wouldn't this mean that what is stored is the maximum path mtu, not the minimum one?

It would be good to mention IPsec (both ESP transport mode whether the option is not (?) expected to work, and for ESP tunnel mode, where the option in the encapsulated packet could set to take into account the IPsec overhead for both ESP and possible ESPinUDP. Or the outer ESP packet could set the option after some header calculations.

    The use of this option with DNS and DNSSEC over UDP

DNS already has its application layer options to deal with MTU via an EDNS option. Although it could possibly read value from the network packet and use that in its ENDS option answer, it is not sure if this is worth the risk of abuse, where amplification attacks are common. If this experiment is not widely deployed, it could mean that excessive large values would actually make it to the DNS server, so using those values could be damaging especially if the packet was spoofed and the large packets are returned to the real victim.

I am not sure how TLS or IPsec could protect this option, as it is required to be modified on-path ?

  When a forged packet causes a packet to be sent including the minimum
   Path MTU option, and the return path does not forward packets with
   this option, the packet will be dropped Section 6.3.6.  This attack
   is mitigated [...]

Isn't dropping the spoofed packet mitigation enough?

Thank you to Charlie Kaufman for the SECDIR

** Recommend consistent language on validating again off-path injection.

Both sections first make this statement:
   An upper layer protocol that validates each received
   packet discards any packet when this validation fails.  

(a) Section 6.3.2.  
   When packet validation fails, the upper layer MUST
   also discard the associated Option Data from the minimum Path MTU
   option without further processing.

(b) Section 8.3
   In this case,
   the host MUST also discard the associated Option Data from the
   minimum Path MTU option without further processing (Section 6.3).

Why does (b) use “host” and not “upper layer”?

** Section 1.1.  Figure 1 is a helpful summary.  Consider including another scenario or additional text which involves a middlebox dropping the packet or stripping the option per the behavior in Section 6.3.6 and 8.6

** Section 6.3.6
   There is evidence that some middleboxes drop packets that include
   Hop-by-Hop options.  For example, a firewall might drop a packet that
   carries an unknown extension header or option.  This practice is
   expected to decrease as an option becomes more widely used.   

Is there a reference that can be used to support this optimism of middle-box operators changing their current practice? I was under the impression that this remains a prevalent practice and the motivation for draft-ietf-opsec-ipv6-eh-filtering.

** Section 9.  Thank you for being explicit on the experiment goals on this experimental document!  Would another component contributing to a successful experiment be operators not filtering this traffic?

Thanks for working on this  specification and I hope efforts for Path MTU discovery will be successful and useful. Thanks to  Olivier Bonaventure for  the  TSVART review.

I have the following  observations/questions  :

* Section 2:  s/1998/1988 for RFC 1063.

* Section 6.1 and 6.2: I was expecting more clear description of consequences/analysis when the SHOULD's are followed. The security consideration was felt a little bit short of describing potential risk analysis in that regard. 

* Section 6.3:  is this ref to section 4.1 of RFC9000 the right reference here? 

* Section 9: I am not sure I get a clear view of the goals of the experiment. is  this to check the dependability questions? or the proof of support those are listed in this section? can we be more precise on what we expect the  implementation experience report(s)?.

Thank you for the work put into this document. I am all in favour of extending IPv6 with extension headers, and any system to improve path MTU detection is helpful (esp. in data center at the beginning).

Let me also apologise to Bob, Gorry, and the 6MAN WG as I could have sent those comments during the WGLC...

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Ole Trøan for the shepherd's write-up including the justification for the intended status as experimental. You may also expect a INT directorate review by David Lamparter later.

I hope that this helps to improve the document,

Regards,

-éric

What about multicast traffic ? Can this HbH option be used ? How can several answers be combined ? As the intended status is "experimental", this is not blocking but close to be a DISCUSS-level point though.

## Abstract

Just wondering whether "node" should be used instead of "host" in "along the forward path between a source host to a destination host" (also in other places in other sections). Of course, nothing prevent a router to act as a host. §9 uses "node" and not "host" ;-)

## Section 1.2

Suggest removing the note about RFC 2460 as 8200 has been published for years now.

Even if mostly obvious, please expand "HBH" at first use.

## Section 6.1

For a router not configured for HbH-processing: why only "SHOULD ignore" ? Either exception use case(s) should be provided or a "MUST NOT" and "MUST" (for forward) be used.

Why does a router "SHOULD" only update and not "MUST" ? This is an experimental document and not a proposed standard one so little reason to be ultra-cautious. If "SHOULD" is kept, then when can/should a router deviate from the update action ?

Is the "Discussion" part still relevant at this stage (IESG evaluation) ? Or should it be moved to the "experiment success evaluation" part ?

Can the router apply sampling/rate limiting on those packets ?

## Section 6.2

"This cached value can be used by other flows that share the host's destination cache." is hard to parse and possibly incorrect (as missing the egress interface), suggest to use "other flows to the same destination and same egress interface" ?

If it was not an experimental document, I would probably have raised a blocking DISCUSS (sorry Bob & Gorry), usually ECMP is done on the 5-tuple, so using different layer-4 ports could end up in slightly different paths with different MTU (section 5.2 of RFC 8201 is a little better, recommend referring to it ? -- it is only referred to in § 6.3.4).

Please expand "PL"

"When requested to send an IPv6 packet" how ? and who request such an action ? My major concern is whether it is a per packet or per "connection" request as using a 8-byte MTU in a data packet actually reduces the useful MTU by 8 bytes. A forward reference to §6.3.1 would be beneficial.

Bullet #3, it is unclear what "This" means.

## Section 6.3

"Using a PMTU Probe" is it the HbH option described in this document ? If so, then propose being clear or introduce the synonym earlier in the text.

## Section 6.3.2 

Just wondering how different this method is wrt to ICMP-based PMTUD as the 5-tuple must also be present (albeit no data).

Also wondering how an upper-layer protocol (possibly QUIC in user space) could signal to the PMTU cache (possibly in the kernel) to ignore a value. But, hey this is all about experimenting ;-) And § 6.3.3 is going in more details about where this data could be stored.

## Section 6.3.4

Why not a "MUST" in "A source host SHOULD ignore a Rtn-PMTU value larger than the MTU configured for the outgoing link." ?

# NITS  

## Section 1.1

In scenario 2, s/considers the link to the destination host/considers the link between R2 and the destination host/ ?

## Section 2

s/977K packets per second (pps)/977,000 packets per second (or 997 kpps)/

## Section 6.3.4

s/layer 2 device/layer-2 device/

## Section 8.1

s/Hop by Hop/Hop-by-Hop/

[Eric and Zahed brought up comments related to the text in §6.1 -- my concerns are slightly different.]

===
   6.1. Router Behavior

   Routers that are not configured to support Hop-by-Hop Options SHOULD
   ignore this option and SHOULD forward the packet [RFC8200].

   Routers that support Hop-by-Hop Options, but that are not configured
   to support this option SHOULD ignore the option and SHOULD forward
   the packet.
===

Both paragraphs seem to want to define the behavior of routers that don't support this specification or HbH in general. I interpret "not configured to support" to mean that the router doesn't support (vs. one that has been upgraded to support the new option but was manually configured not to). Note that the next paragraph covers the case of "[r]outers that support this option".  

If they don't support the option, then this document can't expect, much less specify, any behavior.

Also, and more importantly, the specification above conflicts with rfc8200.


The first paragraph refers to routers that "are not configured to support Hop-by-Hop Options". The reference to rfc8200 confuses me because rfc8200 (1) doesn't use rfc2119 language, and (2) already describes the expectation.  

From §4/rfc8200: "it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so."  I interpret this expectation as a requirement (MUST), not a recommendation (SHOULD). There is a conflict between what is specified here and rfc8200.

I believe it is unnecessary to try to restate what rfc8200 already says. However, please say so clearly if you still want to point at what rfc8200 says about routers not configured to support Hop-by-Hop Options.

Suggestion>
   Routers that are not configured to support Hop-by-Hop Options are
   expected not to examine or process the contents [RFC8200].



The second paragraph refers to routers that "are not configured to support this option". The option type starts with 00, which §4.2/rfc8200 and §5 in this document define as "skip over this option and continue processing the header" (if the type is not recognized). In this case, the behavior is required, but this section only recommends (SHOULD) it. There is a conflict between what is specified here and what is written in rfc8200 and §5.

I believe it is unnecessary to try to restate what rfc8200 and §5 already say. However, if you still want to talk about routers that won't recognize the new option in this section, please say so without Normative language.

Suggestion>
   Routers that support Hop-by-Hop Options but that don't recognize 
   this new option will skip over it and continue processing the header.

Section 5. , paragraph 9, comment:
>      Min-PMTU: n 16-bits.  The minimum MTU recorded along the path
>                  in octets, reflecting the smallest link MTU that
>                  the packet experienced along the path.
>                  A value less than the IPv6 minimum link
>                  MTU [RFC8200] MUST be ignored.

Would there be any value in using a scheme that can encode MTUs larger than
64K? Could steal some bits by not defining a way to encode values below 1280.

Thanks to Paul Kyzivat for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/cSJ1VnpREVnAknRj_ANN0QFRdA0).

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2. , paragraph 3, nit:
-    This results in many transport connections being configured to use
+    This results in many transport-layer connections being configured to use
+                                  ++++++

Section 2. , paragraph 4, nit:
-    size available for a transport to use.  Also, some use-cases increase
+    size available for a transport protocol to use.  Also, some use-cases increase
+                                  +++++++++

Section 6.3. , paragraph 3, nit:
-    This avoids the transport needing to retransmit a lost packet that
+    This avoids the transport protocol needing to retransmit a lost packet that
+                             +++++++++

Section 6.3.1. , paragraph 10, nit:
-    *  A datagram transport can utilise DPLPMTUD [RFC8899].  For example,
-                                     ^
+    *  A datagram transport can utilize DPLPMTUD [RFC8899].  For example,
+                                     ^

Section 6.3.4. , paragraph 4, nit:
-    *  The actual PMTU may be lower than the Rtn-PMTU value because the
-                                                                   ----

Reference [RFC2460] to RFC2460, which was obsoleted by RFC8200 (this may be on
purpose).

Reference [RFC1063] to RFC1063, which was obsoleted by RFC1191 (this may be on
purpose).

Section 4. , paragraph 3, nit:
> IANA-HBH]. Length: 4 The size of the each value field in Option Data field su
>                                  ^^^^^^^^
Two determiners in a row. Choose either "the" or "each".

Section 6.2. , paragraph 2, nit:
> acket with this option in response to a R-flag, as well as which packets to i
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 8.4. , paragraph 4, nit:
>  mitigate the impact by responding to a R-Flag by including the option in a p
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

This is good work on a thorny problem, and I hope the experiment is successful.

Throughout this document, there are SHOULD requirements that ought to have some language about the correct conditions under which to ignore the SHOULD.

(6.3) this is threatened not only by "loss of the packet", but also loss of the packet sent in response.

(8.3) packet validation in itself still leaves the mechanism vulnerable to replay attacks; the packet also must be non-duplicate.

I'm supportive of trying to solve the MTU problem and there seems to be no harm in trying this experiment, although I'm somewhat doubtful as to how many vendors will implement this functionality and how many operators will configure/enable it ... perhaps the IETF should try and write a BCP that recommends that interfaces carrying internet traffic support an IPv6 MTU of 9000 (if that is indeed the right thing to do).

Regards,
Rob