イーサネット経由のポイントツーポイントプロトコル

PPPoE および TCP/IPプロトコル スタック
応用FTPSMTPHTTP...DNS...
輸送TCPUDP
インターネットIPIPv6
ネットワークアクセス購買力平価
PPPoE
イーサネット

PPPoE ( Point -to-Point Protocol over Ethernet ) は、Point-to-Point Protocol (PPP) フレームをEthernetフレーム内にカプセル化するネットワークプロトコルです。1999 年、 DSLブームの中で、 DSL 接続を介してISPのIPネットワークにパケットをトンネリングし、そこからインターネットの他の部分にパケットをトンネリングするソリューションとして登場しました。2005 年のネットワーク書籍には、「ほとんどの DSL プロバイダーは、認証、暗号化、および圧縮を提供する PPPoE を使用しています」と記載されています。 [1] PPPoE の一般的な使用法は、 PAPプロトコルまたはCHAPを介してユーザー名とパスワードでユーザーを認証するための PPP 機能を活用することです。2007 年には PAP が主流でしたが、PAP はプレーンテキスト プロトコルであるため、サービス プロバイダーはより安全な CHAP に移行しています。[2] 2000年頃、PPPoEは、従来のUSB接続に代わり、イーサネットLAN経由でコンピュータやルーターに接続されたモデムと通信する代替手段として普及し始めました。イーサネット経由でルーターとモデムを接続するというこのユースケースは、今日でも非常に一般的です。

顧客構内機器では、DSLモデムとIPルーティング機能の両方を扱う統合住宅用ゲートウェイデバイスにPPPoEを実装するか、または単純なDSLモデム（ルーティングサポートなし）の場合は、PPPoEをその背後の別のイーサネット専用ルーターで、またはユーザーのコンピュータ上で直接処理することができます。（PPPoEのサポートは、Windows XP、[3]、Linux [4]、Mac OS X [5]など、ほとんどのオペレーティングシステムに存在します。）最近では[いつ？ ]、一部のGPONベース（DSLベースではなく）住宅用ゲートウェイもPPPoEを使用していますが、GPON標準におけるPPPoEの位置付けはITU-T勧告G.984.1「ギガビット対応パッシブ光ネットワーク（GPON）：一般的な特性」で言及されているものの、限界があります。

PPPoEはUUNET、Redback Networks（現Ericsson）、RouterWare（現Wind River Systems）[6]によって開発され、情報RFC  2516として入手可能です。

DSL の世界では、PPP は一般にATM上(PPPoA として) で実行され、ATM が基礎となるレイヤー 2 プロトコル、DSL のバージョンがレイヤー 1 プロトコルであると理解されていますが、PPP プロトコル自体にはそのような制限はありません。

その他の使用シナリオでは、別の基盤プロトコルを接尾辞として付加することで区別されることがあります。例えば、メトロイーサネットネットワークのように、トランスポートがイーサネット自体である場合は、PPPoEoEとなります。（この表記法では、PPPoEの本来の用途はPPPoEoAと表記されますが、PPPプロトコルの異なるカプセル化を持つPPPoAと混同しないように注意してください。）

PPPoEは、いくつかの書籍では「レイヤー2.5」プロトコルとして説明されています。[2] [7] PPPoEは、イーサネットインフラストラクチャを共有する異なるIPフローを区別するために使用できるため、基本的な意味でMPLSに似ていますが、PPPoEヘッダーに基づいてルーティングを決定するPPPoEスイッチがないため、その点で適用範囲が制限されます。[7]

当初の根拠

1998 年後半、DSL サービス モデルはまだ、価格が家庭レベルにまで下がるほど大規模にはなっていませんでした。ADSL 技術は 10 年前に提案されていました。[8] 潜在的な機器ベンダーや通信事業者は、ケーブル モデムやDSLなどのブロードバンドが最終的にはダイヤルアップサービスに取って代わることを認識していましたが、ハードウェア (顧客宅内とLEC の両方) は、少量生産時に大きな コスト障壁に直面していました。DSL の少量生産の初期の推定では、DSL モデムのコストが 300～500 米ドル (2024 年には 579～965 米ドル) の範囲で、電話会社からのアクセス料金が月額 300 米ドルと示されていました[要出典] 。これは、家庭ユーザーが支払う金額をはるかに超えていました。そのため、当初の焦点は、~1.5Mbpsの T1回線（当時月額800～1500ドル）は経済的ではありませんでしたが、ダイヤルアップやISDNでは実現できないようなサービスを求める顧客はいました。十分な数の顧客が参入してくれれば、家庭向けダイヤルアップ利用者が興味を持つような価格まで下がるでしょう。

異なる使用プロファイル

問題は、中小企業の顧客の使用プロファイルが、家庭でダイヤルアップを使用するユーザーとは異なっていたことです。

  • LAN 全体をインターネットに接続する。
  • 接続の反対側からアクセス可能なローカル LAN 上でサービスを提供する。
  • 企業 VPN や汎用 ISP などの複数の外部データ ソースへの同時アクセス。
  • 勤務時間中、または 24 時間連続して使用できます。

