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. 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 --------------------------------------------------------------------
