|
This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 20, 2005.
Copyright (C) The Internet Society (2004).
This document provides a description of the management process that is proposed for use by the Regional Internet Registries (RIRs) in managing global unicast IPv6 address resources. The document describes the proposed process of address allocation that is undertaken by the Internet Assigned Numbers Authority (IANA) to an RIR, as well as the RIRs' proposed address management process, whereby address allocations are made from the managed address block according to a "sparse allocation" algorithm. This sparse allocation management process is designed to maximise aggregation of address space within the confines of each allocated block, ensuring that most ISPs and Local Internet Registries (LIRs) retain a single aggregate address prefix as they grow.
Under the system of management of global IP address space, RIRs are responsible for the allocation of address space to organisations within their respective geographic regions.
RIRs receive address space periodically from the IANA, and then manage that address space as a local pool from which subsequent allocations are made to organisations within their regions. RIRs individually use various allocation techniques within their respective pools of address space (including sparse allocation techniques), in an attempt to maximise the likelihood that the initial and subsequent allocations to individual ISPs are able to be aggregated into a single unit and capable of being advertised in a unitary manner within the context of the Internet's inter-domain routing system.
Under this system, the ability to sustain a single aggregate of allocated address space for each ISP is limited by several factors. In the context of management of IPv4 addresses, for example, where a similar aggregation objective holds, these factors include the requirement for RIRs to utilise their existing pool of addresses to a level of 80% prior to requesting more address space from IANA, as well as the relatively small size of the address pools held by RIRs at any one time. This implies that RIRs cannot hold open address blocks that allow expansion of address allocations within a single aggregate indefinitely, and, as a consequence, over a period of several years, a single large ISP may receive a number of discontiguous allocations from its RIR.
The address registry management system for IPv6 described here avoids much of these problems of levels of fragmentation of the IPv6 address space through the allocation of address blocks from the IANA to the RIRs of a sufficient size that takes into account both the RIRs' sparse allocation practice and the desire to undertake ISP and LIR allocations from an address block that can preserve aggregation windows per ISP or LIR for periods of between one and two years per allocated entity. The sparse allocation management scheme is intended to maximize the room for future expansion of each allocation as a single aggregateable address block.
The existing IPv6 address allocations use a threshold metric of address utilization efficiency termed the "HD-Ratio" (described in RFC3914Durand, A. and C. Huitema, The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio, November 2001.[2]). This metric takes into account a commonly observed aspect of address deployment that the efficiency of a deployment drops as the size of the deployment increases.
It is proposed that IANA allocates IPv6 address blocks to the RIRs using an allocation unit of a /12.
It is anticipated that the RIR will manage each allocated address block according to methods of its own choosing, including but not limited to the sparse allocation mechanisms described in this document.
The framework of management of IPv6 address space is described in a number of source documents. An overview of this documentation is provided here.
The range of addresses managed within this framework is the address pool termed the "Global Unicast" IPv6 address pool. This pool is defined in RFC3513 [1]Hinden, R. and S. Deering, Internet Protocol Version 6 (IPv6) Addressing Architecture, April 2003. as the address block with the prefix 2000::/3.
"The rest of the global unicast address space (approximately 85% of the IPv6 address space) is reserved for future definition and use, and is not to be assigned by IANA at this time." (RFC 3513Hinden, R. and S. Deering, Internet Protocol Version 6 (IPv6) Addressing Architecture, April 2003.[1])
Allocations of Global Unicast address space to RIRs are described by RFC2450Hinden, R., Proposed TLA and NLA Assignment Rules, December 1998.[3]. This document uses the (now deprecated) terminology of Format Prefix (FP), Top Level Aggregation Identifier (TLA),and Sub-Top-Level-Aggregation Identifier (Sub-TLA).
The structure is these fields, as defined by RFC2450Hinden, R., Proposed TLA and NLA Assignment Rules, December 1998.[3], is shown in Figure 1.
| 3 | 13 | 13 | 19 |
+----+----------+---------+---------------+
| FP | TLA | Sub-TLA | NLA |
| | ID | | ID |
+----+----------+---------+---------------+
IPv6 Address Structure (after RFC2450Hinden, R., Proposed TLA and NLA Assignment Rules, December 1998.[3]
| Figure 1 |
The IANA-to-RIR allocation framework was described in RFC2450 as follows:
"The IANA will assign small blocks (e.g., few hundred) of Sub-TLA ID's to registries. The registries will assign the Sub-TLA ID's to organizations meeting the requirements specified in Section 5.2. When the registries have assigned all of their Sub-TLA ID's they can request that the IANA give them another block. The blocks do not have to be contiguous." (RFC 2450Hinden, R., Proposed TLA and NLA Assignment Rules, December 1998.[3], section 5.1)
A Sub-TLA in this context is a /29 address block, and "a few hundred" Sub-TLAs is either 256 or 512 Sub-TLAs if using a bit-aligned address management regime. RFC2450 appears to propose IANA assignments using a /21 prefix (256 Sub-TLAs) or a /20 prefix (512 Sub-TLAs).
The initial IANA allocations were documented in RFC2928Hinden, R., Deering, S., Fink, R. and T. Hain, Initial IPv6 Sub-TLA ID Assignments, September 2000.[4]. These initial assignments were smaller than that proposed in RFC2450, and RFC2928 notes that:
"The initial Sub-TLA ID assignments to IP address registries are in blocks of 64 Sub-TLA IDs." (RFC2928Hinden, R., Deering, S., Fink, R. and T. Hain, Initial IPv6 Sub-TLA ID Assignments, September 2000.[4])
These initial allocations were in units of /23 address blocks. The IANA IPv6 Sub-TLA Assignment registryIANA, IPv6 Top Level Aggregation Identifier Assignments, August 2004.[5] lists these allocations, and also all subsequent allocations, with a common allocation unit of a /23 from the sub-TLA assignment registry.
It is noted that the terminology of TLAs and Sub-TLAs has been deprecated within the context of the IPv6 Addressing Architecture specifications (RFC3513Hinden, R. and S. Deering, Internet Protocol Version 6 (IPv6) Addressing Architecture, April 2003.[1]), but the practice of IANA IPv6 allocations to RIRs using a /23 address block remains in place.
IPv6 allocations from RIRs to LIRs and ISPs is described within the framework of a coordinated policy across the RIRs [6]IANA, IPv6 Address Allocation and Assignment Policy, June 2002.. The goals of the address management function include an outcome of address aggregation:
"RIRs should apply practices that maximize the potential for subsequent allocations to be made contiguous with past allocations currently held." (IPv6 Address Allocation and Assignment PolicyIANA, IPv6 Address Allocation and Assignment Policy, June 2002.[6], Section 3.4)
And in reference to potential conflicts of goals of the distribution function:
"In IPv6 address policy, the goal of aggregation is considered to be the most important." (IPv6 Address Allocation and Assignment PolicyIANA, IPv6 Address Allocation and Assignment Policy, June 2002.[6], Section 3.8)
The document references the minimum size of IPv6 allocations as a /32, and proposes that the determination of the allocation will be based on the application of the HD-Ratio metric to the applicant's proposed IPv6 deployment, with a threshold HD-Ratio value of 0.8 being specified as a means of determining an initial allocation size. However, it is envisaged within this policy framework that established ISPs would be eligible for potentially much larger initial allocations.
IPv6 Address Allocation and Assignment PolicyIANA, IPv6 Address Allocation and Assignment Policy, June 2002.[6]
The RIR allocation to LIRs and ISPs uses a doubling function for subsequent allocations, namely:
"When an organization has achieved an acceptable utilization for its allocated address space, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left. (IPv6 Address Allocation and Assignment PolicyIANA, IPv6 Address Allocation and Assignment Policy, June 2002.[6], Section 5.2.3)
Allocations from the RIRs' IPv6 managed address pools may be determined according to a Sparse Allocation (or "binary-chop") algorithm, designed to maximise aggregation of address blocks allocated. In order for this method to produce effective results in the long-term, the source address block from which allocations are made should be as large as reasonably possible.
Under the sparse allocation system, the start addresses for successive allocations are generated according to a binary chop algorithm, as illustrated below. For example, within a 6-bit address space, the first 8 start addresses would be as follows:
Seq# Address Decimal
1 000000 00
2 100000 32
3 010000 16
4 110000 38
5 001000 08
6 101000 40
7 011000 24
8 111000 56
Sparse Allocation using Binary Chop
| Figure 2 |
The following illustration shows this 6-bit address space (comprising 64 locations), and the location of the first 8 allocations to be made (according to their sequence number), according to the above list. The initial allocation is made at the start of the address block. The second allocation divides the block in half. The third allocation divides the first half of the address block into quarters, and the fourth divides the other half into quarters. Sparse allocation attempts to maximize the size of the expansion windows at all times.
+---------------------------------------------------------------+
| . . . . . . . |
|-------|-------|-------|-------|-------|-------|-------|-------+
^ ^ ^ ^ ^ ^ ^ ^
1 | | | | | | |
| | | 2 | | |
| 3 | | | |
| | | 4 |
5 | | |
| 6 |
7 |
8
Sparse Allocation using Binary Chop
| Figure 3 |
The effect of the sparse allocation algorithm is to successively subdivide the largest of each remaining block of unallocated address space into 2 equal parts, the first being left to accommodate growth of an existing allocation, and the second part being made as a new allocation.
As more allocations are made from the address block the free space will become progressively fragmented, and the maximal size of the free block pool will decrease. The progressive operation of this algorithm ensures that the size of the largest free block is at most 1 bit longer than the smallest. The weakness of this approach is that it implies that a large address pool can become excessively fragmented in response to a sustained sequence of minimal address allocation requests, leading to an inability to meet a large allocation request, or an inability to meet a requirement to undertake an additional allocation in an adjacent address block.
Depending on the rate of allocation, and the rate of growth of individual allocations, the avoidance of fragmentation will need to be addressed eventually. A technique is proposed here that attempts to mitigate the extent to which address pool fragmentation causes fragmentary (non-aggregateable) allocations.
The additional information used in such an approach is the growth rate of each entity that has received an allocation. The modified selection algorithm is to perform a binary chop allocation such that the allocation maximizes the time before the first 'collision', where an allocation window immediately adjoins the next allocation in sequence. Growth rates are derived from reallocation frequency, where reallocations have been performed, and where no growth rate information is available an initial growth rate needs to be assumed.
For each allocation address block, a growth rate is calculated, reflecting the recent history of allocation window expansions. The associated aggregate allocation projected lifetime for the block can be calculated by dividing the remaining adjacent unallocated space by this growth rate. The selection aggregate allocation projected lifetime can be calculated by performing a binary chop on the unallocated space within the allocation address block, and dividing the remaining allocation space by the growth rate.
To perform an allocation selection each unallocated space is tested by performing a binary chop and calculating the selection aggregate allocation lifetime on the existing allocated block, and on the created initial allocation block. The minimum of these two time values is the lifetime for that particular selection position. The selection position that offers the maximal lifetime is the one used for this allocation.
A statement of the rate-controlled sparse allocation algorithm is as follows:
In order to ensure that sufficient space is held in reserve for larger allocations the address pool may be seeded with a number of large allocation reservations, useable only for allocations of a certain minimum size.
The outcomes of this algorithm is that smaller allocations tend to cluster together, while larger initial allocations with high growth rates tend to have their expansion window held intact for longer periods. This, in turn, preserves the ability of the address pool to service expansion windows in a more effective manner than a simple binary chop algorithm.
The relative performance of the sequential allocation algorithm, the sparse allocation algorithm and the rate-managed sparse allocation algorithm are indicated in Figure 4, based on simulation of an IPv6 registry function using each algorithm.
Fragmentation Rates
Use Level Sequential Sparse Rate-Sparse
0% 0.0% 0.0% 0.0%
10% 0.0% 0.1% 0.1%
20% 1.8% 1.5% 1.4%
30% 3.2% 3.2% 1.9%
40% 6.8% 3.2% 2.6%
50% 13.7% 3.9% 3.0%
60% 23.4% 4.5% 3.4%
70% 27.0% 4.9% 3.6%
80% 31.0% 5.3% 4.3%
90% 33.7% 4.4% 4.2%
100% 28.0% 3.9% 3.0%
Fragmentation Rates for various allocation sizes
| Figure 4 |
| Figure 5 |
The requirements relating to the size of the address block allocated by IANA to a RIR include that it should be sufficient for the RIR to service all forms of allocations, and make reasonable allowance for additional allocations that preserve aggregation properties. The anticipated timeframe of utility for each allocated block is 36 months, using the average assignment rate of the previous 12 months.
A proposed IANA allocation size of a /12 is reasoned using 3 forms of comparison with the current IPv4 allocation system. The first comparison considers the requirement for address space from ISPs and LIRs (namely the "demand side"), while the second considers the allowable allocations which may be made by IANA from the total available space (namely the "supply side"). The third uses a simulation of an IPv6 registry using the data gathered from the operation of the IPv4 address registry.
The current IANA IPv6 allocation unit of /23 is the equivalent of 33,554,432 end customer /48 assignments, while the current IPv4 allocation unit of /8 corresponds to 16,777,216 end customer assignments (assuming an end customer assignment unit of a /32).
The consumption rates of these address blocks differ greatly between IPv4 and IPv6. IPv4 address management policies assume a constant address utilization rate of 80% as a threshold for further allocations. An IPv4 deployment encompassing some 800,000 end-customer /32 assignments, for example, would therefore utilize a /12 allocation, or 1/16 of the IANA IPV4 allocation unit. The same ISP could request an allocation of IPv6 address space based on a deployment of IPv4 that entails some 800,000 customer assignments. The HD-Ratio applied to this scenario produces the outcome that the allocation size to the ISP is a /23, which is equal the entire IANA allocation to the RIR. In order to allow aggregation of a subsequent allocation, the allocating RIR, according to this policy, would allow for the possibility of a doubling of this assignment, so that the RIR would normally reserve the adjacent /23 address block in addition to the initial /23, requiring a /22 block to service the allocation request.
In order for the RIR to be able to service the same profile of requests that it services from the /8 IPv4 IANA allocation, the equivalent IPv6 allocation needs to be significantly larger than a /23. The equivalent of a /8 allocation in IPv4 using a 80% address utilization efficiency is a /18 allocation in IPv6, again using an HD-Ratio value of 0.8.
The current IANA IPv4 allocation to the RIRs is 1/256 of the entire IPv4 address space, or 1/220 of the IPv4 Global Unicast space. An equivalent IPv6 allocation from the currently assigned Global Unicast space of 2000::/3 is a /11 address block.
The objectives here are to set an allocation size that allows the RIR to service allocation requests from the IANA-allocated address blocks within the allocation policy framework, allowing each LIR and ISP the potential for further allocations within an encompassing aggregate address block; and to be able to service such requests without constant referral to IANA for further allocations.
The IPv6 framework is proposed to set an allocation size equivalent to at least 36 months expected utilisation, based upon the previous 12 months RIR allocation activity. The basis for this proposal is to allow ISPs and LIRs to achieve very high levels of aggregation within the address space, effectively limiting the long term fragmentation-induced overheads that would otherwise be placed on the IPv6 inter-domain routing system.
It is notable that the current IPv4 allocation size of /8 corresponds to an administrative boundary for delegation of "reverse" DNS zones under the in-addr.arpa tree. This allows entire zones to be delegated by the IANA to each RIR, without the need for sharing of zones between RIRs. This administrative factor should also be considered in determining the IPv6 allocation size.
This implication here is that the allocation sizes that allow for efficient management of the reverse DNS space are prefixes sizes that correspond to bit nibble boundaries: i.e. /4, /8, /12, /16 and so on.
Simulation of the operation of an RIR IPv6 registry has been undertaken using historical IPv4 allocation data as the seed data. The simulation has assumed that the underlying network metrics for IPv4 allocations have been based on an 80% host density metric. This metric is applied irrespective of the size of the address block under study. This has been translated to a derived customer count, that, in turn, has been used to seed an HD-ratio-based allocation with each IPv6 customer receiving a /48 and the minimum IPv6 allocation size from the RIRs being a /32. The corresponding table of equivalent IPv4 and IPv6 allocations is shown in Figure 4 ().
IPv4 / IPv4 Allocation Equivalence Table
(IPv4 Density of 80%, IPv6 HD-Ratio of 0.8)
IPv4 Prefix Number of End Customers IPv6 Prefix
/24 204 /32
/23 409 /32
/22 819 /32
/21 1638 /32
/20 3276 /32
/19 6553 /32
/18 13107 /30
/17 26214 /29
/16 52428 /28
/15 104857 /27
/14 209715 /25
/13 419430 /24
/12 838860 /23
/11 1677721 /22
/10 3355443 /20
/9 6710886 /19
/8 13421773 /18
/7 26843546 /17
Allocations Sizes in IPv4 and IPv6 under current allocation policies
| Figure 6 |
The simulation uses publicly available IPv4 allocation data [7]APNIC, APNIC Assignment Report", December 2004.[8]ARIN, ARIN Assignment Report", December 2004.[9]RIPENCC, RIPE NCC Assignment Report", December 2004.[10]LACNIC, LACNIC Assignment Report", December 2004.. This data provides the date and size of each assignment performed by the RIR. Missing from the data is an indication of whether the allocation is a further allocation to an existing recipient (LIR or ISP) expanding their address holdings, or an assignment to a new recipient. In comparing this data to the associated assignment databases that provide more detailed contact information, it appears to be a reasonable model of the IPv4 allocation system to have a steady state metric that 75% of allocations are additional address allocations to existing ISPs and LIRs. The the average life span until complete utilization for each allocation is 1 year, with a randomized variation from 1/2 a year to 2 1/2 years.
The simulated IPv6 registry uses a rate-modified sparse allocation registry management algorithm. New IPv6 allocations are made from bisecting an existing allocation window such that the total lifetime (time before the first collision of adjacent allocation windows) is maximized.
The simulation uses IPv4 allocation data for the period November 2001 until November 2004. The results are indicated in Figure 7. This simulation indicates that each RIR would assign to LIRs and ISPs the equivalent of a /16.5 or smaller from each RIR over a 36 month period.
Month APNIC ARIN RIPE LACNIC All
0 /29.0 /25.0 /32.0 /30.0 /29.0
1 /26.7 /24.5 /29.2 /28.8 /24.6
2 /21.9 /20.7 /22.5 /27.3 /19.9
3 /21.8 /20.4 /21.3 /26.8 /19.5
4 /21.5 /20.0 /21.0 /26.8 /19.2
5 /20.7 /19.5 /20.5 /26.5 /18.5
6 /20.1 /19.3 /20.2 /26.4 /18.2
7 /18.7 /19.3 /20.2 /26.3 /17.7
8 /18.7 /19.1 /20.0 /25.9 /17.6
9 /18.7 /18.9 /19.6 /25.8 /17.5
10 /18.6 /18.9 /19.3 /25.7 /17.3
11 /18.5 /18.8 /19.3 /25.5 /17.2
12 /18.5 /18.8 /19.0 /24.9 /17.1
13 /18.3 /18.8 /19.0 /24.7 /17.1
14 /18.3 /18.6 /18.9 /24.6 /17.0
15 /18.1 /18.5 /18.8 /24.6 /16.9
16 /17.9 /18.4 /18.7 /24.1 /16.7
17 /17.8 /18.2 /18.5 /24.1 /16.5
18 /17.8 /18.2 /18.4 /24.1 /16.5
19 /17.7 /18.1 /18.4 /23.9 /16.4
20 /17.6 /18.1 /18.3 /22.1 /16.4
21 /17.6 /18.1 /18.3 /22.1 /16.3
22 /17.5 /18.0 /18.3 /22.1 /16.3
23 /17.4 /17.9 /18.2 /22.1 /16.2
24 /17.4 /17.9 /18.1 /22.0 /16.1
25 /17.3 /17.8 /18.0 /21.8 /16.1
26 /17.2 /17.7 /17.9 /21.8 /16.0
27 /17.2 /17.6 /17.6 /21.8 /15.9
28 /17.2 /17.5 /17.5 /21.7 /15.8
29 /17.1 /17.5 /17.2 /21.7 /15.7
30 /17.0 /17.3 /17.0 /21.7 /15.5
31 /17.0 /17.2 /16.9 /21.2 /15.5
32 /16.8 /17.2 /16.9 /21.0 /15.4
33 /16.7 /17.2 /16.9 /21.0 /15.3
34 /16.7 /17.2 /16.9 /20.9 /15.3
35 /16.6 /17.1 /16.8 /20.9 /15.2
36 /16.6 /17.1 /16.7 /20.9 /15.2
Simulation 1 - RIR IPv6 Allocation Size (Monthly Totals)
| Figure 7 |
| Figure 8 |
There are a number of assumptions made in any modelling exercise. In this case the major difference between IPv4 address allocations and IPv6 allocations is that we are aware that for IPv4 there is an increasing reliance on Network Address Translators and DHCP in order to undertake address compression by the service provider. This is not a deliberate feature of the IPv6 architecture, and some allowance must be made for the absence of NATs in the IPv6 environment. The next simulation assumes that the customer numbers implied by IPv4 assignments are on average only 1/3 of the true customer count, and that the remainder of the customers are hidden by deployed NATS. Factoring in NATs at this level produces a result as indicated in Figure 9.
Month APNIC ARIN RIPE LACNIC All
0 /27.0 /23.0 /30.0 /28.0 /22.6
1 /24.7 /22.5 /27.8 /27.2 /18.0
2 /19.9 /18.8 /20.6 /25.4 /17.5
3 /19.8 /18.4 /19.4 /24.9 /17.3
4 /19.5 /18.0 /19.1 /24.9 /16.6
5 /18.7 /17.6 /18.6 /24.7 /16.3
6 /18.2 /17.4 /18.3 /24.7 /15.8
7 /16.7 /17.2 /18.3 /24.5 /15.7
8 /16.7 /17.2 /18.1 /24.2 /15.6
9 /16.7 /17.1 /17.8 /24.1 /15.4
10 /16.6 /17.0 /17.4 /24.1 /15.3
11 /16.5 /16.9 /17.4 /23.8 /15.2
12 /16.5 /16.9 /17.2 /23.2 /15.1
13 /16.0 /16.9 /17.1 /22.9 /15.1
14 /16.0 /16.7 /17.0 /22.8 /14.8
15 /15.9 /16.5 /17.0 /22.8 /14.7
16 /15.8 /16.4 /16.8 /22.4 /14.6
17 /15.8 /16.3 /16.6 /22.4 /14.6
18 /15.8 /16.3 /16.6 /22.4 /14.5
19 /15.7 /16.1 /16.5 /22.1 /14.5
20 /15.6 /16.1 /16.5 /20.2 /14.4
21 /15.6 /16.1 /16.4 /20.2 /14.4
22 /15.1 /16.1 /16.4 /20.2 /14.2
23 /15.1 /16.0 /16.3 /20.1 /14.2
24 /15.1 /15.9 /16.2 /20.1 /14.1
25 /15.1 /15.8 /16.2 /19.9 /14.0
26 /15.0 /15.8 /15.9 /19.9 /13.9
27 /15.0 /15.7 /15.7 /19.9 /13.9
28 /15.0 /15.6 /15.7 /19.8 /13.7
29 /15.0 /15.5 /15.3 /19.8 /13.6
30 /15.0 /15.4 /15.2 /19.8 /13.5
31 /15.0 /15.3 /15.1 /19.2 /13.4
32 /14.8 /15.3 /15.0 /19.1 /13.4
33 /14.8 /15.3 /15.0 /19.1 /13.3
34 /14.7 /15.2 /15.0 /18.9 /13.3
35 /14.6 /15.2 /14.9 /18.9 /13.2
36 /14.6 /15.2 /14.8 /18.9 /13.2
Simulation 2 - RIR IPv6 Allocation Size with NAT Factor 2:1 (Monthly Totals)
| Figure 9 |
| Figure 10 |
The results of this simulation indicate that each RIR will allocate a total of an IPv6 address block equal to a /14.6 over a 36 month period
As well as looking at the total amount of allocated space, there is also the consideration of the amount of address block fragmentation. The results of the simulation with regard to address block fragmentation are summarized in Figure 11.
Using data published by ARIN, and the above simulation setup with a /12 IP address pool managed using rate managed sparse allocation over a 36 month period, there will be 2,262 transactions with 800 ISPs and LIRS. A /12 IPv6 address block will be 11% allocated, with no allocations failing to be allocated from ISP's primary window. The average assignment is a /24.8 address block and the largest single allocation space available at the end of the simulation is a /18. All allocations were serviced from the block, and there were no failures to find space.
A comparable simulation using the RIPE NCC data indicates a similar picture, with 5,570 transactions to 1,924 ISPs and LIRS. The block was filled to 15% and 28 allocations failed to be allocated from the ISP's primary window. The average assignment is a /25.8 and the largest remaining open window is a /22.
A comparable simulation using the APNIC data results in 1,644 transactions to 800 ISPs and LIRS. The block was filled to 17% and 1 allocation failed to be allocated from the ISP's primary window. The average assignment is a /23.7 and the largest remaining open window is a /19.
Pool Allocated Avg Alloc LIRS Allocs Frags Avg Free Block
ARIN /12 /15.1 /24.8 800 2262 0 /21.8
RIPE /12 /14.8 /25.8 1924 5570 28 /23.2
APNIC /12 /14.6 /23.7 537 1644 1 /21.4
LACNIC /12 /18.9 /25.9 128 340 0 /19.0
ALL /12 /13.2 /25.0 3389 9816 60 /24.6
Simulation 2 - RIR IPv6 Fragmentation Summary
| Figure 11 |
The simulations indicate that the rate-managed sparse allocation mechanism can provide effective aggregation of address blocks over extended periods. Under the current framework of HD-ratio-based address allocations, a /12 is the minimum address block size that can provide an RIR with effectively aggregated allocation outcomes over a period of a 36 month operational window.
In considering the spectrum of size of current IPv4 network deployments, and the requirement to allow reallocations within the same aggregate window, the minimum IANA IPv6 allocation size should be in a range of between a /10 and a /18. A /10 divides the current IPv6 Global Unicast space into 128 allocation units (or the entire IPv6 space into 1024 allocation units), while a /18 creates 32,768 such allocation units. The midpoint is a /13 or /14, dividing the current IPv6 Global Unicast address space into 1024 or 2048 allocation units.
An IANA allocation unit of a /13 allows an RIR to service requests that include a small number of allocations for large ISPs, as large ISP would encompass some 10**7 customers, equating to an initial allocation of a /18 with an associated initial expansion window of a further 2 bit positions, or a /16. A /13 allocation would allow each RIR, if it chooses, to operate a sparse allocation address management system that would allow significant capability to ensure aggregateability of allocated address blocks. However, using IPv4 allocation data and an allocation simulation, it is evident that a /13 would not be adequate for 36 months of RIR operation. If effective aggregation is required over a 36 month window it is appropriate to propose use of a /12 as the IANA allocation unit.
The issue of administrative management of reverse DNS zones should also be considered, particularly considering the importance of stability of these zones at points close to the root.
It is proposed that the IANA allocation unit to RIRs should be equal to a /12, which represents the operational of a sparse allocation registry with aggregated outcomes over a 36 month window, as well as representing the closest administrative boundary for reverse DNS delegation.
It is proposed that
| [1] | Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. |
| [2] | Durand, A. and C. Huitema, "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", RFC 3194, November 2001. |
| [3] | Hinden, R., "Proposed TLA and NLA Assignment Rules", RFC 2450, December 1998 (TXT, HTML, XML). |
| [4] | Hinden, R., Deering, S., Fink, R. and T. Hain, "Initial IPv6 Sub-TLA ID Assignments", RFC 2928, September 2000. |
| [5] | IANA, "IPv6 Top Level Aggregation Identifier Assignments", August 2004. |
| [6] | IANA, "IPv6 Address Allocation and Assignment Policy", June 2002. |
| [7] | APNIC, "APNIC Assignment Report"", December 2004. |
| [8] | ARIN, "ARIN Assignment Report"", December 2004. |
| [9] | RIPENCC, "RIPE NCC Assignment Report"", December 2004. |
| [10] | LACNIC, "LACNIC Assignment Report"", December 2004. |
| Geoff Huston | |
| Asia Pacific Network Information Centre | |
| EMail: | gih@apnic.net |
| URI: | http://www.apnic.net |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.