idnits 2.17.1 draft-ietf-ion-vpn-id-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Barbara A. Fox 2 INTERNET-DRAFT Lucent Technologies 3 Bryan Gleeson 4 Expires January 2000 Shasta Networks, Inc. 6 Virtual Private Networks Identifier 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 Virtual Private IP networks may span multiple Autonomous Systems or 32 Service Providers. There is a requirement for the use of a globally 33 unique VPN identifier in order to be able to refer to a particular 34 VPN (see section 6.1.1 of [1]). This document proposes a format for 35 a globally unique VPN identifier. 37 1. Introduction 39 As the Public Internet expands and extends its infrastructure 40 globally, the determination to exploit this infrastructure has led to 41 widespread interest in IP based Virtual Private Networks. This VPN 42 emulates a private IP network over public or shared infrastructures. 44 Virtual Private Networks provide advantages to both the Service 45 Provider and its customers. For its customers, a VPN can extend the 46 IP capabilities of a corporate site to remote offices and/or users 47 with intranet, extranet, and dialup services. This connectivity 48 should be achieved at a lower cost to the customer with savings in 49 capital equipment, operations, and services. The Service Provider 50 is able to make better use of its infrastructure and network 51 administration expertise offering IP VPN connectivity and/or services 52 to its customers. 54 There are many ways in which IP VPN services may be implemented. The 55 IP based VPN framework document [1] identifies four types of VPN to 56 be supported: Virtual Leased Lines, Virtual Private Routed Networks, 57 Virtual Private Dial Networks, and Virtual Private LAN Segments. In 58 addition, numerous drafts and white papers outline methods to be used 59 by Service Providers and/or Service Provider customers to enable this 60 service. Solutions may be customer based or network based. Network 61 based solutions may provide connectivity and services at layer 2 62 and/or layer 3. The devices involved in enabling the solution may be 63 Customer Premises Equipment (CPE), Service Provider Edge equipment, 64 Service Provider Core equipment, or some combination of these. 66 While the various methods of VPN service implementation are being 67 discussed and debated, there are two points on which there is 68 agreement: 70 Because a VPN is private, it may use a private address space 71 which may overlap with the address space of another VPN or the 72 Public Internet. 74 A VPN may span multiple IP Autonomous Systems (AS) or Service 75 Providers. 77 The first point indicates that an IP address only has meaning within 78 the VPN in which it exists. For this reason, it is necessary to 79 identify the VPN in which a particular IP address has meaning, the 80 "scope" of the IP address. 82 The second point indicates that several methods of VPN service 83 implementation may be used to provide connectivity and services to a 84 single VPN. Different service providers may employ different 85 strategies based on their infrastructure and expertise. It is 86 desirable to be able to identify any particular VPN at any layer and 87 at any location in which it exists using the same VPN identifier. 89 2. Global VPN Identifier 91 The purpose of a VPN-ID is to identify a VPN. This identifier may be 92 used in various ways depending on the method of VPN service 93 implementation. For example, the VPN-ID may be included: 95 - In a MIB to configure attributes to a VPN, or to assign a physical 96 or logical access interface to a particular VPN. 98 - In a control or data packet, to identify the "scope" of a private 99 IP address and the VPN to which the data belongs. 101 It is necessary to be able to identify the VPN with which a data 102 packet is associated. The VPN-ID may be used to make this 103 association, either explicitly (e.g. through inclusion of the VPN-ID 104 in an encapsulation header [2]) or implicitly (e.g. through inclusion 105 of the VPN-ID in a ATM signalling exchange [3]). The appropriateness 106 of using the VPN-ID in other contexts needs to be carefully 107 evaluated. 109 There is another very important function that may be served by the 110 VPN identifier. The VPN identifier may be used to define the "VPN 111 authority" who is responsible for coordinating the connectivity and 112 services employed by that VPN. The VPN authority may be the Private 113 Network administrator or the primary Service Provider. The VPN 114 authority will administer and serve as the main point of contact for 115 the VPN. The authority may outsource some functions and 116 connectivity, set up contractual agreements with the different 117 Service Providers involved, and coordinate configuration, 118 performance, and fault management. 120 These functions require a VPN that is global in scope and usable in 121 various solutions. To be a truly global VPN identifier, the format 122 cannot force assumptions about the shared network(s). Conversely, the 123 format should not be defined in such a way as to prohibit use of 124 features of the shared network. It is necessary to note that the 125 same VPN may be identified at different layers of the same shared 126 network, e.g. ATM and IP layers. The same VPN-ID format and value 127 should apply at both layers. 129 The methods of VPN-ID usage are beyond the scope of this draft. 131 3. Global VPN Identifier Format Requirements 133 The VPN Identifier format should meet the following requirements: 135 - Provide a globally unique VPN Identifier usable across 136 multiple Service Providers. 137 - Enable support of a non-IP dependent VPN-ID for use in 138 layer 2 VPNs. 139 - Identify the VPN Authority within the VPN Identifier. 141 4. Global VPN Identifier Format 143 The global VPN Identifier format is: 145 3 octet VPN authority Organizationally Unique Identifier [4] 146 followed by 147 4 octet VPN index identifying VPN according to OUI 149 0 1 2 3 4 5 6 7 8 150 +-+-+-+-+-+-+-+-+ 151 | VPN OUI (MSB) | 152 +-+-+-+-+-+-+-+-+ 153 | VPN OUI | 154 +-+-+-+-+-+-+-+-+ 155 | VPN OUI (LSB) | 156 +-+-+-+-+-+-+-+-+ 157 |VPN Index (MSB)| 158 +-+-+-+-+-+-+-+-+ 159 | VPN Index | 160 +-+-+-+-+-+-+-+-+ 161 | VPN Index | 162 +-+-+-+-+-+-+-+-+ 163 |VPN Index (LSB)| 164 +-+-+-+-+-+-+-+-+ 166 The VPN OUI (IEEE 802-1990 Organizationally Unique Identifier) [4] 167 identifies the VPN authority. The VPN authority will serve as the 168 primary VPN administrator. The VPN authority may be the 169 company/organization to which the VPN belongs or a Service Provider 170 that provides the underlying infrastructure using its own and/or 171 other providers' shared networks. The 4 octet VPN Index identifies a 172 particular VPN serviced by the VPN authority. 174 5. Security Considerations 176 This document defines the format of the global VPN identifier without 177 specifying usage. However, the association of particular 178 characteristics and capabilities with a VPN identifier necessitates 179 use of standard security procedures with any specified usage. 180 Misconfiguration or deliberate forging of VPN identifier may result 181 different breaches in security including the interconnection of 182 different VPNs. 184 References 186 [1] Gleeson, Heinanen, Lin, Armitage, Malis, "A Framework for IP Based 187 Virtual Private Networks", work in progress. 189 [2] Grossman, Heinanen, "Multiprotocol Encapsulation over ATM Adaptation 190 Layer 5", work in progress. 192 [3] "MPOA v1.1 Addendum on VPN Support", ATM Forum, str-mpoa-vpn-01_00, 193 July, 1999, Bernhard Petri, editor, straw ballot document. 195 [4] http://standards.ieee.org/regauth/oui/index.html 197 Author Information 199 Barbara A. Fox 200 Lucent Technologies 201 300 Baker Ave, Suite 100 202 Concord, MA 01742-2168 203 phone: +1-978-287-2843 204 email: barbarafox@lucent.com 206 Bryan Gleeson 207 Shasta Networks 208 249 Humboldt Court 209 Sunnyvale, CA 94089-1300 210 phone: +1-408-548-3711 211 email: bgleeson@shastanets.com