Internet Engineering Task Force Barbara A. Fox INTERNET-DRAFT Lucent Technologies Bryan Gleeson Expires May 1999 Shasta Networks, Inc. Virtual Private Networks Identifier Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract Virtual Private IP networks may span multiple Autonomous Systems or Service Providers. There is a requirement for the use of a globally unique VPN identifier in order to be able to refer to a particular VPN (see section 6.1.1 of [1]). This document proposes a format for a globally unique VPN identifier. 1. Introduction As the Public Internet expands and extends its infrastructure globally, the determination to exploit this infrastructure has led to widespread interest in IP based Virtual Private Networks. This VPN emulates a private IP network over public or shared infrastructures. Virtual Private Networks provide advantages to both the Service Provider and its customers. For its customers, a VPN can extend the Fox, Gleeson [Page 1] INTERNET-DRAFT VPN-ID Expires May 1999 IP capabilities of a corporate site to remote offices and/or users with intranet, extranet, and dialup services. This connectivity should be achieved at a lower cost to the customer with savings in capital equipment, operations, and services. The Service Provider is able to make better use of its infrastructure and network administration expertise offering IP VPN connectivity and/or services to its customers. There are many ways in which IP VPN services may be implemented. The IP based VPN framework document [1] identifies four types of VPN to be supported: Virtual Leased Lines, Virtual Private Routed Networks, Virtual Private Dial Networks, and Virtual Private LAN Segments. In addition, numerous drafts and white papers outline methods to be used by Service Providers and/or Service Provider customers to enable this service. Solutions may be customer based or network based. Network based solutions may provide connectivity and services at layer 2 and/or layer 3. The devices involved in enabling the solution may be Customer Premises Equipment (CPE), Service Provider Edge equipment, Service Provider Core equipment, or some combination of these. While the various methods of VPN service implementation are being discussed and debated, there are two points on which there is agreement: Because a VPN is private, it may use a private address space which may overlap with the address space of another VPN or the Public Internet. A VPN may span multiple IP Autonomous Systems (AS) or Service Providers. The first point indicates that an IP address only has meaning within the VPN in which it exists. For this reason, it is necessary to identify the VPN in which a particular IP address has meaning, the "scope" of the IP address. The second point indicates that several methods of VPN service implementation may be used to provide connectivity and services to a single VPN. Different service providers may employ different strategies based on their infrastructure and expertise. It is desirable to be able to identify any particular VPN at any layer and at any location in which it exists using the same VPN identifier. Fox, Gleeson [Page 2] INTERNET-DRAFT VPN-ID Expires May 1999 2. Global VPN Identifier The purpose of a VPN-ID is to identify a VPN. This identifier may be used in various ways depending on the method of VPN service implementation. For example, the VPN-ID may be included: - In a MIB to configure attributes to a VPN, or to assign a physical or logical access interface to a particular VPN. - In a control or data packet, to identify the "scope" of a private IP address and the VPN to which the data belongs. It is necessary to be able to identify the VPN with which a data packet is associated. The VPN-ID may be used to make this associatio, either explicitly (e.g. through inclusion of the VPN-ID in an encapsulation header) or implicitly (e.g. through inclusion of the VPN-ID in a signalling exchange). There is another very important function that may be served by the VPN identifier. The VPN identifier may be used to define the "VPN authority" who is responsible for coordinating the connectivity and services employed by that VPN. The VPN authority may be the Private Network administrator or the primary Service Provider. The VPN authority will administer and serve as the main point of contact for the VPN. The authority may outsource some functions and connectivity, set up contractual agreements with the different Service Providers involved, and coordinate configuration, performance, and fault management. These functions require a VPN that is global in scope and usable in various solutions. To be a truly global VPN identifier, the format cannot force assumptions about the shared network(s). Conversely, the format should not be defined in such a way as to prohibit use of features of the shared network. It is necessary to note that the same VPN may be identified at different layers of the same shared network, e.g. ATM and IP layers. The same VPN-ID format should apply at both layers. The methods of VPN-ID usage are beyond the scope of this draft. 3. Currently Proposed Formats There are currently three proposed formats for a VPN identifier. The first proposed format is a 2 octet identifer that specifies a VPN index within an AS (see [2]). This format works for VPNs that are contained within a single AS but is insufficient for VPNs that span Fox, Gleeson [Page 3] INTERNET-DRAFT VPN-ID Expires May 1999 multiple AS. However, one could argue that it is not necessary to have a globally unique VPN-ID for a VPN that is wholly contained in a single AS. The second proposed format is a 4 octet identifier consisting of a 2 octet "home" AS followed by a 2 octet VPN index within that AS (see [1]). This format works for VPRNs, however, it is insufficient for Service Providers that offer VPN service based on layer 2 connectivity only. In this case, the Service Provider may not have an AS to assign to the VPN as it is not necessary for their solution. In addition, the 2 octet VPN index may be too limited for a long term solution. The third proposed format is a 7 octet identifier consisting of a 3 octet OUI identifying the authoritative VPN provider followed by a 4 octet VPN identifier indicating a specific VPN offered by that Service Provider (see [3]). This format works for ATM but is too long to be carried in the 4 octet BGP community attribute for piggybacking VPN information in the BGP routing messages (see [4]). 4. Global VPN Identifier Format Requirements The VPN Identifier format should meet the following requirements: - Provide a globally unique VPN Identifier. - Enable support of a 32 bit VPN-ID for use in the BGP community attribute. - Enable support of a non-IP dependant VPN-ID for use in layer 2 VPNs. - Identify the VPN Authority within the VPN Identifier. 5. Proposed format of the global VPN Identifier The proposed format is: 3 octet VPN authority OUI followed by 4 octet VPN index identifying VPN according to OUI Fox, Gleeson [Page 4] INTERNET-DRAFT VPN-ID Expires May 1999 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ | VPN OUI (MSB) | +-+-+-+-+-+-+-+-+ | VPN OUI | +-+-+-+-+-+-+-+-+ | VPN OUI (LSB) | +-+-+-+-+-+-+-+-+ |VPN Index (MSB)| +-+-+-+-+-+-+-+-+ | VPN Index | +-+-+-+-+-+-+-+-+ | VPN Index | +-+-+-+-+-+-+-+-+ |VPN Index (LSB)| +-+-+-+-+-+-+-+-+ The VPN OUI identifies the VPN authority. The VPN authority will serve as the primary VPN administrator. The VPN authority may be the company/organization to which the VPN belongs or a Service Provider that provides the underlying infrastructure using its own and/or other providers' shared networks. The 4 octet VPN Index identifies a particular VPN serviced by the VPN authority. In order to use this format and still meet the requirements, it is necessary to obtain a new OUI from IANA. Use of this OUI will indicate that the VPN authority is indicated by AS number. When this XX-XX-XX [TBD] OUI is used, the VPN index consists of a 2 octet "home" AS number followed by a 2 octet VPN index within that AS (see [1]). The owner of the globally unique "home" AS number is the VPN authority. By default, a 4 octet VPN-ID implies a 7 octet VPN-ID with an OUI of XX-XX-XX [TBD]. References [1] Gleeson, Heinanen, Lin, Armitage, "A Framework for IP Based Virtual Private Networks", draft-gleeson-vpn-framework-00.txt. [2] Muthukrishnan, Malis, "Core IP VPN Architecture", draft-muthukrishnan-corevpn-arch-00.txt. [3] Petri, Elwell, "Transfer of an MPOA VPN Index by Signalling", ATM Forum, atm98-0618.txt. Fox, Gleeson [Page 5] INTERNET-DRAFT VPN-ID Expires May 1999 [4] Li, "CPE based VPNs using MPLS", draft-li-mpls-vpn-00.txt. Author Information Barbara A. Fox Lucent Technologies 300 Baker Ave, Suite 100 Concord, MA 01742-2168 phone: +1-978-287-2843 email: barbarafox@lucent.com Bryan Gleeson Shasta Networks 249 Humboldt Court Sunnyvalue CA 94089-1300 phone: +1-408-548-3711 email: bgleeson@shastanets.com Fox, Gleeson [Page 6]