the IETF has refused to adopt the DISCOVER opcode for the DNS - which pretty much handles this problem. Others may have developed other techniques. --bill > > 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@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 mailing list > >Ietf@xxxxxxxx > >https://www1.ietf.org/mailman/listinfo/ietf > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf