IPv6 Network - The Current Situation

After such turmoil, it’s not entirely surprising that implementations were all over the map. Although the A6 record never gained much traction, all the different ways of looking up reverse mapping can still be found “in the wild.” A few rather old IPv6 resolver implementations use ip6.int exclusively. This isn’t a huge deal, as many people set up both ip6.int and ip6.arpa (nibble method). And if the ip6.int lookup fails, it usually does so with a regular “no such domain” error message, which doesn’t lead to additional problems. The IETF seems to want to get rid of ip6.int in a hurry, after which ip6.int-only implementations won’t be able to resolve IPv6 addresses into domain names.

A larger group of implementations (including many versions of Red Hat Linux) looks for bitlabels under ip6.arpa first, and then falls back to the nibble method under ip6.int. Because there is no evidence of there ever having been any bitlabel delegations, the first step will always be unsuccessful, even if all the caching nameserver and the ip6.arpa TLD nameservers all understand bitlabel queries. This may not be the case, however, as most of the available DNS server software doesn’t support bitlabels. BIND gained support for bitlabels around version 9, but it was removed again in version 9.3.

Then there are some resolver implementations that first look for ip6.arpa using the nibble method, and if they don’t find anything, fall back on ip6.int, and finally, there are the implementations that only look for ip6.arpa. A similar spectrum of behavior is present in the DNS utilities dig, host, and nslookup that are part of the BIND distribution. Because these containtheir own resolver code, their behavior may or may not match that of the rest of the system.

Tags: Add more tags...,

or Close

Comment an article   Name   E-mail    Title Available characters: 4000  Notify me of follow-up comments Enter what you see:

No comment posted