Florian, On 01/28/2012 11:26 AM, Florian Weimer wrote: >>> There are existing deployments which effectively filter ICMPv6 traffic. >> >> They should know better.. what can I say? > > These people generally know what they are doing.
TCP relies on PMTUD, so how can you possibly state that "they know what they are doing"? Those are generally the same people that broke IPv4's PMTUD, that lead to non-working 6to4 and Teredo, etc. I have seen quite a few of those hard-to-debug issues which ended up in the culprits removing the filters that they had. >>> 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. > > Currently, you can set DF=0 on IPv4 packets you sent, and fragment IPv6 > at 1280 bytes. Then you don't need to implement PMTUD. > > If you want to deal with atomic fragments in the same way, you have to > add a fragment header to all outgoing packets smaller than 1280 bytes, > creating atomic fragments. However, this doesn't work on the current > network because there are nodes which cannot process atomic fragments, There are many bugs in current IPv6 implementations, and there are many more to be found, because most of them are still very immature. If you take the stance of "we know of a buggy implementation that does not support this, and hence this mechanism is forbidden", I wonder where we'd end up. Fix the bug, and move on. > You can work around that by broadcasting incoming ICMP packets > internally and provision a large enough destination cache on every node, > as I said before. B Or just use the setsockopt() that Mark proposed if you're not going to rely on PMTUD. >>> 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? > > Well, I think the gateway issue is actually fixable (because it's > local). Pervasive atomic fragment support requires kernel, client and > server software updates in a certain order, something which is unlikely > to happen soon. It is unlikely to happen as long as people invest more time in arguing in favour of bugs, rather than in fixing them. Look at OpenBSD's patch. They did it in a couple of days. That said, nobody is *introducing* atomic fragments.They should have been supported for more than 15 years, and there is other stuff (mentioned by Dan Wing at others) that would break without this. My I-D is about improving their handling... not about introducing support of atomic fragments to the IPv6 world. >> No kidding, as noted a a while ago, you can process atomic fragments as >> securely as non-fragmented traffic. > > Except when you need to drop traffic with extension headers. From time > to time, there are compelling reasons to do this. There are times in which you also need to drop TCP traffic. SHould we ban TCP, too? >> 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? > > I think it's misleading to publish an RFC which implicitly suggests that > atomic fragments work on the current network, or somehow can be made to > work. It doesn't imply anything. It just improves the handling of such packets when compared with the current specs. That's it. If you think the document should note that some systems do not support this packets, or the like, I'd have no problem in doing so. For instance, I will try to include a list of working vs. broken implementations in the next rev of the I-D, and also note which ones implement the proposed behaviour. 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 --------------------------------------------------------------------