これらの要件は、ダイヤルアップ接続における接続確立の遅延や、1台のコンピュータと1台のISPというモデル、さらにはNATとダイヤルアップの組み合わせによる多対1という接続にも適合しませんでした。そのため、新しいモデルが必要でした。

PPPoE は主に次のいずれかの目的で使用されます。

  • PPPoE対応のインターネットDSLサービスでは、PPPoE対応のモデム・ルーター（レジデンシャルゲートウェイ）がDSLサービスに接続します。この場合、ISPとモデム・ルーターの両方がPPPoEに対応している必要があります。（この場合、PPPoE over DSL側は「PPPoE over ATM 」の略でPPPoEoAと呼ばれることがあります。）
  • または、PPPoE 対応DSL モデムが、イーサネット ケーブルを使用して PPPoE 対応のイーサネット専用ルーターに接続されている場合。

市場投入までの時間: シンプルであるほど良い

これらのニーズを満たすために全く新しいプロトコルを開発する上での問題は、時間でした。機器もサービスもすぐに利用可能でしたが、全く新しいプロトコルスタック（当時マイクロソフトは光ファイバーベースのATMセルからデスクトップへの接続を提唱しており[9]、L2TPも開発中でしたが、完成には程遠かった）を開発するには実装に非常に長い時間がかかり、好機を逃してしまう可能性がありました。そこで、完全なソリューションを迅速かつ低コストで提供するために、実装と標準化を簡素化するためのいくつかの決定が下されました。

既存のソフトウェアスタックを再利用する

PPPoEは、広く普及しているイーサネットインフラとユビキタスなPPPを統合し、ベンダーが既存のソフトウェアを再利用して短期間で製品を提供できるようにすることを目指していました。当時のオペレーティングシステムは基本的にすべてPPPスタックを備えており、PPPoEの設計により、PPPフレームをイーサネットフレーム内にカプセル化するためのシンプルなラッパー/シムが実現可能になりました。[要出典]

ハードウェア要件を簡素化

競合するWAN技術（T1、ISDN）では、顧客構内にルーターが必要でした。PPPoEは異なるイーサネットフレームタイプを使用することで、DSLハードウェアを単なるブリッジとして機能させ、一部のフレームをWANに渡し、残りのフレームを無視することができました。このようなブリッジの実装は、ルーターよりもはるかに簡単です。

情報RFC

RFC 2516 は当初、同じ理由から、標準化過程RFCではなく情報RFC としてリリースされました。標準化過程 RFC の採用期間が長すぎるためです。

現代のユースケース

2000 年頃、PPPoE プロトコルは、(i) USBを使用する以前の方法に代わって DSL モデムをコンピューターまたはルーターに接続するために、または (ii) PPP+PPPoE の 3 つのプロトコル ヘッダーを使用して、ルーターをネットワーク ノード、プロトコル コンバーター、ISP または ISP の IP ネットワークに接続し、さらにインターネットに接続するホールセール長距離通信事業者に属するやや上流のネットワーク ノードに接続するために使用されました。

最初の使用例である、いわゆる「PPPoEoE」（物理イーサネット LAN 上の PPPoE プロトコル トリオ）を使用するルータとモデムの接続は、PPP が使用される場合にモデムをルータに接続するために現在でも広く使用されています。

2つ目のユースケースは、PPPoEプロトコルトリオを1つ以上のインターネットアクセスリンク上で使用し、上流から下流まで接続するものです。これは、コンセンサスによれば、歴史的な理由から現在も使用されているに過ぎません。しかしながら、PPPは一部のISPで依然として人気があり、その理由は、ISPがホールセールアクセスキャリア/リセラーを利用する場合に必要とされるトンネリングプロトコルとして、あるいはPPPの機能を必要としているから、あるいはその両方であると考えられます。

前述のように、奇妙なことに、イーサネットプロトコルが使用されていない、つまりイーサネットネットワーク上に物理的に存在しない場合でも、イーサネットMACヘッダーがPPPoEヘッダーと共に使用されていることがあります。これは、不要なヘッダーオーバーヘッド、いわゆるブロート（bloat）を追加する以外には何の役にも立たないようです。例えば、後述するPPPoEoAの場合、物理的なイーサネットはなく、ATMのみが存在していましたが、不要なイーサネットMAC層のヘッダーオーバーヘッドが追加されただけでなく、イーサネットをATMに適合させるために、イーサネットアダプテーション層も追加されました。

2 番目のユースケースでは、これらの追加のプロトコル ヘッダーによって大量の肥大化が発生し、パフォーマンスがわずかに低下します。

2つ目のユースケースでは、PPP+PPPoE+イーサネットMACの使用範囲は、上流方向への距離が可変です。これは「ファーストマイル」、つまりADSLまたはVDSL2 / FTTCにおけるモデムを含む銅線ツイストペアのみに限定される場合もあれば、さらに上流方向へBRASの「ブロードバンドリモートアクセスサーバー」または「アクセスコンセントレーター」まで拡張して使用される場合もあります。これらのサーバーはログインを処理するかどうかは不明ですが、何らかのプロトコルコンバーターとして機能することは間違いありません。ある例では、PPPoEは上流方向に拡張され、卸売業者が運営するノードで終端します。このノードはL2TPトンネリングプロトコルに変換され、ISPのIP POP（「プレゼンスポイント」）にトンネリングされます。

