ip6.int will be deprecated on 1 June, 2006.
Thanks to this, we expected that the response time of reverse look up will be shorter.
Resolvers that looks up "ip6.int" only will not be able to resolve host names with reverse look up. It is servers that mainly use reverse look up. If servers uses resolvers that looks up "ip6.int" only, the following problems would happen:
These problems are not fatal. Also, resolvers that looks up "ip6.int" only are minority. And the number of them which are used by servers are limited.
RFC 1886, published in December 1995, defines ip6.int for reverse mapping of IPv6 addresses.
RFC 3152, published in August 2001, defines to use ip6.arpa instead of ip6.int. Please refer to IAB's message to know the reasons. RFC 4159, published in August 2005, describes as follows:
The Regional Internet Registries (RIRs) are advised that maintenance of delegation of entries in "ip6.int" is no longer required as part of infrastructure services in support of Internet Standards Conformant IPv6 implementations as of 1 September 2005.
All RIRs will stop maintenance of the delegated domains under ip6.int on 1 June, 2006.
Note that the day of deprecation of 6bone is defined June 6, 2006 in RFC 3701.
The followings are decided to be carried out.
See also a presentation in DNS SIG of APNIC 20.
APNIC receives about 5 queries every minute to the APNIC-maintained domains under ip6.int.
The following table is statistics measured on the DNS servers of the WIDE project. The period of time is from 05:00 December 30, 2005 to 03:20 January 20, 2006. The average number of DNS queries to ip6.int is about 3.8.
| Transport/Zone | int | arpa | int+arpa |
|---|---|---|---|
| IPv4 | 109,273 | 366,474 | 475,747 |
| IPv6 | 5,211 | 6,023 | 11,234 |
| IPv4+IPv6 | 114,484 | 372,497 | 486,981 |
| Transport/Zone | int | arpa | int+arpa |
|---|---|---|---|
| IPv4 | 22.4% | 75.3% | 97.7% |
| IPv6 | 1.1% | 1.2% | 2.3% |
| IPv4+IPv6 | 23.5% | 76.5% | 100% |
IPv6 address assignments from IANA to RIRs is described in an IANA's page.
With the following reasons, we expected that the response time of reverse look up will be shorter.
There exist four kinds of resolvers.
"X => Y" denotes that the resolver first tries X with a name and if the name cannot be resolved it tries Y.
The following table is a summary that how each resolver will change after "ip6.int" will be deprecated. The lines indicates zones. For instance, "int,arpa" is zones registered both under "ip6.int" and under "ip6.arpa". The columns means resolvers. While "o" refers to "possible to resolve", "x" means "impossible to resolve". The left side is "before the deprecation". And the right side is "after the deprecation".
| Resolvers/Zone | int | arpa | int,arpa | none |
|---|---|---|---|---|
| int only | o/x | x/x | o/x | x/x |
| arpa only | x/x | o/o | o/o | x/x |
| int => arpa | o/x | o/o | o/o | x/x |
| arpa => int | o/x | o/o | o/o | x/x |
To know what will happen, we should consider the cases where its right side is different from its left side.
Addresses registered under "ip6.int" but not "ip6.arpa" (i.e. the "int" column) will not be resolved. This is a mis-configuration. What we can do is just fix it. The problem here is that "int" only resolver will not be able to resolve any host names.
The following is a summary of considerations on each resolver.
It is servers that mainly use reverse look up. The main usage is as follows:
If servers uses "ip6.int" only resolvers, the following problems would happen:
These problems are not fatal. Also, "ip6.int" only resolvers are minority. And the number of them which are used by servers are limited.
The WIDE project created an environment where "ip6.int" is deprecated and we are doing a field test by using the environment for our daily lives.
Concretely speaking, when queries come to DNS servers operated by the WIDE project from a specific address range, they return a "name error". We started this field test on 18 January, 2006.
We knew evaluations for this would be difficult in advance. Though we don't find a good evaluation method at this moment, we can say that there is no problem report. Of course, this is not a perfect evidence that the deprecation of "ip6.int" will not cause fatal problems, we can say it suggests that the deprecation will not cause problems so much.