In your letter dated Tue, 31 Jan 2012 15:58:55 -0300 you wrote: >On 01/31/2012 08:12 AM, Philip Homburg wrote: >> "Such traffic absolutely occurs in the wild. I have three reasonably >> busy name servers where this is logged as an error from the ipfw code, >> e.g." >> >> Inconclusive. We don't know why that traffic is there. >> >> So, just remove that requirement from RFC-2460, and the problem is gone. > >If you're meaning to remove support for some feature from the standard >on the basis that it is not used, then the *you* should prove that is >not being used.
I'm not claiming that it is not used. The Internet is a very big place, proving a negative is almost impossible. One issue is, are atomic fragments used for anything other than stateless IPv6/IPv4 translators? Unless I misunderstood you, you claimed there was such usage. I can't find the message you were referring to, so I asked you for a message ID. Instead you gave examples from another area, that seems consistent with stateless translators. The second issue is that in my opinion, sending atomic fragments to such translators is a bad idea and should be deprecated. Assuming there is no other use for atomic fragments, that implies to me that we should not spend any time making it work better. Just let it die off. Why is sending atomic fragments to translators a bad idea? Because the whole IPv6 Internet has to support it (and will suffer the effects) and the use is extremely limited. There is some benefit when: - The path between the translator and the IPv4 host has an mtu of less then 1280, - and there is a one to one correspondance between IPv4 and IPv6 addresses (so using it in a traditional NAT context doesn't work) - and the data flow from any IPv6 host to the IPv4 host does not exceed 20 Mbit/s - and the IPv6 host maintains a strict counter in the lower 16-bit of the fragment ID. If any of those conditions are not met then either atomic fragments are not needed, or having the translator generate the id in the IPv4 header is just as good. >I personally believe it is very dangerous to think about removing >something without bothering to consider what might break, and without >bothering whether there's stuff (such as translators) that depend on >that feature. > >Fix the bug, and be done with it. I'm not saying that any existing support has to be removed. Just let it be. But fully supporting atomic fragments everywhere will have a lot of impact, and that is in my opinion not worth the effort. So it best to stop now. And not create any additional standards or recommendations on how to deal with or generate atomic fragments. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