ステージ

PPPoE には 2 つの異なる段階があります。

PPPoE検出

従来のPPP接続は、シリアルリンクまたはダイヤルアップ時に既に確立されているATM仮想回線を介して2つのエンドポイント間で確立されるため、回線上で送信されるすべてのPPPフレームは確実にもう一方の端に到達します。しかし、イーサネットネットワークはマルチアクセスであり、ネットワーク内の各ノードは他のすべてのノードにアクセスできます。イーサネットフレームには、宛先ノードのハードウェアアドレス（MACアドレス）が含まれます。これにより、フレームは目的の宛先に到達できます。

したがって、イーサネット接続を確立するためにPPP制御パケットを交換する前に、2つのエンドポイントのMACアドレスを相互に認識しておく必要があります。そうすることで、これらのMACアドレスを制御パケットにエンコードできるようになります。PPPoEの検出段階はまさにこれを行います。また、この段階では、以降のパケット交換に使用するセッションIDの確立や、セッションの終了を示すためにも使用されます。

PPPoE 検出パケットは、 EtherTypeが 0x8863 に設定されたイーサネット フレームで伝送されます。

PPPセッション

ピアのMACアドレスが判明し、セッションが確立されると、セッションステージが開始されます。このステージでは、PPPデータのチャンクがPPPoEパケットにカプセル化され、他のピアに送信されます。最初のセッションパケットは通常通りPPPセッションのネゴシエーションを行い、その後のほとんどのセッションパケットにはPPPデータチャンクが含まれます。

カプセル化は、PPP チャンクの先頭に 6 バイトの PPPoE ヘッダーを追加し、EtherTypeを 0x8864 に設定したイーサネット フレームで伝送することによって行われます。

PPPoE検出（PPPoED）

従来の PPP はピアツーピアプロトコルですが、PPPoE は複数のホストが単一の物理接続を介してサービス プロバイダーに接続できるため、 本質的にクライアント サーバー関係です。

検出プロセスは、クライアントとして機能するホストコンピュータと、インターネットサービスプロバイダ側のサーバーとして機能するアクセスコンセントレータ間の4つのステップで構成されます。以下に概要を示します。5番目で最後のステップは、既存のセッションを終了する方法です。

クライアントからサーバーへ: 開始 (PADI)

PADIはPPPoE Active Discovery Initiationの略です。[10]

ユーザーがDSLを使用してインターネットに「ダイヤルアップ」する場合、まずユーザーのコンピュータは、インターネットサービスプロバイダのPOP（ Point of Presence ）にあるDSLアクセスコンセントレータ（DSL-AC）を見つける必要があります。イーサネット経由の通信は、 MACアドレスを介してのみ可能です。コンピュータはDSL-ACのMACアドレスを知らないため、イーサネットブロードキャスト（MAC: ff:ff:ff:ff:ff:ff）を介してPADIパケットを送信します。このPADIパケットには、送信元コンピュータのMACアドレスが含まれています。

PADIパケットの例:

フレーム 1 (ワイヤ上で 44 バイト、キャプチャされた 44 バイト)イーサネット II、送信元: 00:50:da:42:d7:df、Dst: ff:ff:ff:ff:ff:ffPPP over Ethernet 検出 バージョン: 1 タイプ1 コードアクティブディスカバリーイニシエーション（PADI） セッションID: 0000 ペイロード長: 24PPPoEタグ タグ: サービス名 タグ: Host-Uniq バイナリデータ: (16バイト)

Src.（送信元）はPADIパケットを送信するコンピュータのMACアドレスです。Dst
.（送信先）はイーサネットブロードキャストアドレスです。PADI
パケットは複数のDSL-ACで受信できます。「Service-Name」タグに対応できるDSL-AC機器のみが応答する必要があります。

サーバーからクライアントへ: オファー (PADO)

PADOはPPPoE Active Discovery Offerの略です。[10]

ユーザーのコンピュータがPADIパケットを送信すると、DSL-ACはPADIで指定されたMACアドレスを使用してPADOパケットで応答します。PADOパケットには、DSL-ACのMACアドレス、名前（例：ライプツィヒのT-Com DSL-ACの場合はLEIX11-erx ）、およびサービス名が含まれます。複数のPOPのDSL-ACがPADOパケットで応答した場合、ユーザーのコンピュータは指定された名前またはサービスを使用して、特定のPOPのDSL-ACを選択します。

PADO パケットの例を次に示します。

フレーム 2 (ワイヤ上で 60 バイト、キャプチャされた 60 バイト)イーサネット II、送信元: 00:0e:40:7b:f3:8a、Dst: 00:50:da:42:d7:dfPPP over Ethernet 検出 バージョン: 1 タイプ1 コードアクティブディスカバリーオファー（PADO） セッションID: 0000 ペイロード長: 36PPPoEタグ タグ: AC-Name 文字列データ: lpzbr001 タグ: Host-Uniq バイナリデータ: (16バイト)

AC-Name -> 文字列データはAC名を保持します。この場合は「lpzbr001」（ライプツィヒのArcor DSL-AC）です
。Src.はDSL-ACのMACアドレスを保持します。DSL
-ACのMACアドレスから、DSL-ACのメーカー（この場合はNortel Networks）も分かります。

