Deprecation of ip6.int scheduled for 1 June 2006
Dear Colleagues In August 2005, the IETF published RFC 4159: 'Deprecation of "ip6.int"', as a Best Current Practice document. The RFC noted that maintenance of "ip6.int" is no longer needed and called on the Regional Internet Registries (RIRs) to decide when to stop providing support for the domain. The RIRs have jointly agreed to do this on 1 June 2006. There will be a short presentation on this at the RIPE 52 Meeting in Istanbul. You can find more information about this meeting at: http://www.ripe.net/ripe/meetings/ripe-52/index.html Regards Andrei Robachevsky Chief Technical Officer RIPE NCC
Andrei Robachevsky wrote:
Dear Colleagues
In August 2005, the IETF published RFC 4159: 'Deprecation of "ip6.int"', as a Best Current Practice document. The RFC noted that maintenance of "ip6.int" is no longer needed and called on the Regional Internet Registries (RIRs) to decide when to stop providing support for the domain. The RIRs have jointly agreed to do this on 1 June 2006.
... and there was much rejoicing. :) Doug -- If you're never wrong, you're not trying hard enough
On Tue, Mar 14, 2006 at 02:46:26PM -0800, Doug Barton wrote:
Andrei Robachevsky wrote:
Dear Colleagues
In August 2005, the IETF published RFC 4159: 'Deprecation of "ip6.int"', as a Best Current Practice document. The RFC noted that maintenance of "ip6.int" is no longer needed and called on the Regional Internet Registries (RIRs) to decide when to stop providing support for the domain. The RIRs have jointly agreed to do this on 1 June 2006.
... and there was much rejoicing. :)
Doug
now if the IETF & the RIRs could just get rid of all that deployed resolver code that looks for ip6.int by fiat. --bill
now if the IETF & the RIRs could just get rid of all that deployed resolver code that looks for ip6.int by fiat.
actually, i think it was kazu yamamoto who just gave a good analysis of why this is really not going to cause significant issues. randy
On Tue, 2006-03-14 at 19:02 -1000, Randy Bush wrote:
now if the IETF & the RIRs could just get rid of all that deployed resolver code that looks for ip6.int by fiat.
actually, i think it was kazu yamamoto who just gave a good analysis of why this is really not going to cause significant issues.
I don't know what Kazu San said about it, but one of the main reasons being that the roots will from 1/6/2006 nicely return NXDOMAIN and the resolver code won't try any further. Indeed the application won't get a reverse, but hell, they should upgrade then. Too bad that the nice ip6.int private domain is going away for the people running it though. But experimentation has to end at a certain point, now lets go to production ;) Greets, Jeroen
* Jeroen Massar wrote:
I don't know what Kazu San said about it, but one of the main reasons being that the roots will from 1/6/2006 nicely return NXDOMAIN and the resolver code won't try any further. Indeed the application won't get a reverse, but hell, they should upgrade then.
Upgrading Windows 2000 to XP or Vista will not happen that fast. Ok, let's show them numbers instead of names in tracert6.exe
On Wed, 2006-03-15 at 10:22 +0000, Lutz Donnerhacke wrote:
* Jeroen Massar wrote:
I don't know what Kazu San said about it, but one of the main reasons being that the roots will from 1/6/2006 nicely return NXDOMAIN and the resolver code won't try any further. Indeed the application won't get a reverse, but hell, they should upgrade then.
Upgrading Windows 2000 to XP or Vista will not happen that fast. Ok, let's show them numbers instead of names in tracert6.exe
Windows 2000 doesn't officialy support IPv6. If you have IPv6 on Win2k it is severely broken at a couple of points. Next to that, does it matter to see the numbers instead of names? It's not like you have SSH running on it or anything which requires logging. Thus what is the problem here? Only XP SP1/Win2k3/Vista and later are officially supported by M$ to have a working IPv6. Next ;) Greets, Jeroen
Lutz Donnerhacke wrote:
* Jeroen Massar wrote:
I don't know what Kazu San said about it, but one of the main reasons being that the roots will from 1/6/2006 nicely return NXDOMAIN and the resolver code won't try any further. Indeed the application won't get a reverse, but hell, they should upgrade then.
Upgrading Windows 2000 to XP or Vista will not happen that fast. Ok, let's show them numbers instead of names in tracert6.exe
You always have the option of maintaining your /etc/hosts file. Even windows has a "\somewhere\" {hosts.txt|lmhosts|lmhosts.txt} file. So "dig"out what ever you need and stuff it into /etc/hosts then your day is saved :) Bonus, you can add deprecated site-local IPv6-addresses too. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
Jeroen Massar wrote:
On Tue, 2006-03-14 at 19:02 -1000, Randy Bush wrote:
now if the IETF & the RIRs could just get rid of all that deployed resolver code that looks for ip6.int by fiat. actually, i think it was kazu yamamoto who just gave a good analysis of why this is really not going to cause significant issues.
I don't know what Kazu San said about it, but one of the main reasons being that the roots will from 1/6/2006 nicely return NXDOMAIN and the resolver code won't try any further.
In the interests of pedantry, it won't be the roots that return NXDOMAIN, it will be the INT TLD name servers. The ip6.int delegation (although not the maintenance of the actual zone) is a service brought to you by your friends at ICANN. :) Also, FWIW, I agree with the general consensus that this should be pretty much a non-issue. In addition to the other sources mentioned, I know that the RIRs were doing research on this going back to at least 2004, so this decision has not been made lightly. Pulling the plug on this patient is the kindest thing for all concerned. Doug -- If you're never wrong, you're not trying hard enough
On Thu, Mar 16, 2006 at 11:18:34AM -0800, Doug Barton wrote:
much a non-issue. In addition to the other sources mentioned, I know that the RIRs were doing research on this going back to at least 2004, so this decision has not been made lightly. Pulling the plug on this patient is the kindest thing for all concerned.
agreed. However, what we do not yet know is how many queries never hit the RIR's servers because they were answered locally without ever leaving the respective site. Judging from the behaviour of the non-reverse-delegated address space, there _should_ be no surprises. -Peter
now if the IETF & the RIRs could just get rid of all that deployed resolver code that looks for ip6.int by fiat.
actually, i think it was kazu yamamoto who just gave a good analysis of why this is really not going to cause significant issues.
The numbers of such external queries at our name server is already quite small relative to ip6.arpa: % zgrep -ich "external:.*\.ip6\.int.*PTR" /var/log/bind9-query.log* 0 2 4 5 % zgrep -ich "external:.*\.ip6\.arpa.*PTR" /var/log/bind9-query.log* 83 223 206 206 Looks like it may not be more then a few of percent. I guess there may be some clients that are fall back to ip6.int if a response is not forthcomming from ip6.arpa. David.
On Wed, 15 Mar 2006 04:58:52 +0000, bmanning@vacation.karoshi.com said:
On Tue, Mar 14, 2006 at 02:46:26PM -0800, Doug Barton wrote:
Andrei Robachevsky wrote:
Dear Colleagues
In August 2005, the IETF published RFC 4159: 'Deprecation of "ip6.int"', as a Best Current Practice document. The RFC noted that maintenance of "ip6.int" is no longer needed and called on the Regional Internet Registries (RIRs) to decide when to stop providing support for the domain. The RIRs have jointly agreed to do this on 1 June 2006.
... and there was much rejoicing. :)
Doug
now if the IETF & the RIRs could just get rid of all that deployed resolver code that looks for ip6.int by fiat.
As others said in this thread, this is probably not a big issue. A bigger issue is the fact that 0.1.0.0.2.ip6.int has been broken for a long time. I asked you several times to fix this :-) Why does it matter? For example, the resolver on Solaris (at least Solaris 9 and newer) first looks in ip6.arpa. When it doesn't find a PTR there, it looks in ip6.int. All delegations for 0.1.0.0.2.ip6.int are lame and a BIND9 cache will produce timeouts for every single query in this domain. So, when you do reverse lookups for anything in 2001::/20 that doesn't have a mapping in ip6.arpa, you'll run into this timeout and there's not much you can do about it except for ugly hacks on your cache. Incidentally, this happens for one of our IPv6 upstreams, which makes traceroute a real pain. Thanks to opensolaris.org I have found an undocumented option for resolv.conf (well, at least it's not in the man page). If you add options v6revmode:single then PTR queries will be restricted to ip6.arpa. Removing ip6.int is fine, keeping broken zones is not. -- Alex
On Wed, 15 Mar 2006 16:52:55 +0100, Alexander Gall <gall@switch.ch> said:
Thanks to opensolaris.org I have found an undocumented option for resolv.conf (well, at least it's not in the man page). If you add
options v6revmode:single
then PTR queries will be restricted to ip6.arpa.
This works on Solaris 9/10 as well, BTW. -- Alex
Alexander Gall wrote:
Removing ip6.int is fine, keeping broken zones is not.
Full ACK. Most IPv6 setups I've done so far have an empty zone configured in the resolvers for ip6.int (and did not request a delegation in ip6.int for their own block), because having no reverse name immediately is much more convenient than having no reverse name after a mandatory break waiting for the various delegation errors to timeout. ip6.int hasn't been stable for years, but the situation has become nearly unbearable since the ip6.int zones are no longer maintained. Not all hosts can be configured/updated to do ip6.arpa only (Cisco routers :-) ). I'm really looking forward to get ip6.int removed forever. Regards, Bernhard
--On den 15 mars 2006 04.58.52 +0000 bmanning@vacation.karoshi.com wrote:
now if the IETF & the RIRs could just get rid of all that deployed resolver code that looks for ip6.int by fiat.
IOS 12.0 will be fixed in 12.0(32)S2, and I believe that 12.1 and up are already taken care of. -- Måns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE I'm having an EMOTIONAL OUTBURST!! But, uh, WHY is there a WAFFLE in my PAJAMA POCKET??
Dear Colleagues, This is a reminder that from 1 June 2006, reverse delegations in the ip6.int DNS tree corresponding to IPv6 address space allocated by the RIPE NCC will no longer be supported. On 1 June 2006, RIPE NCC delegations will be deleted from the ip6.int zone. Following this we will remove the zones from the authoritative servers and delete the corresponding DOMAIN objects in the RIPE Whois Database. The maintainers of the DOMAIN objects to be deleted will also receive individual notifications 1 week prior to the deletion. This is being coordinated with other RIRs and is based on an IETF Best Current Practice document (RFC 4159). Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC On 14 March 2006 Andrei Robachevsky wrote:
Dear Colleagues
In August 2005, the IETF published RFC 4159: 'Deprecation of "ip6.int"', as a Best Current Practice document. The RFC noted that maintenance of "ip6.int" is no longer needed and called on the Regional Internet Registries (RIRs) to decide when to stop providing support for the domain. The RIRs have jointly agreed to do this on 1 June 2006.
There will be a short presentation on this at the RIPE 52 Meeting in Istanbul. You can find more information about this meeting at:
http://www.ripe.net/ripe/meetings/ripe-52/index.html
Regards
Andrei Robachevsky Chief Technical Officer RIPE NCC
Dear Colleagues, On 1 June 2006, the reverse delegations in the ip6.int DNS tree corresponding to IPv6 address space allocated by the RIPE NCC were deleted as planned. This means that these reverse delegations will no longer be supported. The corresponding DOMAIN objects were also deleted from the RIPE Whois Database. This has been coordinated with other Regional Internet Registries and is based on an IETF Best Current Practice document (RFC 4159). Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC
participants (12)
-
Alexander Gall -
Andrei Robachevsky -
Bernhard Schmidt -
bmanning＠vacation.karoshi.com -
David Malone -
Doug Barton -
Jeroen Massar -
Lutz Donnerhacke -
Måns Nilsson -
Peter Dambier -
Peter Koch -
Randy Bush