* Fernando Gont: > Hello, Florian, > > On 12/20/2011 07:00 AM, Florian Weimer wrote: >>> ---- cut here ---- >>> IPv6 allows packets to contain a Fragment Header, without the packet >>> being actually fragmented into multiple pieces. Such packets >>> typically result from hosts that have received an ICMPv6 "Packet Too >>> Big" error message that advertises a "Next-Hop MTU" smaller than 1280 >>> bytes, and are currently processed by hosts as "fragmented >>> traffic". >> >> Does such traffic actually occur in the wild, or would it only be used >> in attacks? > > They have been seen in the wild.
Yuck. > 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. 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. >> Per previous WG discussion, when reassembling such atomic fragments, I think I meant to write "any fragments". >> IPv6 implementations must ignore the upper 16 bits of the fragment ID >> (otherwise the stateless v4/v6 gateways won't work). Clearly, this is >> not desirable. > > 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. -- Florian Weimer <fwei...@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
