On 04/02/2010 11:11 AM, james woodyatt wrote: > On Apr 2, 2010, at 08:16, Brian E Carpenter wrote: >> >> I do think that Google's solution to this, i.e. being selective >> about who gets the AAAA records in the first place, is much less of >> a hack, with less harmful side effects. > > While everyone else was in the 6MAN session, I was actually jumping > back and forth between 6MAN and DNSOP because I didn't want to miss > this presentation. As I pointed out at the microphone in DNSOP, the > proposed hack is absolutely broken because it relies on a pair of > TOTALLY INOPERATIVE ASSUMPTIONS: > > A) good IPv6 connectivity between the DNS resolving server and the > DNS content server implies good IPv6 connectivity between the client > application host and the application server host. > > B) good IPv6 connectivity between the client application host and the > application server host requires good IPv6 connectivity between the > DNS resolving server and the DNS content server.
actually they don't rest on those assumptions. the assumption being made is that queriers who are customers of a given set of name-servers have available to them a particular kind of connectivity... this is exactly the same kind of assumption made when selectively returning different A records in an ipv4 global loading balancing setup. The consequences of getting it wrong in ipv4 are you go to a more distant instance of a service. The consequence of getting it wrong in ipv6 are you hand a AAAA record to a host that doesn't use it (this causes no harm) or you hand a AAAA record to host that shouldn't use it (because soemthing about their connectivity is broken). presumably the decision to make a particular set of queriers as blessed for the purpose of reciveing AAAA records is based on a judgement about the likelyhood of the hosts behind that resolver being non-broken. > The obvious illustration that comes to mind is a host behind an Apple > AirPort Extreme base station at a public IPv4 address and configured > in 6to4 tunnel mode, but in a domain where the 6to4 relay service is > unreliable, badly-impaired or black-holed, and also configured to > forward its DNS queries to resolving servers that are dual-stack > IPv4/IPv6 capable. This configuration is sufficiently common that > any proposed solution to the problem must have an answer for it, and > the proposed solution doesn't deal with it at all. > > Shorter james: the proposed hack cannot solve the problem it intends > to solve, and it breaks other networks that work fine today. It > should not be endorsed. > > > -- james woodyatt <[email protected]> member of technical staff, > communications engineering > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
