[ppml] Proposed policy - Unique Addresses for Private Interconnections

[Member Services]

ARIN received the following policy proposal.  In accordance
with the ARIN Internet Resource Policy Evaluation Process the
proposal is being posted to the ARIN Public Policy Mailing List
and being placed on ARIN's website.

The ARIN Advisory Council will review the proposal and within
ten working days may decide to: 
1)  support the proposal as is, 
2)  work with the author to clarify, divide or combine one or more
    policy proposals, or 
3)  not support the policy proposal. 
 
If this proposal is accepted by the Advisory Council or successfully
petitioned it will be posted as a formal policy proposal to the Public
Policy Mailing List and it will be presented at the Public Policy
Meeting.  If the proposal is not supported by the AC and the author
elects not to petition or the petition fails, then the policy proposal
will be considered closed.

The ARIN Internet Resource Policy Evaluation Process is available at:
http://www.arin.net/policy/ipep.html

Mailing list subscription information is available at:
http://www.arin.net/mailing_lists/index.html

Member Services 
American Registry for Internet Numbers (ARIN) 


### * ### 


Policy Proposal Name: Unique Addresses for Private Interconnections

Author: Bill Copeland

Author's Organization: MCI

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 addressing in accordance with
RFC1918 and RFC2050.  

This policy is not intended to override other policies with regard to
justification, minimum size, fees, or any other standard procedure.


Rationale: 

HISTORY

RFC1918 and RFC2050 make some mention of networks that are not routable
on the public Internet.  An internet-draft, internet-draft-guichard-pe-ce,
proposing a large block (/8 or /12) reserved for this purpose, failed to
achieve consensus support to move forward.

Private interconnections between large organizations are becoming more and
more common.  In some cases these are private networks, and in other cases
they 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.

Some of these networks are offered by service providers who create a
network, and establish multiple VPNs to use that network.  For RFC2547
VPNs, the address space used by any single VPN will not conflict with
another, since a separate routing table is used for each network.
However, the routing tables still need reachability information provided
based on the IP address of the links between the provider's edge (PE)
and the customer's edge (CE).

RFC CONSIDERATIONS

RFC2050 says:

   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 RFC1918.
          If it is determined this is not possible, they can be
          issued unique (if not Internet routable) IP addresses.

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 not specific
policy for the situation described here.

In attention to similar situations, RFC1918 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.

It is clear that routers need access to each other, and in a layer 3
VPN that requires non-conflicting addresses between routers (to be
specific and conservative, non-conflicting addresses between PE-CE
links).  So while it is true that one VPN customer organization's router
(host) may not need to be able 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 industry interconnects or
extranets.  

It should be noted that the authors of RFC1918 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.

An Internet Draft was prepared to resolve the policy vacuum, known as
internet-draft-guichard-pe-ce, the latest version of which is available at
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-guichard-pe-ce-addr-03.txt
The draft failed to reach consensus support to move forward.

This draft described some of the alternatives to using public address 
space, and some of the cases where they won't work.

Finally, it should be noted that even if another addressing scheme is
used, a router used to connect to a VPN may also legitmately be connected
to the Internet.  Network Address Translation (NAT) cannot be used in
two instances on a single router under current technology.  Any address
space outside of RFC1918-reserved addresses must be considered routable.
Therefore, if the network local to the router uses RFC1918 space and NAT
to translate addresses back to the Internet, it cannot use another
instance of NAT back to the VPN.

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: 

The policy should be applied immediately, contingent upon final
approval by the Board and agreement that if the policy does not
pass the organization will renumber.