nanog mailing list archives
Re: Geographic map of IPv6 availability
From: Nathan Ward <nanog () daork net>
Date: Fri, 12 Oct 2007 10:58:59 +1300
On 12/10/2007, at 9:43 AM, Tony Hain wrote:
Nathan Ward wrote:On 6/10/2007, at 3:18 AM, Stephen Wilcox wrote:<stuff> Given the above, I think there is no myth.. !That's because the 'v6 network' is broken enough that putting AAAA records on sites that need to be well reachable is a bad idea. For example, due mainly to Vista's 6to4 tunnelling stuff (based on researching a random sample of users), I'd lose about 4% of visitors to my web-sites if I were to turn on AAAA records. For a transit provider, having an unreachable (or seemingly unreachable) web-site is a really bad idea.So why didn't you put up a 6to4 router and put AAAA records in that pointedto the 6to4 prefix for those servers? Is the concept of multiple IPv6addresses on the server really as scary as people make it out to be? Afterall by having an IPv4 and an IPv6 address you already have multiple addresses on the server, so what is one more?
I have both 6to4 and Teredo relays available to all my servers, let me explain;
(sorry to those who've read me talking about this already)The problem is "enterprise" networks that have /all/ of the following conditions as true:
- Use non-RFC1918 addressing for hosts. - Do firewalling (and block IP proto 41) or NAT. - Use Windows Vista and have not disabled 6to4. Some common examples: - Large companies.- Educational institutions (especially ones where people bring their own laptops - Vista configs can't be dictated).
Solutions: 1) These networks deploy 6to4 relays. 2) These networks deploy IPv6 natively.3) These networks deploy 'fake' 6to4 relays which return unreachable messages when someone tries to use them, so packets don't time out. 4) Everyone else figures out a standard to to test the availability of 6to4 services (not unlike Teredo's qualification procedure).
I think that (4) is probably the path of least resistance, so I intend to do some work in that area.
The entire finger-pointing fiasco between the infrastructure providers and the content providers has to stop. The content providers just have to ignore the lethargic infrastructure providers and tunnel over them. Tunneling IPv4over voice is how we got around the lethargy before, so now the onlydifference is we are tunneling IPv6 over IPv4. I hear whining from content providers about how 6to4, or tunneling in general, is bad because the path is not predictable. They never stop to realize that they could avoid that problem by putting up their own tunnel endpoint and through the magic of DNS completely avoid the problem they are complaining about. The only reason clients will look for a public 6to4 relay is to find sites that insist on having a single IPv6 address from a formal RIR IPv6 assignment process. In the grand scheme of things the 6to4 prefix that would correspond to your 6to4 router is formally assigned, it is just through the IPv4 assignment process. In any case a 6to4 connected client will traverse the direct IPv4 path to the server's 6to4 router, so as I said earlier if content providers would just ignore the infrastructure and deploy their own 6to4 routers totunnel over the top, we could move forward.
As both a an infrastructure and content provider (I have many different hats), I point at Microsoft Vista - I appreciate the initiative, but problems like this have (in my view) had a net negative effect.
Nice rant though :-)What is your suggestion RE DNS there? Are you proposing using views or something, to direct 6to4 'clients' to content over 6to4? If so, I don't think that would work terribly well - it wouldn't solve the problem in situations I describe above, but it's likely that it would improve performance for networks who choose to run 6to4, and have their own recursive resolvers who live in their v6 island.
Does anyone have info on how bind (and other recursive resolvers) select whether to use v6 or v4 if an NS points at a resource with both A and AAAA records? Most OSes prefer the AAAA record, does bind behave the same?
-- Nathan Ward
Current thread:
- Re: Geographic map of IPv6 availability, (continued)
- Re: Geographic map of IPv6 availability Kevin Loch (Oct 05)
- Re: Geographic map of IPv6 availability Kevin Day (Oct 05)
- Re: Geographic map of IPv6 availability Stephen Wilcox (Oct 06)
- Re: Geographic map of IPv6 availability Peter Dambier (Oct 06)
- Re: Geographic map of IPv6 availability Joe Abley (Oct 06)
- Re: Geographic map of IPv6 availability Stephen Wilcox (Oct 06)
- Re: Geographic map of IPv6 availability Joe Abley (Oct 06)
- Re: Geographic map of IPv6 availability Mark Prior (Oct 07)
- RE: Geographic map of IPv6 availability Tony Hain (Oct 11)
- Re: Geographic map of IPv6 availability Kevin Loch (Oct 11)
- Re: Geographic map of IPv6 availability Nathan Ward (Oct 11)
- Re: Geographic map of IPv6 availability Martin Hannigan (Oct 14)
- Re: Geographic map of IPv6 availability Iljitsch van Beijnum (Oct 14)
- Re: Geographic map of IPv6 availability JORDI PALET MARTINEZ (Oct 14)
- Re: Geographic map of IPv6 availability Martin Hannigan (Oct 15)
- Re: Geographic map of IPv6 availability Nathan Ward (Oct 15)
- Re: Geographic map of IPv6 availability Iljitsch van Beijnum (Oct 15)
- Re: Geographic map of IPv6 availability Mark Andrews (Oct 15)
- Re: Geographic map of IPv6 availability Martin Hannigan (Oct 15)
- Re: Geographic map of IPv6 availability Mark Andrews (Oct 15)