- ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] IPv6 in .ie (fwd)
by Carlos Friacas 07 Sep '04

07 Sep '04

FYI, 19 TLDs already served by IPv6 nameservers w/glue-record on ".". Tue Sep 7 08:50:45 WEST 2004 ----------------------------- CH. DOMREG.NIC.CH. LI. DOMREG.NIC.CH. DE. A.NIC.DE. FR. C.NIC.FR. IE. NS6.IEDR.IE. JP. A.DNS.JP. JP. D.DNS.JP. JP. E.DNS.JP. JP. F.DNS.JP. KR. G.DNS.KR. IE. NS3.NS.ESAT.NET. TP. NS3.NS.ESAT.NET. AN. NS0.JA.NET. GB. NS0.JA.NET. GG. NS0.JA.NET. INT. NS0.JA.NET. JE. NS0.JA.NET. AN. NS0.JA.NET. GB. NS0.JA.NET. GG. NS0.JA.NET. INT. NS0.JA.NET. JE. NS0.JA.NET. INT. NS-SEC.RIPE.NET. AQ. NS-EXT.ISC.ORG. IL. NS-EXT.ISC.ORG. NL. NS-EXT.ISC.ORG. PH. NS-EXT.ISC.ORG. TN. NS.ATI.TN. TW. A.DNS.TW. TW. C.DNS.TW. TW. D.DNS.TW. ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!" ---------- Forwarded message ---------- Date: Mon, 06 Sep 2004 18:05:11 +0100 From: Billy Glynn <billy.glynn(a)domainregistry.ie> To: ipv6-wg(a)ripe.net Cc: dns-wg(a)ripe.net, tech(a)lists.centr.org, ga(a)centr.org Subject: [ipv6-wg(a)ripe.net] IPv6 in .ie Hi, FYI, the IEDR in it's capacity as ccTLD manager of .ie have added a new IPv6 compatible name server ns6.iedr.ie. Additionally, we have added AAAA glue for one of our slaves ns3.ns.esat.net. ns3.ns.esat.net also slaves for the folks at .tp Kind regards -- ________________________________ Billy Glynn Network Operations Centre IE Domain Registry Ltd Tel: +353 (0)1 2365404 Mobile: +353 (0)87 9188317 billy.glynn(a)domainregistry.ie ________________________________

1 0

[ipv6-wg@ripe.net] IPv6 in .ie
by Billy Glynn 07 Sep '04

07 Sep '04

Hi, FYI, the IEDR in it's capacity as ccTLD manager of .ie have added a new IPv6 compatible name server ns6.iedr.ie. Additionally, we have added AAAA glue for one of our slaves ns3.ns.esat.net. ns3.ns.esat.net also slaves for the folks at .tp Kind regards -- ________________________________ Billy Glynn Network Operations Centre IE Domain Registry Ltd Tel: +353 (0)1 2365404 Mobile: +353 (0)87 9188317 billy.glynn(a)domainregistry.ie ________________________________

3 2

[ipv6-wg@ripe.net] Portuguese Mirror also in IPv6 (fwd)
by Carlos Friacas 03 Sep '04

03 Sep '04

