[arin-ppml] ARIN-prop-178 Regional Use of Resources

ARIN info at arin.net
Fri Jul 13 15:06:22 EDT 2012

ARIN-prop-178 Regional Use of Resources

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with the Policy
Development Process.

The ARIN Advisory Council (AC) will review the proposal at their next
regularly scheduled meeting (if the period before the next regularly
scheduled meeting is less than 10 days, then the period may be extended
to the subsequent regularly scheduled meeting). The AC will decide how
to utilize the proposal and announce the decision to the PPML.

The AC invites everyone to comment on the proposal on the PPML,
particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

Draft Policies and Proposals under discussion can be found at:

The ARIN Policy Development Process can be found at:

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/


Communications and Member Services
American Registry for Internet Numbers (ARIN)

## * ##

ARIN-prop-178 Regional Use of Resources

Proposal Originator: David Farmer

Date: 13 July 2012

Proposal type: New

Policy term: Permanent

Policy statement:

Add the following as a new policy section, substituting the actual
section number selected for X:

X. Regional Use of Resources

All requests for number resources must meet the following criteria
regarding regional use of resources, in addition to any resource
specific criteria.

X.1 Use in ARIN Region

All organizations are entitled to receive resources from ARIN for use
inside the ARIN service region and may use an incidental total of its
ARIN registered resources outside the region. One eighth (or 12.5%) of
said resources by each type, but no less than a /24 for IPv4, a /48 for
IPv6, and one ASN, are considered incidental for this purpose.

X.2. Headquartered in the ARIN Region

Only organizations headquartered in the ARIN service region are entitled
to receive resources from ARIN for use outside the region, in excess of
the incidental use defined above, to operate a connected multi-region
network, provided they have not received any resources for the same
infrastructure from another RIR.

If such an organization has received any resources from another RIR, an
operational justification is required to clarify how the resources from
ARIN will not duplicate any resources from another RIR. However, it is
never justified to receive resources from ARIN and another RIR in order
to evade another RIR’s policies, or solely based on the availability of
resources from another RIR, or the lack thereof.

X.3. Preceding Use of Resources

All ARIN registered resources received and used outside the ARIN region
prior to implementation of this policy, may continue to be used outside
the ARIN region. However, such resources are counted toward an
organization’s incidental use outside the region, unless the resources
qualify under X.2.

X.4. Critical Infrastructure Exempt

All resources received under any RIR's critical infrastructure policy or
equivalent, are exempt from this policy, due to their small resource
impact and importance to Internet stability and operations.

X.5. Use in Multiple Locations

Any resource used simultaneously in multiple locations, like an anycast
prefix or ASN, is considered used inside the region, provided at least
one of the locations is inside the region, regardless of how many other
locations outside the region its also used.

X.6. Service Region and Headquarters when received

The service region in effect and headquarters location of an
organization when resources were originally received applies to any
utilization review of those resources.


The primary purpose of this policy is to determine who is entitled to
request new resources, either by direct assignment, allocation, or
transfer, from ARIN and for use in what service regions. The following
summarizes the essence of it:

• Anyone (either from inside or outside the region) may receive
resources for use (fulfilling operational need) inside the ARIN region
and use a small amount outside the region.

• Anyone headquartered (primary center of business or administrative
operations) inside the ARIN region may receive resources for use in a
globally connected network, only if they have not received resources
from another RIR for the same purpose. If they have received any
resources from another RIR, they must explain how the ARIN resources
requested are not intended for the same purpose.

There are numerous operational justifications for requesting resources
from ARIN for use outside the region and from other RIRs. The
justification is necessary to override any assumption that the resources
duplicate each other. The following are just a few common examples:

• It may be necessary to use resources from another RIR to meet legal or
regulatory requirements, or prevailing operational expectations, in some
economies around the world. In such cases it is justified to also
receive minimal resources from another RIR for use in those economies
instead of using resources received from ARIN.

• If an organization operates a connected network in some regions, but
disconnected networks in other regions, the disconnected networks must
receive resources from other RIRs.

