[ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity
ARIN welcomes feedback and discussion about the following policy
proposal in the weeks leading to the ARIN Public Policy Meeting
in Vancouver, Canada, scheduled for April 19-20, 2004.
According to the ARIN Internet Resource Policy Evaluation Process
the Advisory Council will evaluate policy proposals after the Public
Policy Meeting. The feedback and discussion of policy proposals
on the Public Policy Mailing List will be included in the AC's
Subscription information for the ARIN Public Policy Mailing List is
available at http://www.arin.net/mailing_lists/index.html
The ARIN Internet Resource Policy Evaluation Process is available at:
ARIN's Policy Proposal Archive is available at:
American Registry for Internet Numbers (ARIN)
### * ###
Policy Proposal 2004-3: Global Addresses for Private Network Inter-
Author: Marla Azinger and Bill Copeland
Policy statement: Interfaces that connect private networks may be
assigned globally unique address space. Hosts within the administrative
control of a single organization should still use private address space
in accordance with RFC-1918 and RFC-2050. This policy is not intended
to override other policies with regard to justification, minimum size,
fees, or any other standard procedure.
RFC-1918 and RFC-2050 are somewhat ambiguous concerning the use of
registered IP addresses when connecting separate private networks.
Further, with the complexity of today's private interconnections, it
is not feasible to coordinate RFC-1918 private space among many
enterprises. Therefore, this proposal seeks to expressly allow the
use of registered space on the interfaces between private networks.
Many private networking scenarios present the address assignment
problem that this proposal seeks to resolve. These include private
network interconnections, Virtual Private Networks (VPNs) using a
common layer 3 transport, and service provider RFC-2547 networks that
establish multiple VPNs. In the RFC-2547 case, the VPNs are isolated
via separate routing tables. However, the use of extranets,
partnerships, and other shared applications between VPNs complicate
the address assignment on the PE-CE links.
Per RFC-2050: "In order for the Internet to scale using existing
technologies, use of regional registry services should be limited to
the assignment of IP addresses for organizations meeting one or more
of the following conditions:
a) the organization has no intention of connecting to
the Internet-either now or in the future-but it still
requires a globally unique IP address. The organization
should consider using reserved addresses from RFC-1918.
If it is determined this is not possible, they can be
issued unique (if not Internet routable) IP addresses.
b) the organization is multi-homed with no favored connection.
c) the organization's actual requirement for IP space is
very large, for example, the network prefix required to
cover the request is of length /18 or shorter."
Based on experience, ARIN has interpreted the RFC consistently to mean
that organizations not connected to the global, public Internet do not
need globally unique IP address space. However, there is no specific
policy for the situation described in this proposal.
In addition, RFC-1918 says:
"Hosts within enterprises that use IP can be partitioned into three
Category 1: hosts that do not require access to hosts in other
enterprises or the Internet at large; hosts within
this category may use IP addresses that are
unambiguous within an enterprise, but may be
ambiguous between enterprises.
Category 2: hosts that need access to a limited set of outside
services (e.g., E-mail, FTP, netnews, remote login)
which can be handled by mediating gateways (e.g.,
application layer gateways). For many hosts in this
category an unrestricted external access (provided
via IP connectivity) may be unnecessary and even
undesirable for privacy/security reasons. Just like
hosts within the first category, such hosts may use
IP addresses that are unambiguous within an
enterprise, but may be ambiguous between
Category 3: hosts that need network layer access outside the
enterprise (provided via IP connectivity); hosts in
the last category require IP addresses that are
It is clear that routers need access to each other, and the layer 3
VPN requires non-conflicting addresses between routers. To be
specific and conservative, non-conflicting addresses between PE-CE
links are required. So, while it is true that one VPN customer
organization's router (host) may not need to reach another VPN customer
organization's router (host), the VPN provider needs to reach both
routers. In some cases, VPN customer organizations do need to be able
to reach each other, as in the case of business partnerships or
It should be noted that the authors of RFC-1918 made some consideration
of this scenario, and the RFC seems to suggest that the private space
it reserves should not be used for interconnected enterprises. However,
there is no ARIN policy to allow for allocation for these enterprises.
To recognize earlier work in this area, an Internet Draft was prepared
to resolve the policy vacuum, known as internet-draft-guichard-pe-ce,
by Jim Guichard et al. The draft proposed to use a large block, e.g.,
/8, to be used by all service providers for private interconnection
purposes. The draft failed to reach consensus support.
Finally, it should be noted that even if another addressing scheme is
used, a router used to connect to a VPN may also be connected
to the Internet. Network Address Translation (NAT) cannot be used in
two instances on a single router in common practice. Any address
space outside of RFC-1918 must be considered routable. Therefore,
if the network local to the router uses RFC-1918 space and NAT is
used to translate addresses back to the Internet, it cannot use
another instance of NAT back to the VPN.
Actual Network Case Study
There are many different situations in which it seems public IP
addresses are needed to support a widely used private network. For
example, the E-911 networks facilitate confidential communication
among Police Stations, Fire Stations, Sheriff Stations, State Trooper
Stations and various other Emergency Response Programs.
Background: Every city and state deploys E-911 services separately.
This has created multiple private networks within every County in the
United States. There is now an increasing effort to allow these
separate entities to communicate with each other. This may be achieved
by putting these individual E-911 networks onto one larger connected
private network while at the same time leaving each individual network
with its own autonomy. Since every separate private network is
maintaining it's very own private network and utilizing the private
IP blocks within it's own network...there are no private IP's easily
identified for use in this connected private network. Also, due to
the delicate nature of this E-911 network it is imperative that no IP
range is utilized more than once. This leaves us with only one option.
This option is to use public IP's on the E- 911 Connective Networks.
Technical Translation: In some cases these are private networks, and
in other cases these are Virtual Private Networks (VPN) using a common
layer 3 transport. When these networks connect, there is the possibility
that addresses assigned in good faith on one network may overlap
addresses assigned in good faith on the other. This will cause routing
instability and reachability problems.
How this has been handled in the past? With or without the knowledge
of the upstream provider, public IP addresses are already being used
for these private networks. There is currently one specific company
working with ELI for creating several of these "E-911 connected"
private networks. This company has already obtained several different
blocks from multiple large ISPs.
Why bring this proposal to the table now? Two reasons exist:
1) to make the entire community aware of this situation, and,
2) to provide a clearly documented solution that is supported by ARIN
and the Internet community.
Apr 2004 1st Day of Conference: Vote on yes or no to implement use of
Public IP's for Private use when requirements are met. The initial vote
should solely be based on "should we allow this to happen for
company X if they fit the approved requirements list."
Apr 2004 2nd Day of Conference: Vote on requirements and supporting
questions detailed below in *proposal step 2. The second day/session
will be used to vote in or out what will comprise the "approved
requirements and who does the assigning".
*Policy proposal step 2
Several issues remain should this proposal pass.
1. Should a special block of IP addresses be set aside for this
application as suggested in the earlier work by Jim Guichard?
a. Pro: This approach will potentially consume fewer
b. Con: Networks using IP addresses for this purpose
already exist and the operators will not want to renumber. A
grandfather clause would be needed to protect those that are
already using IP addresses in this manner.
2. Who should assign these IP's? Upstream and ARIN?
a. Upstream Pro: Sometimes this is appropriate if the
private network has an ISP that can accommodate the request.
b. Upstream Con: Some service providers are their own ISP
and need to resort to ARIN for additional address space.
c. ARIN Pro: This is the only choice for major service providers.
d. ARIN Con: This choice incurs more administrative overhead
3. What are the qualifications for an operator to be allocated IP
addresses for this application? The following are acceptable
applications of this proposal.
a. Emergency Use (Police enforcement organizations, Fire
departments, 911 dispatch units)
b. Life support line (i.e. crisis hot lines and hospitals)
c. Layer 3 VPN service providers
d. RFC-2547 public service providers
e. Other private networks not under the same administrative
control that must interconnect.
internet-draft-guichard-pe-ce-addr-03.txt. "Address Allocation for
PE-CE links within a Provider Provisioned VPN Network," Jim Guichard,
RFC2050. "INTERNET REGISTRY IP ALLOCATION GUIDELINES,"
Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, Jon Postel.
RFC2547. "BGP/MPLS VPNs," Eric Rosen, Rakov Rekhter.
RFC1918. "Address Allocation for Private Internets," Yakov Rekhter,
Robert Moskowitz, Daniel Karrenberg, Geert Jan de Groot, Eliot Lear.
Timetable for implementation: This policy should be applied
immediately, contingent upon final approval by the Board.