[ipv6-wg@ripe.net] RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)
Well stated Mr. Manning. Same for any updates from IETF for IPv6 (e.g. 2461, 2462, SEND, Optimistic DAD) as every vendor I know (e.g. routers, switches, servers, clients, embedded systems) is shipping production IPv6 within their OS release. Any changes now to IPv6 will undergo rigorous Q&A, whether it has a business case for deployment to update the OS IPv6 features vs. other work for network centricity within the stack, and general time to test interoperability. Because the freeware BSD and Linux bases do it does not mean that the vendors will do it. Assume the time to change as it is for IPv4 now when we update or add features. The IETF can only provide specifications and suggestions (INFO and BCP) to the market they cannot mandate anything to the market and we have not for IPv4 either, it will not be different than IPv6. This is also dilemma we face for transition mechanisms. Back when we decided to follow the path that we do scenarios and then analysis and killed the forward progress and work on Teredo, ISATAP, DSTM, and Tunnel Broker some vendors and systems software entities did not stop building them and they are now beginning to be deployed in test beds and some early adopters. This will find market interest and into vendor products (note all of the ones listed above) and then when we do finish the specs we will face the same problem with the transition mechanisms. We do need to move to ipv6.arpa in the industry but it will happen gradually and same as a note even for the updates to Base Transition Mechanisms ergo RFC 2893 and I have already run into being asked about IPv4 Compatible Addresses during deployment and those are dead now. Same for the addressing architecture regarding TLAs and Site-Locals. Lesson here is again assume a time to absorb for IPv6 products now just like we do for IPv4. The IPv6 Forum and NAv6TF can help here where the IETF cannot, and I will take this to the members and industry, but it will take time. It is a deployment issue not a standards issue at this point. The exception has been Mobile IPv6 and most vendors are all at RFC level and that is because lots of customers want to begin early adoption with MIPv6 and that keeps the vendors quite proactive on that one. P.S. Bill - the new initial IPv6 AAA at root for JP and KR are they to use ipv6.arpa? Thanks. /jim
-----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of bmanning@vacation.karoshi.com Sent: Sunday, July 25, 2004 5:45 PM To: Jeroen Massar Cc: Anand Kumria; Rob Blokzijl; v6ops@ops.ietf.org; sig-ipv6@apnic.net; ipv6-wg@ripe.net Subject: Re: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)
whjile i applaud each and everyone who has expunged all ip6.int from their lives, the fact of the matter is that IETF fiat or no, there exist -many- systems that can only use reverse maps in the ip6.int tree.
it will be maintained as long as there are queries for it. for those of you for whom ip6.int is a distant memory, pleae understand and respect the fact that you can not, despite public posturing, force others to change their systems. to practically remove ip6.int incures real cost in both time and cash. in the US there is a term for what the IETF is trying to do w/ ip6.int. Its called an unfunded mandate. Unless or until the good folk in the IETF who are calling for the removal of ip6.int are ready to put up the cash to effect real change, I wish they would stop.
On Thu, 2004-07-22 at 09:58, Kurt Erik Lindqvist wrote:
On 2004-07-22, at 09.43, Jeroen Massar wrote:
But indeed, if there is concensus or not 9/9/2004 and ip6.int is gone for me.
I vote for 9/9/2004 and getting rid of it properly. Maintaining two reverse threes will create more problems than it will solve.
What, specifically, is the hurry?
That this has been overdue for three years already and that even though the deprecation was marked in August 2001 some vendors still not have done the change. And as it is a s/ip6.int/ip6.arpa/g which is very easy, if vendors did not do that yet they are way overdue and you got to wonder how much their interest is in keeping software upto date.
Basically we (at least me) have been waiting for the 6bone to get the delegation so that we could remove the 2 trees and only keep one: ip6.arpa. This was decided by the IAB thus we should live up to it.
If we do not remove ip6.int then still implementations using it will not show up. They have had 3 years already to update...
Take your pick:
http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-
removal-00.html
http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-
removal-00.txt
removal-00.xml
Short, quick and easy. If no comments are risen for 16:00 today I'll submit
http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int- this as an ID.
Comments: e.f.f.3.ip6.arpa was documented in RFC3681 published in February 2004 and actioned in July 2004.
Added, but note that this was all long overdue and there where a number of other solutions that would have worked already 2 years ago if there had not been any of the political arguments holding back this technical issue. Note also that 6bone will end per 6/6/6 and that it is a TESTbed. The TESTbed is delaying and thus hurting the production networks in this case.
I'm assuming the actioning of e.f.f.3.ip6.arpa is the trigger for this I-D; if so, why do you want to wait so little time (2 months) between e.f.f.3.ip6.arpa becoming available and requiring people to have updated resolver libraries?
People should have updated their resolvers in the last *3 years*. If you have not done that already then you are not maintaining your machines properly and there is a big chance that you have bigger problems than a IPv6 reverse DNS that doesn't work anymore because ip6.int is gone.
Personally I'd be more in favour of a 6 month timeout - i.e around last December or so.
Of course the date is up to discussion, but IMHO: ASAP and at least before the end of the year, the sooner the better.
Note that Cisco's IOS updates will be done before that date and Windows XP2 will come out in August (they say) thus everybody using IPv6 has time enough to upgrade. All "free unix flavors" already support it
Also users agree: http://www.sixxs.net/forum/?msg=general-83948 Note the begin date of that thread, we where really waiting for 6bone just as being nice to the people still using it.
On Thu, 2004-07-22 at 10:57, Rob Blokzijl wrote:
If no comments are risen for 16:00 today I'll submit this as an ID.
two minor points. In the abstract and the introduction you write:
RFC 3152 delegates IP6.ARPA for reverse IPv6 delegations. For RIRs (RIPE,ARIN,APNIC,LACNIC and soon AFNIC)
Replace RIPE --> RIPE NCC
That I did that wrong is a major oops, I should by know the difference by now.
Replace AFNIC --> AFRINIC
(AFNIC is the .fr registry :-) )
Also adjusted and added some xref's in the XML.
Old version is now draft-massar-v6ops-ip6int-removal-00.a new version carries the draft-massar-v6ops-ip6int-removal-00 name.
Greets, Jeroen
* sig-ipv6: APNIC SIG on IPv6 technology and policy issues * _______________________________________________ sig-ipv6 mailing list sig-ipv6@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-ipv6
On Mon, 2004-07-26 at 12:54, Bound, Jim wrote:
Well stated Mr. Manning. Same for any updates from IETF for IPv6 (e.g. 2461, 2462, SEND, Optimistic DAD) as every vendor I know (e.g. routers, switches, servers, clients, embedded systems) is shipping production IPv6 within their OS release.
Can you identify those vendors which didn't react to a RFC from 3 years ago? I know that Windows XP doesn't do it yet, but will with SP2. And a fair amount of Cisco IOS's. Neither of these are servers thus don't require reverses to resolve. Routers don't need resolving, Switches? ehm Layer2, those don't do IPv6 and certainly don't need resolving ;) Any others that haven't been converted in the last three years?
Any changes now to IPv6 will undergoigorous Q&A,
<SNIP fairytale about slow people suddenly being awakened> You really need to check ip6.arpa? I'd rather be quite anxious in using the following set of servers: ip6.int. 86400 IN NS flag.ep.net. ip6.int. 86400 IN NS y.ip6.int. ip6.int. 86400 IN NS z.ip6.int. ip6.int. 86400 IN NS ns3.nic.fr. ;; Received 266 bytes from 128.9.128.127#53(ns.isi.edu) in 165 ms I only believe ns3.nic.fr to be a production server which is actually pro actively maintained as can be seen from the various reports send to the 6bone mailinglist about the non-workings of ip6.int. For that matter they are broken currently too: http://www.zonecut.net/dns/ Mon Jul 26 12:51:05 UTC 2004 y.ip6.int A record currently not present ip6.int NS ns3.nic.fr z.ip6.int hostmaster.ep.net (1925907 10800 900 604800 129600) ip6.int NS flag.ep.net Nameserver flag.ep.net not responding ip6.int SOA record not found at flag.ep.net, try again ip6.int NS z.ip6.int z.ip6.int hostmaster.ep.net (1925907 10800 900 604800 129600) and totally out of sync, just check the picture that that url produces. This is just like last year and the year before, but people gave up complaining about it as there is apparently only one person who runs ip6.int.
The IPv6 Forum and NAv6TF can help here where the IETF cannot, and I will take this to the members and industry, but it will take time. It is a deployment issue not a standards issue at this point.
The deployment issue is more a lazy administrator issue and also a political issue. The lazy administrators who do not want to upgrade and the political issue where some people want to keep some ropes tied to themselves so they can keep on pulling some strings.
P.S. Bill - the new initial IPv6 AAA at root for JP and KR are they to use ipv6.arpa? Thanks.
And FR also with a couple of others following. I don't see any US based name servers there though, odd. Then again this is for _forward_ resolving, the reverses served through ip6.arpa are delegated to: ip6.arpa. 172800 IN NS ns.apnic.net. ip6.arpa. 172800 IN NS ns.icann.org. ip6.arpa. 172800 IN NS ns.ripe.net. ip6.arpa. 172800 IN NS tinnie.arin.net. ;; Received 126 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 6 ms (K is started to do IPv6 too, at least the peerings are coming up ;) Fortunatly the above 4 servers are production and there are people paying attention to them, unlike the aforementioned ip6.int machines in somebodies private domain. On Sun, 2004-07-25 at 23:45, bmanning@vacation.karoshi.com wrote:
whjile i applaud each and everyone who has expunged all ip6.int from their lives, the fact of the matter is that IETF fiat or no, there exist -many- systems that can only use reverse maps in the ip6.int tree.
As I just asked Jim, which "systems" are those? I also wonder if those are not updated how big virustraps they are ;)
it will be maintained as long as there are queries for it.
Then we can shut it down quite quickly now can't we? And why let a lot of people pay hard cash for maintaining something which is near gone only because a few are too lazy to update?
for those of you for whom ip6.int is a distant memory, pleae understand and respect the fact that you can not, despite public posturing, force others to change their systems. to practically remove ip6.int incures real cost in both time and cash. in the US there is a term for what the IETF is trying to do w/ ip6.int. Its called an unfunded mandate. Unless or until the good folk in the IETF who are calling for the removal of ip6.int are ready to put up the cash to effect real change, I wish they would stop.
Then please donate the rest of the world, thus except for the few of you who don't update, real cash for continuing to maintain ip6.int which has a lot of broken delegations for alone ip6.int, not even checking the rest, see above. I also wonder why the "US" is brought up while the "US" hasn't been so active in the whole IPv6 soup until late. ip6.int will be gone for me and thus 30%+ of the current IPv6 endsite delegations (check the RIPE database :), 31st of December 2004 is the last date this is going to wait. But I'd rather see it pulled down nicely in cooperation than doing it that way. Nevertheless that 30% userbase has already voted in favor and don't see the problem at all. Then again they actually update their systems as they want to be able to use the newest features: IPv6 for instance. I also repeat again: there is nothing *BAD* about having a reverse- resolve which doesn't work. One simply gets an IPv6 address in their logs, too bad, you should have upgraded 3 years ago then. Greets, Jeroen
both ip6.arpa and ip6.int --bill
P.S. Bill - the new initial IPv6 AAA at root for JP and KR are they to use ipv6.arpa? Thanks.
/jim
-----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of bmanning@vacation.karoshi.com Sent: Sunday, July 25, 2004 5:45 PM To: Jeroen Massar Cc: Anand Kumria; Rob Blokzijl; v6ops@ops.ietf.org; sig-ipv6@apnic.net; ipv6-wg@ripe.net Subject: Re: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)
whjile i applaud each and everyone who has expunged all ip6.int from their lives, the fact of the matter is that IETF fiat or no, there exist -many- systems that can only use reverse maps in the ip6.int tree.
it will be maintained as long as there are queries for it. for those of you for whom ip6.int is a distant memory, pleae understand and respect the fact that you can not, despite public posturing, force others to change their systems. to practically remove ip6.int incures real cost in both time and cash. in the US there is a term for what the IETF is trying to do w/ ip6.int. Its called an unfunded mandate. Unless or until the good folk in the IETF who are calling for the removal of ip6.int are ready to put up the cash to effect real change, I wish they would stop.
On Thu, 2004-07-22 at 09:58, Kurt Erik Lindqvist wrote:
On 2004-07-22, at 09.43, Jeroen Massar wrote:
> But indeed, if there is concensus or not 9/9/2004 and ip6.int > is gone for me.
I vote for 9/9/2004 and getting rid of it properly. Maintaining two reverse threes will create more problems than it will solve.
What, specifically, is the hurry?
That this has been overdue for three years already and that even though the deprecation was marked in August 2001 some vendors still not have done the change. And as it is a s/ip6.int/ip6.arpa/g which is very easy, if vendors did not do that yet they are way overdue and you got to wonder how much their interest is in keeping software upto date.
Basically we (at least me) have been waiting for the 6bone to get the delegation so that we could remove the 2 trees and only keep one: ip6.arpa. This was decided by the IAB thus we should live up to it.
If we do not remove ip6.int then still implementations using it will not show up. They have had 3 years already to update...
Take your pick:
http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-
removal-00.html
http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int-
removal-00.txt
removal-00.xml
Short, quick and easy. If no comments are risen for 16:00 today I'll submit
http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int- this as an ID.
Comments: e.f.f.3.ip6.arpa was documented in RFC3681 published in February 2004 and actioned in July 2004.
Added, but note that this was all long overdue and there where a number of other solutions that would have worked already 2 years ago if there had not been any of the political arguments holding back this technical issue. Note also that 6bone will end per 6/6/6 and that it is a TESTbed. The TESTbed is delaying and thus hurting the production networks in this case.
I'm assuming the actioning of e.f.f.3.ip6.arpa is the trigger for this I-D; if so, why do you want to wait so little time (2 months) between e.f.f.3.ip6.arpa becoming available and requiring people to have updated resolver libraries?
People should have updated their resolvers in the last *3 years*. If you have not done that already then you are not maintaining your machines properly and there is a big chance that you have bigger problems than a IPv6 reverse DNS that doesn't work anymore because ip6.int is gone.
Personally I'd be more in favour of a 6 month timeout - i.e around last December or so.
Of course the date is up to discussion, but IMHO: ASAP and at least before the end of the year, the sooner the better.
Note that Cisco's IOS updates will be done before that date and Windows XP2 will come out in August (they say) thus everybody using IPv6 has time enough to upgrade. All "free unix flavors" already support it
Also users agree: http://www.sixxs.net/forum/?msg=general-83948 Note the begin date of that thread, we where really waiting for 6bone just as being nice to the people still using it.
On Thu, 2004-07-22 at 10:57, Rob Blokzijl wrote:
If no comments are risen for 16:00 today I'll submit this as an ID.
two minor points. In the abstract and the introduction you write:
RFC 3152 delegates IP6.ARPA for reverse IPv6 delegations. For RIRs (RIPE,ARIN,APNIC,LACNIC and soon AFNIC)
Replace RIPE --> RIPE NCC
That I did that wrong is a major oops, I should by know the difference by now.
Replace AFNIC --> AFRINIC
(AFNIC is the .fr registry :-) )
Also adjusted and added some xref's in the XML.
Old version is now draft-massar-v6ops-ip6int-removal-00.a new version carries the draft-massar-v6ops-ip6int-removal-00 name.
Greets, Jeroen
* sig-ipv6: APNIC SIG on IPv6 technology and policy issues * _______________________________________________ sig-ipv6 mailing list sig-ipv6@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-ipv6
participants (3)
-
bmanning＠vacation.karoshi.com -
Bound, Jim -
Jeroen Massar