クライアントからサーバーへ: リクエスト (PADR)

PADRはPPPoEアクティブディスカバリリクエストの略です。[10]

PADRパケットは、DSL-ACから受け入れ可能なPADOパケットを受信した後に、ユーザーのコンピュータからDSL-ACに送信されます。これは、PADOパケットを発行したDSL-ACによるPPPoE接続のオファーが受け入れられたことを確認するものです。

サーバーからクライアントへ: セッション確認 (PADS)

PADSはPPPoE Active Discovery Session-confirmationの略です。[10]

上記のPADRパケットは、DSL-ACによってPADSパケットで確認され、セッションIDが発行されます。これにより、該当POPのDSL-ACとの接続が完全に確立されます。

片方の端からもう一方の端まで：終端（PADT）

PADTはPPPoE Active Discovery Terminationの略です。[10]このパケットはPOPへの接続を終了します。これはユーザーのコンピュータからでもDSL-ACからでも送信されます。

プロトコルのオーバーヘッド

PPPoEは、イーサネットリンクを介してPCまたはルーターをモデムに接続するために使用され、また、 PPPoE over ATM（PPPoEoA）over ADSLプロトコルスタックにおいて、電話回線上のDSL経由のインターネットアクセスにも使用できます。PPPoE over ATMは、例えばPPPoA（RFC 2364）と比較すると、一般的なDSL配信方法の中で最も高いオーバーヘッドを持ちます。[11] [12] [13] [14]

DSL での使用 - PPPoE over ATM (PPPoEoA)

DSL リンク上で PPPoEoA によって追加されるオーバーヘッドの量は、パケット サイズによって異なります。その理由は、(i) ATM セル パディングの吸収効果 (後述) により、PPPoEoA の追加オーバーヘッドが完全に打ち消される場合もあります。(ii) PPPoEoA + AAL5のオーバーヘッドにより、53 バイトの ATM セルが追加で必要になる場合もあります。(iii) IP パケットの場合、最大長に近いパケット ( 「MRU」 ) に追加された PPPoE オーバーヘッドによりIP フラグメンテーションが発生する場合があります。この場合も、結果として得られる IP フラグメントの両方に対して、最初の 2 つの考慮事項が適用されます。[15]ただし、ATMとIPのフラグメンテーションを今のところ無視すると、 PPP + PPPoEoAを選択した場合のATMペイロードのプロトコルヘッダーオーバーヘッドは最大44バイト（2バイト（PPPの場合）+ 6バイト（PPPoEの場合）+ 18バイト（イーサネットMAC、可変）+ 10バイト（RFC 2684 LLC、可変）+ 8バイト（AAL5 CPCS））になる可能性があります。[11]このオーバーヘッドは、RFC 2684でPPPoEoAに記述されているLLCヘッダーオプションを使用した場合に発生するオーバーヘッドです。[13] [14]

これを、はるかにヘッダー効率の高いプロトコルであるPPP + PPPoA RFC 2364 VC-MUX over ATM+DSLと比較してみましょう。このプロトコルは、ATMペイロード内のオーバーヘッドがわずか10バイトです。（実際には、10バイト = PPPの2バイト + RFC 2364の0バイト + 8（AAL5 CPCS）です。）[12] [14]

AAL5ペイロードのオーバーヘッド44バイトという数値は、2つの方法で削減できます。(i) RFC 2684の4バイトイーサネットMAC FCSを破棄するオプションを選択することで、上記の18バイトを14バイトに削減できます。(ii) RFC 2684のVC-MUXオプションを使用することで、LLCの代替オプションの10バイトのオーバーヘッドと比較して、そのオーバーヘッドはわずか2バイトです。このオーバーヘッド削減は、効率性を大幅に向上させる可能性があります。LLCの代わりにVC-MUXを使用すると、ATMペイロードのオーバーヘッドは32バイト（イーサネットFCSなし）または36バイト（FCSあり）になります。[11] [13]

ATM AAL5では、AAL5ペイロードパケットを構成する一連のATMセルの最終セル（「右寄せ」）の末尾に、8バイト長の「CPCS」トレーラーが常に存在することが求められます。LLCの場合、ATMペイロードのオーバーヘッドは、イーサネットMAC FCSが存在する場合は2 + 6 + 18 + 10 + 8 = 44バイト、FCSがない場合は2 + 6 + 14 + 10 + 8 = 40バイトとなります。より効率的なVC-MUXの場合、ATMペイロードのオーバーヘッドは、FCSが存在する場合は2 + 6 + 18 + 2 + 8 = 36バイト、FCSがない場合は2 + 6 + 14 + 2 + 8 = 32バイトとなります。

しかし、送信されるATMペイロードデータの総量に関する真のオーバーヘッドは、単純に固定された追加値ではありません。0バイトまたは48バイトのいずれかになります（前述のシナリオ（iii）であるIPフラグメンテーションは別として）。これは、ATMセルが固定長でペイロード容量が48バイトであるため、追加ヘッダーによってAAL5ペイロードの容量がさらに増えると、超過分を含むATMセルを1つ送信する必要があるためです。最後の1つまたは2つのATMセルには、各セルのペイロードが48バイト長になるように、必要に応じてパディングバイトが含まれています。[11] [13]

