On Fri, 2 Apr 2010, 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, it does not rely on these assumptions. It does however rely on the following: 1) Good connectivity between the DNS resolving server and the DNS content server is easily quantifiable by both the service and content providers via a variety of techniques *PLUS* 2) good connectivity between client application host and DNS resolving server can be identified by the ISP recursive server being able to get DNS queries over IPv6 transport Those 2 combined are an excellent indicator of good connectivity between the client application host and the application server host. Ie, if the user can get to his dns server of ipv6, and the content provider determines that ipv6 connectivity between their network and the ISP network works correctly (which we can do -- this is what whitelisting is all about), then we are reasonably sure that the end-user will be able to get to the content service they want to get to over ipv6, w/o breaking anything. :: 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. Actually, I think it can: If the end user's 6to4 tunnel is "flakey", then the ipv6-transported DNS queries over said tunnel would fail, causing the user to try to resolve them over ipv4 transport, (I'm assuming the user would get both the v4 and the v6 ips of the dualstack recursors in this example), which should work just fine. This would then cause the recursive servers running this "hack" to only reply back with A records (since the query comes in over ipv4), therefore the client would work just fine. No? -igor -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
