[要約] RFC 2516は、PPPをEthernet上で転送するための方法であるPPPoEについての規格です。このRFCの目的は、ブロードバンド接続を提供するために、PPPを使用してイーサネット上でネットワーク接続を確立するためのプロトコルを定義することです。
Network Working Group L. Mamakos
Request for Comments: 2516 K. Lidl
Category: Informational J. Evarts
UUNET Technologies, Inc.
D. Carrel
D. Simone
RedBack Networks, Inc.
R. Wheeler
RouterWare, Inc.
February 1999
A Method for Transmitting PPP Over Ethernet (PPPoE)
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 (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
Abstract
概要
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
ポイントツーポイントプロトコル（PPP）[1]は、ポイントツーポイントリンクを介してマルチプロトコルデータグラムを輸送するための標準的な方法を提供します。
This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet.
このドキュメントでは、PPPセッションを構築し、イーサネットを介してPPPパケットをカプセル化する方法について説明します。
Applicability
適用性
This specification is intended to provide the facilities which are defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication, and more. These capabilities require a point-to-point relationship between the peers, and are not designed for the multi-point relationships which are available in Ethernet and other multi-access environments.
この仕様は、リンク制御プロトコル、ネットワークレイヤー制御プロトコル、認証など、PPP用に定義されている機能を提供することを目的としています。これらの機能には、ピア間のポイントツーポイント関係が必要であり、イーサネットやその他のマルチアクセス環境で利用できるマルチポイント関係向けには設計されていません。
This specification can be used by multiple hosts on a shared, Ethernet to open PPP sessions to multiple destinations via one or more bridging modems. It is intended to be used with broadband remote access technologies that provide a bridged Ethernet topology, when access providers wish to maintain the session abstraction associated with PPP.
この仕様は、共有のイーサネット上の複数のホストが使用して、1つ以上のブリッジングモデムを介して複数の宛先にPPPセッションを開きます。アクセスプロバイダーがPPPに関連するセッションの抽象化を維持したい場合に、ブリッジ付きイーサネットトポロジを提供するブロードバンドリモートアクセステクノロジーで使用することを目的としています。
This document describes the PPP Over Ethernet encapsulation that is being deployed by RedBack Networks, RouterWare, UUNET and others.
このドキュメントでは、RedBackネットワーク、ルーターウェア、Uunetなどによって展開されているイーサネット上のカプセル化に関するPPPについて説明します。
Modern access technologies are faced with several conflicting goals. It is desirable to connect multiple hosts at a remote site through the same customer premise access device. It is also a goal to provide access control and billing functionality in a manner similar to dial-up services using PPP. In many access technologies, the most cost effective method to attach multiple hosts to the customer premise access device, is via Ethernet. In addition, it is desirable to keep the cost of this device as low as possible while requiring little or no configuration.
最新のアクセステクノロジーは、いくつかの矛盾する目標に直面しています。同じ顧客前提アクセスデバイスを介して、リモートサイトの複数のホストを接続することが望ましいです。また、PPPを使用したダイヤルアップサービスと同様の方法で、アクセス制御と請求機能を提供することも目標です。多くのアクセステクノロジーでは、複数のホストをCustomer Premise Accessデバイスに接続する最も費用対効果の高い方法は、イーサネットを介してです。さらに、構成はほとんどまたはまったく必要ありませんが、このデバイスのコストを可能な限り低く抑えることが望ましいです。
PPP over Ethernet (PPPoE) provides the ability to connect a network of hosts over a simple bridging access device to a remote Access Concentrator. With this model, each host utilizes it's own PPP stack and the user is presented with a familiar user interface. Access control, billing and type of service can be done on a per-user, rather than a per-site, basis.
PPP Over Ethernet（PPPOE）は、シンプルなブリッジングアクセスデバイスを介してホストのネットワークをリモートアクセスコンセントレーターに接続する機能を提供します。このモデルを使用すると、各ホストは独自のPPPスタックを利用し、ユーザーにはおなじみのユーザーインターフェイスが表示されます。アクセス制御、請求、およびサービスの種類は、1人あたりのベースではなく、ユーザーごとに行うことができます。
To provide a point-to-point connection over Ethernet, each PPP session must learn the Ethernet address of the remote peer, as well as establish a unique session identifier. PPPoE includes a discovery protocol that provides this.
イーサネット上のポイントツーポイント接続を提供するには、各PPPセッションでは、リモートピアのイーサネットアドレスを学習し、一意のセッション識別子を確立する必要があります。PPPOEには、これを提供するディスカバリープロトコルが含まれています。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [2].
キーワードは、[2]で説明されているように解釈される場合、このドキュメントに表示される場合、キーワードは必要、必要は、推奨される、推奨する、推奨することはできません。
PPPoE has two distinct stages. There is a Discovery stage and a PPP Session stage. When a Host wishes to initiate a PPPoE session, it must first perform Discovery to identify the Ethernet MAC address of the peer and establish a PPPoE SESSION_ID. While PPP defines a peer-to-peer relationship, Discovery is inherently a client-server relationship. In the Discovery process, a Host (the client) discovers an Access Concentrator (the server). Based on the network topology, there may be more than one Access Concentrator that the Host can communicate with. The Discovery stage allows the Host to discover all Access Concentrators and then select one. When Discovery completes successfully, both the Host and the selected Access Concentrator have the information they will use to build their point-to-point connection over Ethernet.
PPPOEには2つの異なる段階があります。ディスカバリーステージとPPPセッションステージがあります。ホストがPPPOEセッションの開始を希望する場合、最初にピアのイーサネットMACアドレスを識別し、PPPOE SESSION_IDを確立するために発見を実行する必要があります。PPPはピアツーピアの関係を定義しますが、発見は本質的にクライアントサーバーの関係です。発見プロセスでは、ホスト（クライアント）がアクセスコンセントレーター（サーバー）を発見します。ネットワークトポロジに基づいて、ホストが通信できる複数のアクセスコンセントレーターがある場合があります。ディスカバリーステージにより、ホストはすべてのアクセス濃縮器を発見してから1つを選択できます。ディスカバリーが正常に完了すると、ホストと選択したアクセスコンセントレーターの両方が、イーサネット上のポイントツーポイント接続を構築するために使用する情報を持っています。
The Discovery stage remains stateless until a PPP session is established. Once a PPP session is established, both the Host and the Access Concentrator MUST allocate the resources for a PPP virtual interface.
PPPセッションが確立されるまで、ディスカバリーステージはステートレスのままです。PPPセッションが確立されると、ホストとアクセス濃縮器の両方がPPP仮想インターフェイスにリソースを割り当てる必要があります。
The following packet formats are defined here. The payload contents will be defined in the Discovery and PPP sections.
次のパケット形式はここで定義されています。ペイロードコンテンツは、ディスカバリーおよびPPPセクションで定義されます。
An Ethernet frame is as follows:
イーサネットフレームは次のとおりです。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESTINATION_ADDR |
| (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR |
| (6 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ payload ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DESTINATION_ADDR field contains either a unicast Ethernet destination address, or the Ethernet broadcast address (0xffffffff). For Discovery packets, the value is either a unicast or broadcast address as defined in the Discovery section. For PPP session traffic, this field MUST contain the peer's unicast address as determined from the Discovery stage.
destination_addrフィールドには、ユニキャストイーサネット宛先アドレスまたはイーサネットブロードキャストアドレス（0xffffffffff）が含まれています。ディスカバリーパケットの場合、値は、ディスカバリーセクションで定義されているユニキャストまたはブロードキャストアドレスのいずれかです。PPPセッショントラフィックの場合、このフィールドには、ディスカバリー段階から決定されたピアのユニキャストアドレスが含まれている必要があります。
The SOURCE_ADDR field MUST contains the Ethernet MAC address of the source device.
SOURCE_ADDRフィールドには、ソースデバイスのイーサネットMACアドレスが含まれている必要があります。
The ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864 (PPP Session Stage).
Ether_Typeは、0x8863（発見段階）または0x8864（PPPセッションステージ）のいずれかに設定されています。
The Ethernet payload for PPPoE is as follows:
PPPOEのイーサネットペイロードは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | TYPE | CODE | SESSION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH | payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The VER field is four bits and MUST be set to 0x1 for this version of the PPPoE specification.
Verフィールドは4ビットで、PPPOE仕様のこのバージョンでは0x1に設定する必要があります。
The TYPE field is four bits and MUST be set to 0x1 for this version of the PPPoE specification.
タイプフィールドは4ビットで、PPPOE仕様のこのバージョンでは0x1に設定する必要があります。
The CODE field is eight bits and is defined below for the Discovery and PPP Session stages.
コードフィールドは8ビットで、発見およびPPPセッションの段階で以下に定義されています。
The SESSION_ID field is sixteen bits. It is an unsigned value in network byte order. It's value is defined below for Discovery packets. The value is fixed for a given PPP session and, in fact, defines a PPP session along with the Ethernet SOURCE_ADDR and DESTINATION_ADDR. A value of 0xffff is reserved for future use and MUST NOT be used
Session_idフィールドは16ビットです。これは、ネットワークバイトの順序で署名されていない値です。その値は、ディスカバリーパケットの以下に定義されています。値は特定のPPPセッションで固定されており、実際、Ethernet source_addrおよびdestination_addrとともにPPPセッションを定義します。0xffffの値は将来の使用のために予約されており、使用してはなりません
The LENGTH field is sixteen bits. The value, in network byte order, indicates the length of the PPPoE payload. It does not include the length of the Ethernet or PPPoE headers.
長さのフィールドは16ビットです。値は、ネットワークバイトの順序で、PPPOEペイロードの長さを示します。イーサネットまたはPPPOEヘッダーの長さは含まれません。
There are four steps to the Discovery stage. When it completes, both peers know the PPPoE SESSION_ID and the peer's Ethernet address, which together define the PPPoE session uniquely. The steps consist of the Host broadcasting an Initiation packet, one or more Access Concentrators sending Offer packets, the Host sending a unicast Session Request packet and the selected Access Concentrator sending a Confirmation packet. When the Host receives the Confirmation packet, it may proceed to the PPP Session Stage. When the Access Concentrator sends the Confirmation packet, it may proceed to the PPP Session Stage.
発見段階には4つのステップがあります。それが完了すると、両方のピアがPPPOE SESSION_IDとピアのイーサネットアドレスを知っています。手順は、ホストが開始パケットをブロードキャストし、1つ以上のアクセスコンセントレーターがオファーパケットを送信すること、ホストがユニキャストセッションリクエストパケットを送信し、選択したアクセスコンセントレーターが確認パケットを送信することで構成されています。ホストが確認パケットを受信すると、PPPセッションステージに進むことがあります。Access Concentorが確認パケットを送信すると、PPPセッションステージに進むことがあります。
All Discovery Ethernet frames have the ETHER_TYPE field set to the value 0x8863.
すべてのディスカバリーイーサネットフレームには、ETHER_TYPEフィールドが値0x8863に設定されています。
The PPPoE payload contains zero or more TAGs. A TAG is a TLV (type-length-value) construct and is defined as follows:
PPPOEペイロードには、ゼロ以上のタグが含まれています。タグはTLV（タイプ長価値）コンストラクトであり、次のように定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE | TAG_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_VALUE ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TAG_TYPE is a sixteen bit field in network byte order. Appendix A contains a list of all TAG_TYPEs and their TAG_VALUEs.
tag_typeは、ネットワークバイトの順序で16ビットフィールドです。付録Aには、すべてのtag_typesとそのtag_valuesのリストが含まれています。
TAG_LENGTH is a sixteen bit field. It is an unsigned number in network byte order, indicating the length in octets of the TAG_VALUE.
tag_lengthは16ビットフィールドです。これは、ネットワークバイトの順序で署名されていない数値であり、tag_valueのオクテットの長さを示します。
If a discovery packet is received with a TAG of unknown TAG_TYPE, the TAG MUST be ignored unless otherwise specified in this document. This provides for backwards compatibility if/when new TAGs are added. If new mandatory TAGs are added, the version number will be incremented.
未知のtag_typeのタグでディスカバリーパケットが受信された場合、このドキュメントで特に指定されていない限り、タグは無視する必要があります。これにより、新しいタグが追加された場合に逆方向の互換性が提供されます。新しい必須タグが追加されると、バージョン番号が増加します。
Some example Discovery packets are shown in Appendix B.
いくつかの例ディスカバリーパケットは、付録Bに示されています
The Host sends the PADI packet with the DESTINATION_ADDR set to the broadcast address. The CODE field is set to 0x09 and the SESSION_ID MUST be set to 0x0000.
ホストは、destination_addrをブロードキャストアドレスに設定してPADIパケットを送信します。コードフィールドは0x09に設定され、Session_Idは0x0000に設定する必要があります。
The PADI packet MUST contain exactly one TAG of TAG_TYPE Service-Name, indicating the service the Host is requesting, and any number of other TAG types. An entire PADI packet (including the PPPoE header) MUST NOT exceed 1484 octets so as to leave sufficient room for a relay agent to add a Relay-Session-Id TAG.
PADIパケットには、Tag_Type Service-Nameのタグが正確に1つある必要があり、ホストが要求しているサービスと他のタグタイプの任意の数を示している必要があります。PADIパケット全体（PPPOEヘッダーを含む）は、リレーエージェントがリレーセッションIDタグを追加するのに十分なスペースを残すために、1484オクテットを超えてはなりません。
When the Access Concentrator receives a PADI that it can serve, it replies by sending a PADO packet. The DESTINATION_ADDR is the unicast address of the Host that sent the PADI. The CODE field is set to 0x07 and the SESSION_ID MUST be set to 0x0000.
アクセスコンセントレーターが提供できるPADIを受け取ると、PADOパケットを送信することで返信します。Destination_Addrは、PADIを送信したホストのユニキャストアドレスです。コードフィールドは0x07に設定され、Session_Idは0x0000に設定する必要があります。
The PADO packet MUST contain one AC-Name TAG containing the Access Concentrator's name, a Service-Name TAG identical to the one in the PADI, and any number of other Service-Name TAGs indicating other services that the Access Concentrator offers. If the Access Concentrator can not serve the PADI it MUST NOT respond with a PADO.
PADOパケットには、アクセスコンセントレーターの名前を含む1つのAC-Nameタグ、PADIのものと同一のサービス名、およびAccess Concencoratorが提供する他のサービスを示す他の任意の数のサービス名タグを含める必要があります。アクセスコンセントレーターがパディを提供できない場合、パドで応答してはなりません。
Since the PADI was broadcast, the Host may receive more than one PADO. The Host looks through the PADO packets it receives and chooses one. The choice can be based on the AC-Name or the Services offered. The Host then sends one PADR packet to the Access Concentrator that it has chosen. The DESTINATION_ADDR field is set to the unicast Ethernet address of the Access Concentrator that sent the PADO. The CODE field is set to 0x19 and the SESSION_ID MUST be set to 0x0000.
PADIが放送されたため、ホストは複数のPADOを受け取ることがあります。ホストは、受信したPadoパケットを調べて選択します。選択は、AC-Nameまたは提供されるサービスに基づいています。その後、ホストは1つのPADRパケットを選択したAccess Concentorに送信します。Destination_Addrフィールドは、PADOを送信したアクセス濃縮器のユニキャストイーサネットアドレスに設定されています。コードフィールドは0x19に設定され、Session_Idは0x0000に設定する必要があります。
The PADR packet MUST contain exactly one TAG of TAG_TYPE Service-Name, indicating the service the Host is requesting, and any number of other TAG types.
PADRパケットには、TAG_TYPE Service-Nameのタグが正確に1つある必要があり、ホストが要求しているサービスと他のタグタイプの任意の数を示している必要があります。
When the Access Concentrator receives a PADR packet, it prepares to begin a PPP session. It generates a unique SESSION_ID for the PPPoE session and replies to the Host with a PADS packet. The DESTINATION_ADDR field is the unicast Ethernet address of the Host that sent the PADR. The CODE field is set to 0x65 and the SESSION_ID MUST be set to the unique value generated for this PPPoE session.
Access concentatorがPADRパケットを受信すると、PPPセッションを開始する準備ができます。PPPOEセッション用に一意のセッション_IDを生成し、パッドパケットでホストに返信します。Destination_Addrフィールドは、PADRを送信したホストのユニキャストイーサネットアドレスです。コードフィールドは0x65に設定されており、Session_IDは、このPPPOEセッションで生成された一意の値に設定する必要があります。
The PADS packet contains exactly one TAG of TAG_TYPE Service-Name, indicating the service under which Access Concentrator has accepted the PPPoE session, and any number of other TAG types.
PADSパケットには、tag_type service-nameのタグが正確に1つ含まれており、Access concentorがpppoeセッションを受け入れたサービスと、他の任意の数のタグタイプを示します。
If the Access Concentrator does not like the Service-Name in the PADR, then it MUST reply with a PADS containing a TAG of TAG_TYPE Service-Name-Error (and any number of other TAG types). In this case the SESSION_ID MUST be set to 0x0000.
Access concencoratorがPADRのサービス名が気に入らない場合は、tag_type service-name-error（および他の任意の数のタグタイプ）のタグを含むパッドで返信する必要があります。この場合、セッション_IDは0x0000に設定する必要があります。
This packet may be sent anytime after a session is established to indicate that a PPPoE session has been terminated. It may be sent by either the Host or the Access Concentrator. The DESTINATION_ADDR field is a unicast Ethernet address, the CODE field is set to 0xa7 and the SESSION_ID MUST be set to indicate which session is to be terminated. No TAGs are required.
このパケットは、PPPOEセッションが終了したことを示すためにセッションが確立された後、いつでも送信される場合があります。ホストまたはアクセスコンセントレーターのいずれかによって送信される場合があります。destination_addrフィールドはユニキャストイーサネットアドレスであり、コードフィールドは0xa7に設定され、セッション_IDを設定する必要があります。タグは必要ありません。
When a PADT is received, no further PPP traffic is allowed to be sent using that session. Even normal PPP termination packets MUST NOT be sent after sending or receiving a PADT. A PPP peer SHOULD use the PPP protocol itself to bring down a PPPoE session, but the PADT MAY be used when PPP can not be used.
PADTを受信した場合、そのセッションを使用してPPPトラフィックを送信することは許可されません。通常のPPP終端パケットでも、パッドを送信または受信した後に送信しないでください。PPPピアはPPPプロトコル自体を使用してPPPOEセッションを削減する必要がありますが、PPPを使用できない場合はPADTを使用できます。
Once the PPPoE session begins, PPP data is sent as in any other PPP encapsulation. All Ethernet packets are unicast. The ETHER_TYPE field is set to 0x8864. The PPPoE CODE MUST be set to 0x00. The SESSION_ID MUST NOT change for that PPPoE session and MUST be the value assigned in the Discovery stage. The PPPoE payload contains a PPP frame. The frame begins with the PPP Protocol-ID.
PPPOEセッションが開始されると、PPPデータは他のPPPカプセル化のように送信されます。すべてのイーサネットパケットはユニキャストです。Ether_Typeフィールドは0x8864に設定されています。PPPOEコードは0x00に設定する必要があります。Session_idは、そのpppoeセッションのために変更されてはならず、ディスカバリー段階で割り当てられた値である必要があります。PPPOEペイロードにはPPPフレームが含まれています。フレームは、PPPプロトコルIDから始まります。
An example packet is shown in Appendix B.
パケットの例を付録Bに示します。
The Magic Number LCP configuration option is RECOMMENDED, and the Protocol Field Compression (PFC) option is NOT RECOMMENDED. An implementation MUST NOT request any of the following options, and MUST reject a request for such an option:
マジック番号LCP構成オプションが推奨され、プロトコルフィールド圧縮（PFC）オプションは推奨されません。実装は、次のオプションのいずれかを要求してはならず、そのようなオプションのリクエストを拒否する必要があります。
Field Check Sequence (FCS) Alternatives,
フィールドチェックシーケンス（FCS）の代替案、
Address-and-Control-Field-Compression (ACFC),
アドレスとコントロールフィールド圧縮（ACFC）、
Asynchronous-Control-Character-Map (ACCM)
非同期制御 - キャラクターマップ（ACCM）
The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1492. Since Ethernet has a maximum payload size of 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the PPP MTU MUST NOT be greater than 1492.
最大レシーブユニット（MRU）オプションは1492より大きなサイズと交渉してはなりません。イーサネットの最大ペイロードサイズの1500オクテットは6オクターで、PPPプロトコルIDは2オクテット、PPP MTUは2オクテットです。1492を超えてはいけません。
It is RECOMMENDED that the Access Concentrator ocassionally send Echo-Request packets to the Host to determine the state of the session. Otherwise, if the Host terminates a session without sending a Terminate-Request packet, the Access Concentrator will not be able to determine that the session has gone away.
アクセス濃縮器は、セッションの状態を決定するために、エコーリクエストパケットをホストに偶然送信することをお勧めします。それ以外の場合、ホストが終了リケストパケットを送信せずにセッションを終了した場合、アクセスコンセントレーターはセッションがなくなったことを判断できません。
When LCP terminates, the Host and Access concentrator MUST stop using that PPPoE session. If the Host wishes to start another PPP session, it MUST return to the PPPoE Discovery stage.
LCPが終了すると、ホストとアクセスコンセントレーターはそのPPPOEセッションの使用を停止する必要があります。ホストが別のPPPセッションを開始したい場合は、PPPOEディスカバリー段階に戻る必要があります。
When a host does not receive a PADO packet within a specified amount of time, it SHOULD resend it's PADI packet and double the waiting period. This is repeated as many times as desired. If the Host is waiting to receive a PADS packet, a similar timeout mechanism SHOULD be used, with the Host re-sending the PADR. After a specified number of retries, the Host SHOULD then resend a PADI packet.
ホストが指定された時間内にPADOパケットを受け取らない場合、PADIパケットを再送信し、待機期間を2倍にする必要があります。これは、何度も繰り返されます。ホストがパッドパケットの受信を待っている場合、ホストがPADRを再配置すると、同様のタイムアウトメカニズムを使用する必要があります。指定された数の再試行の後、ホストはPADIパケットを再送信する必要があります。
The ETHER_TYPEs used in this document (0x8863 and 0x8864) have been assigned by the IEEE for use by PPP Over Ethernet (PPPoE). Use of these values and the PPPoE VER (version) field uniquely identify this protocol.
このドキュメント（0x8863および0x8864）で使用されているETHER_TYPESは、IEEEによってPPPを介してイーサネットを介して使用するために割り当てられています（PPPOE）。これらの値とPPPOE Ver（バージョン）フィールドの使用は、このプロトコルを一意に識別します。
UTF-8 [5] is used throughout this document instead of ASCII. UTF-8 supports the entire ASCII character set while allowing for international character sets as well. See [5] for more details.
UTF-8 [5]は、ASCIIの代わりにこのドキュメント全体で使用されます。UTF-8は、国際的なキャラクターセットも可能にしながら、ASCIIキャラクターセット全体をサポートしています。詳細については、[5]を参照してください。
To help protect against Denial of Service (DOS) attacks, the Access Concentrator can employ the AC-Cookie TAG. The Access Concentrator SHOULD be able to uniquely regenerate the TAG_VALUE based on the PADR SOURCE_ADDR. Using this, the Access Concentrator can ensure that the PADI SOURCE_ADDR is indeed reachable and can then limit concurrent sessions for that address. What algorithm to use is not defined and left as an implementation detail. An example is HMAC [3] over the Host MAC address using a key known only to the Access > Concentrator. While the AC-Cookie is useful against some DOS attacks, it can not protect against all DOS attacks and an Access Concentrator MAY employ other means to protect resources.
サービス拒否（DOS）攻撃から保護するために、Access ConcentoratorはAC-Cookieタグを採用できます。Access Concencoratorは、PADR source_addrに基づいてtag_valueを一意に再生できる必要があります。これを使用して、アクセスコンセントレーターは、PADI source_addrが実際に到達可能であることを保証し、そのアドレスの同時セッションを制限できます。使用するアルゴリズムは定義されておらず、実装の詳細として残されています。例は、Access> concentatorのみに既知のキーを使用して、ホストMACアドレス上のHMAC [3]です。ACクッキーは一部のDOS攻撃に対して有用ですが、すべてのDOS攻撃から保護することはできず、アクセスコンセントレーターはリソースを保護するために他の手段を採用する場合があります。
While the AC-Cookie is useful against some DOS attacks, it can not protect against all DOS attacks and an Access Concentrator MAY employ other means to protect resources.
ACクッキーは一部のDOS攻撃に対して有用ですが、すべてのDOS攻撃から保護することはできず、アクセスコンセントレーターはリソースを保護するために他の手段を採用する場合があります。
Many Access Concentrators will not wish to offer information regarding what services they offer to an unauthenticated entity. In that case the Access Concentrator should employ one of two policies. It SHOULD never refuse a request based on the Service-Name TAG, and always return the TAG_VALUE that was sent to it. Or it SHOULD only accept requests with a Service-Name TAG with a zero TAG_LENGTH (indicating any service). The former solution is RECOMMENDED.
多くのアクセスコンセントレーターは、認定されていないエンティティに提供するサービスに関する情報を提供したくありません。その場合、Access Concentatorは2つのポリシーのいずれかを採用する必要があります。Service-Nameタグに基づいてリクエストを拒否したり、送信されたtag_valueを常に返したりしないでください。または、ゼロtag_length（任意のサービスを示す）を備えたService-nameタグでのみリクエストを受け入れる必要があります。前者のソリューションが推奨されます。
This document is based on concepts discussed in several forums, including the ADSL forum.
このドキュメントは、ADSLフォーラムを含むいくつかのフォーラムで説明されている概念に基づいています。
Copious amounts of text have been stolen from RFC 1661, RFC 1662 and RFC 2364.
RFC 1661、RFC 1662、およびRFC 2364から大量のテキストが盗まれました。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994
[1] シンプソン、W。、編集者、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1998.
[3] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1998年2月。
[4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[5] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
TAG_TYPES and TAG_VALUES
tag_typesとtag_values
0x0000 End-Of-List
0x0000リストの終わり
This TAG indicates that there are no further TAGs in the list. The TAG_LENGTH of this TAG MUST always be zero. Use of this TAG is not required, but remains for backwards compatibility.
このタグは、リストにそれ以上のタグがないことを示しています。このタグのtag_lengthは常にゼロでなければなりません。このタグの使用は必須ではありませんが、後方互換性のために残ります。
0x0101 Service-Name
0x0101 Service-Name
This TAG indicates that a service name follows. The TAG_VALUE is an UTF-8 string that is NOT NULL terminated. When the TAG_LENGTH is zero this TAG is used to indicate that any service is acceptable. Examples of the use of the Service-Name TAG are to indicate an ISP name or a class or quality of service.
このタグは、サービス名が続くことを示します。tag_valueは、null終了しないUTF-8文字列です。tag_lengthがゼロの場合、このタグは、あらゆるサービスが許容できることを示すために使用されます。Service-Nameタグの使用の例は、ISP名またはクラスまたはサービスの品質を示すことです。
0x0102 AC-Name
0x0102 ac-name
This TAG indicates that a string follows which uniquely identifies this particular Access Concentrator unit from all others. It may be a combination of trademark, model, and serial id information, or simply an UTF-8 rendition of the MAC address of the box. It is not NULL terminated.
このタグは、この特定のアクセスコンセントレーターユニットを他のすべてのものから一意に識別する文字列が続くことを示します。これは、商標、モデル、シリアルID情報、または単にボックスのMacアドレスのUTF-8の演出の組み合わせである場合があります。null終了ではありません。
0x0103 Host-Uniq
0x0103 host-uniq
This TAG is used by a Host to uniquely associate an Access Concentrator response (PADO or PADS) to a particular Host request (PADI or PADR). The TAG_VALUE is binary data of any value and length that the Host chooses. It is not interpreted by the Access Concentrator. The Host MAY include a Host-Uniq TAG in a PADI or PADR. If the Access Concentrator receives this TAG, it MUST include the TAG unmodified in the associated PADO or PADS response.
このタグは、ホストによって使用され、アクセスコンセントレーター応答（PADOまたはPADS）を特定のホスト要求（PADIまたはPADR）に一意に関連付けます。tag_valueは、ホストが選択する任意の値と長さのバイナリデータです。アクセス濃縮器によって解釈されません。ホストには、PADIまたはPADRにホスト-UNIQタグを含めることができます。Access Concencoratorがこのタグを受信した場合、関連するPADOまたはPADS応答に変更されていないタグを含める必要があります。
0x0104 AC-Cookie
0x0104 ac-cookie
This TAG is used by the Access Concentrator to aid in protecting against denial of service attacks (see the Security Considerations section for an explanation of how this works). The Access Concentrator MAY include this TAG in a PADO packet. If a Host receives this TAG, it MUST return the TAG unmodified in the following PADR. The TAG_VALUE is binary data of any value and length and is not interpreted by the Host.
このタグは、Access concentoratorによって使用され、サービス拒否攻撃から保護するのに役立ちます（これがどのように機能するかについての説明については、セキュリティに関する考慮事項セクションを参照）。アクセスコンセントレーターには、このタグをPADOパケットに含めることができます。ホストがこのタグを受信した場合、次のPADRで変更されていないタグを返す必要があります。tag_valueは、任意の値と長さのバイナリデータであり、ホストによって解釈されません。
0x0105 Vendor-Specific
0x0105ベンダー固有
This TAG is used to pass vendor proprietary information. The first four octets of the TAG_VALUE contain the vendor id and the remainder is unspecified. The high-order octet of the vendor id is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [4].
このタグは、ベンダー専有情報を渡すために使用されます。tag_valueの最初の4オクテットにはベンダーIDが含まれており、残りは不特定です。ベンダーIDの高次オクテットは0であり、低次の3オクテットは、割り当てられた番号RFC [4]で定義されているように、ネットワークバイト順序でベンダーのSMIネットワーク管理プライベートエンタープライズコードです。
Use of this TAG is NOT RECOMMENDED. To ensure inter-operability, an implementation MAY silently ignore a Vendor-Specific TAG.
このタグの使用は推奨されません。相互作用性を確保するために、実装はベンダー固有のタグを静かに無視する場合があります。
0x0110 Relay-Session-Id
0x0110リレーセッションID
This TAG MAY be added to any discovery packet by an intermediate agent that is relaying traffic. The TAG_VALUE is opaque to both the Host and the Access Concentrator. If either the Host or Access Concentrator receives this TAG they MUST include it unmodified in any discovery packet they send as a response. All PADI packets MUST guarantee sufficient room for the addition of a Relay-Session-Id TAG with a TAG_VALUE length of 12 octets.
このタグは、トラフィックを中継している中間エージェントによって任意のディスカバリーパケットに追加される場合があります。tag_valueは、ホストとアクセス濃縮器の両方に不透明です。ホストまたはAccess concentatorがこのタグを受け取る場合、それらは応答として送信するディスカバリーパケットに変更されていないことを含める必要があります。すべてのPADIパケットは、12オクテットのTAG_Value長を持つリレーセッションIDタグを追加するのに十分なスペースを保証する必要があります。
A Relay-Session-Id TAG MUST NOT be added if the discovery packet already contains one. In that case the intermediate agent SHOULD use the existing Relay-Session-Id TAG. If it can not use the existing TAG or there is insufficient room to add a Relay-Session-Id TAG, then it SHOULD return a Generic-Error TAG to the sender.
ディスカバリーパケットに既に含まれている場合、リレーセッションIDタグを追加しないでください。その場合、中間エージェントは既存のリレーセッションIDタグを使用する必要があります。既存のタグを使用できない場合、またはリレーセッションIDタグを追加するためのスペースが不十分な場合は、ジェネリックエラータグを送信者に返す必要があります。
0x0201 Service-Name-Error
0x0201 service-name-error
This TAG (typically with a zero-length data section) indicates that for one reason or another, the requested Service-Name request could not be honored.
このタグ（通常、ゼロ長データセクションを使用）は、何らかの理由で、要求されたサービス名の要求を尊重できないことを示しています。
If there is data, and the first octet of the data is nonzero, then it MUST be a printable UTF-8 string which explains why the request was denied. This string MAY NOT be NULL terminated.
データがあり、データの最初のオクテットがゼロでない場合、リクエストが拒否された理由を説明する印刷可能なUTF-8文字列でなければなりません。この文字列は、終了しない場合があります。
0x0202 AC-System-Error
0x0202 ac-system-error
This TAG indicates that the Access Concentrator experienced some error in performing the Host request. (For example insufficient resources to create a virtual circuit.) It MAY be included in PADS packets.
このタグは、Access Concentorがホスト要求の実行にある程度のエラーを経験したことを示しています。（たとえば、仮想回路を作成するためのリソースが不十分です。）パッドパケットに含まれる場合があります。
If there is data, and the first octet of the data is nonzero, then it MUST be a printable UTF-8 string which explains the nature of the error. This string MAY NOT be NULL terminated.
データがあり、データの最初のオクテットがゼロでない場合、エラーの性質を説明する印刷可能なUTF-8文字列でなければなりません。この文字列は、終了しない場合があります。
0x0203 Generic-Error
0x0203 generic-error
This TAG indicates an error. It can be added to PADO, PADR or PADS packets when an unrecoverable error occurs and no other error TAG is appropriate. If there is data then it MUST be an UTF-8 string which explains the nature of the error. This string MUST NOT be NULL terminated.
このタグはエラーを示します。回復不可能なエラーが発生し、他のエラータグが適切でない場合、PADO、PADR、またはPADSパケットに追加できます。データがある場合、エラーの性質を説明するUTF-8文字列でなければなりません。この文字列は、終了してはなりません。
The following are some example packets:
以下はパケットの例です。
A PADI packet:
パディパケット：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xffffffff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xffff | Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x09 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x0000 | LENGTH = 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PADO packet:
パドパケット：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) | Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x07 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x0000 | LENGTH = 0x0020 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0101 | TAG_LENGTH = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG_TYPE = 0x0102 | TAG_LENGTH = 0x0018 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x47 | 0x6f | 0x20 | 0x52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x65 | 0x64 | 0x42 | 0x61 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x63 | 0x6b | 0x20 | 0x2d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x20 | 0x65 | 0x73 | 0x68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x73 | 0x68 | 0x65 | 0x73 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x68 | 0x6f | 0x6f | 0x74 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PPP LCP packet: The PPP protocol value is shown (0xc021) but the PPP payload is left to the reader. This is a packet from the Host to the Access Concentrator.
PPP LCPパケット：PPPプロトコル値が表示されます（0xc021）が、PPPペイロードは読者に任されています。これは、ホストからアクセスコンセントレーターまでのパケットです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x???? |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PROTOCOL = 0xc021 | PPP payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authors' Addresses
著者のアドレス
Louis Mamakos UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031-4648 United States of America
Louis Mamakos Uunet Technologies、Inc。3060 Williams Drive Fairfax、VA 22031-4648アメリカ合衆国アメリカ
EMail: louie@uu.net
Kurt Lidl UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031-4648 United States of America
Kurt Lidl Uunet Technologies、Inc。3060 Williams Drive Fairfax、VA 22031-4648アメリカ合衆国アメリカ
EMail: lidl@uu.net
Jeff Evarts UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031-4648 United States of America
Jeff Evarts Uunet Technologies、Inc。3060 Williams Drive Fairfax、VA 22031-4648アメリカ合衆国アメリカ
EMail: jde@uu.net
David Carrel RedBack Networks, Inc. 1389 Moffett Park Drive Sunnyvale, CA 94089-1134 United States of America
David Carreel Redback Networks、Inc。1389 Moffett Park Drive Sunnyvale、CA 94089-1134アメリカ合衆国アメリカ
EMail: carrel@RedBack.net
Dan Simone RedBack Networks, Inc. 1389 Moffett Park Drive Sunnyvale, CA 94089-1134 United States of America
Dan Simone Redback Networks、Inc。1389 Moffett Park Drive Sunnyvale、CA 94089-1134アメリカ合衆国アメリカ
EMail:dan@RedBack.net
メール：dan@redback.net
Ross Wheeler RouterWare, Inc. 3961 MacArthur Blvd., Suite 212 Newport Beach, CA 92660 United States of America
Ross Wheeler Routerware、Inc。3961 Macarthur Blvd.、Suite 212 Newport Beach、CA 92660 United States of America
EMail: ross@routerware.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明するか、その実装を支援する派生作品は、いかなる種類の制限なしに、準備、コピー、公開、配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準のプロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。