例：PPPoEoAとRFC2684-LLCを用いてAAL5/ATMで1500バイトのIPパケットを送信する場合（最終セルパディングは考慮しません）、イーサネットFCSが存在する場合は1500 + 2 + 6 + 18 + 10 + 8（AAL5 CPCSトレーラー）= 1544バイト、FCSがない場合は+ 2 + 6 + 14 + 10 + 8 = 40バイトとなります。ATMで1544バイトを送信するには、48バイトのATMセルが33個必要です。これは、利用可能なペイロード容量である32セル×48バイト/セル=1536バイトでは十分ではないためです。これをPPP + PPPoAの場合と比較してみましょう。PPPoAの場合は、1500 + 2 (PPP) + 0 (PPPoA: RFC 2364 VC-MUX) + 8 (CPCSトレーラー) = 1510バイトとなり、32セルに収まります。したがって、1500バイトのIPパケットにPPPoEoAとRFC2684-LLCを選択した場合の実際のコストは、IPパケットあたり1つのATMセルの追加となり、比率は33:32となります。[11] [12] [13]したがって、1500バイトのパケットの場合、LLCを使用したPPPoEoAは、PPPoAまたはPPPoEoAヘッダーオプションの最適な選択よりも約3.125%遅くなります。

いくつかのパケット長では、PPPoA と比較して PPPoEoA を選択することによる実際の追加の有効 DSL オーバーヘッドは、その特定のパケット長で追加のヘッダー オーバーヘッドが追加の ATM セルを必要とするほどでない場合、ゼロになります。たとえば、RFC2684-LLC と FCS を使用して PPP + PPPoEoA で送信された 1492 バイト長のパケットでは、合計 ATM ペイロードはちょうど 1492 + 44 = 1536 バイト = 32 セルとなり、この特殊なケースでのオーバーヘッドは、1492 + 2 + 0 + 8 = 1502 バイトの ATM ペイロード = 32 セルを必要とするヘッダー効率の高い PPPoA プロトコルを使用した場合よりも大きくなりません。[11] [13]パケット長が 1492 の場合、比率の点では RFC2684-LLC を使用した PPPoEoA の最適効率を表します

RFC2684 VC-MUXヘッダーオプションをPPPoEoAで使用すると、LLCオプションを使用する場合よりも常にはるかに効率的です。これは、前述のようにATMオーバーヘッドが32バイトまたは36バイト（PPPoEoAのイーサネットFCSオプションの有無によって異なります）であるため、VC-MUXを使用するPPP + PPPoEoAのすべてのオーバーヘッドを含む1500バイト長のパケットは、FCSが存在する場合、合計1500 + 36 = 1536バイトのATMペイロードに相当し、正確に32個のATMセルになり、ATMセル全体を節約できます。[11] [13]

パケットが短い場合、ヘッダーのオーバーヘッドが長いほど、追加の ATM セルが生成される可能性が高くなります。最悪のケースでは、ヘッダーのオーバーヘッドが 10 バイトのヘッダーのオーバーヘッドと比較して 44 バイトであるため、2 つではなく 3 つの ATM セルが送信されることがあり、データの送信に 50% 多くの時間がかかります。たとえば、IPv6 経由の TCP ACK パケットは 60 バイト長で、PPPoEoA + LLC のオーバーヘッドが 40 または 44 バイトの場合、48 バイトの ATM セルのペイロードが 3 つ必要になります。比較すると、PPPoA ではオーバーヘッドが 10 バイトなので、合計 70 バイトが 2 つのセルに収まります。そのため、PPPoA ではなく PPPoE/LLC を選択することによる追加コストは、50% の追加データが送信されることです。ただし、PPPoEoA + VC-MUX では問題ありません。オーバーヘッドが 32 または 36 バイトであれば、IP パケットは依然として 2 つのセルに収まります。

いずれの場合も、ATMベースのADSLインターネットアクセスにおいて最も効率的な選択肢は、PPPoA (RFC2364) VC-MUXを選択することです。ただし、PPPoEoAが必要な場合は、イーサネットFCSなしのVC-MUX（LLCではなく）を使用するのが最善の選択です。この場合、ATMペイロードのオーバーヘッドは32バイト（2バイト（PPPの場合）+ 6バイト（PPPoEの場合）+ 14バイト（イーサネットMAC、FCSなし）+ 2バイト（RFC 2684 VC-MUX）+ 8バイト（AAL5 CPCSトレーラー）となります。

残念ながら、一部のDSLサービスではPPPoEで無駄なLLCヘッダーを使用する必要があり、より効率的なVC-MUXオプションは使用できません。そのような場合、最大MTUを1492に設定するなど、パケット長を短縮することで、LLCヘッダーを含む長いパケットでも効率が向上します。また、前述のように、無駄なATMセルは生成されません。

イーサネットのオーバーヘッド

イーサネット LAN では、IP フラグメンテーションが生成されない限り、PPP + PPPoE のオーバーヘッドは 2 + 6 = 8 バイトに固定されます。

MTU/MRU

