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)
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.
著作権（C）インターネット協会（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.
この仕様は、一台の以上のブリッジモデムを介して、複数の宛先へのPPPセッションを開くには、共有、イーサネット上の複数のホストで使用することができます。アクセスプロバイダは、PPPに関連するセッションの抽象化を維持したいときには、ブリッジイーサネットトポロジを提供し、ブロードバンドリモートアクセス技術を使用することを意図しています。
This document describes the PPP Over Ethernet encapsulation that is being deployed by RedBack Networks, RouterWare, UUNET and others.
この文書では、レッドバックネットワークス、のRouterware、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を使用して、同様の方法でアクセス制御および課金機能を提供することが目標です。多くのアクセス技術では、顧客宅内アクセスデバイスに複数のホストを接続するための最もコスト効果的な方法は、イーサネット経由です。また、ほとんど又は全く設定を必要としながら、可能な限り低く、この装置のコストを維持することが望ましいです。
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（PPPoEは）リモートアクセスコンセントレータへの単純なブリッジングアクセスデバイス上にホストのネットワークに接続する能力を提供します。このモデルでは、各ホストはそれ自身のPPPスタックを利用し、ユーザーが使い慣れたユーザーインターフェースを提示されます。サービスのアクセス制御、課金・タイプではなく、サイトごと、基礎よりも、ユーザごとに行うことができます。
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].
キーワードは、REQUIREDは、、、、、MAYを推奨、オプション、彼らは、この文書に表示されたときに、で説明したように解釈されるすべきでないないものとものとしてはなりませんしなければならない[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は、二つの異なる段階があります。ディスカバリーステージと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フィールドはユニキャストイーサネット宛先アドレス、またはイーサネットブロードキャストアドレス（0xFFFFFFFFの）いずれかを含みます。ディスカバリパケットの場合、値は検出部で定義されるように、ユニキャストまたはブロードキャストアドレスのいずれかです。ディスカバリー段階から決定されたPPPセッショントラフィックの場合、このフィールドはピアのユニキャストアドレスを含まなければなりません。
The SOURCE_ADDR field MUST contains the Ethernet MAC address of the source device.
SOURCE_ADDRフィールドMUSTは、ソースデバイスのイーサネット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.
TYPEフィールドは4ビットであり、PPPoEの仕様のこのバージョンの0x1に設定しなければなりません。
The CODE field is eight bits and is defined below for the Discovery and PPP Session stages.
CODEフィールドは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ビットです。これは、ネットワークバイト順で符号なしの値です。これは、値がディスカバリーパケットのために次のように定義されます。値は、実際には、イーサネットSOURCE_ADDRとDESTINATION_ADDRと共にPPPセッションを定義し、指定された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.
LENGTHフィールドは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と一緒に一意のPPPoEセッションを定義するピアのイーサネットアドレスを、知っています。手順は、開始パケットをブロードキャストしているホストのオファーパケットを送信する1つ以上のアクセスコンセントレータ、ホストのユニキャストセッション要求パケットを送信すると、選択したアクセスコンセントレータが確認パケットを送信する構成されています。ホストが確認パケットを受信すると、PPPセッションステージに進むことができます。アクセスコンセントレータが確認パケットを送信すると、それはPPPセッションステージに進むことができます。
All Discovery Ethernet frames have the ETHER_TYPE field set to the value 0x8863.
すべてのディスカバリーイーサネットフレームは、値0x8863に設定ETHER_TYPEフィールドを持っています。
The PPPoE payload contains zero or more TAGs. A TAG is a TLV (type-length-value) construct and is defined as follows:
PPPoEのペイロードは、ゼロ以上のタグが含まれています。 TAGは、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パケットを送信します。 CODEフィールドは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サービス名の正確に一つのタグを含まなければなりません。リレーセッションIDタグを追加するために、リレーエージェントのための十分な余地を残すように（PPPoEヘッダを含む）全体のPADIパケットは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を送ったホストのユニキャストアドレスです。 CODEフィールドは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パケットは、アクセスコンセントレータの名前、PADIの1、およびアクセスコンセントレータが提供する他のサービスを示す他のサービス名TAGの任意の数と同一のサービス名タグを含む1つのAC-nameタグを含まなければなりません。アクセスコンセントレータは、PADIにサービスを提供できない場合には、PADOに応じてはいけません。
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を受け取ることができます。ホストは、それが受信し、1つを選択するPADOパケットを調べます。選択は、AC-名前または提供されるサービスに基づくことができます。ホストは、それが選択したアクセスコンセントレータに1つのPADRパケットを送信します。 DESTINATION_ADDRフィールドは、PADOを送ったアクセスコンセントレータのユニキャストイーサネットアドレスに設定されています。 CODEフィールドは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サービス名の正確に一つのタグを含まなければなりません。
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.
アクセスコンセントレータは、PADRパケットを受信すると、PPPセッションを開始する準備をします。これは、PPPoEセッションのためのユニークなSESSION_IDを生成し、PADSパケットでホストに応答します。 DESTINATION_ADDRフィールドはPADRを送信したホストのユニキャストイーサネットアドレスです。 CODEフィールドは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パケットは、アクセスコンセントレータがPPPoEセッションを受け入れたその下でのサービス、およびその他のタグタイプの任意の数を示す、TAG_TYPEサービス名の正確に一つのタグが含まれています。
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.
アクセスコンセントレータはPADRにサービス名が気に入らない場合、それはTAG_TYPEサービス名、エラーのTAG（および他のタグタイプの任意の数）を含むPADSで返答しなければなりません。この場合、SESSION_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フィールドはユニキャストイーサネットアドレスで、CODEフィールドは0xa7に設定され、SESSION_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終端パケットがPADTを送信または受信後に送ってはいけません。 PPPピアはPPPoEセッションをダウンさせるためにPPPプロトコル自体を使用する必要がありますが、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のCODEは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.
イーサネット（登録商標）が1500オクテットの最大ペイロードサイズを有するので、最大受信・ユニット（MRU）オプションが1492よりも大きなサイズにネゴシエートしてはいけません、PPPoEヘッダは、6つのオクテットであり、PPPプロトコルIDは2つのオクテット、PPP MTUであります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.
アクセスコンセントレータはocassionallyセッションの状態を判断するために、ホストにエコー要求パケットを送信することが推奨されます。ホストが終了要求パケットを送信せずにセッションを終了した場合それ以外の場合は、アクセスコンセントレータは、セッションがなくなったと判断することができません。
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パケットとダブル待機期間です再送信する必要があります。これは、必要な数回繰り返されます。ホストがPADSパケットの受信を待機している場合は、同様のタイムアウトメカニズムは、ホストは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は、PPPオーバー・イーサネット（PPPoEの）で使用するためにIEEEによって割り当てられています。これらの値の使用および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）攻撃、サービス拒否から保護するために、アクセスコンセントレータはAC-Cookieのタグを利用することができます。アクセスコンセントレータは、一意PADR SOURCE_ADDRに基づいTAG_VALUEを再生することができるべきです。これを利用して、アクセスコンセントレータは、PADI SOURCE_ADDRが実際に到達可能であることを確認することができますし、そのアドレスの同時セッションを制限することができます。使用にどのようなアルゴリズムが定義されており、実装の詳細として残されていません。実施例[3]のみアクセス>コンセントレータに知られているキーを使用して、ホストMACアドレス上HMACです。 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.
多くのアクセスコンセントレータは、彼らが認証されていないエンティティに提供するサービスに関する情報を提供したくないでしょう。その場合、アクセスコンセントレータは、2つのポリシーのいずれかを採用する必要があります。これは、サービス名タグに基づいて要求を拒否していないし、常にそれに送られたTAG_VALUEを返すん。それともそれだけで（どんなサービスを示す）ゼロTAG_LENGTHとサービス名タグで要求を受け入れる必要があります。かつてのソリューションをお勧めします。
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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1998.
[3] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "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
[4]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月を見る：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月を。
Appendix A
付録A
TAG_TYPES and TAG_VALUES
TAG_TYPESとTAG_VALUES
0x0000 End-Of-List
0000リスト終了
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サービス名
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がゼロである場合、このタグは、任意のサービスが受け入れ可能であることを示すために使用されます。サービス名タグの使用例としては、ISP名またはクラスまたはサービスの品質を示すためです。
0x0102 AC-Name
0x0102 AC-名前
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.
このタグは、文字列を一意に他のすべてから、この特定のアクセスコンセントレータユニットを識別する次のことを示しています。これは商標、モデル、シリアル番号情報、又はボックスのMACアドレスを単にUTF-8表現の組み合わせであってもよいです。これは、NULL終端されていません。
0x0103 Host-Uniq
0x0103ホスト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.
このタグは、一意に特定のホスト要求（PADI又はPADR）へのアクセスコンセントレータの応答（PADOまたはPADS）を関連付けるためにホストによって使用されます。 TAG_VALUEホストが選択した任意の値と長さのバイナリデータです。これは、アクセスコンセントレータによって解釈されていません。ホストはPADIまたはPADRでホストUNIQタグを含んでいてもよいです。アクセスコンセントレータは、このタグを受信した場合、それは、関連するPADO又はPADS応答に修飾されていないタグを含まなければなりません。
0x0104 AC-Cookie
0x0104 AC-クッキー
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.
このタグは、（これがどのように動作するかの説明のためのセキュリティの考慮事項のセクションを参照）、サービス拒否攻撃からの保護を支援するために、アクセスコンセントレータによって使用されます。アクセスコンセントレータは、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であり、割り当てられた番号RFCに定義されるように、下位3オクテットは、ネットワークバイト順におけるベンダのSMIネットワーク管理プライベート企業コードである[4]。
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は、ホストとアクセスコンセントレータの両方に不透明です。ホストまたはアクセスコンセントレータのいずれかが、このタグを受け取った場合、彼らは応答として送信するすべてのディスカバリパケットに変更されていないことを含まなければなりません。すべての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.
ディスカバリパケットは、すでに1が含まれている場合、リレーセッションIDタグを追加してはなりません。その場合、中間エージェントは、既存のリレーセッションIDタグを使用すべきです。それは既存のタグを使用することはできませんか、リレーセッションIDタグを追加するのに十分な余裕がある場合、それは送信者にジェネリック・エラータグを返すべきです。
0x0201 Service-Name-Error
0x0201サービス名、エラー
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文字列である必要があります。この文字列はNULL終端されない場合があります。
0x0202 AC-System-Error
0x0202 AC-システム・エラー
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.
このタグは、アクセスコンセントレータがホストの要求を実行する際に、いくつかのエラーを経験したことを示しています。 （たとえば、仮想回線を作成するのに十分なリソース。）これは、PADSパケットに含まれるかもしれません。
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文字列である必要があります。この文字列はNULL終端されない場合があります。
0x0203 Generic-Error
0x0203ジェネリック-エラー
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文字列である必要があります。この文字列はNULL終端されてはなりません。
Appendix B
付録B
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
ルイMamakos UUNET Technologies社3060ウィリアムズドライブフェアファックス、VAアメリカの22031から4648米国
EMail: louie@uu.net
メールアドレス：louie@uu.net
Kurt Lidl UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031-4648 United States of America
クルトLidlのUUNET Technologies社3060ウィリアムズドライブフェアファックス、VAアメリカの22031から4648米国
EMail: lidl@uu.net
メールアドレス：lidl@uu.net
Jeff Evarts UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031-4648 United States of America
ジェフEvarts UUNET Technologies社3060ウィリアムズドライブフェアファックス、VAアメリカの22031から4648米国
EMail: jde@uu.net
メールアドレス：jde@uu.net
David Carrel RedBack Networks, Inc. 1389 Moffett Park Drive Sunnyvale, CA 94089-1134 United States of America
デビッド・カレルレッドバックネットワークス株式会社1389年モフェットパークドライブサニーベール、CAアメリカの94089から1134米国
EMail: carrel@RedBack.net
メールアドレス：carrel@RedBack.net
Dan Simone RedBack Networks, Inc. 1389 Moffett Park Drive Sunnyvale, CA 94089-1134 United States of America
ダン・シモーネレッドバックネットワークス株式会社1389年モフェットパークドライブサニーベール、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
アメリカのロス・ウィーラーのRouterware株式会社3961マッカーサーブルバード、スイート212ニューポートビーチ、CA 92660米国
EMail: ross@routerware.com
メールアドレス：ross@routerware.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。