* Fernando Gont: > 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.
And the only way to achieve that reliably in certain existing deployments appears to be to send a fragment header unconditionally. (And with increasing IPv6 adoption, this will be only option for every large DNS operator---right now, PMTUD in the IPv6 stack appears to work because the number of clients is small compared to the size of the destination cache in the servers.) Steinar wrote that atomic fragments break FreeBSD 7.4 (and there might be others, of course). Not sending them breaks important transition technology. >> 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. Could you elaborate on that? For some operators, the ability to serve stateless protocols statelessly over IPv6 is quite important. I'm not aware of any fundamental requirement for per-destination bookkeeping in IPv6 nodes. >>> 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. Couldn't it be translated back to IPv6? Then there could be an IPv6-only path between sender and recipient. -- Florian Weimer <[email protected]> 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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
