- address-policy-wg - mailman.ripe.net

draft-hain-ipv6-pi*
by Tony Hain 23 Sep '04

23 Sep '04

Per request, the pointers to the current PI drafts are: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-07.txt http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-07.txt As the USE draft discusses, the exchange points are likely to have a more prominent role than they do in the PA deployment model. For the obvious discussion about how this is impacted by natural impediments, there is an example for exception prefixes at: http://www.tndh.net/~tony/ietf/GrandCanyon.htm Depending on where these prefixes aggregate, there may or may not be any need for distributing these exception prefixes beyond one exchange point. In any case the only entities that need to know the detail are the ones directly involved in sorting it out. Tony

1 0

Additional supporting document for IANA->RIR IPv6 policy proposal
by Dominic Spratley 17 Sep '04

17 Sep '04

Dear Colleagues, The following informational paper "IPv6 address space management" was posted to the APNIC sig-policy mailing list by Geoff Huston, APNIC Secretariat. We have forwarded it to the Address Policy Working Group mailing list for your information. The document can also be found at: http://www.apnic.net/mailing-lists/sig-policy/archive/2004/08/msg00066.html Best regards Dominic Spratley Registration Services Manager RIPE NCC

1 0

Re: ETNO comments on AD ratio for IPv4 addresses allocation
by Wilfried Woeber, UniVie/ACOnet 16 Sep '04

16 Sep '04

> [ ... ] >Findings >1- This proposal fairly takes into account addressing hierarchies used in >large and extra-large registries and introduces a useful level of >flexibility for those registries. >2- The Local Internet Registries using the 80% criteria may continue to do >so and will not be impacted by the new policy. >3- Complicated calculation or administrative burden should be easily avoided >to registries choosing this method using simple chart or software through >LIR portal. >4- As analysed by APNIC, the impact on address consumption is limited to a >maximum around 20% and can be easily controlled and monitored using a rather >conservative approach (AD ratio of 0.966). Up to this point it sounds reasonable and well-balanced to me, >5- This impact can be partly counterbalanced by reducing the number of small >and extra-small registries whose existence is only justified by management >overhead of large registries with current 80% criteria, and has a positive >impact on address aggregation. but that particular reasoning in "5-": "whose existence is only justified by management overhead of large registries..." seems to be slightly off the mark? >6- No additional impact on registrations is seen in RIPE region, as >infrastructure assignments are already registered in the database. > [ ... ] 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

ETNO comments on AD ratio for IPv4 addresses allocation
by Debecker J.L. 16 Sep '04

16 Sep '04

