[102239] in North American Network Operators' Group
Re: IPv6 Connectivity Saga (part n+1)
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Sat Feb 2 12:30:27 2008
Cc: nanog@merit.edu
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas@kuehne.cn>
In-Reply-To: <200802021142.01682@msgid.kuehne.cn>
Date: Sat, 2 Feb 2008 18:28:35 +0100
Errors-To: owner-nanog@merit.edu
On 2 feb 2008, at 11:42, Thomas K=FChne wrote:
> 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 =20
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 =20=
it as a failure. This typically happens when a host has an IPv6 =20
address in the DNS, but a service isn't reachable over IPv6. Since =20
reasonable implementations will retry over IPv4 after a round trip, =20
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 =20=
"install and forget", which goes to the "use it or lose it" doctrine: =20=
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 =20
doesn't work. Interestingly, if something new is set up incorrectly =20
and then someone comes along who wants to use the new option, and it =20
doesn't work, the blame is laid at the person who decided to use the =20
new option, rather than the person who offered a service over it but =20
didn't make sure it worked correctly.
I've been downloading files from the FTP servers of the five RIRs a =20
few times a week for several years now. I haven't kept track of it, =20
but it seems that it's gotten harder to reach these FTP servers over =20
IPv6 the past year or so. This could very well have something to do =20
with IPv6 becoming more mainstream, so it's no longer some =20
experimental thing that can be enabled without trouble, but a =20
production service that must be firewalled. This seems to be the =20
source of much trouble, especially with ARIN, which I can't =20
successfully reach over IPv6 anymore, probably because of a routing =20
issue between their and my ISPs. But before that, I had path MTU =20
problems towards them on several occasions.
Another factor is that with IPv4, you need to be pragmatic, because if =20=
you don't, you have no connectivity. With IPv6, you can impose =20
arbitrary restrictions as much as you want, because IPv4 makes sure =20
there is always fallback connectivity anyway.=
