RFC-2516

注：　この資料はIEで閲覧ください。

イーサネットを介したPPP伝送法

A Method for Transmitting PPP Over Ethernet

Network Working Group

Request for Comments: 2516

Category: Informational

L. Mamakos, K. Lidl, J. Everts (UUNET Technologies, Inc.)

D. Carrel, D. Simone (RedBack Networks, Inc.)

R. Wheeler (RouterWare, Inc.)

February 1999

本メモのステータス (Status of this Memo)

このメモはインターネットコミュニティへの情報提供のためのものである。これは如何なるインターネットの標準を規定するものではない。このメモの配布には制限はない。

著作権 (Copyright Notice)

アブストラクト (Abstract)

ポイント対ポイントプロトコル(PPP: Point-to-Point Protocol)[1] はマルチプロトコルのデータグラムをポイント対ポイントのリンクを介して伝達する標準の方法を規定している。

このドキュメントは、イーサネット上で如何にPPPセッションを構築し、また如何にPPPパケットをカプセル化するかについて記したものである。

適用性 (Applicability)

本仕様はPPPに対し規定されているリンク制御プロトコル、ネットワーク層制御プロトコル、認証、その他の機能を提供することを意図している。これらの機能はピア間においてのポイント対ポイントの関係を必要とし、イーサネットやその他のマルチアクセスの環境で得られるマルチポイントの関係に対して設計されていない。

本仕様により、共有されたイーサネット上の複数のホストがひとつまたは複数のブリッジモデム(Bridging modem)を介して複数の相手にPPPセッションを開くことができる。これはブリッジで繋がったイーサネットのトポロジをもたらすブロードバンドのアクセス技術を使って、アクセスプロバイダたちがPPPに連結してセッションを維持したいときに採用されることを意図したものである。

1.　概要 (Introduction)

近年のアクセス技術は、幾つかの相反する目標に面している。複数のホストを同じ宅内アクセス装置でリモートのサイトに接続できることが好ましい。また、PPPを使ったダイヤルアップのサービスと同じやり方で、アクセス制御や課金の機能を持たせることも一つの目標である。多くのアクセス技術のなかで、複数のホストを宅内アクセス装置に接続するのに、一番コスト効率の高いのはイーサネットを介することである。加えて、この装置のコストを極力低く維持し、かつわずかな設定、あるいは設定作業なしとすることが好ましい。

PPPoEはPPP over Ethernetを略したものであり、ホストの網を簡単なブリッジ機能を持ったアクセス装置を通してリモートのアクセス集線装置(Access Concentrator)に接続する機能を有する。FTTHの場合は、宅内または近隣のゲートウエイ装置との接続機能になる。このモデルでは、各ホストは自分自身のPPPスタックを使い、ユーザは、使い慣れたユーザインターフェイス上で利用できる。アクセス制御、課金、及びサービスのタイプは、サイトごとのベースではなくユーザごとのベースでなされる。

イーサネット上でポイント対ポイントの接続をするために、各PPPセッションではリモートのピアのイーサネット・アドレス（MACアドレス）が、単一無二なセッション識別子とともに管理されることになる。PPPoEはこれを達成するディスカバリ・プロトコルを含む。

2.　規約 (Conventions)

本ドキュメントに使われているMUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONALなどのキーワードは[2]で規定されている規約にもとずいて解釈されること。

3.　プロトコルの概要 (Protocol Overview)

