[ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity

[Member Services]

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

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:
http://www.arin.net/policy/ipep.html

ARIN's Policy Proposal Archive is available at:
http://www.arin.net/policy/proposal_archive.html


Member Services 
American Registry for Internet Numbers (ARIN) 


### * ### 


Policy Proposal 2004-3: Global Addresses for Private Network Inter-
Connectivity

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.

Rationale: 

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.

RFC Considerations
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
     categories:

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

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

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

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.

Meeting Considerations:

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
     addresses.  
  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 
     for ARIN.   

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.  

References: 

internet-draft-guichard-pe-ce-addr-03.txt. "Address Allocation for  
PE-CE links within a Provider Provisioned VPN Network," Jim Guichard,  
et al.  
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-guichard-pe-ce-addr-03.txt 

RFC2050. "INTERNET REGISTRY IP ALLOCATION GUIDELINES," 
Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, Jon Postel.
http://www.arin.net/library/rfc/rfc2050.txt 

RFC2547. "BGP/MPLS VPNs," Eric Rosen, Rakov Rekhter.  
http://www.ietf.org/rfc/rfc2547.txt 

RFC1918. "Address Allocation for Private Internets," Yakov Rekhter,  
Robert Moskowitz, Daniel Karrenberg, Geert Jan de Groot, Eliot Lear.  
http://www.arin.net/library/rfc/rfc1918.txt 

Timetable for implementation:  This policy should be applied 
immediately, contingent upon final approval by the Board.