[address-policy-wg] IANA implementation analysis of proposal 2011-01, "Global Policy Proposal for Post Exhaustion IPv4 Allocation Mechanisms by IANA"

Dear Colleagues,

In order to provide a more comprehensive overview of the expected
implementation aspects of proposal 2011-01, the RIPE NCC sought input
from IANA staff.

Below is the analysis produced by Leo Vegoda. We hope that this input
will be useful to RIPE community discussion of this proposal.

We also note that the current Review Phase for the proposal will end on
25 August 2011.


Best Regards
Emilio Madaio
Policy Development Officer
RIPE NCC



--------oooooooooo--------------

IANA staff impact analysis of RIPE policy proposal 2011-01

This analysis considers the impact of ratification of RIPE policy 
proposal 2011-01 (as a part of GPP-IPv4-2011) by the ICANN Board of 
Directors.

1. The policy would require ICANN, as the IANA function operator, to 
establish a Recovered IPv4 Pool. The pool would have to include “any 
fragments that may be left over in the IANA”.  In order to do this, 
ICANN staff would have to work closely with the five RIRs’ staffs to 
make sure the initial pool included all fragments assigned to IANA. It 
is not clear whether this policy proposal is intended to supersede the 
IETF’s right to make IPv4 assignments for “specialised address blocks 
(such as multicast or anycast blocks)” as documented in section 4.3 of 
RFC 2860. This should be clarified but that can probably be done by way 
of assertions from the NRO rather than a revision to the policy text. In 
the event that the policy is intended to supersede RFC 2860 there is a 
potential issue with the internal reservation of small blocks address 
blocks that have been informally reserved for IETF standards track work 
currently in progress.

2. It would replace the current procedure for Updating legacy Class A 
IPv4 allocations, which was agreed with the NRO in February 2007. This 
is because the text includes a statement that “The Recovered IPv4 Pool 
will initially contain any fragments that may be left over in the IANA. 
It will also hold any space returned to the IANA by any other means” and 
this presumably include address space returned directly by registrants.

3. Once it was activated by an RIR declaring that it has less than a /9 
in its inventory, IANA would have to make the first allocation. IANA 
would then have to make additional allocations on 1 March and 1 
September each year, if there is enough address space left in the pool. 
The minimum allocation size would be a /24 and the “allocation unit” 
used in each allocation would be determined by dividing the total pool 
by five and rounding down to the nearest CIDR boundary. As an example, 
if the pool contained 27 /24s, each RIR would be allocated a /22 (or the 
equivalent made from multiple /24 prefixes) because 5.4 /24s is not on a 
CIDR boundary. There is no text stating that the “allocation units” must 
be a single prefix and so it seems reasonable to make them up from a 
bundle of prefixes when necessary.

4. All address space added to the Recovered IPv4 Pool would be 
registered as such in the IANA IPv4 Address Space Registry. Similarly, 
allocations from the pool would also be registered. This would require 
the granularity of registration to move from /8 boundaries as is 
currently the case and as such could inflate the size of the registry 
from 256 lines to several thousand.


--------oooooooooo--------------