Geographic map of IPv6 availability

michael.dillon · October 3, 2007, 11:18pm

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.

Rik_van_Riel · October 5, 2007, 1:40pm

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?

Marshall_Eubanks3 · October 5, 2007, 1:43pm

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

Stephen_Wilcox1 · October 5, 2007, 2:18pm

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

michael.dillon · October 5, 2007, 3:12pm

Vint Cerf works for Google now, as does Harald Alvestrand. I
don't know if either are on NANOG, but both are certainly
appraochable.

vint@google.com and hta@google.com

Nathan_Ward · October 6, 2007, 2:12am

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.

Kevin_Loch2 · October 6, 2007, 3:38am

Nathan Ward 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

Kevin_Day · October 6, 2007, 4:53am

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

Stephen_Wilcox1 · October 6, 2007, 12:11pm

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

Peter_Karin_Dambier · October 6, 2007, 12:29pm

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:

Joe_Abley1 · October 6, 2007, 1:55pm

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

Stephen_Wilcox1 · October 6, 2007, 4:26pm

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

Joe_Abley1 · October 6, 2007, 4:33pm

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

Mark_Prior2 · October 7, 2007, 12:39pm

Kevin Loch wrote:

Has anyone who was using AAAA records for a site turned them off due to
reachability problems?

Not me but then again my MX also points at the AAAA so perhaps I'm not
getting the problem reports

Mark.

Tony_Hain · October 11, 2007, 8:43pm

Nathan Ward 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

Kevin_Loch2 · October 11, 2007, 9:58pm

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

Nathan_Ward · October 11, 2007, 9:58pm

Nathan Ward 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?