• If an organization receives resources from one or more other RIRs,
without additional justification such as above, only an incidental
amount of ARIN resources may be used within those regions. ARIN
resources may be used in the other regions where resources were not

Why 12.5% for incidental? First thought was simply a 90-10 rule, but
12.5% or 1/8th works better with powers of 2 and bit boundary prefixes.
Example: an organization that has a /20 from ARIN can simply use up to
a /23 outside the region, whereas 10% would result in an ugly fraction
of 1.6 /24s, instead of the simple /23 of 12.5%. The other limits set a
floor for each type of resource to ensure that all organizations have an
operationally useful amount of resources for use outside the region. A
/24 for IPv4 and a /48 for IPv6 were selected as they are fairly common
minimum prefix sizes allowed and a fraction of an ASN doesn’t make much

To facilitate X.6 it is recommended ARIN should publish and maintain a
reference timeline of changes in the service region for ARIN and its
predecessor registries.

But we’re not headquartered in the ARIN region and are using more than
an incidental amount of ARIN resources outside the region, do we have to
return resources? No, this policy primarily determines who is entitled
to receive new resources from ARIN and X.3 explicitly allows you to
continue to use those resources outside the region. However, if you are
currently using more than 12.5% of your ARIN resources outside the ARIN
region then going forward, you are not entitled to receive additional
resources for use outside the ARIN region. If those resources were
received some time ago when the services regions were different, they
may not count against your incidental use because of X.6.

Alternatives to this proposal:

What if the most restrictive regional hierarchy were used instead?
Restricting the use of all resources to only within the region of the
RIR that allocated them. This would require an organization needing
addresses for a single globally connected infrastructure to get five
separate unaggregatable allocations, even if the organization would be
willing and able to operate under a single globally aggregatable
allocation, this should especially be possible in IPv6. This will cause
at least some unnecessary route table growth. Additionally,
organizations would be required to deal with all five RIRs, even if this
doesn’t provide additional value. Many organizations have only small
needs outside one or two of the RIRs, dealing with all five RIRs may not
provide additional value in such cases. Some organizations may not be
able to justify minimum allocations in all five RIRs, while easily
justifying a minimum allocation within at least one RIR or on an overall
global basis. However, this strict interpretation of regional hierarchy
ensures overall stewardship on a global basis.

What if the most liberal regional hierarchy were used instead? Allowing
an organization to obtain resources from one or all five RIRs and use
those resources completely unrestricted on a global basis. This solves
most of the drawbacks of the strict regional hierarchy. However, taken
to an extreme, this could allow an organization to obtain as much as
five times its justifiable global need, creating an obvious stewardship
issue on a global basis, this is the primary drawback of this option.
Also, it is difficult to understand what functional purpose defining
regions actually serves with this option. Finally, with IPv4 run-out
this option has the additional drawback of allowing completely
unrestricted RIR shopping.

Benefits to this Proposal:

The RIR System was created to facilitate stewardship within the global
Internet allowing for better interactions with users and ISPs by
providing support during operational hours, in languages and with
cultural understanding appropriate to and under the control of each
region. This can only be accomplished if the RIR’s regions have at
least some meaning. However, an overly strict interpretation of the
regions will create operational inefficiencies for many networks and for
the Internet as a whole in other cases. This policy creates a framework
providing necessary flexibility for the community, while ensuring
overall stewardship of resources on a global basis.

The genesis of this policy is from the ARIN XXVII Policy Experience
Report and the outcome of the discussions of ARIN-2011-13 at ARIN
XXVIII. This policy is intended to be generally consistent with current
practice and community intent while formally spelling out and clarifying
several aspects that are currently open to interpretation.

Further, this policy explicitly seeks to head off risks of RIR shopping
based on free pool availability. Concerns regarding this were expressed
by the community and in the ARIN XXVII Policy Experience Report.

Timetable for implementation: Immediate

More information about the ARIN-PPML mailing list