On 02/08/2013 03:16 PM, Templin, Fred L wrote: >>> 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, > > Link adaptation is not necessarily as a result of PMTUD failures. > We already know that, for IPv6, link adaptation is a MUST if the > link MTU is smaller than 1280. What I am saying is that some links > may wish to set an even larger link adaptation threshold (say 1500) > under the presumption that PMTUD *might* fail.
That wasn't what I got in my first read of the document (at least). WOuld it be possible to clarify that? >>> 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. > > I'm curious as to what you mean by this. ICMPv6 PTB messages are > mandated to include "As much of (the) invoking packet as possible". > Has this not proven to be the case in operational practice? Or, are > you saying that the TCP header is sometimes not available in-the-clear, > e.g., if IP security is applied? I'm saying that, at least theoretically speaking, such header might not be there. Even if a node complies with draft-ietf-6man-oversized-header-chain (and e.g. puts lots of extension headers and then the tcp header in the first frag), when an error is elicited, the tcp header might need to be left out. That said, some implementations check for progress on the connection before honoring ICMPv6 PTB -- which means such implementations would drop the ICMPv6 PTB your proposing. >> 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. > > The system will still work if the source drops the ICMPv6 PTB > message - it's just that the system would work *better* if the > source would heed the message as specified in this document. Agreed. Just wanted to point this one out, since I don't know whether you had considered it. -- it might be worth a para. >> -- 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) > > It would be too much to ask for the link adaptation endpoint to > keep track of all of the sources and observe their behavior. Agreed. > > 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? > > No, I actually meant 1500 bytes. This is the minimum-sized reassembly > buffer that the destination is required to configure per RFC2460. So, > this is the maximum size for which the source can expect the destination > to perform reassembly unless it has some way of knowing that the > destination is capable of reassembling more. > >> 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? > > Each piece must be smaller than the Next-Hop MTU as reported by the > ICMPv6 PTB message, and the source must also minimize the number of > pieces it sends. But then you *are* reducing the size of your packets (the text says "is not required..."). Or am I missing something? May be you mean "is not required to reduce the assumed path mtu"? > >> 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..." > [...] > > "...when an originating IPv6 node receives a PTB message > reporting a Next-Hop MTU value between 1280 and 1500 bytes, the node > can reduce the size of the packets it sends as specified in RFC1981. > Alternatively, the node can invoke fragmentation for packets that are > larger than the Next-Hop MTU value but no larger than 1500 bytes, since > IPv6 destinations are required to reassemble at least that much > [RFC2460]." Probably saying "..can reduce the assumed path mtu" (RFC1918-terminology IIRC) might make it even clearer? >> 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>. > > That is worrisome. Yes. :-) > I don't understand that, if an IPv6 destination > is required to reassemble at least 1500 bytes, that middleboxes in > the network would prevent it from doing so. This seems to be even > more broken than the failure of the network to deliver ICMPv6 PTB > messages. If these core features don't work as advertised, can we > really ever expect to do anything better than 1280? I guess when it comes to packet size, something along the lines of < 1400 would generally work (i.e., the usual internet cell size, minus some bytes for possible tunnels). But it looks like as long as you need ICMPv6 PTB and/or fragmentation, you're in trouble. >>> 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 :-) ). > > What I would like to say is that the IPv6 minimum MTU size > should be bounded by the IPv6 minimum reassembly size (which is > 1500 bytes) instead of bounded by some curious constant value > such as 1280. I wasn't objecting at all -- for instance, at least at first thought, what you say makes sense to me. > Packets larger than 1500 bytes are also possible > when the IPv6 source uses RFC4821, but these packets would be > delivered without fragmentation if they are delivered at all. What if you need to send, say, a 5000 byte UDP datagram? >> -- 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). > > I think 6lowpan (RFC4944) might be one example? To be honest, I haven't picked at 6lowpan, yet. Do they implement an adaptation layer, or they simply say "sorry, our minimum MTU is something smaller than 1280"? Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
