[hm-staff] RE: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity
Anne Lord
anne at apnic.net
Mon Apr 5 02:11:48 EDT 2004
hi Marla,
Thought it might be useful to share with you the outcome of
one of the proposals at APNIC's recent Open Policy Policy in
KL, Malaysia in February.
The policy proposal [prop-015-v001] 'Should APNIC allocate global
unicast IPv6 address space to 'unconnected' networks?' was approved
by consensus at the meeting. Full details of the proposal and all
related documentation and presentations can be found at:
http://www.apnic.net/docs/policy/proposals/prop-015-v001.html
The proposal is now in the two month post meeting 'comment period',
after which it will be presented to the Executive Council for
endorsement.
As background information to the proposal, the APNIC Executive council
made a decision on behalf of the members to respond to the issue
of IPv6 allocations to 'closed/private' networks which was raised on
the globally co-ordinated IPv6 mailing list last year
<global-v6 at apnic.net>:
http://www.apnic.net/mailing-lists/global-v6/archive/2003/10/msg00008.html
The issue is fully explained in the 'interim statement' issued
by the EC:
http://www.apnic.net/docs/policy/ipv6-policy-clarification.html
Best wishes,
Anne
_____________________________________________________________________
Anne Lord, Manager, Policy Liaison <anne at apnic.net>
Asia Pacific Network Information Centre phone: +61 7 3858 3100
http://www.apnic.net fax: +61 7 3858 3199
----------------------------------------------------------------------
On Wed, 31 Mar 2004, Azinger, Marla wrote:
> 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-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.
> _______________________________________________
> Hostmaster-staff mailing list
> Hostmaster-staff at apnic.net
> http://mailman.apnic.net/mailman/listinfo/hostmaster-staff
>
More information about the ARIN-PPML
mailing list