[arin-ppml] Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update

[Andrew Dul]

As the primary author of this draft policy, I support the policy. 

This draft policy replaces the current section 4.10 "transition
technology" allocations with a more generic "austerity policy" which
more closely aligns with other RIR's austerity policies. 

This policy does the following:

1. Changes the requirements to be non-technology IPv6 specific, which
allows for a broader group of organizations to qualify for IPv4 address
space under this section.
2. Increases the block size to a maximum /22
3. Uses sparse allocation and permits an organization to possibly grow
their allocation up to a /22, if they don't qualify for the full block
on their initial allocation.
4. Places additional IANA reclaimed blocks into this pool for allocation.
5. Limits the number of blocks per organization to one; this directly
mirrors other successful RIR austerity policies.

I believe this policy along with recommended draft policy "ARIN-2014-13:
Reduce All Minimum Allocation/Assignment Units to /24" solve many of the
immediate IPv4 policy issues that ARIN will face after the free pool is
depleted.  Therefore, I recommend this policy be moved forward as
quickly as possible.

I and the AC welcome your comments on this draft.

Andrew




On 5/16/2014 1:20 PM, ARIN wrote:
>
> ## * ##
>
>
> Draft Policy ARIN-2014-16
> Section 4.10 Austerity Policy Update
>
> Date: 16 May 2014
>
> Problem Statement:
>
> NRPM section 4.10 defines an IPv4 to IPv6 transition pool which was
> intended to be used by new entrants after the IPv4 free pool has been
> exhausted. This policy was written prior to exhaustion in the APNIC
> and RIPE region and has largely not been used to date. It is believed
> that the current policy may be too restrictive to be useful to many
> organizations within the ARIN region. Furthermore the during the ARIN
> 33 public policy meeting experience report (1), ARIN staff noted
> issues with the current IPv4 policy after the IPv4 free pool is
> exhausted.
>
> RIPE & APNIC adopted an “austerity” policy which allows organizations
> to obtain a small single block directly from the registry. These
> policies appear to have been quite effective at getting IPv4 resources
> to organizations without address space after IPv4 exhaustion. Learning
> from other regions, we have crafted a policy to update section 4.10 to
> adopt some of the policy text from the RIPE & APNIC region while
> looking at the unique aspects of the ARIN region’s number resource needs.
>
> Policy statement:
>
> Replace Section 4.10 with the following policy.
>
> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
>
> 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 and continued transition from IPv4 to IPv6.
>
> Address space received from IANA under the “Global Policy for Post
> Exhaustion IPv4 Allocation Mechanisms by the IANA (NRPM 10.5)” by ARIN
> shall be allocated or assigned under this section.
>
> Allocations and assignments from this block must be justified by
> immediate IPv6 deployment requirements. Organizations must obtain an
> IPv6 block to receive a block under section 4.10 and show
> documentation on how the IPv6 and IPv4 block will be used to
> facilitate an organization’s operational needs.
>
> This block will be subject to a minimum size allocation of /28 and a
> maximum size allocation of /22. ARIN shall use sparse allocation
> within these blocks.
>
> In order to receive an allocation or assignment under this policy:
>
> 1. the organization, nor it parent(s) or subsidiary organizations, may
> not have received IPv4 resources greater than or equal to a /22 from
> ARIN or any other RIR;
>
> 2. the organization must show immediate use (within 30 days) of 25% of
> the allocation;
>
> 3. the organization is eligible to receive only one contiguous IPv4
> block under this section;
>
> 4. the organization may apply to ARIN for an increase in their
> allocation up to a /22, if the previous allocation under this section
> shows a utilization of at least 80%, increases will only be granted if
> adjacent bit-boundary aligned space is available at the time of request.
>
> Comments:
>
> a. Timetable for implementation: immediately
>
> b. Anything else: (1)
> https://www.arin.net/participate/meetings/reports/ARIN_33/PDF/monday/nobile_policy.pdf
>
>