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--------------