RFC3817 日本語訳
3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPPover Ethernet (PPPoE). W. Townsley, R. da Silva. June 2004. (Format: TXT=37765 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Townsley
Request for Comments: 3817 cisco Systems
Category: Informational R. da Silva
AOL Time Warner
June 2004
Townsleyがコメントのために要求するワーキンググループW.をネットワークでつないでください: 3817年のコクチマスSystems Category: 情報のR.ダシルバAOLタイム・ワーナー2004年6月
Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay
for PPP over Ethernet (PPPoE)
イーサネットの上でpppのためのプロトコルの(L2TP)活性発見リレーにトンネルを堀る層2(PPPoE)
Status of this Memo
この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).
Copyright(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.
Pointからポイントへのプロトコル(PPP)はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 Two Tunnelingプロトコル(L2TP)を層にして、介入しているパケット交換網の向こう側にPPPパケットのトンネリングを容易にします。 そして、しかし、3番目のプロトコル、イーサネット(PPPoE)の上のPPPはどのようにセッションを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 ActiveディスカバリーRelayはL2TPの中の高信頼の制御チャンネルの上にPPPoEからActiveディスカバリーとService Selectionの機能性をリレーする方法を説明します。 L2TPのための2つの新しいL2TPコントロールメッセージタイプと関連PPPoE特有のAttribute Valueペア(AVPs)が定義されます。 このリレーメカニズムは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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 操作. . . . . . . . . . . . . . . . . . . . . . 2 2.1について議定書の中で述べてください。 PPPoEのアクティブな発見ステージ. . . . . . . . . . . . . . 3 2.2。 セッション設立と分解. . . . . . . . . . . 4 2.3。 PPPoEは交換処理の一貫性. . . . . . . . . . 6 2.4を水増しします。 PPPoEはリレー能力交渉. . . . . . 8 2.4.1を修理します。 PPPoEはリレー応答能力AVPを調整します。 . . 8 2.4.2. PPPoEはリレーの前進の能力AVP. . . 9 3を調整します。 L2TPはリレーメッセージを修理します。 . . . . . . . . . . . . . . . . . 9
Townsley & da Silva Informational [Page 1] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[1ページ]RFC3817L2TP Relay
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. リレー要求メッセージ(SRRQ). . . . . . . . . . 9 3.2を修理してください。 リレー応答メッセージ(SRRP). . . . . . . . . . . 10 4を修理してください。 PPPoEはAVPをリレーします。 . . . . . . . . . . . . . . . . . . . . . . . 10 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 10 6. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 11 7. 承認. . . . . . . . . . . . . . . . . . . . . . . 12 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1。 引用規格. . . . . . . . . . . . . . . . . . 12 8.2。 有益な参照. . . . . . . . . . . . . . . . . 12付録A: PPPoEはポイントで多点に環境をリレーします。 . . . 13 付録B: 交換処理一貫性の例を水増ししてください。 . . . . . . . 13人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 16の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
1. 序論
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]は、PPPoE Hostが関連しているローカルのイーサネットネットワークの範囲を超えてPPP[3]フレームをネットワークの上まで運ぶためにしばしばL2TP[2]に関連して配備されます。 例えば、PPPoEの中でトンネルを堀られたPPPフレームは、L2TP Access Concentrator(LAC)によって受け取られて、次に、IPネットワークを通して届いているどんなL2TP Network Server(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 Hostからのイーサネットを通して届いているPPPoE Access Concentrators(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の上でPADメッセージを抜粋して、L2TP制御チャンネルの上にそれらを送ることによってPPPoE Activeディスカバリー(PAD)メッセージをリレーするための簡単な方法を説明します。 そして、PADメッセージの処理によるセットアップの完成の後に、PPPoEを通して到着するPPPパケットは常法でL2TP[2]で定義されるようにL2TPの上でトンネルを堀られます。 したがって、変化がLACかLNSでこの特徴を支持するのを必要としたデータ飛行機が全くありません。 また、L2TP制御チャンネルを利用することによって、PPPoE発見メカニズムは、どんなL2TPセッションの創造の前にもLNSに確かに輸送されて、トランジットか受領でコントロールメッセージに適用されたどんな特別な処理も利用するかもしれません。
2. Protocol Operation
2. プロトコル操作
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[4]で説明されるように本書では解釈されることであるべきですか?
Townsley & da Silva Informational [Page 2] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[2ページ]RFC3817L2TP Relay
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 Access ConcentratorにPPPoE PADメッセージを受け取るとき、メッセージは通り過ぎられて、L2TPが確立したトンネル(セクション3.1)の上の新たに定義されたService Relay Request Message(SRRQ)を通して接続を監督するということです。 受け取ると、PPPoE PADメッセージをL2TPノードで処理するか、または別のL2TPノードかPPPoE Access Concentratorにリレーします。 回答が同じように新たに定義されたService Relay Reply Message(SRRP)(セクション3.2)の上で扱われるので、PPPoE PADメッセージは発信しました。
2.1. PPPoE Active Discovery Stage
2.1. PPPoEのアクティブな発見ステージ
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 ActiveディスカバリーInitiationパケット(PADI)が受け取られているときには、PPPoE Service Relay、PADI MUSTを提供しているL2TP LACによってPPPoE Relay AVPの中で全体として(イーサネットMACヘッダーを含んでいる)パッケージされて、PADIが到着したインタフェースに関連している確立したL2TP Control Connection(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).
セクション3で定義されたService Relay Request Message(SRRQ)を通してPPPoE Relay AVPを送ります。 コントロールコネクション確立の間にPPPoE Service Relay Response Capability AVPを含んでいなかったL2TPノードにSRRQメッセージを送ってはいけません。 許容できるコントロール接続がないのを利用可能であるか、または創造できないなら、どうでも(これが慎重な行為であるに違いありませんが、故意に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.
接続がどのコントロールに関してリレーのために設立されて、与えられたインタフェースに関連づけられるだろうか、そして、Controlコネクションズがいつ確立されるかは、ローカルの方針の問題です。 例えば、実現は、特定のL2TPの目的地にコントロール接続を「釘でとどめ」て、PPPoE PADIパケットが到着するインタフェースに接続を関連づけるかもしれません。 あるいはまた、実現はPADIを受け取り次第特定のソースからのPADIを受け取り次第ダイナミックに予定された目的地にControl Connectionを設立するかもしれません。
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西暦にリレーしなければなりません。
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 ActiveディスカバリーOfferパケット(PADO)もSRRQの送付者にPPPoE Relay AVPでカプセルに入れって、Service Relay Reply Message(SRRP)を通して届けなければなりません。
Townsley & da Silva Informational [Page 3] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[3ページ]RFC3817L2TP Relay
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.
SRRPを受け取り次第、リレーされたPADOがあるメッセージ、LAC MUSTは要約のPADOメッセージを対応するPPPoE Hostに送ります。 PADOメッセージのソースMACアドレスはLACが応じるものであるに違いありません、恐らくそれ自身の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 Host-Uniq TAGまたは交流クッキーTAG MUSTで使用されてください。
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とLNSの間のPAD交換に関する例が以下にこの時点までにあります、L2TP Control Connectionが既に設立されたと仮定して。 交流クッキーTAGとHost-Uniq TAG操作を含んでいる例がAppendixに含まれています。
PPPoE Host LAC Tunnel Switch LNS
PPPoEホストラックトンネルスイッチLNS
PADI ->
SRRQ (w/PADI) -> SRRQ (w/PADI) ->
<- SRRP (w/PADO) <- SRRP (w/PADO)
<- PADO
PADI->SRRQ(PADIと)->SRRQ(PADIと)-><SRRP(PADOと)<SRRP(PADOと)<PADO
2.2. Session Establishment and Teardown
2.2. セッション設立と分解
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 Service Relayの特徴を提供しているLACが有効なPPPoE ActiveディスカバリーRequestパケット(PADR)を受けるとき、LAC MUSTは[2]で定義されるようにIncoming Call Request(ICRQ)の創造のための動作としてこれを扱います。 結果のICRQメッセージはPADRを全体として含むPPPoE Relay 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サービス連結部(例えば、Service名前誤りTAGはPPPoE ActiveディスカバリーSession-確認パケット(PADS)応答に含まれていない)であるなら、LACに送られるL2TP Incoming呼び出し回答(ICRP)メッセージはPPPoE Relay AVPの中で要約された結果のPPPoE PADSを含んでいます。 サービスが容認できないなら、Call分離に通知している(CDN)メッセージの中のRelay Session AVPを通してService名前誤りTagとPADSを届けます。また、メッセージはL2TPセッションを取りこわします。 それがLACによって選択されて、記入されるので、いつもPPPoE Relay 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 Relay AVPとICRPを受け取り次第、LACはAVPからPADSを分析して、有効なPPPoE SESSION_IDを挿入して、PADSとPPPoE Hostに応じます。 PADS MUSTのMACアドレスは1つのように同じくらいです。上で説明されたPADI/PADO交換の間、利用されています。 LACはまた、接続されたIncoming要求(ICCN)をLNSに送ることによってL2TPセッション設立を終了して、付きます。
Townsley & da Silva Informational [Page 4] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[4ページ]RFC3817L2TP Relay
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 MUSTは、接続が終えられたのを示すために、PPPoE ActiveディスカバリーTerminateパケット(PADT)をホストに送ります。 このPADT MAY、LNSから、これがLNSでPPPoEサブシステムで開始された優雅な閉鎖であったならCDNメッセージの中のPPPoE Relay AVPを通して受け取ってください。 PADSのように、適切なSESSION_IDがLACにある状態で記入されるまで、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 HostからPADTを受けるなら、[2]で定義された標準手続きでL2TPセッションを止めなければなりません。 PADT MUST、PPPoE Relay AVPを通してCDNメッセージでLNSに送ってください。 LNS分離セッション、a PADT SHOULDのPPPoEシステムであるなら、CDNで送ってください。 LACがL2TPから分離を受けて、PADTを受けなかったなら、それは、[3]で説明されるように適切にフォーマットされたPADTを発生させて、それをPPPoE Hostに送らなければなりません。
Session Establishment
セッション設立
PPPoE Host LAC Tunnel Switch LNS
PPPoEホストラックトンネルスイッチLNS
PADR ->
ICRQ (w/PADR) ->
ICRQ (w/PADR) ->
<- ICRP (w/PADS)
<- ICRP (w/PADS)
<- PADS
ICCN ->
ICCN ->
PADR->ICRQ(PADRと)->ICRQ(PADRと)-><ICRP(パッドがある)<ICRP(パッドがある)<はICCN->ICCN->を水増しします。
Session Teardown (LNS Initiated)
セッション分解(開始されたLNS)
PPPoE Host LAC Tunnel Switch LNS
PPPoEホストラックトンネルスイッチLNS
<- CDN (w/PADT)
<- CDN (w/PADT)
<- PADT
<CDN(PADTと)<CDN(PADTと)<PADT
Session Teardown (Host Initiated)
セッション分解(開始されたホスト)
PPPoE Host LAC Tunnel Switch LNS
PPPoEホストラックトンネルスイッチLNS
PADT ->
CDN (w/PADT) ->
CDN (w/PADT) ->
PADT->CDN(PADTと)->CDN(PADTと)->。
Townsley & da Silva Informational [Page 5] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[5ページ]RFC3817L2TP Relay
2.3. PPPoE PAD Message Exchange Coherency
2.3. PPPoEパッド交換処理の一貫性
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メッセージにどこを送らなければならないかを追跡するために、私たちはHost-Uniq TAGと交流クッキーTAGを利用します。 どのPADメッセージについて送るか、または答えているかによって、それぞれが同じ方法で使用されます。 両方が別のPADメッセージに関する回答がこれらのTAGsを全体として反響しなければならないのでどんな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交換処理の間に横断する2「指示」を定義するのは役に立ちます。 このようにして、以下の例のために
"Upstream" ----------------------->
「上流へ」----------------------->。
PPPoE Host ------ LAC ----- Tunnel Switch ------ LNS
PPPoEホスト------ ラック----- トンネルスイッチ------ 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 HostからLACまで送られるPADメッセージ(Tunnel Switch、および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
Upstreamが送られるPADメッセージ: PADI、PADR、Downstreamが送られるPADT PADメッセージ: PADO、パッド、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に設置されるのと同じSESSION_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交換処理の一貫性の目標はPADメッセージがノードからノードまでリレーされるときPADI/PADOと、PADO/PADRと、PADR/PADSとPADS/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メッセージのためにこれを確実にするための基本的機構は、交流クッキーのTAGとHost-Uniq TAGです。 これらのTAGsの両方が別のメッセージへの応答として送られたどんなメッセージでも反映しなければならない任意のデータと定義されます。 これは各ホップでこれらのPADメッセージを結びつけるキーです。 以下の2つの規則で、これは可能になります:
Townsley & da Silva Informational [Page 6] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[6ページ]RFC3817L2TP Relay
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.
Upstreamが送られるPADメッセージに関しては、PADメッセージを転送する前にノードをリレーして、それぞれで新しいHost-Uniq TAGを挿入しなければなりません。 SHOULDは高々そこでは、そうです。PADメッセージあたり1Host-Uniq TAG。
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.
Downstream、新しい交流クッキーTAG MUSTが送られるPADメッセージに関しては、PADメッセージを転送する前にノードをリレーしながら、それぞれで挿入されてください。 SHOULDは高々そこでは、そうです。PADメッセージあたり1交流クッキーTAG。 さらに、LNSに関して、複数のPADを受けると、上流と、そこから、SHOULDは高々あるPADが容認されたSRRP Message単位で川下に転送されたメッセージであったなら通信します。 SHOULDはまさに言い換えれば、そして、そこでは、そうです。1L2TP SRRP Messageあたり1PPPoE Relay 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.
ここの例外は、PADSとPADTです。(PADSは交流クッキーTAG(そして、感謝してそうする必要はない)を運ぶことができません)。 私たちはこのセクションで後であることの状態でこれらについて議論するつもりです。 上の規則を使用する、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 TAGsで送られる値に関して非常に知的であっても構わないと思っているなら、これは達成可能です。 TAGsが任意のサイズと構成があって、全体としていつも反響されるなら、どんな次のリレーホップ情報も写像するのにここで情報を使用するかもしれません。 例えば、到着するとき、どこでメッセージをリレーするかを特定するために、TAGでL2TP Tunnel ID(コントロールConnection ID)をコード化できました。 人がこの方法を選ぶなら、コード化は暗号化の何らかの方法と価値の認証を取り入れなければなりません。 これが唯一のそれが領収書の値を解読して、認証する必要があるコード化とデータの源(その結果、どんな主要な交換も必要ではありません、そして、アルゴリズムの無数のどれかは選ばれるかもしれない)であるなら比較的簡単な提案であることに注意してください。 個々のTAGsが長さにおける255の八重奏を決して超えてはいけなくて、全体のPPPoEメッセージの長さが基本的なイーサネットの最大のセグメントサイズを決して超えてはいけないことに注意してください。 TAGが長さにおける255の八重奏を超えている場合、新しいTAGを組み立てる前に、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メッセージは適切なノードへの向けるために交流クッキーのTAGかHost- Uniq TAGを当てにしません。 セクション2.2で説明されるように、L2TPセッションはL2TP LACの有効なPADRを受け取り次第作成されます。 以来、AVPとしてこの交換処理でPADSを送ります。
Townsley & da Silva Informational [Page 7] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[7ページ]RFC3817L2TP Relay
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.
クライアントは交流クッキーTAGを不明瞭な物として扱うべきです。 彼らは単にMACアドレス、Service-名前TAG(s)、および交流名のTAG(s)でPADOsを微分します。 LACが複数のPADOsを送るなら、彼らは異なった交流名の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.
その上、区別するノード実行PPPoE L2TP Relay(LACなどの)SHOULD試みかレート限界が、L2TPの積みすぎを制限するために、PADxメッセージ(恐らくメッセージのソースMACアドレス、そして/または、到着インタフェースを通した)を再送しました。
Examples of this operation for a number of scenarios and considerations for certain deployment situations may be found in the Appendix of this document.
多くのシナリオのためのこの操作とある展開状況のための問題に関する例はこのドキュメントのAppendixで見つけられるかもしれません。
2.4. PPPoE Service Relay Capabilities Negotiation
2.4. PPPoEサービスリレー能力交渉
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.
本書では定義された拡大が現在であって操作のために与えられたControl Connectionで構成されているなら、このセクションで記載されたAVPsはコントロール接続設定の間、Startコントロール接続要求(SCCRQ)かStartコントロール接続回答(SCCRP)メッセージに存在していなければなりません。
2.4.1. PPPoE Service Relay Response Capability AVP
2.4.1. PPPoEサービスリレー応答能力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.
PPPoE Service Relay Response Capability AVP(Attribute Type56)はPPPoE Service Relay(SRRQ、SRRP)メッセージとPPPoE Relay 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| 業者ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
Vendor IDは0のIETF Vendor IDです。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
このAVP MAY、隠されてください(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の送付者がそうしない同輩に取引関係を築きたくないなら
Townsley & da Silva Informational [Page 8] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[8ページ]RFC3817L2TP Relay
understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0.
SHOULDは1まで噛み付かれたMを設定します。このL2TP拡張子を理解してください、それ、さもなければ、0にそれを設定しなければなりません。
The Length of this AVP is 6.
このAVPのLengthは6歳です。
The AVP may be present in the following messages: SCCRQ, SCCRP
AVPは以下のメッセージに存在しているかもしれません: SCCRQ、SCCRP
2.4.2. PPPoE Service Relay Forward Capability AVP
2.4.2. PPPoEのサービスのリレーの前進の能力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 Service Relay Forward Capability AVP(Attribute Type57)は、PPPoE Service Relay(SRRQ、SRRP)メッセージとPPPoE Relay 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| 業者ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
Vendor IDは0のIETF Vendor IDです。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
このAVP MAY、隠されてください(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拡張子を理解していない同輩に取引関係を築きたがっていません、それ。SHOULDは1まで噛み付かれたMを設定します。さもなければ、0にそれを設定しなければなりません。
The Length of this AVP is 6.
このAVPのLengthは6歳です。
The AVP may be present in the following messages: SCCRQ, SCCRP
AVPは以下のメッセージに存在しているかもしれません: SCCRQ、SCCRP
3. L2TP Service Relay Messages
3. L2TPサービスリレーメッセージ
This section identifies two new L2TP messages used to deliver PPPoE PADI and PADO messages.
このセクションはPPPoE PADIとPADOにメッセージを渡すのに使用される2つの新しいL2TPメッセージを特定します。
3.1. Service Relay Request Message (SRRQ)
3.1. サービスリレー要求メッセージ(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.
Service Relay Request Message(SRRQ)(Message Type18)は、サービスを求める要求をリレーするためにLACによって送られます。 このドキュメントは1セクション2でサービスを要求するために存在するかもしれない新しいAVPを定義します。 また、さらなるサービスリレーメカニズムは同様の文脈でこのメッセージを使用するかもしれません。 このドキュメントの範囲の外に他のサービスリレーメカニズムの議論があります。
Townsley & da Silva Informational [Page 9] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[9ページ]RFC3817L2TP Relay
3.2. Service Relay Reply Message (SRRP)
3.2. サービスリレー応答メッセージ(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.
Service Relay Reply Message(SRRP)(Message Type19)は、サービスを求める要求の応答をリレーするためにLACによって送られます。 このドキュメントは1サービスを求める要求への応答としてセクション2に存在するかもしれない新しいAVPを定義します。 また、さらなるサービスリレーメカニズムは同様の文脈でこのメッセージを使用するかもしれません。 このドキュメントの範囲の外に他のサービスリレーメカニズムの議論があります。
4. PPPoE Relay AVP
4. PPPoEリレー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 Relay AVP(Attribute Type55)は全体の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| 長さ| 業者ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ| PPPoEはメッセージを水増しします… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (メッセージの端に達するまで) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
Vendor IDは0のIETF Vendor IDです。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
このAVP MAY、隠されてください(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拡張子を理解していない同輩に取引関係を築きたがっていません、それ。SHOULDは1まで噛み付かれたMを設定します。さもなければ、0にそれを設定しなければなりません。
The Length of this AVP is 6 plus the length of the PPPoE PAD Message.
このAVPのLengthはPPPoE PAD Messageの6と長さです。
The AVP may be present in the following messages: SRRQ, SRRP, ICRQ, ICRP, ICCN, and CDN.
AVPは以下のメッセージに存在しているかもしれません: SRRQ、SRRP、ICRQ、ICRP、ICCN、およびCDN。
5. Security Considerations
5. セキュリティ問題
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 HostとPPPoE西暦の間のPPPoE Activeディスカバリー交通を観測するか、または変更できる侵入者はサービスと他の攻撃の否定の多数の機会を持っています。 ここで説明されたL2TP拡張子の使用でLACとLNSの間でトンネルPPPoE発見パケットに可能になります、経路を広げていて
Townsley & da Silva Informational [Page 10] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[10ページ]RFC3817L2TP Relay
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 Activeディスカバリーパケットは輸送されるか。 この2つの関与の可能性があります。 まず最初に、トンネルを堀られたパケットはL2TPトンネル経路に沿って交通に近づく手段を持っている侵入者が現在、観察可能であるかもしれません。 これは、それが、より広いバラエティーのメディアの上と、そして、おそらくより長い距離、そして/または、、より多くのホップの上に送るか、管理ドメインであるならサービス提供かホストのアイデンティティの情報を凶暴なパーティーに得るのをより簡単にするかもしれません。 悪意の目的にこの情報を使用できたかどうかが情報に中に含まれた状態でよりますが、これが機密情報であるかもしれなく、このメカニズムがこの情報が侵入者に提示されるだろう可能性を増加させるのが想像できます。 また、2番目に、侵入者がそれがL2TPコントロールメッセージの中で運ばれる間のPPPoE Activeディスカバリー交通を変更するのも、可能であるかもしれません。
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つのものの1つを使用しなければなりません。 1番目は、方法が[2]で説明されたAVP隠れることであると示唆しました。 これはトランジットにパケットのコンテンツを隠すのに使用されるかもしれません、申し出ですが。AVPでのデータの変更に対する保全保護がありません。 2番目の、そして、より安全な方法はIPsecと共に[6]で定義されるようにL2TPを保護することです。
6. IANA Considerations
6. IANA問題
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].
このドキュメントは、3の新しい「AVP属性」(属性タイプ)番号が[2]のセクション10.1にみられるようにIETF Consensus[5]を通して割り当てられるのを必要とします。
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つの新しい「メッセージタイプ」番号が[2]のセクション10.2にみられるようにIETF Consensus[5]を通して割り当てられるのを必要とします。
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に関するどんな追加要件もありません。
Townsley & da Silva Informational [Page 11] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[11ページ]RFC3817L2TP Relay
7. Acknowledgements
7. 承認
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@ipsec.org で彼らのPPPoE実現についての非常に役立っている議論をデヴィッドSkollと多くの他のものに提供してくださってありがとうございます。
Thanks to Ross Wheeler, Louis Mamakos, and David Carrel for providing valuable clarifications of PPPoE [1] while designing this protocol.
[1] このプロトコルを設計している間、ロス・ウィーラー、ルイスMamakos、およびデヴィッドCarrelにPPPoEの貴重な明確化を提供してくださってありがとうございます。
8. References
8. 参照
8.1. Normative References
8.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.とエバーツとJ.と個人閲覧室とD.とシモンとD.とR.ウィーラー、「イーサネット(PPPoE)の上にpppを伝えるための方法」、RFC2516、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.はあしらわれます、「層Twoはプロトコル'L2TP'にトンネルを堀っ」て、RFC2661、1999年8月。
[3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[3] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
8.2. Informative References
8.2. 有益な参照
[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.ブース、「IPsecを使用することでL2TPを固定します」、RFC3193、2001年11月。
Townsley & da Silva Informational [Page 12] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[12ページ]RFC3817L2TP Relay
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メッセージは形成して、同報メッセージとしてイーサネットリンクに送ります。 したがって、1個以上の交流集中装置が、多分受信して、このメッセージに反応できました。 同様である、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.
PPPoEインタフェースを1L2TP Control Connectionに関連づけることができました、潜在的にサービスプロフィールを変えるのに複数のLNSsについて質問するために、よく負荷バランス要求のように。
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の動きをまねるために複数のControlコネクションズにメッセージを模写するのを選ぶかもしれません。 模写されたノードの数が大きく、ホップの数が深いなら、PADI伝播の「非-処理しやす」「四方八方に広がってください」は起こるかもしれません。 したがって、それが絶対に必要であるときにだけ、複数のControlコネクションズにメッセージを模写するためにここに注意するべきです。
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 Hostに広告を出す必要がある異なったサービス方策をすべて、持っているのが知られているところにあるのが必要に見えます。 この書くこと時点で、作者はこの能力(代わりに独身のPPPoE PADOだけへの応じる)を利用するPPPoE Host実現を全く知りません。 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.
複数のControlコネクションズがロードバランシング目的のための複数のLNSsに存在するかもしれない場合では、L2TP Service Relayは同時にすべてのControlコネクションズに放送するより一度に1Control Connectionに試みる対策をむしろ実施するはずです。
Appendix B: PAD Message Exchange Coherency Examples
付録B: パッド交換処理一貫性の例
Example 1: "PPPoE Relay With Multiple LNSs"
例1: 「複数のLNSsとのPPPoEリレー」
,--- LNS1
/
Host --- LAC
\
`--- LNS2
,--- LNS1/ホスト--- ラック'\‘--- 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).
この例は、PADIのコピーを両方のLNSsに送るためにもっともな理由があると仮定します(例えば各LNSは提供する異なったサービスプロフィールを持っているかもしれません)。
Townsley & da Silva Informational [Page 13] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[13ページ]RFC3817L2TP Relay
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 Host-Uniq=R1にコピーを送ります。(割り当てられます)
c. LAC replicates the PADI message and forwards a copy to LNS2
Host-Uniq = R2 (assigned)
c。 LACはPADIメッセージを模写して、LNS2 Host-Uniq=R2にコピーを送ります。(割り当てられます)
2) a. LNS1 responds with PADO to LAC
Host-Uniq = R1 (echoed)
AC-Cookie = C1 (assigned)
2) a。 LNS1はPADOと共にLAC Host-Uniq=R1(反響される)に応じます。 交流クッキー=C1(割り当てられます)
b. LNS1 responds with PADO to LAC
Host-Uniq = R2 (echoed)
AC-Cookie = C2 (assigned)
b。 LNS1はPADOと共にLAC Host-Uniq=R2(反響される)交流クッキー=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はソースMACとHostへのPADOメッセージがLACのMACアドレスに設定する両方を進めます。 'PADO、(新しい交流クッキーC1は2a)に割り当てられます、そして、'(2b)からのPADOに交流クッキーC2を与えます'。
3) a. Host sends PADR to MAC address of LAC (choosing one)
AC-Cookie = C1' (echoed)
3) a。 ホストはLACのMACアドレスにPADRを送ります(1つを選んで)。 '交流クッキー=C1'(反響されます)
b. LAC knows to forward PADR to LNS1 based on C1'
AC-Cookie = C1 (echoed)
b。 'LACは、C1に基づくLNS1にPADRを送るのを知っている'交流クッキーはC1と等しいです。(反響されます)
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) さらなるPADメッセージがL2TPセッション自体の文脈の中で伝えられている状態で、LACのセッション特権階級は始まります。 適切にメッセージを指示するためにこのポイントフォワードから交流クッキーのTAGかHost-Uniq TAGを点検する必要性がありません。
Example 2: "PPPoE Relay With L2TP Tunnel-Switching"
例2: 「L2TPトンネル切り換えとのPPPoEリレー」
Host --- LAC ---- LNS1 ---- LNS2
ホスト--- ラック---- LNS1---- LNS2
1) a. Host sends PADI to LAC.
1) a。 ホストはPADIをLACに送ります。
b. LAC sends PADI to LNS1
Host-Uniq = R1 (assigned)
b。 LACはLNS1 Host-Uniq=R1にPADIを送ります。(割り当てられます)
c. LNS1 sends PADI to LNS2
Host-Uniq = R2 (assigned)
c。 LNS1はLNS2 Host-Uniq=R2にPADIを送ります。(割り当てられます)
2) a. LNS2 responds to LNS1 with PADO
Host-Uniq = R2 (echoed)
AC-Cookie = C1 (assigned)
2) a。 LNS2はPADO Host-Uniq=R2(反響される)と共にLNS1に応じます。 交流クッキー=C1(割り当てられます)
Townsley & da Silva Informational [Page 14] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[14ページ]RFC3817L2TP Relay
b. LNS1 relays PADO to LAC
Host-Uniq = R1 (echoed)
AC-Cookie = C1' (assigned)
b。 'LNS1はLAC Host-Uniq=R1(反響される)交流クッキー=C1にPADOをリレーします'(割り当てられます)
c. LAC sends PADO to Host
AC-Cookie = C1'' (assigned)
c。 LACはHost交流クッキー=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の特権階級が始まるセッション、一層のPADと共に、メッセージはL2TPセッション自体の文脈の中で運ばれました。 適切にメッセージを指示するためにこのポイントフォワードから交流クッキーのTAGかHost-Uniq TAGを点検する必要性がありません。
Example 3: "PPPoE Relay With Multiple PPPoE ACs"
例3: 「複数のPPPoE ACsとのPPPoEリレー」
,--- AC1
/
Host --- LAC ---- LNS
\
`--- AC2
,--- AC1/ホスト--- ラック---- 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。 ホストはPADIをLACに送ります。
b. LAC sends PADI to LNS
Host-Uniq = R1 (assigned)
b。 LACはLNS Host-Uniq=R1にPADIを送ります。(割り当てられます)
c. LNS broadcasts PADI to AC1 and AC2
Host-Uniq = R2 (assigned)
c。 LNS放送のAC1へのPADIとAC2 Host-UniqはR2と等しいです。(割り当てられます)
2) a. AC1 sends PADO to LNS
Host-Uniq = R2 (echoed)
AC-Cookie = C1 (assigned)
2) a。 AC1はLNS Host-Uniq=R2(反響される)にPADOを送ります。 交流クッキー=C1(割り当てられます)
b. AC2 sends PADO to LNS
Host-Uniq = R2 (echoed)
AC-Cookie = C2 (assigned)
b。 AC2はLNS Host-Uniq=R2(反響される)交流クッキー=C2にPADOを送ります。(割り当てられます)
Townsley & da Silva Informational [Page 15] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[15ページ]RFC3817L2TP Relay
c. LNS sends two PADOs to LAC
Host-Uniq = R1 (echoed)
AC-Cookie (assigned) = C1' and C2', respectively
c。 'LNSはそれぞれLAC Host-Uniq=R1(反響される)交流クッキー(割り当てられる)=C1と'C2'に2PADOsを送ります。
d. LAC sends two PADOs to Host
Host-Uniq = R1
AC-Cookie (assigned) = C1'' and C2'', respectively
d。 LACはそれぞれHost Host-Uniq=R1 AC-クッキー(割り当てられる)=C1"とC2"に2PADOsを送ります。
3) a. Host sends PADR with to LAC to select service from AC2.
AC-Cookie = C2'' (echoed)
3) a。 ホストは、AC2からサービスを選択するためにPADRをLACに送ります。 交流クッキー=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の特権階級が始まるセッション、一層のPADと共に、メッセージはL2TPセッションかPPPoEセッション自体の文脈の中で運ばれました。 適切にメッセージを指示するためにこのポイントフォワードから交流クッキーのTAGかHost-Uniq TAGを点検する必要性がありません。
Authors' Addresses
作者のアドレス
W. Mark Townsley cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709
w.Systems7025Kit Creek RoadリサーチトライアングルPark、NC Townsleyコクチマスが27709であるとマークしてください。
EMail: mark@townsley.net
メール: mark@townsley.net
Ron da Silva AOL Time Warner 12100 Sunrise Valley Dr Reston, VA 20191
レストン、ロンダシルバAOLタイム・ワーナー12100Sunriseバレー博士ヴァージニア 20191
EMail: rdasilva@va.rr.com
メール: rdasilva@va.rr.com
Townsley & da Silva Informational [Page 16] RFC 3817 L2TP Relay for PPPoE June 2004
PPPoE2004年6月のためのTownsleyとダシルバInformational[16ページ]RFC3817L2TP Relay
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Townsley & da Silva Informational [Page 17]
TownsleyとダシルバInformational[17ページ]
一覧
スポンサーリンク
