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

[John Curran]

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