[要約] RFC 3817は、PPPoE上のPPPのためのL2TP Active Discovery Relayに関する規格です。目的は、PPPoEセッションの確立と管理を支援するために、L2TPを使用してリレーを提供することです。

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)

レイヤー2トンネルプロトコル(L2TP)イーサネット上のPPP用のアクティブディスカバリーリレー(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)The Internet Society(2004)。

Abstract

概要

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet.

ポイントツーポイントプロトコル(PPP)は、ポイントツーポイントリンクでマルチプロトコルデータグラムを輸送するための標準的な方法を提供します。2つのトンネリングプロトコル(L2TP)を層化し、介在するパケットスイッチネットワークを介したPPPパケットのトンネルを容易にします。それでも、3番目のプロトコルであるPPP Over Ethernet(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.

L2TP Active Discovery PPPOEのリレーは、L2TP内の信頼できる制御チャネルを介してPPPOEからアクティブな発見およびサービス選択機能を中継する方法を説明しています。L2TPの2つの新しい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
        
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]は、L2TP [2]と併せて展開され、PPPOEホストが接続されているローカルイーサネットネットワークの範囲を超えてネットワーク上にPPP [3]フレームを運ぶことがよくあります。たとえば、PPPOE内でトンネル化されたPPPフレームは、L2TPアクセス濃縮器(LAC)によって受信され、IPネットワークを介して到達可能なL2TPネットワークサーバー(LNS)にトンネル化できます。

In addition to tunneling PPP over Ethernet, PPPoE defines a simple method for discovering services offered by PPPoE Access Concentrators (PPPoE AC) reachable via Ethernet from the PPPoE Host. Since the packets used in this exchange are not carried over PPP, they are not tunneled with the PPP packets over L2TP, thus the discovery negotiation cannot extend past the LAC without adding functionality.

PPPOEは、イーサネットを介したPPPのトンネルPPPに加えて、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.

このドキュメントでは、PPPOEアクティブディスカバリー(PAD)メッセージをL2TPでリレーするための簡単な方法で、PADメッセージを抽出し、L2TPコントロールチャネルに送信します。PADメッセージの処理を介してセットアップが完了した後、PPPOEを介して到着するPPPパケットは、L2TPで定義されているように、通常の方法でL2TPの上にトンネル化されます[2]。したがって、この機能をサポートするために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].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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パッドメッセージがPPPOEアクセスコンセントレーターで受信されると、メッセージは、確立されたトンネル(セクション3.1)の新たに定義されたサービスリレーリクエストメッセージ(SRRQ)を介してL2TP制御接続に渡されます。受信すると、PPPOEパッドメッセージはL2TPノードで処理されるか、別のL2TPノードまたはPPPOEアクセス濃縮器に中継されます。返信として送信されたpppoeパッドメッセージは、新たに定義されたサービスリレー返信メッセージ(SRRP)(セクション3.2)で同様の方法で処理されます。

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アクティブディスカバリー開始パケット(PADI)がPPPOEサービスリレーを提供しているL2TP LACによって受信される場合、PPPOEリレーAVP内のPADI全体(イーサネットMACヘッダーを含む)をパッケージ化する必要があり、確立されたL2TP制御接続を介して送信されます。(S)PADIが到着したインターフェイスに関連付けられています。

The PPPoE Relay AVP is sent via the Service Relay Request Message (SRRQ) defined in Section 3. The SRRQ message MUST NOT be sent to an L2TP node which did not include the PPPoE Service Relay Response Capability AVP during control connection establishment. If no acceptable control connection is available or cannot be created, PPPoE PAD operation MUST be handled locally by some means (including intentionally ignoring the PPPoE PAD message, though this must be a deliberate act).