Hello, Just to report yet another very small step... (the 3rd ripe meetings' webcast mirror, acessible via IPv6 - following Cesnet's and Surfnet's) Regards, ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!" ---------- Forwarded message ---------- Date: 3 Sep 2004 14:33:31 +0100 From: Nuno Gonçalves <nuno(a)fccn.pt> To: ripecast(a)ripe.net Cc: 'Carlos Friacas' <cfriacas(a)fccn.pt>, Subject: Portuguese Mirror also in IPv6 Hello! My name is Nuno Gonçalves and I work at FCCN on the streaming area. I saw on your website at http://www.ripe.net/ripe/meetings/ripe-49/webcast.html , that there is an URL to our mirror here at Lisbon among the other mirrors across Europe! Our mirror already has IPv6 enabled, so is it possible to add the IPv6 next to Portugal Mirror: on the web page? Thanks in advance Best Regards Nuno Gonçalves _____________________ Nuno Gonçalves - FCCN Work Group Multimedia nuno(a)fccn.pt http://www.fccn.pt _____________________

1 0

[ipv6-wg@ripe.net] Call for agenda items RIPE49 & draft agenda (v1)
by David Kessens 03 Sep '04

03 Sep '04

Please see below for the first version of the draft agenda. As usual, we don't have enough interesting topics (yet). That is bad news and good news: I need your help in finding interesting topics but the good news is that we will have time to accommodate your suggestions. Let me know if you want to volunteer for an agenda topic, but also feel free to suggest a topic that I or the list might know volunteers for. Thanks, David Kessens --- Updated agenda for the IPv6 Working Group Meeting RIPE49 When: 14:00 - 18:00, Wednesday September 22, 2004 Where: Medici Room, Renaissance Hotel, Manchester, UK A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Global IPv6 routing table status (Gert Doering) C. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) D. What are the deployment plans behind the larger ipv6 allocations ? o TeliaSonera (Mikael Lind) E. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) F. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

2 1

[ipv6-wg@ripe.net] DNS Weather Report 2004-08-31
by Daniel Roesen 31 Aug '04

31 Aug '04

[sorry! resent, wrong subject date!] DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-31 Zones analyzed and their SOA contacts: - . - arpa. nstld(a)verisign-grs.com - int. noc(a)icann.org - in-addr.arpa bind(a)arin.net - ip6.arpa. hostmaster(a)icann.org - ip6.int. hostmaster(a)ep.net [Operators: please let me know wether you do want a copy when there's no problem with your zone(s) or not. Don't want to annoy anyone unnecessarily!] Executive summary: * m.root out-of-sync problem got fixed within one hour after I've sent out report 2004-08-24. Thanks WIDE! * The INT problem with the non-matching NS RRset (in-zone and delegation) was also fixed. Unfortunately ns.isi.edu is _still_ out of sync. * The IP6.ARPA NS RRset discrepancy got worse over the last week. * ns.isi.edu is _still_ auth for IP6.INT where it shouldn't be. The state of the root zone =========================== fine! The state of the ARPA zone ========================== fine! The state of the INT zone ========================= - ns.isi.edu is not in sync with the other nameservers Current SOA serial of the INT TLD: 2004082300, ns.isi.edu has still 2002080104 and is publishing stale data (e.g. an old NS RRset for the zone). Problem exists since at least 2004-08-24 The state of the IN-ADDR.ARPA zone ================================== fine! The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ---------------- ----------------- ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. ns.lacnic.net. Problem known, RIPE sent a reminder to ip6.arpa operators two weeks ago, obviously without any outcome. Since the last DNS weather report last week, ns.lacnic.net. was added. Looks like now at least two change requests for the ip6.arpa delegation are pending. Problem exists since in various degrees since at least 2004-08-24 The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so induces no operational problems so far. Problem exists since at least 2004-08-24 Regards, Daniel

1 0

[ipv6-wg@ripe.net] DNS Weather Report 2004-08-24
by Daniel Roesen 31 Aug '04

31 Aug '04

DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-31 Zones analyzed and their SOA contacts: - . - arpa. nstld(a)verisign-grs.com - int. noc(a)icann.org - in-addr.arpa bind(a)arin.net - ip6.arpa. hostmaster(a)icann.org - ip6.int. hostmaster(a)ep.net [Operators: please let me know wether you do want a copy when there's no problem with your zone(s) or not. Don't want to annoy anyone unnecessarily!] Executive summary: * m.root out-of-sync problem got fixed within one hour after I've sent out report 2004-08-24. Thanks WIDE! * The INT problem with the non-matching NS RRset (in-zone and delegation) was also fixed. Unfortunately ns.isi.edu is _still_ out of sync. * The IP6.ARPA NS RRset discrepancy got worse over the last week. * ns.isi.edu is _still_ auth for IP6.INT where it shouldn't be. The state of the root zone =========================== fine! The state of the ARPA zone ========================== fine! The state of the INT zone ========================= - ns.isi.edu is not in sync with the other nameservers Current SOA serial of the INT TLD: 2004082300, ns.isi.edu has still 2002080104 and is publishing stale data (e.g. an old NS RRset for the zone). Problem exists since at least 2004-08-24 The state of the IN-ADDR.ARPA zone ================================== fine! The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ---------------- ----------------- ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. ns.lacnic.net. Problem known, RIPE sent a reminder to ip6.arpa operators two weeks ago, obviously without any outcome. Since the last DNS weather report last week, ns.lacnic.net. was added. Looks like now at least two change requests for the ip6.arpa delegation are pending. Problem exists since in various degrees since at least 2004-08-24 The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so induces no operational problems so far. Problem exists since at least 2004-08-24 Regards, Daniel

1 0

[ipv6-wg@ripe.net] Re: [address-policy-wg] Re: IANA to RIR IPv6 Allocation
by Wilfried Woeber, UniVie/ACOnet 25 Aug '04

25 Aug '04

>> My proposal would be that IANA would have to perform the subsequent >> allocation within this 30 day period, even if they might not be able to >> obtain advice or an expertise (for whatever reason) from any other party >> they might have decided to ask for advice. > >sure, if we can we do the same for rir to lir No problem with that, although I don't see the need for global coordination here. To me this sounds like a RIR-Customer service-contract aspect. Wilfried.

1 0

Re: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANA to RIR ipv6 Allocation
by Iljitsch van Beijnum 24 Aug '04

24 Aug '04

On 24-aug-04, at 4:48, Jeff Williams wrote: > Iljitsch and all, ^^^^^ No kidding... > None of this addresses the outstanding problems with Ipv6 or ipv6 > allocation concerns and existing as well as discussed problems. > They are "at least" the following: I don't think I get what you're talking about. > 1. ) Invalid or incorrect minimal allocation. What is invalid or incorrect here? > 2.) Still existing cost increases for allocations. What cost? > 3.) Still existing security/privacy "holes" in ipv6 What holes? There is no difference with IPv4. > 4.) Routing notification for new allocation practice or method. What on Earth is a "routing notification"? > 5.) Routing table maintenance Best practices and/or policy, Well, there is some of this but since the RIRs seem to have trouble living up to their own policies this is problematic. (See http://www.bgpexpert.com/archive2003q4.php ) > and enforcement of same. Yes, we don't do this in the internet. (And go fix the IPv4 table first if you feel so inclined.) > 6.) Dealing with "Dark" existing and/or future allocated addresses. Again, I have no idea what you're talking about. Now if we could have a mechanism to determine resolving DNS servers automatically in IPv6 and have visible IPv6 addresses for the root DNS servers we'd be well on our way. And of course we still need multihoming in IPv4 and the IETF has to quit rewriting the RFCs all the time. > Iljitsch van Beijnum wrote: I know what I wrote, so P L E A S E don't repeat it in its entirety!!! I'm really getting sick and tired of people who are too lazy to quote in a decent manner.

1 0

[ipv6-wg@ripe.net] DNS Weather Report 2004-08-24
by Daniel Roesen 24 Aug '04

24 Aug '04

DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-24 Zones analyzed and their SOA contacts: - . nstld(a)verisign-grs.com - arpa. nstld(a)verisign-grs.com - int. noc(a)icann.org - in-addr.arpa bind(a)arin.net - ip6.arpa. hostmaster(a)icann.org - ip6.int. hostmaster(a)ep.net Executive summary: not a single zone without any problems, but ip6.int situation improved significantly. The state of the root zone =========================== - m.root-servers.net is lagging behind the others... general SOA serial is 2004082201, m.root has 2004082101 The state of the ARPA zone ========================== - same SOA serial problem as in the root zone, m.root out-of-sync. Interestingly, all the same SOA serial numbers as the root zone (coincidence?) The state of the INT zone ========================= - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ns0.ja.net. ns0.ja.net. ns1.cs.ucl.ac.uk. ns1.cs.ucl.ac.uk. ns.icann.org. ns.icann.org. ns.isi.edu. ns.isi.edu. ns.uu.net. ns.uu.net. ns.ripe.net. z.ip6.int. - ns.isi.edu started to be auth again (was lame a few days ago), but is not in sync. current SOA serial of the INT TLD: 2004080300, ns.isi.edu has 2002080104 The state of the IN-ADDR.ARPA zone ================================== - same problem with m.root as with the root zone. m.root seems to lag exactly one day behind, judging from the SOA serial number. The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. Problem known, RIPE sent a reminder to ip6.arpa operators a week ago, obviously without any outcome. The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so introduces no operational problems so far. Regards, Daniel

1 0

[ipv6-wg@ripe.net] Re: IANA to RIR IPv6 Allocation
by Wilfried Woeber, UniVie/ACOnet 21 Aug '04

21 Aug '04

I've got one comment here on section 7. paragraph 4. "Subsequent Allocation": While the wording might be sufficiently clear for a native speaker by referring to "set of administrative procedures....", I am missing clear guidance for the IANA that there should _not_ be any incentive or responsibilty to consult with other groups, entities or third parties (irrespective of their, say, credibility for e.g. protocol development or technical specifications) which would require extending that 30 day period. My proposal would be that IANA would have to perform the subsequent allocation within this 30 day period, even if they might not be able to obtain advice or an expertise (for whatever reason) from any other party they might have decided to ask for advice. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...there's no place like 127.0.0.1 (or ::1/128 ?) From: David Kessens <david.kessens(a)nokia.com> To: Jeroen Massar <jeroen(a)unfix.org> Date: Fri, 20 Aug 2004 01:48:52 -0700 CC: ipv6-wg(a)ripe.net Subject: Re: [ipv6-wg(a)ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation Jeroen, On Fri, Aug 20, 2004 at 09:25:59AM +0200, Jeroen Massar wrote: > For people not on the arin-council (not likely ;) or the ppml@arin > lists: All policy discussions for the RIPE region are now conducted at the RIPE policy working group maillist: address-policy-wg(a)ripe.net David Kessens --- > -----Forwarded Message----- > From: "Sweeting, John" <John.Sweeting(a)teleglobe.com> > To: 'ppml(a)arin.net' <ppml(a)arin.net> > Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation > Date: Thu, 19 Aug 2004 17:36:56 -0400 > > I am submitting the following proposal IAW ARIN's Internet Resource Policy > Evaluation Process. In the interest of all I would like to disclose up front > that the information used to prepare this template was provided by ARIN > staff. > > > ############################################ > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet > Assigned Numbers Authority (IANA) Policy to Regional Internet Registries > > 2. Author > > a. name: John Sweeting > b. email: john.sweeting(a)teleglobe.com > c. telephone: 703-766-3042 > d. organization: ARIN Advisory Council > > 3. Proposal Version: 1 > > 4. Submission Date: 8/17/04 > > 5. Proposal type: new, global > > 6. Policy term: permanent > > 7. Policy statement: > > 1. Minimum Allocation Size. > > The minimum size of any allocation of IPv6 address space from IANA to an RIR > is prefix length /12. If this address space is not sufficient to meet the > needs of an RIR for a projected 18 month period, IANA shall allocate to that > RIR the address space for which it can provide justification. > > 2. Reservation of Unicast Address space. > > 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 > addresses beginning at binary value 001 (prefix length /3) for its > allocations of unicast address space. In order to support regional > aggregation of IPv6 address space IANA shall establish a reservation of a > prefix length of /6 from this space for each established RIR and for each > emerging RIR. Allocations to each RIR will be from the appropriate > reservation. > > 2.2. RIRs. Each RIR may apply its own respective chosen allocation and > reservation strategy in order to meet the needs of its community and to > ensure the efficiency and efficacy of its work. Such reservations made by > an RIR will be considered as being allocated by that RIR when that RIR > applies for an allocation of address space from the IANA. > > 3. Initial Allocation. > > 3.1. Upon implementation of this policy IANA shall allocate to each > established RIR a /12 from the reservation established for each particular > RIR. > > 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from > the reservation set aside for that RIR. > > > 4. Subsequent Allocation. > > An RIR shall be eligible for an allocation of at least a minimal allocation > from the IANA when its current holdings are less than 50% of its 18 month > requirement or when it has less than 180 days of holdings available. The > IANA shall evaluate the requested allocation using a set of administrative > procedures that are mutually agreed to by the IANA and the NRO. This set of > procedures shall be enacted within 30 days of the implentation of this > policy. > > > 5. Announcement of IANA allocations to the RIRs > > When address space is allocated to a RIR, the IANA will send a detailed > announcement to the receiving RIR. The IANA will also make announcements to > all other RIRs, informing them of the recent allocation. > > The IANA will make appropriate modifications to the "Internet Protocol V6 > Address Space" page of the IANA website and may make announcements to only > its own global announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry they > have been allocated. > > > 8. Rationale: > > The current IANA allocation policy for IPv6 is an interim policy that was > promulgated in 1999. Operational experience has demonstrated the current > minimum allocation size is too small; that the built in reservation system > that must be followed by the RIRs does not allow for efficient and effective > management of the resource by the RIR; and does not provide for an well > known evaluation criteria. This document does not stipulate performance > requirements in the provision of services by IANA to an RIR in accordance > with the policy. Such requirements should be specified by appropriate > agreements between the NRO and ICANN. > > > 9. Timetable for implementation: Thirty days after ratification by the ICANN > Board of Directors in accordance with the global policy development process _______________________________________________

5 6

[ipv6-wg@ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation
by Jeroen Massar 20 Aug '04

20 Aug '04

For people not on the arin-council (not likely ;) or the ppml@arin lists: -----Forwarded Message----- From: "Sweeting, John" <John.Sweeting(a)teleglobe.com> To: 'ppml(a)arin.net' <ppml(a)arin.net> Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation Date: Thu, 19 Aug 2004 17:36:56 -0400 I am submitting the following proposal IAW ARIN's Internet Resource Policy Evaluation Process. In the interest of all I would like to disclose up front that the information used to prepare this template was provided by ARIN staff. ############################################ Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries 2. Author a. name: John Sweeting b. email: john.sweeting(a)teleglobe.com c. telephone: 703-766-3042 d. organization: ARIN Advisory Council 3. Proposal Version: 1 4. Submission Date: 8/17/04 5. Proposal type: new, global 6. Policy term: permanent 7. Policy statement: 1. Minimum Allocation Size. The minimum size of any allocation of IPv6 address space from IANA to an RIR is prefix length /12. If this address space is not sufficient to meet the needs of an RIR for a projected 18 month period, IANA shall allocate to that RIR the address space for which it can provide justification. 2. Reservation of Unicast Address space. 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 addresses beginning at binary value 001 (prefix length /3) for its allocations of unicast address space. In order to support regional aggregation of IPv6 address space IANA shall establish a reservation of a prefix length of /6 from this space for each established RIR and for each emerging RIR. Allocations to each RIR will be from the appropriate reservation. 2.2. RIRs. Each RIR may apply its own respective chosen allocation and reservation strategy in order to meet the needs of its community and to ensure the efficiency and efficacy of its work. Such reservations made by an RIR will be considered as being allocated by that RIR when that RIR applies for an allocation of address space from the IANA. 3. Initial Allocation. 3.1. Upon implementation of this policy IANA shall allocate to each established RIR a /12 from the reservation established for each particular RIR. 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from the reservation set aside for that RIR. 4. Subsequent Allocation. An RIR shall be eligible for an allocation of at least a minimal allocation from the IANA when its current holdings are less than 50% of its 18 month requirement or when it has less than 180 days of holdings available. The IANA shall evaluate the requested allocation using a set of administrative procedures that are mutually agreed to by the IANA and the NRO. This set of procedures shall be enacted within 30 days of the implentation of this policy. 5. Announcement of IANA allocations to the RIRs When address space is allocated to a RIR, the IANA will send a detailed announcement to the receiving RIR. The IANA will also make announcements to all other RIRs, informing them of the recent allocation. The IANA will make appropriate modifications to the "Internet Protocol V6 Address Space" page of the IANA website and may make announcements to only its own global announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. 8. Rationale: The current IANA allocation policy for IPv6 is an interim policy that was promulgated in 1999. Operational experience has demonstrated the current minimum allocation size is too small; that the built in reservation system that must be followed by the RIRs does not allow for efficient and effective management of the resource by the RIR; and does not provide for an well known evaluation criteria. This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with the policy. Such requirements should be specified by appropriate agreements between the NRO and ICANN. 9. Timetable for implementation: Thirty days after ratification by the ICANN Board of Directors in accordance with the global policy development process. 10. Meeting presenter: Elected AC Member or the President of ARIN. END OF TEMPLATE ################################################

4 5

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

20 Aug '04

On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning(a)vacation.karoshi.com wrote: > > So the whole delegation thing is broken. The int. TLD servers delegate > > ip6.int to imag.imag.fr which feels it self authoritative, but isn't > > in the NS RRset of the ip6.int zone. And ip6.int is delegated to > > munnari.oz.au which doesn't know about this (anymore). > > so... this was apparently enough to get the attention it > deserved. the long postponed migration from imag.imag.fr. > to ns3.nic.fr. is now "done" and imag.imag.fr. has been removed > from the NS list in the INT zone. > and munnari.oz.au has been removed. - more cleanup in the > next week or two. Well, two weeks down the road and things got even worse: NS list summary for ip6.int. from parent (int.) servers == flag.ep.net. ns3.nic.fr. y.ip6.int. == z.ip6.int. $ dig @flag.ep.net. int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740 $ dig @ns3.nic.fr int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334 $ dig @y.ip6.int int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872 $ dig @z.ip6.int int. SOA +norec ;; connection timed out; no servers could be reached So we have 3 out of 4 servers totally broken. Looks like the importance of ip6.int is way overstated by some folks. Regards, Daniel

6 6

[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] New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 18 Aug '04

18 Aug '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4600::/23 from the IANA in August 2004. You may want to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

[ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken
by Daniel Roesen 17 Aug '04

17 Aug '04

On Sat, Aug 14, 2004 at 09:17:56AM +0100, David Malone wrote: > 2.0.0.2.ip6.int has become completely unavailable in the last few > days, resulting in delays for people connecting from 6to4 addresses > via ssh and the like. 2.0.0.2.ip6.arpa is also broken in all colors. soa @ns.apnic.net. for ip6.arpa. has serial: 2004071900 soa @ns.icann.org. for ip6.arpa. has serial: 2004071900 soa @ns-sec.ripe.net. for ip6.arpa. has serial: 2004071900 dig @tinnie.arin.net. for SOA of parent (ip6.arpa.) failed ==> tinnie.arin.net IPv6 connectivity is broken: $ dig @69.25.34.195 ip6.arpa. SOA +short dns1.icann.org. hostmaster.icann.org. 2004071900 3600 1800 604800 10800 $ dig @2001:440:2000:1::22 ip6.arpa. SOA ; <<>> DiG 9.2.3 <<>> @2001:440:2000:1::22 ip6.arpa. SOA ;; global options: printcmd ;; connection timed out; no servers could be reached Found 0 NS and 0 glue records for 2.0.0.2.ip6.arpa. @ns.apnic.net. (AUTH) Found 0 NS and 0 glue records for 2.0.0.2.ip6.arpa. @ns.icann.org. (AUTH) Found 4 NS and 4 glue records for 2.0.0.2.ip6.arpa. @ns-sec.ripe.net. (AUTH) DNServers for ip6.arpa. === 3 were also authoritatve for 2.0.0.2.ip6.arpa. === 0 were non-authoritative for 2.0.0.2.ip6.arpa. ERROR: Found 2 diff sets of NS records === from servers authoritative for 2.0.0.2.ip6.arpa. WARNING: ns.apnic.net. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone WARNING: ns.icann.org. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone WARNING: ns-sec.ripe.net. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone ==> so although the three remaining NS for ip6.arpa have the same SOA serial, they obviously have a different view on the NS RRset for 2.0.0.2.ip6.arpa... and all are authoritative for 2.0.0.2.ip6.arpa. Now looking at the NS RRset ns-sec.ripe.net returns for 2.0.0.2.ip6.arpa: == ns-apnic.6to4.nro.net. ns-arin.6to4.nro.net. ns-lacnic.6to4.nro.net. == ns-ripe.6to4.nro.net. soa @ns-apnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 dig @ns-arin.6to4.nro.net. for SOA of 2.0.0.2.ip6.arpa. failed soa @ns-lacnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 soa @ns-ripe.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 ==> ns-arin.6to4.nro.net == tinnie.arin.net, so we have the same IPv6 reachability problem again What a mess all over... why do ns.apnic.net and ns.icann.org return NXDOMAIN when queried for the NS RRset for 2.0.0.2.ip6.arpa, but ns-sec.ripe.net returning one? It looks like the whole 2.0.0.2.ip6.arpa is missing in the ip6.arpa zone, and ns-sec.ripe.net is only by chance carrying the 2.0.0.2.ip6.arpa zone, thus returning the NS RRset. I wonder where's the right place to report such global (multi-RIR/org) DNS problems to, if not v6ops. I see no "global IPv6 operations" list, can anyone enlighten me? Best regards, Daniel

2 4

[ipv6-wg@ripe.net] Re: [address-policy-wg] Policy for allocation of IPv6 address space from IANA to RIRs
by Daniel Roesen 13 Aug '04

13 Aug '04

On Wed, Aug 11, 2004 at 09:04:21AM +0100, Jon Lawrence wrote: > Yes, doubling does seem unwise. > It would make sense (to me anyway) that once xx% of a /12 is allocated then > another /12 is issued to the RIR. Indeed. I see no point in unconditional doubling. I'm pretty confident that /12 blocks are large enough to serve a RIR long enough so that ordering a new /12 is not hampering anything. My suggestion would be to set aside a /8 per RIR (perhaps also a DNS reverse delegation for that) and allocate /12s to the RIRs upon their request. A RIR qualifies for a new /12 block as soon as nn% usage of the current /12 block is reached. nn might be 50% or more. As Randy suggests, the percentage should be low enough so that the RIRs can get new space without delaying allocation to LIRs (as it happens nowadays). Best regards, Daniel

3 2

[ipv6-wg@ripe.net] Policy for allocation of IPv6 address space from IANA to RIRs
by leo vegoda 10 Aug '04

10 Aug '04

Dear Colleagues, The Number Resource Organisation (NRO) has published a proposal for a policy for the allocation of IPv6 address space from the IANA to the RIRs. It is intended that this proposed policy should be agreed by all RIRs' open policy fora and then approved by the ASO and ICANN as a global policy. The proposal is available on our web site at: http://www.ripe.net/ripe/draft-documents/ipv6.html Comment on the proposal is sought. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC

9 15

[ipv6-wg@ripe.net] inet6num missing for allocation - more?
by Daniel Roesen 04 Aug '04

04 Aug '04

Hi, I've just noticed, that the allocation 2001:478::/32 is not registered in the RIPE DB: $ whois -h whois.ripe.net -r 2001:478::/32 | fgrep inet6num: inet6num: 0::/0 Could RIPE check wether this problem does exist for other allocations too? Or is EP.NET "special"? :-) Best regards, Daniel

2 2

RE: [ipv6-wg@ripe.net] inet6num missing for allocation - more?
by Wilfried Woeber, UniVie/ACOnet 04 Aug '04

04 Aug '04

>I've just noticed, that the allocation 2001:478::/32 is not registered >in the RIPE DB: But it is in ARIN's: > warin 2001:478:: OrgName: EP.NET, LLC. OrgID: V6EP Address: PO 12317 City: Marina del Rey StateProv: CA PostalCode: 90295 Country: US NetRange: 2001:0478:0000:0000:0000:0000:0000:0000 - 2001:0478:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:0478:0000:0000:0000:0000:0000:0000/32 NetName: EP-NET NetHandle: EP-NET-NET Parent: ARIN-001-NET NetType: Direct Allocation NameServer: FLAG.EP.NET NameServer: Z.IP6.INT Comment: RegDate: 2001-05-21 Updated: 2002-08-05 TechHandle: WM110-ARIN TechName: Manning, Bill TechPhone: +1-310-322-8102 TechEmail: bmanning(a)karoshi.com > ... Or is EP.NET "special"? :-) Who knows :-) >Best regards, >Daniel 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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 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

Re: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
by Doug Barton 22 Jun '04

22 Jun '04

Johan Ihren wrote: > Kurt Erik Lindqvist <kurtis(a)kurtis.pp.se> writes: > > >>>I guess if the RFC is there is because IANA requires it, so moving >>>this to historic will not work, instead updating it will do. >> >>Help me out here. Why would IANA require it? I don't remember there >>being an RFC telling IANA how to allocate other resources? What's so >>special about IPv6 addresses? > > > The lesson learned here is that IANA allocation policy based on > numbers specified in an RFC caused problems once. Then updating the > RFC to get around the problem is broken. That's just pushing the > problem out of sight with a clear promise of it coming back to bite us > sometime in the future. > > Moving the RFC to historic is one half of the solution. The other half > is IANA standing on their own legs (together with the NRO) on these > matters. Thank you for including me in this discussion. Rather than attempting to correct details of the history described in this thread (and which even if I was right it wouldn't matter too much since they happened before I took my current position in December of 2003) I would like to suggest a way forward. The current membership of the Internet Architecture Board (IAB) has expressed an interest in the direction in which IPv6 allocation policy proceeds. ICANN thinks that this interest is perfectly reasonable, and welcomes it, as well as their valuable insight on the relevant issues. My position on this issue has been clearly stated on numerous occasions going back to January of this year. It is not IANA's job to create policy. We will however be glad to participate in a discussion that is designed to lead to a policy, offering our unique perspective. An excellent example of how this process probably should work is the IPv4 global allocation policy that was developed in cooperation between the RIRs and IANA back in July 2003. http://www.ripe.net/ripe/draft-documents/iana-rir-allocation-policies.html That policy subsequently went through the policy fora in all 4 regions, and is currently awaiting finalization through the ASO process. A similar process needs to occur in relationship to IPv6 allocation policy on a global level. ICANN and the IAB stand ready to enter into such discussions, and eagerly await such an invitation from the RIRs. Between now and the time that such a policy is created, IANA's position is that it is not appropriate for us to attempt to be "creative" in this area. Doug -- Doug Barton General Manager, The Internet Assigned Numbers Authority

3 2