PPPoEは2つの区切られた段階(stage)をもつ。つまり、ディスカバリ(Discovery)とPPPセッション(PPP Session)の段階である。ホストがPPPoEセッションを開始しようとしたときは、ピアのイーサネットMACアドレスを特定しPPPoEのセッションID (PPP0E SESSION_ID)を確立するために、最初にディスカバリを実行しなければならない。PPPはピア対ピアの関係を定めているので、ディスカバリは本質的にクライアント対サーバの関係となる。このディスカバリのプロセスでは、ホスト（クライアント）はアクセス集線装置（サーバ）を探し出す。ネットワークのトポロジに基づけば、ホストがともに通信できるアクセス集線装置はひとつ以上存在し得る。ディスカバリ段階では、ホストが全部のアクセス集線装置を発見して、しかるのちひとつを選択することができる。ディスカバリが成功裏に終了すれば、ホストと選択されたアクセス集線装置は、イーサネット上でポイント対ポイント接続を確立するために使う情報を取得したことになる。このディスカバリ段階は状態無し（stateless）でPPPセッションが確立されるまで存続する。PPPセッションが確立されると、ホストとアクセス集線装置双方は、PPP仮想インターフェイス(PPP Virtual interface)のためこの資源を割り当てなければならない[MUST]。

4.　ペイロード (Payloads)

ここでは以下のパケットフォーマットを定める。ペイロードの中身はディスカバリとPPPセッションのセクションで別途定める。

イーサネットフレームは以下のとおりである。

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セッショントラフィックでは、このフィールドにはディスカバリ段階で特定されたピアのユニキャスト・アドレスが入らなければならない[MUST]。

SOURCE_ADDR（送信元アドレス）フィールドには送信元装置のイーサネットMACアドレスが入らなければならない[MUST]。

ETHER_TYPE（イーサネットタイプ）はディスカバリ段階では0x8863が、PPPセッションの段階では0x8864がセットされねばならない。

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| LENGTH | payload ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

VER（バージョン）フィールドは4ビットで、PPPoE仕様の本バージョンでは0x1にセットされねばならない[MUST]。

TYPE（タイプ）フィールドは4ビットで、PPPoE仕様の本バージョンでは0x1にセットされねばならない[MUST]。

CODE（コード）フィールドは8ビットで、以下のディスカバリ及びPPPセッション段階のところで定義されている。

SESSION_ID（セッションID）のフィールドは16ビット長である。これはネットワークバイト順の符号無し数値である。ディスカバリ・パケットに対してはこの値は以下に記されている。この値は与えられたPPPセッションでは固定され、イーサネット送信元アドレス、イーサネット宛先アドレスとともにPPPセッションを指定するものである。0xffffなる値は将来の為に予約されており、これを使ってはいけない。

LENGTH（長さ）フィールドは16ビットである。この値はネットワークバイト順で、PPPoEペイロードの長さを示す。イーサネットあるいはPPPoEのヘッダの長さを含めてはいけない。

5.　ディスカバリ段階 (Discovery Stage)

このディスカバリ段階には4つのステップがある。これが終了すると、双方のピアはPPPoEのSESSION_IDとピアのイーサネット・アドレスを知ることとなり、これにより単一無二なPPPoEセッションを共有する。4つのステップには、ホスト(Host)からの開始(Initiation)パケットのブロードキャスト、ひとつまたはそれ以上のアクセス集線装置(Access Concentrator)からの提示(Offer)パケットの送信、ホストからのユニキャストのセッション要求(Session Request)パケットの送信、および選択されたアクセス集線装置からの応答(Confirmation)パケットの送信からなる。ホストが応答パケットを受信すると、そのホストはPPPセッション段階に進んでよい。アクセス集線装置が応答パケットを送信したら、その集線装置はPPPセッション段階に進んでよい。

すべてのディスカバリのイーサネット・フレームはETHER_TYPEフィールドには0x8863がセットされる。

PPPoEペイロードにはゼロ以上のタグ(TAGs)が含まれる。タグはいわゆるTLV（タイプ－長さ－値：type-length-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 | TAG_LENGTH |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TAG_VALUE ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TAG_TYPE（タグタイプ）はネットワークバイト順16ビット長フィールドである。Appendix AにすべてのTAG_TYPEとその取るべきTAG_VALUEのリストを示してある。