PPPOEリレーAVPは、セクション3で定義されているサービスリレーリクエストメッセージ(SRRQ)を介して送信されます。SRRQメッセージは、コントロール接続の確立中にPPPOEサービスリレー応答機能AVPを含まないL2TPノードに送信してはなりません。許容可能な制御接続が利用できないか、作成できない場合、PPPOEパッドの操作は、何らかの方法でローカルに処理する必要があります(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アドレスの置換が必要です。

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タグまたはACクッキータグを使用する必要があります。

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-Cookieタグやホスト-UNIQタグ操作を含む例は、付録に含まれています。

      PPPoE Host         LAC            Tunnel Switch            LNS
        
                 PADI ->
                            SRRQ (w/PADI) ->      SRRQ (w/PADI) ->
                            <- SRRP (w/PADO)      <- SRRP (w/PADO)
                 <- PADO
        
2.2. Session Establishment and Teardown
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サービスリレー機能を提供しているLACが有効なPPPOE Active Discovery Request Packet(PADR)を受信する場合、LACは[2]で定義されているように、これを着信コールリクエスト(ICRQ)を作成するためのアクションとして扱う必要があります。結果のICRQメッセージには、PADR全体を含むPPPOEリレーAVPを含める必要があります。

Upon receipt of an L2TP ICRQ message, the LNS parses the PADR message as described in [3]. If this is an acceptable PPPoE service connection (e.g., the Service-Name-Error TAG would not be included in a PPPoE Active Discovery Session-confirmation packet (PADS) response), the L2TP Incoming-Call-Reply (ICRP) message that is sent to the LAC includes the resultant PPPoE PADS encapsulated within the PPPoE Relay AVP. If the service is unacceptable, the PADS with a Service-Name-Error Tag is delivered via the Relay Session AVP within a Call-Disconnect-Notify (CDN) message, which also tears down the L2TP session. The PPPoE PADS SESSION_ID in the PPPoE Relay AVP MUST always be zero as it will be selected and filled in by the LAC.

L2TP ICRQメッセージを受信すると、LNSは[3]で説明されているようにPADRメッセージを解析します。これが許容可能なPPPOEサービス接続である場合(たとえば、Service-Name-ErrorタグがPPPOEアクティブディスカバリーセッションパケット(PADS)応答に含まれない場合)、L2TP ecoming-Call-Reply(ICRP)メッセージはLACに送信されたのは、PPPOEリレーAVP内にカプセル化された結果のpppoeパッドが含まれています。サービスが受け入れられない場合、サービス名のエラータグを備えたパッドは、L2TPセッションを引き裂くコールDisconnect-Notify(CDN)メッセージ内のリレーセッションAVPを介して配信されます。PPPOEリレーAVPのPPPOE PADS SESSION_IDは、LACによって選択されて埋められるため、常にゼロでなければなりません。

Upon receipt of an ICRP with the PPPoE Relay AVP, the LAC parses the PADS from the AVP, inserts a valid PPPoE SESSION_ID, and responds to the PPPoE Host with the PADS. The MAC address of the PADS MUST be the same one was utilized during the PADI/PADO exchange described above. The LAC also completes the L2TP session establishment by sending an Incoming-Call-Connected (ICCN) to the LNS and binds the 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リレーAVPでICRPを受信すると、LACはAVPからパッドを解析し、有効なPPPOE SESSION_IDを挿入し、PPPOEホストにパッドで応答します。パッドのMACアドレスは、上記のPADI/PADO交換中に使用されたものと同じでなければなりません。また、LACは、LNSに着信コール接続(ICCN)を送信することにより、L2TPセッションの確立を完了し、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 Active Discoveryをホストに終了するパケット(PADT)を送信して、接続が終了したことを示しなければなりません。このPADTは、LNSのPPPOEサブシステムによって開始された優雅なシャットダウンである場合、CDNメッセージ内のPPPOEリレーAVPを介してLNSから受信できます。パッドと同様に、PADTメッセージのセッション_IDは、ラックの適切なセッション_IDで満たされるまでゼロになります。

If the LAC receives a PADT from the PPPoE Host, the L2TP session MUST be shut down via the standard procedures defined in [2]. The PADT MUST be sent in the CDN message to the LNS via the PPPoE Relay AVP. If the PPPoE system at the LNS disconnects the session, a PADT SHOULD be sent in the CDN. In the event that the LAC receives a disconnect from L2TP and did not receive a PADT, it MUST generate a properly formatted PADT and send it to the PPPoE Host as described in [3].

LACがPPPOEホストからPADTを受信した場合、[2]で定義されている標準手順を介してL2TPセッションをシャットダウンする必要があります。PPPOEリレーAVPを介して、PADTをCDNメッセージにLNSに送信する必要があります。LNSのPPPOEシステムがセッションを切断する場合、PADTをCDNに送信する必要があります。LACがL2TPから切断を受け、PADTを受け取らなかった場合、[3]で説明されているように、適切にフォーマットされたPADTを生成し、PPPOEホストに送信する必要があります。

Session Establishment

セッション設立

     PPPoE Host         LAC            Tunnel Switch            LNS
        
                PADR ->
                           ICRQ (w/PADR) ->
                                                 ICRQ (w/PADR) ->
                                                 <- ICRP (w/PADS)
                           <- ICRP (w/PADS)
                <- PADS
                             ICCN ->
                                                      ICCN ->
        

Session Teardown (LNS Initiated)

セッション分解(LNSが開始された)

     PPPoE Host         LAC            Tunnel Switch            LNS
        

<- CDN (w/PADT) <- CDN (w/PADT) <- PADT

<-cdn(/cost)<-cdn(with/past)< - 過去

Session Teardown (Host Initiated)

セッションの分解(ホストが開始された)

     PPPoE Host         LAC            Tunnel Switch            LNS
        
                PADT ->
                            CDN (w/PADT) ->
                                                  CDN (w/PADT) ->
        
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制御接続全体で中継されます。どのパッドメッセージを送信する必要があるかを追跡するために、Host-UniqタグとACクッキータグを使用します。それぞれが同じ方法で使用され、どのパッドメッセージが送信または返信されているかに応じて使用されます。どちらも、別のパッドメッセージへの返信として送信されたパッドメッセージがこれらのタグ全体をエコーしなければならないという事実を利用しています[3]。

For purposes of this discussion, it is useful to define two "directions" which PAD messages will traverse during a relayed PPPoE PAD message exchange. Thus, for the following example,

この議論の目的のために、リレーされたPppoeパッドメッセージ交換中にパッドメッセージが通過する2つの「方向」を定義することが有用です。したがって、次の例では、

                     "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ホストから送信されるパッドメッセージは、LAC、トンネルスイッチ、およびLNSを介して、「上流」を横断すると定義されています。反対方向に送信されるパッドメッセージは、「下流」を横断するように定義されています。

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

上流に送信されるパッドメッセージ:PADI、PADR、下流に送信されるPADTパッドメッセージ: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の間には要求/応答接続があります。パッドは単独で応答せずに送信されますが、PADRの送信者に配信する必要があります。パッドは、パッドに確立されたのと同じセッション_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.

パッドメッセージ交換のコヒーレンシーの目標は、パディ/パド、パド/パッド、パッド/パッドとパッド/パッドの間の接続がすべてノードからノードにリレーされるため、すべて無傷のままであることを保証することです。

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タグです。これらのタグは両方とも、別のメッセージへの応答として送信されたメッセージに反映する任意のデータとして定義されます。これは、各ホップでこれらのパッドメッセージを一緒に結び付けるための鍵です。次の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.

上流に送信されるパッドメッセージの場合、パッドメッセージが転送される前に、各ホスト-UNIQタグを各リレーノードに挿入する必要があります。最大で1つのHost-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.

下流に送信されるパッドメッセージの場合、パッドメッセージが転送される前に、各リレーノードに新しいACクッキータグを挿入する必要があります。パッドメッセージごとに最大で1つのACクーキータグがあるはずです。さらに、上流から複数のパッドメッセージを受信するLNSの場合、受信したSRRPメッセージごとに下流に転送される最大1つのパッドメッセージがあるはずです。言い換えれば、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クッキータグを運ぶことができないパッド(そしてありがたいことに、必要ではない)とパッドです。これらについては、このセクションの後半で説明します。上記のルールを使用して、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ノードでリソースを縛らずにこの交換を実装するには、各ノードでは、各転送されたパッドメッセージからのメッセージ応答を待っている各ノードではかない状態を必要としないことが望ましい。これは、メッセージの一貫性に使用されるPPPOEタグで送信される値について非常にインテリジェントになりたい場合に達成できます。タグはarbitrary意的なサイズと構成であり、常に全体がエコーされていることを考えると、ここで情報を使用して次のリレーホップ情報をマッピングできます。たとえば、L2TPトンネルID(コントロール接続ID)をタグにエンコードして、メッセージが到着したときにどこにリレーするかを特定することができます。この方法を選択した場合、エンコードには、値の暗号化と認証の何らかの方法を組み込む必要があります。これは、暗号化されたデータのソースであり、領収書に値を復号化および認証する必要があることを考えると、比較的単純な提案であることに注意してください(したがって、重要な交換は必要ありません。選ばれた)。個々のタグの長さが255オクテットを超えないでください。PPPOEメッセージ全体の長さは、基礎となるイーサネットの最大セグメントサイズを超えないでください。タグの長さが255オクテットを超える場合、新しいタグを構築する前にL2TPノードで状態の保存を含む圧縮スキームが必要になる場合があります。

The PADS and PADT messages do not rely on the AC-Cookie TAG or Host-Uniq TAG for directing to the proper node. As described in Section 2.2, the L2TP session is created upon receipt of a valid PADR at the L2TP LAC. Since the PADS is sent as an AVP on this message exchange, 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-Cookieタグまたはホスト-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クッキータグを不透明なオブジェクトとして扱うことになっています。Padosは、MACアドレス、サービス名タグ、およびAC-Nameタグによってのみ区別します。LACが複数のパドスを送信する場合、異なるAC-Nameタグを含める必要があります。

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.

さらに、L2TPの過負荷を制限するために、PPPOE L2TPリレーを実行するノード(LACなど)を実行することで、再送信された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.

特定の展開状況に関する多くのシナリオと考慮事項のこの操作の例は、このドキュメントの付録に記載されている場合があります。

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.

このドキュメントで定義されている拡張機能が存在し、特定のコントロール接続で動作用に構成されている場合、このセクションにリストされているAVPは、Start-Connection-Request(SCCRQ)またはStart-Control-Connection-Reply(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サービスリレーの応答機能AVP属性タイプ56は、L2TPピアにPPPOEサービスリレー(SRRQ、SRRP)メッセージとPPPOEリレーAVPが処理され、受信時に応答されることを示します。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H| rsvd  |      Length       |           Vendor ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Attribute Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

The Vendor ID is the IETF Vendor ID of 0.

ベンダーIDは0のIETFベンダーIDです。

This AVP MAY be hidden (the H bit MAY be 0 or 1).

このAVPは隠されている可能性があります(Hビットは0または1です)。

The M bit for this AVP may be set to 0 or 1. If the sender of this AVP does not wish to establish a connection to a peer which does not understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0.

このAVPのMビットは0または1に設定される場合があります。このAVPの送信者が、このL2TP拡張を理解していないピアへの接続を確立したくない場合、Mビットを1に設定する必要があります。0に設定します。

The Length of this AVP is 6.

このAVPの長さは6です。

The AVP may be present in the following messages: SCCRQ, SCCRP

AVPは次のメッセージに存在する場合があります:SCCRQ、SCCRP

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サービスリレーフォワード機能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ビットは0または1に設定される場合があります。このAVPの送信者が、このL2TP拡張を理解していないピアへの接続を確立したくない場合、Mビットを1に設定する必要があります。0に設定します。

The Length of this AVP is 6.

このAVPの長さは6です。

The AVP may be present in the following messages: SCCRQ, SCCRP

AVPは次のメッセージに存在する場合があります:SCCRQ、SCCRP

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.

サービスリレーリクエストメッセージ(SRRQ)、メッセージタイプ18は、LACによって送信され、サービスのリクエストを中継します。このドキュメントでは、セクション2でサービスをリクエストするために存在する可能性のある新しいAVPを定義します。さらなるサービスリレーメカニズムは、同様のコンテキストでこのメッセージを使用する場合もあります。他のサービスリレーメカニズムの議論は、このドキュメントの範囲外です。

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メッセージ(SRRP)、メッセージタイプ19は、サービスのリクエストの応答を中継するためにLACによって送信されます。このドキュメントでは、セクション2のサービスのリクエストへの応答として存在する可能性のある1つの新しい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.

属性タイプ55のPPPOEリレーAVPは、イーサネットMACソースと宛先アドレスを含む、PADI、PADO、PADR、PADS、PADTメッセージ全体を搭載しています。これは、L2TPを介したすべてのパッドメッセージのリレーに必要な唯一の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ビットは0または1に設定される場合があります。このAVPの送信者が、このL2TP拡張を理解していないピアへの接続を確立したくない場合、Mビットを1に設定する必要があります。0に設定します。

The Length of this AVP is 6 plus the length of the PPPoE PAD Message.

このAVPの長さは、Pppoeパッドメッセージの長さ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 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拡張機能を使用すると、LACとLNSの間でPPPOEディスカバリーパケットをトンネルし、PPPOEアクティブディスカバリーパケットが輸送されるパスを拡張することができます。これには2つの可能な意味があります。まず、トンネルパケットは、L2TPトンネルパスに沿ったトラフィックにアクセスできる侵入者によって観察可能になる可能性があります。これにより、サービスの提供やホストのアイデンティティに関する情報が、より多くの種類のメディアに、おそらくより長い距離および/またはより多くのホップまたは管理ドメインにわたって送信されていることを考えると、不正なパーティーに簡単に取得できます。この情報が悪意のある目的に使用できるかどうかは、内部に含まれる情報に依存しますが、これが機密情報である可能性があると考えられます。このメカニズムは、この情報がインターローパーに提示される可能性を高めます。第二に、侵入者がL2TP制御メッセージ内で運ばれている間にPPPOEアクティブディスカバリートラフィックを変更することも可能かもしれません。

There are at least two methods defined to help thwart this inspection or modification by an unauthorized individual. One of the two MUST be used if the service discovery information is considered to be sensitive and is traversing an untrusted network. The first suggested method is AVP hiding described in [2]. This may be used to hide the contents of the packets in transit, though offers no integrity protection against modification of data in the AVP. The second and more secure method is protecting L2TP with IPsec as defined in [6].

許可されていない個人によるこの検査または変更を阻止するために、少なくとも2つの方法が定義されています。サービスの発見情報が敏感であると見なされ、信頼できないネットワークを横断している場合、2つのうちの1つを使用する必要があります。最初に提案された方法は、[2]で説明されているAVP隠蔽です。これは、AVPのデータの変更に対する完全性保護を提供しませんが、輸送中のパケットの内容を非表示にするために使用できます。2番目の安全な方法は、[6]で定義されているように、IPSECを使用して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].

このドキュメントでは、[2]のセクション10.1に示されているように、IETFコンセンサス[5]を通じて3つの新しい「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に示されているように、IETFコンセンサス[5]を通じて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には追加の要件はありません。

7. Acknowledgements
7. 謝辞

Thanks to Vinay Shankarkumar for valuable review, comment, and implementation.

貴重なレビュー、コメント、および実装をしてくれたVinay Shankarkumarに感謝します。

Thanks to David Skoll and a number of others on pppoe@ipsec.org for providing very helpful discussion about their PPPoE implementations.

PPPOE@Ipsec.orgのDavid Skollと他の多くの人に感謝します。

Thanks to Ross Wheeler, Louis Mamakos, and David Carrel for providing valuable clarifications of PPPoE [1] while designing this protocol.

このプロトコルを設計しながら、Pppoe [1]の貴重な説明を提供してくれたRoss Wheeler、Louis Mamakos、およびDavid Carrelに感謝します。

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.、Evarts、J.、Carrel、D.、Simone、D。、およびR. Wheeler、「PPPをイーサネット上に送信する方法(PPPOE)」、RFC 2516、1999年2月。

[2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol 'L2TP'", RFC 2661, August 1999.

[2] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G.およびB. Palter、「レイヤー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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[5] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。

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] Patel、B.、Aboba、B.、Dixon、W.、Zorn、G。、およびS. Booth、「IPSECを使用したL2TPのセキュリティ」、RFC 3193、2001年11月。

Appendix A: PPPoE Relay in Point to Multipoint Environments

付録A:マルチポイント環境へのPPPOEリレー

The PPPoE PADI message in its native form, is sent as a broadcast message on an Ethernet link. Thus, more than one AC concentrator could conceivably receive and respond to this message. Similarly, a

ネイティブ形式のpppoe padiメッセージは、イーサネットリンク上のブロードキャストメッセージとして送信されます。したがって、複数のAC濃縮器がこのメッセージを受信して応答できる可能性があります。同様に、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インターフェイスは、潜在的にさまざまなサービスプロファイルを備えた複数のLNSSとロードバランスリクエストを照会するために、複数の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メッセージが伝播されると、複数のACSが添付されているイーサネットリンクで送信されるPADIの動作を模倣するために、複数の制御接続にメッセージを複製することを選択できます。複製されたノードの数が大きく、ホップ数が深い場合、PADI伝播の管理不可能な「ファンアウト」が発生する可能性があります。したがって、ここでは、絶対に必要な場合にのみメッセージを複数のコントロール接続に複製するように注意する必要があります。

The only case where it is seems necessary to replicate messages to multiple destinations is in the case where each destination is known to have varying service policies that all need to be advertised to a PPPoE Host for its gathering and selection. At the time of this writing, the authors know of no PPPoE Host implementations that take advantage of this ability (instead, responding to only a single PPPoE PADO). This, of course, is subject to change if and when PPPoE implementations are advanced to this stage.

複数の宛先にメッセージを複製する必要があると思われる唯一のケースは、各宛先がさまざまなサービスポリシーを持っていることが知られている場合、すべてが集会と選択のためにPPPOEホストに宣伝する必要があることが知られています。この執筆時点で、著者は、この能力を活用するPPPOEホストの実装がないことを知っています(代わりに、単一のPPPOE PADOのみに応答します)。もちろん、これは、PPPOEの実装がこの段階に進出した場合に変更される場合があります。

In cases where multiple Control Connections may exist to multiple LNSs for load balancing purposes, L2TP Service Relay should take measures to try one Control Connection at a time, rather than broadcasting to all Control Connections simultaneously.

ロードバランスのために複数の制御接続が複数のLNSSに存在する場合がある場合、L2TPサービスリレーは、すべての制御接続に同時にブロードキャストするのではなく、一度に1つの制御接続を試すための措置を講じる必要があります。

Appendix B: PAD Message Exchange Coherency Examples

付録B:パッドメッセージ交換の一貫性の例

Example 1: "PPPoE Relay With Multiple LNSs"

例1:「複数のLNSSを使用したPPPOEリレー」

,--- LNS1 / Host --- LAC \ `--- LNS2

、--- lns1 / host --- lac \ `--- lns2

This example assumes that there is good reason to send a copy of the PADI to both LNSs (e.g., each LNS may have a different service profile to offer).

この例は、PADIのコピーを両方のLNSSに送信する正当な理由があることを前提としています(たとえば、各LNSには異なるサービスプロファイルが提供される場合があります)。

1) a. Host sends PADI via broadcast MAC address to LAC

