On Mar 29, 2011, at 1:21 AM, Wil Schultz wrote: > So far the consensus is to run dual stack natively. > > While this definitely is the way things should be set up in the end, I can > see some valid reasons to run ipv4 and ipv6 on separate domains for a while > before final configuration. For example, if I'm in an area with poor ipv6 > connectivity I'd like to be given the option of explicitly going to an ipv4 > site vs the ipv6 version. > > I'd also like to not damage SEO in the process though. ;-)
There has been a discussion of this in v6ops, around http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications "IPv6 AAAA DNS Whitelisting Implications", Jason Livingood, 22-Feb-11 and http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs "Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts", Dan Wing, Andrew Yourtchenko, 14-Mar-11 In that context, you might review http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf Where you find a name ipv6.example.com, such as ipv6.google.com and www.v6.facebook.com, it is generally a place where the service is testing the IPv6 configuration prior to listing both the A and the AAAA record under the same name. The up side of giving them the same name is that the same content is viewable using IPv4 and IPv6; being IP-agnostic is a good thing. Unfortunately, at least right now, there is a side-effect. The side-effect is that a temporary network problem (routing loop etc) on one technology can be fixed by using the other, and the browsers don't necessarily fall back as one would wish. This works negatively against IPv6 deployment and customer satisfaction; it is not unusual for tech support people to respond to such questions with "turn off IPv6 and you won't have that problem". Hence, content providers often separate the names to ensure that people only get the IPv6 experience if they expect it. And Google among others whitelists people for IPv6 DNS service based on their measurements of the client's path to google - if a bad experience is likely, they try to prevent it by not offering IPv6 names. In general, I don't see a lot of difference between A and AAAA accesses, but I have had glitches when there was a network glitch. On one occasion, there was an IPv6 routing loop en route to www.ietf.org, but not one on the IPv4 path. The net result was a huge delay - it took nearly two minutes to download a page. The amusing part of that was that the same routing loop got in the way of reporting the issue to HE; I wound up sending an email rather than filing a case. Once it was fixed, matters returned to normal.
