Hi, Fred, Sorry for the delay in providing comments (as promised). Here they are:
Section 2: > The current "Internet cell size" is effectively 1500 bytes, i.e., the > minimum MTU configured by the vast majority of links in the Internet. > IPv6 constrains this even further by specifying a minimum link MTU of > 1280 bytes [RFC2460]. However, due to operational issues with Path > MTU Discovery (PMTUD) [RFC1981] these sizes can often only be > accommodated when links with smaller link-layer segment sizes are > configured to perform link adaptation. We could probably add some references regarding PMTUD issues in IPv6 (some folks think/thought/expected them to be gone with v6... but they are not) -- found them later... could you move them to this para? > Unfortunately, link adaptation can present a significant burden to > the link endpoints, i.e., especially when the link supports high data > rates and/or is located nearer the "middle" of the network instead of > nearer the "edge". An alternative therefore is to ask the > originating IPv6 node to perform fragmentation on the packets it > sends, in which case reassembly would be performed by the final > destination. This is okay, but.. in the previous para, you started with the premise that you have to rely on link-adaptation as a result of PMTUD failures, so.... if ICMPv6 PTB are going to be blocked, how an you expect the sources to fragment their packets? (i.e., receive the corresponding signal) Section 3: > > This document does not propose to change these requirements, but > notes that link adaptation can be burdensome for some links to the > point that it would be highly desirable to push the fragmentation and > reassembly responsibility to the IPv6 communication endpoints. In > order to accommodate this, when the router at the link ingress > performs link adaptation on a packet it should also send an ICMPv6 > PTB message back to the original source (subject to rate limiting) > with a Next-Hop MTU less than 1280 and with Code field set to 1 > [RFC4443]. (Note that these PTB messages are advisory in nature and > do not necessarily indicate packet loss.) Some implementations validate ICMP error messages based on connection-progress (please see RFC 5927)-- in v6 this is as good as it can get, since you might not even receive the eg TCP header in the ICMPv6 payload. Since you'd be both sending an error *and* performing link adaptation, the connection would progress, and hence such implementations would drop the ICMPv6 message. -- workaround: keep track of whether the other endpoint reduces the size of its packets. If it doesn't, try "drop & send ICMPv6 PTB". (and yes, if packets stop flowing, you should assume there's a PMTUD blackhole) Section 3: > "In response to an IPv6 packet that is sent to a destination located > beyond an IPv6 link that must perform link adaptation, the > originating IPv6 node may receive an ICMP Packet Too Big message > reporting a Next-Hop MTU less than 1280 and with Code=1. In that > case, the IPv6 node is not required to reduce the size of subsequent > packets to less than 1500 bytes, but must perform IPv6 fragmentation > on those packets by breaking the packet into N roughly equal-length > pieces (where N is minimized and the length of each piece is smaller > than the Next-Hop MTU). These fragments will be reassembled by the > destination." I guess you meant "1280" rather than 1500? That aside: the text is a bit confusing. what's should be the maximum size of each fragment? The one reported by the ICMPv6 PTB code 1? Section 4: > Regardless of whether there is a link in the path that performs link > adaptation, when an originating IPv6 node receives a PTB message > reporting a Next-Hop MTU value between 1280 and 1500 bytes, the node > need not reduce the size of the packets it sends. The node may > instead invoke fragmentation for packets between 1281 and 1500 bytes > (again, by splitting the packet into N roughly equal-length pieces) > before submitting each fragment for link-layer framing. These > fragments will be reassembled by the final destination Why don't you want the packet size to be reduced in this case? That aside, if you're fragmenting the packets, you're reducing their size.... so I don't get why the text says "need not reduce..." Section 4: > A more interesting situation arises when PTB messages are lost on the > return path to the originating IPv6 node. Since the node has no way > of discerning which paths may exhibit this condition, it may be > better served to assume the worst case for all paths and take > precautionary measures to avoid silent packet loss. For example, an > originating IPv6 node that wishes to ensure that packets between 1281 > and 1500 bytes will reach the final destination can use "proactive > fragmentation" to fragment each packet (again, by splitting the > packet into N roughly equal-length pieces). Fragmentation is not a panacea. Please check the recent discussion on v6ops regarding IPv6 fragment filtering, and <http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf>. > 6. IANA Considerations > > There are no IANA considerations for this document. Of the top of my head: Aren't you specifying a new Code value for ICMPv6 PTB? -- Then it looks like you do have actions for IANA. Important item: At the end of the day, you're somehow saying that the IPv6 minimum MTU is no longer 1280 -- but not explicitly. So this should be made explicit (yes, yes.. "controversial"... but I like to call a lemon a lemon :-) ). -- FWIW, some folks have already noted that the hassle of having to do link adaptation, and v6-enabled links failing to to that (I have always been for references on this topic, though). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
