GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2685

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:
  1. In a MIB to configure attributes to a VPN, or to assign a physical

or logical access interface to a particular VPN.

  1. 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 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:
  1. Provide a globally unique VPN Identifier usable across

multiple Service Providers.

  1. Enable support of a non-IP dependent VPN-ID for use in

layer 2 VPNs.

  1. 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

Fox & Gleeson Standards Track [Page 3] RFC 2685 Virtual Private Networks Identifier September 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 (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

Fox & Gleeson Standards Track [Page 4] RFC 2685 Virtual Private Networks Identifier September 1999

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

Fox & Gleeson Standards Track [Page 5] RFC 2685 Virtual Private Networks Identifier September 1999

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.

Fox & Gleeson Standards Track [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2685.txt · Last modified: 1999/09/13 16:09 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki