Virtual Private Networks Identifier
RFC 2685

Document Type RFC - Proposed Standard (September 1999; No errata)
Authors Bryan Gleeson  , Barbara Fox 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized 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.


   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

    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

    A VPN may span multiple IP Autonomous Systems (AS) or Service

   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 appropriateness
Show full document text