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

[William Copeland]

To address the questions about the magnitude of private network numbering
and the process used to number them thus far: 

The authors of the proposal have first-hand knowledge of 10's of thousands
of PE-CE subnets that are numbered from globally unique address space.  
Given the growing popularity of private network interconnection, there are
perhaps 100's of thousands if not millions of such address assignments
today.  Also, and again from the author's view point, these assignments were
made with the full knowledge of and full disclosure to ARIN or its
representatives within our respective corporations.  The current rules of
ARIN, though a bit vague on the subject, have been interpreted thus far to
allow such assignments between private networks. 

Because the private network connections are quite complex and the networks
involved are quite large, the private address spaces employed by the various
agencies are often well populated.  To avoid any conflicting addresses, 
private network have turned to ARIN for permission to assign registered
space to the interconnecting networks only between such entities.  This
proposal seeks to codify in explicit language what has become operative
practice.

Regards   

-----Original Message-----
From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Bill
Darte
Sent: Thursday, April 01, 2004 7:25 AM
To: 'Azinger, Marla'; ppml at arin.net
Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses for Private N
etwork Inter-Connectivity

I wish to reiterate this call for comments.  I would be particularly
interested in some statistics (or firm anecdotes) about the magnitude and
trend of such need.  Also, is there some background about what technologies
are currently being employed to get around this problem and the pain that
that might involve.  Are maneuvers being employed to avoid notifying ARIN or
an upstream of this intention when requesting blocks?

Bill Darte
ARIN AC

> -----Original Message-----
> From: Azinger, Marla [mailto:marla_azinger at eli.net]
> Sent: Wednesday, March 31, 2004 2:10 PM
> To: ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses 
> for Private
> N etwork Inter-Connectivity
> 
> 
> Hello-  In preperation for the 1/2 hour slot provided at the 
> conference on
> this proposal...does anyone have any comments and/or input to 
> this one?
> 
> In order to make good use of the 1/2 hour this is slotted 
> for... we would
> like to be fully prepared ahead of time for any angles that 
> this discussion
> might take on.  So your comments ahead of time either Pro or 
> Con are greatly
> appreciated.
> 
> Thank you for your time
> Marla Azinger
> 
> 
> -----Original Message-----
> From: Member Services [mailto:memsvcs at arin.net]
> Sent: Wednesday, March 17, 2004 11:43 AM
> To: ppml at arin.net
> Subject: [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
> 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-guicha
rd-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.