1) a。ホストは、ブロードキャストMACアドレスを介してPADIをLACに送信します

b. LAC replicates the PADI message and forwards a copy to LNS1 Host-Uniq = R1 (assigned)

b. ラックはPADIメッセージを複製し、コピーをlns1 host-uniq = r1(割り当て)に転送します

c. LAC replicates the PADI message and forwards a copy to LNS2 Host-Uniq = R2 (assigned)

c. ラックは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(echoed)ac-cookie = c1(割り当て)

b. LNS1 responds with PADO to LAC Host-Uniq = R2 (echoed) AC-Cookie = C2 (assigned)

b. LNS1はPadoにlacに応答します。Host-uniq = r2(echoed)ac-cookie = c2(割り当て)

c. LAC forwards both PADO messages to Host with source MAC set to MAC address of LAC. PADO from (2a) is assigned new AC-Cookie C1' and PADO from (2b) is given AC-Cookie C2'

c. LACは両方のPADOメッセージをフォワードして、Source MacをMACアドレスのLACに設定してホストします。(2A)のPADOには新しいACクーキーC1 'が割り当てられ、(2B)からのPADOにACクーキーC2'が与えられます

3) a. Host sends PADR to MAC address of LAC (choosing one) AC-Cookie = C1' (echoed)

3) a。ホストはPADRをMACアドレスのLAC(1つの選択)に送信しますAC-COOKIE = C1 '(エコー)

b. LAC knows to forward PADR to LNS1 based on C1' AC-Cookie = C1 (echoed)

b. ラックは、C1 'AC-COOKIE = C1(ECHOED)に基づいて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セッション自体のコンテキスト内でさらにパッドメッセージが掲載されます。メッセージを適切に指示するために、このポイントからAC-CookieタグまたはHost-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。ホストはパディをラックに送ります。

b. LAC sends PADI to LNS1 Host-Uniq = R1 (assigned)

b. lacはpadiをlns1 host-uniq = r1に送信します(割り当て)

c. LNS1 sends PADI to LNS2 Host-Uniq = R2 (assigned)

c. lns1はpadiをlns2に送信しますhost-uniq = r2(割り当て)

2) a. LNS2 responds to LNS1 with PADO Host-Uniq = R2 (echoed) AC-Cookie = C1 (assigned)

2) a。LNS2は、PADO HOST-UNIQ = R2(Echoed)AC-COOKIE = C1(割り当て)でLNS1に応答します

b. LNS1 relays PADO to LAC Host-Uniq = R1 (echoed) AC-Cookie = C1' (assigned)

b. lns1リレーパドからラックホスト-uniq = r1(echoed)ac-cookie = c1 '(割り当て)

c. LAC sends PADO to Host AC-Cookie = C1'' (assigned)

