Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors



Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 25 June 2013

Origin - ARIN-prop-189

Draft Policy - 25 June 2013

Revised - 4 September 2013

Revised - 25 September 2013

Abandoned by the AC - 16 October 2013


Public Policy Mailing List

ARIN Public Policy Meeting:


ARIN Advisory Council:

AC Shepherds:
David Farmer, Bill Darte, and Milton Mueller


ARIN Board of Trustees:


Previous version(s)


Draft Policy ARIN-2013-6
Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors

Date: 25 September 2013

Problem Statement:

ARIN number resources should be used primarily in the ARIN region, for
ARIN region organizations. There is currently no explicit policy guiding
staff in this area, this proposal seeks to correct that.

Policy Statement:

Create new policy Section X.

X. Resource Justification within ARIN Region

Organizations requesting Internet number resources from ARIN must
provide proof that they (1) are an active business entity legally
operating within the ARIN service region, 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
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.

Authors Comments:

Although we represent law enforcement, and have brought forth this issue
based upon our concerns and experience from a law enforcement
perspective, this is a problem in which the entire ARIN community has a

As reported at the last meeting in Barbados, ARIN staff is having
difficulty verifying organizations out-of-region. In many of the cases,
particularly in VPS (Virtual Private Service), the only information
received on these organizations by ARIN is a customer name and IP
address. This information cannot be properly verified by ARIN. Accuracy
of registration data is critical to not only law enforcement, but the
greater ARIN community as it relates to abuse contact and complaints. In
fact, most issues facing law enforcement are also shared by legitimate
companies attempting, for instance, to identify an organization that has
hijacked their IP address space.

The expedited depletion of IPv4 address space in the ARIN region
certainly seems to negatively impact those organizations currently
operating in the region that may need to return to ARIN for additional
IPv4 address space. While law enforcement’s concern is that criminal
organizations outside of the ARIN region can easily and quickly request
large blocks of IPv4 address space from ARIN, organizations that are not
truly global organizations, but specific national companies from the
RIPE and APNIC regions, also have this capability which is detrimental
to true ARIN region organizations.

This policy proposal is re-enforcing practices the ARIN staff currently
employs to ensure that ARIN IP space is used for and by companies that
are legitimate and have a legitimate presence in the ARIN region. This
policy will assist in defining clear criteria that will be helpful to
ARIN staff and the community.

The primary role of RIRs is to manage and distribute public Internet
address space within their respective regions. The problem brought forth
here clearly undermines the current RIR model; if any organization can
acquire IP address space from any region, what then is the purpose of
the geographical breakdown of the five RIRs?

Advisory Council Comments:

The term "Internet number resources" or more simply "resources" should
be used instead of "IP Blocks" to more accurately reflect the totality
of the Registry. This implies both IPv4 and IPv6, as well as ASNs.

While Internet registries are organized on a regional basis, policy must
recognize that many networks, services and operations are trans-regional
and it would be burdensome and impractical to attempt to strictly
enforce territorially exclusive allocations. Therefore, policy should
seek to balance the regional structure of address allocation with
flexibility of service provision, by ensuring that ARIN's resources are
primarily aligned with the ARIN service region but facilitate
flexibility and efficiency of use by applicants from any region.

There are concerns that out of region organizations should be able to
request resources for use within the ARIN service region. The proposed
text accommodates this issue by requiring only proof that an
organization is "legally operating within the ARIN Service Region". This
includes business entities formed in the region, or other business
entities with legal branch offices within the region. So, as long as an
out of region organization is "legally operating within the ARIN Service
Region" they can request resources from ARIN.

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.

Previous discussions of the topic indicated that it is difficult to
enforce and undesirable for many in the community to dictate where
resources are to be used once they are allocated. A strategy to deal
with this is to focus the policy on the technical infrastructure and
customers used to justify the requested number resources from ARIN, as
opposed to where resources are actually used once allocated. This is a
subtle but important distinction.

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.

A concern was raised that this policy shouldn't limit or interfere with
outbound inter-RIR transfers. If we focus on what justifies a request
for resources from ARIN, outbound inter-RIR transfers shouldn't be
affected, as they are clearly based on the receiving RIR's policies.

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.

The legal jurisdiction an organization is formed in doesn't necessarily
reflect the jurisdictions in which it operates, or even that it operates
a network in a jurisdiction. This implies that we should have both
technical and legal requirements regarding operating within the ARIN
service region in order to receive resources.

This policy is not intended to have any retroactive effect. It should
not be construed to effect or invalidate any assignment or allocation
previously made by ARIN, one of its predecessor registries, or any ISP
or other LIR, based on good faith application information. In
particular direct assignments previously made to individuals are not
invalidated by this policy. However, this policy is intended to
disallow any new assignment or allocation made directly to an individual
person, consistent with current operational practice.

The original text used the term "majority", seeming to describe a
"simple," "absolute" or "overall" majority, which means greater than
50%. Many organizations don't have greater than 50% of their users or
customers in any one region. A "plurality", "relative majority",
"largest of", or more specifically "more than any other RIR's service
region" seems to be the intended and appropriate meaning of the term
"majority" in this context. Let's clarify that intent by using the term

The intent is not to require an organization to have an overall
plurality of its technical infrastructure and customers within the ARIN
service region. Rather, it is to ensure that the plurality of currently
requested resources is justified from within the ARIN region. If an
organization¹s primary, or largest, demand for resources is in another
region then the organization should request resources from that region's
RIR, at least for the demand within that other RIR's region. Further,
it is not intended to limit access to resources intended to be
exclusively used within the ARIN region.




ARIN Staff and Legal Assessment of the earlier, 4 September 2013, version of the draft

Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors

DATE: 18 September 2013

1. Summary (Staff Understanding)

This policy would require requesters to provide proof of legal presence within the ARIN region and to demonstrate that a majority (or plurality) of their technical infrastructure and customers are within the ARIN region in order to qualify and receive IPv4 and IPv6 addresses.


A. ARIN Staff Comments

· This proposal would predominantly formalize ARIN's existing practice with respect to requiring the requestor to have a legal presence in the ARIN region and to operate a network in region. However, the proposal would also create new practice and processes via inclusion of the statement "a plurality of resources requested from ARIN must be justified by technical infrastructure and customers located within the ARIN service region, and any located outside the region must be interconnected to the ARIN service region."

· This could create a scenario where a network can't get IPv4/IPv6 addresses from any RIR. For example, suppose a large network operator from another region wants to establish a presence at a datacenter in Miami. That other regional registry may decline to issue IP addresses for use in the ARIN region, but the requester would also be unable to get IP addresses from ARIN since a majority of their technical infrastructure and customers are located outside the ARIN region.

· It's unclear how the location of hosted customers is defined. If a customer resides or operates outside of ARIN’s region, but leases a dedicated server in Los Angeles, is the customer considered to be within the ARIN region since the hardware they're controlling is within the ARIN region, or are they considered to be outside the region since they reside elsewhere? How about a colocation situation where a customer who resides out of region ships a server to Los Angeles? Does the presence of a customer's hardware in the region make them in-region?

· The phrase "a majority of their technical infrastructure and customers are within the ARIN region" could be read that technical infrastructure and customers should be evaluated together as one pool. That could be problematic. Consider a hosting provider whose technical infrastructure is 100% within the ARIN region. 5% of their customers are located within the ARIN region (assuming "resides within the ARIN region" constitutes in-region). Does that mean a majority of their technical infrastructure and customers are located within the region since when you consider them in total, the majority is in-region? If the intent is to require that the majority of both be in-region, the phrasing should be something like "a majority of both their technical infrastructure and customers" to indicate each item is being evaluated independently.

· Text says, "...and any located outside the region must be interconnected to the ARIN service region." This statement is unclear. Is the intent that discrete networks overseas cannot obtain space from ARIN? (A discrete network meaning a different autonomous system number)

· There are potential implications with respect to IPv6 and proposed policy text; in particular, does the community want an organization to be able to get all space from one RIR when it comes to IPv6? If you are a multinational, and get a huge block from ARIN, and years from now your overseas division has grown and you need more space, you have to go another RIR serving that region?

· Staff notes that policy text would be inserted into NRPM section 2.2.

B. ARIN General Counsel - Legal Assessment

The current draft seeks to fill an important gap in ARIN’s policies; more specifically, policy guidance that clearly describes the degree to which a proposed recipient of number resources from ARIN has to have real installations and customers in the ARIN region.

From a legal standpoint, there are two possible spectrum points of policy to avoid: first, having inadequate policy guidance would leave policy implementation subject to a high degree of staff interpretation; and at the other end, adopting an overly prescriptive guidance or standard that fails to permit multinational business entities to obtain number resources that are needed both in the ARIN region and outside of the ARIN region from ARIN. Both extremes are unattractive for a standard setting organization such as ARIN.

In particular, the current text:

**** ‘plurality of resources requested from ARIN must be justified by technical infrastructure and customers located within the ARIN service region’ ****

should be carefully evaluated, as it sets the policy requirement of ‘plurality’ that may prove unnecessarily restrictive in some cases. A lower standard is recommended to avoid otherwise valid requesters for address resources from being precluded from obtaining number resources.

Note that policy language which provides for reasonable restrictions (e.g. requiring more than a fictitious or tenuous and limited presence for the recipient to receive the resources in this region and/or clear intention to make use of some of the resources within the region) can be adopted without creating serious legal risk.

3. Resource Impact

This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement:

A. Updated guidelines

B. Staff training