On 01/05/2012 07:45 AM, Florian Weimer wrote: > Steinar wrote that atomic fragments break FreeBSD 7.4 (and there might > be others, of course). Not sending them breaks important transition > technology.
Looks like FreeBSD should patch. :-) >>> 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. The Destinations Cache is described in the IPv6 specs themselves (RFC4861?), and is not a requirement of PMTUD. Typically, if you maintain PMTUD information, you already have a PMTUD cache in place, and you'd sort of had to patch the kernel if you wanted to eliminate that. >>>> 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. Huh? If any packet of that communication instances crossed a translator is because it was an IPv6 packet destined to an IPv4 node (i.e., the packets is ultimately destined to an IPv4 address). That will remain true for the life of that communication instance. So if one packet needed a translator, so will the others. Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