c. lacはpadoをHost ac-cookie = c1 ''に送信します(割り当て)

3) a. Host sends PADR to MAC address of LAC AC-Cookie = C1'' (echoed)

3) a。ホストはPadrをlac ac-cookie = c1 ''のMacアドレスに送信します(エコー)

b. LAC sends PADR to LNS1 AC-Cookie = C1' (echoed)

b. lacはpadrをlns1 ac-cookie = c1 'に送信します(echoed)

c. LNS1 sends PADR to LNS2 AC-Cookie = C1 (echoed)

c. LNS1はPADRをLNS2に送信しますac-cookie = c1(echoed)

4) Session Establishment at the LAC, LNS1 and LNS2 commences, with further PAD messages carried within the context of the L2TP session itself. No need to inspect the AC-Cookie TAG or Host-Uniq TAG from this point forward in order to direct messages properly.

4) LAC、LNS1、およびLNS2でのセッション確立が開始され、L2TPセッション自体のコンテキスト内でさらにパッドメッセージが掲載されます。メッセージを適切に指示するために、このポイントからAC-CookieタグまたはHost-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。ホストはパディをラックに送ります。

b. LAC sends PADI to LNS Host-Uniq = R1 (assigned)

b. lacはpadiをlns host-uniq = r1に送信します(割り当て)

