Consideration of the IPv6 Allocation Unit Size

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 RFC3914). 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 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 3513)

Allocations of Global Unicast address space to RIRs are described by RFC2450. 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 RFC2450, is shown in Figure 1.

| 3 | 13 | 13 | 19 | +----+----------+---------+---------------+ | FP | TLA | Sub-TLA | NLA | | | ID | | ID | +----+----------+---------+---------------+ IPv6 Address Structure (after RFC2450 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 2450, 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 RFC2928. 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." (RFC2928) These initial allocations were in units of /23 address blocks. The IANA IPv6 Sub-TLA Assignment registry 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 (RFC3513), 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 . 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 Policy, 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 Policy, 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. "Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure." (IPv6 Address Allocation and Assignment Policy, Section 4.4) 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 Policy, 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 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 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: For each allocation A[i] the corresponding expansion slot, X[i], is subdivided according the to the binary chop, resulting in a new expansion slot X'[i] and an initial allocation window W[i]. If W[i] is less than the required initial allocation size, Ax, then the associated slot lifetime, P[i], is assigned a value of 0. Otherwise the growth rate of A[i], R[i], is used. The lifetime for A[i] is calculated as X'[i] / R[i]. The rate of the new allocation, Rx, is calculated as Ax/(inital_period). The lifetime of using W[i] for this new allocation, Tx, is calculated as (W[i] - Ax) / Rx. The lifetime associated with selection of slot i for this new allocation, P[i], is the minimum of T[i] and Tx. The selected slot is the value of i that maximizes the value of P[i] over all i. 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 , 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

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 The simulation uses publicly available IPv4 allocation data . 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 . 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)

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 .

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)

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 . 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 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 IANA shall allocate address blocks to the RIRs using an allocation unit of a /12 address block. Further allocations will be made from IANA to the RIRs such that the RIR will have a minimum pool of allocateable addresses that encompass at least a further 36 months of allocations at the average allocation rate of the previous 12 months without compromising the ability to service allocation extension requests within aggregateable blocks according to the sparse allocation procedure. The RIR may choose to manage each allocated address block using sparse allocation mechanisms described in this document. If so, each allocation would be performed in a manner such that allocation selection preserves the longevity of the usefulness of the address block with respect to both servicing initial allocations and servicing allocation extensions within aggregation block boundaries by using a rate-governed window selection algorithm.