On 6 jan 2008, at 11:21, John C Klensin wrote:
The basic theory is supposed to be that faced with a mixture of A and AAAA responses, the host will by default prefer IPv6 and by default use RFC 3484 to choose among multiple IPv6 addresses. As far as I know, that's running code for many SMTP servers.
But, in general, SMTP servers don't choose addresses. SMTP clients do. The number of them that are 3484-compliant is not, in my experience, large
Not sure what you mean here by "SMTP clients"... Would that be client computers such as the one I'm typing this message on? But those don't look at MX records, unless I'm very much mistaken.
However, it's not the applications that have to be aware of RFC 3484, but the OS. The only thing the application needs to do is use a network API that supports IPv6 and the OS will take care of selecting a list of appropriate addresses and try to order them in descending order of preference. (For instance, Apple's Mail can work over IPv6 but it only tries the first address so if there is non-working IPv6 I can't get at my mail.)
As far as the default IPv6 preference is concerned, trying something, waiting for it to get a "not reachable" or, much worse, time out, and then trying something else takes sufficiently long that, until IPv6 reaches some critical mass, configuring a 3484 sequence to prefer IPv6 in a production environment just doesn't make a lot of sense right now.
No, the part that doesn't make sense is enabling IPv6 but then preferring IPv4. That way, you don't get to find out what works and what doesn't work. It is true that enabling (and thus preferring) IPv6 can have downsides. In my case it means the IETF website is excruciatingly slow because there doesn't seem to be any routing from the IETF to my ISP's IPv6 addresses. This is something that doesn't generate ICMP errors for me so I have to suffer TCP timeouts and fallback to IPv4. But fortunately, this type of issue is rare these days. However, operators aren't yet as responsive to these issues as they are to IPv4 reachability problems.
It's also obviously that case that if an FQDN has both A and AAAA records, all applications servers reached at those addresses must support IPv4 and IPv6 respectively. No exceptions.
It may obviously be the case, but the implication of this is that I dare not put an AAAA record up for a host that serves out several protocols until all of those protocols are IPv6-ready.
That's just silly. You can create different names where one has only IPv4 and one also has IPv6.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf