February 2005 - address-policy-wg

IPv6 Policy Clarification - Initial allocation criteria "c)"
by Laura Cobley 19 Jul '05

19 Jul '05

Dear Colleagues, As explained in the email sent on Mon, 14 Jun 2004: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2004/msg00240.html This is the second mail request for clarification of the IPv6 Address Allocation and Assignment Policy. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "c)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation" LIRs who operate closed/private networks appear not to qualify because the address space in these networks will not be advertised. Was this the community's intention? Best Regards, Laura Cobley Registration Services RIPE NCC

9 12

HD ratio policy proposal
by BIDRON Alain ROSI/DAS 30 Jun '05

30 Jun '05

Dear Colleagues Referring to the minutes of the last RIPE Policy Working Group meeting and to the action list as updated during that meeting, I have to make a formal proposal on use of HD ratio for IPV4. Here is this policy proposal. In order to be consistent with the PDP Draft proposal coming from Rob Blokzijl I have used the template provided in the new PDP proposal. Best regards. Alain _________________________________________________________ 1. Policy Proposal Name: IPv4-HD-Ratio 2. Author a. name: Alain Bidron b. e-mail: alain.bidron(a)francetelecom.com c. telephone: +33 1 44 44 27 75 d. organisation: France Telecom 3. Proposal Version: V0 4. Submission Date: 02/02/2005 5. Suggested WG for discussion and publication: Address Policy WG 6. Proposal type: modify 7. Policy term: permanent 8. Summary of proposal: Internet address space is managed hierarchically: - IANA allocates space to Regional Internet Registries (RIRs). - RIRs allocate space to Local Internet Registries (LIRs). - LIRs assign space to End Users. At each level, some address space may be reserved for future expansion and/or efficient aggregation. As more hierarchical levels are introduced, the overall efficiency of the address space usage decreases. The HD ratio (Host-Density ratio) is a way to measure address space usage [RFC 3194]. The HD ratio value can relate to a percentage of usage, which decreases as the amount of address space grows. This allows for the decreasing efficiency that occurs with more hierarchical levels. The HD ratio is currently used to measure IPv6 address space usage [ipv6-address-policy]. The IPv6 Address Allocation and Assignment Policy considers a block of IPv6 address space to be ‘used’ when its HD ratio reaches 0.80. This is a manageable figure ("values of 80% or less correspond to comfortable trade-offs between pain and efficiency" [RFC 3194]). This document proposes using the HD ratio to measure IPv4 usage. The proposed value of the HD ratio for IPv4 is 0.96. 9. Policy text: a. Current: "An LIR may receive an additional allocation when about eighty percent (80%) of all the address space currently allocated to it is used in valid assignments or sub-allocations." b. New: "An LIR may receive an additional allocation when its total allocated address space usage meets the HD-Ratio value of 0.96." 10. Rationale: a. Background The current document, “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” [ipv4-address-policy], considers a block of IPv4 addresses to be ‘used’ when 80% of the addresses within the block have been sub-allocated or assigned. This is applied to all address blocks, regardless of size. Current policies assume a hierarchical system of address space delegation. However, they do not make any allowance for hierarchical management within allocated address space. For LIRs in particular, a hierarchical approach is often required for assignment of address space to service elements such as customer networks, individual Points of Presence (PoPs), regionalised topologies, and even distinct ISP products. Small network infrastructures may require simple hierarchies, but large infrastructures can require several levels of address space subdivision. These levels of hierarchy are not recognised by the current policy framework and are highly restricted by the "80% rule". As a result, managing large blocks is often difficult, requiring large internal routing tables and/or frequent renumbering of internal address blocks. One of the goals of the RIR system is to avoid unnecessary depletion of IPv4 address space. However, address management policies must also be practical in terms of how much management overhead they cause. When large amounts of address space are involved, the "80% rule" can result in more work for an LIR. Basing usage on the HD ratio should lead to equal levels of management overhead across the board, rather than penalising the holders of large address blocks. b.Impact To see a rough estimation of the immediate impact of this proposal, an HD Ratio value of 0.96 was applied to the average amount of address space held by an LIR in the RIPE NCC Service Region. This showed that on average, LIRs would qualify for an additional allocation block when they have assigned or sub-allocated about 59% of their allocated address space. c.Arguments supporting the proposal. 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 The local Internet registries using the 80% criteria may continue to do so and will not be impacted by the new policy. The RIPE NCC will provide support to minimise complicated calculations or administrative burden to LIRs. d. Arguments opposing the proposal. This proposal will have some limited impact on IPV4 address consumption. Appendix A. The HD ratio The HD ratio is calculated as follows [RFC 3194]: HD = log(U)/log(S) Where: S is the size of the address block concerned, and U is the number of addresses used. Note: The current IPv4 policy considers addresses to be ‘used’ once they are assigned or sub-allocated by the LIR. Appendix B. Selection of HD ratio value We should decide an appropriate HD ratio value on a rational basis. To do this, we make certain assumptions about the number of "hidden" hierarchical levels involved in managing address blocks of various sizes. If we assume there is 80% usage at each level, we can easily calculate the overall usage. The following table proposes a set of hierarchical levels which we can reasonably expect within different amounts of address space. If a usage of 80% is achieved at each hierarchical level, then the overall usage will be (0.80 to the power of "n"). It is then possible to calculate HD ratio values from this value. Size range Level Utilisation HD ratio (prefix) (n) (0.80**n) (calculated) /24 to /20 1 80% .960 to .973 /20 to /16 1.5 72% .961 to .970 /16 to /12 2 64% .960 to .968 /12 to /8 2.5 57.2% .960 to .966 /8 to /4 3 51.20% .960 to .966 The levels of hierarchy listed above are based on assumptions about the likely size and structure of LIRs holding address blocks of these sizes. A reasonable HD ratio value may be 0.96 (a round figure which occurs within most of these ranges) from the table above. The following table gives the usage requirements for IPv4 address blocks from /24 to /8 for this value. IPv4 Addresses Addresses Util% prefix total used 24 256 205 80.11% 23 512 399 77.92% 22 1024 776 75.79% 21 2048 1510 73.71% 20 4096 2937 71.70% 19 8192 5713 69.74% 18 16384 11113 67.83% 17 32768 21619 65.98% 16 65536 42055 64.17% 15 131072 81811 62.42% 14 262144 159147 60.71% 13 524288 309590 59.05% 12 1048576 602249 57.43% 11 2097152 1171560 55.86% 10 4194304 2279048 54.34% 9 8388608 4433455 52.85% 8 16777216 8624444 51.41% Note: This table provides values for CIDR blocks, but the same calculations can be made for non-CIDR blocks. As an example, an LIR holding a total amount of address space equal to a /16 would be able to receive more address space when they had sub-allocated or assigned 64.17% of that space; while an LIR holding a /9 would be able to receive more space when they had sub-allocated or assigned 52.85% of their address space. Appendix C. References [RFC 3194] "The Host-Density ratio for address assignment efficiency: An update on the H ratio", A. Durand, C.Huitema, November 2001. [ipv6-address-policy] RIPE NCC document: "IPv6 Address Allocation and Assignment Policy" http://www.ripe.net/ripe/docs/ipv6policy.html [ipv4-address-policy] RIPE NCC document: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" http://www.ripe.net/ripe/docs/ipv4-policies.html

