doc: Add RFC documents

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]
+