IPv6 Connectivity Saga (part n+1)

Mailman List Mirror (Read Only)
1

I took a DMOZ[1] dump, extracted all unique domain-name port combinations
and checked their IPv6 connectivity.

3 388 012 : 100.000% : total
3 260 296 : 96.230% : IPv4 only
  122 560 : 3.620% : bad NS
    3 372 : 0.100% : IPv6 working
    1 694 : 0.050% : broken or "fake" IPv6

broken: TCP connect failed
fake: IPv6 mapped IPv4 addresses (e.g. ::ffff:1.2.3.4)

33.4% of all services that advertised IPv6 failed to deliver or in
other words the IPv6 failure rate is ten times the NS failure rate.

Seems high, thus a cross check via TLDs' NS:

270 : 100.0% : TLD total (excluding the IDN tests)
268 : 99.3% : IPv4 working
  2 : 0.7% : IPv4 broken (HM and KP)
177 : 65.6% : IPv6 working
  8 : 3.0% : IPv6 broken

1910 : 100.0% : NS total
1500 : 78.5% : IPv4 only
  31 : 1.6% : IPv4 broken
356 : 19.1% : IPv6 working
  23 : 1.2% : IPv6 broken

IPv6 failure rates of 4.3% (TLD) and 6.1% (NS) is lower than the above
33.4% but are still significantly higher than the IPv4 failure rates of
0.7% (TLD) and 1.6% (NS). TLD root-NSs usually are managed by dedicated
infrastructure organisations thus better trouble shooting than the DMOZ
listed ones get is expected and suggests the above 33.4% failure rate
isn't some kind of sampling artifact.

About 4 days later I did a more detailed check of the hosts with
broken IPv6:

1624 : hosts total
827 : connection timed out
382 : no route to host
249 : connection refused
  95 : network unreachable
  54 : SixXS never received a route announcement for that block
  43 : broadcast address
  30 : * IPv4 in IPv6
  22 : IPv6 assignments reclaimed (3ffe::/16)
  16 : * no IPv6 (::slight_smile:
  12 : * IPv4 only
  10 : * IPv6 working
   4 : IPv6 never assigned
   4 : local (fe80::/10)
   2 : local (::1)
   2 : broken NS

Issues(cases not marked with a star) do tend to arise
but why are fundamental issues like "connection timed out",
"no route to host" and "connection refused" so frequent?

(testing was done from 2a01:4d0:102::31)

Thomas

[1] http://www.dmoz.org/help/getdata.html

2

I took a DMOZ[1] dump

What's a DMOZ dump?

33.4% of all services that advertised IPv6 failed to deliver or in
other words the IPv6 failure rate is ten times the NS failure rate.

"failing to deliver" is not necessarily a failure condition, in my opinion.

IPv6 failure rates of 4.3% (TLD) and 6.1% (NS)

What does TLD and NS mean?

About 4 days later I did a more detailed check of the hosts with
broken IPv6:

1624 : hosts total
827 : connection timed out

That would be bad.

382 : no route to host

Not quite as bad, but also not good.

249 : connection refused

Although it would be better to avoid this condition, I wouldn't count it as a failure. This typically happens when a host has an IPv6 address in the DNS, but a service isn't reachable over IPv6. Since reasonable implementations will retry over IPv4 after a round trip, this doesn't cause any real trouble.

43 : broadcast address

?

22 : IPv6 assignments reclaimed (3ffe::/16)

Which shows that installing IPv6 (or anything, really) is pretty much "install and forget", which goes to the "use it or lose it" doctrine: only services that are actually used will remain operational.

Issues(cases not marked with a star) do tend to arise
but why are fundamental issues like "connection timed out",
"no route to host" and "connection refused" so frequent?

Like I said: if something isn't used, it doesn't get fixed if it doesn't work. Interestingly, if something new is set up incorrectly and then someone comes along who wants to use the new option, and it doesn't work, the blame is laid at the person who decided to use the new option, rather than the person who offered a service over it but didn't make sure it worked correctly.

I've been downloading files from the FTP servers of the five RIRs a few times a week for several years now. I haven't kept track of it, but it seems that it's gotten harder to reach these FTP servers over IPv6 the past year or so. This could very well have something to do with IPv6 becoming more mainstream, so it's no longer some experimental thing that can be enabled without trouble, but a production service that must be firewalled. This seems to be the source of much trouble, especially with ARIN, which I can't successfully reach over IPv6 anymore, probably because of a routing issue between their and my ISPs. But before that, I had path MTU problems towards them on several occasions.

Another factor is that with IPv4, you need to be pragmatic, because if you don't, you have no connectivity. With IPv6, you can impose arbitrary restrictions as much as you want, because IPv4 makes sure there is always fallback connectivity anyway.

3

> I took a DMOZ[1] dump

What's a DMOZ dump?

DMOZ: http://www.dmoz.org/about.html
# The Open Directory Project is the largest, most comprehensive human-edited
# directory of the Web. It is constructed and maintained by a vast, global
# community of volunteer editors.

A DMOZ dump is the complete data set including directory structure, links and
descriptions. I've use this source because other lists are either too small or
contain a lot of spam.

> IPv6 failure rates of 4.3% (TLD) and 6.1% (NS)

What does TLD and NS mean?

TLD: Top Level Domain (e.g. .com, .us. org)
NS: Name Server - in this case Domain Name Server (DNS)

> 43 : broadcast address

?

Sorry, the same error message is also triggered by some firewalls.

Another factor is that with IPv4, you need to be pragmatic, because if
you don't, you have no connectivity. With IPv6, you can impose
arbitrary restrictions as much as you want, because IPv4 makes sure
there is always fallback connectivity anyway.

Maybe, but the most frequently encountered errors were time outs and
those usually degrade performance drastically.

Thomas

4

Thomas Kühne wrote:

I took a DMOZ[1] dump

What's a DMOZ dump?

DMOZ: http://www.dmoz.org/about.html
# The Open Directory Project is the largest, most comprehensive human-edited
# directory of the Web. It is constructed and maintained by a vast, global
# community of volunteer editors.

A DMOZ dump is the complete data set including directory structure, links and
descriptions. I've use this source because other lists are either too small or
contain a lot of spam.

I'd like to hear more about the methods that led to your summary, and, if possible, take a look at the raw data. It sounds to me like you took the dump file and parsed it so that all of the URLs could be sorted by domain. Did you then do DNS lookups on each domain name (or hostname?) and see how many had AAAA records? Did you also look at NS records (I am assuming you did)? I understand what TLDs and NSes are, but I don't quite know what you mean when you say things like "thus a cross check via TLDs' NS."

As for raw data, at the very least, it would be useful to get a list of the resources that have some form of IPv6 brokenness, so that those of us who would actually like to provide our information resources over both IPv4 and IPv6 can get to work on fixing it.

I personally am concerned that there are some islands of poor v6 connectivity out there that are having problems reaching v6 resources, even though other parts of the v6 world are able to reach those resources just fine. Because we may only be able to test from "good" v6 locations, we can't see what's wrong at the "bad" v6 locations.

michael

5

one might also consider that there may not be v4 conectivity in all
cases, so if you offer up a AAAA please make sure the services on the
relevant AAAA/A are consistent/available.

-Chris