John,
Excuse front-posting but it probably works better than
interstitial comments for what I want to say.
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.
It's also running code for Java 1.5 and up. (In both
cases, the host needs a dual stack supporting RFC 3484.)
In fact it's running code for any properly ported
application. But it does need some logic on top of
the getaddrinfo() call.
Note that this set of preferences would apply *after*
any set of preferences applied at the FQDN level, e.g.
after MX preferences have been applied.
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.
There's an operational fly in the ointment if the
DNS returns an AAAA record but no path exists to that
address; unfortunately we still have such issues
(exactly as we did for some A records 15 or 20 years ago).
In that case the client host would need to try all IPv6
addresses in sequence, followed by all IPv4 addresses in
sequence, until something works. That's more logic on top
of the socket API.
As Phill H-B has implied more than once, there's scope
for a library on top of the socket API that takes care
of this once and for all. Does anyone have such a library?
Brian
On 2008-01-06 03:45, John C Klensin wrote:
--On Saturday, 05 January, 2008 22:08 +1200 Franck Martin
<franck(_at_)sopac(_dot_)org> wrote:
Seems to me that DNS software at the customer level should be
able to respond to the applications immediately from the
cache: switch from IPv6 to IPv4 because I have IPv4 info.
The standard behavior would be query with IPv6 the network
DNS, and if they answer with IPv6 info, carry on, if they
answer no info return error, or they answer switch to IPv4
because I have IPv4 info to give you.
Would that simplify the life of IPv6 applications?
As long as the application gets back exactly one address from
whatever query process it uses, it is presumably happy. If it
gets back zero addresses, it may not be happy, but it knows
exactly what to do.
The problems arise in (at least) the following cases:
(i) The application must choose whether to query for IPv4
records, or for IPv6 records, or both. Your scenario assumes
that it will ask for IPv6 records first and stop if it finds
one, but it might choose to ask for IPv4 ones anyway or to
prefer IPv4 connections if those were available.
(ii) If the application gets multiple address records back
(IPv6, IPv4, or a mixture), it must select which one to use.
This is not a new problem but dates back to roughly the point at
which we discovered how to make machines with multiple
interfaces. It got much worse when we started connecting
networks to each other with routers, rather than hosts to
networks because, in the latter case, the requisite routing
preference information was at least available on the local host.
With hosts connected to LANs that terminate in one or more
router, the routing preference information is typically not even
available on the same host as the application that is called on
to make the decision. IPv6 obviously adds a layer of
complexity, since, all of things being equal, one would probably
prefer an IPvX path to a host that did not involve address
translation to an IPvY path that did and _that_ information is
typically not even available to the routing system. And, of
course, if one has no support (either on the local host or
between it and the first-hop router) for IPvX, then IPvY is
obviously preferred regardless of other considerations.
(iii) MX RRs, and to some considerable extent SRV RRs, which do
permit expressing some preference information at the application
layer, raise some additional complications about configuration
if not present and carefully organized. In addition to the one
that I mentioned in starting this thread, the preference levels
reflect information available to the server and, presumably,
preferences from the server's perspective. They cannot reflect
preferences from the perspective of the client or its network
connectivity. One can easily configure oneself into a large
mess and, as I pointed out in an earlier not, we have offered
little advice about how to deal with that problem.
This is complicated by a more general problem with MX records:
the model assumes that all of the listed hosts will have the
same capabilities other than simple reachability (or not). When
the spec was written, that was reasonable because we didn't have
a mechanism for different hosts advertising different
capabilities. I'm on the hook for doing a writeup on that
subject, but doing so is backed up behind other work (and, in
particular, getting 2821bis into Last Call).
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf