Hi, Florian, On 12/23/2011 07:46 AM, Florian Weimer wrote: >> That aside, I don't know whether e.g. NAT64 or the like used this >> (.e.g, whether they are used for transition technologies as envisioned >> in RFC 2460). However, it might also be the case that such "atomic >> fragments" are generated when communicating through networks that do >> 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? > 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. >> I may be missing something, but: when sending from the v6 side to the v4 >> side, we can probably assume that only the low order 16 bits of the >> Fragment Identification field are used (whether you set the rest of the >> bits or not, it doesn't matter -- particularly if the Fragment >> Identification for each destination is a linear function (as e.g. in the >> algorithm proposed in the I-D)). That is, you don't really need to do >> anything special with the high order bits. > > Actually, atomic fragments aren't the problem, but the technology that > serves as a justification for them. If there are sub-1280 links which > require network fragmentation and which fail to preserve the entire > fragment ID, this happen to a packet which has already been fragmented > by the sending host: One fragment is delivered over a regular IPv6 link > and not fragmented further. Another fragment is sent over a different > link involving some v4 transition technology, causing further > fragmentation and loss of the upper 16 bit of the fragment id. The > receiving node can reassemble the original packet only if it disregards > the upper 16 bits in all those fragments. Sorry, I cannot see why some packets would require going through a translator, while others wouldn't. 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. Am I missing something? 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 --------------------------------------------------------------------
