Though this is a good document it does not cater for the needs of Multinational Registries, i specifily asked for the MIR proposal to be included in this discussion. This document caters for the single LIR not mutiple LIR's in one very large pan EMEA network, which is still growing. I would like to see this included in the draft, or reasons why the community (not the NCC) are opposed to the MIR proposal for IPV6 (and ipv4 also). To date there has been no negative comments on the porposal which is why i am puzzled it is not included. Regards, Stephen Burley UUNET EMEA Hostmaster SB855-RIPE
Dear LIRs,
Following the discussions at the RIPE 39 meeting and on the mailing lists in all the RIR communities, please find below the latest developments concerning IPv6 address allocation policies. This proposal is based on requirements expressed by the RIPE community as well as those of the other RIR communities.
Please note that the text below is not a replacement of the current policy document, but rather a summary of the new IPv6 address allocation framework. Therefore this proposal is intended as input for further discussion in the RIPE community.
When formulating this framework, we were specifically taking the following feedback into account:
- The allocation criteria should be such that it is easy to obtain IPv6 address space.
- The size of the initial allocation should be large enough to allow flexibility in addressing infrastructure and customer sites.
This results in the following changes to previously discussed IPv6 allocation criteria:
1. to recognise existing infrastructure (both IPv4 and IPv6) where it exists and calculate IPv6 address needs based on existing networks.
2. to apply the slow start mechanism only for 'IPv6 only' networks without existing IPv4 infrastructure
3. to reduce the minimum allocation size for those IPv6 only networks (unless larger requirements are shown)
4. to measure the utilisation rate with the HD ratio rather than percentages
5. to make subsequent allocations when the HD ratio is reached
Kind Regards, Mirjam Kuehne RIPE NCC ----------------
1. Abstract
This document provides a set of proposed policies for the management of IPv6 address space, specifically concerning the allocation of address space allocated by Regional Internet Registries (RIRs) to organisations operating IPv6 networks.
2. Overview
Under the current system of management of global IP address space,
Regional
Internet Registries (RIRs) are responsible for allocation of address space to organisations within their respective geographic regions.
In 1999, the RIRs APNIC, ARIN and RIPE NCC published a provisional policy document for IPv6, which has been in operation since then. Since 2000, this document has been under review and discussion, and through this process many issues have been raised.
It is the aim of this document to propose a new policy framework for IPv6 address space management which takes into account the operational experience of the past 3 years, and addresses most if not all of the major issues raised through the open review process.
This document does not attempt to provide details of policy implementation, procedures or documentation; nor does it document requirements for management of address space which is allocated. These policies can be established globally or regionally as appropriate, based on global consensus regarding the fundamental principles described here.
3. Address Space Requirement for Initial Allocation
It is proposed to recognise existing network infrastructure and address utilisation (both IPv4 and IPv6). New IPv6 address needs are then based on these existing networks.
In assessing a request for an initial allocation, there are 3 possible cases to consider:
3.1. the requesting organisation has an existing IPv4 network which will be addressed by the new IPv6 allocation
3.2. the requesting organisation has an existing IPv6 network
3.3. the requesting organisation has no network at all
3.1. Case 1 - Existing IPv4 services
Where IPv6 address space is requested for addressing an existing IPv4 network, the address requirement is determined according to the structure and customer base of the existing IPv4 network. This only relates to the part of the network that will be migrated to IPv6.
Additional policies may require the return of IPv4 address space to the RIR or upstream ISP, in the case the existing network is renumbered to the new IPv6 space in future.
3.2. Case 2 - Existing IPv6 services
Where an IPv6 allocation is requested by an organisation to address infrastructure which is already addressed by IPv6 addresses from an upstream provider (or from the 6BONE), the address requirement is determined from the number of site addresses assigned by the organisation (as registered in the appropriate whois database).
Where existing address space is no longer used, it must be returned.
3.3. Case 3 - No existing IPv4 or IPv6 services
Where IPv6 address space is required by an organisation which has no existing infrastructure, the address requirement will be assessed according to network architecture plans and other documentation provided to the RIR within the request process. Such documentation be thorough enough to satisfy the RIR that the network deployment is genuine, however the specific details of documentation requirements will be defined separately.
4. Size of Initial Allocation
The amount of addresses allocated to an existing network, will be determined based on the existing infrastructure and address utilisation of that network.
For new networks without existing infrastructure, it is proposed to establish a minimum allocation for IPv6 address space. It is suggested to keep the size of the initial allocation relatively small (a /35 or smaller) and to determine the size of subsequent allocations based on the utilisation rate of the initial allocation (this is called slow start mechanism). This will allow easy access to IPv6 allocations for newcomers. At the same time possible wastage of address space and routing table growth will be limited.
5. Qualification for Subsequent Allocation
An organisation which has already received address space from an RIR may receive a subsequent allocation providing that its existing address space is utilised in accordance with these policies. As explained below, the HD-Ratio will be used to measure utilisation of the existing address space.
An organisation which is deploying substantial new network infrastructure may receive a subsequent allocation before it has reached the required utilisation threshold, providing that the address requirement would immediate cause the organisation to exceed the utilisation threshold. In such cases, the new network infrastructure will be examined by the RIR as if it is a request for a new network, and the RIR may require the same level of documentation detail, in order to approve the allocation.
6. Address Space Requirement for Subsequent Allocation
For subsequent allocations, the RIR should assess the address requirement according to the organisation's history of IP address usage, as well as its stated requirements for future development.
In general, the RIR should provide address space for a fixed time period of 2 years.
The above recommendation should be followed in cases where the organisation concerned has complied with all relevant address management policies. In other cases, the RIR may allocate for a shorter future timeframe, and require that identified problems be rectified before larger allocations are made.
7. IPv6 Utilisation Metric: the HD-Ratio
In IPv4, currently, a "utilisation threshold" of 80% is applied consistently in determining whether an IPv4 address pool is to be considered utilised, regardless of the size of that block. Consequently, an organisation which holds IP address space may not receive additional addresses until it has utilised at least 80% of the address space held.
For IPv6 is it proposed to assess utilisation according to the "HD-Ratio" rather than by a simple percentage. The HD-Ratio was proposed by Durand in "draft-durand-huitema-h-density-ratio-01.txt" (an adaptation of the original H-Ratio defined by Huitema in RFC-1715).
Using the HD-ratio we can establish a utilisation metric which allows percentage utilisation to decrease as the address space grows large. This is appropriate for management of the much larger blocks of address space under IPv6, and the likelihood of complex routing and allocation hierarchies within those address blocks.
More details about the HD ratio can be found in Appendix A.
Appendix A:
In the general case, where individual objects are allocated out of an arbitrary address space, the HD-Ratio is calculated as follows:
log(number of allocated objects) HD = -------------------------------------------- log(maximum number of allocatable objects)
Where the objects being allocated are IPv6 site addresses (/48s) assigned from an IPv6 prefix of length P, we can restate this formula as follows (where A is the number of /48 prefixes actually assigned):
log(A) log(A)
In other words, the utilisation threshold T, expressed as a number of individual /48 prefixes to be allocated from IPv6 prefix P, can be calculated as:
((48-P)*HD) T = 2
In accordance with the recommendations of draft-durand-huitema-h-density-ratio-01.txt, it is proposed in this draft to adopt an HD-Ratio of 0.8 as the utilisation threshold for IPv6 address space allocations.
The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.8
P 48-P Total /48s Threshold Util%
48 0 1 1 100.0% 47 1 2 2 87.1% 46 2 4 3 75.8% 45 3 8 5 66.0% 44 4 16 9 57.4% 43 5 32 16 50.0% 42 6 64 28 43.5% 41 7 128 49 37.9% 40 8 256 84 33.0% 39 9 512 147 28.7% 38 10 1024 256 25.0% 37 11 2048 446 21.8% 36 12 4096 776 18.9% 35 13 8192 1351 16.5% 34 14 16384 2353 14.4% 33 15 32768 4096 12.5% 32 16 65536 7132 10.9% 31 17 131072 12417 9.5% 30 18 262144 21619 8.2% 29 19 524288 37641 7.2% 28 20 1048576 65536 6.3% 27 21 2097152 114105 5.4% 26 22 4194304 198668 4.7% 25 23 8388608 345901 4.1% 24 24 16777216 602249 3.6% 23 25 33554432 1048576 3.1% 22 26 67108864 1825677 2.7% 21 27 134217728 3178688 2.4% 20 28 268435456 5534417 2.1% 19 29 536870912 9635980 1.8% 18 30 1073741824 16777216 1.6% 17 31 2147483648 29210830 1.4% 16 32 4294967296 50859008 1.2% 15 33 8589934592 88550677 1.0% 14 34 17179869184 154175683 0.9% 13 35 34359738368 268435456 0.8% 12 36 68719476736 467373275 0.7% 11 37 137438953472 813744135 0.6% 10 38 274877906944 1416810831 0.5% 9 39 549755813888 2466810934 0.4% 8 40 1099511627776 4294967296 0.4% 7 41 2199023255552 7477972398 0.3% 6 42 4398046511104 13019906166 0.3% 5 43 8796093022208 22668973294 0.3% 4 44 17592186044416 39468974941 0.2% 3 45 35184372088832 68719476736 0.2% 2 46 70368744177664 119647558364 0.2% 1 47 140737488355328 208318498661 0.1% 0 48 281474976710656 362703572709 0.1%