July 2004 - ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 :ip6.int shutdown?)
by Bound, Jim 20 Aug '04

20 Aug '04

> Can you identify those vendors which didn't react to a RFC > from 3 years ago? No that is up to those vendors product managers etc. What I know is from interoperability testing and cannot reveal. You missed mine and Bill's entire point. No one is against doing this it is a matter getting it into the production DNS code base. I think Bill should answer your other questions as you integrated my mail with Bill's. Your complaining here in IETF at least is irrelevant. And not the purpose of the IETF list IMO. I will not respond to other mail. If you want to discuss offline send me mail and I suggest you copy Bill. Ipv6.arpa is supported in the latest BIND releases and IMO all should be doing it, but I don't attribute it to being lazy at all. Again IPv6 is production code now vendors can't just change it as we do the public domain and university code base, it requires QA et al per the customer and that has cost and all changes to IPv6 at this point. /jim

2 1

[ipv6-wg@ripe.net] RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)
by Bound, Jim 31 Jul '04

31 Jul '04

Thank you. /jim > -----Original Message----- > From: bmanning(a)vacation.karoshi.com > [mailto:bmanning@vacation.karoshi.com] > Sent: Wednesday, July 28, 2004 7:20 AM > To: Bound, Jim > Cc: bmanning(a)vacation.karoshi.com; Jeroen Massar; Anand > Kumria; Rob Blokzijl; v6ops(a)ops.ietf.org; sig-ipv6(a)apnic.net; > ipv6-wg(a)ripe.net > Subject: Re: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: > 9/9/2006 : ip6.int shutdown?) > > > 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(a)ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of > > > bmanning(a)vacation.karoshi.com > > > Sent: Sunday, July 25, 2004 5:45 PM > > > To: Jeroen Massar > > > Cc: Anand Kumria; Rob Blokzijl; v6ops(a)ops.ietf.org; > > > sig-ipv6(a)apnic.net; ipv6-wg(a)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 > > > > > > > > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int- > > > > > > removal-00.xml > > > > > > > > > > > > Short, quick and easy. > > > > > > If no comments are risen for 16:00 today I'll submit > > > 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(a)lists.apnic.net > > > > http://mailman.apnic.net/mailman/listinfo/sig-ipv6 > > > > > > > > > >

1 0

[ipv6-wg@ripe.net] RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)
by Bound, Jim 28 Jul '04

28 Jul '04

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(a)ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of > bmanning(a)vacation.karoshi.com > Sent: Sunday, July 25, 2004 5:45 PM > To: Jeroen Massar > Cc: Anand Kumria; Rob Blokzijl; v6ops(a)ops.ietf.org; > sig-ipv6(a)apnic.net; ipv6-wg(a)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 > > > > > http://unfix.org/~jeroen/archive/drafts/draft-massar-v6ops-ip6int- > > > > removal-00.xml > > > > > > > > Short, quick and easy. > > > > If no comments are risen for 16:00 today I'll submit > 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(a)lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/sig-ipv6 > > >

3 2

[ipv6-wg@ripe.net] 9/9/2006 : ip6.int shutdown?
by Jeroen Massar 26 Jul '04

26 Jul '04

Hi, As e.f.f.3.ip6.arpa has finally been delegated and works as of today I want to propose the end-day for ip6.int. ip6.int has been deprecated in favor of ip6.arpa for almost 3 years already (RFC3152 dates August 2001) thus it is time to clean up the mess. Vendors have been able to update their stacks for almost 3 years, ip6.arpa has been deployed on production (read RIR) IPv6 space already for quite some time too. Thus now, with 6bone also having a working ip6.arpa tree this seems to be a perfect opportunity to start shutting down ip6.int. At the moment only Cisco IOS and Windows XP don't have ip6.arpa support, but IOS has been addressed (they say) and Windows XP will be fixed with SP2 due out per August. As neither of these are server OS's this doesn't pose much of a problem anyway. People using IPv6 need to keep their systems up-to-date anyways. I propose that RIPE, and actually any other RIR, stops any delegations for ip6.int per 9/9/2006. Which is more than 3 years after the RFC has been released. Greets, Jeroen

17 34

Re: [ipv6-wg@ripe.net] 9/9/2006 : ip6.int shutdown?
by Wilfried Woeber, UniVie/ACOnet 22 Jul '04

22 Jul '04

>Blame the IAB. Apparently, they were the ones who created this mess by >frivolously adopting ip6.arpa as a replacement for ip6.int. I think that's not exactly true ;-) . The reverse name tree for IPv4 is already located in the arpa. subtree. I cannot see any good reason why the same service for IPv6 should use a different TLD. (Actually I don't see a good formal reason for not using in-addr.arpa. - but I presume that there are good technical reasons...) . The mandate of the int. TLD (to support international treaty organisations) is not exactly compatible with the use for IPv6 reverse name tree delegations :-) Wilfried ( https://cert.aco.net/ ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

[ipv6-wg@ripe.net] Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jeroen Massar 21 Jul '04

21 Jul '04

[Added CC to ipv6-wg(a)ripe.net, where IMHO this belongs ;) ] On Wed, 2004-07-21 at 11:11, Jim Reid wrote: > >>>>> "Jeroen" == Jeroen Massar <jeroen(a)unfix.org> writes: > > >> Wrong, several root name servers (of course, not ICANN's one) > >> are reachable over IPv6: read http://www.root-servers.org/ > >> and edit your db.root. > > Jeroen> I know those addresses and I also know that all of those > Jeroen> boxes have a latency over at least 200ms and very odd > Jeroen> routability and those are far far far from to be called > Jeroen> production. > > This could be a good topic for presenting to the WG. Want to volunteer > to write up a document and/or presentation on the state of IPv6 > deployment in the root and TLD name servers, routing anomalies, etc, > etc? It would be good to hear someone's first-hand experiences with > this stuff: what went wrong, how it was worked around or solved, what > could be done better, future directions. Check http://www.sixxs.net/misc/latency/ and select the "IPv6 between POPs and well known destinations" option to reveal some ugglyness. I've been monitoring most of them for quite some time already and I also did some testing with the IPv6 only test root's (see http://www.rs.net) The POPs mentioned btw are the located all over Europe at various independent ISP's add .sixxs.net to find out exactly where or see the POP page on the site. Average latency to b.root-servers.net at least 294ms. H.root-servers.net was gone for sunday to monday and so on.... Not even minding the packetloss. E and I are also there btw, though that is not on the root-servers.org site. > Personally, I don't see why you care about the RTT to a root server. A > well-behaved name server will make 4-5 queries to a root server once a > week or so. <SNIP> That is indeed true, but it is rather odd when a machine is physically close and good connectivity between for instance Amsterdam and Sweden exists and then one still has traffic going over the US... But this is more a problem of the state of the IPv6 routing tables and the fact that only I is in europe and is only even testing IPv6 connectivity. Thus a presentation or better a debate about how the IPv6 routing can be improved in general would be a better subject and prolly the place for that is the ipv6-wg. But as people know who go there Gert Doering has been doing those updates for quite some time already and last time at least there was some discussion about the MIPP draft. Even as it has improved considerably in the last couple of years we are not there yet.. Greets, Jeroen

1 0