[arin-ppml] Policy Proposal 2008-5 Dedicated IPv4 block to facilitate IPv6 deployment

[Member Services]

On 19 June 2008, the ARIN Advisory Council (AC) concluded its review of 
"Dedicated IPv4 block to facilitate IPv6 deployment" and accepted it as 
a formal policy proposal for discussion by the community.

The proposal is designated Policy Proposal 2008-5: Dedicated IPv4 block 
to facilitate IPv6 deployment. The proposal text is below and can be 
found at:
http://www.arin.net/policy/proposals/2008_5.html

All persons in the community are encouraged to discuss Policy Proposal 
2008-5 prior to it being presented at the October ARIN XXII Public 
Policy Meeting. Both the discussion on the Public Policy Mailing List 
and at the Public Policy Meeting will be used to determine the community 
consensus regarding this policy proposal.

The ARIN Internet Resource Policy Evaluation Process can be found at: 
http://www.arin.net/policy/irpep.html

ARIN's Policy Proposal Archive can be found at: 
http://www.arin.net/policy/proposals/proposal_archive.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##

Policy Proposal 2008-5
Dedicated IPv4 block to facilitate IPv6 deployment

Author: Alain Durand
Proposal Version: 1.0
Submission Date: 6/6/2008

Proposal type: New

Policy term: Permanent

Policy statement:

When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous 
/10 IPv4 block will be set aside and dedicated to facilitate IPv6 
deployment. Allocations and assignments from this block must be 
justified by immediate IPv6 deployment requirements. Examples of such 
needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT 
or NAT464 translators. ARIN staff will use their discretion when 
evaluating justifications.

This block will be subject to a minimum size allocation of /28 and a 
maximum size allocation of /24. ARIN should use sparse allocation when 
possible within that /10 block.

In order to receive an allocation or assignment under this policy:
1) the applicant may not have received resources under this policy in 
the preceding six months;

2) previous allocations/assignments under this policy must continue to 
meet the justification requirements of this policy;

3) previous allocations/assignments under this policy must meet the 
utilization requirements of end user assignments;

4) the applicant must demonstrate that no other allocations or 
assignments will meet this need;

5) on subsequent allocation under this policy, ARIN staff may require 
applicants to renumber out of previously allocated / assigned space 
under this policy in order to minimize non-contiguous allocations;

6) recipient organizations must be members in good standing of ARIN.

Rationale:

Rationale for reserving IPv4 space:

This policy provides predictability on how the end game of IPv4 is going 
to be played after IANA completion. It will facilitate IPv6 deployment 
by ensuring that some small chunks of IPv4 space will remain available 
for a long time to ease the co-existence of IPv4 & IPv6.

Rationale for reserving a contiguous /10

This is a balance between setting aside too much space and not having 
enough to facilitate IPv6 deployment for many years. Out of the last /8, 
that would leave the equivalent of 3 /10 to ARIN either for business as 
usual or for other policies in the spirit of this one.

A /10 represents 4,194,304 IP addresses, If all of them were to be used 
in NAT-PT or NAT464 type devices with a consolidation factor of 100 
users behind each IP address, that would represent about 400 million users.

Most networks today filter IPv4 announcements more specific than /24.

This policy creates allocations & assignment prefixes as long as /28.

Allocating out of a contiguous block will mitigate the impact of this 
policy on filter lists.


Rationale for minimum size allocation of /28

This minimum size allocation will put a cap at 250k additional entries 
in the global IPv4 routing table.

Rationale for maximum size allocation of /24 and for the 6 month delay 
between allocations

This maximum allocation size coupled with the requirement of a 6 months 
delay between allocations will prevent hoarding and make sure this pool 
will last several years.

Rationale for forced renumbering for further allocation

The minimum allocation size of /28 may create a huge increase in the

IPv4 routing table size. Forcing renumbering for subsequent allocations 
under this policy will somehow limit the growth of the routing table 
size by enabling the announcement of aggregated space. It is expected 
that the savings in routing table entries will outweigh the pain of 
forced renumbering.

However, renumbering is never an easy task, so it should only be 
considered as last resort. it is expected that sparse allocation 
techniques will prevent the need of force renumbering for a fairly long 
time.

Note: This policy proposal hints that the /10 should come out of the 
last /8 received by ARIN from IANA. However, it does not say so 
explicitly, leaving the final decision up to the ARIN staff.

Timetable for implementation:

As soon as ARIN gets its last /8 allocation from IANA.