2004-3 Previous Version(s) [Archived]

Click here to view the current policy proposal text.

Policy statement

Private networks may obtain global addresses for private network usage. Hosts within the administrative control of a single organization should still use private address space in accordance with RFC-1918 and RFC-2050. Private networks may receive global IP’s for private Interconnectivity if they have already used private IP space in accordance with RFC-1918 and RFC-2050 and any further use of private IP space would result in network conflicts.

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. https://www.rfc-editor.org/rfc/rfc2050.html

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.
https://www.rfc-editor.org/rfc/rfc1918.html

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