Path MTU Discovery for IP version 6
draft-ietf-6man-rfc1981bis-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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 Jesús Bernardos | Request for Early review by INTDIR is assigned to Donald Eastlake |
2017-01-05
|
03 | Carlos Jesús 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 |