c. LNS broadcasts PADI to AC1 and AC2 Host-Uniq = R2 (assigned)

c. LNSはPADIをAC1およびAC2 HOST-UNIQ = R2に放送します(割り当て)

2) a. AC1 sends PADO to LNS Host-Uniq = R2 (echoed) AC-Cookie = C1 (assigned)

2) a。AC1はPADOをLNS HOST-UNIQ = R2(ECHOED)AC-COOKIE = C1(割り当て)に送信します

b. AC2 sends PADO to LNS Host-Uniq = R2 (echoed) AC-Cookie = C2 (assigned)

b. AC2はPADOをLNS HOST-UNIQ = R2(ECHOED)AC-COOKIE = C2(割り当て)に送信します

c. LNS sends two PADOs to LAC Host-Uniq = R1 (echoed) AC-Cookie (assigned) = C1' and C2', respectively

c. LNSは2つのパドスをlac host-uniq = r1(echoed)ac-cookie(割り当て)= c1 'およびc2'に送信します。

d. LAC sends two PADOs to Host Host-Uniq = R1 AC-Cookie (assigned) = C1'' and C2'', respectively

d. LACは、ホスト-UNIQ = R1 AC-COOKIE(割り当て)= C1 ''とC2 ''に2つのパドを送信します。

