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.)
Apple's Mail is not RFC 1123 compliant then. I seriously
doubt that Apple can produce the design documentation that
proves that they even thought about this. If they can I'd
like to see the justification. It would be a interesting
read.
* "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and the case carefully weighed before choosing
a different course.
2. GENERAL ISSUES
[snip]
2.3 Applications on Multihomed hosts
When the remote host is multihomed, the name-to-address
translation will return a list of alternative IP addresses. As
specified in Section 6.1.3.4, this list should be in order of
decreasing preference. Application protocol implementations
SHOULD be prepared to try multiple addresses from the list until
success is obtained. More specific requirements for SMTP are
given in Section 5.3.4.
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.
And the longer people leave it the more likely it is that
the service will be swamped as more and more clients have
IPv6 transports.
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.
No. There is no such requirement. Just make sure the
server sends ICMP or RST. The client should move on
to the next address after one RTT.
UDP based applications may be more problematic but not
always.
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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf