RFC2516 日本語訳
2516 A Method for Transmitting PPP Over Ethernet (PPPoE). L. Mamakos,K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. February 1999. (Format: TXT=32537 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Mamakosがコメントのために要求するワーキンググループL.をネットワークでつないでください: 2516年のK.Lidlカテゴリ: 情報のJ.のInc.D.個人閲覧室D.シモンエバーツUUNET技術20ドル紙幣はInc.1999年2月にInc.R.車で運ぶ人RouterWareをネットワークでつなぎます。
A Method for Transmitting PPP Over Ethernet (PPPoE)
イーサネットの上にpppを伝えるためのメソッド(PPPoE)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(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のために定義される施設を提供することを意図します、Link Controlプロトコルや、Network-層のControlプロトコルや、認証や、その他などのように。 これらの能力は、同輩の間の二地点間関係を必要として、イーサネットと他のマルチアクセス環境で利用可能なマルチポイント関係のために設計されていません。
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セッションか以上へのイーサネットがモデムをブリッジして、共有されたaの複数のホストがこの仕様を使用できます。イーサネットトポロジーであるとブリッジされたaを提供する広帯域の遠隔アクセスの技術で使用されるのは意図しています、セッション抽象化を維持するというアクセスプロバイダー願望がPPPと交際したとき。
Mamakos, et. al. Informational [Page 1] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[1ページ]のRFC2516
This document describes the PPP Over Ethernet encapsulation that is being deployed by RedBack Networks, RouterWare, UUNET and others.
このドキュメントはRedBack Networks、RouterWare、UUNET、および他のものによって配布されているPPP Overイーサネットカプセル化について説明します。
1. Introduction
1. 序論
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.
イーサネット(PPPoE)の上のPPPは簡単なブリッジしているアクセスデバイスの上にホストのネットワークを接続する能力をリモートAccess Concentratorに供給します。 このモデルと共に、各ホストはそれの自身の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はこれを提供する発見プロトコルを含んでいます。
2. Conventions
2. コンベンション
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]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
3. Protocol Overview
3. プロトコル概要
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 Sessionステージがあります。 HostがPPPoEセッションを開始したがっているとき、それは、最初に、同輩のイーサネットMACアドレスを特定して、PPPoE SESSION_IDを証明するためにディスカバリーを実行しなければなりません。 PPPはピアツーピア関係を定義しますが、本来ディスカバリーはクライアント/サーバー関係です。 ディスカバリープロセスでは、Host(クライアント)はAccess Concentrator(サーバ)を発見します。 ネットワーク形態に基づいて、Hostがコミュニケートできる1Access Concentratorがあるかもしれません。 ディスカバリーステージで、HostはすべてのAccess Concentratorsを発見して、次に、1つを選択します。 いつのディスカバリーが完成するか、首尾よく、Hostと選択されたAccess Concentratorの両方には、彼らがイーサネットの上の彼らの二地点間接続を組み込むのに使用する情報があります。
Mamakos, et. al. Informational [Page 2] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[2ページ]のRFC2516
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セッションがいったん確立されると、HostとAccess Concentratorの両方がPPP仮想インターフェースのためのリソースを割り当てなければなりません。
4. Payloads
4. 有効搭載量
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地_ADDR| | (6つの八重奏) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_ADDR| | (6つの八重奏) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETHER_TYPE(2つの八重奏)| +++++++++++++++++~~~ペイロード~~~+++++++++++++++++| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
ADDRがさばく_がそうしなければならないSOURCEはソースデバイスのイーサネットMACアドレスを含んでいます。
The ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864 (PPP Session Stage).
ETHER_TYPEは0×8863へのセット(発見Stage)か0×8864(PPP Session Stage)です。
Mamakos, et. al. Informational [Page 3] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[3ページ]のRFC2516
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| コード| セッション_ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| ペイロード~+++++++++++++++++++++++++++++
The VER field is four bits and MUST be set to 0x1 for this version of the PPPoE specification.
VER分野を4ビットであり、PPPoE仕様のこのバージョンのために0×1に設定しなければなりません。
The TYPE field is four bits and MUST be set to 0x1 for this version of the PPPoE specification.
TYPE分野を4ビットであり、PPPoE仕様のこのバージョンのために0×1に設定しなければなりません。
The CODE field is eight bits and is defined below for the Discovery and PPP Session stages.
CODE分野は、8ビットであり、以下でディスカバリーとPPP Sessionステージと定義されます。
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セッションのために修理されていて、事実上、イーサネット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.
LENGTH分野は16ビットです。 ネットワークバイトオーダーでは、値はPPPoEペイロードの長さを示します。 それはイーサネットかPPPoEヘッダーの長さを含んでいません。
5. Discovery Stage
5. 発見ステージ
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セッションを一緒に唯一定義しますか? ステップはInitiationパケット(Offerパケット、ユニキャストSession Requestパケットを送るHost、および選択されたAccess ConcentratorにConfirmationパケットを送らせる1Access Concentrators)を放送するHostから成ります。 HostがConfirmationパケットを受けるとき、それはPPP Session Stageに続くかもしれません。 Access ConcentratorがConfirmationパケットを送るとき、それはPPP Session Stageに続くかもしれません。
All Discovery Ethernet frames have the ETHER_TYPE field set to the value 0x8863.
すべてのディスカバリーイーサネットフレームで、ETHER_TYPE分野を値0x8863に設定します。
Mamakos, et. al. Informational [Page 4] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[4ページ]のRFC2516
The PPPoE payload contains zero or more TAGs. A TAG is a TLV (type- length-value) construct and is defined as follows:
PPPoEペイロードはゼロか、より多くのTAGsを含んでいます。 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 ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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のTAGと共にパケットを受け取ります、TAG MUST。別の方法で本書では指定されない場合、無視されてください。 新しいTAGsが加えられるとき、これは/であるなら後方に互換性に備えます。 新しい義務的なTAGsが加えられると、バージョン番号は増加されるでしょう。
Some example Discovery packets are shown in Appendix B.
いくつかの例のディスカバリーパケットがAppendix Bで見せられます。
5.1 The PPPoE Active Discovery Initiation (PADI) packet
5.1 PPPoE ActiveディスカバリーInitiation(PADI)パケット
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.
HostはADDRが放送演説に設定するDESTINATION_があるPADIパケットを送ります。 CODE分野は0×09に設定されます、そして、SESSION_IDを0×0000に設定しなければなりません。
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-名前の1TAGを含まなければなりません、Hostが要求しているサービス、および他のいろいろなTAGタイプを示して。 全体のPADIパケット(PPPoEヘッダーを含んでいる)は、中継エージェントがRelayセッションイドを加えることができるくらいの余地をTAGに残すために1484の八重奏を超えてはいけません。
5.2 The PPPoE Active Discovery Offer (PADO) packet
5.2 PPPoE ActiveディスカバリーOffer(PADO)パケット
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.
Access Concentratorがそれが役立つことができるPADIを受けるとき、それは、PADOパケットを送ることによって、返答します。 DESTINATION_ADDRはPADIを送ったHostのユニキャストアドレスです。 CODE分野は0×07に設定されます、そして、SESSION_IDを0×0000に設定しなければなりません。
Mamakos, et. al. Informational [Page 5] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[5ページ]のRFC2516
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パケットはAccess Concentratorの名前を含む1交流名のTAG、PADIのものと同じService-名前TAG、およびAccess Concentratorが提供する他のサービスを示す他のいろいろなService-名前TAGsを含まなければなりません。 Access ConcentratorがPADIに役立つことができないなら、それはPADOと共に応じてはいけません。
5.3 The PPPoE Active Discovery Request (PADR) packet
5.3 PPPoE ActiveディスカバリーRequest(PADR)パケット
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が放送されたので、Hostは1PADOを受けるかもしれません。 Hostはそれが受けるPADOパケットに目を通して、1つを選びます。 選択は交流名か提供されたServicesに基づくことができます。 そして、Hostは1つのPADRパケットをそれが選んだAccess Concentratorに送ります。 DESTINATION_ADDR分野はPADOを送ったAccess Concentratorのユニキャストイーサネットアドレスに設定されます。 CODE分野は0×19に設定されます、そして、SESSION_IDを0×0000に設定しなければなりません。
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-名前の1TAGを含まなければなりません、Hostが要求しているサービス、および他のいろいろなTAGタイプを示して。
5.4 The PPPoE Active Discovery Session-confirmation (PADS) packet
5.4 PPPoE ActiveディスカバリーSession-確認(PADS)パケット
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 ConcentratorがPADRパケットを受けるとき、それは、PPPセッションを始めるのを準備します。 それは、PPPoEセッションのためにユニークなSESSION_がIDであると生成して、PADSパケットでHostに答えます。 DESTINATION_ADDR分野はPADRを送ったHostのユニキャストイーサネットアドレスです。CODE分野は0×65に設定されます、そして、このPPPoEセッションのために生成されたユニークな値にSESSION_IDを設定しなければなりません。
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-名前の1TAGを含んでいます、そして、どのAccess Concentratorの下でサービスを示すかと、PPPoEセッションは受け入れられました、そして、他のいろいろなTAGがタイプします。
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 ConcentratorがPADRのService-名前が好きでないなら、PADSがTAG_TYPE Service-名前誤りのTAGを含んでいて、それは返答しなければなりません(他のいろいろなTAGがタイプします)。 この場合、SESSION_IDを0×0000に設定しなければなりません。
5.5 The PPPoE Active Discovery Terminate (PADT) packet
5.5 PPPoE ActiveディスカバリーTerminate(PADT)パケット
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セッションが終えられたのを示すためにセッションを確立した後にいつでもこのパケットを送るかもしれません。 それはHostかAccess Concentratorのどちらかによって送られるかもしれません。 DESTINATION_ADDR分野はユニキャストイーサネットアドレスです、そして、CODE分野は0xa7に設定されます、そして、どのセッションが終えられるかことであるかを示すようにSESSION_IDを設定しなければなりません。 TAGsは全く必要ではありません。
Mamakos, et. al. Informational [Page 6] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[6ページ]のRFC2516
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トラフィックでも、そのセッションを使用できません。 PADTを送るか、または受けた後に、正常なPPP終了パケットさえ送ってはいけません。 PPP同輩SHOULDは、PPPoEセッション、しかし、PADT MAYを降ろすのにPPPプロトコル自体を使用します。PPPを使用できないとき、使用されます。
6. PPP Session Stage
6. pppセッションステージ
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分野は0×8864に設定されます。 PPPoE CODEは0×00に用意ができなければなりません。 SESSION_IDは、そのPPPoEセッションのために変化してはいけなくて、ディスカバリー段階で割り当てられた値であるに違いありません。 PPPoEペイロードはPPPフレームを含んでいます。 フレームはPPP Protocol IDと共に始まります。
An example packet is shown in Appendix B.
例のパケットはAppendix Bで見せられます。
7. LCP Considerations
7. LCP問題
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:
マジックNumber LCP設定オプションはRECOMMENDEDです、そして、プロトコルField Compression(PFC)オプションはNOT RECOMMENDEDです。 実装は、以下のオプションのどれかを要求してはいけなくて、そのようなオプションを求める要求を拒絶しなければなりません:
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.
Maximumがユニットを受けている(MRU)オプションを1492年より大きいサイズと交渉してはいけません。 イーサネットには1500の八重奏の最大積載量サイズがあるので、PPPoEヘッダーは6つの八重奏です、そして、PPP Protocol IDは2つの八重奏です、PPP MTU MUST NOT。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.
Access Concentrator ocassionallyがセッションの状態を決定するためにEcho-リクエスト・パケットをHostに送るのは、RECOMMENDEDです。 さもなければ、HostがTerminate-リクエスト・パケットを送らないでセッションを終えると、Access Concentratorは、セッションが遠ざかったことを決定できないでしょう。
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が終わると、HostとAccess集中装置は、そのPPPoEセッションを使用するのを止めなければなりません。 Hostが別のPPPセッションを始めたいと思うなら、それはPPPoEディスカバリー舞台に戻らなければなりません。
Mamakos, et. al. Informational [Page 7] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[7ページ]のRFC2516
8. Other Considerations
8. 他の問題
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パケットを受けてください、それ。SHOULDはそれのPADIパケットを再送して、待ちの期間を倍にします。 これは必要な同じくらい何回も繰り返されます。 Hostが待っているなら、PADSパケット、同様のタイムアウトメカニズムSHOULDを受け取るのに、使用されてください、HostがPADRを再送していて。次に、指定された数の再試行の後に、Host SHOULDは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.
PPP Overイーサネット(PPPoE)によってこのドキュメント(0×8863と0×8864)で使用されるETHER_TYPEsは使用のために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]を見てください。
9. Security Considerations
9. セキュリティ問題
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 Concentratorは交流クッキーTAGを使うことができます。 唯一PADR SOURCE_ADDRに基づくTAG_VALUEは作り直すことができてください。Access Concentrator SHOULD、これを使用して、Access Concentratorは本当に、PADI SOURCE_ADDRが届いていて、次に、そのアドレスのための同時発生のセッションを制限できるのを確実にすることができます。 どんなアルゴリズムを使用したらよいかは、実装の詳細として定義されて、残されません。 例はAccess>Concentratorだけにおいて知られているキーを使用するHost MACアドレスの上のHMAC[3]です。 交流クッキーがいくつかのDOS攻撃に対して役に立つ間、すべてのDOS攻撃から守ることができるというわけではありません、そして、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攻撃に対して役に立つ間、すべてのDOS攻撃から守ることができるというわけではありません、そして、Access Concentratorはリソースを保護する他の手段を使うかもしれません。
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 Concentratorsは情報を提供したくならないでしょう。 その場合、Access Concentratorは2つの方針の1つを使うはずです。 それ、SHOULDはService-名前TAGに基づく要求を決して拒否しないで、いつもそれに送られたTAG_VALUEを返します。 それ、SHOULDはゼロがあるService-名前TAG TAG_LENGTHとの要求を受け入れるだけです(どんなサービスも示して)。 前のソリューションはRECOMMENDEDです。
10. Acknowledgments
10. 承認
This document is based on concepts discussed in several forums, including the ADSL forum.
このドキュメントはADSLフォーラムを含むいくつかのフォーラムで議論した概念に基づいています。
Mamakos, et. al. Informational [Page 8] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[8ページ]のRFC2516
Copious amounts of text have been stolen from RFC 1661, RFC 1662 and RFC 2364.
豊富な量のテキストがRFC1661、RFC1662、およびRFC2364から盗まれました。
11. References
11. 参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、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.ポステル、「規定番号」、STD2、RFC1700、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、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
Mamakos, et. al. Informational [Page 9] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[9ページ]のRFC2516
Appendix A
付録A
TAG_TYPES and TAG_VALUES
タグ_タイプとタグ_値
0x0000 End-Of-List
リストの0×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は、リストにはTAGsがこれ以上ないのを示します。 TAG_LENGTH、いつもこのTAG MUSTでは、ゼロになってください。 このTAGの使用は必要でなく、後方に唯一の残りは互換性です。
0x0101 Service-Name
0×0101 サービス名
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は、サービス名が従うのを示します。 TAG_VALUEはUTF-8ストリングです、すなわち、NOT NULLが終わりました。 TAG_LENGTHがゼロであるときに、このTAGは、どんなサービスも許容できるのを示すのに使用されます。 Service-名前TAGの使用に関する例はISP名、クラスまたはサービスの質を示すことです。
0x0102 AC-Name
0×0102交流名
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.
このTAGは、ストリングが続くのを示します(唯一すべての他のものからのこの特定のAccess Concentratorユニットを特定します)。 それは、商標、モデル、および連続のイド情報の組み合わせ、または単に箱のMACアドレスのUTF-8表現であるかもしれません。 それは終えられたNULLではありません。
0x0103 Host-Uniq
0×0103 ホスト-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.
このTAGは、唯一、特定のHostへの(PADOかPADS)が要求するAccess Concentrator応答(PADIかPADR)を関連づけるのにHostによって使用されます。 TAG_VALUEはHostが選ぶどんな値と長さのバイナリ・データです。 それはAccess Concentratorによって解釈されません。 HostはPADIかPADRにHost-Uniq TAGを含むかもしれません。Access ConcentratorがこのTAGを受けるなら、それは関連PADOかPADS応答で変更されていないTAGを含まなければなりません。
0x0104 AC-Cookie
0×0104交流クッキー
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.
このTAGは、サービス不能攻撃から守る際に支援するのにAccess Concentratorによって使用されます(これがどう働くかに関する説明に関してSecurity Considerations部を見てください)。 Access ConcentratorはPADOパケットにこのTAGを含むかもしれません。 HostがこのTAGを受けるなら、それは以下のPADRで変更されていないTAGを返さなければなりません。TAG_VALUEはどんな値と長さのバイナリ・データでありも、Hostによって解釈されません。
Mamakos, et. al. Informational [Page 10] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[10ページ]のRFC2516
0x0105 Vendor-Specific
0×0105ベンダー詳細
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は、ベンダー知的財産情報を通過するのに使用されます。 TAG_VALUEの最初の4つの八重奏がベンダーイドを含んでいます、そして、残りは不特定です。 ベンダーイドの高位八重奏は0です、そして、下位の3つの八重奏がネットワークバイトオーダーにおけるVendorのSMI Network Management兵士のエンタープライズCodeです、Assigned民数記RFC[4]で定義されるように。
Use of this TAG is NOT RECOMMENDED. To ensure inter-operability,
an implementation MAY silently ignore a Vendor-Specific TAG.
このTAGの使用はNOT RECOMMENDEDです。 相互運用性を確実にするために、実装は静かにVendor特有のTAGを無視するかもしれません。
0x0110 Relay-Session-Id
0×0110リレーセッションイド
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 MAY、トラフィックをリレーしている仲介物質によってあらゆる発見パケットに加えられてください。 TAG_VALUEはHostとAccess Concentratorの両方に不透明です。 HostかAccess ConcentratorのどちらかがこのTAGを受けるなら、彼らは彼らが応答として送るどんな発見パケットでも変更されていなかった状態でそれを含まなければなりません。 すべてのPADIパケットが12の八重奏のTAG_VALUEの長さでRelayセッションイドTAGの追加の十分なスペースを保証しなければなりません。
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.
RelayセッションイドTAG MUST NOT、発見パケットが既に1つを含むなら、加えられてください。 その場合、仲介物質SHOULDは既存のRelayセッションイドTAGを使用します。 既存のTAGを使用できないか、RelayセッションイドTAGを加える不十分な余地があって、次に、それが送付者へのSHOULDリターンa Generic-誤りTAGであるなら。
0x0201 Service-Name-Error
0×0201 サービス名前誤り
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.
このTAG(通常、ゼロ・レングス資料課がある)は、何らかの理由に関して、要求されたService-名前要求を光栄に思うことができなかったのを示します。
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
0×0202交流システム・エラー
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.
このTAGは、Access ConcentratorがHostが要求する実行における何らかの誤りを経験したのを示します。 (仮想の回路を作成する例えば、不十分なリソース。) それはPADSパケットに含まれるかもしれません。
Mamakos, et. al. Informational [Page 11] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[11ページ]のRFC2516
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
0×0203 ジェネリック誤り
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.
このTAGは誤りを示します。 回復不能エラーがいつ起こるか、そして、他の誤りがないTAGが適切であるとPADO、PADRまたはPADSパケットに言い足すことができます。 データがあれば、それは誤りの本質がわかるUTF-8ストリングであるに違いありません。 このストリングは終えられたNULLであるはずがありません。
Mamakos, et. al. Informational [Page 12] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[12ページ]のRFC2516
Appendix B
付録B
The following are some example packets:
↓これはいくつかの例のパケットです:
A PADI packet:
PADIパケット:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| _mac_addrを接待してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホスト_mac_addr(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エーテル_は=0x8863をタイプします。| =1に対して| t=1| コード=0x09| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション_ID=0x0000| 長さ=0×0004| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ_タイプ=0x0101| タグ_長さ=0×0000| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mamakos, et. al. Informational [Page 13] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[13ページ]のRFC2516
A PADO packet:
PADOパケット:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _mac_addrを接待してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホスト_mac_addr(cont)| _アクセス_集中装置mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アクセス_集中装置_mac_addr(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エーテル_は=0x8863をタイプします。| =1に対して| t=1| コード=0x07| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション_ID=0x0000| 長さ=0×0020| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ_タイプ=0x0101| タグ_長さ=0×0000| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグ_タイプ=0x0102| タグ_長さ=0×0018| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×47| 0x6f| 0×20| 0×52| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×65| 0×64| 0×42| 0×61| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×63| 0x6b| 0×20| 0x2d| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×20| 0×65| 0×73| 0×68| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×73| 0×68| 0×65| 0×73| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×68| 0x6f| 0x6f| 0×74| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mamakos, et. al. Informational [Page 14] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[14ページ]のRFC2516
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ペイロードは読者に任せます。 HostからAccess Concentratorまでこれはパケットです。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _アクセス_集中装置mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_アクセス_集中装置mac_addr(c)| _mac_addrを接待してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホスト_mac_addr(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エーテル_は=0x8864をタイプします。| =1に対して| t=1| コード=0x00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション_ID=0x1234| 長さ=0x? | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pppプロトコル=0xc021| PPPペイロード~+++++++++++++++++++++++++++++
Authors' Addresses
作者のアドレス
Louis Mamakos UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031-4648 United States of America
ルイスMamakos UUNET Technologies Inc.3060ウィリアムズ・Driveヴァージニア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 Inc.3060ウィリアムズ・Driveヴァージニア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
ジェフエバーツUUNET Technologies Inc.3060ウィリアムズ・Driveヴァージニア22031-4648フェアファクス(アメリカ合衆国)
EMail: jde@uu.net
メール: jde@uu.net
Mamakos, et. al. Informational [Page 15] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[15ページ]のRFC2516
David Carrel RedBack Networks, Inc. 1389 Moffett Park Drive Sunnyvale, CA 94089-1134 United States of America
デヴィッド個人閲覧室20ドル紙幣ネットワークInc.1389モフェット・公園Driveカリフォルニア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
ダンシモン20ドル紙幣ネットワークInc.1389モフェット・公園Driveカリフォルニア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 Inc.3961マッカーサーBlvd.、Suite212ニューポートビーチ、カリフォルニア92660アメリカ合衆国
EMail: ross@routerware.com
メール: ross@routerware.com
Mamakos, et. al. Informational [Page 16] RFC 2516 Transmitting PPP Over Ethernet February 1999
et Mamakos、アル。 1999年2月にイーサネットの上にpppを伝える情報[16ページ]のRFC2516
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Mamakos, et. al. Informational [Page 17]
et Mamakos、アル。 情報[17ページ]
一覧
スポンサーリンク