TAG_LENGTHは16ビット長のフィールドである。これはネットワークバイト順符号なし数値で、TAG_VALUEのオクテット長を示す。

未知のTAG_TYPEのタグを持つディスカバリ・パケットが受信されたときは、該タグは本ドキュメントに特に定めてないかぎりこれを無視しなければならない[MUST]。これにより、もし新規のタグが追加されたときの後方互換性(backwards compatibility)を持たせる。新規に必須のタグ(mandatory TAGs)が追加されたときは、バージョンをひとつ上げねばならない。

ディスカバリ・パケットのいくつかの事例をAppendix Bに示す。

5.1　PPPoEアクティブ・ディスカバリ開始パケット(The PPPoE Active Discovery Initiation (PADI) packet)

ホストはDESTINATION_ADDRフィールドにブロードキャスト・アドレス（oxffffffffffff）をセットしたPADIパケットを送信する。CODEフィールド0x09でSESSION_IDは0x0000にセットされていなければならない。

このPADIパケットは、他の任意の数のTAGタイプのタグも含まれていて良いが、このホストが要求とするサービスを示すTAG_TYPEのサービス名(Service-Name)のひとつを正しく含んでいなければならない[MUST]。PADIパケットの全体の（PPPoEヘッダも含めて）長さは、中継エージェントが中継セッションID(Relay-Session-Id)を付加するために十分な余裕を持たせる為に、1484オクテットを超えてはいけない[MUST NOT]。

5.2　PPPoEアクティブ・ディスカバリ提示パケット (The PPPoE Active Discovery Offer (PADO) packet)

アクセス集線装置が、自分がサービス可能なPADIパケットを受信すると、PADOパケットを送信することでこれに応答する。DESTINATION_ADDRフィールドはこのPADIを送信したホストのユニキャスト・アドレスとなる。CODEフィールドは0x07、またSESSION_IDフィールドは0x0000にセットされていなければならない[MUST]。

このPADOパケットは、アクセス集線装置の名前を含むひとつのAC-Nameタグと、PADIに含まれていたと同じService-Nameタグ、そしてこのアクセス集線装置がこれ以外に提示する任意の数のService-Nameタグを含んでいなければならない[MUST]。もしこのアクセス集線装置がこのPADIパケットにサービスできないときは、PADOで応答してはならない[MUST NOT]。

5.3　PPPoEアクティブ・ディスカバリ要求パケット(The PPPoE Active Discovery Request (PADR) packet)

PADIはブロードキャストだったので、このホストはひとつ以上のPADOを受信することもある。該ホストはは受信したPADOパケットを調べてどれかひとつを選択する。選択にあたってはAC-Nameや提示しているサービスをベースにしてよい。このホストは次に、それが選択したアクセス集線装置にPADRパケットを送信する。DESTINATION_ADDRフィールドは、PADOを送信したアクセス集線装置のユニキャスト・イーサネット・アドレスがセットされる。CODEフィールドは0x19に、SESSION_IDは0x0000にセットされねばならない[MUST]。

このPADRパケットは、このホストが要求しているサービスを示す正しいService-NameのTAG_TYPEのタグひとつと、他の任意のタグ・タイプのタグを含んでいなければならない[MUST]。

5.4　PPPoEアクティブ・ディスカバリ・セッション確認パケット (The PPPoE Active Discovery Session-Confirmation (PADS) packet)

アクセス集線装置がPADRパケットを受信したら、PPPセッション開始の準備をする。この集線装置はこのPPPoEセッションに対し唯一無二のSESSION_IDを作成し、該ホストに向けPADSパケットを返す。DESTINATION_ADDRフィールドはこのPADRを送信したホストのユニキャスト・イーサネット・アドレスである。CODEフィールドは0x65に、SESSION_IDはこのPPPoEセッションのために作成された唯一無二の数値である[MUST]。

