diff options
Diffstat (limited to 'doc/rfc/rfc3817.txt')
| -rw-r--r-- | doc/rfc/rfc3817.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc3817.txt b/doc/rfc/rfc3817.txt new file mode 100644 index 0000000..7f967d5 --- /dev/null +++ b/doc/rfc/rfc3817.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group W. Townsley +Request for Comments: 3817 cisco Systems +Category: Informational R. da Silva + AOL Time Warner + June 2004 + + + Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay + for PPP over Ethernet (PPPoE) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + The Point-to-Point Protocol (PPP) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. + Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP + packets across an intervening packet-switched network. And yet a + third protocol, PPP over Ethernet (PPPoE) describes how to build PPP + sessions and to encapsulate PPP packets over Ethernet. + + L2TP Active Discovery Relay for PPPoE describes a method to relay + Active Discovery and Service Selection functionality from PPPoE over + the reliable control channel within L2TP. Two new L2TP control + message types and associated PPPoE-specific Attribute Value Pairs + (AVPs) for L2TP are defined. This relay mechanism provides enhanced + integration of a specific feature in the PPPoE tunneling protocol + with L2TP. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 2 + 2.1. PPPoE Active Discovery Stage . . . . . . . . . . . . . . 3 + 2.2. Session Establishment and Teardown . . . . . . . . . . . 4 + 2.3. PPPoE PAD Message Exchange Coherency . . . . . . . . . . 6 + 2.4. PPPoE Service Relay Capabilities Negotiation . . . . . . 8 + 2.4.1. PPPoE Service Relay Response Capability AVP. . . 8 + 2.4.2. PPPoE Service Relay Forward Capability AVP . . . 9 + 3. L2TP Service Relay Messages. . . . . . . . . . . . . . . . . . 9 + + + +Townsley & da Silva Informational [Page 1] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + 3.1. Service Relay Request Message (SRRQ) . . . . . . . . . . 9 + 3.2. Service Relay Reply Message (SRRP) . . . . . . . . . . . 10 + 4. PPPoE Relay AVP. . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 10 + 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 11 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + Appendix A: PPPoE Relay in Point to Multipoint Environments. . . . 13 + Appendix B: PAD Message Exchange Coherency Examples. . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17 + +1. Introduction + + PPPoE [1] is often deployed in conjunction with L2TP [2] to carry PPP + [3] frames over a network beyond the reach of the local Ethernet + network to which a PPPoE Host is connected. For example, PPP frames + tunneled within PPPoE may be received by an L2TP Access Concentrator + (LAC) and then tunneled to any L2TP Network Server (LNS) reachable + via an IP network. + + In addition to tunneling PPP over Ethernet, PPPoE defines a simple + method for discovering services offered by PPPoE Access Concentrators + (PPPoE AC) reachable via Ethernet from the PPPoE Host. Since the + packets used in this exchange are not carried over PPP, they are not + tunneled with the PPP packets over L2TP, thus the discovery + negotiation cannot extend past the LAC without adding functionality. + + This document describes a simple method for relaying PPPoE Active + Discovery (PAD) messages over L2TP by extracting the PAD messages and + sending them over the L2TP control channel. After the completion of + setup through the processing of PAD messages, PPP packets arriving + via PPPoE are then tunneled over L2TP in the usual manner as defined + in L2TP [2]. Thus, there are no data plane changes required at the + LAC or LNS to support this feature. Also, by utilizing the L2TP + control channel, the PPPoE discovery mechanism is transported to the + LNS reliably, before creation of any L2TP sessions, and may take + advantage of any special treatment applied to control messages in + transit or upon receipt. + +2. Protocol Operation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + + + + +Townsley & da Silva Informational [Page 2] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + When PPPoE PAD messages are received at a PPPoE Access Concentrator, + the messages are passed over the L2TP control connection via a newly + defined Service Relay Request Message (SRRQ) on an established tunnel + (Section 3.1). When received, the PPPoE PAD message is processed at + the L2TP node, or relayed to another L2TP node or PPPoE Access + Concentrator. PPPoE PAD messages sent as replies are handled in a + similar manner over a newly defined Service Relay Reply Message + (SRRP) (Section 3.2). + +2.1. PPPoE Active Discovery Stage + + When a PPPoE Active Discovery Initiation packet (PADI) is received by + an L2TP LAC that is providing PPPoE Service Relay, the PADI MUST be + packaged in its entirety (including the Ethernet MAC header) within + the PPPoE Relay AVP and transmitted over established L2TP Control + Connection(s) associated with the interface on which the PADI + arrived. + + The PPPoE Relay AVP is sent via the Service Relay Request Message + (SRRQ) defined in Section 3. The SRRQ message MUST NOT be sent to an + L2TP node which did not include the PPPoE Service Relay Response + Capability AVP during control connection establishment. If no + acceptable control connection is available or cannot be created, + PPPoE PAD operation MUST be handled locally by some means (including + intentionally ignoring the PPPoE PAD message, though this must be a + deliberate act). + + It is a matter of local policy as to which control connections will + be established for relay and associated with a given interface, and + when the Control Connections will be established. For instance, an + implementation may "nail up" a control connection to a particular + L2TP destination and associate the connection with an interface over + which PPPoE PADI packets will arrive. Alternatively, an + implementation might dynamically establish a Control Connection to a + predetermined destination upon receipt of a PADI, or upon receipt of + a PADI from a particular source. + + Upon receipt of the SRRQ, the included PPPoE PADI message MUST be + processed as described in [3], be relayed to another L2TP control + connection, or be relayed to another PPPoE AC. + + After processing of a PADI, any resultant PPPoE Active Discovery + Offer packet (PADO) MUST be encapsulated in a PPPoE Relay AVP and + delivered via the Service Relay Reply Message (SRRP) to the sender of + the SRRQ. + + + + + + +Townsley & da Silva Informational [Page 3] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + Upon receipt of an SRRP message with relayed PADO, a LAC MUST send + the encapsulated PADO message to the corresponding PPPoE Host. The + source MAC address of the PADO message MUST be one which the LAC will + respond to, perhaps requiring substitution of its own MAC address. + + In each exchange above, the PPPoE Host-Uniq TAG or AC-Cookie TAG MUST + be used as described in Section 2.3. + + Following is an example of the PAD exchange between a PPPoE Host, LAC + and LNS up to this point, assuming the L2TP Control Connection has + already been established. Examples that include AC-Cookie TAG and + Host-Uniq TAG operation are included in the Appendix. + + PPPoE Host LAC Tunnel Switch LNS + + PADI -> + SRRQ (w/PADI) -> SRRQ (w/PADI) -> + <- SRRP (w/PADO) <- SRRP (w/PADO) + <- PADO + +2.2. Session Establishment and Teardown + + When a LAC that is providing the PPPoE Service Relay feature receives + a valid PPPoE Active Discovery Request packet (PADR), the LAC MUST + treat this as an action for creation of a Incoming Call Request + (ICRQ) as defined in [2]. The resultant ICRQ message MUST contain + the PPPoE Relay AVP containing the PADR in its entirety. + + Upon receipt of an L2TP ICRQ message, the LNS parses the PADR message + as described in [3]. If this is an acceptable PPPoE service + connection (e.g., the Service-Name-Error TAG would not be included in + a PPPoE Active Discovery Session-confirmation packet (PADS) + response), the L2TP Incoming-Call-Reply (ICRP) message that is sent + to the LAC includes the resultant PPPoE PADS encapsulated within the + PPPoE Relay AVP. If the service is unacceptable, the PADS with a + Service-Name-Error Tag is delivered via the Relay Session AVP within + a Call-Disconnect-Notify (CDN) message, which also tears down the + L2TP session. The PPPoE PADS SESSION_ID in the PPPoE Relay AVP MUST + always be zero as it will be selected and filled in by the LAC. + + Upon receipt of an ICRP with the PPPoE Relay AVP, the LAC parses the + PADS from the AVP, inserts a valid PPPoE SESSION_ID, and responds to + the PPPoE Host with the PADS. The MAC address of the PADS MUST be + the same one was utilized during the PADI/PADO exchange described + above. The LAC also completes the L2TP session establishment by + sending an Incoming-Call-Connected (ICCN) to the LNS and binds the + + + + + +Townsley & da Silva Informational [Page 4] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + L2TP session with the PPPoE session. PPP data packets may now flow + between the PPPoE session and the L2TP session in the traditional + manner. + + If the L2TP session is torn down for any reason, the LAC MUST send a + PPPoE Active Discovery Terminate packet (PADT) to the host to + indicate that the connection has been terminated. This PADT MAY be + received from the LNS via the PPPoE Relay AVP within a CDN message if + this was a graceful shutdown initiated by the PPPoE subsystem at the + LNS. As with the PADS, the SESSION_ID in the PADT message is zero + until filled in with the proper SESSION_ID at the LAC. + + If the LAC receives a PADT from the PPPoE Host, the L2TP session MUST + be shut down via the standard procedures defined in [2]. The PADT + MUST be sent in the CDN message to the LNS via the PPPoE Relay AVP. + If the PPPoE system at the LNS disconnects the session, a PADT SHOULD + be sent in the CDN. In the event that the LAC receives a disconnect + from L2TP and did not receive a PADT, it MUST generate a properly + formatted PADT and send it to the PPPoE Host as described in [3]. + + Session Establishment + + PPPoE Host LAC Tunnel Switch LNS + + PADR -> + ICRQ (w/PADR) -> + ICRQ (w/PADR) -> + <- ICRP (w/PADS) + <- ICRP (w/PADS) + <- PADS + ICCN -> + ICCN -> + + Session Teardown (LNS Initiated) + + PPPoE Host LAC Tunnel Switch LNS + + <- CDN (w/PADT) + <- CDN (w/PADT) + <- PADT + + Session Teardown (Host Initiated) + + PPPoE Host LAC Tunnel Switch LNS + + PADT -> + CDN (w/PADT) -> + CDN (w/PADT) -> + + + +Townsley & da Silva Informational [Page 5] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + +2.3. PPPoE PAD Message Exchange Coherency + + PPPoE PAD messages will arrive from multiple ethernet interfaces and + be relayed across multiple L2TP control connections. In order to + track which PAD messages must be sent where, we utilize the Host-Uniq + TAG and AC-Cookie TAG. Each are used in the same manner, depending + on which PAD message is being sent or replied to. Both take + advantage of the fact that any PAD message sent as a reply to another + PAD message MUST echo these TAGs in their entirety [3]. + + For purposes of this discussion, it is useful to define two + "directions" which PAD messages will traverse during a relayed PPPoE + PAD message exchange. Thus, for the following example, + + "Upstream" -----------------------> + + PPPoE Host ------ LAC ----- Tunnel Switch ------ LNS + + <--------------------- "Downstream" + + PAD messages being sent from the PPPoE Host, through the LAC, Tunnel + Switch, and LNS, are defined to be traversing "Upstream." PAD + messages being sent in the opposite direction are defined to be + traversing "Downstream." + + Consider further, the following observation for this example: + + PAD messages that are sent Upstream: PADI, PADR, PADT + PAD messages that are sent Downstream: PADO, PADS, PADT + + Also, there is a request/response connection between the PADI and + PADO which must be linked with some common value. Similarly, there + is a request/response connection between PADO and PADR. The PADS is + sent on its own with no response, but must be delivered to the sender + of the PADR. The PADT must be sent with the same SESSION_ID as + established in the PADS. + + The goal for PAD message exchange coherency is to ensure that the + connections between the PADI/PADO, PADO/PADR, and PADR/PADS and + PADS/PADT all remain intact as the PAD messages are relayed from node + to node. + + The basic mechanism for ensuring this for PADI, PADO, and PADR + messages is the AC-Cookie TAG and Host-Uniq TAG. Both of these TAGs + are defined as arbitrary data which must be echoed in any message + sent as a response to another message. This is the key to tying + these PAD messages together at each hop. The following two rules + makes this possible: + + + +Townsley & da Silva Informational [Page 6] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + For PAD messages that are sent Upstream, a new Host-Uniq TAG MUST + be inserted at each relaying node before the PAD message is + forwarded. There SHOULD be at most one Host-Uniq TAG per PAD + message. + + For PAD messages being sent Downstream, a new AC-Cookie TAG MUST + be inserted at each relaying node before the PAD message is + forwarded. There SHOULD be at most one AC-Cookie TAG per PAD + message. Additionally, for an LNS receiving multiple PAD messages + from upstream, there SHOULD be at most one PAD message forwarded + downstream per received SRRP Message. In other words, there + SHOULD be exactly one PPPoE Relay AVP per L2TP SRRP Message. + + The exception here is the PADS, which cannot carry an AC-Cookie TAG + (and, thankfully, doesn't need to), and the PADT. We will discuss + these later in this section. Using the above rules, PADI, PADO, and + PADR messages may be relayed through an arbitrary number of nodes, + each inserting its own value to link a message response that it might + receive. + + In order to implement this exchange without tying up resources at + each L2TP node, it is desirable to not require ephemeral state at + each node waiting for a message response from each forwarded PAD + message. This is achievable if one is willing to be very intelligent + about the values that will be sent in the PPPoE TAGs used for message + coherency. Given that the TAGs are of arbitrary size and composition + and are always echoed in their entirety, one may use the information + here to map any next relay hop information. For example, the L2TP + Tunnel ID (Control Connection ID) could be encoded in the TAG in + order to identify where to relay the message when it arrives. If one + chooses this method, the encoding MUST incorporate some method of + encryption and authentication of the value. Note that this is a + relatively simple proposition given that it is only the source of the + encrypted and data that will ever need to decrypt and authenticate + the value upon receipt (thus, no key exchanges are necessary, and any + of a myriad of algorithms may be chosen). Note that individual TAGs + MUST never exceed 255 octets in length, and the length of an entire + PPPoE message MUST never exceed the maximum segment size of the + underlying ethernet. In the event that a TAG exceeds 255 octets in + length, a compression scheme which may include storage of state at an + L2TP node may be necessary before constructing a new TAG. + + The PADS and PADT messages do not rely on the AC-Cookie TAG or Host- + Uniq TAG for directing to the proper node. As described in Section + 2.2, the L2TP session is created upon receipt of a valid PADR at the + L2TP LAC. Since the PADS is sent as an AVP on this message exchange, + + + + + +Townsley & da Silva Informational [Page 7] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + its coherency may be secured via the L2TP session itself. Similarly + for the PADT, as it is carried in the L2TP disconnect message (CDN) + for the L2TP session. + + Clients are supposed to treat an AC-Cookie TAG as an opaque object. + They differentiate PADOs only by MAC address, Service-Name TAG(s) and + by AC-Name TAG(s). If an LAC sends multiple PADOs, they should + contain different AC-Name TAGs. + + Furthermore, a node performing PPPoE L2TP Relay (such as an LAC) + SHOULD attempt to distinguish or rate limit retransmitted PADx + messages (perhaps via the source MAC address and/or arriving + interface of the message) in order to limit the overloading of L2TP. + + Examples of this operation for a number of scenarios and + considerations for certain deployment situations may be found in the + Appendix of this document. + +2.4. PPPoE Service Relay Capabilities Negotiation + + If the extensions defined in this document are present and configured + for operation on a given Control Connection, the AVPs listed in this + section MUST be present in the Start-Control-Connection-Request + (SCCRQ) or Start-Control-Connection-Reply (SCCRP) messages during + control connection setup. + +2.4.1. PPPoE Service Relay Response Capability AVP + + The PPPoE Service Relay Response Capability AVP, Attribute Type 56, + indicates to an L2TP peer that the PPPoE Service Relay (SRRQ, SRRP) + messages and the PPPoE Relay AVP will be processed and responded to + when received. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H| rsvd | Length | Vendor ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Vendor ID is the IETF Vendor ID of 0. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). + + The M bit for this AVP may be set to 0 or 1. If the sender of this + AVP does not wish to establish a connection to a peer which does not + + + + +Townsley & da Silva Informational [Page 8] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + understand this L2TP extension, it SHOULD set the M bit to 1, + otherwise it MUST be set to 0. + + The Length of this AVP is 6. + + The AVP may be present in the following messages: SCCRQ, SCCRP + +2.4.2. PPPoE Service Relay Forward Capability AVP + + The PPPoE Service Relay Forward Capability AVP, Attribute Type 57, + indicates to an L2TP peer that PPPoE Service Relay (SRRQ, SRRP) + messages and the PPPoE Relay AVP may be sent by this L2TP peer. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H| rsvd | Length | Vendor ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Vendor ID is the IETF Vendor ID of 0. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). + + The M bit for this AVP may be set to 0 or 1. If the sender of this + AVP does not wish to establish a connection to a peer which does not + understand this L2TP extension, it SHOULD set the M bit to 1, + otherwise it MUST be set to 0. + + The Length of this AVP is 6. + + The AVP may be present in the following messages: SCCRQ, SCCRP + +3. L2TP Service Relay Messages + + This section identifies two new L2TP messages used to deliver PPPoE + PADI and PADO messages. + +3.1. Service Relay Request Message (SRRQ) + + The Service Relay Request Message (SRRQ), Message Type 18, is sent by + an LAC to relay requests for services. This document defines one new + AVP that may be present to request service in section 2. Further + service relay mechanisms may also use this message in a similar + context. Discussion of other service relay mechanisms are outside + the scope of this document. + + + + +Townsley & da Silva Informational [Page 9] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + +3.2. Service Relay Reply Message (SRRP) + + The Service Relay Reply Message (SRRP), Message Type 19, is sent by + an LAC to relay responses of requests for services. This document + defines one new AVP that may be present as a response to a request + for service in section 2. Further service relay mechanisms may also + use this message in a similar context. Discussion of other service + relay mechanisms are outside the scope of this document. + +4. PPPoE Relay AVP + + The PPPoE Relay AVP, Attribute Type 55, carries the entire PADI, + PADO, PADR, PADS and PADT messages within, including Ethernet MAC + source and destination addresses. This is the only AVP necessary for + relay of all PAD messages via L2TP. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|H| rsvd | Length | Vendor ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute Type | PPPoE PAD Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... (Until end of message is reached) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Vendor ID is the IETF Vendor ID of 0. + + This AVP MAY be hidden (the H bit MAY be 0 or 1). + + The M bit for this AVP may be set to 0 or 1. If the sender of this + AVP does not wish to establish a connection to a peer which does not + understand this L2TP extension, it SHOULD set the M bit to 1, + otherwise it MUST be set to 0. + + The Length of this AVP is 6 plus the length of the PPPoE PAD Message. + + The AVP may be present in the following messages: SRRQ, SRRP, ICRQ, + ICRP, ICCN, and CDN. + +5. Security Considerations + + PPPoE has a number of known security weaknesses that are not + described here. For example, an intruder between a PPPoE Host and a + PPPoE AC who can observe or modify PPPoE Active Discovery traffic has + numerous opportunities for denial of service and other attacks. The + use of the L2TP extensions described here makes it possible to tunnel + PPPoE discovery packets between the LAC and LNS, extending the path + + + +Townsley & da Silva Informational [Page 10] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + which the PPPoE Active Discovery packets are transported. There are + two possible implications of this. First, the tunneled packets may + now be observable by an intruder having access to traffic along the + L2TP tunnel path. This MAY make information regarding service + offerings or host identity easier to obtain to a rogue party given + that it is being sent over a wider variety of media, and presumably + over a longer distance and/or more hops or administrative domains. + Whether this information could be used for malicious purposes depends + on the information contained within, but it is conceivable that this + could be sensitive information, and this mechanism increases the + possibility that this information would be presented to an + interloper. Second, it may also be possible for an intruder to + modify PPPoE Active Discovery traffic while it is being carried + within L2TP control messages. + + There are at least two methods defined to help thwart this inspection + or modification by an unauthorized individual. One of the two MUST + be used if the service discovery information is considered to be + sensitive and is traversing an untrusted network. The first + suggested method is AVP hiding described in [2]. This may be used to + hide the contents of the packets in transit, though offers no + integrity protection against modification of data in the AVP. The + second and more secure method is protecting L2TP with IPsec as + defined in [6]. + +6. IANA Considerations + + This document requires three new "AVP Attribute" (attribute type) + numbers to be assigned through IETF Consensus [5] as indicated in + Section 10.1 of [2]. + + 1. PPPoE Relay AVP (section 4.0) + 2. PPPoE Relay Response Capability AVP (section 2.4.1) + 3. PPPoE Relay Forward Capability AVP (section 2.4.2) + + This document requires two new "Message Type" numbers to be assigned + through IETF Consensus [5] as indicated in Section 10.2 of [2]. + + 1. Service Relay Request Message (SRRQ) (Section 3.1) + 2. Service Relay Reply Message (SRRP) (Section 3.2) + + There are no additional requirements on IANA to manage numbers in + this document or assign any other numbers. + + + + + + + + +Townsley & da Silva Informational [Page 11] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + +7. Acknowledgements + + Thanks to Vinay Shankarkumar for valuable review, comment, and + implementation. + + Thanks to David Skoll and a number of others on pppoe@ipsec.org for + providing very helpful discussion about their PPPoE implementations. + + Thanks to Ross Wheeler, Louis Mamakos, and David Carrel for providing + valuable clarifications of PPPoE [1] while designing this protocol. + +8. References + +8.1. Normative References + + [1] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and R. + Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", + RFC 2516, February 1999. + + [2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. + Palter, "Layer Two Tunneling Protocol 'L2TP'", RFC 2661, August + 1999. + + [3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + +8.2. Informative References + + [6] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth, "Securing + L2TP Using IPsec," RFC 3193, November 2001. + + + + + + + + + + + + + + + +Townsley & da Silva Informational [Page 12] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + +Appendix A: PPPoE Relay in Point to Multipoint Environments + + The PPPoE PADI message in its native form, is sent as a broadcast + message on an Ethernet link. Thus, more than one AC concentrator + could conceivably receive and respond to this message. Similarly, a + + PPPoE interface could be associated with more than one L2TP Control + Connection, in order to query multiple LNSs with potentially varying + service profiles, as well as to load balance requests. + + As the PADI message is propagated, one may choose to replicate the + message to multiple Control Connections in order to mimic the + behavior of the PADI being sent on an ethernet link with multiple ACs + attached. If the number of replicated nodes is large, and the number + of hops deep, then an unmanageable "fan-out" of PADI propagation may + occur. Thus, care should be taken here to only replicate messages to + multiple Control Connections when it is absolutely necessary. + + The only case where it is seems necessary to replicate messages to + multiple destinations is in the case where each destination is known + to have varying service policies that all need to be advertised to a + PPPoE Host for its gathering and selection. At the time of this + writing, the authors know of no PPPoE Host implementations that take + advantage of this ability (instead, responding to only a single PPPoE + PADO). This, of course, is subject to change if and when PPPoE + implementations are advanced to this stage. + + In cases where multiple Control Connections may exist to multiple + LNSs for load balancing purposes, L2TP Service Relay should take + measures to try one Control Connection at a time, rather than + broadcasting to all Control Connections simultaneously. + +Appendix B: PAD Message Exchange Coherency Examples + + Example 1: "PPPoE Relay With Multiple LNSs" + + ,--- LNS1 + / + Host --- LAC + \ + `--- LNS2 + + This example assumes that there is good reason to send a copy of the + PADI to both LNSs (e.g., each LNS may have a different service + profile to offer). + + + + + + +Townsley & da Silva Informational [Page 13] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + 1) a. Host sends PADI via broadcast MAC address to LAC + + b. LAC replicates the PADI message and forwards a copy to LNS1 + Host-Uniq = R1 (assigned) + + c. LAC replicates the PADI message and forwards a copy to LNS2 + Host-Uniq = R2 (assigned) + + 2) a. LNS1 responds with PADO to LAC + Host-Uniq = R1 (echoed) + AC-Cookie = C1 (assigned) + + b. LNS1 responds with PADO to LAC + Host-Uniq = R2 (echoed) + AC-Cookie = C2 (assigned) + + c. LAC forwards both PADO messages to Host with source MAC set to + MAC address of LAC. PADO from (2a) is assigned new AC-Cookie + C1' and PADO from (2b) is given AC-Cookie C2' + + 3) a. Host sends PADR to MAC address of LAC (choosing one) + AC-Cookie = C1' (echoed) + + b. LAC knows to forward PADR to LNS1 based on C1' + AC-Cookie = C1 (echoed) + + 4) Session Establishment at the LAC commences, with further PAD + messages carried within the context of the L2TP session itself. + No need to inspect the AC-Cookie TAG or Host-Uniq TAG from this + point forward in order to direct messages properly. + + Example 2: "PPPoE Relay With L2TP Tunnel-Switching" + + Host --- LAC ---- LNS1 ---- LNS2 + + 1) a. Host sends PADI to LAC. + + b. LAC sends PADI to LNS1 + Host-Uniq = R1 (assigned) + + c. LNS1 sends PADI to LNS2 + Host-Uniq = R2 (assigned) + + 2) a. LNS2 responds to LNS1 with PADO + Host-Uniq = R2 (echoed) + AC-Cookie = C1 (assigned) + + + + + +Townsley & da Silva Informational [Page 14] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + b. LNS1 relays PADO to LAC + Host-Uniq = R1 (echoed) + AC-Cookie = C1' (assigned) + + c. LAC sends PADO to Host + AC-Cookie = C1'' (assigned) + + 3) a. Host sends PADR to MAC address of LAC + AC-Cookie = C1'' (echoed) + + b. LAC sends PADR to LNS1 + AC-Cookie = C1' (echoed) + + c. LNS1 sends PADR to LNS2 + AC-Cookie = C1 (echoed) + + 4) Session Establishment at the LAC, LNS1 and LNS2 commences, with + further PAD messages carried within the context of the L2TP + session itself. No need to inspect the AC-Cookie TAG or Host-Uniq + TAG from this point forward in order to direct messages properly. + + Example 3: "PPPoE Relay With Multiple PPPoE ACs" + + ,--- AC1 + / + Host --- LAC ---- LNS + \ + `--- AC2 + + In this example, AC1 and AC2 are PPPoE access concentrators on a + broadcast domain. Sequence of operation is as follows. + + 1) a. Host sends PADI to LAC. + + b. LAC sends PADI to LNS + Host-Uniq = R1 (assigned) + + c. LNS broadcasts PADI to AC1 and AC2 + Host-Uniq = R2 (assigned) + + 2) a. AC1 sends PADO to LNS + Host-Uniq = R2 (echoed) + AC-Cookie = C1 (assigned) + + b. AC2 sends PADO to LNS + Host-Uniq = R2 (echoed) + AC-Cookie = C2 (assigned) + + + + +Townsley & da Silva Informational [Page 15] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + + c. LNS sends two PADOs to LAC + Host-Uniq = R1 (echoed) + AC-Cookie (assigned) = C1' and C2', respectively + + d. LAC sends two PADOs to Host + Host-Uniq = R1 + AC-Cookie (assigned) = C1'' and C2'', respectively + + 3) a. Host sends PADR with to LAC to select service from AC2. + AC-Cookie = C2'' (echoed) + + b. LAC sends PADR to LNS AC-Cookie = C2' (echoed) + + c. LAC sends PADR to AC2 + AC-Cookie = C1 (echoed) + + 4) Session Establishment at the LAC, LNS and AC2 commences, with + further PAD messages carried within the context of the L2TP + session or PPPoE session itself. No need to inspect + the AC-Cookie TAG or Host-Uniq TAG from this point forward in + order to direct messages properly. + +Authors' Addresses + + W. Mark Townsley + cisco Systems + 7025 Kit Creek Road + Research Triangle Park, NC 27709 + + EMail: mark@townsley.net + + + Ron da Silva + AOL Time Warner + 12100 Sunrise Valley Dr + Reston, VA 20191 + + EMail: rdasilva@va.rr.com + + + + + + + + + + + + + +Townsley & da Silva Informational [Page 16] + +RFC 3817 L2TP Relay for PPPoE June 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Townsley & da Silva Informational [Page 17] + |