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

[David Farmer]

On 9/25/13 20:24 , Owen DeLong wrote:
>
> On Sep 25, 2013, at 5:33 PM, Jason Schiller <jschiller at google.com
> <mailto:jschiller at google.com>> wrote:
>
>>
>> The policy is a little hard to parse...

If you have suggestions to improve the readability of the text I'd be 
happy to hear them.

>> On Wed, Sep 25, 2013 at 6:55 PM, Owen DeLong <owen at delong.com
>> <mailto:owen at delong.com>> wrote:
>>
>> | As to moving, yes, corporations often use DNS changes to move the
>> | service for "www.support.foocorp.com
>> <http://www.support.foocorp.com/>" from one place to another (or
>> | to balance it across many locations), but that's DNS. Policy here is
>> | about the numbers and corporations rarely move the numbers around
>> | in such a scheme. (Anycast notwithstanding, but I would treat any cast
>> | as used in region so long as at least one site advertising the any cast
>> | prefix was in region).
>>
>>
>> What I can't tell is if this is changing current ARIN practice, and if
>> so, making it more restrictive or less restrictive.
>
> My understanding is that it would make a slight change to current ARIN
> practice making it slightly less restrictive.
>
>> With respect to a global contiguous network that operates, in part, in
>> the ARIN service region,  and advertises reachability for all of the
>> aggregates both in the ARIN service region, and outside the ARIN service
>> region, count their utilization of equipment and customers of this global
>> network regardless of where they are.
>
> Unfortunately, no, this is not entirely current practice. If you can
> justify everything you need based on in-region devices, then ARIN won't
> complain about your out-of-region usage, but if you come back for more,
> you need to be able to justify your additional need strictly using
> in-region devices. If you tell ARIN that you want numbers for your local
> office and your POP in London, they will approve you only for the local
> office. (It used to be that the POP in London was no problem, but not any
> more).
>
>> This seems to be current practice, and suggested by Owen that he still
>> considers it true wrt his anycast statement.
>
> I believe this policy would return us to a better place as described
> above.

In another aspect this is a little less restrictive than current 
operational practice as well, this is discussed in the following from 
the Advisory Council Comment Section;

"Current operational practice is to require an organization be formed
within the ARIN service region. However, if this were applied by all the
RIRs, a global network would be required to have a minimum of five
subsidiaries, one formed in each of the five RIR regions, this seems
overly burdensome. Good resource policy should consider the consequences
of all RIRs adopting the same policy."

>> "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 same technical
>> infrastructure or customers cannot be used to justify resources in
>>  more than one RIR."
>>
>> This could be read as:
>> new resources requested from ARIN must be justified by:
>> 1.  technical infrastructure or customers located within the ARIN
>> service region
>>
>> AND
>>
>> 2. any [technical infrastructure or customers] located outside the
>> region [which are] interconnected to the [infrastructure in point 1]
>> in the ARIN service region.
>
> Yes, but with the additional caveat that the quantity of resources justified
> by [1] must exceed the amount of resources in any other single RIR region
> justified by [2], and, though the resources in [2] have to be interconnected
> to the ARIN region, they don't necessarily connect to new devices from
> [1] rather than old devices that are already deployed.
>
>> This would suggest that you get to count the non-ARIN customers that
>> are attached to the global network, such as the case now, including the
>> case where an Asian company is providing tunnel services to an LA
>> gateway that is terminating Asian customers.
>
> This is only partially the case now sort of under some circumstances.
> The proposal would make it universally the case.

I'm with you so far.

>> This also suggests that you can count utilization of ARIN resources
>> outside of the ARIN region in a disconnected network that is wholly
>> outside the ARIN region so long as this utilization doesn't cross the
>> plurality or 20% or 50% threshold.

Why doesn't this fail your #2 above? Even if it doesn't, the policy text 
says "...and any located outside the region *must be* interconnected to 
the ARIN service region."  The "must be" is intended to disallow out of 
region disconnected or discrete networks, justifying ARIN resources. 
This is clarified by the following from the Advisory Council Comment 
Section;

