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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf