[arin-ppml] Updated text for ARIN 2014-16: Section 4.10 Austerity Policy Update

Owen DeLong owen at delong.com
Thu Sep 18 18:05:54 EDT 2014


> 
>>> 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. ARIN shall use sparse allocation within
>>> these blocks.
>>> 4.10.1 Austerity Policy
>>> Organizations must obtain an IPv6 block to receive a block under section
>>> 4.10.1 and show documentation on how the IPv6 and IPv4 block will be used
>>> to facilitate an organization¹s operational needs. These allocations or
>>> assignments will be subject to a minimum size of /28 and a maximum size of
>>> /22.
>>> In order to receive an allocation or assignment under this policy:
>>> 1. the organization, its parent(s), or subsidiary organizations, may not
>>> have received IPv4 address resources greater than or equal to a /22 from
>>> ARIN or any other RIR;
>>> 2. the organization must show immediate use (within 90 days) of 25% of the
>>> allocation;
>> It feels like the numbered sections should end here, because the next
>> two are not requirements for receiving a block under this policy,
>> rather statements of what will happen next. But that's minor.
>>> 3. the organization is eligible to receive only one contiguous IPv4 block
>>> under this section;
>> By extension, does that mean the organization, its parent(s) or subsidiaries?
> 
> Yes, the intention is that only one of these blocks is available to an organization, its parent(s) or subsidiaries.

Then the policy should clearly state that. A plain text reading of the current proposal would, IMHO, yield an interpretation
that it is governed by ORG-ID in the ARIN database, which is a very different result from the intent you claim.

> 
>>> 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.
>> Does 'utilization' in this sense mean 'active v4 addresses', or
>> 'active v4 addresses being used in accordance with the documentation
>> provided to justify the original allocation'? Bullet 2 in the existing
>> 4.10/new 4.10.2 seems to cover this but only for that section.
> 
> My intention is that if/when the organization comes back to ARIN to grow their prefix that they are actively using 80% of the block which was allocated under 4.10.1.  So if you have a /24 from 4.10.1 and you are using ~205 IP addresses you can expand to the next bit boundary.

I support doing this where possible, but if you happen to be unable to do so due to adjacent allocations, but a /24 is still available elsewhere, you should still be able to receive an additional /24 IMHO.

> 
>>> 4.10.2 Transition technologies
>>> 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.
>>> These allocations or assignments will be subject to a minimum size of /28
>>> and a maximum size of /24.  ARIN shall reserve a minimum of a /11 for
>>> allocations under this subsection.
>> Will this /11 come out of existing free space, or be half of the
>> existing /10, or wait for the next batch of IANA blocks?
> 
> My assumption/intention was that ARIN would take the /10 that has been reserved under the existing 4.10 policy and divide it into two /11s one for 4.10.1 and one /11 for 4.10.2.  Other IANA returned blocks would be placed into the 4.10.1 pool.

That is how I interpret the proposal. I don’t support this diversion of original 4.10 space into the new 4.10.1 purpose. I would support putting all IANA returned blocks into 4.10.1, preserving the original /10 from 4.10 for what would become 4.10.2.

Owen




More information about the ARIN-PPML mailing list