2 2

Re: [ipv6-wg@ripe.net] IPv6 access to K-root
by Iljitsch van Beijnum 02 Mar '05

02 Mar '05

On 2-aug-04, at 19:42, Andrei Robachevsky wrote: > K-root server has now IPv6 transport enabled. > k.root-servers.net. AAAA 2001:7fd::1 > A 193.0.14.129 > This information is also available from www.root-servers.org webiste. Since the ARIN micro allocation policy creates some problems, I was curious what kind of address space RIPE uses for k-root. A /32 "macro allocation", it turns out: inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary. Iljitsch van Beijnum

14 70

Re: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root
by Iljitsch van Beijnum 28 Feb '05

28 Feb '05

On 28-feb-05, at 9:45, Marco Davids (SARA) wrote: >> There is no special case policy for (unicast) ccTLD name servers, for >> major search engines, big software vendor download sites, etc. -> find >> an upstream provider, get an IPv6 address block, and enter that in the >> relevant DNS zones. >> Of course the underlying question returns to "how to do IPv6 >> multihoming >> for A Special End Site". > I think gTLD's and ccTLD's would certainly qualify for their own IPv6 > space (for the purpose of being able to do proper multihoming). I strongly disagree. The DNS protocol has its own built-in redundancy, and changing addresses for TLD servers is not prohibitively difficult. So I see no reason why they should have PI addresses, especially since there is a significant number of TLDs and they all use several addresses. If those addresses would all become PI this would probably double the IPv6 routing table size at this point. (Granted, it's very small now, but still.) If TLD servers are anycast that _could_ be a reason for giving them PI space, but I think the TLD community first has to come up with coordinated plan for this, rather than just start giving out PI blocks and play "voldongen feit" game. (Sorry, it's monday morning, can't think of the English translation. In French it's "fait accompli".)