PADSパケットには、このPPPoEセッションを受理したアクセス集線装置のもとでのサービスを示すService-Nameの正しいTAG_TYPEタグと、任意の他のタグ・タイプのタグを含む。

アクセス集線装置がPADRにあるService-Nameを好まないならば、Service-Name-Errorのタグ（及び任意の数の他のタグ）を含むPADSで応答しなければならない[MUST]。この場合、SESSION_IDは0x0000にセットされねばならない[MUST]。

5.5　PPPoEアクティブ・ディスカバリ終了パケット (The PPPoE Active Discovery Terminate (PADT) packet)

このパケットはセッションが確立した後なら何時でも、PPPoEセッションが終了されたことを示す為に送信して良い。これはホスト側からでもアクセス集線装置側からでも送信してよい。DESTINATION_ADDRフィールドはユニキャスト・イーサネット・アドレス、CODEフィールドは0xa7、そしてSESSION_IDはどのセッションが終了するのかを示すために設定されていなければならない[MUST]。タグは必要とされない。

PADTを受信したら、このセッションを用いたその後の如何なるPPPトラフィックも許されない。通常のPPP終了パケットであっても、PADTを送信または受信したあとは送信してはならない[MUST NOT]。PPPピアは、PPPoEセッションを終了させるのにPPPプロトコル自身をを使用すべきであるが[SHOULD]、PPPが使えないときはPADTを使用しても良い。

6.　PPPセッション段階 (PPP Session Stage)

PPPoEセッションが開始したら、他の任意のPPPカプセル化でデータが送信される。総てのイーサネット・パケットはユニキャストである。ETHER_TYPEフィールドは0x8864にセットする。PPPoEのCODEは0x00にセットされねばならない[MUST]。SESSION_IDはこのPPPoEセッションに関しては変更されてはならないし[MUST NOT]、ディスカバリ段階で割り当てられた値を維持しなければならない[MUST]。PPPoEペイロードはPPPフレームが入る。このフレームはPPPプロトコルID(PPP Protocol-ID)で始まる。

パケットの事例がAppendix Bに示してある.

7.　LCP（リンク制御プロトコル）の考察 (LCP Considerations)

マジックナンバーLCP(Magic Number LCP)設定オプションは推奨され、プロトコルフィールド圧縮(PFC: Protocol Field Compression)は推奨されない。実装にあたっては、以下のオプションのいずれも要求してはならないし[MUST NOT]、かかるオプションの要求は拒絶しなければならない[MUST]：

フィールド・チェック・シーケンス(FCS: Field Check Sequence)代替

アドレスと制御フィールド圧縮(ACFC: Address-and-Control-Field-Compression)

非同期制御文字マップ(ACCM: Asynchronous-Control-Character-Map)

最大受信ユニット(MRU: Maximum-Receive-Unit)オプションは1492より大きなサイズをネゴシエートしてはならない[MUST NOT]。イーサネットは、最大1500オクテットのペイロード・サイズを有し、PPPoEヘッダは6オクテット、またPPPプロトコルIDが2オクテットであるので、PPP MTUは1492以上であってはならない[MUST NOT]。

アクセス集線装置が適時ホストにむけてセッションの状態を知るためにエコー要求(Echo-Request)パケットを送信することを勧める。でないと、ホストが終了要求(Terminate-Request)パケットを送信することなくセッションを終了してしまったとき、該セッションが行ってしまったかをアクセス集線装置が知ることが出来なくなる。

LPCが終了したら、ホストとアクセス集線装置ともにこのPPPoEセッションの使用を停めなければならない[MUST]。ホストが他のPPPセッションの開始を望むときは、PPPoEディスカバリ段階に戻らねばならない[MUST]。

8.　その他の考察 (Other Considerations)

