> >>> 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 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
