Skip to main content

Path MTU Discovery for IP version 6
draft-ietf-6man-rfc1981bis-08

Revision differences

Document history

Date Rev. By Action
2017-07-14
08 (System)
Received changes through RFC Editor sync (created alias RFC 8201, changed abstract to 'This document describes Path MTU Discovery (PMTUD) for IP version 6.  …
Received changes through RFC Editor sync (created alias RFC 8201, changed abstract to 'This document describes Path MTU Discovery (PMTUD) for IP version 6.  It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4.  It obsoletes RFC 1981.', changed pages to 19, changed standardization level to Internet Standard, changed state to RFC, added RFC published event at 2017-07-14, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-6man-rfc1981bis and RFC 1981, created alias STD 87)
2017-07-14
08 (System) RFC published
2017-07-11
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-06-29
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-06-26
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2017-06-02
08 (System) RFC Editor state changed to EDIT
2017-06-02
08 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-06-02
08 (System) Announcement was received by RFC Editor
2017-06-02
08 (System) IANA Action state changed to No IC from In Progress
2017-06-02
08 (System) IANA Action state changed to In Progress
2017-06-02
08 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-06-02
08 Amy Vezza IESG has approved the document
2017-06-02
08 Amy Vezza Closed "Approve" ballot
2017-06-02
08 Amy Vezza Ballot approval text was generated
2017-06-02
08 Suresh Krishnan IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2017-06-01
08 Suresh Krishnan RFC Editor Note was changed
2017-06-01
08 Suresh Krishnan RFC Editor Note was changed
2017-06-01
08 Suresh Krishnan RFC Editor Note was changed
2017-06-01
08 Suresh Krishnan RFC Editor Note for ballot was generated
2017-06-01
08 Suresh Krishnan RFC Editor Note for ballot was generated
2017-06-01
08 Suresh Krishnan RFC Editor Note for ballot was generated
2017-05-29
08 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my discuss. I believe there is an editing nit in section 5.4 now:
"Alternatively, the retransmission could be done in …
[Ballot comment]
Thanks for addressing my discuss. I believe there is an editing nit in section 5.4 now:
"Alternatively, the retransmission could be done in immediate response
  to a notification that the Path MTU was decreased, but only for the
  specific connection specified by the Packet Too Big message, but only
  based on the message and connection. "
Is it on purpose to have twice "but only" here?

I leave my previous comments  below for the record. I don't think all of them have been addressed but I aldo don't recognize any further discussion about those points:

1) I agree with Ekr on this sentence:
"Nodes SHOULD appropriately validate the payload of ICMPv6 PTB
  messages to ensure these are received in response to transmitted
  traffic (i.e., a reported error condition that corresponds to an IPv6
  packet actually sent by the application) per [ICMPv6]."
This sounds like it should be a MUST but I guess it depends on the upper layer protocol if such a validation is possible or not, e.g. if information are available that can be used for validation. Maybe you can be more explicit here and even say something like pmtu discovery should/must only be used if the upper layer protocol provides means for validation of the icmp payload (like a sequence number in TCP)…?

Further also note that if the upper layer does the validation while the IP layer maintains EMTU_S, there must be an interface from the upper layer to the IP layer to tell if a packet is valid or not before the IP layer updates the MTU estimate. This seems actually more complicated than this one sentences indicates.

2) Also as Ekr says, I also have problems to fully understand this normative text in section 4:
"After receiving a Packet Too Big message, a node MUST attempt to
  avoid eliciting more such messages in the near future.  The node MUST
  reduce the size of the packets it is sending along the path.  Using a
  PMTU estimate larger than the IPv6 minimum link MTU may continue to
  elicit Packet Too Big messages.  Since each of these messages (and
  the dropped packets they respond to) consume network resources, the
  node MUST force the Path MTU Discovery process to end.

  Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
  as possible."
I especially don't understand the first part, given that a PTB message may still indicate a MTU that is larger than the minimum link MTU which then may cause another PTB message later on the path. This text reads like if you receive one PTB message you should better end discovery and fall back to the minimum link MTU to avoid any further PTB message and not waist any resources. I don't think that's the intention and as such I don't understand when it is recommended to end discovery here...?

3) Section 5.2 seems to be written with only single homed hosts in mind. It might be good to advise that the pmtu information should always be stored on a per interface basis...?

4) Also section 5.2:
You only advise to store information per flow ID, however, if the flow label is not used, wouldn't it make really sense to just use the 5-tuple instead? Also note that EMCP is often done based on the 5-tuple or even 6-tuple (with the ToS field).

5) And more in section 5.2:
"When a Packet Too Big message is received, the node determines which
  path the message applies to based on the contents of the Packet Too
  Big message. "
MAYBE:
"When a valid Packet Too Big message is received, the node determines which
  path the message applies to based on the contents of the Packet Too
  Big message."
And further on:
"If the tentative PMTU is less than the existing PMTU estimate, the
  tentative PMTU replaces the existing PMTU as the PMTU value for the
  path."
This doesn't cover the case where a pmtu probe with a larger size was send and the PTB message returns a larger value then stored. Maybe state this explicitly.

This applies similar to this sentence in section 6:
OLD
"A node, however, should never raise its estimate of the
      PMTU based on a Packet Too Big message, so should not be
      vulnerable to this attack.“
NEW
"A node, however, MUST NOT raise its estimate of the
      PMTU based on a Packet Too Big message that is not a (validated) response to a PMTU probe that was previously send by this node, so should not be
      vulnerable to this attack."

6) Further section 5.2:
Should this statement be maybe upper case MUST:
"The packetization layers must be notified about decreases in the PMTU. "

7) Technical comment on section 5.3 in general:
There is a difference between aging if a flow is active or not. While I maybe don't want to probe again for this connection because my application already decided to use a mode where it can live with the current pmtu and it's too much effect to switch, I really want to probe at the beginning of the next connection again to check if I can use a different mode now. While the IP layer does not have a notion of connection it can observe if packets are frequently send with the same 5-tuple and reset the cached pmtu after a certain idle time.

8) Section 5.4: should this maybe be normative, at least the last MUST NOT (be fragmented):
"A packetization layer (e.g., TCP) must track the PMTU for the path(s)
  in use by a connection; it should not send segments that would result
  in packets larger than the PMTU, except to probe during PMTU
  discovery (this probe packet must not be fragmented to the PMTU). "