RIPE Dear Sir, Madam, ETNO, representing 41 major telecom operators from 34 European countries, has studied the proposal to replace the fixed utilisation criteria of 80% in IPv4 address space allocation, by criteria based on AD (Assignment Density) ratio. Our conclusions are formulated in the attached Expert Contribution EC064. The document is the unanimous opinion of ETNO Members represented in the ETNO Frequency Management Working Group and has been endorsed by the ETNO Board. We are all prepared to discuss these comments in more detail and whenever useful. ETNO will be pleased to contribute to the further development of Europes views on the issue. Best regards, Michael Bartholomew ETNO Director ------------------------- September 2004 ETNO Expert Contribution on AD ratio for IPv4 addresses allocation Executive Summary ETNO (1) has considered the proposal to replace the fixed utilisation criteria of 80% in IPv4 address space allocation, by a criteria based on AD (Assignment Density) ratio. ETNO strongly support the proposal and suggest selecting an AD ratio of 0.966. ETNO further suggest to the RIRs to monitor the impact of this measure on address consumption and periodically report on it to the addressing community. Background During the RIPE 48 meeting in Amsterdam, a proposal was presented by APNIC to replace the fixed utilisation criteria of 80% to request additional IPv4 addresses blocks, by a criteria based on "AD ratio" value. This ratio value corresponds to a logarithmic scale and corresponds to a percentage utilisation, which decreases as the size of the address space grows. The presentation can be downloaded at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-hd-ratio.p df The decision was made to take the discussion to the RIPE Address-policy working group mailing list and to ask for some feed back from the community. As most European Telecommunications Network Operators' Association 1(ETNO) members are large or extra-large Local Internet Registries in Europe, representing an important part of these categories in the RIPE region, this proposal was considered and analysed with attention. Findings 1- This proposal fairly takes into account addressing hierarchies used in large and extra-large registries and introduces a useful level of flexibility for those registries. 2- The Local Internet Registries using the 80% criteria may continue to do so and will not be impacted by the new policy. 3- Complicated calculation or administrative burden should be easily avoided to registries choosing this method using simple chart or software through LIR portal. 4- As analysed by APNIC, the impact on address consumption is limited to a maximum around 20% and can be easily controlled and monitored using a rather conservative approach (AD ratio of 0.966). 5- This impact can be partly counterbalanced by reducing the number of small and extra-small registries whose existence is only justified by management overhead of large registries with current 80% criteria, and has a positive impact on address aggregation. 6- No additional impact on registrations is seen in RIPE region, as infrastructure assignments are already registered in the database. Conclusion ETNO strongly supports this proposal and suggest selecting a conservative AD ratio value of 0.966. ETNO also suggest to the RIRs to monitor the use of this facility and its impact on address consumption, and periodically report on it to the addressing community. (1) The European Telecommunications Network Operators' Association is representing 41 major companies from 34 European countries, providing electronic communications networks over fixed, mobile or personal communications systems. ETNO's primary purpose is to establish a constructive dialogue between its member companies and actors involved in the development of the European Information Society to the benefit of users. More information on ETNO can be found at: www.etno.be ETNO Expert Contribution EC064 (2004/09)

1 0

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 13 Sep '04

13 Sep '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:5000::/20 from the IANA in September 2004. You may wish 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

RIPE 49 Address Policy WG Draft Agenda
by Andrea Borgato 09 Sep '04

09 Sep '04

Hi All, Please see below the RIPE Address Policy WG Draft Agenda Day 1: Tuesday, 21 September 2004, 16:00 - 17:30 Day 2: Thursday, 22 September 2004, 09:00 - 10:30 Room: Medici A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 48: http://www.ripe.net/ripe/wg/address-policy/r48-minutes.html B. RIPE NCC and other Updates (Filiz Yilmaz, RIPE NCC) - RIPE NCC policy implementation & regional statistics. - Policy discussion and decisions in other RIR regions - Internet Number Resource statistics C. ICANN ASO AC Update (TBD, ICANN ASO AC) D. ICANN ASO AC - A View From Outside (A volunteer) E. Discussion Resulting From ICANN ASO Presentations F. Policy Development Process Hans Petter Holen, et al G. Policy Discussion - IPv6 (changes to the initial allocation criteria) Andy Furnell, LINX - Policy for allocation of IPv6 address space from IANA to RIRs Paul Wilson, APNIC - Whois Registration (What should be in Whois and why) Eva Ericsson Rabete, TeliaSonera --Possible topics-- - Paul Wilson's updated proposal: HD Ratio for IPv4 Allocations Y. Open Microphone Z. AOB Andrea Borgato - RIPE Address Policy WG co-chair

1 0

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

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

Re: [address-policy-wg] Re: Policy for allocation of IPv6 address space from IANA to RIRs
by Wilfried Woeber, UniVie/ACOnet 20 Aug '04

20 Aug '04

>Well, clearly ICANN and the U.S. watch the IANA because the IANA >an activity which the DOC subcontracts to ICANN to perform. Exactly. > The IANA is not an organization and it has no independent status. It >just happens to be the historical name for some of the functions of ICANN Exactly. >so for convenience and clarity, the name remains assigned to that set of >functions. For clarification read this contract that ICANN has signed with >the DOC on behalf of the U.S. Government. Indeed. And given the world, some governments, and ICANN as they are these days, I (personally) do not consider that structure to be the most stable and resilient setup that I'd rather have in place to control global resource distribution. Wilfried.

1 0