Virtual Private Networks Identifier
RFC 2685
Document | Type |
RFC - Proposed Standard
(September 1999; No errata)
Was draft-ietf-ion-vpn-id (ion WG)
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text pdf html bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2685 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group B. Fox Request for Comments: 2685 Lucent Technologies Category: Standards Track B. Gleeson Nortel Networks September 1999 Virtual Private Networks Identifier Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 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. A 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 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, Fox & Gleeson Standards Track [Page 1] RFC 2685 Virtual Private Networks Identifier September 1999 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. 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 association, either explicitly (e.g. through inclusion of the VPN-ID in an encapsulation header [2]) or implicitly (e.g. through inclusion Fox & Gleeson Standards Track [Page 2] RFC 2685 Virtual Private Networks Identifier September 1999 of the VPN-ID in a ATM signalling exchange [3]). The appropriatenessShow full document text