--On Saturday, 05 January, 2008 22:08 +1200 Franck Martin
<franck@xxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf