Geographic map of IPv6 availability
Has anyone seen a map showing geographic availability of IPv6 in North America like this Russian example? http://www.ipv6.ru/russian/history/map/map.php If you click on the cities they are mostly showing State Universities, but something that showed both R&E and commercial operators separately with some kind of color coding (temperature?) for the number of organizations offering the service, would be interesting to follow progress over the next two to three years. It's one way to debunk the myth that IPv6 is really hard to find. ------------------------------------------------------- Michael Dillon RadianzNet Capacity Management -- BT Design 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon@bt.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com One Community One Connection One Focus
On Thu, 4 Oct 2007 00:18:34 +0100 <michael.dillon@bt.com> wrote:
It's one way to debunk the myth that IPv6 is really hard to find.
I just realized that IPv6 web sites are not being indexed by Google. That would make IPv6 content really hard to find. What can we do about that? Any Google people on NANOG? -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Vint Cerf works for Google now, as does Harald Alvestrand. I don't know if either are on NANOG, but both are certainly appraochable. Regards Marshall On Oct 5, 2007, at 9:40 AM, Rik van Riel wrote:
On Thu, 4 Oct 2007 00:18:34 +0100 <michael.dillon@bt.com> wrote:
It's one way to debunk the myth that IPv6 is really hard to find.
I just realized that IPv6 web sites are not being indexed by Google. That would make IPv6 content really hard to find.
What can we do about that? Any Google people on NANOG?
-- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
On 4 Oct 2007, at 00:18, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
Has anyone seen a map showing geographic availability of IPv6 in North America like this Russian example?
http://www.ipv6.ru/russian/history/map/map.php
If you click on the cities they are mostly showing State Universities, but something that showed both R&E and commercial operators separately with some kind of color coding (temperature?) for the number of organizations offering the service, would be interesting to follow progress over the next two to three years.
It's one way to debunk the myth that IPv6 is really hard to find.
the best way to debunk the 'myth' would be to find some let me see now how about content, lets do some AAAA lookups: Google - no Microsoft - no Yahoo - no YouTube - no Facebook - no well, maybe that'll follow.. lets look for a v6 provider here in the UK: VirginMedia cable - no BT ADSL - no Pipex ADSL - no Tiscali ADSL - no Talktalk ADSL - no I see some carriers can provide me v6 transit or peering, typically its bundled with their v4 offerings or at a reduced rate but other than being part of the 'v6 backbone' what exactly can i get to? Given the above, I think there is no myth.. ! Steve
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. -- Nathan Ward
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.
Has anyone who was using AAAA records for a site turned them off due to reachability problems? - Kevin
On Oct 5, 2007, at 10:38 PM, Kevin Loch 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.
Has anyone who was using AAAA records for a site turned them off due to reachability problems?
Yes. We tried it on one of our client's rather high profile sites and had to turn it off because of exactly that problem. We found a few friendly tech savvy users who were experiencing the problem and followed up with them the best we could. The reasons for the problems were: Some had inadvertently enabled 6to4 (one admitted remembering playing with it after reading about it on slashdot, then forgot about it). Some had installed one vendor's firewall that was trying to be proactive and firewall v6 things as well. We never determined if this was default behavior or not, but if you checked the "Firewall v6 traffic" box, it enabled the whole v6 stack just so that it could firewall it. Some we were never able to figure out why it broke connectivity for them. Theories about transparent proxies doing the wrong thing, broken resolvers or other issues floated up, but we could never pin them down. It definitely wasn't in the order of entire percentage points of users being unable to access the site, but it was a non-zero number and enough to make the site owner want the AAAA records pulled. I talked about this briefly at http://www.ipv6experiment.com and it's one of the things we plan on trying to measure when we finally get it up and running. -- Kevin
On 6 Oct 2007, at 05:53, Kevin Day wrote:
On Oct 5, 2007, at 10:38 PM, Kevin Loch 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.
Has anyone who was using AAAA records for a site turned them off due to reachability problems?
Yes. We tried it on one of our client's rather high profile sites and had to turn it off because of exactly that problem.
Ditto, we started enabling v6 a few years ago and tried dual stacking some servers including DNS and www .. we noticed that hosts were doing DNS lookups over v4 that would yield AAAA results to v6 addresses they could not reach and they preferred AAAA over A so the end user experienced a mysterious hang then a timeout error Steve
Have a look at IO ~> dig -t any IO @a.nic.IO. ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.4.0b4 <<>> -t any IO @a.nic.IO. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63841 ;; flags: qr aa rd; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 7 ;; QUESTION SECTION: ;IO. IN ANY ;; ANSWER SECTION: IO. 604800 IN SOA ns.nic.IO. nicadmin.nic.IO. 2007100602 43200 3600 3600000 86400 IO. 604800 IN NS b.nic.ac. IO. 604800 IN NS b.nic.IO. IO. 604800 IN NS b.ns13.net. IO. 604800 IN NS ns1.communitydns.net. IO. 604800 IN NS ns3.icb.co.uk. IO. 604800 IN NS a.nic.IO. IO. 604800 IN NS a.ns13.net. ;; ADDITIONAL SECTION: a.nic.IO. 3600 IN A 64.251.31.179 b.nic.ac. 3600 IN A 217.160.203.158 b.nic.IO. 3600 IN A 66.235.201.216 ns1.communitydns.net. 3600 IN A 194.0.1.1 ns3.icb.co.uk. 3600 IN A 217.199.188.61 ns3.icb.co.uk. 3600 IN AAAA 2001:628:453:430c:230:48ff:fe42:60f ;; Query time: 231 msec ;; SERVER: 64.251.31.179#53(64.251.31.179) ;; WHEN: Sat Oct 6 14:19:41 2007 ;; MSG SIZE rcvd: 884 (sorry I had to clip a bit) Now look at the root-servers: ; <<>> DiG 9.4.0b4 <<>> -t any IO @a.root-servers.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31250 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 8 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;IO. IN ANY ;; AUTHORITY SECTION: IO. 172800 IN NS B.NS13.NET. IO. 172800 IN NS NS1.COMMUNITYDNS.NET. IO. 172800 IN NS NS3.ICB.CO.UK. IO. 172800 IN NS A.NIC.IO. IO. 172800 IN NS A.NS13.NET. IO. 172800 IN NS B.NIC.AC. IO. 172800 IN NS B.NIC.IO. IO. 172800 IN NS B.NIC.SH. ;; ADDITIONAL SECTION: A.NIC.IO. 172800 IN A 64.251.31.179 A.NS13.NET. 172800 IN A 202.181.97.168 B.NIC.AC. 172800 IN A 217.160.203.158 B.NIC.IO. 172800 IN A 66.235.201.216 B.NIC.SH. 172800 IN A 216.117.156.206 B.NS13.NET. 172800 IN A 202.181.96.60 NS1.COMMUNITYDNS.NET. 172800 IN A 194.0.1.1 NS3.ICB.CO.UK. 172800 IN A 217.199.188.61 ;; Query time: 144 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Sat Oct 6 14:23:27 2007 ;; MSG SIZE rcvd: 326 The IPv6 is gone. On my own boxes I had problems to reach sites that had both IPv6 and IPv4 addresses for one and the same server until I unplucked the IPv6 stack. My problem was there were nonconnected IPv6 islands that could not see each other. Kevin Loch 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.
Has anyone who was using AAAA records for a site turned them off due to reachability problems?
- Kevin
-- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.arl.pirates http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
On 6-Oct-2007, at 0829, Peter Dambier wrote:
The IPv6 is gone.
It's not unusual for the delegation NS set and the apex NS set to be different. This is not a phenomenon which is isolated to delegations from the root. The missing AAAA glue in the root zone seems more like just another example of this, rather than something insidiously IPv6- specific. I'm not suggesting this state of affairs is good, but it's certainly not unusual. Joe
On 6 Oct 2007, at 14:55, Joe Abley wrote:
On 6-Oct-2007, at 0829, Peter Dambier wrote:
The IPv6 is gone.
It's not unusual for the delegation NS set and the apex NS set to be different. This is not a phenomenon which is isolated to delegations from the root. The missing AAAA glue in the root zone seems more like just another example of this, rather than something insidiously IPv6-specific.
I'm not suggesting this state of affairs is good, but it's certainly not unusual.
But it highlights the lack of v6 support in the root... OOI Do you know the status of v6 in the root and gtlds (delegations, glue and the root IPv6s themselves?) Steve
On 6-Oct-2007, at 1226, Stephen Wilcox wrote:
But it highlights the lack of v6 support in the root...
Actually, no. There's lots of IPv6 glue in the root zone. Not as much as IPv4 glue, to be sure, but it's most certainly there: [calamari:~]% dig @192.5.5.241 . axfr | grep -c AAAA 102 [calamari:~]% What's missing (for those who hanker after a DNS that works as intended with v6-only clients) is AAAA glue for *.ROOT-SERVERS.NET.
OOI Do you know the status of v6 in the root and gtlds (delegations, glue and the root IPv6s themselves?)
Many TLDs are served by nameservers which are reachable over IPv6. I don't know how many TLD registries support IPv6 glue. Several root servers are reachable over IPv6. There are no AAAA records in the ROOT-SERVERS.NET zone. Many of those questions are answerable directly by looking in the DNS. Joe
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 pointed to the 6to4 prefix for those servers? Is the concept of multiple IPv6 addresses on the server really as scary as people make it out to be? After all by having an IPv4 and an IPv6 address you already have multiple addresses on the server, so what is one more? 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 IPv4 over voice is how we got around the lethargy before, so now the only difference 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 to tunnel over the top, we could move forward. Eventually the carriers will figure out that their customers have moved on without them, and they will grudgingly come to the party. Tony
Tony Hain wrote:
Nathan Ward wrote:
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.
So why didn't you put up a 6to4 router and put AAAA records in that pointed to the 6to4 prefix for those servers?
That would not help situations where a client has 6to4 enabled (and a non rfc1918 address) and is behind a firewall that doesn't support or filters proto 41. At least Teredo detects whether or not it will work before enabling the interface. In a perfect world people would fix the routing or filtering issue. In reality if it only affects a few sites the typical end user won't think it's their problem. - Kevin
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 pointed to the 6to4 prefix for those servers? Is the concept of multiple IPv6 addresses on the server really as scary as people make it out to be? After all 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 IPv4 over voice is how we got around the lethargy before, so now the only difference 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 to tunnel 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
participants (11)
-
Joe Abley -
Kevin Day -
Kevin Loch -
Mark Prior -
Marshall Eubanks -
michael.dillon＠bt.com -
Nathan Ward -
Peter Dambier -
Rik van Riel -
Stephen Wilcox -
Tony Hain