Network Working Group W. Townsley
Request for Comments: 3817 cisco Systems
Category: Informational R. da Silva
AOL Time Warner
June 2004
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)
以太网PPP（PPPoE）的第2层隧道协议（L2TP）主动发现中继
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).
版权所有（C）互联网协会（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.
点到点协议（PPP）提供了通过点到点链路传输多协议数据报的标准方法。第二层隧道协议（L2TP）促进了PPP数据包在中间分组交换网络中的隧道传输。还有第三种协议，以太网PPP（PPPoE）描述了如何构建PPP会话和封装以太网PPP数据包。
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.
用于PPPoE的L2TP主动发现中继描述了一种通过L2TP内的可靠控制信道从PPPoE中继主动发现和服务选择功能的方法。定义了两种新的L2TP控制消息类型和L2TP的相关PPPoE特定属性值对（AVP）。这种中继机制增强了PPPoE隧道协议中特定功能与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
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
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
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
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.
PPPoE[1]通常与L2TP[2]一起部署，以便在PPPoE主机所连接的本地以太网范围之外的网络上承载PPP[3]帧。例如，在PPPoE中隧道传输的PPP帧可由L2TP接入集中器（LAC）接收，然后隧道传输到可通过IP网络到达的任何L2TP网络服务器（LNS）。
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.
除了通过以太网隧道PPP外，PPPoE还定义了一种简单的方法，用于发现PPPoE接入集中器（PPPoE AC）提供的服务，这些服务可通过以太网从PPPoE主机访问。由于此交换中使用的数据包不是通过PPP传输的，因此它们不是通过L2TP与PPP数据包进行隧道传输的，因此在不添加功能的情况下，发现协商无法扩展到LAC之外。
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.
本文档描述了一种通过L2TP中继PPPoE主动发现（PAD）消息的简单方法，方法是提取PAD消息并通过L2TP控制信道发送它们。在通过处理PAD消息完成设置后，通过PPPoE到达的PPP数据包将按照L2TP[2]中定义的通常方式通过L2TP进行隧道传输。因此，LAC或LNS不需要更改数据平面以支持此功能。此外，通过利用L2TP控制信道，PPPoE发现机制在创建任何L2TP会话之前可靠地传输到LNS，并且可以利用应用于控制传输中或接收时的消息的任何特殊处理。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释。
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).
当PPPoE接入集中器接收到PPPoE PAD消息时，这些消息通过已建立隧道上新定义的服务中继请求消息（SRRQ）通过L2TP控制连接传递（第3.1节）。接收时，PPPoE PAD消息在L2TP节点处处理，或中继到另一L2TP节点或PPPoE接入集中器。通过新定义的服务中继回复消息（SRRP）以类似方式处理作为回复发送的PPPoE PAD消息（第3.2节）。
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.
当提供PPPoE服务中继的L2TP LAC接收到PPPoE主动发现发起数据包（PADI）时，PADI必须在PPPoE中继AVP内整体打包（包括以太网MAC报头），并通过与PADI到达的接口相关联的已建立L2TP控制连接进行传输。
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).
PPPoE中继AVP通过第3节中定义的服务中继请求消息（SRRQ）发送。在控制连接建立期间，不得将SRRQ消息发送到不包括PPPoE服务中继响应能力AVP的L2TP节点。如果没有可接受的控制连接可用或无法创建，则必须通过某种方式在本地处理PPPoE PAD操作（包括故意忽略PPPoE PAD消息，但这必须是故意行为）。
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.
关于将为继电器建立哪些控制连接并与给定接口关联，以及何时建立控制连接，这是本地政策的问题。例如，实现可以“锁定”到特定L2TP目的地的控制连接，并将该连接与PPPoE PADI分组将到达的接口相关联。或者，实现可以在接收到PADI或从特定源接收到PADI时动态地建立到预定目的地的控制连接。
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.
收到SRRQ后，必须按照[3]中所述处理包含的PPPoE PADI消息，将其中继到另一个L2TP控制连接，或中继到另一个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.
处理PADI后，任何生成的PPPoE主动发现提供数据包（PADO）必须封装在PPPoE中继AVP中，并通过服务中继回复消息（SRRP）传递给SRRQ的发送方。
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.
收到带有中继PADO的SRRP消息后，LAC必须将封装的PADO消息发送至相应的PPPoE主机。PADO消息的源MAC地址必须是LAC将响应的MAC地址，可能需要替换其自己的MAC地址。
In each exchange above, the PPPoE Host-Uniq TAG or AC-Cookie TAG MUST be used as described in Section 2.3.
在上述每次交换中，必须按照第2.3节所述使用PPPoE主机Uniq标签或AC Cookie标签。
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主机、LAC和LNS之间的PAD交换示例，假设L2TP控制连接已经建立。附录中包括AC Cookie标记和主机Uniq标记操作的示例。
PPPoE Host LAC Tunnel Switch LNS
PPPoE主机LAC隧道交换机LNS
PADI ->
SRRQ (w/PADI) -> SRRQ (w/PADI) ->
<- SRRP (w/PADO) <- SRRP (w/PADO)
<- PADO
PADI ->
SRRQ (w/PADI) -> SRRQ (w/PADI) ->
<- SRRP (w/PADO) <- SRRP (w/PADO)
<- PADO
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.
当提供PPPoE服务中继功能的LAC收到有效的PPPoE主动发现请求包（PADR）时，LAC必须将其视为创建[2]中定义的传入呼叫请求（ICRQ）的操作。生成的ICRQ消息必须包含完整包含PADR的PPPoE中继AVP。
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.
收到L2TP ICRQ消息后，LNS按照[3]所述解析PADR消息。如果这是可接受的PPPoE服务连接（例如，服务名称错误标签不会包含在PPPoE主动发现会话确认包（PADS）响应中），则发送到LAC的L2TP呼入应答（ICRP）消息包括封装在PPPoE中继AVP中的结果PPPoE PADS。如果服务不可接受，带有服务名称错误标签的PAD将通过呼叫断开通知（CDN）消息中的中继会话AVP传送，这也会中断L2TP会话。PPPoE中继AVP中的PPPoE PADS会话ID必须始终为零，因为LAC将选择并填写该ID。
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
在收到带有PPPoE中继AVP的ICRP后，LAC从AVP解析PAD，插入有效的PPPoE会话ID，并用PAD响应PPPoE主机。焊盘的MAC地址必须与上述PADI/PADO交换期间使用的MAC地址相同。LAC还通过向LNS发送已连接的传入呼叫（ICCN）来完成L2TP会话建立，并绑定
L2TP session with the PPPoE session. PPP data packets may now flow between the PPPoE session and the L2TP session in the traditional manner.
L2TP会话与PPPoE会话。PPP数据包现在可以以传统方式在PPPoE会话和L2TP会话之间流动。
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.
如果L2TP会话因任何原因中断，LAC必须向主机发送PPPoE主动发现终止数据包（PADT），以指示连接已终止。如果这是由LNS处的PPPoE子系统启动的正常关机，则可通过CDN消息内的PPPoE中继AVP从LNS接收此PADT。与PADS一样，PADT消息中的SESSION_ID为零，直到在LAC用正确的SESSION_ID填充为止。
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].
如果LAC从PPPoE主机接收到PADT，则必须通过[2]中定义的标准程序关闭L2TP会话。PADT必须通过PPPoE中继AVP在CDN消息中发送到LNS。如果LNS处的PPPoE系统断开会话，则应在CDN中发送PADT。如果LAC收到与L2TP的断开连接，但未收到PADT，则必须生成格式正确的PADT，并将其发送至PPPoE主机，如[3]所述。
Session Establishment
会议设立
PPPoE Host LAC Tunnel Switch LNS
PPPoE主机LAC隧道交换机LNS
PADR ->
ICRQ (w/PADR) ->
ICRQ (w/PADR) ->
<- ICRP (w/PADS)
<- ICRP (w/PADS)
<- PADS
ICCN ->
ICCN ->
PADR ->
ICRQ (w/PADR) ->
ICRQ (w/PADR) ->
<- ICRP (w/PADS)
<- ICRP (w/PADS)
<- PADS
ICCN ->
ICCN ->
Session Teardown (LNS Initiated)
会话拆卸（LNS启动）
PPPoE Host LAC Tunnel Switch LNS
PPPoE主机LAC隧道交换机LNS
<- CDN (w/PADT)
<- CDN (w/PADT)
<- PADT
<- CDN (w/PADT)
<- CDN (w/PADT)
<- PADT
Session Teardown (Host Initiated)
会话拆卸（主机启动）
PPPoE Host LAC Tunnel Switch LNS
PPPoE主机LAC隧道交换机LNS
PADT ->
CDN (w/PADT) ->
CDN (w/PADT) ->
PADT ->
CDN (w/PADT) ->
CDN (w/PADT) ->
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].
PPPoE PAD消息将从多个以太网接口到达，并通过多个L2TP控制连接进行中继。为了跟踪哪些PAD消息必须发送到哪里，我们使用主机Uniq标记和AC Cookie标记。根据发送或回复的PAD消息的不同，每种消息的使用方式都相同。两者都利用了这样一个事实，即作为对另一条PAD消息的回复发送的任何PAD消息都必须完整地回显这些标记[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,
在本讨论中，有必要定义两个“方向”，在中继PPPoE PAD消息交换过程中，PAD消息将穿过这两个“方向”。因此，对于以下示例，
"Upstream" ----------------------->
"Upstream" ----------------------->
PPPoE Host ------ LAC ----- Tunnel Switch ------ LNS
PPPoE Host ------ LAC ----- Tunnel Switch ------ LNS
<--------------------- "Downstream"
<--------------------- "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."
从PPPoE主机通过LAC、隧道交换机和LNS发送的PAD消息被定义为“上游”。向相反方向发送的PAD消息被定义为“下游”
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
向上游发送的PAD消息：PADI、PADR、PADT向下游发送的PAD消息：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.
此外，PADI和PADO之间还有一个请求/响应连接，必须用一些公共值链接。类似地，PADO和PADR之间存在请求/响应连接。PADS单独发送，没有响应，但必须发送给PADR的发送方。必须使用PADS中建立的相同会话ID发送PADT。
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.
PAD消息交换一致性的目标是确保PADI/PADO、PADO/PADR、PADR/PADS和PADS/PADT之间的连接在PAD消息从节点中继到节点时保持完整。
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:
确保PADI、PADO和PADR消息的这一点的基本机制是AC Cookie标记和Host Uniq标记。这两个标记都被定义为任意数据，必须在作为对另一条消息的响应而发送的任何消息中回显。这是在每个跃点将这些PAD消息绑定在一起的关键。以下两条规则使这成为可能：
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.
对于向上游发送的PAD消息，在转发PAD消息之前，必须在每个中继节点插入新的主机Uniq标记。每个PAD消息最多应有一个主机Uniq标记。
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.
对于下行发送的PAD消息，在转发PAD消息之前，必须在每个中继节点插入新的AC Cookie标记。每个PAD消息最多应有一个AC Cookie标记。此外，对于从上游接收多条PAD消息的LNS，每个接收到的SRRP消息最多应有一条PAD消息向下游转发。换句话说，每个L2TP SRRP消息应该只有一个PPPoE中继AVP。
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.
这里的例外是PAD，它不能携带AC Cookie标签（谢天谢地，它不需要），还有PADT。我们将在本节后面讨论这些问题。使用上述规则，可以通过任意数量的节点中继PADI、PADO和PADR消息，每个节点插入自己的值以链接它可能接收的消息响应。
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.
为了在不占用每个L2TP节点上的资源的情况下实现该交换，希望在每个节点上不需要等待来自每个转发的PAD消息的消息响应的短暂状态。这是可以实现的，如果一个人愿意非常明智地了解将在用于消息一致性的PPPoE标签中发送的值。考虑到标签具有任意大小和组成，并且总是在其整体上回响，人们可以使用这里的信息来映射任何下一个中继跳信息。例如，L2TP隧道ID（控制连接ID）可以编码在标记中，以便识别消息到达时在何处中继。如果选择此方法，则编码必须包含某种加密和值验证方法。请注意，这是一个相对简单的命题，因为它只是需要在接收时解密和验证值的加密数据和数据的来源（因此，不需要密钥交换，并且可以选择各种算法中的任何一种）。请注意，单个标记的长度不得超过255个八位字节，并且整个PPPoE消息的长度不得超过底层以太网的最大段大小。在标签长度超过255个八位字节的情况下，在构造新标签之前，可能需要压缩方案，该压缩方案可能包括在L2TP节点处存储状态。
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,
PADS和PADT消息不依赖AC Cookie标记或主机Uniq标记来定向到正确的节点。如第2.2节所述，L2TP会话是在L2TP LAC收到有效PADR后创建的。由于PAD在此消息交换上作为AVP发送，
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.
它的一致性可以通过L2TP会话本身来保证。与PADT类似，因为它在L2TP会话的L2TP断开连接消息（CDN）中携带。
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.
客户端应该将AC Cookie标记视为不透明对象。它们仅通过MAC地址、服务名称标签和AC名称标签来区分PADO。如果LAC发送多个PADO，它们应该包含不同的AC名称标签。
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.
此外，执行PPPoE L2TP中继的节点（例如LAC）应尝试区分或限制重新传输的PADx消息（可能通过消息的源MAC地址和/或到达接口），以限制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.
本文件附录中提供了许多场景下的此操作示例以及某些部署情况下的注意事项。
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.
如果本文档中定义的扩展存在并配置为在给定控制连接上运行，则在控制连接设置期间，本节中列出的AVP必须出现在启动控制连接请求（SCCRQ）或启动控制连接回复（SCCRP）消息中。
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.
PPPoE服务中继响应能力AVP，属性类型56，向L2TP对等方指示PPPoE服务中继（SRRQ，SRRP）消息和PPPoE中继AVP将在接收时被处理和响应。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
供应商ID是0的IETF供应商ID。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
该AVP可能被隐藏（H位可能为0或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
此AVP的M位可设置为0或1。如果此AVP的发送方不希望建立与对等方的连接，则
understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0.
理解这个L2TP扩展，它应该将M位设置为1，否则必须设置为0。
The Length of this AVP is 6.
这个AVP的长度是6。
The AVP may be present in the following messages: SCCRQ, SCCRP
AVP可能出现在以下消息中：SCCRQ、SCCRP
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.
PPPoE服务中继转发能力AVP（属性类型57）向L2TP对等方指示该L2TP对等方可以发送PPPoE服务中继（SRRQ，SRRP）消息和PPPoE中继AVP。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
供应商ID是0的IETF供应商ID。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
该AVP可能被隐藏（H位可能为0或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.
此AVP的M位可设置为0或1。如果此AVP的发送方不希望与不理解此L2TP扩展的对等方建立连接，则应将M位设置为1，否则必须将其设置为0。
The Length of this AVP is 6.
这个AVP的长度是6。
The AVP may be present in the following messages: SCCRQ, SCCRP
AVP可能出现在以下消息中：SCCRQ、SCCRP
This section identifies two new L2TP messages used to deliver PPPoE PADI and PADO messages.
本节确定了用于传递PPPoE PADI和PADO消息的两条新L2TP消息。
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.
消息类型为18的服务中继请求消息（SRRQ）由LAC发送，以中继服务请求。本文件定义了一个新的AVP，可在第2节中提出服务请求。进一步的服务中继机制也可以在类似的上下文中使用该消息。对其他服务中继机制的讨论不在本文档的范围内。
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.
LAC发送消息类型为19的服务中继回复消息（SRRP），以中继服务请求的响应。本文件定义了一个新的AVP，作为对第2节中服务请求的响应。进一步的服务中继机制也可以在类似的上下文中使用该消息。对其他服务中继机制的讨论不在本文档的范围内。
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.
PPPoE中继AVP（属性类型55）承载整个PADI、PADO、PADR、PADS和PADT消息，包括以太网MAC源地址和目标地址。这是通过L2TP中继所有PAD消息所需的唯一AVP。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
供应商ID是0的IETF供应商ID。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
该AVP可能被隐藏（H位可能为0或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.
此AVP的M位可设置为0或1。如果此AVP的发送方不希望与不理解此L2TP扩展的对等方建立连接，则应将M位设置为1，否则必须将其设置为0。
The Length of this AVP is 6 plus the length of the PPPoE PAD Message.
此AVP的长度为6加上PPPoE PAD消息的长度。
The AVP may be present in the following messages: SRRQ, SRRP, ICRQ, ICRP, ICCN, and CDN.
AVP可能存在于以下消息中：SRRQ、SRRP、ICRQ、ICRP、ICCN和CDN。
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
PPPoE有许多已知的安全弱点，这里没有描述。例如，PPPoE主机和PPPoE AC之间的入侵者可以观察或修改PPPoE主动发现通信量，有许多机会进行拒绝服务和其他攻击。这里描述的L2TP扩展的使用使得能够在LAC和LN之间隧道PPPoE发现数据包，从而扩展路径
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.
传输PPPoE主动发现数据包的位置。这有两种可能的含义。首先，隧道包现在可以被能够访问L2TP隧道路径上的流量的入侵者观察到。这可能会使流氓方更容易获得有关服务产品或主机身份的信息，因为这些信息是通过更广泛的媒体发送的，并且可能是通过更长的距离和/或更多的跃点或管理域发送的。该信息是否可用于恶意目的取决于其中包含的信息，但可以想象，这可能是敏感信息，这种机制增加了向入侵者提供该信息的可能性。其次，入侵者也可能在L2TP控制消息中传输PPPoE主动发现流量时修改该流量。
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].
至少有两种方法可以帮助阻止未经授权的个人进行检查或修改。如果服务发现信息被认为是敏感信息并且正在穿越不受信任的网络，则必须使用这两种信息之一。第一种建议的方法是[2]中描述的AVP隐藏。这可用于隐藏传输中的分组的内容，但不提供针对AVP中的数据修改的完整性保护。第二种也是更安全的方法是使用[6]中定义的IPsec保护L2TP。
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].
本文件要求通过IETF共识[5]分配三个新的“AVP属性”（属性类型）编号，如[2]第10.1节所示。
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)
1. PPPoE中继AVP（第4.0节）2。PPPoE继电器响应能力AVP（第2.4.1节）3。PPPoE中继转发能力AVP（第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].
本文件要求通过IETF共识[5]分配两个新的“消息类型”编号，如[2]第10.2节所示。
1. Service Relay Request Message (SRRQ) (Section 3.1) 2. Service Relay Reply Message (SRRP) (Section 3.2)
1. 服务中继请求消息（SRRQ）（第3.1节）2。服务中继回复消息（SRRP）（第3.2节）
There are no additional requirements on IANA to manage numbers in this document or assign any other numbers.
IANA没有管理本文件中的编号或分配任何其他编号的额外要求。
Thanks to Vinay Shankarkumar for valuable review, comment, and implementation.
感谢Vinay Shankarkumar的宝贵审查、评论和实施。
Thanks to David Skoll and a number of others on pppoe@ipsec.org for providing very helpful discussion about their PPPoE implementations.
感谢David Skoll和其他一些pppoe@ipsec.org提供关于PPPoE实施的非常有用的讨论。
Thanks to Ross Wheeler, Louis Mamakos, and David Carrel for providing valuable clarifications of PPPoE [1] while designing this protocol.
感谢罗斯·惠勒（Ross Wheeler）、路易斯·马马科斯（Louis Mamakos）和大卫·卡雷尔（David Carrel）在设计本协议时对PPPoE[1]进行了有价值的澄清。
[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.
[1] Mamakos，L.，Lidl，K.，Evarts，J.，Carrel，D.，Simone，D.和R.Wheeler，“通过以太网传输PPP（PPPoE）的方法”，RFC 2516，1999年2月。
[2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol 'L2TP'", RFC 2661, August 1999.
[2] Townsley，W.，Valencia，A.，Rubens，A.，Pall，G.，Zorn，G.和B.Palter，“第二层隧道协议‘L2TP’”，RFC 26611999年8月。
[3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[3] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[6] Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth, "Securing L2TP Using IPsec," RFC 3193, November 2001.
[6] Patel，B.，Aboba，B.，Dixon，W.，Zorn，G.和S.Booth，“使用IPsec保护L2TP”，RFC 3193，2001年11月。
Appendix A: PPPoE Relay in Point to Multipoint Environments
附录A：点对多点环境中的PPPoE中继
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 PADI消息以其本机形式在以太网链路上作为广播消息发送。因此，可以想象，不止一个AC集中器可以接收并响应该消息。同样，一个
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.
PPPoE接口可以与多个L2TP控制连接相关联，以便查询具有可能变化的服务配置文件的多个LNS，以及负载平衡请求。
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.
随着PADI消息的传播，人们可以选择将消息复制到多个控制连接，以模拟在连接了多个ACs的以太网链路上发送的PADI的行为。如果复制节点的数量很大，且跳数很深，则可能会发生无法管理的PADI传播“扇出”。因此，此处应注意仅在绝对必要时将消息复制到多个控制连接。
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.
似乎有必要将消息复制到多个目的地的唯一情况是，已知每个目的地都有不同的服务策略，所有这些策略都需要发布到PPPoE主机以供收集和选择。在撰写本文时，作者知道没有利用这种能力的PPPoE主机实现（相反，只响应单个PPPoE PADO）。当然，如果PPPoE实施推进到这一阶段，这一点可能会发生变化。
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.
在多个LNS可能存在多个控制连接以实现负载平衡的情况下，L2TP服务中继应采取措施一次尝试一个控制连接，而不是同时向所有控制连接广播。
Appendix B: PAD Message Exchange Coherency Examples
附录B：PAD消息交换一致性示例
Example 1: "PPPoE Relay With Multiple LNSs"
示例1：“具有多个LNS的PPPoE中继”
,--- LNS1
/
Host --- LAC
\
`--- LNS2
,--- 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).
本例假设有充分的理由向两个LNS发送PADI副本（例如，每个LNS可能提供不同的服务配置文件）。
1) a. Host sends PADI via broadcast MAC address to LAC
1) A.主机通过广播MAC地址向LAC发送PADI
b. LAC replicates the PADI message and forwards a copy to LNS1 Host-Uniq = R1 (assigned)
b. LAC复制PADI消息并将副本转发给LNS1主机Uniq=R1（已分配）
c. LAC replicates the PADI message and forwards a copy to LNS2 Host-Uniq = R2 (assigned)
c. LAC复制PADI消息并将副本转发给LNS2主机Uniq=R2（已分配）
2) a. LNS1 responds with PADO to LAC Host-Uniq = R1 (echoed) AC-Cookie = C1 (assigned)
2) A.LNS1用PADO响应LAC主机Uniq=R1（回显）AC Cookie=C1（已分配）
b. LNS1 responds with PADO to LAC Host-Uniq = R2 (echoed) AC-Cookie = C2 (assigned)
b. LNS1用PADO响应LAC主机Uniq=R2（回显）AC Cookie=C2（已分配）
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'
c. LAC将两条PADO消息转发给主机，源MAC设置为LAC的MAC地址。来自（2a）的PADO被分配到新的AC Cookie C1′，来自（2b）的PADO被分配到AC Cookie C2′
3) a. Host sends PADR to MAC address of LAC (choosing one) AC-Cookie = C1' (echoed)
3) A.主机将PADR发送到LAC的MAC地址（选择一个）AC Cookie=C1'（回显）
b. LAC knows to forward PADR to LNS1 based on C1' AC-Cookie = C1 (echoed)
b. LAC知道根据C1'AC Cookie=C1（回声）将PADR转发至LNS1
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.
4) LAC的会话建立开始，在L2TP会话本身的上下文中携带更多的PAD消息。从这一点开始，无需检查AC Cookie标记或主机Uniq标记，以便正确引导消息。
Example 2: "PPPoE Relay With L2TP Tunnel-Switching"
示例2：“具有L2TP隧道切换的PPPoE继电器”
Host --- LAC ---- LNS1 ---- LNS2
Host --- LAC ---- LNS1 ---- LNS2
1) a. Host sends PADI to LAC.
1) A.主机向LAC发送PADI。
b. LAC sends PADI to LNS1 Host-Uniq = R1 (assigned)
b. LAC将PADI发送到LNS1主机Uniq=R1（已分配）
c. LNS1 sends PADI to LNS2 Host-Uniq = R2 (assigned)
c. LNS1将PADI发送到LNS2主机Uniq=R2（已分配）
2) a. LNS2 responds to LNS1 with PADO Host-Uniq = R2 (echoed) AC-Cookie = C1 (assigned)
2) A.LNS2使用PADO主机Uniq=R2（回显）AC Cookie=C1（已分配）响应LNS1
b. LNS1 relays PADO to LAC Host-Uniq = R1 (echoed) AC-Cookie = C1' (assigned)
b. LNS1将PADO中继至LAC主机Uniq=R1（回声）AC Cookie=C1'（已分配）
c. LAC sends PADO to Host AC-Cookie = C1'' (assigned)
c. LAC将PADO发送到主机AC Cookie=C1''（已分配）
3) a. Host sends PADR to MAC address of LAC AC-Cookie = C1'' (echoed)
3) A.主机将PADR发送到LAC AC Cookie=C1''的MAC地址（回显）
b. LAC sends PADR to LNS1 AC-Cookie = C1' (echoed)
b. LAC向LNS1发送PADR AC Cookie=C1'（回显）
c. LNS1 sends PADR to LNS2 AC-Cookie = C1 (echoed)
c. LNS1将PADR发送至LNS2 AC Cookie=C1（回声）
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.
4) 开始在LAC、LNS1和LNS2建立会话，在L2TP会话本身的上下文中携带更多PAD消息。从这一点开始，无需检查AC Cookie标记或主机Uniq标记，以便正确引导消息。
Example 3: "PPPoE Relay With Multiple PPPoE ACs"
示例3：“具有多个PPPoE ACs的PPPoE中继”
,--- AC1
/
Host --- LAC ---- LNS
\
`--- AC2
,--- 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.
在此示例中，AC1和AC2是广播域上的PPPoE接入集中器。操作顺序如下。
1) a. Host sends PADI to LAC.
1) A.主机向LAC发送PADI。
b. LAC sends PADI to LNS Host-Uniq = R1 (assigned)
b. LAC将PADI发送到LNS主机Uniq=R1（已分配）
c. LNS broadcasts PADI to AC1 and AC2 Host-Uniq = R2 (assigned)
c. LNS将PADI广播到AC1和AC2主机Uniq=R2（已分配）
2) a. AC1 sends PADO to LNS Host-Uniq = R2 (echoed) AC-Cookie = C1 (assigned)
2) A.AC1将PADO发送到LNS主机Uniq=R2（回显）AC Cookie=C1（已分配）
b. AC2 sends PADO to LNS Host-Uniq = R2 (echoed) AC-Cookie = C2 (assigned)
b. AC2将PADO发送到LNS主机Uniq=R2（回显）AC Cookie=C2（已分配）
c. LNS sends two PADOs to LAC Host-Uniq = R1 (echoed) AC-Cookie (assigned) = C1' and C2', respectively
c. LNS将两个PADO分别发送到LAC主机Uniq=R1（回显）AC Cookie（分配）=C1'和C2'
d. LAC sends two PADOs to Host Host-Uniq = R1 AC-Cookie (assigned) = C1'' and C2'', respectively
d. LAC分别向主机Uniq=R1 AC Cookie（已分配）=C1''和C2''发送两个PADO
3) a. Host sends PADR with to LAC to select service from AC2. AC-Cookie = C2'' (echoed)
3) A.主机向LAC发送PADR，以从AC2中选择服务。AC Cookie=C2''（回声）
b. LAC sends PADR to LNS AC-Cookie = C2' (echoed)
b. LAC向LNS发送PADR AC Cookie=C2'（回声）
c. LAC sends PADR to AC2 AC-Cookie = C1 (echoed)
c. LAC将PADR发送到AC2 AC Cookie=C1（回显）
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.
4) 开始在LAC、LNS和AC2建立会话，在L2TP会话或PPPoE会话本身的上下文中承载更多PAD消息。从这一点开始，无需检查AC Cookie标记或主机Uniq标记，以便正确引导消息。
Authors' Addresses
作者地址
W. Mark Townsley cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709
W.马克·汤斯利思科系统7025基特克里克路研究三角公园，北卡罗来纳州27709
EMail: mark@townsley.net
EMail: mark@townsley.net
Ron da Silva AOL Time Warner 12100 Sunrise Valley Dr Reston, VA 20191
罗恩·达席尔瓦美国在线时代华纳12100日出谷雷斯顿博士，弗吉尼亚州20191
EMail: rdasilva@va.rr.com
EMail: rdasilva@va.rr.com
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.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。