Florian, On 01/27/2012 09:14 AM, Florian Weimer wrote: >> On 01/27/2012 08:36 AM, Florian Weimer wrote: >>> And I see no functional difference between the gateway and the host >>> generating the fragment ID, except that the latter approach seems to >>> require network-wide software updates currently. >> >> Namely, are you saying that Linux won't react to an ICMPv6 PTB<1280 by >> inserting a Fragment Header in subsequent packets, or what? (last time I >> checked, I think this was the case) > > There are existing deployments which effectively filter ICMPv6 traffic.
They should know better.. what can I say? > Some of them do so explicitly, others simply to do not broadcast > incoming IPv6 ICMP traffic to all cluster nodes (or whatever it takes to > make this work with behind a per-packet load balancer). Naked host > behavior does not matter in such scenarios. How does this make a special case for atomic fragments? If they do this, they also break PMTUD -- not just the generation of atomic fragments. > As soon as IPv6 traffic levels increase, all busy UDP sources will stop > generating atomic fragments reliably because at the time of retry, the > fact that an atomic fragment is required has expired from the > destination cache (if there is one in the first place, that is). > That's why Mark proposes to send atomic fragments unconditionally > and *that* is known to break stuff for sure. Regarding Mark's proposal, yes, some stacks need to patch their bugs (this was required by RFC 2460, not by a brand new RFC). >> In any, please note the difference between *accepting* atomic fragments, >> generating ICMPv6 PTB when the MTU of the constricting link is < 1280, >> and reacting to ICMPv6 PTB by generating atomic fragments. > > True, but why would it be important to accept atomic fragments, when the > system as a whole does not actually generate them properly? So that you have only one bug instead of two? No kidding, as noted a a while ago, you can process atomic fragments as securely as non-fragmented traffic. So I don't understand why you're making a big deal. -- This is the sort of thing that, since you can do the right thing easily with no security implications, you simply do it. > I'm worried that we're imposing updates on significant parts of the > network to address an issue that could also be fixed locally, > maintaining full interoperability with the rest of the network as it > exists now. Not sure what you mean by "fixes locally". (That said, the cat is out of the bag, already -- there's stuff that depends on this). That said, I wouldn't call this an "update". I'd call this a bug fix... and you fix many of these, so... what's the big deal? 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 --------------------------------------------------------------------
