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).
著作権（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）は、ポイントツーポイントリンク上でマルチプロトコルデータグラムを輸送するための標準的な方法を提供します。レイヤ2トンネリングプロトコル（L2TP）は、介在パケット交換ネットワークを介したPPPパケットのトンネリングを容易にします。そして、さらに第3のプロトコルは、イーサネット上の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の）が規定されています。このリレーメカニズムは、L2TPでのPPPoEトンネリングプロトコルにおける特定の機能の統合が強化されています。
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
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] PPPを運ぶためのPPPoEホストが接続されたローカル・イーサネット・ネットワークの到達範囲を超えてネットワークを介して[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アクセスコンセントレータ（PPPoEのAC）によって提供されるサービス到達を発見するための簡単な方法を定義します。この交換で使用されるパケットは、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.
この文書は、PADメッセージを抽出し、L2TP制御チャネルを介してそれらを送信することによって、L2TP上のPPPoEアクティブディスカバリー（PAD）のメッセージを中継するための簡単な方法を説明します。 L2TPで定義されているPADメッセージの処理を経てセットアップが完了した後、PPPoEを介して到着PPPパケットは、次に、[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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のPADメッセージは、PPPoEアクセスコンセントレータで受信される場合、メッセージは、確立されたトンネル（セクション3.1）に新たに定義されたサービス中継要求メッセージ（SRRQ）を介してL2TP制御接続を介して渡されます。受信された場合、PPPoEのPADメッセージはL2TPノードで処理、または他のL2TPノードまたはPPPoEアクセスコンセントレータへ中継されます。返信として送信のPPPoE PADメッセージは、新たに定義されたサービスリレー応答メッセージ（SRRP）（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のアクティブ探索開始パケット（PADI）がPPPoEのサービスリレーを提供してL2TPのLACによって受信されると、PADIは、PPPoEのリレーAVP内（イーサネットMACヘッダを含む）、その全体がパッケージされ、確立されたL2TPコントロール接続を介して送信されなければなりませんPADIが到着したインターフェイスに関連付けられた（S）。
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はSRRQメッセージセクション3で定義されたサービス中継要求メッセージ（SRRQ）を介して送信される制御接続確立時のPPPoEサービスリレー応答能力AVPが含まれていなかったL2TPノードに送信してはいけません。受け入れ可能な制御接続が利用可能でないか、または作成することができない場合（これは意図的な行為でなければならないが、意図的にPPPoE PADメッセージを無視するなど）、PPPoEのパッド操作は、いくつかの手段によって局所的に処理されなければなりません。
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を受信すると、付属のPPPoE PADIメッセージが処理されなければならない[3]は、別の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にカプセル化されなければならないとSRRQの送信者にサービスリレー応答メッセージ（SRRP）を介して配信します。
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は、対応のPPPoEホストにカプセル化されたPADOメッセージを送らなければなりません。 PADOメッセージの送信元MACアドレスは、LACは、おそらく自身のMACアドレスの置換を必要とする、に反応する1でなければなりません。
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-クッキーTAGを使用しなければなりません。
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.
以下は、L2TPコントロール接続がすでに確立されたと仮定すると、この時点までのPPPoEホスト、LACとLNS間パッド交換の一例です。 AC-クッキーTAGとホストUNIQタグ動作を含む実施例は、付録に含まれています。
PPPoE Host LAC Tunnel Switch LNS
PPPoEのホストLACトンネルスイッチのLNS
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）を受信すると、[2]で定義されているように、LACは、着信呼要求（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サービス接続の場合で、L2TP着信-返信（ICRP）メッセージ（例えば、サービス名、エラータグは、PPPoEアクティブディスカバリーセッション確認パケット（PADS）応答に含まれません） PPPoEのリレーAVP内にカプセル化された結果のPPPoE PADSは、LACに含まれて送信されます。サービスが受け入れられない場合は、サービス名、エラータグ付きパッドもL2TPセッションを切断コール外し-通知（CDN）メッセージ内のリレーセッションAVPを介して配信されます。それが選択され、LACが記入されるように、PPPoEのリレーAVPでのPPPoE PADS SESSION_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からPADSを解析し、有効なのPPPoE SESSION_IDを挿入し、PADSでのPPPoEホストに応答します。 PADSのMACアドレスは、上述したPADI / PADO交換時に利用したものと同じでなければなりません。 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.
PPPoEセッションでのL2TPセッション。 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サブシステムによって開始され、正常なシャットダウンした場合には、このPADTは、CDNメッセージ内のPPPoEリレーAVPを経由してLNSから受信することができます。 LACでの適切なSESSION_IDで満たされるまで、PADSと同様に、PADTメッセージ内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を受信した場合、L2TPセッションは[2]で定義された標準的な手順を介してシャットダウンされなければなりません。 PADTは、PPPoEリレーAVPを介してLNSにCDNメッセージで送信されなければなりません。 LNSでのPPPoEシステムがセッションを切断すると、PADTは、CDNに送ってください。 LACは、L2TPから切断を受信し、PADTを受信しなかった場合に、それが適切にフォーマットされたPADTを生成しなければならない[3]に記載されているようにPPPoEホストに送信します。
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 ->
Session Teardown (LNS Initiated)
セッションのティアダウン（LNSが開始）
PPPoE Host LAC Tunnel Switch LNS
PPPoEのホストLACトンネルスイッチのLNS
<- 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) ->
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,
この議論の目的のためには、PADのメッセージが中継されたPPPoE PADのメッセージ交換中に横断する二つの「方向」を定義すると便利です。したがって、以下の例のために、
"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."
PPPoEのホストから送信され、PADメッセージは、LAC、トンネル・スイッチ、およびLNSを通じて、横断されるように定義されている「上流を。」 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の送信者に配信されなければなりません。 PADTはPADSに設立されたのと同じSESSION_IDで送信する必要があります。
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メッセージ交換コヒーレンシのための目標は、PADメッセージをノードからノードへ中継されるようにPADI / PADO、PADO / PADR、及びPADR /パッドとパッドの間の接続は/ PADTすべてが無傷のままであることを保証することです。
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-クッキータグとホストUNIQタグです。これらのタグの両方が別のメッセージへの応答として送信されるすべてのメッセージにエコーされなければならない任意のデータとして定義されます。これは、各ホップでこれらのPADのメッセージを一緒に結びつけるための鍵です。以下の2つのルールがこれを可能に：
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のTAGは、各中継ノードで挿入されなければなりません。 PADのメッセージあたり最大1つのホスト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-クッキーTAGは、各中継ノードで挿入されなければなりません。 PADのメッセージあたり最大1つのAC-Cookieのタグがあるはずです。また、上流側から複数PADメッセージを受信するLNSため、最大1つのPADメッセージで受信SRRPメッセージあたりの下流転送があるべきです。言い換えれば、L2TPのSRRPメッセージごとに1つの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.
ここでの例外は、AC-Cookieのタグを運ぶことができない（と、ありがたいことに、する必要はありません）PADS、および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メッセージからメッセージ応答を待っている各ノードで短命の状態を必要としないことが望ましいです。 1は、メッセージの一貫性のために使用されたPPPoEタグに送信されます値について非常に知的なことに喜んでいる場合、これは達成可能です。タグは任意のサイズおよび組成であると、常にそれらの全体にエコーされていることを考えると、1は任意の次の中継ホップ情報をマップするために、ここで情報を使用することができます。例えば、L2TPトンネルID（制御コネクションID）は、それが到着したときにメッセージを中継するために識別するためにタグに符号化することができました。一つは、この方法を選択した場合、符号化値の暗号化と認証のいくつかの方法を組み込まなければなりません。 （従って、いかなる鍵交換が必要でなく、アルゴリズムの無数のいずれかとすることができることがこれまで受けて値を復号化し、認証する必要があることを暗号化し、データの唯一のソースであることを考えれば、これは比較的単純な命題であることに注意してください選択しました）。個々のタグの長さが255個のオクテットを超えてはならないことに注意してください、そして全体のPPPoEメッセージの長さは、基礎となるイーサネットの最大セグメントサイズを超えてはなりません。 TAGは、長さが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, 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.
PADSとPADTメッセージは、適切なノードに導くためのAC-クッキータグまたはホストUNIQタグに依存しないでください。 2.2節で述べたように、L2TPセッションは、L2TP LACで有効PADRの受信時に作成されます。パッドは、このメッセージ交換にAVPとして送信されるので、そのコヒーレンシは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-クッキーTAGを扱うことになっています。彼らは唯一のMACアドレス、サービス名TAG（S）によっておよびAC-名札（S）でPADOsを区別します。 LACは複数のPADOsを送信する場合、それらは異なる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.
さらに、（例えば、LACなど）のPPPoE L2TP中継を行うノードは、L2TPの過負荷を制限するために、（おそらく元MACアドレス及び/又はメッセージの到着インタフェースを介して）再送PADxメッセージを区別するか、レート制限を試みます。
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属性タイプ、PPPoEのサービスリレー（SRRQ、SRRP）メッセージおよびPPPoEリレーAVPが処理され、受信されたときに応答する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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットは、そうでなければ、それがなければならず、このAVPの送信者はこのL2TP拡張子を理解していないピアへの接続を確立することを望まない場合、それは1にMビットをセットすべきである0または1に設定することができます0に設定します。
The Length of this AVP is 6.
このAVPの長さは6です。
The AVP may be present in the following messages: SCCRQ, SCCRP
SCCRQ、SCCRP：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.
PPPoEのサービス中継転送の能力AVP、57属性タイプ、PPPoEのサービスリレー（SRRQ、SRRP）メッセージおよびPPPoEリレーAVPこのL2TPピアによって送信されてもよい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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットは、そうでなければ、それがなければならず、このAVPの送信者はこのL2TP拡張子を理解していないピアへの接続を確立することを望まない場合、それは1にMビットをセットすべきである0または1に設定することができます0に設定します。
The Length of this AVP is 6.
このAVPの長さは6です。
The AVP may be present in the following messages: SCCRQ, SCCRP
SCCRQ、SCCRP：AVPは、以下のメッセージに存在してもよいです
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.
サービスリレー要求メッセージ（SRRQ）、メッセージタイプ18は、サービスの要求を中継するためにLACによって送られます。この文書はまた、同様の文脈では、このメッセージを使用してもよい部2またサービスリレー機構にサービスを要求するために存在することができる1つの新しいAVPを定義します。他のサービスリレーメカニズムの議論は、この文書の範囲外です。
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.
サービスリレー応答メッセージ（SRRP）、メッセージタイプ19は、サービス要求の応答を中継するLACによって送られます。この文書はまた、同様の文脈では、このメッセージを使用してもよい部2またサービスリレー機構内のサービス要求に対する応答として存在することができる1つの新しい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.
PPPoEのリレーAVPは、イーサネットMAC送信元アドレスと宛先アドレスを含む、内55、全体PADIを運び、PADO、PADR、PADSとPADTメッセージ属性タイプ。これは、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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットは、そうでなければ、それがなければならず、このAVPの送信者はこのL2TP拡張子を理解していないピアへの接続を確立することを望まない場合、それは1にMビットをセットすべきである0または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.
SRRQ、SRRP、ICRQ、ICRP、ICCN、及びCDN：AVPは以下のメッセージ中に存在してもよいです。
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 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はここで説明されていない既知のセキュリティ上の弱点がいくつかあります。例えば、PPPoEのアクティブディスカバリのトラフィックを監視または変更できるのPPPoEホストとPPPoEのAC間の侵入者は、サービスやその他の攻撃の拒否のために多くの機会を持っています。ここで説明したL2TP拡張子の使用は、PPPoEアクティブdiscoveryパケットが搬送される経路を延びる、LACとLNS間のトンネルのPPPoEディスカバリパケットすることができます。この2つの可能な意味合いがあります。まず、トンネルパケットは現在、L2TPトンネル経路に沿ったトラフィックへのアクセスを有する侵入者によって観察することができます。これは、メディアの幅広い種類以上の、そしておそらく長い距離および/または複数のホップまたは管理ドメインを介して送信されていることを考えると、不正なパーティに取得するサービスの提供やホストIDに関する情報を容易に行うことができます。この情報は、悪質な目的のために使用することができるかどうかに含まれる情報に依存するが、これは機密情報であり得ることは考えられるが、この機構は、この情報は、侵入者に提示されるであろうという可能性を増加させます。それは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つの方法があります。サービスディスカバリ情報は敏感であると考えられ、信頼できないネットワークを通過した場合の二つのうちの一つを使用しなければなりません。最初の提案された方法[2]に記載のAVP隠れています。これは、輸送中のパケットの内容を隠すために使用することができる、しかしAVPのデータの変更に対しては完全性保護を提供しています。 [6]で定義されるように、第2の、より安全な方法は、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].
この文書では、[2]のセクション10.1に示されているように[5] IETFコンセンサスを通して割り当てられるつの新しい「AVP属性」（属性タイプ）の番号を必要とします。
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].
[2]のセクション10.2に示されているように、この文書では、[5] IETFコンセンサスを通して割り当てされる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.
貴重なレビュー、コメント、および実装のためのビナイShankarkumarに感謝します。
Thanks to David Skoll and a number of others on pppoe@ipsec.org for providing very helpful discussion about their PPPoE implementations.
彼らのPPPoEの実装についての非常に有用な議論を提供するためのデビッド・スコールとpppoe@ipsec.org上の他人の数に感謝します。
Thanks to Ross Wheeler, Louis Mamakos, and David Carrel for providing valuable clarifications of PPPoE [1] while designing this protocol.
このプロトコルを設計しながら、[1]のPPPoEの貴重な明確化を提供するためのロス・ウィーラー、ルイMamakos、とDavidカレルに感謝します。
[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.、カレル、D.、シモン、D.およびR.ウィーラー、 "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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、G、BのPalter、 "レイヤ2トンネリングプロトコル 'L2TP'"、RFC 2661、1999年8月。
[3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[3]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]パテル、B.、Aboba、B.、ディクソン、W.、ゾルン、G.及びS.ブース、RFC 3193、2001年11月 "IPsecを使用してL2TPの保護"。
Appendix A: PPPoE Relay in Point to Multipoint Environments
環境をポイントツーマルチポイントでの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のインタフェースは、潜在的にサービスプロファイルを変えて複数のLNSを照会するため、ならびにバランス要求をロードするために、複数のL2TPコントロール接続に関連付けすることができます。
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メッセージが伝播されると、1は接続された複数の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 PADOへの対応）この機能を利用なしのPPPoEホストの実装を知っています。 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
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（例えば、各LNSが提供する異なるサービスプロファイルを有していてもよい）にPADIのコピーを送信するための十分な理由があることを前提としています。
1) a. Host sends PADI via broadcast MAC address to LAC
1）A。ホストは、LACにブロードキャストMACアドレスを経由して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はLACホスト-UNIQ = R1（エコー）AC-クッキー= C1（割り当て）にPADOで応答します
b. LNS1 responds with PADO to LAC Host-Uniq = R2 (echoed) AC-Cookie = C2 (assigned)
B。 LNS1はLACホスト-UNIQ = R2（エコー）AC-クッキー= C2（割り当て）にPADOで応答します
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は、LACのMACアドレスへの送信元MACセットのホストにPADOメッセージの両方を転送します。 （2A）からPADOは（2B）AC-クッキーC2与えられるからとPADOの新しいAC-クッキーC1' が割り当てられています
3) a. Host sends PADR to MAC address of LAC (choosing one) AC-Cookie = C1' (echoed)
3）A。ホストは、LACのMACアドレスにPADRを送信する（いずれかを選択）AC-クッキー= C1' （エコー）
b. LAC knows to forward PADR to LNS1 based on C1' AC-Cookie = C1 (echoed)
B。 LACは、C1' AC-クッキー= C1（エコー）に基づいて、LNS1にPADRを転送するために知っています
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-クッキータグまたはホストUNIQタグを検査する必要はありません。
Example 2: "PPPoE Relay With L2TP Tunnel-Switching"
例2：「L2TPトンネルスイッチングでPPPoEのリレー」
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はLNS1ホスト-UNIQ = R1にPADIを送信する（割り当て）
c. LNS1 sends PADI to LNS2 Host-Uniq = R2 (assigned)
C。 LNS1はLNS2ホストUNIQ = R2にPADIを送信する（割り当てます）
2) a. LNS2 responds to LNS1 with PADO Host-Uniq = R2 (echoed) AC-Cookie = C1 (assigned)
2）A。 LNS2はPADOホスト-UNIQ = R2（エコー）AC-クッキー= C1（割り当て）とLNS1に応答します
b. LNS1 relays PADO to LAC Host-Uniq = R1 (echoed) AC-Cookie = C1' (assigned)
B。 LNS1リレーPADO LACのホストUNIQ = R1（割り当てられた）（エコー）AC-クッキー= C1'
c. LAC sends PADO to Host AC-Cookie = C1'' (assigned)
C。 LACは、（割り当てられた） '' AC-クッキー= C1をホストするPADOを送信します
3) a. Host sends PADR to MAC address of LAC AC-Cookie = C1'' (echoed)
3）A。ホストはLAC AC-クッキー= C1 'のMACアドレスにPADRを送信'（エコー）
b. LAC sends PADR to LNS1 AC-Cookie = C1' (echoed)
B。 LACはLNS1 AC-クッキー= C1' にPADRを送信する（エコー）
c. LNS1 sends PADR to LNS2 AC-Cookie = C1 (echoed)
C。 LNS1はLNS2 AC-クッキー= C1（エコー）にPADRを送信します
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-クッキータグまたはホストUNIQタグを検査する必要はありません。
Example 3: "PPPoE Relay With Multiple PPPoE ACs"
例3： "複数のPPPoE ACSとPPPoEのリレー"
,--- 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はLNSホスト-UNIQ = R1にPADIを送信する（割り当て）
c. LNS broadcasts PADI to AC1 and AC2 Host-Uniq = R2 (assigned)
C。 AC1とAC2ホストUNIQ = R2にLNSブロードキャストのPADI（割り当て）
2) a. AC1 sends PADO to LNS Host-Uniq = R2 (echoed) AC-Cookie = C1 (assigned)
2）A。 AC1はLNSホストUNIQ = R2（エコー）AC-クッキー= C1（割り当て）にPADOを送信します
b. AC2 sends PADO to LNS Host-Uniq = R2 (echoed) AC-Cookie = C2 (assigned)
B。 AC2はLNSホストUNIQ = R2（エコー）AC-クッキー= C2（割り当て）にPADOを送信します
c. LNS sends two PADOs to LAC Host-Uniq = R1 (echoed) AC-Cookie (assigned) = C1' and C2', respectively
C。 LNSは、それぞれ、LACホストUNIQ = R1（エコー）AC-クッキー（割り当て）= C1' 及びC2' への2つのPADOsを送信します
d. LAC sends two PADOs to Host Host-Uniq = R1 AC-Cookie (assigned) = C1'' and C2'', respectively
D。 LACは、それぞれ、 'ホストUNIQ = R1 AC-クッキー（割り当て）= C1'及びC2' をホストするために2つのPADOsを送信します
3) a. Host sends PADR with to LAC to select service from AC2. AC-Cookie = C2'' (echoed)
3）A。ホストは、AC2からサービスを選択するために、LACにしてPADRを送信します。 AC-クッキー= C2 ''（エコー）
b. LAC sends PADR to LNS AC-Cookie = C2' (echoed)
B。 LACは、LNS AC-クッキー= C2' にPADRを送信する（エコー）
c. LAC sends PADR to AC2 AC-Cookie = C1 (echoed)
C。 LACはAC2 AC-クッキー= C1（エコー）にPADRを送信します
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-クッキータグまたはホストUNIQタグを検査する必要はありません。
Authors' Addresses
著者のアドレス
W. Mark Townsley cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709
W.マークTownsleyシスコシステムズ7025キットクリーク道路リサーチトライアングルパーク、NC 27709
EMail: mark@townsley.net
メールアドレス：mark@townsley.net
Ron da Silva AOL Time Warner 12100 Sunrise Valley Dr Reston, VA 20191
ロン・ダシルバAOLタイム・ワーナー12100日の出バレー博士レストン、バージニア州20191
EMail: rdasilva@va.rr.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。