Florian, On 01/03/2012 05:42 AM, Florian Weimer wrote: >>>> not really have a MTU >= 1280. In such scenarios there might be some >>>> for of gateway that sends the ICMPv6 PTB advertising a Next-Hop MTU >>>> smaller than 1280, thus resulting in atomic fragments (such that it's >>>> easier for the "gateway" to fragment the IPv6 packets). >>> >>> Yes, this seems a plausible explanation. I wouldn't consider this >>> actual use, rather network misconfiguration. >> >> Why? > > What Brian said---IPv6 is supposed to have a lower bound on the MTU. > I just don't think it's a good idea to through that out of the window > because there are genuine advantages.
Again: the v6 core spec mentions a possible scenarion in which you might legitimately receive CIMP PTBs that advertise an MTU smaller than 1280 bytes. In that case, you're not required to split your packets into fragments smaller or equal to 1280 bytes, but *are* required to react by including a Fragment Header in subsequent packets. >>> In my opinion, we need >>> more evidence that these fragments actually serve a useful purpose. >>> >>>> That aside, there's the proposal by Mark Andrews which would add yet >>>> another use case for these atomic fragments. >>> >>> Not really. It's a workaround so that stateless IPv6 services are >>> possible, despite this protocol weiredness. >> >> Not sure what you mean. > > Without the API change in draft-andrews-6man-force-fragmentation, it is > flat out impossible to server IPv6 traffic in a stateless fashion. The > stack is required to keep a per-destination cache which records the > necessity of a fragment extension header, even if the application never > sends any packets larger than 1280 bytes. The stack is required to have a Destination Cache, anyway. >> Sorry, I cannot see why some packets would require going through a >> translator, while others wouldn't. > > The joy of packet switching. 8-) If a packet is actually destined to the IPv4 world (and hence needs to go through a translator), it will need to cross one translator, or another... but *some* translator. >> That is, if the intended destination is really a v4 node, all packets >> meant to it will go through a translator, If it's not, none will. > > If the target is a v4 node, surely the network can just fragment as > needed, and reassemble using the v4 fragmentation information? That's > why I assumed the actual use case has to be more complicated (such as > translation back to v6). Then you'd need the translator to be stateful, such that it can selecct appropriate Identification values (i.e., not reuse them too quickly). > I'm attempting a reductio ad absurdum here---trying to show that for all > potential use cases of atomic fragments, there are much simpler > alternatives, and the remaining ones are utterly bizarre and not worth > supporting. We're not designing for the future. We're *currently* using/seeing atomic fragments. If you plan to ban them, that comes at the cost of breaking stuff. That aside, atomic fragments can be handled as safely as non-fragmented traffic: *that* was the motivation of the publication of draft-gont-6man-ipv6-atomic-fragments Thanks, -- 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 --------------------------------------------------------------------