PPPoE 対応の DSL モデムが、イーサネット リンクを介してルータ(または PPPoE 対応の単一の PC) への PPP + PPPoE ペイロードを含むイーサネット フレームを送受信する場合、PPP + PPPoE により、各イーサネット フレームのペイロード内に 8 バイト = 2 (PPP) + 6 (PPPoE) の追加オーバーヘッドが発生します。この追加オーバーヘッドにより、送受信される IP パケットの最大長制限 (いわゆる「MTU」または「MRU」 ) が、標準のイーサネット ネットワークに適用される通常の 1500 バイトのイーサネット フレーム ペイロード長制限ではなく、1500 - 8 = 1492 バイトに短縮されます。一部のデバイスは RFC 4638 をサポートしており、これは 1508 バイトのイーサネット ペイロードを持つ非標準のイーサネット フレーム (「ベビージャンボ フレーム」と呼ばれることもある) の使用をネゴシエーションして、完全な 1500 バイトの PPPoE ペイロードを許可することを意味します。この機能は、IP パケットを受信する企業が (誤って) すべてのICMP応答を自社のネットワークから出ないようにブロックすることを選択したような場合に多くのユーザーにとって有利です。これは、パス MTU 検出が正しく機能しないという悪い習慣であり、MTU が 1500 バイト未満の場合にそのようなネットワークにアクセスするユーザーに問題を引き起こす可能性があります。

PPPoEからPPPoAへの変換ADSLモデム

次の図は、イーサネット接続されたADSLモデムがPPPoEからPPPoAへのプロトコルコンバータとして機能し、サービスプロバイダがPPPoAサービスを提供しているもののPPPoEに対応していないというシナリオを示しています。このプロトコルチェーンにはPPPoEoAは含まれていません。これは、イーサネットでルーターに接続された独立したADSLモデムのための、プロトコル効率を最適化した設計です。

この代替技術において、PPPoEはDSLモデムをイーサネット専用ルーター（あるいは単一のホストPC）に接続するための手段に過ぎません。ここでは、ISPがブロードバンドサービスを提供するために採用しているメカニズムとは関係ありません。

Draytek Vigor 110、120、および 130 モデムはこのように動作します。

PPPoE対応イーサネットルーターは、インターネット宛てのパケットを送信する際、イーサネットフレームを（同じくPPPoE対応の）DSLモデムに送信します。モデムは受信したPPPoEフレームからPPPフレームを抽出し、RFC 2364（PPPoA）に従ってカプセル化してDSLAMに送信します。これにより、PPPoEがPPPoAに変換されます。

DSLインターネットアクセスアーキテクチャ
PCまたはゲートウェイDSLモデムDSLAMリモート アクセス サーバー（ISP）
（IP）（IP）
イーサネット購買力平価購買力平価購買力平価購買力平価
PPPoEPPPoEPPPoAPPPoAL2TPL2TP
イーサネットイーサネットAAL5AAL5バックボーンバックボーンIPIP
ATMATM
DSLDSL

図では、「バックボーン」として示されているエリアは、古いネットワークではATMである可能性もありますが、そのアーキテクチャはサービスプロバイダーによって異なります。より詳細で、サービスプロバイダー固有の図では、このエリアに追加の表セルが配置されるでしょう。

癖

確立されたポイントツーポイント接続のMTUは標準的なイーサネットのMTU（通常1492、イーサネットの1500）よりも低いため、ファイアウォールの設定が不十分なためにパスMTU検出が失敗すると、問題が発生することがあります。プロバイダのネットワークではより高いMTUが一般的になりつつありますが、通常はTCP MSS（最大セグメントサイズ）の「クランプ」または「書き換え」を使用することで回避できます。これにより、アクセスコンセントレータがMSSを書き換え、TCPピアが送信するデータグラムのサイズを小さくします。TCP MSSクランプはTCPのMTU問題を解決しますが、ICMPやUDPなどの他のプロトコルは依然として影響を受ける可能性があります。

RFC 4638 では、基盤となるイーサネット層がジャンボ フレームに対応している場合、PPPoE デバイスが 1492 を超える MTU をネゴシエートすることを許可しています。

一部のベンダー（Cisco [16]やJuniper [要出典]など）は、PPPoE[oA] を PPPoEoE (PPPoE over Ethernet) と区別しています。PPPoEoE は、イーサネットまたはその他の IEEE 802 ネットワーク上、または ATM でブリッジされたイーサネット上で直接実行される PPPoE です。これは、PPPoEのRFC 2684 およびSNAPカプセル化を使用した ATM 仮想回線上で実行される PPPoE である PPPoEoA (PPPoE over ATM) と区別するためです。[要出典] （PPPoEoA は、SNAP を使用しないPoint-to-Point Protocol over ATM (PPPoA)とは異なります）。

Cisco社の資料によると、「PPPoEoEはPPPoEの変種であり、レイヤ2トランスポートプロトコルがATMではなくイーサネットまたは802.1q VLANになっています。このカプセル化方式は、メトロイーサネットまたはイーサネットデジタル加入者線アクセスマルチプレクサ（DSLAM）環境で一般的に使用されています。一般的な導入モデルとしては、このカプセル化方式はマルチテナントビルやホテルでよく見られます。加入者にイーサネットを提供することで、利用可能な帯域幅が大幅に増加し、さらなるサービス提供の容易性が向上します。」[16]

