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

Wed Sep 25 21:33:58 EDT 2013

Seems my posts didn't show up... trying again...

(Owen, did you get it the first time around?
Can you repost it if it doesn't show up?)

---------- Forwarded message ----------
From: Jason Schiller <jschiller at google.com>
Date: Wed, Sep 25, 2013 at 8:33 PM
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and
IPv6 Address Space to Out-of-region Requestors - Revised
To: Owen DeLong <owen at delong.com>
Cc: John Santos <JOHN at egh.com>, "arin-ppml at arin.net" <arin-ppml at arin.net>

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.

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.

This seems to be current practice, and suggested by Owen that he still
considers it true wrt his anycast statement.

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

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

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

---

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

---

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?

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?

Or in both cases do they have to number out of RIPE space and into ARIN
space?

___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

-- 
_______________________________________________________
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/a2b309e7/attachment.htm>