このドキュメントはRFC2516 Method for Transmitting PPP Over Ethernet (PPPoE
を弊社が日本語に翻訳したものです。このRFCの内容に関してのお問い合わせは受け付け
ておりません。ご了承下さい。
ネットワークワーキンググループ L. Mamakos
Request for Comments: 2516 K. Lidl
カテゴリー: 情報通達 J. Evarts
UUNET Technologies, Inc.
D. Carrel
D. Simone
RedBack Networks, Inc.
R. Wheeler
RouterWare, Inc.
February 1999
PPP Over Ethernet (PPPoE)パケットの伝達手法
このメモの位置付け
このメモはインターネットコミュニティに対して情報を提供するために作成されています。
いかなるインターネットの標準を定めるものではありません。このメモの配布には制限があり
ません。
著作権に関して
複製権はインターネットソサエティが有します。すべての権利は保護されています。
Copyright (C) The Internet Society (1999). All Rights Reserved.
要約
Point-to-Point プロトコル(PPP) [1] は、ポイントツーポイントで接続されたリンク上を
マルチプロトコルのデータグラムを転送する標準的な手法です。
このドキュメントでは、イーサネット上でのPPPセッションの確立およびPPPパケットのカプ
セル化の手法に関して記述しています。
応用
ここで述べられる仕様は、リンクコントロールプロトコル、ネットワークレイヤープロトコ
ル、認証などのPPPに関して定義されている機能の提供を目的としています。これらの機能は、
ピアツーピア間でのポイントツーポイント接続を必要としイーサネットや他のマルチポイント
アクセス環境で用いられるマルチポイントの接続向けにデザインされたものではありません。
この仕様は、イーサネットに接続された複数のホストにより使用することが可能で、１つかそ
れ以上のブリッジ接続されたモデムを介して複数の送信先に対してPPPセッションをオープンす
るために用いられます。アクセスプロバイダーが、関連するPPPのセッションの保持を行ないた
い場合に、イーサネットトポロジーのブリッジ接続機能を提供するブロードバンドリモートア
クセス技法をとともに使用されることを意図しています。
Mamakos, et. al. Informational [Page 1]
RFC 2516 Transmitting PPP Over Ethernet February 1999
このドキュメントでは、RedBack社、RouterWare社、UUNET等で展開されているPPP Over
Ethernet カプセル化に関して記述しています。
1. はじめに
最新アクセス技法は、いくつかの格闘すべき目標に直面しています。リモートサイトでカス
タマー固有のアクセスデバイスを介して複数のホストに接続することが望まれています。また、
PPPを使ったダイアルアップサービスと同様の方法でアクセス制御および課金機能を実現させ
るのもその望まれるゴールです。様々なアクセス技法において、カスタマー固有のアクセスデ
バイスと複数のホストの接続を行なう最も経済的な方法はイーサネットを使うことです。さら
に、そのデバイスの設定の省力化と同様可能な限りデバイスのコストを低く抑える事が望まれ
ます。
PPP over Ethernet (PPPoE) を使って、簡単なブリッジングアクセスデバイス上のホストの
ネットワークとリモートにあるAccess Concentratorと接続することができます。この手法で、
各ホストはそれぞれのPPPスタックを利用しユーザーに対してなじみのユーザーインタフェース
を提供することが可能です。アクセスコントロール、課金機能およびサービスタイプは、基本的
にサイト別というよりもユーザー上で実現されます。
イーサネットを介してポイントツーポイントの接続を提供するために、各PPPセッションはユ
ニークなセッション識別子の確立と同様リモートピアのイーサネットアドレスの学習を行わな
ければなりません。PPPoEには、この機能を実現するディスカバリプロトコルが含まれます。
2. 解釈
しなければならない (MUST)、してはならない (MUST NOT)、要求される (REQUIRED)、するこ
とになる (SHALL)、することはない (SHALL NOT)、する必要がある (SHOULD)、しないほうが
よい(SHOULD NOT)、推奨される (RECOMMENDED)、してもよい (MAY)、選択できる (OPTIONAL)
の語句がこのドキュメント内で記述されている場合、[2]での記述に沿って解釈されものと
します。
3. プロトコル概要
PPPoEには、ディスカバリステージとPPPセッションステージの２つの異なるステージがあります。
ホストがPPPoEステージを開始する場合、ピアのイーサネットMACアドレスの識別とPPPoE SESSI
ON_IDを確立するため最初にディスカバリステージを実行しなければなりません。PPPがピアツー
ピアの関係を設定している間、ディスカバリはclient-server の関係を踏襲します。ディスカバ
リプロセスにおいて、ホスト（クライアント）はAccess Concentrator（サーバ）を検索します。
ネットワークトポロジーに基づいてホストが接続できるAccess Concentratorは１つ以上存在しま
す。ディスカバーステージではホストはすべてのAccess Concentratorを検索しそのうちの１つを
選択します。ディスカバリステージが問題なく完了すれば、ホストと選択されたAccess Concentr
atorの両方ともイーサネット上をポイン
トツーポイントの接続を確立するために使用された情報を所有します。
Mamakos, et. al. Informational [Page 2]
RFC 2516 Transmitting PPP Over Ethernet February 1999
ディスカバリステージは、PPPセッションが確立されるまで状態を保持しません。いったんPPPセッ
ションが確立されると、ホストとAccess ConcentratorはPPP仮想インタフェースのためのリソー
スをアロケートしなければなりません。
4. ペイロード（Payloads）
次のパケットのフォーマットはここで定義されます。ペイロードの内容はディスカバリとPPPのセ
クションで定義されています。
イーサネットフレームは以下のように構成されています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DESTINATION_ADDRフィールドには、ユニキャストイーサネットデスティネーションアドレス
もしくはイーサネットブロードキャストアドレス(0xffffffff)が含まれます。ディスカバリ
パケットに関して、その値はディスカバリセクションで定義されているようにユニキャストも
しくはブロードキャストのいずれかです。PPPセッショントラフィックに関して、ディスカバ
リステージで決定されるピアのユニキャストアドレスが含
まれてなければなりません。
SOURCE_ADDRフィールドにはソースデバイスのイーサネットMACアドレスが含まれます。
ETHER_TYPEは0x8863 (ディスカバリステージ) もしくは0x8864(PPPセッションステージ)の
値が設定されます。
Mamakos, et. al. Informational [Page 3]
RFC 2516 Transmitting PPP Over Ethernet February 1999
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VERフィールドは4ビット長で、ここで定義されるPPPoEのバージョンでは0x1に設定されます。
TYPEフィールドは4ビット長で、ここで定義されるPPPoEのバージョンでは0x1に設定されます。
CODEフィールドは8ビット長で、ディスカバリおよびPPPセッションステージのため以下で定義
されます。
SESSION_IDフィールドは、16ビット長で符号なしのネットワークバイトオーダーの値で表さ
れます。その値は、ディスカバリパケットのために以下に定義されます。値は、PPPセッション
ごとに固定で、実際にイーサネットのSOURCE_ADDRとDESTINATION_ADDRにしたがってPPPセッ
ションを定義します。0xffffは、未定義で使用することはできません。
LENGTHフィールドは16ビット長です。ネットワークバイトオーダーでPPPoEペイロードの長
さを表わします。これにはイーサネットもしくはPPPoEのヘッダー長は含まれません。
5. ディスカバリステージ（Discovery Stage）
ディスカバリステージには４つのステップがあります。すべてが完了すると、通信を行なう両
端のネットワーク機器は、PPPoEセッションでユニークに設定されたPPPoE SESSION_IDとイー
サネットアドレスを取得します。これらのステップは、ホストのInitiationパケットのブロー
ドキャスティング、１つか２つのアクセスコンセントレータからのOfferパケットの送信、ホ
ストからのSession Requestパケットのユニキャスト送信および選択されたアクセスコンセン
トレータからのConfirmationパケットの送信で構成されます。ホストがConfirmationパケット
を受信すると、PPPセッションステージが開始されます。アクセスコンセントレータが
Confirmationパケットを送信するとPPPセッションステージが開始されます。
すべてのディスカバリイーサネットフレームには、0x8863にセットされたETHER_TYPEフィールド
が含まれます。
Mamakos, et. al. Informational [Page 4]
RFC 2516 Transmitting PPP Over Ethernet February 1999
PPPoEペイロードは、ゼロもしくは複数のTAGがふくまれています。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は16ビット長のフィールドでネットワークバイトオーダーです。付録Aで、すべての
TAG_TYPEとTAG_VALUEを記述します。
TAG_LENGTHは16ビット長のフィールドです。ネットワークバイトオーダーの符号なしの数字
でTAG_VALUEのオクテット数を表しています。
ディスカバリパケットが未知のTAG_TYPEで表されているTAGとして受け取られた場合、TAGは
このドキュメントで定義されたタイプが設定されるまで無視されます。この機能により新た
なTAGが追加された場合の下位互換が保たれます。新たなTAGが追加された場合、バージョン
ナンバーは１増分されます。
ディスカバリパケットのサンプルは付録Bを参照ください。
5.1 PPPoEのActive Discovery Initiation (PADI)パケット
ホストは、DESTINATION_ADDRフィールドにブロードキャストアドレスを設定しPADIパケット
を送信します。CODEフィールドは0x09に設定されSESSION_IDは0x0000でなければなりません。
PADIパケットには、ホストが要求したサービスを示すTAG_TYPE Service Nameが正確に記述
されたTAGと他のタイプが記述されたTAGが含まれます。リレーエージェントがRelay-Sessio
n-Id TAGを追加できる十分な領域を確保するため、PADIパケット全体（PPPoEヘッダーを含
む）は1484オクテットを越えてはいけません。
5.2 PPPoE Active Discovery Offer (PADO) パケット
Access Concentratorがサービス可能なPADIパケットを受信した場合、PADOパケットを送
信し応答します。DESTINATION_ADDRフィールドには、PADIパケットを送信したホストのユ
ニキャストアドレスがセットされます。CODEフィールドの値は0x07にセットされSESSION_
IDフィールドの値は0x0000でなければなりません。
Mamakos, et. al. Informational [Page 5]
RFC 2516 Transmitting PPP Over Ethernet February 1999
PADOパケットには、PADI内のService-Name TAGと一致するアクセスコンセントレータの名
前が含まれた１つのAC-Name TAGと、アクセスコンセントレータから提供される他のサービ
スを示すいくつかのService-Name TAG が含まれていなければなりません。Access Concen
tratorがPADIパケットをサービスできない場合、PADOパケットを返信してはいけません。
5.3 PPPoE Active Discovery Request (PADR) パケット
PADIパケットがブロードキャストの場合、ホストは1つ以上のPADOパケットを受け取ること
があります。ホストはPADOの内容を見て受信を行ない１つを選択します。その選択はAC-Nam
eもしくは提供されるServiceに基づいて判断することができます。ホストは１つのPADRパケ
ットを選択されたAccess Concentratorに送信します。DESTINATION_ADDRフィールドには、
PADOを送信したAccess Concentratorのユニキャストイーサネットアドレスがセットされま
す。CODEフィールドは0x19にセットされSESSION_IDフィールドの値は0x0000にセットされ
ていなければなりません。
PADRパケットは、ホストが要求したサービスを表す正確に記述されたTAG_TYPE Service-
NameのTAGと他のTAGタイプのTAGが含まれています。
5.4 PPPoE Active Discovery Session-confirmation (PADS) パケット
Access ConcentratorがPADRパケットを受け取った場合、PPPセッションの開始準備を行な
います。PPPoEセッションに対してユニークなSESSION_IDを生成しホストにPADSパケットを
送信し応答します。送信されるPADRパケットのDESTINATION_ADDRフィールドにはホストのユ
ニキャストイーサネットアドレスがセットされます。CODEフィールドは0x65にセットされSE
SSION_IDフィールドにはPPPoEセッションに対して生成されたユニークな値がセットされな
ければなりません。
PADSパケットには、Access Convcentratorが受け取ったPPPoEセッション下でのサービスを
示す正確に記述された１つのTAG_TYPE Service-NameのTAGと他のタイプのいくつかのTAGが
含まれます。
Access ConcentratorがPADRパケットに定義されたService-Nameを気に入らない場合、PADS
パケットのTAGのTAG-TYPEフィールドにService-Name-Error含めて返信しなければなりませ
ん。この場合、SESSION_IDは0x0000にセットされます。
5.5 PPPoE Active Discovery Terminate (PADT) パケット
このパケットは、セッションが確立された後PPPoEセッションが終了したことを示すためいつで
も送信することができます。ホストもしくはAccess Concentratorのどちらでも送信可能です。
DESTINATION_ADDRフィールドは、ユニキャストイーサネットアドレスで、CODEフィールドは0x
a7にセットされています。SESSION_IDは、終了したセッションを表しています。TAGは必要あ
りません。
Mamakos, et. al. Informational [Page 6]
RFC 2516 Transmitting PPP Over Ethernet February 1999
PADTパケットを受信した場合、セッションを使ってPPPトラフィックを送ることはできません。
通常のPPP終了パケットもPADT受信後送ることはできません。PPPピアはPPPoEを終了させるため
PPPプロトコルを使用しなければなりません。しかし、PPPが使用できない場合PADTを使用するこ
とができます。
6. PPPセッションステージ
いったんPPPoEが開始されると、PPPデータは他のPPPカプセル化と同様に送信されます。すべて
のイーサネットパケットはユニキャストです。ETHER_TYPEフィールドは0x8864にセットされて
います。PPPoE CODEフィールドは0x00にセットされなければなりません。SESSION_IDはPPPoE
セッションを変更してはいけません。また、その値はディスカバリステージで設定されたもので
なければなりません。PPPoEペイロードはPPPフレームを含みます。フレームはPPPのプロトコル
IDで始まります。
パケットのサンプルは付録Bに記述します。
7. LCPに関する考慮事項
マジックナンバーであるLCP設定オプションを用いることお勧めします。また、Protocol Field
Compression (PFC)オプションを使用することはお勧めできません。 この実装は次のいかなる
オプションを要求するものではありませんし、そのような要求を拒否しなければなりません。
Field Check Sequence (FCS) Alternatives,
Address-and-Control-Field-Compression (ACFC),
Asynchronous-Control-Character-Map (ACCM)
Maximum-Receive-Unit (MRU) オプションでは1492以上のサイズの要求を認めてはいけません。
イーサネット上でのペイロードの最大サイズは1500オクテット、PPPoEヘッダーは６オクテット
およびPPP Protocol IDは2オクテットであるため、PPP MTUは1492より小さくなければなりません。
セッションの状態を判断するためAccess Concentratorは随時ホストに対してEcho-Requestパ
ケットを送ることをお勧めします。このパケットが送られない場合、ホストはTerminate-Requ
estパケットを送ることなくセッションを終了するとAccess Concentratorはセッションが終了
したかどうかの判断をすることができません。
LCPが終了すると、ホストとAccess ConcentratorはPPPoEセッションの使用を停止しなければな
りません。ホストが新たにPPPセッションを開始したい場合は、PPPoEディカバリステージに戻る
必要があります。
Mamakos, et. al. Informational [Page 7]
RFC 2516 Transmitting PPP Over Ethernet February 1999
8. その他の考慮事項
ホストがある定められた時間内にPADOパケットを受け取らない場合、PADIパケットの再送を行
いまた定められた待ち時間を2倍に拡張しなければなりません。この手順は必要時間の間繰り返
し行なわれます。ホストがPADSパケットを待つ場合でも、同様のタイムアウトメカニズムを使
用しホストはPADRの再送を行ないます。一定の回数この再送を繰り返し行なった後、ホストは
PADIパケットを再送しなければなりません。
このドキュメントで使用されているETHER_TYPEは、PPP Over Ethernet（PPPoE）での使用に
関してIEEEによって定義されています。これらの値の使用とPPPoE VER（Version）フィールド
で、このプロトコルの識別が可能になります。
このドキュメントではASCIIの代わりにUTF-8 [5]が使用されています。UTF-8では、インター
ナショナルキャラクターセットの使用も可能であるのと同様にすべてのASCIIキャラクターセッ
トをサポートしています。詳細に関しては[5]を参照下さい。
9. セキュリティに関する考慮事項
DOSアタックに対する防御の補助としてAccess ConcentratorはAC-Cookie TAGを用います。
Access Concentratorは、PADRパケットのSOURCE_ADDRに基づくユニークなTAG_VALUEを再度
生成できなければなりません。これを用いて、Access ConcentratorはPADIパケットのSOURCE
_ADDRが実際に到達可能であることを確認することができしかもこのアドレスへの同時アクセス
数の制限を設定することが可能となります。これを使用するたのアルゴリズムに関して実装の
詳細は定義されておりません。 例えば、キーを用いたHMAC over the Host MAC addressは
Access Concentratorに対してのみとなります。
AC-CookieがいくつかのDOSアタックに有効である間、すべてのDOSアタックを防ぐことはでき
ません。また、Access Concentratorはリソースを保護するために他の手段を採用する場合が
あります。
ほとんどのAccess Concentratorは、認証されていないものに対してサービスを提供するため
の情報の提供を望みません。その場合、Access Concentratorは１つか２つのポリシーを採用
する必要があります。Service-Name TAGに基づくリクエストを拒否してはいけません。必ず
送られたTAG_VALUEを返さなければなりません。もしくは、TAG_LENGTHがゼロ（あらゆるサー
ビスを示す）のService-Name TAGのリクエストのみ受け付けます。前者の方法を推奨します。
10. 受信確認（Acknowledgments）
このドキュメントはADSL部会を含むいくつかの部会で議論されたコンセプトに基づいて記述さ
れています。
Mamakos, et. al. Informational [Page 8]
RFC 2516 Transmitting PPP Over Ethernet February 1999
テキストのほとんどの部分はRFC1661、RFC1662およびRFC2364から引用されています。
11. 参考文献（References）
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1998.
[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.
Mamakos, et. al. Informational [Page 9]
RFC 2516 Transmitting PPP Over Ethernet February 1999
付録 A（Appendix A）
TAG_TYPES と TAG_VALUES
0x0000 End-Of-List
このTAGは、このリストに上にこれ以上のTAGが存在しないことを表します。このTAGのTAG_LE
NGTHの値は常にゼロです。 このTAGは通常使用されませんが後方互換のため保持されています。
0x0101 Service-Name
このTAGは次に続くサービス名を表しています。TAG_VALUEは、NULLで終了しないUTF-8のキャ
ラクターセットを用いています。TAG_LENGTHがゼロの場合、このTAGはいかなるサービスでも
受け入れられることを示します。Service-Name TAGの使用例として、ISP名もしくはサービス
のクラスもしくは質の表示があります。
0x0102 AC-Name
このTAGでは、特定のAccess Concentratorユニットを他のすべてのユニットから識別すること
のできる文字列が次に続くことを示しています。トレードマーク、モデル名、シリアル番号情
報などの組み合わせ、もしくはMACアドレスのUTF-8表記で表される場合があります。NULLで区
切られることはありません。
0x0103 Host-Uniq
このTAGは、特定のホストリクエストに対して応答（PADOもしくはPADS）を行なうAccess Con
centratorにユニークに関連付けられたホストによって使用されます。TAG_VALUEはバイナリ
ーデータで データ長はホストが選択します。Access Concentratorによって解釈されること
はありません。ホストは、PADIもしくはPADRパケット中にHost-Uniq TAGを含める場合があり
ます。 Access ConcentratorがこのTAGを受け取った場合、関連するPADOもしくはPADSレス
ポンスパケットに このTAGを変更することなく含めなければありません。
0x0104 AC-Cookie
このTAGはDOSアタックからAccess Concentratorを防御するために使用されます。（このメカ
ニズムはセキュリティの考慮条件の項を参照して下さい。） Access ConcentratorはPADOパ
ケット中にこのTAGを含めることがあります。ホストがこのTAGを受け取った場合、内容を変更
することなくPADRに続いてこのTAGを返信しなければなりません。TAG_VALUEはバイナリーデー
タおよびデータ長でホストによって解釈されることはありません。
Mamakos, et. al. Informational [Page 10]
RFC 2516 Transmitting PPP Over Ethernet February 1999
0x0105 Vendor-Specific
このTAGはベンダー固有の情報を伝える場合に使用されます。TAG_VALUEの最初の４つのオクテ
ットはベンダーの識別子が含まれ残りは定義されていません。ベンダー識別子の上位オクテッ
ト部分はゼロで、下位の3オクテットはネットワークバイトオーダーでベンダーのSMI Network
Management Private Enterprise Codeが設定されます。符号付の数値で表されます。 RFC [4].
TAGの使用はお勧めできません。相互互換を保持するため、実装において、Vendor-Specific
TAGは考慮されておりません。
0x0110 Relay-Session-Id
このTAGは、トラフィックの中継を行なう中間エージェントによりいくつかのディスカバリパケッ
トに含まれる場合があります。TAG_VALUEは、ホストおよびAccess Concentratorに対して認識さ
れません。ホストもしくはAccess ConcentratorがこのTAGを受け取った場合、レスポンスとして
返信するディスカバリパケット中にこのTAGを変更することなく含めなくてはいけません。すべて
のPADIパケットは、TAG_VALUEが12オクテットのRelay-Session-Id TAGに対して十分な領域を
保証する必要があります。
Relay-Session-Id TAGがすでにディスカバリパケット中に１つが含まれている場合、新たに追
加してはいけません。この場合、中間エージェントは既存のRelay-Session-Id TAG を用いなけ
ればなりません。既存のRelay-Session-Id TAG が使用できないかもしくは追加する十分な領域
がない場合、送信元にGeneric-Error TAGを返信しなければなりません。
0x0201 Service-Name-Error
TAG (主にデータ長がゼロのセクション)は、要求されたService-Name リクエストが受け入れら
れない１つかもしくは別の理由を表します。
データがある場合でしかもデータの最初のオクテットはゼロではない場合、それは印刷可能なUTF
-8 の文字列でリクエストが拒否された理由を表しています。文字列はNULLコードで区切られない
場合があります。
0x0202 AC-System-Error
このTAGは、Access Concentratorがホストのリクエストを実行する際にエラーを検出したこと
を示します。(例えば、仮想サーキットを生成するための十分なリソースがない場合) このTAGは
PADSパケットに含まれる場合があります。
Mamakos, et. al. Informational [Page 11]
RFC 2516 Transmitting PPP Over Ethernet February 1999
データがある場合でしかもデータの最初のオクテットはゼロではない場合、それは印刷可能なUTF-8
の文字列でエラーの性質を表しています。文字列はNULLコードで区切られない場合があります。
0x0203 Generic-Error
このTAGはエラーを示しています。致命的なエラーでしかも適切なエラーTAGが無い場合、PADO、PAD
RもしくはPADSパケットに追加されます。データがある場合、印刷可能なUTF-8 の文字列でエラーの
性質を表しています。文字列はNULLコードで区切られません。
Mamakos, et. al. Informational [Page 12]
RFC 2516 Transmitting PPP Over Ethernet February 1999
付録 B（Appendix B）
次にパケットのフォーマットを示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mamakos, et. al. Informational [Page 13]
RFC 2516 Transmitting PPP Over Ethernet February 1999
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mamakos, et. al. Informational [Page 14]
RFC 2516 Transmitting PPP Over Ethernet February 1999
PPP LCP パケット: PPP プロトコル値は(0xc021)で表されますが、PPPペイロードはリーダーで
設定されます。このパケットはホストから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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
著者の住所
Louis Mamakos
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031-4648
United States of America
EMail: louie@uu.net
Kurt Lidl
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031-4648
United States of America
EMail: lidl@uu.net
Jeff Evarts
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031-4648
United States of America
EMail: jde@uu.net
Mamakos, et. al. Informational [Page 15]
RFC 2516 Transmitting PPP Over Ethernet February 1999
David Carrel
RedBack Networks, Inc.
1389 Moffett Park Drive
Sunnyvale, CA 94089-1134
United States of America
EMail: carrel@RedBack.net
Dan Simone
RedBack Networks, Inc.
1389 Moffett Park Drive
Sunnyvale, CA 94089-1134
United States of America
EMail:dan@RedBack.net
Ross Wheeler
RouterWare, Inc.
3961 MacArthur Blvd., Suite 212
Newport Beach, CA 92660
United States of America
EMail: ross@routerware.com
Mamakos, et. al. Informational [Page 16]
RFC 2516 Transmitting PPP Over Ethernet February 1999
著作権全文表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
このドキュメントおよびその翻訳物は、複写および配布が可能です。また、この文書に論評
や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれ
ば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布が可
能です。しかしながら、このドキュメント自体に対して、著作権表示やインターネット・ソサ
エティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはいけま
せん。インターネット標準化過程で定義されている著作権のための手続きに従って、インター
ネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合
はその限りではありません。
上記の制限は永続的なものであり、インターネット・ソサエティもしくはその継承者や譲渡者に
よって取り消されることはありません。.
このドキュメントとここに含まれた情報はいかなる変更を加えることもなく提供されます。イン
ターネット・ソサエティおよび IETF は、ここで示される情報の使用がいかなる権利をも侵害し
ないことの保証、商用目的や特定利用への適応性への保証を含めすべての保証を明示的にも暗黙
的にも行なうことはありません。
Mamakos, et. al. Informational [Page 17]