VPN Identifier: Virtual Private Networks Identifier
A globally unique name for a virtual private network: an organization ID plus a 4-octet index.
Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, DOI 10.17487/RFC2685, September 1999, <https://www.rfc-editor.org/info/rfc2685>.
@misc{rfc2685,
series = {Request for Comments},
number = 2685,
howpublished = {RFC 2685},
publisher = {RFC Editor},
doi = {10.17487/RFC2685},
url = {https://www.rfc-editor.org/info/rfc2685},
author = {B. Fox and B. Gleeson},
title = {{Virtual Private Networks Identifier}},
pagetotal = 6,
year = 1999,
month = sep,
} RFC text
Contents
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,
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
of the VPN-ID in a ATM signalling exchange [3]). The appropriateness
of using the VPN-ID in other contexts needs to be carefully
evaluated.
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 and value
should apply at both layers.
The methods of VPN-ID usage are beyond the scope of this memo.
3. Global VPN Identifier Format Requirements
The VPN Identifier format should meet the following requirements:
- Provide a globally unique VPN Identifier usable across
multiple Service Providers.
- Enable support of a non-IP dependent VPN-ID for use in
layer 2 VPNs.
- Identify the VPN Authority within the VPN Identifier.
4. Global VPN Identifier Format
The global VPN Identifier format is:
3 octet VPN authority Organizationally Unique Identifier [4]
followed by
4 octet VPN index identifying VPN according to OUI
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 (IEEE 802-1990 Organizationally Unique Identifier) [4]
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.
5. Security Considerations
This document defines the format of the global VPN identifier without
specifying usage. However, the association of particular
characteristics and capabilities with a VPN identifier necessitates
use of standard security procedures with any specified usage.
Misconfiguration or deliberate forging of VPN identifier may result
different breaches in security including the interconnection of
different VPNs.
6. References
[1] Gleeson, Heinanen, Lin, Armitage, Malis, "A Framework for IP
Based Virtual Private Networks", Work in Progress.
[2] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over
ATM Adaptation Layer 5", RFC 2684, September 1999.
[3] "MPOA v1.1 Addendum on VPN Support", ATM Forum, af-mpoa-0129.000,
August, 1999, Bernhard Petri, editor, final ballot document.
[4] http://standards.ieee.org/regauth/oui/index.html
7. Authors' Addresses
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
Nortel Networks
4500 Great America Parkway,
Santa Clara, CA 95054
Phone: +1-408-855-3711
EMail: bgleeson@shastanets.com
8. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1Why VPNs Need an Identifier
A Virtual Private Network (VPN) emulates a private IP network over public or shared infrastructure. The RFC notes that many ways of providing VPN service were being discussed, and that the IP based VPN framework identifies four types: Virtual Leased Lines, Virtual Private Routed Networks, Virtual Private Dial Networks and Virtual Private LAN Segments.
Two points were agreed on by everyone. First, a VPN is private, so it may use a private address space that overlaps with another VPN or with the public Internet. Second, a VPN may span multiple Autonomous Systems or Service Providers.
Lots of private groups can use the same house numbers, and one group can live across many towns. So a house number alone is not enough to find the right house.
§2The Purpose of a VPN-ID
Because addresses can overlap, an IP address only has meaning inside the VPN where it exists. The identifier tells you the "scope" of an address. Because several providers may serve one VPN, the RFC wants one identifier that works at any layer and at any location.
The VPN-ID might appear in a MIB, to assign an access interface to a VPN, or in a control or data packet, to show the scope of a private address. It can tie a packet to a VPN explicitly (for example in an encapsulation header as in RFC 2684) or implicitly (for example in an ATM signalling exchange). The same VPN can be identified at different layers, such as ATM and IP, and the same format and value should apply at both.
The identifier also names the VPN authority, which coordinates connectivity and services for the VPN. That may be the private network's administrator or its primary Service Provider. How the VPN-ID is used is beyond the scope of the memo.
The ID says which private group an address belongs to, and who is in charge of that group. It works the same way no matter which road, rail or air route the message takes.
§3Format Requirements
The format has to meet three requirements:
- Provide a globally unique identifier usable across multiple Service Providers.
- Allow a VPN-ID that does not depend on IP, for use in layer 2 VPNs.
- Identify the VPN authority within the identifier itself.
The format also must not assume anything about the shared networks, and must not prevent use of features of the shared network.
The name has to be one-of-a-kind everywhere, work even without IP addresses, and say who is in charge.
§4The VPN Identifier Format
A global VPN identifier is a 3 octet VPN authority Organizationally Unique Identifier followed by a 4 octet VPN index. Each field is sent most significant octet first.
The OUI is an IEEE 802-1990 Organizationally Unique Identifier and identifies the VPN authority, the primary VPN administrator. That authority may be the company or organization the VPN belongs to, or a Service Provider that supplies the underlying infrastructure using its own or other providers' shared networks. The VPN index identifies one particular VPN serviced by that authority.
It is like a phone number with two parts: the first part says which company, and the second part says which of that company's private networks you mean.
§5Security Considerations
The document defines the format without specifying usage. Tying capabilities to a VPN identifier means that standard security procedures are needed with any specified usage. The RFC warns that misconfiguring or deliberately forging a VPN identifier may cause different security breaches, including interconnecting different VPNs.
If someone writes the wrong name tag, or fakes one, two private groups might end up mixed together. So the tags must be handled carefully.