ホストが指定された時間内にPADOパケットを受信しなかったときは、PADIを再送するとともに待ち時間を2倍にしなければならない[SHOULD]。これを必要な回数だけ繰り返す。ホストがPADSパケット受信を待っているときも、同様なタイムアウトのメカニズムを適用してPADRパケットを再送しなければならない[SHOULD]。指定された回数リトライされたときは、ホストはPADIパケットを再送しなければならない[SHOULD]。

本ドキュメントに使ったETHER_TYPEs(0x8863ETHER_TYPEs及び0x8864)はイーサネット上のPPP(PPPoE)用としてIEEEが割り当てたものである。これらの値とPPPoEバージョン(PPPoE VER)フィールドの使用は、本プロトコルだけのものとなっている。

本ドキュメントを通して、ASCIIではなくUTF-8 [5]が採用されている。UTF-8はASCII文字セットの総てをサポートすることに加え、国際文字セットもサポートする。より詳細は[5]を参照のこと。

9.　セキュリティの考察 (Security Considerations)

サービス拒絶(DOS: Denial of Service)攻撃に対する保護のために、アクセス集線装置はAC-Cookieタグを採用できる。アクセス集線装置はPADRのSOURCE_ADDRに基づいてTAG_VALUEを唯一無二に再生できるようにならねばならない[SHOULD]。これを採用すると、アクセス集線装置はこのPADRのSOURCE_ADDRが実際に相手に到達可能であることを保証し、該アドレスへの同時の複数のセッションを制限することが出来る。どのアルゴリズムを適用するかはここでは規定せず、実装のデテイルとしてある。ひとつの例としてホストのMACアドレス上のHMAC [3]で、これはアクセス>集線装置に対してのみわかっている鍵を使うものである。

AC-Cookieはある程度のDOS攻撃に有効であるものの、総てのDOS攻撃を防御できなく、アクセス集線装置は資源をするために別の手法を採用しても良い[MAY]。

多くの集線装置は、認証されていない実体にたいして、どのサービスが提示されているかの情報を開示することを望まないであろう。その場合、アクセス集線装置は2つのポリシーのひとつを採用しなければならない。Service-Nameタグをベースとした要求を決して拒絶せず[SHOULD]、いつもそこに送信されたTAG_VALUEを何時も返さねばならない。あるいは、Service-Nameタグのついた要求に対してTAG_LENGTHゼロ（任意のサービスであることを示す）で受理しなければならない[SHOULD]。前者のソリューションのほうが推奨される。

10.　謝辞 (Acknowledgements)

本ドキュメントはADSLフォーラムを含む幾つかのフォーラムにて討議されたコンセプトに準拠している。

RFC 1661, RFC 1662, RFC 2364から多大のテキストが流用されている。

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.

Appendix A TAG_TYPESとTAG_VALUES

0x0000 End-Of-List（リストの終わり）

このタグはこのリストにこれ以上のタグが存在しないことを示す。このタグのTAG_LENGTHは何時もゼロでなければならない[MUST]。このタグの使用は必要とはされていないが、後方互換性の為に存続している。

0x0101 Service-Name（サービス名）

このタグはサービスの名前が以下のようであることを示す。TAG_VALUEはUTF-8ストリングで、NULL終端ではない。ゼロのTAG_LENGTHが入っているタグは、どのサービスも受けつけ可能であることを示す為に使用される。

0x0102 AC-Name（アクセス集線装置名）

このタグは、以下の文字列が、特定のアクセス集線装置を他のすべてから特定することを意味する。これは商標、モデル、シリアルID情報などの組み合わせ、あるいは単に該装置のMACアドレスをUTF-8に翻訳したものであっても良い。これはNULL終端ではない。

0x0103 Host-Uniq（ホスト固有）

このタグは、ホストがあるアクセス集線装置からの応答（PADOまたはPADS）をあるホスト要求（PADIまたはPADR）とするのに使われる。TAG_VALUEはこのホストが選択した任意の値と長さのバイナリ・データである。これはデータはアクセス集線装置では解釈されない。ホストはこのHost-UniqタグをPADIまたはPADRに含めてよい。アクセス集線装置はこのタグを受信したら、それに基づくPADOまたはPADSに、修正しないでこのタグを含めなければならない[MUST]。

