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.