* Fernando Gont: >> 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. >> 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, and you really, really need to support them. Generating conforming packets just isn't sufficient here, the recipient must actually be able to process them. 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. But this is an insane amount of complexity for very little gain. >> 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. So the gateways will need those local workarounds anyway, otherwise they will have trouble using DNS over IPv6. > 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. > 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. -- 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 --------------------------------------------------------------------
