reverse DNS considered pointless was: [6bone] Fwd: BCP 80, RFC3681 on Delegation of E.F.F.3.IP6.ARPA

[Jeroen Massar]

-----BEGIN PGP SIGNED MESSAGE-----

Matthew Luckie wrote:

<SNIP>

> just a small amount of stats from someone who is not big on stats:
> 
> i did a DNS walk of ip6.int about 9 months ago.

The trick here is that you should taka a look at ip6.arpa.
ip6.int has been deprecated for over 2 years ago...
Please check ip6.arpa and test RIR space, not 6bone space as
can be seen yet again, ip6.arpa for 6bone will take quite some
time and even more time to get deployed under the many slumbering
and neglected pTLA's floating around.

> of the ~31k addresses i got, 21k were automatically generated 
> (2x 10k, 1x 1k).  i saw a fair amount of DNS spamming, but it did not 
> feel like IRC lamers had taken over the DNS.  From memory there was 
> some kind of free DNS service behind a fair amount of the spam.

It is indeed always in the same prefix, some operators don't
use it at all and some like to use it on every single IP they
can put their hands on.

Do you have some more detailed output of these results. Also did
you mean you autogenerated 21k addresses or that you found 21k
autogenerated reverses?

> of the ~10k left, 2445 survived a sanity check (taking the 
> name returned in the PTR and resolving for the IPv6 address returned as 
> part of the walk).

That's the 6bone indeed, sometimes in traceroutes some odd routes
pop up and some times even the domainname to which the reverse
points to has been expired for 2 years already :)

> of those 2445, i got a response rate of about 70% +/- 3% with 
> traceroute, depending on where the tests were run from.  the 
> majority of failures of communicating with an address were loops, 
> followed by dead paths (hosts/networks that said nothing).  only a very small 
> proportion of addresses that were not actually reachable had a router 
> send an ICMP response saying so.
> 
> http://voodoo.cs.waikato.ac.nz/~mjl12/ipv6-scamper/

I guess you did the same thing as what Lorenzo Colitti did for his
tunnel discovery, you thought that the 6bone registry is a working
and up-to-date source. Well two things about that. There is more to
the IPv6 internet than the 6bone, secondly, the 6bone registry
is one of the biggest messes of them all.

I also read that you used the 6bone db of February 2003 while
doing the tests almost 4 and 6 months later, better use a more
up-to-date version next time as some people do actually update it.

"google IPv6: addresses collected by taking the first 1000 unique
sites returned in a google search for "IPv6" and resolving them for IPv6 addresses "

Most sites in google don't have IPv6, as your report also
notices of the 1000 you took, only 123 has IPv6... though that
is still 12.3% of the hosts, which actually is quite a lot.
Also see http://www.prik.net/list.html for a big list of
IPv6 capable hosts. Maybe run scamper against that list ?
I can do it from my vantage point if you would like to.

Checking slide 9 of Lorenzo's presentation, to be found at:
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunnel-disco.pdf
shows that of over the 4000 tunnels 'registered' in the 6bone registry
about 43% are nonexistent and another 32% are down or filtered,
let's assume those simply don't work as filtering simply is not
something that most people do. Thus of the 4000 tunnels
in the registry 43+32 = 75% is broken, only 1000 left...
One can read from this that the 6bone is going away, which is
a good thing as people move to RIR space and more production
environments, the only problem there though is that people
don't take the responsibility to clean the registries.

PS: as for the /127 question at the bottom of your page,
there are many ISP's using /127's, IPng.nl has over 500
from them to endusers. It only hurts on OS's that are
anycast aware and when the tunnel gets configured as a
/127, using 2x /128 does work. I am also aware of setups
that use /64 per link but only route 2x the /128, that is
one /128 to the local host and, one /128 to the remote
endpoint pointing across the tunnel.

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / http://unfix.org/~jeroen

iQA/AwUBQCd/mSmqKFIzPnwjEQKzGgCeJZXJCnhpe9PujN4KAsRUuXfVIaIAniO7
gYGXe2vgBMTUbfNCKwrjiQtW
=/t0M
-----END PGP SIGNATURE-----