Nit:
The abbreviation PTB is only used once in section 4 (and never expanded).
2017-05-29
08 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2017-05-27
08 Bob Hinden New version available: draft-ietf-6man-rfc1981bis-08.txt
2017-05-27
08 (System) New version approved
2017-05-27
08 (System) Request for posting confirmation emailed to previous authors: Robert Hinden , 6man-chairs@ietf.org
2017-05-27
08 Bob Hinden Uploaded new revision
2017-05-20
07 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss
2017-05-19
07 Alvaro Retana [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss
2017-05-19
07 Warren Kumari
[Ballot comment]
I sent email about this to the authors on Feb 23rd - I seem to still have have many of the same questions... …
[Ballot comment]
I sent email about this to the authors on Feb 23rd - I seem to still have have many of the same questions...

Comments:
1: Sec 1: "Path MTU Discovery relies on such messages to determine the MTU of the path."
-- it is unclear which "such" refers to. Perhaps s/such/ICMPv6/ (or PTB).

2: Sec 3: "Upon receipt of such a message, the
  source node reduces its assumed PMTU for the path based on the MTU of
  the constricting hop as reported in the Packet Too Big message" -- this says that it reduces it *for the path*. But (as somewhat alluded to later in the draft) the nodes doesn't know what the path *is* -- it can decrease for the destination, or flow, or even interface, but (unless it is strict source routing) it doesn't control or really know the path (see also #4)

3: Sec 4: "The recommended setting for this timer is twice its minimum value (10 minutes)." - as above. This was from 1996 - were these metrics discussed at all during the -bis? I suspect that the average flow is much shorter these days (more web traffic, fatter pipes, etc) and so a flow of 10 minutes seems really long (to me at least).

4: Sec 5.2: "The packetization layers must be notified about decreases in the
  PMTU.  Any packetization layer instance (for example, a TCP
  connection) that is actively using the path must be notified if the
  PMTU estimate is decreased.
      Note: even if the Packet Too Big message contains an Original
      Packet Header that refers to a UDP packet, the TCP layer must be
      notified if any of its connections use the given path."
- this is related to #2 -- I don't know *which* path my packets take - once I launch them into the void, they may be routed purely based upon destination IP address, or they may be hashed based upon some set of header fields to a particular ECMP link or LSP. Once packets hit a load balancer, it is probably even *likely* that the UDP and TCP packets end up on different things. So, if I get a PTB from a router somewhere, I can probably guess that other packets to the same destination address will also follow that path, but I cannot know that for sure. I'm fine to decrease MTU towards that destination IP, but is that what this is suggesting? If so, please say that. If not, please let me know what I should do. The above is even more tricky / fun when I'm using flow id as the flow identifier -- if I get a PTB for flow 0x1234, what do I do?

5: Sec 5.3: "Once a minute, a timer-driven procedure runs through all cached PMTU values, and for each PMTU whose timestamp is not "reserved" and is older than the timeout interval ...". Please consider providing clarifications here. The wording implies that I should set a timer to fire on the minute, and trigger the behavior. If all of the (NTP synced!) machines in my datacenter do this, and all try send bigger packets (on 1/10th of long flows) their first hop router will get many, many over-sized packets and it will severely rate-limit the PTBs.


Nits (Some of these are purely academic.)
I understand that you are trying to limit the changes, so feel free to ignore these:

1: "A node sending packets much smaller than the Path
MTU allows is wasting network resources and probably getting
suboptimal throughput." - the "much" confuses me. If I'm using anything less than the MTU I'm wasting network resources and getting suboptimal throughput - I might not care, but if (used MTU) < (path MTU) I'm wasting resources.

2: "Nodes implementing Path MTU Discovery and sending packets larger than
the IPv6 minimum link MTU are susceptible to problematic connectivity
if ICMPv6 [ICMPv6] messages are blocked or not transmitted." The "implementing Path MTU Discovery and" seems redundant. ALL nodes sending packets larger than minimum MTU are "susceptible to problematic connectivity if ICMPv6 [ICMPv6] messages are blocked or not transmitted.". I get what you are trying to say, but my OCD tendencies would not allow me to ignore this...

3: "In the case of multipath routing (e.g., Equal Cost Multipath Routing, ECMP),"- this is vague / confusing -- (Equal Cost Multipath Routing, ECMP) makes it sound like either ECMP is an acronym for Equal Cost Multipath Routing, or that ECMP is something different to Equal Cost Multipath Routing.
I'd suggest just dropping the "ECMP" (or, "Equal Cost Multipath (ECMP) routing", but that seems clumsy)
2017-05-19
07 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss
2017-05-16
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-05-16
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-05-16
07 Bob Hinden New version available: draft-ietf-6man-rfc1981bis-07.txt
2017-05-16
07 (System) New version approved
2017-05-16
07 (System) Request for posting confirmation emailed to previous authors: Robert Hinden , 6man-chairs@ietf.org
2017-05-16
07 Bob Hinden Uploaded new revision
2017-05-11
06 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2017-05-11
06 Benoît Claise
[Ballot discuss]
  Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum
  link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum …
[Ballot discuss]
  Nodes not implementing Path MTU Discovery MUST use the IPv6 minimum
  link MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet
  size.

I searched for "IPv6 minimum link MTU" in draft-ietf-6man-rfc2460bis-09, and could not find that term.
Even unlikely at this point in the IPv6 implementation cycle, we don't want readers to believe that they should look at the minimum of the device IPv6 MTU link(s).
Proposal: define "IPv6 minimum link MTU" as 1280 octets in 2460bis, or in both documents.
2017-05-11
06 Benoît Claise
[Ballot comment]
In this document, I see:

  IPv6 nodes SHOULD implement Path MTU Discovery in order to discover
  and take advantage of paths …
[Ballot comment]
In this document, I see:

  IPv6 nodes SHOULD implement Path MTU Discovery in order to discover
  and take advantage of paths with PMTU greater than the IPv6 minimum
  link MTU [I-D.ietf-6man-rfc2460bis].  A minimal IPv6 implementation
  (e.g., in a boot ROM) may choose to omit implementation of Path MTU
  Discovery.

In draft-ietf-6man-rfc2460bis-09:
  It is strongly recommended that IPv6 nodes implement Path MTU
  Discovery [RFC1981], in order to discover and take advantage of path
  MTUs greater than 1280 octets.  However, a minimal IPv6
  implementation (e.g., in a boot ROM) may simply restrict itself to
  sending packets no larger than 1280 octets, and omit implementation
  of Path MTU Discovery.

So a SHOULD in one document versus "strongly recommended" in the other.
We should reconcile the two texts.
Note: may and may are consistent.


ICMPv6 PTB => ICMPv6 Packet to Big (PTB)
2017-05-11
06 Benoît Claise [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise
2017-05-10
06 Adam Roach
[Ballot comment]
I'd like to add my voice to the concerns expressed regarding RFC2119 language. I understand the desire to only deal with the changed …
[Ballot comment]
I'd like to add my voice to the concerns expressed regarding RFC2119 language. I understand the desire to only deal with the changed parts of the specification; but the current process as I understand it is that bis versions of document are expected to be "brought up to code" according to modern IETF document practices. Perhaps we should have a conversation about whether that practice is in need of revising, but I'm not sure making piecemeal exceptions is the best way to go about starting that conversation. In any case, I believe that current practice is that new RFCs cite 2119 and adhere to its definitions when using these specific terms in all-caps; and that this will be published as a new RFC.

Minor technical comment: Like others, I also had a really hard time with the paragraph in section 4 concluding with "MUST force the Path MTU Discovery process to end." It's difficult to read this as anything *other* than "you get one Path Too Big, and just shut down discovery," but that's clearly not what the rest of the document says. (I'll also note that if we are treating capital "MUST" as normative, then "MUST attempt to" is kind of meaningless).

Minor technical comment: Section 5.4 has three paragraphs, starting "Alternatively, the retransmission could be done in immediate response to a notification" that propose a more aggressive means of dealing with packets lost to PMTU issues; most of this text is a warning about how this can go awry and (if you'll excuse a bit of hyperbole) melt the Internet. Given that the first alternative works just fine and appears to be much safer, is this alternative actually something we want to recommend for today's implementations?

The remainder of my comments are editorial.

The second-to-last paragraph of the introduction uses the phrase "such messages" in a way that makes the antecedant difficult to find. I spent a while trying to figure out how PMTUD used TCP three-way-handshakes or blackholed TCP packets to determine PMTU. Suggest: "..relies on ICMPv6 messages to determine..."

The abbreviation "PTB" appears in the second paragraph of section 4. I would ordinarily suggest expanding on first use; but as this is this first and only use, I suggest simply replacing it with the long form used in the rest of the document.

Section 5.1 introduces the term MMS_S, and relates it to EMTU_S. I note that the former is not in the terminology section, while the latter is -- I suspect that they should both be present.

Section 5.2 uses the acronym "ECMP". I would suggest citing the related document in which ECMP is defined and optionally expanding the acronym.

Section 5.2 indicates:

  Also, the instance that sent the packet that elicited the Packet Too
  Big message should be notified that its packet has been dropped, even
  if the PMTU estimate has not changed, so that it may retransmit the
  dropped data.

It is quite nonintuitive how this situation could arise: if the packet is of size X, and the PMTU has not changed, then it follows that X <= PMTU (as the packet would have been reduced in size otherwise). If the PMTU has not changed, it also follows that PMTU <= MTU (from the Packet Too Big message). it follows that X <= MTU (from the Packet Too Big message), and so it really should not have been dropped unless the corresponding router has an implementation flaw of some kind. More importantly, it would seem that an attempt to transmit another packet of size X at this point would run an overwhelmingly high chance of triggering another Packet Too Big for whatever errant reason caused the first one to be sent.

I'm sure this naïve explanation overlooks whatever nonintuitive situation is envisioned by this paragraph. It would be quite helpful if such a situation were described: I, as an implementor, would look at this and say "What? No. I'm not doing that. It's extra work for no benefit."

I suspect it will be dealt with by the RFC editor, but the first normative reference seems to have some kind of issue with the production of the authors' names.

I see several acknowledgements in section B.1 that will be removed prior to publication. The authors may wish to consider moving these names to section 7 for the sake of posterity.
2017-05-10
06 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2017-05-10
06 Alissa Cooper [Ballot comment]
I agree with Alvaro's proposed resolution to the 2119 issue, which was also raised by the Gen-ART reviewer.
2017-05-10
06 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2017-05-10
06 Ben Campbell [Ballot comment]
I agree Alvaro's DISCUSS point about 2119 language.
2017-05-10
06 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-05-10
06 Warren Kumari
[Ballot discuss]
The OpsDir review (https://datatracker.ietf.org/doc/review-ietf-6man-rfc1981bis-04-opsdir-lc-hares-2017-03-04/ ) raises an interesting point, which I had not occurred to me. If the MTU for a path …
[Ballot discuss]
The OpsDir review (https://datatracker.ietf.org/doc/review-ietf-6man-rfc1981bis-04-opsdir-lc-hares-2017-03-04/ ) raises an interesting point, which I had not occurred to me. If the MTU for a path is 1440 bytes, and ND/RA suddenly says that the interface MTU is only 1400 bytes, what should implementations do?
I'd expect something like decrease the path MTU (for all paths) to min (new link MTU, current path MTU), but it isn't (AFAICT) specified.

It's entirely possible that this is a: already covered and / or b: covered at a different layer / different protocol, happy to be hit with a clue bat...
2017-05-10
06 Warren Kumari
[Ballot comment]
Please also see the OpsDir review....


I sent email about this to the authors on Feb 23rd - I seem to still have …
[Ballot comment]
Please also see the OpsDir review....


I sent email about this to the authors on Feb 23rd - I seem to still have have many of the same questions...

Comments:
1: Sec 1: "Path MTU Discovery relies on such messages to determine the MTU of the path."
-- it is unclear which "such" refers to. Perhaps s/such/ICMPv6/ (or PTB).

2: Sec 3: "Upon receipt of such a message, the
  source node reduces its assumed PMTU for the path based on the MTU of
  the constricting hop as reported in the Packet Too Big message" -- this says that it reduces it *for the path*. But (as somewhat alluded to later in the draft) the nodes doesn't know what the path *is* -- it can decrease for the destination, or flow, or even interface, but (unless it is strict source routing) it doesn't control or really know the path (see also #4)

3: Sec 4: "The recommended setting for this timer is twice its minimum value (10 minutes)." - as above. This was from 1996 - were these metrics discussed at all during the -bis? I suspect that the average flow is much shorter these days (more web traffic, fatter pipes, etc) and so a flow of 10 minutes seems really long (to me at least).

4: Sec 5.2: "The packetization layers must be notified about decreases in the
  PMTU.  Any packetization layer instance (for example, a TCP
  connection) that is actively using the path must be notified if the
  PMTU estimate is decreased.
      Note: even if the Packet Too Big message contains an Original
      Packet Header that refers to a UDP packet, the TCP layer must be
      notified if any of its connections use the given path."
- this is related to #2 -- I don't know *which* path my packets take - once I launch them into the void, they may be routed purely based upon destination IP address, or they may be hashed based upon some set of header fields to a particular ECMP link or LSP. Once packets hit a load balancer, it is probably even *likely* that the UDP and TCP packets end up on different things. So, if I get a PTB from a router somewhere, I can probably guess that other packets to the same destination address will also follow that path, but I cannot know that for sure. I'm fine to decrease MTU towards that destination IP, but is that what this is suggesting? If so, please say that. If not, please let me know what I should do. The above is even more tricky / fun when I'm using flow id as the flow identifier -- if I get a PTB for flow 0x1234, what do I do?

5: Sec 5.3: "Once a minute, a timer-driven procedure runs through all cached PMTU values, and for each PMTU whose timestamp is not "reserved" and is older than the timeout interval ...". Please consider providing clarifications here. The wording implies that I should set a timer to fire on the minute, and trigger the behavior. If all of the (NTP synced!) machines in my datacenter do this, and all try send bigger packets (on 1/10th of long flows) their first hop router will get many, many over-sized packets and it will severely rate-limit the PTBs.


Nits (Some of these are purely academic.)
I understand that you are trying to limit the changes, so feel free to ignore these:

1: "A node sending packets much smaller than the Path
MTU allows is wasting network resources and probably getting
suboptimal throughput." - the "much" confuses me. If I'm using anything less than the MTU I'm wasting network resources and getting suboptimal throughput - I might not care, but if (used MTU) < (path MTU) I'm wasting resources.

2: "Nodes implementing Path MTU Discovery and sending packets larger than
the IPv6 minimum link MTU are susceptible to problematic connectivity
if ICMPv6 [ICMPv6] messages are blocked or not transmitted." The "implementing Path MTU Discovery and" seems redundant. ALL nodes sending packets larger than minimum MTU are "susceptible to problematic connectivity if ICMPv6 [ICMPv6] messages are blocked or not transmitted.". I get what you are trying to say, but my OCD tendencies would not allow me to ignore this...

3: "In the case of multipath routing (e.g., Equal Cost Multipath Routing, ECMP),"- this is vague / confusing -- (Equal Cost Multipath Routing, ECMP) makes it sound like either ECMP is an acronym for Equal Cost Multipath Routing, or that ECMP is something different to Equal Cost Multipath Routing.
I'd suggest just dropping the "ECMP" (or, "Equal Cost Multipath (ECMP) routing", but that seems clumsy)
2017-05-10
06 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to Discuss from No Record
2017-05-10
06 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2017-05-10
06 Kathleen Moriarty
[Ballot comment]
Thanks for the agreed text update from the SecDir review that should show up in the next revision:
https://mailarchive.ietf.org/arch/msg/secdir/TSP93gEx0QW9WDOHUK3X3ipGiMk

I also agree with …
[Ballot comment]
Thanks for the agreed text update from the SecDir review that should show up in the next revision:
https://mailarchive.ietf.org/arch/msg/secdir/TSP93gEx0QW9WDOHUK3X3ipGiMk

I also agree with others that use of RFC2119 and ensuring consistent use of normative language would be helpful.
2017-05-10
06 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-05-10
06 Spencer Dawkins [Ballot comment]
I'm watching the many e-mail threads on IESG ballot positions for this draft, but don't have anything to add.
2017-05-10
06 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-05-09
06 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-05-09
06 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2017-05-09
06 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2017-05-08
06 Alvaro Retana
[Ballot discuss]
I'm putting in this point as a DISCUSS because I think that the current text may be confusing and vague.

As others have …
[Ballot discuss]
I'm putting in this point as a DISCUSS because I think that the current text may be confusing and vague.

As others have pointed out, this document includes rfc2119-like language, both capitalized and not.  I realize that rfc1981 was published before rfc2119 and that no expectation on the language existed then.  However, we're at a point in time where not only rfc2119 is in place, but draft-leiba-rfc2119-update (which clarifies that only uppercase language has special meaning) is in AUTH48.  I think that this leads to the possibility that the average reader may interpret the requirements in this document in a way that it wasn't intended.

While I would prefer that this document be consistent (and either use capitalized rfc2119 language as intended, OR, not used it at all), I understand the intent of not changing some of the original text.  I would be happy with a note like this one: "Note:  This document is an update to RFC1981 that was published prior to RFC2119 being published.  Consequently while it does use "should/must" style language in upper and lower case, the document does not cite the RFC2119 definitions.  This update does not change that."  [I borrowed this text from the the INTDIR review thread. [1]]

I find that including a note in the Shepherd's write-up is not enough because the average reader/implementer will not consult it.


[1] https://mailarchive.ietf.org/arch/msg/int-dir/bVH_0ydVdGssOiszJKhQXLYPuXY/?qid=4000f8a954b226266f429842911101f5
2017-05-08
06 Alvaro Retana [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana
2017-05-08
06 Warren Kumari
[Ballot comment]
[ Reminder to myself - I'm leaving this as No Record while looking more... ]

I sent email about this to the authors …
[Ballot comment]
[ Reminder to myself - I'm leaving this as No Record while looking more... ]

I sent email about this to the authors on Feb 23rd - I seem to still have have many of the same questions...

Comments:
1: Sec 1: "Path MTU Discovery relies on such messages to determine the MTU of the path."
-- it is unclear which "such" refers to. Perhaps s/such/ICMPv6/ (or PTB).

2: Sec 3: "Upon receipt of such a message, the
  source node reduces its assumed PMTU for the path based on the MTU of
  the constricting hop as reported in the Packet Too Big message" -- this says that it reduces it *for the path*. But (as somewhat alluded to later in the draft) the nodes doesn't know what the path *is* -- it can decrease for the destination, or flow, or even interface, but (unless it is strict source routing) it doesn't control or really know the path (see also #4)

3: Sec 4: "The recommended setting for this timer is twice its minimum value (10 minutes)." - as above. This was from 1996 - were these metrics discussed at all during the -bis? I suspect that the average flow is much shorter these days (more web traffic, fatter pipes, etc) and so a flow of 10 minutes seems really long (to me at least).

4: Sec 5.2: "The packetization layers must be notified about decreases in the
  PMTU.  Any packetization layer instance (for example, a TCP
  connection) that is actively using the path must be notified if the
  PMTU estimate is decreased.
      Note: even if the Packet Too Big message contains an Original
      Packet Header that refers to a UDP packet, the TCP layer must be
      notified if any of its connections use the given path."
- this is related to #2 -- I don't know *which* path my packets take - once I launch them into the void, they may be routed purely based upon destination IP address, or they may be hashed based upon some set of header fields to a particular ECMP link or LSP. Once packets hit a load balancer, it is probably even *likely* that the UDP and TCP packets end up on different things. So, if I get a PTB from a router somewhere, I can probably guess that other packets to the same destination address will also follow that path, but I cannot know that for sure. I'm fine to decrease MTU towards that destination IP, but is that what this is suggesting? If so, please say that. If not, please let me know what I should do. The above is even more tricky / fun when I'm using flow id as the flow identifier -- if I get a PTB for flow 0x1234, what do I do?

5: Sec 5.3: "Once a minute, a timer-driven procedure runs through all cached PMTU values, and for each PMTU whose timestamp is not "reserved" and is older than the timeout interval ...". Please consider providing clarifications here. The wording implies that I should set a timer to fire on the minute, and trigger the behavior. If all of the (NTP synced!) machines in my datacenter do this, and all try send bigger packets (on 1/10th of long flows) their first hop router will get many, many over-sized packets and it will severely rate-limit the PTBs.


Nits (Some of these are purely academic.)
I understand that you are trying to limit the changes, so feel free to ignore these:

1: "A node sending packets much smaller than the Path
MTU allows is wasting network resources and probably getting
suboptimal throughput." - the "much" confuses me. If I'm using anything less than the MTU I'm wasting network resources and getting suboptimal throughput - I might not care, but if (used MTU) < (path MTU) I'm wasting resources.

2: "Nodes implementing Path MTU Discovery and sending packets larger than
the IPv6 minimum link MTU are susceptible to problematic connectivity
if ICMPv6 [ICMPv6] messages are blocked or not transmitted." The "implementing Path MTU Discovery and" seems redundant. ALL nodes sending packets larger than minimum MTU are "susceptible to problematic connectivity if ICMPv6 [ICMPv6] messages are blocked or not transmitted.". I get what you are trying to say, but my OCD tendencies would not allow me to ignore this...

3: "In the case of multipath routing (e.g., Equal Cost Multipath Routing, ECMP),"- this is vague / confusing -- (Equal Cost Multipath Routing, ECMP) makes it sound like either ECMP is an acronym for Equal Cost Multipath Routing, or that ECMP is something different to Equal Cost Multipath Routing.
I'd suggest just dropping the "ECMP" (or, "Equal Cost Multipath (ECMP) routing", but that seems clumsy)
2017-05-08
06 Warren Kumari Ballot comment text updated for Warren Kumari
2017-05-08
06 Mirja Kühlewind
[Ballot discuss]
I know this is a bis document and my discuss does not address any text that changed in the bis version but given …
[Ballot discuss]
I know this is a bis document and my discuss does not address any text that changed in the bis version but given all previous discussion, I would like to discuss the following text parts on statements regarding retransmissions which don't seem to be appropriate for this document and are partly even wrong.
In general it does not make a lot of sense to talk about retransmission semantics in this document because this really depends on the upper layer protocol, and I'm really not sure if any implementaiton of a reliable transport does send retransmission based on the receptions of PTB messages (if exposed) rather than only relying on it's own loss detection mechanism. This discuss concerns a few sentence all over the document and most parts of section 5.4. Details proposals below:

I propose to either remove this sentence, or at least reword to the following (or something similar):
OLD:
"Retransmission should be done for only for those packets that are
  known to be dropped, as indicated by a Packet Too Big message."
NEW:
"The IP layer may indicate loss to the upper layer protocol of those packets that are
  known to be dropped, as indicated by a Packet Too Big message."
Or MAY or SHOULD or MUST...?

Subsequently the following sentence should be removed as well:
"An upper layer must not retransmit data in response to an increase in
  the PMTU estimate, since this increase never comes in response to an
  indication of a dropped packet."

And here is the bigger change in section 5.4:
OLD
"When a Packet Too Big message is received, it implies that a packet
  was dropped by the node that sent the ICMPv6 message.  It is
  sufficient to treat this in the same way as any other dropped
  segment, and will be recovered by normal retransmission methods.  If
  the Path MTU Discovery process requires several steps to find the
  PMTU of the full path, this could delay the connection by many round-
  trip times.

  Alternatively, the retransmission could be done in immediate response
  to a notification that the Path MTU has changed, but only for the
  specific connection specified by the Packet Too Big message.  The
  packet size used in the retransmission should be no larger than the
  new PMTU."
NEW
"When a Packet Too Big message is received, it implies that a packet
  was dropped by the node that sent the ICMPv6 message.  A reliable
  upper layer protocol will detect the loss of this segment, and recover
  it by its normal retransmission methods.  Depending on the loss
  detection method that is used by the upper layer protocol, this
  could delay the connection by many round-trip times.

  Alternatively, the retransmission could be done in immediate response
  to a notification that the Path MTU was decreased, but only for the
  specific connection specified by the Packet Too Big message.  The
  packet size used in the retransmission should be no larger than the
  new PMTU."

I don't understand the following paragraph. Can this be removed?
"Note: A packetization layer must not retransmit in response to
      every Packet Too Big message, since a burst of several oversized
      segments will give rise to several such messages and hence several
      retransmissions of the same data.  If the new estimated PMTU is
      still wrong, the process repeats, and there is an exponential
      growth in the number of superfluous segments sent."

The following text is fine but probably is not needed if the whole document is reworded accordingly to ensure that retransmissions are solely the responsibility of the upper layer protocol:
    "Retransmissions can increase network load in response to
      congestion, worsening that congestion.  Any packetization layer
      that uses retransmission is responsible for congestion control of
      its retransmissions.  See [RFC8085] for more information."

This can also be removed, because a reliable protocol that detected loss and decided to send a retransmission, should and will do the same processing as for all other retransmissions, e.g. reset the retransmission time in TCP. Mentioning this separately is rather confusing.
      "This means that the TCP layer must be able to recognize when a
      Packet Too Big notification actually decreases the PMTU that it
      has already used to send a packet on the given connection, and
      should ignore any other notifications."

And this is even incorrect. Slow start means that you will increase the connection window exponentially. Only sending one segment means setting the congestion/sending window to one. I propose the following change:
OLD
  "Many TCP implementations incorporate "congestion avoidance" and
  "slow-start" algorithms to improve performance [CONG].  Unlike a
  retransmission caused by a TCP retransmission timeout, a
  retransmission caused by a Packet Too Big message should not change
  the congestion window.  It should, however, trigger the slow-start
  mechanism (i.e., only one segment should be retransmitted until
  acknowledgements begin to arrive again)."
NEW
"A loss caused by a PMTU probe indicated by the reception of a Packet Too Big message MUST NOT be considered as a congestion notification and hence the congestion window may not change."

And I also don't understand this sentence:
"TCP performance can be reduced if the sender's maximum window size is
  not an exact multiple of the segment size in use (this is not the
  congestion window size)."
2017-05-08
06 Mirja Kühlewind
[Ballot comment]
1) I agree with Ekr on this sentence:
"Nodes SHOULD appropriately validate the payload of ICMPv6 PTB
  messages to ensure these are …
[Ballot comment]
1) I agree with Ekr on this sentence:
"Nodes SHOULD appropriately validate the payload of ICMPv6 PTB
  messages to ensure these are received in response to transmitted
  traffic (i.e., a reported error condition that corresponds to an IPv6
  packet actually sent by the application) per [ICMPv6]."
This sounds like it should be a MUST but I guess it depends on the upper layer protocol if such a validation is possible or not, e.g. if information are available that can be used for validation. Maybe you can be more explicit here and even say something like pmtu discovery should/must only be used if the upper layer protocol provides means for validation of the icmp payload (like a sequence number in TCP)…?

Further also note that if the upper layer does the validation while the IP layer maintains EMTU_S, there must be an interface from the upper layer to the IP layer to tell if a packet is valid or not before the IP layer updates the MTU estimate. This seems actually more complicated than this one sentences indicates.

2) Also as Ekr says, I also have problems to fully understand this normative text in section 4:
"After receiving a Packet Too Big message, a node MUST attempt to
  avoid eliciting more such messages in the near future.  The node MUST
  reduce the size of the packets it is sending along the path.  Using a
  PMTU estimate larger than the IPv6 minimum link MTU may continue to
  elicit Packet Too Big messages.  Since each of these messages (and
  the dropped packets they respond to) consume network resources, the
  node MUST force the Path MTU Discovery process to end.

  Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
  as possible."
I especially don't understand the first part, given that a PTB message may still indicate a MTU that is larger than the minimum link MTU which then may cause another PTB message later on the path. This text reads like if you receive one PTB message you should better end discovery and fall back to the minimum link MTU to avoid any further PTB message and not waist any resources. I don't think that's the intention and as such I don't understand when it is recommended to end discovery here...?

3) Section 5.2 seems to be written with only single homed hosts in mind. It might be good to advise that the pmtu information should always be stored on a per interface basis...?

4) Also section 5.2:
You only advise to store information per flow ID, however, if the flow label is not used, wouldn't it make really sense to just use the 5-tuple instead? Also note that EMCP is often done based on the 5-tuple or even 6-tuple (with the ToS field).

5) And more in section 5.2:
"When a Packet Too Big message is received, the node determines which
  path the message applies to based on the contents of the Packet Too
  Big message. "
MAYBE:
"When a valid Packet Too Big message is received, the node determines which
  path the message applies to based on the contents of the Packet Too
  Big message."
And further on:
"If the tentative PMTU is less than the existing PMTU estimate, the
  tentative PMTU replaces the existing PMTU as the PMTU value for the
  path."
This doesn't cover the case where a pmtu probe with a larger size was send and the PTB message returns a larger value then stored. Maybe state this explicitly.

This applies similar to this sentence in section 6:
OLD
"A node, however, should never raise its estimate of the
      PMTU based on a Packet Too Big message, so should not be
      vulnerable to this attack.“
NEW
"A node, however, MUST NOT raise its estimate of the
      PMTU based on a Packet Too Big message that is not a (validated) response to a PMTU probe that was previously send by this node, so should not be
      vulnerable to this attack."

6) Further section 5.2:
Should this statement be maybe upper case MUST:
"The packetization layers must be notified about decreases in the PMTU. "

7) Technical comment on section 5.3 in general:
There is a difference between aging if a flow is active or not. While I maybe don't want to probe again for this connection because my application already decided to use a mode where it can live with the current pmtu and it's too much effect to switch, I really want to probe at the beginning of the next connection again to check if I can use a different mode now. While the IP layer does not have a notion of connection it can observe if packets are frequently send with the same 5-tuple and reset the cached pmtu after a certain idle time.

8) Section 5.4: should this maybe be normative, at least the last MUST NOT (be fragmented):
"A packetization layer (e.g., TCP) must track the PMTU for the path(s)
  in use by a connection; it should not send segments that would result
  in packets larger than the PMTU, except to probe during PMTU
  discovery (this probe packet must not be fragmented to the PMTU). "


