idnits 2.17.1 draft-heinanen-dns-l2tp-vpls-01.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 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. ** There are 11 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 72: '... MUST use a single VLAN ID for the s...' RFC 2119 keyword, line 75: '... VPLS service MAY support Differenti...' RFC 2119 keyword, line 105: '... MAY be 802.1Q tagged or untag...' RFC 2119 keyword, line 106: '...to connect the site to the VPN MUST be...' RFC 2119 keyword, line 111: '...e. The "owner" of a VPN MAY choose to...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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) -- No information found for draft-ietf-ppvpn-vpls-requirements - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-03) exists of draft-luciani-ppvpn-vpn-discovery-02 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-03 -- Possible downref: Normative reference to a draft: ref. '4' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Juha Heinanen 3 INTERNET DRAFT Song Networks 4 Expires March 2003 September, 2002 6 DNS/L2TP Based VPLS 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo describes a simple mechanism to implement provider 33 provisioned Virtual Private LAN Service (VPLS) using DNS and L2TP as 34 discovery, control, and data plane protocols. 36 1. Introduction 38 This memo describes a simple mechanism to implement provider 39 provisioned Virtual Private LAN Service (VPLS) [1] using DNS and 40 L2TPv3 [3] as discovery, control and data plane protocols. DNS is 41 deployed as described in [2], whereas L2TP is deployed as described 42 in [4] with minor changes. 44 An advantage of a directory (such as DNS) based discovery solution 45 for provider based VPNs is that it doesn't require BGP implementation 46 or configuration complexity in the PE routers and can be easily 47 deployed also in inter-AS cases where the VPN sites are attached to 48 PEs in more than one AS. An advantage of DNS as a directory is that 49 it has been in Internet-wide use for years and can thus be deployed 50 without any new standardization effort. 52 A similar directory based VPLS solution could be specified that uses 53 LDP for signaling and MPLS label stack encapsulation for data 54 transport. An L2TP based solution may, however, be preferable to 55 providers who are already familiar with L2TP and are not deploying 56 MPLS. An L2TP based solution may also be considered simpler to 57 manage, because L2TP tunnels are bidirectional and because L2TP 58 bundles control, data, and management planes in a single protocol. 60 Although this memo proposed the use of DNS as the discovery 61 mechanism, the described VPLS solution itself is not DNS specific. 62 Later memos may thus specify how other protocols, such as Radius or 63 LDAP, can replace DNS as the VPLS discovery mechanism. 65 2. Service Description 67 This memo supports VPLS service in a mode where each VPLS instance 68 (also called VPN for short) connects one or more CEs (also called VPN 69 sites) to a common virtual LAN. A VPN site can use either 802.1q 70 tagged or untagged (but not both) Ethernet frames to communicate with 71 the other sites of the VPN. In case of tagged frames, each VPN site 72 MUST use a single VLAN ID for the same VPN, but the VLAN ID MAY 73 differ at each VPN site. 75 VPLS service MAY support Differentiated Services treatment of tagged 76 or untagged Ethernet frames. In case of tagged frames, the desired 77 treatment of the frame is coded in the 802.1p User Priority field. 78 In case of untagged frames, all frames sent by a site receive a 79 default treatment. Differentiated Services treatment as well as 80 mapping of 802.1p User Priority values to DiffServ code points of 81 L2TP tunnels is VPLS specific and outside the scope of this memo. 83 3. Addition of Sites 85 3.1 Configuration Actions 87 A DNS/L2TP based VPLS is very easy to provision. Only the following 88 two configuration actions are needed when a new site (CE) is added to 89 a VPN (VPLS instance): 91 (1) If the PE does not previously connect any sites of this VPN, 92 the IP address (A record) of the PE is added to the directory 93 (DNS in this memo) under domain name 95 vpn-name.domain 97 The label "vpn-name" uniquely identifies the VPN within 98 "domain", which belongs to the administrative "owner" of the 99 VPN. An example of the domain name of a VPN is 100 bobsVpn.serviceProvider.net. 102 (2) An Ethernet "interface" of the PE to which the site is 103 connected to is configured to belong to the VPN by associating 104 the interface with the domain name of the VPN. The interface 105 MAY be 802.1Q tagged or untagged. In the former case, the VLAN 106 ID that is used to connect the site to the VPN MUST be 107 specified. 109 Note that also in the case of a multi-provider VPN, the 110 administrative "owner" of the VPN is the single body that operates 111 the directory for the VPN zone. The "owner" of a VPN MAY choose to 112 make all updates to the zone data of the VPN by itself or MAY allow 113 other providers to dynamically update the zone data. 115 3.2 Protocol Actions 117 After the above configuration actions, the following protocol actions 118 take place in sequence at the PE of the new site if the PE of the new 119 site doesn't previously connect any site(s) of the VPN: 121 (1) The PE of the new site checks that its own IP address has 122 become available in the directory under the domain name of the 123 VPN. 125 (2) The PE of the new site queries the directory for IP addresses 126 of the other (remote) PEs of the VPN. 128 (3) The PE of the new site establishes an L2TP Control Connection 129 with each the remote PEs unless one already exists. The Pseudo 130 Wire Capabilities List AVP of the Control Connection MUST 131 contain this and only this value: 133 0x0004 - Sessions without control word for connecting 134 Ethernet VLANs are allowed 136 The Control Connection Tie-Breaker AVP MUST be used for 137 tie-breaking. 139 (4) The PE of the new site establishes for this VPN an L2TP session 140 with each of the remote PEs unless one already exists. L2TP 141 sessions are established as defined in section 6.2.1.2 of [4] 142 with the following changes and clarifications: 144 L2TP sessions are established as for Incoming Calls using 145 ICRQ/ICRP/ICCN message exchange (see section 3.4.1 of [3]). 147 The Pseudo Wire Type AVP MUST have in its Attribute Value field 148 value 150 0x0004 - Ethernet VLAN 152 The Application Identifier AVP MUST have in its Attribute 153 Value field value 155 0xXXXX - Directory/L2TP based VPLS 157 The End Identifier AVP MUST have in its Attribute Value field 158 the domain name of the VPN: 160 0 1 2 3 161 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Domain name (vpn-name.domain) ... 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 The Application Identifier AVP and End Identifier AVP thus 167 replace the PW ID and Group ID AVPs used in [4]. 169 The Session Tie-Breaker AVP MUST be used for tie-breaking. 171 The following protocol actions take place in sequence at a PE when it 172 receives an L2TP Incoming-Call-Request from another PE for the 173 application described in this document: 175 (1) The PE checks from the directory that the other PE belongs to 176 the VPN indicated by the End Identifier AVP and that it itself 177 has at least one site in that VPN. If not, the PE responds 178 with a Call-Disconnect-Notify and no other protocol actions 179 take place at the PE. 181 The Call-Disconnect-Notify MUST include a Result Code AVP with 182 Error Code and Error Message fields. The Result Code MUST have 183 the value 0xXXXX (Session disconnected for the application 184 specific reason indicated in Error Code) and the MUST have one of the two values 187 <0x0001, "Requesting PE does not belong to the VPN"> 188 <0x0002, "Requested PE does not belong to the VPN"> 190 (2) The PE checks if it already has an L2TP session with the 191 calling PE for the VPN indicated by the End Identifier AVP. If 192 so, the PE responds with a Call-Disconnect-Notify and no other 193 protocol actions take place at the PE. 195 The Call-Disconnect-Notify MUST include a Result Code AVP with 196 Error Code and Error Message fields. The Result Code MUST have 197 the value 0xXXXX(Session disconnected for the application 198 specific reason indicated in Error Code) and the MUST have the value 201 <0x0003, "Session already exists for the VPN"> 203 (3) Otherwise the PE accepts the request with an 204 Incoming-Call-Reply. 206 If the PE of the new site already connects site(s) of this VPN, no 207 protocol actions take place at either the PE of the new site or at 208 the remote PEs. 210 4. Removal of Sites 212 4.1 Configuration Actions 214 The following configuration actions are needed when an existing site 215 (CE) is removed from a VPN: 217 (1) If the site to be removed is the last site of the VPN at the 218 PE, the IP address of the PE is removed from the directory 219 under the domain name of the VPN. 221 (2) The site is removed from the VPN by unconfiguring the VPN from 222 the "interface" of the PE to which the site is connected to. 224 4.2 Protocol Actions 226 After the above configuration actions, the following protocol actions 227 take place in sequence at the PE of the removed site if the removed 228 site was the last site of the VPN at the PE: 230 (1) The PE checks that its IP address no longer exists in the 231 directory under the domain name of the VPN. 233 (2) The PE tears down any existing L2TP sessions for the VPN by 234 sending each remote PE a Call-Disconnect-Notify. 236 The Call-Disconnect-Notify MUST include a Result Code AVP with 237 Error Code and Error Message fields. The Result Code MUST have 238 the value 0xXXXX (Session disconnected for the application 239 specific reason indicated in Error Code) and the MUST have the value 241 <0x0004, "Requesting PE does not anymore belong to the VPN"> 243 When a PE receives a Call-Disconnect-Notify from another PE for the 244 application described in this memo, no other protocol actions than 245 normal clean up of the corresponding L2TP session are needed at the 246 PE. 248 If the L2TP session that was torn down between two PEs was the last 249 session associated with the Control Connection, either PE MAY tear 250 down the Control Connection. 252 5. Failure Recovery 254 If a PE loses its Control Connection with another PE having site(s) 255 in a common VPN, the PE tries to re-establish the Control Connection 256 until (a) the Control Connection gets re-established or (b) this PE 257 or the other PE no longer have site(s) in this VPN. Once the Control 258 Connection gets re-established, the PE re-establishes an L2TP session 259 with the other PE for this VPN as described in section 3.2. 261 If an L2TP session gets teared down between two PEs and they still 262 have site(s) in the VPN of the teared down session, the two PEs try 263 to re-establish the session as described in section 3.2 as long as 264 the two PEs have site(s) in the VPN of the teared down session. 266 When a PE recovers from a crash, it adds each of the configured VPN 267 site(s) to their respective VPN(s) as described in section 3.2. 269 6. Exponential Back-off Behavior 271 If any protocol action does not succeed immediately, normal behavior 272 is that the PE keeps on trying with exponential back-off until the 273 action either succeeds or becomes invalid due to a change in VPN 274 configuration. If the protocol action fails for an implementation 275 specific prolonged period of time, the PE SHOULD notify the "owner" 276 of the VPN about the problem via a management action. 278 7. Data Plane 280 The PEs that host the sites of a VPN act as virtual, fully connected 281 learning bridges for the VPN. 283 When a PE receives a Ethernet frame from a CE for a particular VPN, 284 it adds to it a 802.1q tag (if not already present) and sets the VLAN 285 ID to zero. Treatment of the 802.1p User Priority field is VPLS 286 specific and outside the scope of this memo. 288 When a PE needs to send an Ethernet frame to a VPN site connected to 289 it, it either overwrites the VLAN ID with the VLAN ID used by the 290 site for this VPN or removes the 802.1q tag if the interface of the 291 VPN site is untagged. Treatment of the 802.1p User Priority field is 292 VPLS specific and outside the scope of this memo. 294 When a PE needs to send an Ethernet frame to another PE, the PE 295 processes the frame as described in section 6.1 of [4] using the L2TP 296 session established for this VPLS instance. Mapping of the 802.1p 297 User priority value to DiffServ code point of the L2TP packet is VPLS 298 specific and outside the scope of this memo. 300 8. Security Considerations 302 Security of DNS/L2TP based VPNs depends on security of DNS and L2TP. 303 Security of DNS is covered in section 9 or [2] and security of L2TP 304 is covered in section 9 of [3]. 306 Acknowledgements 308 I would like to thank Mark Townsley of Cisco Systems for his 309 expertise and constructive comments during the development of this 310 memo. 312 References 314 [1] Augustyn, et al., "Requirements for Virtual Private LAN Services 315 (VPLS)". draft-ietf-ppvpn-vpls-requirements-00.txt, March 2002. 317 [2] Luciani et al., "Using DNS for VPN Discovery". draft-luciani- 318 ppvpn-vpn-discovery-02.txt, March 2002. 320 [3] Lau, et al., "Layer Two Tunneling Protocol (Version 3) "L2TPv3"". 321 draft-ietf-l2tpext-l2tp-base-03.txt, June 2002. 323 [4] So, et al., Ethernet Pseudo Wire Emulation Edge-to-Edge (PWE3). 324 draft-so-pwe3-ethernet-01.txt, March 2002. 326 Author's Address 328 Juha Heinanen 329 Song Networks, Inc. 330 Hallituskatu 16 331 33200 Tampere, Finland 332 Email: jh@song.fi 334 Full Copyright 336 Copyright (C) The Internet Society (2000). All Rights Reserved. 338 This document and translations of it may be copied and furnished to 339 others, and derivative works that comment on or otherwise explain it or 340 assist in its implementation may be prepared, copied, published and 341 distributed, in whole or in part, without restriction of any kind, 342 provided that the above copyright notice and this paragraph are included 343 on all such copies and derivative works. However, this document itself 344 may not be modified in any way, such as by removing the copyright notice 345 or references to the Internet Society or other Internet organizations, 346 except as needed for the purpose of developing Internet standards in 347 which case the procedures for copyrights defined in the Internet 348 Standards process must be followed, or as required to translate it into 349 languages other than English. 351 The limited permissions granted above are perpetual and will not be 352 revoked by the Internet Society or its successors or assigns. 354 This document and the information contained herein is provided on an "AS 355 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 356 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 357 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 358 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 359 FITNESS FOR A PARTICULAR PURPOSE.