Draytek Vigor 120などのDSLモデムでは、PPPoEがDSLモデムとパートナールーター間のイーサネットリンクに限定されており、ISPがPPPoEをまったくサポートしていない（PPPoAをサポートしている）場合があります。[17]

DSL以降の用途とこれらの状況におけるいくつかの代替手段

PPPoEをGPONと組み合わせて使用​​する特定の方法（ OMCI経由でVLANを作成する方法）は、 ZTEによって特許取得されています。[18]

PPPoE over GPONは、オーストラリアのNational Broadband NetworkのInternode、[19]、フランスのOrange [20]、ウルグアイのAntel [21 ]、フィリピンのGlobe Telecom [22]、イタリアのAruba FTTH [23]などの小売サービスプロバイダーによってOpenFiberパブリックGPONネットワーク上で使用されていると報告されています。

RFC 6934「PONベースのブロードバンドネットワークへのアクセスノード制御メカニズムの適用性」は、加入者アクセスの認証やIPアドレスの管理などのためにPONにおけるアクセスノード制御プロトコルの使用を主張しており、その筆頭著者はVerizon社の社員である。このRFCでは、PPPoEはGPONの許容可能なカプセル化方式として除外されている。「BPONにおけるプロトコルカプセル化は、[RFC2684]で定義されているATMアダプテーション層5（AAL5）上のマルチプロトコルカプセル化に基づいています。これは、[RFC2516]で定義されているPPP over Ethernet（PPPoE）またはIP over Ethernet（IPoE）をカバーします。GPONにおけるプロトコルカプセル化は常にIPoEです。」[24]

10G-PON（XG-PON）規格（G.987 ）は、G.984から継承されたOMCI方式に加えて、ONUとOLTの802.1X相互認証を規定している。[25] G.987は、ONU以外の顧客構内機器（MDU内など）の認証もサポートしているが、これはイーサネットポートに限定され、やはり802.1Xで処理される。（このシナリオでは、ONUはEAPでカプセル化されたRADIUSメッセージをスヌーピングし、認証が成功したかどうかを判断することになっている。）[26] OMCI規格ではPPPoEのサポートがわずかながら規定されているが、それはONUがカプセル化（およびその他のパラメータ）に基づいてトラフィックをフィルタリングしVLANタグを追加できることのみであり、ONUが識別できなければならないプロトコルの中にPPPoEも含まれている。[27]

ブロードバンドフォーラムのTR-200「TR-101の文脈におけるEPONの使用」（2011年）は10G-EPONにも関連しており、「OLTと複数加入者ONUは、セクション3.9.2/TR-101に規定されているPPPoE中間エージェント機能を実行できなければならない」と規定している。[28]

イーサネットのファーストマイルに関する書籍では、IPセッション用にホストを構成する際にPPPoEの代わりにDHCPを使用できることは明らかであると述べられているが、カプセル化も必要な場合（VLANブリッジはこの機能を実現できるが）、DHCPはPPPoEの完全な代替手段ではないと指摘している。さらに、DHCPは（加入者）認証を提供しないため、PPPoEを使用しない「完全なソリューション」にはIEEE 802.1Xも必要であると示唆している。[29]（本書では、PPPoEはカプセル化以外にも、ホスト構成用のIPCPや認証用のPAPまたはCHAPなど、PPPの他の機能にも活用されると想定している。）

セキュリティ上の理由から、電力線通信ネットワークなどの（DSL/ATM以外の）共有メディア環境でPPPoEを使用して、顧客ごとに個別のトンネルを作成する必要があります。[30]

PPPoEはFTTxを含むWAN回線で広く利用されています。ISPが提供する多くのFTTx住宅用ゲートウェイには、ルーティング機能が統合されています。

参照

