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

Wed Sep 25 21:24:24 EDT 2013

On Sep 25, 2013, at 5:33 PM, Jason Schiller <jschiller at google.com> wrote:

> 
> The policy is a little hard to parse...
> 
> On Wed, Sep 25, 2013 at 6:55 PM, Owen DeLong <owen at delong.com> wrote:
> | As to moving, yes, corporations often use DNS changes to move the
> | service for "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 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.

> 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.

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.

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

Correct.

> 
> ---
> 
> 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.

> ---
> 
> 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.

> 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'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.

Owen

> 
> 
> ___Jason
> 
> On Wed, Sep 25, 2013 at 6:55 PM, Owen DeLong <owen at delong.com> wrote:
> 
> On Sep 25, 2013, at 3:27 PM, John Santos <JOHN at egh.com> wrote:
> 
> > On Wed, 25 Sep 2013, William Herrin wrote:
> >
> >> On Wed, Sep 25, 2013 at 10:59 AM, ARIN <info at arin.net> wrote:
> > [...]
> >
> >>
> >>> , and (2) are operating a
> >>> network located within the ARIN service region. In addition to meeting
> >>> all other applicable policy requirements, a plurality of new resources
> >>
> >> "Plurality" is a non-starter for me. You really want to do this, pick a
> >> percent.
> >>
> >> The reasons have all been stated before, both in the previous
> >> discussion, the staff comments and the legal assessment. In context,
> >> plurality is a sloppy, hard to pin down concept that makes management
> >> and analysis needlessly hard.
> >
> > Huh?  "Plurality" is a precisely defined mathematical concept.
> >
> > The part I have a problem with is "a network located within the ARIN
> > service region."
> 
> I don't think this is as problematic as you are perceiving.
> 
> > Networks intrinsically span service regions.  Nodes can be scattered
> > across RIR regions, links between nodes can (and often do) cross regional
> > boundaries, and what's worse, nodes can move, both day-to-day (for
> > example, an international corporation moves its "www.support.foocorp.com"
> > web servers from a data center in Michigan to one in Luxembourg), and
> > totally dynamically, as in load-balancing and site failover, as well as
> > mobile nodes that can cross RIR boundaries at will.  In which region is a
> > Liberian-registered cruise ship sailing out of San Diego currently exploring
> > the coast of Patagonia?  Or an airplane or the ISS?
> 
> In the case of spanning regions and scattered across regions, that is the
> reason for the "plurality" provision. It allows a company to keep some
> portion of its assets in region and still address its out-of-region assets so
> long as none of the other regions contain more of the network using ARIN
> region numbers than what is in the ARIN region.
> 
> As to moving, yes, corporations often use DNS changes to move the
> service for "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).
> 
> Mobile nodes that cross RIR boundaries actually tend to get new numbers
> when they do so. (At least I haven't roamed across an RIR boundary without
> being assigned a new IP address when I did so, and I've been across a lot
> of RIR boundaries.
> 
> > There needs to be a degree of fuzziness.  If we are going to force a
> > regional preponderance of the network (a much vaguer term than
> > "plurality"), to be in ARIN's geographical region, then (1) clearly a
> 
> Yes.
> 
> > network with 30% ARIN, 70% RIPE should be getting its resources from RIPE,
> 
> Which would fail the plurality test.
> 
> > but (2) one with 29% ARIN, 28% RIPE, 25% APNIC, and the other 17% spread
> > across Africa and Latin America should get their resources from ARIN,
> 
> Which would pass the plurality test.
> 
> > despite having a smaller footprint than the 1st organization.  And what of
> > (3), which has 28.99% ARIN, 29.01% RIPE right now, but it could change in
> > the next 15 minutes?  Maybe "within 5% of a plurality in the ARIN region"
> > would be a better metric.
> 
> In reality, I think that particular boundary condition is an unlikely corner case.
> Where is the other 42% of that network, by the way?
> 
> As I said above, the numbers do not tend to move as quickly as you claim.
> Names tend to be quite dynamic. Numbers tend to be fairly stable. If they
> were not, BGP would have a much higher (and unsustainable) level of churn.
> 
> > I think right now, an organization can basically deal with the registry it
> > finds most convenient, whether for geography, language, culture or
> > whatever. The proposal doesn't seem to be about registry shopping (my
> 
> No, actually, most of the other RIRs are much stricter about out-of-region
> use of address space than ARIN.
> 
> > local RIR rejected my request or has too many restrictions on my trying to
> > commoditize or speculateon the resources, so I'm going take a dip from
> > another well), or double-dipping or playing registries off against each
> > other.  Its goal seems to be accountability of the registrants, so I think
> 
> These are definitely one aspect of the intended policy, but not exclusively,
> no.
> 
> > thats what it should try to do directly.  It shouldn't matter *where* an
> 
> That is a second aspect of the proposal.
> 
> > organization is based, it should matter whether it is contactable,
> > receives and pays its bills, handles abuse complaints and technical
> > issues, etc.  If these are true, local law enforcement should have no
> > problem tracking them down if needed.
> 
> I don't think this is just about law enforcement, though the proposal authors
> are primarily representatives of US and Canadian LE organizations. I do
> think that the primary intent of the proposal is to address a growing perceived
> issue with registry shopping.
> 
> Personally, I'm all for making the process more open to out-of-region usage
> as you described, but if you look closely at current ARIN operating practice
> and this policy proposal, you will see that the proposal is actually more
> liberal about this than current (though not some prior) operating practice.
> 
> Owen
> 
> _______________________________________________
> 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.
> 
> 
> 
> -- 
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130925/5ad761ba/attachment.htm>