idnits 2.17.1 draft-dasilva-l2tp-relaysvc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 33 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 44 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (February 2002) is 8099 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2434' on line 509 ** Downref: Normative reference to an Informational RFC: RFC 2516 (ref. '3') Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. M. Townsley 3 Internet-Draft cisco Systems 4 Ron da Silva 5 AOL Time Warner 6 February 2002 8 L2TP Active Discovery Relay for PPPoE 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of RFC2026 Section 10. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (C) The Internet Society (2002). All Rights Reserved. 35 Abstract 37 The Point-to-Point Protocol (PPP) [1] provides a standard method for 38 transporting multi-protocol datagrams over point-to-point links. 39 Layer Two Tunneling Protocol (L2TP) [2], facilitates the tunneling of 40 PPP packets across an intervening packet-switched network. And yet a 41 third protocol, PPP over Ethernet (PPPoE) [3] describes how to build 42 PPP sessions and to encapsulate PPP packets over Ethernet. 44 L2TP Active Discovery Relay for PPPoE describes a method to relay 45 Active Discovery and Service Selection functionality from PPPoE over 46 the reliable control channel within L2TP. Two new L2TP control 47 message types and associated PPPoE-specific Attribute Value Pairs 48 (AVPs) for L2TP are defined. This relay mechanism provides enhanced 49 integration of a specific feature in the PPPoE tunneling protocol 50 with L2TP. 52 Contents 54 Status of this Memo.......................................... 1 55 1.0 Introduction.......................................... 2 56 2.0 Protocol Operation.................................... 3 57 2.1 PPPoE Active Discovery Stage.......................... 3 58 2.2 Session Establishment and Teardown.................... 4 59 2.3 PPPoE PAD Message Exchange Coherency.................. 6 60 2.4 PPPoE Service Relay Capabilities Negotiation.......... 8 61 2.4.1 PPPoE Service Relay Response Capability AVP...... 8 62 2.4.2 PPPoE Service Relay Forward Capability AVP....... 9 63 3.0 L2TP Service Relay Messages........................... 10 64 3.1 Service Relay Request Message (SRRQ).................. 10 65 3.2 Service Relay Reply Message (SRRP).................... 10 66 4.0 PPPoE Relay AVP....................................... 10 67 5.0 Security Considerations............................... 11 68 6.0 IANA Considerations................................... 11 69 7.0 Acknowledgements...................................... 11 70 8.0 References............................................ 12 71 8.1 Normative References.................................. 12 72 8.2 Informative References................................ 12 73 9.0 Author's Addresses.................................... 12 75 Appendix A: PPPoE Relay in Point to Multipoint Environments.. 13 77 Appendix B: PAD Message Exchange Coherency Examples.......... 13 79 1.0 Introduction 81 PPPoE is often deployed in conjunction with L2TP to carry PPP frames 82 over a network beyond the reach of the local Ethernet network to 83 which a PPPoE Host is connected. For example, PPP frames tunneled 84 within PPPoE may be received by an L2TP Access Concentrator (LAC) and 85 then tunneled to any L2TP Network Server (LNS) reachable via an IP 86 network. 88 In addition to tunneling PPP over Ethernet, PPPoE defines a simple 89 method for discovering services offered by PPPoE Access Concentrators 90 (PPPoE AC) reachable via Ethernet from the PPPoE Host. Since the 91 packets used in this exchange are not carried over PPP, they are not 92 tunneled with the PPP packets over L2TP, thus the discovery 93 negotiation cannot extend past the LAC without adding functionality. 95 This document describes a simple method for relaying PPPoE Access 96 Discovery (PAD) messages over L2TP by extracting the PAD messages and 97 sending them over the L2TP control channel. After the completion of 98 setup through the processing of PAD messages, PPP packets arriving 99 via PPPoE are then tunneled over L2TP in the usual manner as defined 100 in L2TP [2]. Thus, there are no data plane changes required at the 101 LAC or LNS to support this feature. Also, by utilizing the L2TP 102 control channel, the PPPoE discovery mechanism is transported to the 103 LNS reliably, before creation of any L2TP sessions, and may take 104 advantage of any special treatment applied to control messages in 105 transit or upon receipt. 107 2.0 Protocol Operation 109 When PPPoE PAD messages are received at a PPPoE Access Concentrator, 110 the messages are passed over the L2TP control connection via a newly 111 defined Service Relay Request Message (SRRQ) on an established tunnel 112 (Section 3.1). When received, the PPPoE PAD message is processed at 113 the L2TP node, or relayed to another L2TP node or PPPoE Access 114 Concentrator. PPPoE PAD messages sent as replies are handled in a 115 similar manner over a newly defined Service Relay Reply Message 116 (SRRP) (Section 3.2). 118 2.1 PPPoE Active Discovery Stage 120 When a PPPoE Active Discovery Initiation packet (PADI) is received by 121 an L2TP LAC that is providing PPPoE Service Relay, the PADI MUST [4] 122 be packaged in its entirety (including the Ethernet MAC header) 123 within the PPPoE Relay AVP and transmitted over established L2TP 124 Control Connection(s) associated with the interface on which the PADI 125 arrived. 127 The PPPoE Relay AVP is sent via the Service Relay Request Message 128 (SRRQ) defined in Section 3. The SRRQ message MUST NOT be sent to an 129 L2TP node which did not include the PPPoE Service Relay Response 130 Capability AVP during control connection establishment. If no 131 acceptable control connection is available or cannot be created, 132 PPPoE PAD operation MUST be handled locally by some means (including 133 intentionally ignoring the PPPoE PAD message, though this must be a 134 deliberate act). 136 It is a matter of local policy as to which control connections will 137 be established for relay and associated with a given interface, and 138 when the Control Connections will be established. For instance, an 139 implementation may "nail up" a control connection to a particular 140 L2TP destination and associate the connection with an interface over 141 which PPPoE PADI packets will arrive. Alternatively, an 142 implementation might dynamically establish a Control Connection to a 143 predetermined destination upon receipt of a PADI, or upon receipt of 144 a PADI from a particular source. 146 Upon receipt of the SRRQ, the included PPPoE PADI message MUST be 147 processed as described in [3], be relayed to another L2TP control 148 connection, or be relayed to another PPPoE AC. 150 After processing of a PADI, any resultant PPPoE Active Discovery 151 Offer packet (PADO) MUST be encapsulated in a PPPoE Relay AVP and 152 delivered via the Service Relay Reply Message (SRRP) to the sender of 153 the SRRQ. 155 Upon receipt of an SRRP message with relayed PADO, a LAC MUST send 156 the encapsulated PADO message to the corresponding PPPoE Host. The 157 source MAC address of the PADO message MUST be one which the LAC will 158 respond to, perhaps requiring substitution of its own MAC address. 160 In each exchange above, the PPPoE Host-Uniq TAG or AC-Cookie TAG MUST 161 be used as described in Section 2.3. 163 Following is an example of the PAD exchange between an PPPoE Host, 164 LAC and LNS up to this point, assuming the L2TP Control Connection 165 has already been established. Examples that include AC-Cookie TAG and 166 Host-Uniq TAG operation are included in the Appendix. 168 PPPoE Host LAC Tunnel Switch LNS 170 PADI -> 171 SRRQ (w/PADI) -> SRRQ (w/PADI) -> 172 <- SRRP (w/PADO) <- SRRP (w/PADO) 173 <- PADO 175 2.2 Session Establishment and Teardown 177 When a LAC that is providing the PPPoE Service Relay feature receives 178 a valid PPPoE Active Discovery Request packet (PADR), the LAC MUST 179 treat this an an action for creation of a Incoming Call Request 180 (ICRQ) as defined in [2]. The resultant ICRQ message MUST contain 181 the PPPoE Relay AVP containing the PADR in its entirety. 183 Upon receipt of an L2TP ICRQ message, the LNS parses the PADR message 184 as described in [3]. If this is an acceptable PPPoE service 185 connection (e.g. the Service-Name-Error TAG would not be included in 186 a PPPoE Active Discovery Session-confirmation packet (PADS) 187 response), the L2TP Incoming-Call-Reply (ICRP) message that is sent 188 to the LAC includes the resultant PPPoE PADS encapsulated within the 189 PPPoE Relay AVP. If the service is unacceptable, the PADS with a 190 Service-Name-Error Tag is delivered via the Relay Session AVP within 191 a Call-Disconnect-Notify (CDN) message, which also tears down the 192 L2TP session. The PPPoE PADS SESSION_ID in the PPPoE Relay AVP MUST 193 always be zero as it will be selected and filled in by the LAC. 195 Upon receipt of an ICRP with the PPPoE Relay AVP, the LAC parses the 196 PADS from the AVP, inserts a valid PPPoE SESSION_ID, and responds to 197 the PPPoE Host with the PADS. The MAC address of the PADS MUST be the 198 same as that which was utilized during the PADI/PADO exchange 199 described above. The LAC also completes the L2TP session 200 establishment by sending an Incoming-Call-Connected (ICCN) to the LNS 201 and binds the L2TP session with the PPPoE session. PPP data packets 202 may now flow between the PPPoE session and the L2TP session in the 203 traditional manner. 205 If the L2TP session is torn down for any reason, the LAC MUST send a 206 PPPoE Active Discovery Terminate packet (PADT) to the host to 207 indicate that the connection has been terminated. This PADT MAY be 208 received from the LNS via the PPPoE Relay AVP within a CDN message if 209 this was a graceful shutdown initiated by the PPPoE subsystem at the 210 LNS. As with the PADS, the SESSION_ID in the PADT message is zero 211 until filled in with the proper SESSION_ID at the LAC. 213 If the LAC receives a PADT from the PPPoE Host, the L2TP session MUST 214 be shut down via the standard procedures defined in [2]. The PADT 215 MUST be sent in the CDN message to the LNS via the PPPoE Relay AVP. 216 If the PPPoE system at the LNS disconnects the session, a PADT SHOULD 217 be sent in the CDN. In the event that the LAC receives a disconnect 218 from L2TP and did not receive a PADT, it MUST generate a properly 219 formatted PADT and send it to the PPPoE Host as described in [3]. 221 Session Establishment 223 PPPoE Host LAC Tunnel Switch LNS 225 PADR -> 226 ICRQ (w/PADR) -> 227 ICRQ (w/PADR) -> 228 <- ICRP (w/PADS) 229 <- ICRP (w/PADS) 230 <- PADS 231 ICCN -> 232 ICCN -> 234 Session Teardown (LNS Initiated) 236 PPPoE Host LAC Tunnel Switch LNS 238 <- CDN (w/PADT) 239 <- CDN (w/PADT) 240 <- PADT 242 Session Teardown (Host Initiated) 244 PPPoE Host LAC Tunnel Switch LNS 246 PADT -> 247 CDN (w/PADT) -> 248 CDN (w/PADT) -> 250 2.3 PPPoE PAD Message Exchange Coherency 252 PPPoE PAD messages will arrive from multiple ethernet interfaces and 253 be relayed across multiple L2TP control connections. In order to 254 track which PAD messages must be sent where, we utilize the Host-Uniq 255 TAG and AC-Cookie TAG. Each are used in the same manner, depending on 256 which PAD message is being sent or replied to. Both take advantage of 257 the fact that any PAD message sent as a reply to another PAD message 258 MUST echo these TAGs in their entirety [3]. 260 For purposes of this discussion, it is useful to define two 261 "directions" which PAD messages will traverse during a relayed PPPoE 262 PAD message exchange. Thus, for the following example, 264 "Upstream" -----------------------> 266 PPPoE Host ------ LAC ----- Tunnel Switch ------ LNS 268 <--------------------- "Downstream" 270 PAD messages being sent from the PPPoE Host, through the LAC, Tunnel 271 Switch, and LNS, are defined to be traversing "Upstream." PAD 272 messages being sent in the opposite direction are defined to be 273 traversing "Downstream." 275 Consider further, the following observation for this example: 277 PAD messages that are sent Upstream: PADI, PADR, PADT 278 PAD messages that are sent Downstream: PADO, PADS, PADT 280 Also, there is a request/response connection between the PADI and 281 PADO which must be linked with some common value. Similarly, there is 282 a request/response connection between PADO and PADR. The PADS is sent 283 on its own with no response, but must be delivered to the sender of 284 the PADR. The PADT must be sent with the same SESSION_ID as 285 established in the PADS. 287 The goal for PAD message exchange coherency is simply ensure that the 288 connections between the PADI/PADO, PADO/PADR, and PADR/PADS and 289 PADS/PADT all remain intact as the PAD messages are relayed from node 290 to node. 292 The basic mechanism for ensuring this for PADI, PADO, and PADR 293 messages is the AC-Cookie TAG and Host-Uniq TAG. Both of these TAGs 294 are defined as arbitrary data which must be echoed in any message 295 sent as a response to another message. This is the key to tying these 296 PAD messages together at each hop. The following two rules makes 297 this possible: 299 For PAD messages that are sent Upstream, a new Host-Uniq TAG MUST 300 be inserted at each relaying node before the PAD message is 301 forwarded. There SHOULD be at most one Host-Uniq TAG per PAD 302 message. 304 For PAD messages being sent Downstream, a new AC-Cookie TAG MUST 305 be inserted at each relaying node before the PAD message is 306 forwarded. There SHOULD be at most one AC-Cookie TAG per PAD 307 message. Additionally, for an LNS receiving multiple PAD messages 308 from upstream, there SHOULD be at most one PAD message forwarded 309 downstream per received SRRP Message. In other words, there 310 SHOULD be exactly one PPPoE Relay AVP is allowed per L2TP SSRP 311 Message. 313 The exception here is the PADS, which cannot carry an AC-Cookie TAG 314 (and, thankfully, doesn't need to), and the PADT. We will discuss 315 these later in this section. Using the above rules, PADI, PADO, and 316 PADR messages may be relayed through an arbitrary number of nodes, 317 each inserting its own value to link a message response that it might 318 receive. 320 In order to implement this exchange without tying up resources at 321 each L2TP node, it is desirable to not require ephemeral state at 322 each node waiting for a message response from each forwarded PAD 323 message. This is achievable if one is willing to be very intelligent 324 about the values that will be sent in the PPPoE TAGs used for message 325 coherency. Given that the TAGs are of arbitrary size and composition 326 and are always echoed in their entirety, one may use the information 327 here to map any next relay hop information. For example, the L2TP 328 Tunnel ID (Control Connection ID) could be encoded in the TAG in 329 order to identify where to relay the message when it arrives. If one 330 chooses this method, the encoding MUST incorporate some method of 331 encryption and authentication of the value. Note that this is 332 actually quite an easy proposition given that it is only the source 333 of the encrypted and data that will ever need to decrypt and 334 authenticate the value upon receipt (thus, no key exchanges, and any 335 of a myriad of algorithms may be chosen). Individual TAGs MUST never 336 exceed 255 octets in length, and the length of an entire PPPoE 337 message MUST never exceed the maximum segment size of the underlying 338 ethernet. 340 The PADS and PADT messages do not rely on the AC-Cookie TAG or Host- 341 Uniq TAG for directing to the proper node. As described in Section 342 2.2, the L2TP session is created upon receipt of a valid PADR at the 343 L2TP LAC. Since the PADS is sent as an AVP on this message exchange, 344 its coherency may be secured via the L2TP session itself. Similarly 345 for the PADT, as it is carried in the L2TP disconnect message (CDN) 346 for the L2TP session. 348 Clients are supposed to treat an AC-Cookie TAG as an opaque object. 349 They differentiate PADOs only by MAC address, Service-Name TAG(s) and 350 by AC-Name TAG(s). If an LAC sends multiple PADOs, they should 351 contain different AC-Name TAGs. 353 Furthermore, a node performing PPPoE L2TP Relay (such as an LAC) 354 SHOULD attempt to distinguish or rate limit retransmitted PADx 355 messages (perhaps via the source MAC address and/or arriving 356 interface of the message) in order to limit the overloading of L2TP. 358 Examples of this operation for a number of scenarios and 359 considerations for certain deployment situations may be found in the 360 Appendix of this document. 362 2.4 PPPoE Service Relay Capabilities Negotiation 364 If the extensions defined in this document are present and configured 365 for operation on a given Control Connection, the AVPs listed in this 366 section MUST be present in the Start-Control-Connection-Request 367 (SCCRQ) or Start-Control-Connection-Reply (SCCRP) messages during 368 control connection setup. 370 2.4.1 PPPoE Service Relay Response Capability AVP 372 The PPPoE Service Relay Response Capability AVP, Attribute Type TBA, 373 indicates to an L2TP peer that the PPPoE Service Relay (SRRQ, SRRP) 374 messages and the PPPoE Relay AVP will be processed and responded to 375 when received. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |M|H| rsvd | Length | Vendor ID | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Attribute Type | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 The Vendor ID is the IETF Vendor ID of 0. 387 This AVP MAY be hidden (the H bit MAY be 0 or 1). 389 The M bit for this AVP may be set to 0 or 1. If the sender of this 390 AVP does not wish to establish a connection to a peer which does not 391 understand this L2TP extension, it SHOULD set the M bit to 1, 392 otherwise it MUST be set to 0. 394 The Length of this AVP is 6. 396 The AVP may be present in the following messages: SCCRQ, SCCRP 398 2.4.2 PPPoE Service Relay Forward Capability AVP 400 The PPPoE Service Relay Forward Capability AVP, Attribute Type TBA, 401 indicates to an L2TP peer that PPPoE Service Relay (SRRQ, SRRP) 402 messages and the PPPoE Relay AVP may be sent by this L2TP peer. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |M|H| rsvd | Length | Vendor ID | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Attribute Type | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 The Vendor ID is the IETF Vendor ID of 0. 414 This AVP MAY be hidden (the H bit MAY be 0 or 1). 416 The M bit for this AVP may be set to 0 or 1. If the sender of this 417 AVP does not wish to establish a connection to a peer which does not 418 understand this L2TP extension, it SHOULD set the M bit to 1, 419 otherwise it MUST be set to 0. 421 The Length of this AVP is 6. 423 The AVP may be present in the following messages: SCCRQ, SCCRP 425 3.0 L2TP Service Relay Messages 427 This section identifies two new L2TP messages used to deliver PPPoE 428 PADI and PADO messages. 430 3.1 Service Relay Request Message (SRRQ) 432 The Service Relay Request Message (SRRQ), Message Type TBD, is sent 433 by an LAC to relay requests for services. This document defines one 434 new AVP that may be present to request service in section 2. Further 435 service relay mechanisms may also use this message in a similar 436 context. Discussion of other service relay mechanisms are outside 437 the scope of this document. 439 3.2 Service Relay Reply Message (SRRP) 441 The Service Relay Reply Message (SRRP), Message Type TBD, is sent by 442 an LAC to relay responses of requests for services. This document 443 defines one new AVP that may be present as a response to a request 444 for service in section 2. Further service relay mechanisms may also 445 use this message in a similar context. Discussion of other service 446 relay mechanisms are outside the scope of this document. 448 4.0 PPPoE Relay AVP 450 The PPPoE Relay AVP, Attribute Type TBA, carries the entire PADI, 451 PADO, PADR, PADS and PADT messages within, including Ethernet MAC 452 source and destination addresses. This is the only AVP necessary for 453 relay of all PAD messages via L2TP. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 |M|H| rsvd | Length | Vendor ID | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Attribute Type | PPPoE PAD Message ... 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 ... (Until end of message is reached) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 The Vendor ID is the IETF Vendor ID of 0. 467 This AVP MAY be hidden (the H bit MAY be 0 or 1). 469 The M bit for this AVP may be set to 0 or 1. If the sender of this 470 AVP does not wish to establish a connection to a peer which does not 471 understand this L2TP extension, it SHOULD set the M bit to 1, 472 otherwise it MUST be set to 0. 474 The Length of this AVP is 6 plus the length of the PPPoE PAD Message. 476 The AVP may be present in the following messages: SRRQ, SRRP, ICRQ, 477 ICRP, ICCN, and CDN. 479 5.0 Security Considerations 481 This document describes a method for transporting packets containing 482 service selection information which is generally only available on an 483 ethernet segment and transporting it over IP via L2TP Control 484 Messages. This MAY make information regarding service offerings or 485 host identity easier to obtain to a rogue party given that it is 486 being sent over a wider variety of media, and presumably over a 487 longer distance and/or more hops or administrative domains. Whether 488 this information could be used for malicious purposes depends on the 489 information contained within, but it is conceivable that this could 490 be sensitive information, and this mechanism increases the 491 possibility that this information would be presented to an 492 interloper. There are at least two methods defined to help thwart 493 this inspection by an unauthorized individual. One of the two MUST be 494 used if the service discovery information is considered to be 495 sensitive, and is traversing an untrusted network. The first 496 suggested method is AVP hiding described in [2]. This may be used to 497 hide the contents of the packets in transit. The second and more 498 secure method is protecting L2TP with IPsec as defined in [5]. 500 6.0 IANA Considerations 502 This document requires one new "AVP Attribute" (attribute type) 503 to be assigned through IETF Consensus [RFC2434] as indicated in 504 Section 10.1 of [2]. 506 1. PPPoE Relay AVP (section 4.0) 508 This document requires two new "Message Type" to be assigned through 509 IETF Consensus [RFC2434] as indicated in Section 10.2 of [2]. 511 1. Service Relay Request Message (SRRQ) (Section 3.1) 512 2. Service Relay Reply Message (SRRP) (Section 3.2) 514 There are not additional requirements on IANA to manage numbers in 515 this document or assign any other numbers. 517 7.0 Acknowledgements 519 Thanks to Vinay Shankarkumar for valuable review, comment, and 520 implementation. 522 Thanks to David Skoll and a number of other great folks on 523 pppoe@ipsec.org providing very helpful details about their PPPoE 524 implementations. 526 Thanks to Ross Wheeler, and Louis Mamakos, and David Carrel for 527 providing valuable clarifications of PPPoE [3] while designing this 528 protocol. 530 8.0 References 532 8.1 Normative References 534 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 535 RFC 1661, July 1994. 537 [2] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer 538 Two Tunneling Protocol 'L2TP'", RFC 2661, June 1999. 540 [3] Mamakos, Lidl, Evarts, Carrel, Simone, Wheeler, 541 "A Method for Transmitting PPP Over Ethernet (PPPoE)", 542 RFC 2516, February 1999. 544 [4] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", RFC 2119, March 1997 547 8.2 Informative References 549 [5] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing 550 L2TP Using IPsec," RFC 3193, November 2001 552 9.0 Author's Addresses 554 W. Mark Townsley 555 cisco Systems 556 7025 Kit Creek Road 557 PO Box 14987 558 Research Triangle Park, NC 27709 559 mark@townsley.net 561 Ron da Silva 562 AOL Time Warner 563 12100 Sunrise Valley Dr 564 Reston, VA 20191 565 ron@aol.net 567 Appendix A: PPPoE Relay in Point to Multipoint Environments 569 The PPPoE PADI message in its native form, is sent as a broadcast 570 message on an Ethernet link. Thus, more than one AC concentrator 571 could conceivably receive and respond to this message. Similarly, a 572 PPPoE interface could be associated with more than one L2TP Control 573 Connection, in order to query multiple LNSs with potentially varying 574 service profiles, as well as to load balance requests. 576 As the PADI message is propagated, one may choose to replicate the 577 message to multiple Control Connections in order to mimic the 578 behavior of the PADI being sent on an ethernet link with multiple ACs 579 attached. If the number of replicated nodes is large, and the number 580 of hops deep, then an unmanageable "fan-out" of PADI propagation may 581 occur. Thus, care should be taken here to only replicate messages to 582 multiple Control Connections when it is absolutely necessary. 584 The only case where it is seems necessary to replicate messages to 585 multiple destinations is in the case where each destination is known 586 to have varying 587 service policies that all need to be advertised to a PPPoE Host for 588 its gathering and selection. At the time of this writing, the authors 589 know of no PPPoE Host implementations that take advantage of this 590 ability (instead, responding to only a single PPPoE PADO). This, of 591 course, is subject to change if and when PPPoE implementations are 592 advanced to this stage. 594 In cases where multiple Control Connections may exist to multiple 595 LNSs for load balancing purposes, L2TP Service Relay should take 596 measures to try one Control Connection at a time, rather than 597 broadcasting to all Control Connections simultaneously. 599 Appendix B: PAD Message Exchange Coherency Examples 601 Example 1: "PPPoE Relay With Multiple LNSs" 603 ,--- LNS1 604 / 605 Host --- LAC 606 \ 607 `--- LNS2 609 This example assumes that there is good reason to send a copy of the 610 PADI to both LNSs (e.g. each LNS may have a different service profile 611 to offer). 613 1) a. Host sends PADI via broadcast MAC address to LAC 614 b. LAC replicates the PADI message and forwards a copy to LNS1 615 Host-Uniq = R1 (assigned) 617 c. LAC replicates the PADI message and forwards a copy to LNS2 618 Host-Uniq = R2 (assigned) 620 2) a. LNS1 responds with PADO to LAC 621 Host-Uniq = R1 (echoed) 622 AC-Cookie = C1 (assigned) 624 b. LNS1 responds with PADO to LAC 625 Host-Uniq = R2 (echoed) 626 AC-Cookie = C2 (assigned) 628 c. LAC forwards both PADO messages to Host with source MAC set to 629 MAC address of LAC. PADO from (2a) is assigned new AC-Cookie 630 C1' 631 and PADO from (2b) is given AC-Cookie C2' 633 3) a. Host sends PADR to MAC address of LAC (choosing one) 634 AC-Cookie = C1' (echoed) 636 b. LAC knows to forward PADR to LNS1 based on C1' 637 AC-Cookie = C1 (echoed) 639 4) Session Establishment at the LAC commences, with further PAD 640 messages 641 carried within the context of the L2TP session itself. No need to 642 inspect the AC-Cookie TAG or Host-Uniq TAG from this point 643 forward in order to direct messages properly. 645 Example 2: "PPPoE Relay With L2TP Tunnel-Switching" 647 Host --- LAC ---- LNS1 ---- LNS2 649 1) a. Host sends PADI to LAC. 651 b. LAC sends PADI to LNS1 652 Host-Uniq = R1 (assigned) 654 c. LNS1 sends PADI to LNS2 655 Host-Uniq = R2 (assigned) 657 2) a. LNS2 responds to LNS1 with PADO 658 Host-Uniq = R2 (echoed) 659 AC-Cookie = C1 (assigned) 661 b. LNS1 relays PADO to LAC 662 Host-Uniq = R1 (echoed) 663 AC-Cookie = C1' (assigned) 665 c. LAC sends PADO to Host 666 AC-Cookie = C1'' (assigned) 668 3) a. Host sends PADR to MAC address of LAC 669 AC-Cookie = C1'' (echoed) 671 b. LAC sends PADR to LNS1 672 AC-Cookie = C1' (echoed) 674 c. LNS1 sends PADR to LNS2 675 AC-Cookie = C1 (echoed) 677 4) Session Establishment at the LAC, LNS1 and LNS2 commences, with 678 further PAD messages carried within the context of the L2TP 679 session itself. No need to inspect the AC-Cookie TAG or 680 Host-Uniq TAG from this point forward in order to direct 681 messages properly. 683 Example 3: "PPPoE Relay With Multiple PPPoE ACs" 685 ,--- AC1 686 / 687 Host --- LAC ---- LNS 688 \ 689 `--- AC2 691 In this example, AC1 and AC2 are PPPoE access concentrators on a 692 broadcast domain. Sequence of operation is as follows. 694 1) a. Host sends PADI to LAC. 696 b. LAC sends PADI to LNS 697 Host-Uniq = R1 (assigned) 699 c. LNS broadcasts PADI to AC1 and AC2 700 Host-Uniq = R2 (assigned) 702 2) a. AC1 sends PADO to LNS 703 Host-Uniq = R2 (echoed) 704 AC-Cookie = C1 (assigned) 706 b. AC2 sends PADO to LNS 707 Host-Uniq = R2 (echoed) 708 AC-Cookie = C2 (assigned) 710 c. LNS sends two PADOs to LAC 711 Host-Uniq = R1 (echoed) 712 AC-Cookie (assigned) = C1' and C2', respectively 714 d. LAC sends two PADOs to Host 715 Host-Uniq = R1 716 AC-Cookie (assigned) = C1'' and C2'', respectively 718 3) a. Host sends PADR with to LAC to select service from AC2. 719 AC-Cookie = C2'' (echoed) 721 b. LAC sends PADR to LNS AC-Cookie = C2' (echoed) 723 c. LAC sends PADR to AC2 724 AC-Cookie = C1 (echoed) 726 4) Session Establishment at the LAC, LNS and AC2 commences, with 727 further PAD messages carried within the context of the L2TP 728 session or PPPoE session itself. No need to inspect 729 the AC-Cookie TAG or Host-Uniq TAG from this point forward in 730 order to direct messages properly.