参考文献

  1. ^ James Boney (2005). Cisco IOS in a Nutshell. O'Reilly Media, Inc. p. 88. ISBN 978-0-596-55311-1。
  2. ^ ab Philip Golden、Hervé Dedieu、Krista S. Jacobsen (2007). DSL技術の実装と応用. Taylor & Francis. p. 479. ISBN 978-1-4200-1307-8。
  3. ^ 「Windows XPでPPPoE接続を作成する方法」。2013年12月3日時点のオリジナルよりアーカイブ。2013年12月11日閲覧。
  4. ^ 「Linuxの設定」www.tldp.org . 2019年3月26日閲覧。
  5. ^ 「PPPoEでインターネットに接続する（Mac OS X v10.5以前）」Appleサポート。 2019年3月26日閲覧。
  6. ^ Wind River Systems、RouterWare, Inc.を買収。Findarticles.com (1999年7月5日). 2011年9月27日閲覧。Wayback Machineに2005年5月26日アーカイブ。
  7. ^ ab Michael Beck (2005). Ethernet in the First Mile: The IEEE 802.3ah EFM Standard . McGraw Hill Professional. p. 27. ISBN 978-0-07-146991-3。
  8. ^ Richard D. Gitlin、Sailesh K. Rao、Jean-Jacques Werner、Nicholas Zervos (1990年5月8日). 「例えば電話局と顧客構内との間のデジタル信号の広帯域伝送方法および装置」.米国特許第4,924,492号.
  9. ^ 「TouchWave、VoIP組み込み通信ソフトウェアでTelogy Networksと提携」Business Wire、1998年10月5日。 2008年12月16日閲覧。[リンク切れ]
  10. ^ abcde Mamakos, L.; Simone, D.; Wheeler, R.; Carrel, D.; Evarts, J.; Lidl, K. (1999年2月). 「PPP Over Ethernet (PPPoE) の送信方法」 . tools.ietf.org . doi :10.17487/RFC2516 . 2019年3月26日閲覧。
  11. ^ abcdefg Dirk Van Aken、Sascha Peckelbeen ADSLアクセスネットワークにおけるカプセル化オーバーヘッド Archived 12 April 2021 at the Wayback Machine、2003年6月
  12. ^ abc Kaycee, Manu; Gross, George; Malis, Andrew; Stephens, John; Lin, Arthur (1998年7月). 「PPP Over AAL5」 . tools.ietf.org . doi :10.17487/RFC2364 . 2019年3月26日閲覧。
  13. ^ abcdefg Grossman, Dan; Heinanen, Juha (1999年9月). 「ATMアダプテーション層5におけるマルチプロトコルカプセル化」 . tools.ietf.org . doi :10.17487/RFC2684 . 2019年3月26日閲覧。
  14. ^ abc 「サイモン・ファーンズワースの記事」farnz.org.uk . 2019年3月26日閲覧。
  15. ^ ADSLアクセスネットワークにおけるカプセル化オーバーヘッド。[永久リンク切れ]
  16. ^ ab 「ブロードバンドアクセス集約について」(PDF)シスコシステムズ2005年5月2日
  17. ^ “Vigor120 - DrayTek Corp”. 2014年2月23日時点のオリジナルよりアーカイブ。2014年2月10日閲覧。
  18. ^ 「ギガビット対応パッシブ光ネットワークシステムとそれによって実現されるイーサネット経由ポイントツーポイントプロトコル構成方法」。google.com 。2019年3月26日閲覧。
  19. ^ “Internode :: Support :: Guides :: Internet Access :: NBN :: FTTP”. www.internode.on.net . 2013年9月13日時点のオリジナルよりアーカイブ。
  20. ^ “TP-Linkの新コミュニティが正式に開始！ - TP-Linkコミュニティ”. community.tp-link.com . 2019年3月26日時点のオリジナルよりアーカイブ。 2019年3月26日閲覧。[検証に失敗しました]
  21. ^ "Wi-Fi の概要".アンテル（スペイン語）。アンテル。
  22. ^ “YouTube”. www.youtube.com . 2014年6月8日時点のオリジナルよりアーカイブ。2019年3月26日閲覧。[検証に失敗しました]
  23. ^ "ルーターとモデムの ADSL の設定 | Guide Aruba".ガイドのアルバです。2022 年3 月 10 日に取得。
  24. ^ Bitar, Nabil N.; Wadhwa, Sanjay; Haag, Thomas; Hongyu, Li (2013年6月). 「RFC 6934 - Passive Optical Networks (PONs) に基づくブロードバンドネットワークへのアクセスノード制御メカニズムの適用性」. datatracker.ietf.org . 2019年3月26日閲覧。
  25. ^ Dave Hood & Elmar Trojer (2012).ギガビット対応パッシブ光ネットワーク. John Wiley & Sons. p. 200. ISBN 978-1-118-15558-5。
  26. ^ Dave Hood & Elmar Trojer (2012).ギガビット対応パッシブ光ネットワーク. John Wiley & Sons. p. 207 and 274–275. ISBN 978-1-118-15558-5。
  27. ^ Dave Hood & Elmar Trojer (2012).ギガビット対応パッシブ光ネットワーク. John Wiley & Sons. p. 261 and 271. ISBN 978-1-118-15558-5。
  28. ^ 「Broadband Forum 公開リソース - リソース - BBF Wiki」(PDF) . www.broadband-forum.org . 2025年3月31日閲覧。
  29. ^ Michael Beck (2005). Ethernet in the First Mile: The IEEE 802.3ah EFM Standard . McGraw Hill Professional. p. 241. ISBN 978-0-07-146991-3。
  30. ^ Xavier Carcelle (2009). 電力線通信の実践. Artech House. p. 235. ISBN 978-1-59693-336-1。
  • RFC 2516 - PPP over Ethernet (PPPoE) の伝送方法
  • RFC 3817 - PPP over Ethernet (PPPoE) 用レイヤー 2 トンネリング プロトコル(L2TP) アクティブ ディスカバリ リレー
  • RFC 4638 - Point-to-Point Protocol over Ethernet (PPPoE) における 1492 を超える最大伝送単位/最大受信単位 (MTU/MRU) の対応
  • RFC 4938 - クレジットフローとリンクメトリックのための PPP Over Ethernet (PPPoE) 拡張
  • 米国特許6891825 - パケット交換ネットワークへのマルチユーザーアクセスを提供する方法およびシステム
  • TR-043 - ATM/DSLを用いたデータネットワークへのアクセスにおけるUインターフェースプロトコル、第1.0版、2001年8月

Retrieved from "https://en.wikipedia.org/w/index.php?title=Point-to-Point_Protocol_over_Ethernet&oldid=1311351782"