[arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised

[Owen DeLong]

Perhaps replacing "technical infrastructure" with "addresses assigned
to equipment and/or interfaces physically present within the ARIN region".

Owen

On Oct 7, 2013, at 8:37 AM, John Curran <jcurran at arin.net> wrote:

> On Oct 6, 2013, at 3:22 PM, William Herrin <bill at herrin.us> wrote:
> 
>> There is a subtlety here that is escaping me. If the addresses are
>> assigned to hosted infrastructure within the region then how are they
>> not used within the region?
> 
> Bill - 
> 
> Apologies in advance for length - the community is entitled to a complete
> understanding of how we administer number resources, and that appears to 
> take more words than I expected at first..
> 
> Technical infrastructure can be used to justify addresses (for example,
> network routers, POP equipment, concentrators, management systems, IT 
> systems, data center servers, etc.)  We're very experienced with this, 
> and often ask for equipment lists, invoices, etc. to confirm existence 
> of the asserted equipment.
> 
> When technical infrastructure grows, more IP addresses are needed for 
> assignment to the technical infrastructure. Technical infrastructure 
> exists in a region based on the location of the physical devices.
> 
> Customers growth can also justify addresses (e.g. you assign addresses to 
> an single customer, or customer growth requires that a certain dynamic pool
> assigned to customers be expanded)  We are also quite experienced with the
> verification of customers, including obtaining customer lists, contact info, 
> etc.
> 
> When the number of customers served grows, more IP addresses are needed to 
> assign to the new customers, or to assign to the dynamic pools for those
> customers.  Customers exist in a region, based on their actual location of 
> each customer.
> 
> For example, if someone needs more addresses because they are adding
> new VPN concentrators (i.e. more actual equipment itself), then that is 
> indeed technical infrastructure need based on where the equipment will
> be installed.  i.e. if you buy stacks of new VPN concentrators and have 
> no addresses to connect them to your infrastructure, it's a simple matter 
> to request (per policy) additional addresses needed.  We do this all of 
> the time with the infrastructure side of DSLAMS, cable head-ends, wifi 
> nodes, etc.
> 
> If someone needs additional addresses for their _customers_ (including
> to expand a dynamically assigned pool), then we verify the customer
> growth as noted earlier, including the location of the customers.
> 
> Requesters have to show that they have additional equipment or additional
> customers to obtain addition addresses.  Both equipment and customers are 
> associated with real-world addresses, and hence are within some region of 
> the registry system.
> 
>> What aspect of the draft policy would change that evaluation? ...
> 
> The draft policy 2013-6 reads as follows:
> 
> "In addition to meeting all other applicable policy requirements, 
> a plurality of new resources requested from ARIN must be justified 
> by technical infrastructure or customers located within the ARIN 
> service region, and any located outside the region must be 
> interconnected to the ARIN service region."
> 
> The requesters who were previously discussed (i.e. "the 52" who have received 
> allocations since mid-year), often have some existing infrastructure, are not 
> adding anything more, and do not need more addresses due to their _technical 
> infrastructure_ growth. 
> 
> They do have remarkable customer growth, and hence need additional addresses.   
> Under the policy change proposed by 2013-6, we would only consider customers 
> within the ARIN service region for this purpose, and would provide an allocation
> which they could justify based on that in-region customer demand. The proposed 
> policy change makes clear that customers must be in-region to be considered. 
> (The present policy does not have such a constraint, hence the approval of 
> recent requests where the vast majority of customers are known to be outside 
> the ARIN region.)
> 
> We don't consider virtual "technical infrastructure" for assessing the need 
> for addresses, even though service providers may use such when adding customers.
> The additional customers driving such virtual growth are readily verifiable.  
> The alternative would be to consider virtual equipment (e.g. VM's) as actual 
> technical infrastructure and that would effectively open the justification of 
> unlimited resources by any party without any actual equipment or customer growth.
> 
> If the desire was to simply clarify existing policy (without actually changing 
> the current practice), it could be accomplished by dropping the "in region" 
> requirement for customers as follows: "must be justified by technical 
> infrastructure within the ARIN or by customers located anywhere as long as
> the addresses are managed and interconnected in the ARIN service region."  
> (Note that such a change would make rather clear that nearly any heavily-utilized 
> customer-driven IP address pool interconnected in the ARIN region can qualify 
> for additional resources, which may or may not be a desirable outcome depending 
> on one's individual perspective.)
> 
> I hope this helps in clarifying what ARIN-2013-6 would be change to the
> existing policy, as it would make clear that customer growth in-region
> would be necessary to justify requests, whereas presently we have some
> folks requesting resources using nominal equipment within the region and
> backed by extensive customer growth external to the region.
> 
> Please do not hesitate to ask if you have any further questions - it is
> indeed very important that folks understand how we implement the policy 
> in order to fully consider any proposed policy changes, so thank you for 
> your diligence on this topic.
> 
> /John
> 
> John Curran
> President and CEO
> ARIN
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.