原文：ftp://ftp.rfc-editor.org/in-notes/rfc2516.txt
この文書はインターネットコミュニティのための情報を提供する。この文書はいかなる種類のインターネット標準も規定しない。この文書の配布は無制限である。
Copyright (C) The Internet Society (1999). All Rights Reserved.
ポイントツーポイントプロトコル(PPP) [1] は、ポイントツーポイントリンク上でマルチプロトコルのデータグラムを送信する標準的手法を提供する。
この文書はイーサネット上で PPP セッションを確立する方法と、PPP パケットをカプセル化する方法とを説明している。
この仕様は、リンクコントロールプロトコル・ネットワーク層コントロールプロトコル・認証などの PPP 向けに定義されている機能を提供することを目的としている。これらの能力はピア間のポイントツーポイント接続を必要とし、イーサネットなどのマルチアクセス環境で利用可能なマルチポイント接続向けには設計されていない。
この仕様は、共有されたイーサネット上の複数のホストが１つ以上のブリッジングモデムを経由して複数の宛先へ PPP セッションを開くために使用することが出来る。これは PPP に対応するセッションの抽象概念をアクセスプロバイダが維持したい場合に、イーサネットブリッジ技術を提供するブロードバンドのリモートアクセス技術とともに利用されることを意図している。
この文書は RedBack Networks、RouterWare、UUNET などにより展開されている PPP Over Ethernet の カプセル化について説明している。
近年のアクセス技術はいくつかの競合する目標に直面している。同じ顧客の構内アクセス装置を通してリモートサイトの複数ホストへ接続することを望むと同時に、PPP を利用するダイアルアップサービスのような方法でアクセスコントロールと課金とを提供することも目標である。数多くのアクセス技術の中で、顧客の構内アクセス装置に複数ホストを接続するための費用効果の高い方法は、イーサネットを経由することである。さらにその装置は、少しの設定しか必要としないか全く設定を必要としない一方で、費用を出来るだけ低く保つことも望ましい。
PPP over Ethernet (PPPoE) は、複数ホストのネットワークが単純なブリッジングアクセス装置越しにリモートのアクセスコンセントレータに接続する能力を提供する。このモデルでは、各ホストは自身の PPP スタックを利用し、利用者には使い慣れたユーザーインターフェイスが提供される。アクセスコントロールや課金、サービスの種類などは、サイト単位ではなくユーザー単位に行うことが出来る。
イーサネット越しのポイントツーポイント接続を提供するためには、各 PPP セッションはリモート側ピアのイーサネットアドレスを知っていなければならないのと同時に、ユニークなセッション識別子の確立も行わなければならない。PPPoE にはそれを提供するための発見プロトコルも含まれる。
この文書中のキーワード MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONAL は、[2] で説明されている通りに解釈される。
PPPoE は独立した２つのステージ、Discovery ステージと PPP セッションステージとを持つ。PPPoE セッションを開始したいホストは、まず最初にピアのイーサネット MAC アドレスを識別して PPPoE SESSION_ID を確立するために、Discovery を実行しなければならない。PPP はピアツーピア関係を定義するが、Discovery は本質的にクライアントサーバー関係である。この Discovery プロセスにおいて、ホスト(クライアント)はアクセスコンセントレータ(サーバー)を見つけ出す。ネットワークトポロジに基づき、ホストが通信可能なアクセスコンセントレータは１つまたは複数存在することが許される。Discovery ステージは、ホストが全てのアクセスコンセントレータを探し出し、そこから１つを選択することを可能にする。Discovery が正常に完了したとき、ホストと選択されたアクセスコンセントレータは共に、イーサネット越しにポイントツーポイント接続を確立するために使用される情報を持つ。
PPP セッションが確立されるまでは、Discovery ステージはステートレスのままであり続ける。PPP セッションが確立された時点で、ホストとアクセスコンセントレータは PPP 仮想インターフェイスのためのリソースを割り当てなければならない(MUST)。
ここで以下のパケットフォーマットを定義する。ペイロードの内容は Discovery と PPP のセッションで定義される。
イーサネットフレームは以下の通り：
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESTINATION_ADDR |
| (6 オクテット) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR |
| (6 オクテット) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 オクテット) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ ペイロード ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DESTINATION_ADDR フィールドは、ユニキャストのイーサネット目的アドレスまたはイーサネットブロードキャストアドレス(0xffffffff)のどちらかを含む。Discovery パケットの場合、この値は Discovery セクションで定義されているユニキャストかブロードキャストのどちらかである。PPP セッションのトラフィックの場合、このフィールドは Discovery ステージで決定したピアのユニキャストアドレスを含まなければならない(MUST)。
SOURCE_ADDR フィールドは送信元デバイスのイーサネット MAC アドレスを含まなければならない(MUST)。
ETHER_TYPE には 0x8863 (Discovery ステージ) または 0x8864 (PPP セッションステージ) のどちらかがセットされる。
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 | ペイロード ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VER フィールドは４ビットであり、このバージョンの PPPoE 仕様では 0x01 がセットされなければならない(MUST)。
TYPE フィールドは４ビットであり、このバージョンの PPPoE では 0x01 がセットされなければならない(MUST)。
CODE フィールドは８ビットであり、Discovery ステージ用と PPP セッションステージ用とに以下で定義される。
SESSION_ID フィールドは 16 ビットであり、ネットワークバイトオーダーで表された符号なしの値である。この値は Discovery パケット用に以下で定義される。ある特定の PPP セッションにおいてこの値は不変であり、実際にはイーサネットの SOURCE_ADDR と DESTINATION_ADDR とに従って PPP セッションを定義する。値 0xffff は将来のために予約されており、使用されてはならない(MUST NOT)。
LENGTH フィールドは 16 ビットであり、PPPoE のペイロード長をネットワークバイトオーダーで表す。これにはイーサネットヘッダや PPPoE ヘッダの長さは含まれない。
Discovery ステージには４つのステップが存在する。それらが完了したとき、両ピアは PPPoE SESSION_ID とピアのイーサネットアドレスとを知る(これら二つを併せることで PPPoE セッションをユニークに定義する)。これらのステップは、ホストによる Initiation パケットのブロードキャスト、１つ以上のアクセスコンセントレータによる Offer パケットの送信、ホストによる Session Request パケットのユニキャスト送信、選ばれたアクセスコンセントレータによる Confirmation パケットの送信から成る。ホストが Confirmation パケットを受け取ると、そのホストは PPP セッションステージへと進むことが許される。アクセスコンセントレータが Confirmation パケットを送信すると、そのアクセスコンセントレータは PPP セッションステージへと進むことが許される。
全ての Discovery Ethernet フレームは、その ETHER_TYPE フィールドに値 0x8863 がセットされる。
PPPoE のペイロードはゼロ個以上の TAG を含む。TAG は 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 ビットフィールドである。付録 A は全ての TAG_TYPE とその TAG_VALUE の一覧である。
TAG_LENGTH は 16 ビットのフィールドである。これはネットワークバイトオーダーの符号無し数値であり、TAG_VALUE のオクテット長を表す。
不明な TAG_TYPE の TAG を持つ Discovery パケットを受信した場合、この文書とは別の規定がない限り、その TAG は無視されなければならない(MUST)。これにより、新しい TAG が追加された場合の後方互換性が提供される。新しい必須 TAG が追加された場合、バージョン番号はインクリメントされるだろう。
いくつかの Discovery パケットの例が付録 B に示されている。
ホストは DESTINATION_ADDR にブロードキャストアドレスをセットした PADI パケットを送信する。CODE フィールドには 0x09 がセットされ、SESSION_ID には 0x0000 がセットされなければならない(MUST)。
PADI パケットにはホストが要求しているサービスを表す Service-Name の TAG_TYPE が正確に１つだけ含まれなければならない(MUST)。その他の種類の TAG は任意の数だけ含まれて良い。リレーエージェントが Relay-Session-Id TAG を追加するのに十分な空きを残すために、PADI パケット全体は 1484 オクテットを超えてはならない(MUST)。
提供可能な PADI を受け取ったアクセスコンセントレータは、PADO パケットを送信することで応答する。DESTINATION_ADDR は PADI パケットを送信したホストのユニキャストアドレスとなる。CODE フィールドには 0x07 がセットされ、SESSION_ID には 0x0000 がセットされなければならない(MUST)。
PADO パケットにはアクセスコンセントレータの名前を含む AC-Name TAG を１つと、PADI に含まれるものと同一の Service-Name TAG とを含まなければならない(MUST)。アクセスコンセントレータが提供する他のサービスを表す Service-Name TAG を任意の数だけ含んでも良い。アクセスコンセントレータがその PADI を提供できない場合、PADO を返してはならない(MUST NOT)。
PADI をブロードキャストした後、ホストは１つ以上の PADO を受け取る可能性がある。ホストは受信した PADO パケットを調べ、その１つを選択する。その後ホストは選択したアクセスコンセントレータへ１つの PADR パケットを送信する。DESTINATION_ADDR フィールドには、PADO を送信したアクセスコンセントレータのユニキャストイーサネットアドレスがセットされる。CODE フィールドには 0x19 がセットされ、SESSION_ID には 0x0000 がセットされなければならない(MUST)。
PADR パケットにはホストが要求するサービスを表す TAG_TYPE Service-Name の TAG を正確に１つだけ含まなければならない(MUST)。その他の種類の TAG は任意の数だけ含まれて良い。
PADR パケットを受け取ると、アクセスコンセントレータは PPP セッションを開始する準備をする。アクセスコンセントレータはその PPPoE セッションのためのユニークな SESSION_ID を生成し、PADS パケットでホストへ返信する。DESTINATION_ADDR フィールドには PADR を送信したホストのユニキャストイーサネットアドレスがセットされる。CODE フィールドには 0x65 がセットされ、SESSION_ID にはその PPPoE セッションのために生成されたユニークな値がセットされなければならない(MUST)。
PADS パケットはアクセスコンセントレータが受け入れた PPPoE セッションにおけるサービスを表す TAG_TYPE Service-Name の TAG を正確に１つと、任意の数のその他の種類の TAG とを含む。
PADR に含まれる Service-Name をアクセスコンセントレータが好まない場合、アクセスコンセントレータは TAG_TYPE Service-Name-Error の TAG (と任意の数のその他の種類の TAG)を含む PADS を返さなければならない(MUST)。この場合 SESSION-ID には 0x0000 がセットされなければならない(MUST)。
このパケットは PPPoE セッションが閉じられたことを示すために、セッションの確立後いつでも送信して良い。ホストとアクセスコンセントレータのどちらが送信しても良い。DESTINATION_ADDR フィールドはユニキャストイーサネットアドレスであり、CODE フィールドには 0xa7がセットされ、SESSION_ID はどのセッションが終了したのかを表すためにセットされなければならない(MUST)。TAG は不要である。
PADT を受信すると、そのセッションでそれ以上 PPP トラフィックを送信することは許されない。PADT の送信または受信の後には、通常の PPP 終了パケットさえも送信してはならない(MUST NOT)。PPP ピアは PPPoE セッションを停止するのに PPP プロトコルを使用するべき(SHOULD)だが、PADT は PPP が使用できないときにでも送信して良い(MAY)。
PPPoE セッションが開始されると、PPP データは他の PPP カプセル化においてと同様に送信される。全てのイーサネットパケットはユニキャストである。ETHER_TYPE フィールドには 0x8864 がセットされる。PPPoE の CODE には 0x00 がセットされなければならない(MUST)。SESSHON_ID は Discovery ステージで割り当てられた値でなければならず(MUST)、その PPPoE セッション中には変化してはならない(MUST NOT)。PPPoE ペイロードには PPP フレームが含まれ、そのフレームは PPP の Protocol-ID で始まる。
付録 B にパケットの例が示されている。
LCP 構成オプションの Magic Number が推奨され(RECOMMENDED)、Protocol Field Compression (PFC) オプションは推奨されない(NOT RECOMENDED)。実装は以下のオプションを要求してはならず(MUST NOT)、これらのオプションの要求は拒否しなければならない(MUST)：
Field Check Sequence (FCS) Alternatives,
Address-and-Control-Field-Compression (ACFC),
Asynchronous-Control-Character-Map (ACCM)
Maximum-Receive-Unit (MRU) オプションで 1492 より大きいサイズをネゴシエートしてはならない(MUST NOT)。イーサネットの最大ペイロードサイズが 1500 オクテット、PPPoE ヘッダが 6 オクテット、PPP Protocol ID が 2 オクテットであるため、PPP の MTU は 1492 を超えてはならない(MUST NOT)。
セッションの状態を判断するために、アクセスコンセントレータは時々 Echo-Request パケットをホストに送信することが推奨される(RECOMMENDED)。もしそうしなければ、ホストが Terminate-Request パケットを送信せずにセッションを終了した場合に、アクセスコンセントレータはそのセッションが終了していることを判断できないだろう。
LCP が終了したとき、ホストとアクセスコンセントレータは PPPoE セッションの使用を停止しなければならない(MUST)。ホストが別の PPP セッションを開始したい場合、PPPoE Discovery ステージに戻らなければならない(MUST)。
規定時間内に PADO パケットを受信しなかった場合、ホストはその PADI パケットを再送し、二倍の時間待機するべきである(SHOULD)。これは好きなだけ繰り返される。ホストが PADS パケットの受信を待つ場合にも似たようなタイムアウトのメカニズム(この場合ホストは PADR を再送する)を使用するべきである(SHOULD)。規定の回数リトライした後、ホストは PADI パケットを再送するべきである(SHOULD)。
この文書で使用されている ETHER_TYPE (0x8863 と 0x8864)は、IEEE によって PPP Over Ethernet (PPPoE) 用に割り当てられている。これらの値と PPPoE VER (バージョン)フィールドとを使用することにより、このプロトコルは一意に識別される。
この文書全体を通して、ASCII の代わりに UTF-8 [5] が使用されている。UTF-8 は国際的な文字セットを許可する一方で、ASCII 文字セットも完全にサポートする。より詳細は [5] を参照されたい。
サービス不能攻撃(DOS)から保護するために、アクセスコンセントレータは AC-Cookie TAG を採用することが出来る。アクセスコンセントレータは PADR の SOURCE_ADDR に基づくユニークな TAG_VALUE を再生成できるべきである(SHOULD)。それを使用することでアクセスコンセントレータは PADI の SOURCE_ADDR が確かに到達可能であることを確実にすることができ、そのアドレスへの同時セッションを制限することができる。使用されるアルゴリズムは定義されておらず、詳細は実装に任されている。ひとつの例としては、アクセスコンセントレータだけが知っているキーを使ったホスト MAC アドレス上の HMAC [3] がある。
AC-Cookie は一部の DOS 攻撃に対しては有効だが、全ての DOS 攻撃から保護することは出来ない。アクセスコンセントレータはリソースを保護するために別の方法を採用しても良い(MAY)。
多くのアクセスコンセントレータは、自身の提供しているサービスに関する情報を認証されていないエンティティに対して提供したいとは思わないだろう。そのような場合、アクセスコンセントレータは２つのポリシーのうち１つを採用するべきである。ひとつは Service-Name TAG に基づく要求を決して拒否せず、アクセスコンセントレータに送信された TAG_VALUE を常に返すべきである(SHOULD)というポリシー、もうひとつは、TAG_LENGTH がゼロの Service-Name TAG (これは任意のサービスを表す)による要求のみ受け付けるべきである(SHOULD)というポリシーである。前者の方法が推奨される(RECOMMENDED)。
この文書はいくつかのフォーラム(ADSL フォーラムを含む)で議論されているコンセプトに基づいている。
大量のテキストが RFC 1661 と RFC 1662、RFC 2364 から採られている。
[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.
TAG_TYPE と TAG_VALUE
いくつかのパケットの例を以下に示す：
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)は示されているが、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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
Copyright (C) The Internet Society (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.
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.