0x0104 AC-Cookie

このタグはアクセス集線装置がサービス拒絶攻撃に対向する防御手段に使われる（これの動作の記述に関しては、セキュリティの考察の項を参照のこと）。アクセス集線装置はこのタグをPADOパケットに含めて良い[MAY]。ホストは、このタグを受信したら、このタグを無修正で後のPADRにいれて返さなければならない[MUST]。TAG_VALUEは任意の値と長さを持ったバイナリ・データで、ホストはこれを解釈しない。

0x0105 Vendor-Specific（ベンダ固有）

このタグはベンダー固有の情報を渡すのに使用される。TAG_VALUEの最初の4オクテットはベンダーIDであり、残りの部分は規定しない。ベンダーIDの一番上のオクテットは0で、下位の3オクテットはネットワーク・バイト順のこのベンダーのSMIネットワーク管理プライベート企業コード(SMI Network Management Private Enterprise Code)であり、これはRFC[4]のAssigned Numbersに定めてある。

このタグの使用は推奨されない。相互運用性を確たるものとするためには、実装にあたってはVendor-Specificタグを静かに無視してよい[MAY]。

0x0110 Relay-Session-Id（中継セッションID）

このタグはトラフィックを中継する中継エージェントにより、どのディスカバリ・パケットに追加されても良い。TAG_VALUEはホスト及びアクセス集線装置共に解釈できないものである。ホストまたはアクセス集線装置のどれかがこのタグを受信したら、それが応答として送信するディスカバリ・パケットにこれを無修正で含めねばならない[MUST]。総てのPADIパケットは、長さが12オクテットのTAG_VALUEを持ったRelay-Session-Idタグが追加されるのに充分な余裕を保証しなければならない[MUST]。

Relay-Session-Idタグは、該ディスカバリ・パケットがすでにこれをひとつ含んでいるときは、これを追加してはならない[MUST NOT]。この場合、中継エージェントは既存のRelay-Session-Idタグを使用しなければならない[SHOULD]。既存のタグが使えないか、Relay-Session-Idタグを追加する余地がないときは、Generic-Errorタグを送信元に返さなければならない[SHOULD]。

0x0201 Service-Name-Error（サービス名エラー）

このタグ（通常ゼロ長のデータ部分）は、ひとつあるいは別の理由により、要求されているService-Name要求が受理できないことを示す。

データ部分が存在し、このデータの最初の3オクテットがゼロでなければ、これはどの要求が拒絶されたかを記述した印刷可能なUTF-8文字列でなければならない[MUST]。この文字列はNULL終端でないこともある[MAY NOT]。

0x0202 AC-System-Error（アクセス集線装置システムエラー）

このタグはアクセス集線装置がホストからの要求を処理中に何らかのエラーを生じたことを示す。（例えばバーチャル接続、VC、を張るのにリソースが不足した。）こらはPADSパケットに含めて良い[MAY]。データが存在する場合は、このデータの最初の3オクテットがゼロでなければ、エラーの種類を記述した印刷可能なUTF-8文字列でなければならない[MUST]。この文字列はNULL終端でないこともある[MAY NOT]。

0x0203 Generic-Error（属固有エラー）

このタグはエラーを示す。これは復帰不能のエラーが発生し、他のエラー・タグが適切でないときにPADO、PADR、あるいはPADSに追加され得る。データが存在する場合は、このデータの最初の3オクテットがゼロでなければ、エラーの種類を記述した印刷可能なUTF-8文字列でなければならない[MUST]。この文字列はNULL終端であってはならない[MUST NOT]。

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 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PPP LCPパケット：

PPPプロトコル値(0xc021: LCP)が示されているが、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

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