Subject: I-D Action: draft-ietf-6man-mtu-option-08.txt

From: [email-masked]
Date: Tue, 07 Sep 2021 14:21:32 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

        Title           : IPv6 Minimum Path MTU Hop-by-Hop Option
        Authors         : Robert M. Hinden
                          Godred Fairhurst
	Filename        : draft-ietf-6man-mtu-option-08.txt
	Pages           : 22
	Date            : 2021-09-07

Abstract:
   This document specifies a new Hop-by-Hop IPv6 option that is used to
   record the minimum Path MTU along the forward path between a source
   host to a destination host.  The value can then be communicated back
   to the source using the return Path MTU field in the option.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-6man-mtu-option-08.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-mtu-option-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Dougherty <[email-masked]>
Date: Thu, 9 Sep 2021 01:26:05 +0000

Good evening Mr. Hinden and Mr. Fairhurst,

I enjoyed the proposed Path MTU option draft and would like to offer the following comments and recommendations for readability. I will say that this proposal has possible interaction with another draft that I reviewed by your contributor Fernando Gont regarding carrier and providers filtering out IPv6 options. 

Section 4 – Applicability Statement:
For example in Data Centers and on paths between Data Centers, to allow a hosts to better take advantage of a path that is able to support a large PMTU.

Comment: The above statement has a slight grammatical error, “… to allow a hosts to better take advantage….” The use of “a” implies a singular tense, but the term “hosts” is pluralized. 

Suggestion: It would be correct with the use of “… to allow hosts to take better advantage…”

The design of the option is sufficiently simple that it can be executed on a router's fast path. 

Suggestion: Remove the apostrophe from the router above.

A strong pull from router vendors customers will be required to create critical mass for this to happen.

Did you mean, poll from router vendors?

The method could also be useful in other environments, including the general Internet, and offers advantage when this Hop-by-Hop Option is supported on these paths. 

Comment: Maybe rewrite the end of the sentence to “…Hop-by-Hop Option is supported on all paths.”

Section 6.2.1
The described process of source to destination PMTU discovery along with the reverse path process appears to be logical and straight forward. However, is there any mitigation to abuse or misuse of setting the R-Flag in appropriately or maliciously? Similar to TCP flag being set inappropriately in a SYN-Flood attacks, for example.

Section 6.2.2.1 – Discussion --- Point-5
The use of this option with DNS and DNSSEC over UDP ought to work for paths where the PMTU is symmetric.

Comment: The term “ought” is slang, maybe consider replacing it with “should work…” or “is expected to work…” 

Section 6.2.2.4
The actual PMTU may be larger than the Rtn-PMTU value because of a corrupted, delayed or mis-ordered response.  A source host SHOULD ignore a Rtn-PMTU value larger than the MTU configured for the outgoing link.

Comment: How does the recipient of the Rtn-PMTU determine if a that message has been delayed or mis-ordered?

//Thank you for your time,

Michael Dougherty
[email-masked]

###############

On 9/7/21, 5:21 PM, "[email-masked]" <[email-masked]> wrote:

    Abstract:

---

From: Bob Hinden <[email-masked]>
Date: Fri, 10 Sep 2021 08:01:59 -0700

Michael,

Thanks for your comments and questions.  Responses inline.

Bob & Gorry

> On Sep 8, 2021, at 6:26 PM, Michael Dougherty <[email-masked]> wrote:
> 

> Suggestion: It would be correct with the use of “… to allow hosts to take better advantage…”

Thanks, will fix.

> Suggestion: Remove the apostrophe from the router above.

Thanks, will fix.

> Did you mean, poll from router vendors?

No we meant from the customers of router vendors.   How about if we change it to:

Customers of router vendors will need to create a demand for support of this hop-by-hop option.

> Comment: Maybe rewrite the end of the sentence to “…Hop-by-Hop Option is supported on all paths.”

Thanks, will fix.

> The described process of source to destination PMTU discovery along with the reverse path process appears to be logical and straight forward. However, is there any mitigation to abuse or misuse of…

This is not different from other header fields.  Setting the flag inappropriately would cause more options to be sent.  This is not like the kind of resource exhaustion that can occur in a SYN-Flood attack.

The receiving node has control when to send a packet with this option in response to a R-flag, as well as which packets to include it.   If this becomes a problem is could also reduce the rate that it sends these packets.  We will add something like this to the draft:

The receiving node has control when to send a packet with this option in response to a R-flag, as well as which packets to include it.  The receiver MAY control the rate that at which it sends these packets.

> Comment: The term “ought” is slang, maybe consider replacing it with “should work…” or “is expected to work…”

Thanks, will change to “is expected to work”.

> Comment: How does the recipient of the Rtn-PMTU determine if a that message has been delayed or mis-ordered?

This wasn’t saying there was a problem with out of order responses, just pointing out that it might result in a larger Rtn-PMTU value.  That said, when using a transport like TCP, out of order packets can be usually detected.  We don’t think this is likely to be an issue in practice.