North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: IPv6 Connectivity Saga (part n+1)
On 2 feb 2008, at 11:42, Thomas Kühne wrote:
I took a DMOZ 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.