Nit:
The abbreviation PTB is only used once in section 4 (and never expanded).
2017-05-08
06 Mirja Kühlewind [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind
2017-05-08
06 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-05-08
06 Eric Rescorla
[Ballot comment]
Document: draft-ietf-6man-rfc1981bis-06.txt

OVERALL
I see in the shepherd's writeup that you have opted not to cite RFC
2119
, but that makes the …
[Ballot comment]
Document: draft-ietf-6man-rfc1981bis-06.txt

OVERALL
I see in the shepherd's writeup that you have opted not to cite RFC
2119
, but that makes the mixed case use of SHOULD/MUST even more
confusing. I would suggest that at minimum you go through the document
and evaluate whether each should/must should be capitalized, though I
would prefer a cite to 2119.

For instance:
  changed.  Therefore, attempts to detect increases in a path's PMTU
  should be done infrequently.

Is this normative?


I also share the concerns others have raised about whether, given the
actual state of PMTU this is something we should be making IS, but
I'm willing to bow to the majority here.


S 3.
  Note that Path MTU Discovery must be performed even in cases where a
  node "thinks" a destination is attached to the same link as itself.

I think you need to qualify this must because you just said above that
you don't need to if you use the minimum. Perhaps:

  Note that even when a node "thinks" a destination is attached to
  the same link as itself, it might have a PMTU lower than the
  link MTU...


S 4.

  Nodes SHOULD appropriately validate the payload of ICMPv6 PTB
  messages to ensure these are received in response to transmitted
  traffic (i.e., a reported error condition that corresponds to an IPv6
  packet actually sent by the application) per [ICMPv6].

This seems like it ought to be a MUST. Is there a good reason why
it is not? Perhaps also a cite to how one validates.


  When a node receives a Packet Too Big message, it MUST reduce its

a valid Packet Too Big message, I think because in graf 2 you say you
should validate.


  elicit Packet Too Big messages.  Since each of these messages (and
  the dropped packets they respond to) consume network resources, the
  node MUST force the Path MTU Discovery process to end.

It's not clear to me what the requirement is.

  Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
  as possible.  Nodes MAY detect increases in PMTU, but because doing

Same thing, what are you requiring. How could I be nonconformant to
this?

S 5.
  This section discusses a number of issues related to the
  implementation of Path MTU Discovery.  This is not a specification,
  but rather a set of notes provided as an aid for implementers.

However, this section contains a lot of normative language. Is that all
non-normative?


S 5.3.
  If the stale PMTU value is too large, this will be discovered almost
  immediately once a large enough packet is sent on the path.  No such
  mechanism exists for realizing that a stale PMTU value is too small,
  so an implementation SHOULD "age" cached values.  When a PMTU value
  has not been decreased for a while (on the order of 10 minutes), the
  PMTU estimate should be set to the MTU of the first-hop link, and the
  packetization layers should be notified of the change.  This will
  cause the complete Path MTU Discovery process to take place again.

Is this really good advice for TCP? It seems like if you have a
situation where it required several attempts to get the true PMTU (for
instance, if you have successively narrower tunnels), then a PMTU
reset could have a pretty material impact on throughput.


S 6.
      dropped.  A node, however, should never raise its estimate of the
      PMTU based on a Packet Too Big message, so should not be
      vulnerable to this attack.

I get that this is now not a normative statement but rather a claim
about what nodes who follow the MUST NOT in S 4, but it might still
be better to make it a MUST to avoid confusion.
2017-05-08
06 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2017-05-07
06 Suresh Krishnan IESG state changed to IESG Evaluation from Waiting for Writeup
2017-05-07
06 Suresh Krishnan Ballot has been issued
2017-05-07
06 Suresh Krishnan [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan
2017-05-07
06 Suresh Krishnan Created "Approve" ballot
2017-05-07
06 Suresh Krishnan Ballot writeup was changed
2017-05-05
06 Ines Robles Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Ines Robles.
2017-04-24
06 Stewart Bryant Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Stewart Bryant. Sent review to list.
2017-04-23
06 Suresh Krishnan Telechat date has been changed to 2017-05-11 from 2017-04-27
2017-04-19
06 Jean Mahoney Request for Telechat review by GENART is assigned to Stewart Bryant
2017-04-19
06 Jean Mahoney Request for Telechat review by GENART is assigned to Stewart Bryant
2017-04-17
06 Rifaat Shekh-Yusef Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Rifaat Shekh-Yusef.
2017-04-13
06 Tero Kivinen Request for Telechat review by SECDIR is assigned to Rifaat Shekh-Yusef
2017-04-13
06 Tero Kivinen Request for Telechat review by SECDIR is assigned to Rifaat Shekh-Yusef
2017-04-12
06 Wesley Eddy Closed request for Telechat review by TSVART with state 'Team Will not Review Version'
2017-04-12
06 Wesley Eddy Request for Telechat review by TSVART is assigned to Joseph Touch
2017-04-12
06 Wesley Eddy Request for Telechat review by TSVART is assigned to Joseph Touch
2017-04-07
06 Bob Hinden New version available: draft-ietf-6man-rfc1981bis-06.txt
2017-04-07
06 (System) New version approved
2017-04-07
06 (System) Request for posting confirmation emailed to previous authors: Robert Hinden , 6man-chairs@ietf.org
2017-04-07
06 Bob Hinden Uploaded new revision
2017-04-07
05 Suresh Krishnan Placed on agenda for telechat - 2017-04-27
2017-03-31
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-03-31
05 Bob Hinden New version available: draft-ietf-6man-rfc1981bis-05.txt
2017-03-31
05 (System) New version approved
2017-03-31
05 (System) Request for posting confirmation emailed to previous authors: Robert Hinden , 6man-chairs@ietf.org
2017-03-31
05 Bob Hinden Uploaded new revision
2017-03-28
04 Martin Stiemerling Request for Telechat review by TSVART Completed: Not Ready. Reviewer: Joseph Touch.
2017-03-27
04 Jonathan Hardwick Request for Last Call review by RTGDIR is assigned to Ines Robles
2017-03-27
04 Jonathan Hardwick Request for Last Call review by RTGDIR is assigned to Ines Robles
2017-03-04
04 Susan Hares Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Susan Hares. Sent review to list.
2017-03-01
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-02-26
04 Suresh Krishnan Removed from agenda for telechat
2017-02-23
04 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2017-02-23
04 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-6man-rfc1981bis-04.txt, which is currently in Last Call, and has the following comments:

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

The IANA Services Operator has reviewed draft-ietf-6man-rfc1981bis-04.txt, 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.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2017-02-12
04 Min Ye Request for Last Call review by RTGDIR is assigned to Thomas Clausen
2017-02-12
04 Min Ye Request for Last Call review by RTGDIR is assigned to Thomas Clausen
2017-02-10
04 Alvaro Retana Requested Last Call review by RTGDIR
2017-02-10
04 Martin Stiemerling Request for Telechat review by TSVART is assigned to Joseph Touch
2017-02-10
04 Martin Stiemerling Request for Telechat review by TSVART is assigned to Joseph Touch
2017-02-09
04 Suresh Krishnan Placed on agenda for telechat - 2017-03-02
2017-02-09
04 Stewart Bryant Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Stewart Bryant. Sent review to list.
2017-02-09
04 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Rifaat Shekh-Yusef.
2017-02-03
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2017-02-03
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2017-02-02
04 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2017-02-02
04 Jean Mahoney Request for Last Call review by GENART is assigned to Stewart Bryant
2017-02-02
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef
2017-02-02
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef
2017-02-01
04 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-02-01
04 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ipv6@ietf.org, "Ole Troan" , suresh.krishnan@ericsson.com, draft-ietf-6man-rfc1981bis@ietf.org, otroan@employees.org, …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ipv6@ietf.org, "Ole Troan" , suresh.krishnan@ericsson.com, draft-ietf-6man-rfc1981bis@ietf.org, otroan@employees.org, 6man-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Path MTU Discovery for IP version 6) to Internet Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Path MTU Discovery for IP version 6'
  as Internet 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
ietf@ietf.org mailing lists by 2017-03-01. 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 describes Path MTU Discovery for IP version 6.  It is
  largely derived from RFC 1191, which describes Path MTU Discovery for
  IP version 4.  It obsoletes RFC1981.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (Draft Standard - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.


2017-02-01
04 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-02-01
04 Suresh Krishnan Last call was requested
2017-02-01
04 Suresh Krishnan Ballot approval text was generated
2017-02-01
04 Suresh Krishnan Ballot writeup was generated
2017-02-01
04 Suresh Krishnan IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-02-01
04 Suresh Krishnan Last call announcement was changed
2017-01-31
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-01-31
04 Bob Hinden New version available: draft-ietf-6man-rfc1981bis-04.txt
2017-01-31
04 (System) New version approved
2017-01-31
04 (System) Request for posting confirmation emailed to previous authors: "Robert Hinden" , 6man-chairs@ietf.org
2017-01-31
04 Bob Hinden Uploaded new revision
2017-01-27
03 Bob Hinden
RFC1981bis Writeup
-------------------

Title          : Path MTU Discovery for IP version 6
Authors        : Jack McCann <>
  …
RFC1981bis Writeup
-------------------

Title          : Path MTU Discovery for IP version 6
Authors        : Jack McCann <>
                  Stephen E. Deering <>
                  Jeffrey Mogul <>
                  Robert M. Hinden, Editor
Filename        : draft-ietf-6man-rfc1981bis-03.txt
Pages          : 17
Date            : 2016-10-04


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

  Internet Standard

  RFC1981 is currently at Draft Standard, the 6MAN working group has
  reached a consensus that it’s time to elevate the Path MTU Discovery
  for IP version 6 specification to Internet Standard.

  The header indicates “Standards Track”.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes Path MTU Discovery for IP version 6.  It is
  largely derived from RFC 1191, which describes Path MTU Discovery for
  IP version 4.  It obsoletes RFC1981.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

  The 6MAN working started working on advancing the IPv6 core
  specifications to Internet Standard at IETF93 July 2015.  See:
  https://www.ietf.org/proceedings/93/slides/slides-93-6man-3.pdf The
  working group identified three RFCs to update (RFC2460, RFC4291, and
  RFC1981) by incorporating updates from other RFCs and Errata, and
  three to advance in place RFC4443, RFC3596, and RFC4941.  After
  further analysis, the w.g. decided to not reclassify RFC4941 at this
  time.
 
  The working followed the requirements in RFC6410 for advancing a Draft
  Standard to Internet Standard.  While RFC6410 describes how to handle
  Errata, it doesn't say anything about Updated-By RFCs.  The working
  group, with the advice of our AD, incorporated the changes from the
  the Updated-By RFC and verified there was interoperability of the
  updates.

  All of the Updated-By and errata were brought into the new draft in
  small steps to allow thorough review of all of the changes.  A summary
  and link to diff from the previous version was sent to the mailing
  list.  All of the changes to each draft were also discussed in detail
  at IETF94, IETF95, IETF96, and IETF97.  All of the changes from
  RFC1981 are summarized in Appendix B and are ordered by the Internet
  Draft that brought the change in.

  This document is an update to RFC1981 that was published prior to
  RFC2119 being published.  Consequently while it does use "should/must"
  style language in upper and lower case, the document does not cite the
  RFC2119 definitions.  Since the changes in this update were very
  limited, the w.g. concluded to not change any of this language.
 
  A working group last call for moving this and the other two documents
  to Internet Standard was started on 30 May 2016.  Reviews were also
  requested.  Issues found during the last call and reviews were entered
  into the 6MAN ticket system.  These are now closed.


Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  IPv6 is implemented on most platforms (hosts, routers, servers, etc.),
  including proprietary and open source.  A list of products that have
  received the IPV6 Ready logo can be found at:
  https://www.ipv6ready.org/db/index.php/public/?o=4

  Most major ISP now support IPv6, as well as many mobile
  operators.

  Google’s IPv6 stats at
  https://www.google.com/intl/en/ipv6/statistics.html show they are
  seeing now about 15% of their overall user traffic is IPv6. Country
  adoption is 29% in the US, Germany 27%, Finland 12%, Japan 14%, Brazil
  11%.  IPv6 users per AS can be found at
  http://stats.labs.apnic.net/aspop

  The University of New Hampshire InterOperability Laboratory (UNH)
  analyzed the incorporated updates to insure they were implemented and
  interoperable.  No problems were found.  Their report can be found at:
  https://www.ietf.org/proceedings/95/slides/slides-95-6man-2.pdf

  No MIB, Media, or other expert reviews are required.
 

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Document Shepherd: Ole Trøan
  Responsible AD: Suresh Krishnan


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document was reviewed by the Document Shepherd and believes it is
  ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  Yes


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR.


(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

  The document has had extensive review in the 6MAN working group and
  there is broad support to this version of the IPv6 specification as an
  Internet Standard.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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 appeals have been threatened.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  Nothing serious.  A few miscellaneous warning about line spacing and
  notice that the reference to draft-ietf-6man-rfc2460bis is a down
  reference. Draft-ietf-6man-rfc2460bis will be submitted for Internet
  Standard with this draft.  Also, this document uses capitalized MUST,
  SHOULD, etc. language, but doesn't reference RFC2119 because it was
  originally written prior to RFC2119.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  N/A


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  The only normative reference this is not an RFC, is a reference to
  draft-ietf-6man-rfc2460bis. This draft is also being submitted to the
  IESG for Internet standard around the same time as this document.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  Nothing other than draft-ietf-6man-rfc2460bis discussed in the
  previous section.
 

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.


  This document obsoletes RFC1981. This is indicated in the header and
  abstract.


(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

    This document does not make any new assignments.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

    N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.


    N/A


2017-01-27
03 Suresh Krishnan A new version will be needed to address the AD evaluation comments and the INT dir review by Donald Eastlake.
2017-01-27
03 Suresh Krishnan IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-01-25
03 Donald Eastlake Request for Early review by INTDIR Completed: Ready with Nits. Reviewer: Donald Eastlake.
2017-01-24
03 Suresh Krishnan INT Dir review was not received and reviewer did not respond to reminders from INT Dir secretary.
2017-01-05
03 Carlos Bernardos Request for Early review by INTDIR is assigned to Donald Eastlake
2017-01-05
03 Carlos Bernardos Request for Early review by INTDIR is assigned to Donald Eastlake
2017-01-04
03 Suresh Krishnan IESG state changed to AD Evaluation from Publication Requested
2017-01-04
03 Suresh Krishnan Requested Early review by INTDIR
2016-12-02
03 Bob Hinden
RFC1981bis Writeup
-------------------

Title          : Path MTU Discovery for IP version 6
Authors        : Jack McCann <>
  …
RFC1981bis Writeup
-------------------

Title          : Path MTU Discovery for IP version 6
Authors        : Jack McCann <>
                  Stephen E. Deering <>
                  Jeffrey Mogul <>
                  Robert M. Hinden, Editor
Filename        : draft-ietf-6man-rfc1981bis-03.txt
Pages          : 17
Date            : 2016-10-04


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

  Internet Standard

  RFC1981 is currently at Draft Standard, the 6MAN working group has
  reached a consensus that it’s time to elevate the Path MTU Discovery
  for IP version 6 specification to Internet Standard.

  The header indicates “Standards Track”.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes Path MTU Discovery for IP version 6.  It is
  largely derived from RFC 1191, which describes Path MTU Discovery for
  IP version 4.  It obsoletes RFC1981.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

  The 6MAN working started working on advancing the IPv6 core
  specifications to Internet Standard at IETF93 July 2015.  See:
  https://www.ietf.org/proceedings/93/slides/slides-93-6man-3.pdf The
  working group identified three RFCs to update (RFC2460, RFC4291, and
  RFC1981) by incorporating updates from other RFCs and Errata, and
  three to advance in place RFC4443, RFC3596, and RFC4941.  After
  further analysis, the w.g. decided to not reclassify RFC4941 at this
  time.
 
  The working followed the requirements in RFC6410 for advancing a Draft
  Standard to Internet Standard.  While RFC6410 describes how to handle
  Errata, it doesn't say anything about Updated-By RFCs.  The working
  group, with the advice of our AD, incorporated the changes from the
  the Updated-By RFC and verified there was interoperability of the
  updates.

  All of the Updated-By and errata were brought into the new draft in
  small steps to allow thorough review of all of the changes.  A summary
  and link to diff from the previous version was sent to the mailing
  list.  All of the changes to each draft were also discussed in detail
  at IETF94, IETF95, IETF96, and IETF97.  All of the changes from
  RFC1981 are summarized in Appendix B and are ordered by the Internet
  Draft that brought the change in.

  A working group last call for moving this and the other two documents
  to Internet Standard was started on 30 May 2016.  Reviews were also
  requested.  Issues found during the last call and reviews were entered
  into the 6MAN ticket system.  These are now closed.


Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  IPv6 is implemented on most platforms (hosts, routers, servers, etc.),
  including proprietary and open source.  A list of products that have
  received the IPV6 Ready logo can be found at:
  https://www.ipv6ready.org/db/index.php/public/?o=4

  Most major ISP now support IPv6, as well as many mobile
  operators.

  Google’s IPv6 stats at
  https://www.google.com/intl/en/ipv6/statistics.html show they are
  seeing now about 15% of their overall user traffic is IPv6. Country
  adoption is 29% in the US, Germany 27%, Finland 12%, Japan 14%, Brazil
  11%.  IPv6 users per AS can be found at
  http://stats.labs.apnic.net/aspop

  The University of New Hampshire InterOperability Laboratory (UNH)
  analyzed the incorporated updates to insure they were implemented and
  interoperable.  No problems were found.  Their report can be found at:
  https://www.ietf.org/proceedings/95/slides/slides-95-6man-2.pdf

  No MIB, Media, or other expert reviews are required.
 

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Document Shepherd: Ole Trøan
  Responsible AD: Suresh Krishnan


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document was reviewed by the Document Shepherd and believes it is
  ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  No.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  Yes


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR.


(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

  The document has had extensive review in the 6MAN working group and
  there is broad support to this version of the IPv6 specification as an
  Internet Standard.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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 appeals have been threatened.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  Nothing serious.  A few miscellaneous warning about line spacing and
  notice that the reference to draft-ietf-6man-rfc2460bis is a down
  reference. Draft-ietf-6man-rfc2460bis will be submitted for Internet
  Standard with this draft.  Also, this document uses capitalized MUST,
  SHOULD, etc. language, but doesn't reference RFC2119 because it was
  originally written prior to RFC2119.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  N/A


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  The only normative reference this is not an RFC, is a reference to
  draft-ietf-6man-rfc2460bis. This draft is also being submitted to the
  IESG for Internet standard around the same time as this document.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  Nothing other than draft-ietf-6man-rfc2460bis discussed in the
  previous section.
 

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.


  This document obsoletes RFC1981. This is indicated in the header and
  abstract.


(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

    This document does not make any new assignments.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

    N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.


    N/A


2016-12-02
03 Bob Hinden Responsible AD changed to Suresh Krishnan
2016-12-02
03 Bob Hinden IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2016-12-02
03 Bob Hinden IESG state changed to Publication Requested
2016-12-02
03 Bob Hinden IESG process started in state Publication Requested
2016-11-30
03 Bob Hinden Changed document writeup
2016-11-15
03 Ole Trøan IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2016-11-01
03 Bob Hinden Added to session: IETF-97: 6man  Tue-0930
2016-10-04
03 Bob Hinden New version available: draft-ietf-6man-rfc1981bis-03.txt
2016-10-04
03 (System) New version approved
2016-10-04
02 (System) Request for posting confirmation emailed to previous authors: "Robert Hinden" , 6man-chairs@ietf.org
2016-10-04
02 Bob Hinden Uploaded new revision
2016-07-16
02 Ole Trøan Notification list changed to "Ole Troan" <otroan@employees.org>
2016-07-16
02 Ole Trøan Document shepherd changed to Ole Troan
2016-07-16
02 Ole Trøan IETF WG state changed to In WG Last Call from WG Document
2016-05-12
02 Ole Trøan This document now replaces draft-hinden-6man-rfc1981bis instead of None
2016-04-27
02 Bob Hinden New version available: draft-ietf-6man-rfc1981bis-02.txt
2016-03-17
01 Bob Hinden New version available: draft-ietf-6man-rfc1981bis-01.txt
2016-03-16
00 Ole Trøan Changed consensus to Yes from Unknown
2016-03-16
00 Ole Trøan Intended Status changed to Internet Standard from None
2016-03-03
00 Bob Hinden New version available: draft-ietf-6man-rfc1981bis-00.txt