home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2685.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  11.2 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                             B. Fox
  8. Request for Comments: 2685                           Lucent Technologies
  9. Category: Standards Track                                     B. Gleeson
  10.                                                          Nortel Networks
  11.                                                           September 1999
  12.  
  13.  
  14.                   Virtual Private Networks Identifier
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Copyright Notice
  25.  
  26.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  27.  
  28. Abstract
  29.  
  30.    Virtual Private IP networks may span multiple Autonomous Systems or
  31.    Service Providers.  There is a requirement for the use of a globally
  32.    unique VPN identifier in order to be able to refer to a particular
  33.    VPN (see section 6.1.1 of [1]).  This document proposes a format for
  34.    a globally unique VPN identifier.
  35.  
  36. 1. Introduction
  37.  
  38.    As the Public Internet expands and extends its infrastructure
  39.    globally, the determination to exploit this infrastructure has led to
  40.    widespread interest in IP based Virtual Private Networks.  A VPN
  41.    emulates a private IP network over public or shared infrastructures.
  42.    Virtual Private Networks provide advantages to both the Service
  43.    Provider and its customers.  For its customers, a VPN can extend the
  44.    IP capabilities of a corporate site to remote offices and/or users
  45.    with intranet, extranet, and dialup services.  This connectivity
  46.    should be achieved at a lower cost to the customer with savings in
  47.    capital equipment, operations, and services.   The Service Provider
  48.    is able to make better use of its infrastructure and network
  49.    administration expertise offering IP VPN connectivity and/or services
  50.    to its customers.
  51.  
  52.    There are many ways in which IP VPN services may be implemented.  The
  53.    IP based VPN framework document [1] identifies four types of VPN to
  54.    be supported:  Virtual Leased Lines, Virtual Private Routed Networks,
  55.  
  56.  
  57.  
  58. Fox & Gleeson               Standards Track                     [Page 1]
  59.  
  60. RFC 2685          Virtual Private Networks Identifier     September 1999
  61.  
  62.  
  63.    Virtual Private Dial Networks, and Virtual Private LAN Segments.  In
  64.    addition, numerous drafts and white papers outline methods to be used
  65.    by Service Providers and/or Service Provider customers to enable this
  66.    service.  Solutions may be customer based or network based.  Network
  67.    based solutions may provide connectivity and services at layer 2
  68.    and/or layer 3.  The devices involved in enabling the solution may be
  69.    Customer Premises Equipment (CPE), Service Provider Edge equipment,
  70.    Service Provider Core equipment, or some combination of these.
  71.  
  72.    While the various methods of VPN service implementation are being
  73.    discussed and debated, there are two points on which there is
  74.    agreement:
  75.  
  76.     Because a VPN is private, it may use a private address space which
  77.     may overlap with the address space of another VPN or the Public
  78.     Internet.
  79.  
  80.     A VPN may span multiple IP Autonomous Systems (AS) or Service
  81.     Providers.
  82.  
  83.    The first point indicates that an IP address only has meaning within
  84.    the VPN in which it exists.  For this reason, it is necessary to
  85.    identify the VPN in which a particular IP address has meaning, the
  86.    "scope" of the IP address.
  87.  
  88.    The second point indicates that several methods of VPN service
  89.    implementation may be used to provide connectivity and services to a
  90.    single VPN.  Different service providers may employ different
  91.    strategies based on their infrastructure and expertise.  It is
  92.    desirable to be able to identify any particular VPN at any layer and
  93.    at any location in which it exists using the same VPN identifier.
  94.  
  95. 2. Global VPN Identifier
  96.  
  97.    The purpose of a VPN-ID is to identify a VPN.  This identifier may be
  98.    used in various ways depending on the method of VPN service
  99.    implementation.  For example, the VPN-ID may be included:
  100.  
  101.     - In a MIB to configure attributes to a VPN, or to assign a physical
  102.       or logical access interface to a particular VPN.
  103.  
  104.     - In a control or data packet, to identify the "scope" of a private
  105.       IP address and the VPN to which the data belongs.
  106.  
  107.    It is necessary to be able to identify the VPN with which a data
  108.    packet is associated.  The VPN-ID may be used to make this
  109.    association, either explicitly (e.g. through inclusion of the VPN-ID
  110.    in an encapsulation header [2]) or implicitly (e.g. through inclusion
  111.  
  112.  
  113.  
  114. Fox & Gleeson               Standards Track                     [Page 2]
  115.  
  116. RFC 2685          Virtual Private Networks Identifier     September 1999
  117.  
  118.  
  119.    of the VPN-ID in a ATM signalling exchange [3]).  The appropriateness
  120.    of using the VPN-ID in other contexts needs to be carefully
  121.    evaluated.
  122.  
  123.    There is another very important function that may be served by the
  124.    VPN identifier.  The VPN identifier may be used to define the "VPN
  125.    authority" who is responsible for coordinating the connectivity and
  126.    services employed by that VPN.  The VPN authority may be the Private
  127.    Network administrator or the primary Service Provider.  The VPN
  128.    authority will administer and serve as the main point of contact for
  129.    the VPN.  The authority may outsource some functions and
  130.    connectivity, set up contractual agreements with the different
  131.    Service Providers involved, and coordinate configuration,
  132.    performance, and fault management.
  133.  
  134.    These functions require a VPN that is global in scope and usable in
  135.    various solutions.  To be a truly global VPN identifier, the format
  136.    cannot force assumptions about the shared network(s). Conversely, the
  137.    format should not be defined in such a way as to prohibit use of
  138.    features of the shared network.  It is necessary to note that the
  139.    same VPN may be identified at different layers of the same shared
  140.    network, e.g. ATM and IP layers.  The same VPN-ID format and value
  141.    should apply at both layers.
  142.  
  143.    The methods of VPN-ID usage are beyond the scope of this memo.
  144.  
  145. 3. Global VPN Identifier Format Requirements
  146.  
  147.    The VPN Identifier format should meet the following requirements:
  148.  
  149.     - Provide a globally unique VPN Identifier usable across
  150.       multiple Service Providers.
  151.     - Enable support of a non-IP dependent VPN-ID for use in
  152.       layer 2 VPNs.
  153.     - Identify the VPN Authority within the VPN Identifier.
  154.  
  155.  
  156. 4.  Global VPN Identifier Format
  157.  
  158.    The global VPN Identifier format is:
  159.  
  160.      3 octet VPN authority Organizationally Unique Identifier [4]
  161.  
  162.    followed by
  163.  
  164.      4 octet VPN index identifying VPN according to OUI
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Fox & Gleeson               Standards Track                     [Page 3]
  171.  
  172. RFC 2685          Virtual Private Networks Identifier     September 1999
  173.  
  174.  
  175.    0 1 2 3 4 5 6 7 8
  176.    +-+-+-+-+-+-+-+-+
  177.    | VPN OUI (MSB) |
  178.    +-+-+-+-+-+-+-+-+
  179.    |   VPN OUI     |
  180.    +-+-+-+-+-+-+-+-+
  181.    | VPN OUI (LSB) |
  182.    +-+-+-+-+-+-+-+-+
  183.    |VPN Index (MSB)|
  184.    +-+-+-+-+-+-+-+-+
  185.    |  VPN Index    |
  186.    +-+-+-+-+-+-+-+-+
  187.    |  VPN Index    |
  188.    +-+-+-+-+-+-+-+-+
  189.    |VPN Index (LSB)|
  190.    +-+-+-+-+-+-+-+-+
  191.  
  192.    The VPN OUI (IEEE 802-1990 Organizationally Unique Identifier) [4]
  193.    identifies the VPN authority.  The VPN authority will serve as the
  194.    primary VPN administrator.  The VPN authority may be the
  195.    company/organization to which the VPN belongs or a Service Provider
  196.    that provides the underlying infrastructure using its own and/or
  197.    other providers' shared networks.  The 4 octet VPN Index identifies a
  198.    particular VPN serviced by the VPN authority.
  199.  
  200. 5. Security Considerations
  201.  
  202.    This document defines the format of the global VPN identifier without
  203.    specifying usage.  However, the association of particular
  204.    characteristics and capabilities with a VPN identifier necessitates
  205.    use of standard security procedures with any specified usage.
  206.    Misconfiguration or deliberate forging of VPN identifier may result
  207.    different breaches in security including the interconnection of
  208.    different VPNs.
  209.  
  210. 6. References
  211.  
  212.    [1] Gleeson, Heinanen, Lin, Armitage, Malis, "A Framework for IP
  213.        Based Virtual Private Networks", Work in Progress.
  214.  
  215.    [2] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over
  216.        ATM Adaptation Layer 5", RFC 2684, September 1999.
  217.  
  218.    [3] "MPOA v1.1 Addendum on VPN Support", ATM Forum, af-mpoa-0129.000,
  219.        August, 1999, Bernhard Petri, editor, final ballot document.
  220.  
  221.    [4] http://standards.ieee.org/regauth/oui/index.html
  222.  
  223.  
  224.  
  225.  
  226. Fox & Gleeson               Standards Track                     [Page 4]
  227.  
  228. RFC 2685          Virtual Private Networks Identifier     September 1999
  229.  
  230.  
  231. 7. Authors' Addresses
  232.  
  233.    Barbara A. Fox
  234.    Lucent Technologies
  235.    300 Baker Ave, Suite 100
  236.    Concord, MA  01742-2168
  237.  
  238.    Phone: +1-978-287-2843
  239.    EMail: barbarafox@lucent.com
  240.  
  241.  
  242.    Bryan Gleeson
  243.    Nortel Networks
  244.    4500 Great America Parkway,
  245.    Santa Clara, CA  95054
  246.  
  247.    Phone: +1-408-855-3711
  248.    EMail: bgleeson@shastanets.com
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Fox & Gleeson               Standards Track                     [Page 5]
  283.  
  284. RFC 2685          Virtual Private Networks Identifier     September 1999
  285.  
  286.  
  287. 8.  Full Copyright Statement
  288.  
  289.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  290.  
  291.    This document and translations of it may be copied and furnished to
  292.    others, and derivative works that comment on or otherwise explain it
  293.    or assist in its implementation may be prepared, copied, published
  294.    and distributed, in whole or in part, without restriction of any
  295.    kind, provided that the above copyright notice and this paragraph are
  296.    included on all such copies and derivative works.  However, this
  297.    document itself may not be modified in any way, such as by removing
  298.    the copyright notice or references to the Internet Society or other
  299.    Internet organizations, except as needed for the purpose of
  300.    developing Internet standards in which case the procedures for
  301.    copyrights defined in the Internet Standards process must be
  302.    followed, or as required to translate it into languages other than
  303.    English.
  304.  
  305.    The limited permissions granted above are perpetual and will not be
  306.    revoked by the Internet Society or its successors or assigns.
  307.  
  308.    This document and the information contained herein is provided on an
  309.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  310.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  311.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  312.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  313.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  314.  
  315. Acknowledgement
  316.  
  317.    Funding for the RFC Editor function is currently provided by the
  318.    Internet Society.
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Fox & Gleeson               Standards Track                     [Page 6]
  339.  
  340.