1 0

Re: [ipv6-wg@ripe.net] IPv6 access to K-root
by Wilfried Woeber, UniVie/ACOnet 25 Feb '05

25 Feb '05

>At the time the policy was written, people thought that this way would >be better. On the subject of root servers, people tend to be conservative. ...and I think this is a very reasonable approch. >OTOH, no policy that can't be changed if people think otherwise today. Yes, this is what we have this forum for. <AC hat on> Otoh, I think we (the community, not the registry) should take care of providing some stability in address distribution policy. Starting to play "channel hopping" on the management plane is not going to be funny for those who provide these services for us. </AC hat on> Let me add that I think the same holds true by and large for ccTLD operators... >Gert Doering > -- NetMaster Wilfried.

1 0

Re: [address-policy-wg] IPv6 access to K-root
by Wilfried Woeber, UniVie/ACOnet 25 Feb '05

25 Feb '05

>As I said above, the roots are a special case - end of story - we cannot live >without them (slight exaggeration). Why can't a /48 be set a side for the >root servers in each region (or even a global /32). 1st answer that springs to my mind: SPOF. >Jon DoSing the whole gang would only require me to break or target 1 prefix... Wilfried.

1 0

New Document available: RIPE-343
by RIPE NCC Document Announcement Service 23 Feb '05

23 Feb '05

[apologies for duplicate e-mails] New RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-343 Title: IPv6 Address Space Management Author: Paul Wilson, Raymond Plzak, Axel Pawlik Date: 22 February 2005 Format: PS=53986 TXT=13567 Obsoletes: ripe-261 Short content description ------------------------- This document provides the management process for IPv6 global unicast address space whereby address allocations are made from a single global pool according to a "sparse allocation" algorithm. In this version, previously published as ripe-261, we fixed an error in the 6-bit address space table. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/ipv6-sparse.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-343.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-343.txt plain text version Kind Regards, RIPE NCC Document Announcement Service

3 2

IPv4 assignment to resident user
by Jaka Erjavec 07 Feb '05

07 Feb '05

Dear colleagues, I was searching www.ripe.net website for a document where it says that IPv4 block can NOT be allocated to resident user (not company). Can you, guys, please point me to appropriate url? Thank you! Jaka

6 8

[Fwd: [apops] APNIC new IPv4 addresses]
by leo vegoda 07 Feb '05

07 Feb '05

Dear Colleagues, I'm forwarding this announcement, on request. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Call for Comments on the WGIG Draft Working Papers
by Axel Pawlik 04 Feb '05

04 Feb '05

>Dear Colleagues, > >As you may be aware the <http://www.itu.int/wsis/>World Summit on the >Information Society (WSIS) requested the United Nations Secretary-General >to establish a Working Group on Internet Governance (WGIG). > >A series of 'draft working papers' prepared by WGIG members can be found at: > >http://www.wgig.org/working-papers.html > >A template to submit comments on the draft papers can be found at: > >http://www.wgig.org/docs/comment-template.doc > >As stated on the WGIG website: > >"Governments and all stakeholders are invited to comment on these papers, >preferably by making use of this template. Due consideration will be given >to all comments, but use of the template will facilitate processing >feedback. All comments received from governments and WSIS accredited >entities by 11 February 1200 hours GMT will be posted on this website. >Comments by other entities or individuals will also be posted, provided >they are relevant to the issues under discussion." > >Regards, > >Axel Pawlik >Managing Director >RIPE NCC

1 0