3) a. Host sends PADR with to LAC to select service from AC2. AC-Cookie = C2'' (echoed)

3) a。ホストは、AC2からサービスを選択するためにPADRをLACに送信します。ac-cookie = c2 ''(エコー)

b. LAC sends PADR to LNS AC-Cookie = C2' (echoed)

b. lacはpadrをlns ac-cookie = c2 'に送信します(echoed)

c. LAC sends PADR to AC2 AC-Cookie = C1 (echoed)

c. lacはpadrをac2 ac-cookie = c1(echoed)に送信します

4) Session Establishment at the LAC, LNS and AC2 commences, with further PAD messages carried within the context of the L2TP session or PPPoE session itself. No need to inspect the AC-Cookie TAG or Host-Uniq TAG from this point forward in order to direct messages properly.

4) LAC、LNS、およびAC2でのセッション確立が開始され、L2TPセッションまたはPPPOEセッション自体のコンテキスト内でさらにパッドメッセージが掲載されます。メッセージを適切に指示するために、このポイントからAC-CookieタグまたはHost-Uniqタグを前方に検査する必要はありません。

Authors' Addresses

著者のアドレス

W. Mark Townsley cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709

W.マークタウンズリーシスコシステム7025キットクリークロードリサーチトライアングルパーク、ノースカロライナ州27709

   EMail: mark@townsley.net
        

Ron da Silva AOL Time Warner 12100 Sunrise Valley Dr Reston, VA 20191

Ron Da Silva Aol Time Warner 12100 Sunrise Valley Dr Reston、VA 20191

   EMail: rdasilva@va.rr.com
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

著作権(c)The Internet Society(2004)。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。