"While resources received from ARIN may be used outside the ARIN region,
a common technical infrastructure must interconnect the use of these
resources to the ARIN region. This provides a necessary nexus with the
ARIN service region for such out of region use. Therefore, if a discrete
network is operating within another region, not interconnected to the
ARIN region, then resources for that discrete network should be
requested from that region's RIR."

> I don't believe that is true. I believe that the requirement is for the
> utilization out of region to be entirely on infrastructure that is part
> of the contiguous interconnection (intra-ORG) with the ARIN region.

That would be the intent.

>> My understand is today ARIN does not recognize this utilization at all
>> suggesting this would loosen current practice.
>
> Correct.

Neither is this intended to.  Any text you have that clarifies this 
intent is welcome.

>> ---
>>
>> Based on the tone of the conversation, I suspect the community believes
>> the reading of the policy is parsed differently:
>>
>> new resources requested from ARIN must be justified only  by technical
>> infrastructure or customers located within the ARIN service region.
>>
>> [In addition,] any [use] located outside the [ARIN] service region
>> must be
>> interconnected to [a network in] the ARIN service region.
>>
>> This seems to suggest usage outside the region even in a globally
>> connected network that is, in part, within the ARIN service region
>> does not count towards plurality (or whatever minimum percentage)
>> suggesting this policy is more restrictive than current policy.
>>
>> Additionally, I have not seen any object to the next clause:
>>
>> "The same technical infrastructure or customers cannot be used to justify
>> resources in more than one RIR."
>
> The intent of this statement is to prevent "double dipping". You can't ask
> ARIN for resources for the same pieces of your network in Asia that you
> already received resources from APNIC to number.

Correct, as discussed in the following from Advisory Council Comments 
Section;

"From previous discussions of the topic, "double dipping" should not be
allowed, that is using the same technical infrastructure or customers to
justify resources from ARIN and another RIR at the same time."

>> ---
>>
>> I agree that double counting should not occur, but there are cases when it
>> is justified to have multiple addresses on a single piece of equipment or
>> to a single customer.  Why can't a mix and match approach work.
>>
>> For example imagine a server serving https for two domains.  It needs two
>> IP addresses, one for each domain's cert with IP based vhosting.  Should
>> this operator be precluded from having their previous turned up customers
>> continue to have RIPE space, but newly turned up customers on the same
>> server use ARIN space?  What if each service is anycasted on machines in
>> the UE and Europe for diversity, and performance? Can the first customer
>> on the same hardware use a single IP from RIPE in both locations, and the
>> second a single IP from ARIN?
>
> I think from an RIR perspective, these would not be considered the same
> infrastructure for addressing purposes. Each of the two web servers is
> counted separately, even though they happen to be on the same physical
> piece of hardware.
>
> If you have better wording to clarify that intent, I'm sure it would be
> welcome.

Definitely.

>> How about a customer that has a RIPE /24 and has grown beyond their
>> current addresses, should they be precluded from getting an additional
>> ARIN /24 and keep their RIPE /24?  What if the customer has a single
>> network in both the US and Europe and is multi-homed to a single
>> provider in the US and Europe?
>
> If they have enough additional infrastructure to justify the additional
> /24, I believe this policy would allow that.

I believe so as well, sounds like they meet the other policy 
requirements, the intent would be to allow it.  The intent would be to 
prevent them from getting an additional /24 from both ARIN and RIPE, if 
they only really justify one additional /24 in totality.  However, if 
they can justify an additional /24 separately using the ARIN portion of 
the network for ARIN and the RIPE portion of the network for RIPE, they 
should be allowed one from each.

> I'm not sure I fully comprehend your meaning in the last sentence.
>
>> Or in both cases do they have to number out of RIPE space and into ARIN
>> space?
>
> I think this might make more sense if I understood the previous question.

I don't think renumbering should be necessary and it isn't intended in 
my opinion.

Thanks for exploring more of the policies intent, any suggestions for 
text would be appreciated.

-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================