Loading article…
PPPoE ( Point -to-Point Protocol over Ethernet ) は、Point-to-Point Protocol (PPP) フレームをEthernetフレーム内にカプセル化するためのネットワーク プロトコルです。これは、 DSLのブームの文脈で 1999 年に登場し、DSL 接続を介してパケットをインターネット サービス プロバイダ(ISP) のIPネットワークにトンネルし、そこからインターネットの残りの部分に接続するソリューションとして機能しました。2005 年のネットワークの本には、「ほとんどの DSL プロバイダは、認証、暗号化、圧縮を提供する PPPoE を使用しています」と記載されています。 [ 1 ] PPPoE の一般的な使用法は、 PAPプロトコルまたはCHAPを介してユーザー名とパスワードを使用してユーザーを認証するために PPP 機能を利用することです。PAP は 2007 年に主流でしたが、 PAP は平文プロトコルであるため、サービス プロバイダはより安全な CHAP に移行しています。 [ 2 ] 2000年頃、PPPoEは、イーサネットLANを介してコンピュータやルーターに接続されたモデムと通信するための代替方法として普及し始め、それまで使われていたUSB方式に取って代わりました。ルーターとモデムをイーサネット経由で接続するというこのユースケースは、今日でも非常に一般的です。
顧客宅内機器では、PPPoE は、 DSLモデムとIP ルーティング機能の両方を処理する統合住宅用ゲートウェイデバイスで実装される場合もあれば、単純なDSL モデム(ルーティング サポートなし)の場合は、PPPoE は、その背後にある別のイーサネット専用ルーター、あるいはユーザーのコンピューターで直接処理される場合もあります。 (PPPoE のサポートは、Windows XP [ 3 ]、Linux [ 4 ] 、 Mac OS X [ 5 ]など、ほとんどのオペレーティングシステムに存在します) 最近では、GPONベース (DSL ベースではなく) の住宅用ゲートウェイでも PPPoE が使用されていますが、 ITU-T勧告 G.984.1「ギガビット対応パッシブ光ネットワーク (GPON)：一般特性」で言及されているものの、GPON 規格における PPPoE の地位は限定的です。
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は、イーサネットインフラストラクチャを共有する異なるIPフローを区別するために使用できるため、 MPLSと基本的な意味で類似した「レイヤ2.5」プロトコルとして一部の書籍で説明されています[ 2 ] [ 7 ]。ただし、PPPoEヘッダーに基づいてルーティング決定を行うPPPoEスイッチがないため、その点での適用範囲は制限されます。[ 7 ]
1998年後半の時点では、DSLサービスモデルはまだ家庭レベルまで価格を引き下げるほど大規模には普及していませんでした。ADSL技術は10年前に提案されていました。[ 8 ]機器ベンダー と通信事業者はともに、ケーブルモデムやDSLなどのブロードバンドがいずれダイヤルアップサービスに取って代わることを認識していましたが、ハードウェア（顧客宅内とLECの両方）は、少量展開におけるコスト面で大きな障壁に直面していました。DSLの少量展開に関する初期の見積もりでは、DSLモデムのコストは300～500米ドル（2025年には593～988米ドル）の範囲で、通信事業者からの月額アクセス料金は300米ドルと示されており、これは家庭ユーザーが支払う金額をはるかに超えていました。そのため、当初は小規模事業者や在宅ビジネス顧客に焦点を当てていました。1.5 Mbit/sのT1回線（当時月額800～1500米ドル）は経済的ではなかったが、ダイヤルアップやISDNで提供できる以上の速度を必要とする人はどれほどいただろうか。こうした顧客が十分に集まれば、価格が下がり、家庭用ダイヤルアップユーザーが興味を持つような価格帯になるだろう。
問題は、中小企業の顧客は家庭用ダイヤルアップユーザーとは異なる利用プロファイルを持っていたことであり、具体的には以下の点が挙げられる。
これらの要件は、ダイヤルアップ接続の確立遅延や、1台のコンピュータと1台のISPを接続するモデル、さらにはNATとダイヤルアップを組み合わせた多対1の接続モデルにも適していなかった。新たなモデルが必要とされた。
PPPoEは主に以下のいずれかの用途で使用されます。
これらのニーズを満たすために全く新しいプロトコルを作成する際の問題点の1つは時間でした。機器とサービスはすぐに利用可能でしたが、全く新しいプロトコルスタックの開発（当時マイクロソフトは光ファイバーベースのATMセルからデスクトップへの接続を提唱しており[ 9 ]、L2TPも開発中でしたが完成には程遠い状態でした）には実装に非常に時間がかかり、好機を逃してしまう可能性がありました。完全なソリューションを迅速かつ低コストで提供するために、実装と標準化を簡素化するためのいくつかの決定がなされました。
PPPoEは、広く普及しているイーサネットインフラと、広く普及しているPPPを統合することで、ベンダーが既存のソフトウェアを再利用し、ごく短期間で製品を提供できるようにすることを目指していました。当時、ほぼすべてのオペレーティングシステムにPPPスタックが搭載されており、PPPoEの設計では、シンプルなラッパー/シムを用いることで、PPPフレームをイーサネットフレーム内にカプセル化することが可能でした。
競合するWAN技術（T1、ISDN）では、顧客宅内にルーターが必要でした。PPPoEは異なるイーサネットフレームタイプを使用するため、DSLハードウェアは単なるブリッジとして機能し、一部のフレームをWANに転送し、残りを無視することができます。このようなブリッジの実装は、ルーターに比べて桁違いに簡単です。
RFC 2516が当初、標準化トラックではなく情報提供を目的としたRFCとしてリリースされたのも、同じ理由からです。標準化トラックのRFCを採用するには、非常に長い期間を要するためです。
2000年頃、PPPoEプロトコルは、(i) DSLモデムをコンピュータやルータに接続するために使用され、以前のUSBを使用する方法に取って代わりました。または、(ii) PPP+PPPoEの3つのプロトコルヘッダーを使用して、ルータをネットワークノード、つまりプロトコルコンバータに接続しました。このネットワークノードは、ISPまたは卸売長距離通信事業者に属し、ISPのIPネットワークに接続してからインターネットに接続します。[ 10 ]
最初のユースケースであるルーターとモデムの接続は、いわゆる「PPPoEoE」（物理的なイーサネットLAN上でPPPoEプロトコルの3つを組み合わせたもの）を使用しており、PPPを使用する場合、モデムとルーターを接続するために今日でも広く使用されています。
2番目のユースケース、つまりPPPoEプロトコルの3つを、上流に多かれ少なかれ深く到達する1つ以上のインターネットアクセスリンクで使用するケースは、一般的には歴史的な理由からのみ使用されていると考えられています。しかし、PPPは、ISPが卸売アクセスキャリア/リセラーを使用する場合に必要なトンネリングプロトコルとして、またはPPPの機能が望ましいという理由で、あるいはその両方の理由で、一部のISPの間で依然として人気があります。
前述したように、奇妙なことに、イーサネットプロトコルが使用されていない場合、つまりイーサネットネットワーク上に物理的に存在しない場合でも、PPPoEヘッダーとともにイーサネットMACヘッダーが使用されていることがあります。これは、いわゆるブロートと呼ばれる、不要なヘッダーオーバーヘッドをさらに追加する以外に何の役にも立たないようです。たとえば、後述するPPPoEoAの場合、物理的なイーサネットがなくATMのみが存在する場合、不要なイーサネットMAC層のヘッダーオーバーヘッドが追加されただけでなく、イーサネットをATM上に適合させるための追加のイーサネット適応層も追加されました。
2番目の使用例では、これらの追加のプロトコルヘッダーによってデータ量が大幅に増加し、パフォーマンスがわずかに低下します。
2番目のユースケースでは、PPP+PPPoE+Ethernet MACの使用範囲は、上流の可変距離まで広がります。ADSLまたはVDSL2 / FTTCの銅線ツイストペアケーブル（モデムを含む）の「ファーストマイル」に限定される場合もあれば、BRAS（ブロードバンドリモートアクセスサーバー）または「アクセスコンセントレータ」まで上流に拡張して使用される場合もあります。BRASはログインを処理する場合もしない場合もありますが、何らかのプロトコルコンバータであることは間違いありません。ある例では、PPPoEは上流に拡張され、卸売キャリアが運用するノードで終端します。このノードはL2TPトンネルプロトコルに変換し、ISPのIP POP（「接続ポイント」）までトンネル接続します。
PPPoEには2つの明確な段階があります。
従来のPPP接続は、シリアルリンクまたはダイヤルアップ時に既に確立されたATM仮想回線を介して2つのエンドポイント間で確立されるため、ワイヤ上で送信されるすべてのPPPフレームは確実に相手側に到達します。しかし、イーサネットネットワークはマルチアクセスであり、ネットワーク内の各ノードは他のすべてのノードにアクセスできます。イーサネットフレームには、宛先ノードのハードウェアアドレス（MACアドレス）が含まれています。これにより、フレームは目的の宛先に到達します。
したがって、イーサネット経由で接続を確立するためにPPP制御パケットを交換する前に、2つのエンドポイントのMACアドレスを互いに認識しておく必要があります。そうすることで、MACアドレスを制御パケットにエンコードできるからです。PPPoEディスカバリステージはまさにこの処理を行います。また、このステージは、その後のパケット交換に使用できるセッションIDの確立にも役立ち、セッションの終了を示すためにも使用されます。
PPPoE検出パケットは、 EtherTypeが0x8863に設定されたイーサネットフレームで伝送されます。
ピアのMACアドレスが判明し、セッションが確立されると、セッション段階が開始されます。この段階では、PPPデータのチャンクがPPPoEパケットにカプセル化され、相手ピアに送信されます。最初のセッションパケットは通常どおりPPPセッションのネゴシエーションを行い、その後はほとんどのセッションパケットにPPPデータのチャンクが含まれます。
カプセル化は、PPPチャンクの先頭に6バイトのPPPoEヘッダーを付加し、EtherTypeを0x8864に設定したイーサネットフレームで伝送することによって行われます。
従来のPPPはピアツーピアプロトコルであるのに対し、PPPoEは複数のホストが単一の物理接続を介してサービスプロバイダに接続できるため、本質的にクライアント・サーバの関係である。
検出プロセスは、クライアントとして機能するホストコンピュータと、ISP側のサーバーとして機能するアクセスコンセントレータとの間で、4つのステップで構成されます。以下にその概要を示します。5番目で最後のステップは、既存のセッションを閉じる方法です。
PADIはPPPoE Active Discovery Initiationの略です。[ 11 ]
ユーザーがDSLを使用してインターネットにダイヤルアップ接続する場合、まずコンピュータはユーザーのISPの接続拠点（POP）にある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:ff PPP over Ethernet ディスカバリ バージョン: 1 1型 コードアクティブディスカバリー開始（PADI） セッションID: 0000 ペイロードの長さ：24 PPPoEタグ タグ: サービス名 タグ: ホスト固有 バイナリデータ：（16バイト）
Src.（送信元）には、PADIパケットを送信するコンピュータのMACアドレスが格納されます。Dst .（宛先）はイーサネットのブロードキャストアドレスです。PADI パケットは複数のDSL-AC機器で受信できます。「Service-Name」タグを処理できるDSL-AC機器のみが応答する必要があります。
PADOはPPPoE Active Discovery Offerの略です。[ 11 ]
ユーザーのコンピュータが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:df PPP over Ethernet ディスカバリ バージョン: 1 1型 コードアクティブディスカバリーオファー（PADO） セッションID: 0000 ペイロードの長さ：36 PPPoEタグ タグ: AC名 文字列データ: lpzbr001 タグ: ホスト固有 バイナリデータ：（16バイト）
AC-Name -> 文字列データには AC 名が格納されます。この例では「lpzbr001」（ライプツィヒの Arcor DSL-AC）です 。Src.には DSL-AC の MAC アドレスが格納されます。DSL -AC の MAC アドレスからは、DSL-AC の製造元（この例ではNortel Networks）もわかります。
PADRはPPPoEアクティブディスカバリ要求の略です。[ 11 ]
ユーザーのコンピュータは、DSL-ACから適切なPADOパケットを受信すると、DSL-ACにPADRパケットを送信します。これは、PADOパケットを発行したDSL-ACによるPPPoE接続の申し出を受け入れたことを確認するものです。
PADSはPPPoE Active Discovery Session-confirmationの略です。[ 11 ]
上記のPADRパケットは、DSL-ACによってPADSパケットで確認され、セッションIDが同時に発行されます。これにより、当該POPにおけるDSL-ACとの接続が完全に確立されました。
PADTはPPPoE Active Discovery Terminationの略です。[ 11 ]このパケットはPOPへの接続を終了します。これはユーザーのコンピュータまたはDSL-ACから送信される可能性があります。
PPPoE は、イーサネット リンクを介してPC またはルーターをモデムに接続するために使用され、 ADSLプロトコル スタック上のPPPoE over ATM (PPPoEoA)で電話回線上のDSLを介したインターネット アクセスにも使用できます。 PPPoE over ATM は、たとえば PPPoA (RFC 2364) と比較すると、一般的な DSL 配信方法の中で最もオーバーヘッドが大きくなっています。[ 12 ] [ 13 ] [ 14 ] [ 15 ]
DSLリンク上でPPPoEoAによって追加されるオーバーヘッドの量は、パケットサイズに依存します。これは、(i) ATMセルパディングの吸収効果（後述）により、場合によってはPPPoEoAの追加オーバーヘッドが完全に相殺されること、(ii) PPPoEoA + AAL5オーバーヘッドにより、53バイトのATMセル全体が追加で必要になること、(iii) IPパケットの場合、最大長に近いパケット（' MRU '）に追加されるPPPoEオーバーヘッドによりIPフラグメンテーションが発生する可能性があり、その結果生じる2つのIPフラグメントの両方について最初の2つの考慮事項も関係すること、によるものです。[ 16 ]ただし、現時点では ATM と IP の断片化を無視すると、 PPP + PPPoEoA を選択した場合のATM ペイロードのプロトコル ヘッダー オーバーヘッドは、最大で44 バイトになります= 2 バイト (PPP 用) + 6 バイト (PPPoE 用) + 18 バイト (イーサネット MAC、可変) + 10 バイト (RFC 2684 LLC、可変) + 8 バイト (AAL5 CPCS)。[ 12 ]このオーバーヘッドは、RFC 2684 で説明されている LLC ヘッダー オプションを PPPoEoA に使用した場合に得られるものです。[ 14 ] [ 15 ]
これに対し、はるかにヘッダー効率の高いプロトコルである PPP + PPPoA RFC 2364 VC-MUX over ATM+DSL は、ATM ペイロード内のオーバーヘッドがわずか 10 バイトです。（実際には、単純に 10 バイト = PPP の 2 バイト + RFC 2364 の 0 バイト + 8 (AAL5 CPCS) です。）[ 13 ] [ 15 ]
この 44 バイトの AAL5 ペイロード オーバーヘッドは、次の 2 つの方法で削減できます。(i) RFC 2684 オプションで 4 バイトの Ethernet MAC FCS を破棄することで、上記の 18 バイトを 14 バイトに削減します。(ii) RFC 2684 VC-MUX オプションを使用することで、オーバーヘッドは LLC の代替案の 10 バイトのオーバーヘッドと比較してわずか 2 バイトになります。このオーバーヘッドの削減は、効率の向上に大きく貢献することがわかります。LLC の代わりに VC-MUX を使用すると、ATM ペイロード オーバーヘッドは 32 バイト (Ethernet FCS なし) または 36 バイト (FCS あり) になります。[ 12 ] [ 14 ]
ATM AAL5では、AAL5ペイロードパケットを構成するATMセルの最後のセル（右寄せ）の末尾に、8バイト長の「CPCS」トレーラーが必ず存在する必要があります。LLCの場合、イーサネットMAC FCSが存在する場合はATMペイロードのオーバーヘッドは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 ペイロード データの総量に関する実際のオーバーヘッドは、固定の追加値ではなく、ゼロまたは 48 バイトのいずれかになります(前述のシナリオ (iii)、IP フラグメンテーションは除く)。これは、ATM セルは固定長で、ペイロード容量が 48 バイトであるため、追加ヘッダーによる AAL5 ペイロードの追加量が増えると、超過分を含む ATM セルを 1 つ余分に送信する必要が生じる可能性があるためです。最後の 1 つまたは 2 つの ATM セルには、各セルのペイロードが 48 バイトの長さになるように必要なパディング バイトが含まれています。[ 12 ] [ 14 ]
例として、PPPoEoAとRFC2684-LLCを使用してAAL5/ATM経由で送信される1500バイトのIPパケットの場合、現時点では最終セルのパディングを無視すると、イーサネットFCSが存在する場合は1500 + 2 + 6 + 18 + 10 + 8 (AAL5 CPCSトレーラー) = 1544バイトから始まり、FCSがない場合は+ 2 + 6 + 14 + 10 + 8 = 40バイトから始まり、1544バイトをATM経由で送信するには、33個の48バイトのATMセルが必要です。これは、利用可能なペイロード容量が32セル × 1セルあたり48バイト = 1536バイトでは十分ではないためです。これを PPP + PPPoA の場合と比較すると、1500 + 2 (PPP) + 0 (PPPoA: RFC 2364 VC-MUX) + 8 (CPCS トレーラー) = 1510 バイトが 32 セルに収まります。したがって、1500 バイトの IP パケットに対して PPPoEoA と RFC2684-LLC を選択する実際のコストは、IP パケットごとに 1 つの ATM セルが追加されることであり、比率は 33:32 です。[ 12 ] [ 13 ] [ 14 ]したがって、1500 バイトのパケットの場合、LLC 付き PPPoEoA は、PPPoA または最適な PPPoEoA ヘッダー オプションの選択よりも約 3.125% 遅くなります。
パケット長によっては、PPPoEoA を PPPoA と比較して選択することによる実際の追加の実効 DSL オーバーヘッドは、その特定のパケット長で追加の ATM セルが必要になるほどヘッダーのオーバーヘッドが十分でない場合、ゼロになります。たとえば、RFC2684-LLC と FCS を使用して PPP + PPPoEoA で送信される 1492 バイトのパケットは、合計 ATM ペイロードが 1492 + 44 = 1536 バイト = 32 セルとなり、この特殊なケースでのオーバーヘッドは、ヘッダー効率の高い PPPoA プロトコルを使用した場合よりも大きくなりません。この場合、1492 + 2 + 0 + 8 = 1502 バイトの ATM ペイロード = 32 セルが必要になります。[ 12 ] [ 14 ]パケット長が 1492 の場合、比率の観点から RFC2684-LLC を使用した PPPoEoA の最適な効率を表します。ただし、さらに長いパケットが許可されている場合は除きます。
RFC2684 VC-MUX ヘッダー オプションを使用した PPPoEoA は、LLC オプションよりも常に効率的です。これは、前述のように ATM オーバーヘッドが 32 バイトまたは 36 バイト (PPPoEoA の Ethernet FCS オプションの有無によって異なります) だけであるため、VC-MUX を使用した PPP + PPPoEoA のすべてのオーバーヘッドを含む 1500 バイトのパケットは、FCS が存在する場合、合計 1500 + 36 = 1536 バイトの ATM ペイロードに相当し、正確に 32 ATM セルとなり、ATM セル全体を節約できます。[ 12 ] [ 14 ]
パケットが短い場合、ヘッダーのオーバーヘッドが長いほど、追加の ATM セルが生成される可能性が高くなります。最悪の場合、ヘッダーのオーバーヘッドが 10 バイトの場合と比較して 44 バイトの場合、2 つの ATM セルではなく 3 つの ATM セルが送信される可能性があり、データの送信に 50% 余計に時間がかかります。たとえば、IPv6 上の TCP ACK パケットは 60 バイトの長さで、PPPoEoA + LLC のオーバーヘッドが 40 バイトまたは 44 バイトの場合、48 バイトの ATM セルのペイロードが 3 つ必要になります。比較として、オーバーヘッドが 10 バイトの PPPoA では、合計 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バイトで固定です。
PPPoE 対応の DSL モデムが、イーサネット リンクを介して PPP + PPPoE ペイロードを含むイーサネット フレームをルーター(または PPPoE 対応の PC) に送受信する場合、PPP + PPPoE は、各イーサネット フレームのペイロード内に 8 バイト (2 (PPP) + 6 (PPPoE)) の追加オーバーヘッドをもたらします。この追加オーバーヘッドにより、標準イーサネット ネットワークに適用される通常の 1500 バイトのイーサネット フレーム ペイロード長制限とは異なり、送受信される (例えば) IP パケットの最大長制限 (いわゆる「MTU」または「MRU」 ) が 1500 − 8 = 1492 バイトに短縮される可能性があります。一部のデバイスは RFC 4638 をサポートしており、1508 バイトのイーサネット ペイロードを持つ非標準イーサネット フレーム (「ベビージャンボ フレーム」と呼ばれることもあります) の使用をネゴシエートできるため、完全な 1500 バイトの PPPoE ペイロードが可能になります。この機能は、IPパケットを受信する企業が（誤って）すべてのICMP応答がネットワークから送信されるのをブロックするように設定している場合など、多くのユーザーにとって有利です。このような設定は、パスMTUの検出が正しく機能しなくなるだけでなく、MTUが1500バイト未満のユーザーがそのようなネットワークにアクセスする際に問題を引き起こす可能性があります。
次の図は、イーサネット接続されたADSLモデムがPPPoEからPPPoAへのプロトコル変換器として機能し、サービスプロバイダがPPPoAサービスを提供し、PPPoEを理解しないシナリオを示しています。このプロトコルチェーンにはPPPoEoAは含まれていません。これは、イーサネットでルータに接続された独立したADSLモデムにとって、プロトコル効率が最適な設計です。
この代替技術では、PPPoEは単にDSLモデムをイーサネット専用ルーター（または単一のホストPC）に接続するための手段にすぎません。ここでは、ISPがブロードバンドサービスを提供するために用いる仕組みとは関係ありません。
Draytek Vigor 110、120、130モデムはこのように動作します。
インターネット宛てのパケットを送信する際、PPPoE対応のイーサネットルータはイーサネットフレームを（同じくPPPoE対応の）DSLモデムに送信します。モデムは受信したPPPoEフレームからPPPフレームを抽出し、RFC 2364（PPPoA）に従ってカプセル化することでPPPフレームをDSLAMに送信し、PPPoEをPPPoAに変換します。
図中の「バックボーン」と示されている領域は、旧世代ネットワークではATMを指す場合もありますが、そのアーキテクチャはサービスプロバイダによって異なります。より詳細で、サービスプロバイダ固有の図では、この領域にさらに表形式のセルが追加されます。
確立されたポイントツーポイント接続のMTUは標準イーサネットよりも低いため（通常1492、イーサネットは1500）、ファイアウォールの設定が不十分なためにパスMTU検出が無効になると問題が発生することがあります。プロバイダのネットワークではより高いMTUが一般的になりつつありますが、通常はTCP MSS（最大セグメントサイズ）の「クランプ」または「書き換え」による回避策が取られます。これにより、アクセスコンセントレータがMSSを書き換えて、TCPピアがより小さなデータグラムを送信するようにします。TCP MSSクランプはTCPのMTU問題を解決しますが、ICMPやUDPなどの他のプロトコルには影響が残る可能性があります。
RFC 4638では、基盤となるイーサネット層がジャンボフレームに対応している場合、PPPoEデバイスが1492を超えるMTUをネゴシエートすることを許可しています。
一部のベンダー（Cisco [ 17 ]やJuniperなど）は、PPPoE[oA] を PPPoEoE (イーサネット上の PPPoE) と区別しています。PPPoEoE (イーサネット上の PPPoE) はイーサネットまたはその他のIEEE 802ネットワーク上、あるいはATM上でブリッジされたイーサネット上で直接実行されるPPPoE です。これは、PPPoEoA (ATM 上の PPPoE) と区別するためです。PPPoEoA は、RFC 2684 とSNAPカプセル化を使用して ATM 仮想回線上で実行される PPPoE です。 (PPPoEoA は、SNAP を使用しないATM 上のポイントツーポイントプロトコル(PPPoA)とは異なります)。
Cisco のドキュメントによると、「PPPoEoE は PPPoE のバリアントであり、レイヤ 2 トランスポート プロトコルが ATM ではなく Ethernet または 802.1q VLAN になっています。このカプセル化方式は、一般的にメトロ Ethernet または Ethernet デジタル加入者線アクセス多重化装置 (DSLAM) 環境で見られます。一般的な展開モデルは、このカプセル化方式が通常、複数のテナントが入居するビルやホテルで見られることです。加入者に Ethernet を提供することで、利用可能な帯域幅が大幅に増加し、さらなるサービス提供が容易になります。」[ 17 ]
Draytek Vigor 120などのDSLモデムでは、PPPoEはDSLモデムとパートナールーター間のイーサネットリンクに限定されており、ISPはPPPoEを全く使用せず（PPPoAを使用する）、PPPoEは使用しないというケースも見られる。[ 18 ]
ZTEは、 GPONとPPPoEを併用する特定の方法（OMCIを介してVLANを作成する方法）を特許取得している。[ 19 ]
PPPoE over GPONは、オーストラリアのナショナルブロードバンドネットワークのInternode [ 20 ]、フランスのOrange [ 21 ] 、ウルグアイのAntel [ 22 ]、フィリピンのGlobe Telecom [ 23 ]、イタリアのAruba FTTH [ 24 ]などの小売サービスプロバイダーによってOpenFiberのパブリックGPONネットワークで使用されていると報告されている。
RFC 6934「PON ベースのブロードバンド ネットワークへのアクセス ノード制御メカニズムの適用性」は、加入者アクセスの認証や IP アドレスの管理など、PON でのアクセス ノード制御プロトコルの使用を主張しており、その最初の著者は Verizon の従業員ですが、GPON の許容可能なカプセル化として PPPoE を除外しています。「BPON のプロトコル カプセル化は、[RFC2684] で定義されている ATM 適応レイヤ 5 (AAL5) 上のマルチ プロトコル カプセル化に基づいています。これには、イーサネット上の PPP ([RFC2516] で定義されている PPPoE) またはイーサネット上の IP (IPoE) が含まれます。GPON のプロトコル カプセル化は常に IPoE です。」[ 25 ]
10G-PON (XG-PON) 規格 ( G.987 )は、G.984から引き継がれた OMCI 方式に加えて、ONU と OLT の802.1X相互認証を提供します。[ 26 ] G.987 は、ONU 以外の顧客宅内機器(MDU 内など) の認証もサポートしますが、これは Ethernet ポートに限定され、これも 802.1X で処理されます。(このシナリオでは、ONU はEAPカプセル化されたRADIUSメッセージをスヌープし、認証が成功したかどうかを判断することになっています。) [ 27 ] OMCI 規格では PPPoE に対するある程度のサポートが指定されていますが、これは ONU がトラフィックのカプセル化 (およびその他のパラメータ) に基づいてトラフィックをフィルタリングして VLAN タグを追加できるという点に限られ、これには ONU が識別できなければならないプロトコルの中に PPPoE が含まれます。[ 28 ]
ブロードバンドフォーラムのTR-200「TR-101のコンテキストでのEPONの使用」（2011年）は、 10G-EPONにも関連しており、「OLTとマルチ加入者ONUは、セクション3.9.2/TR-101で規定されているPPPoE中間エージェント機能を実行できなければならない」と述べている。[ 29 ]
イーサネットのファーストマイルに関する書籍では、IPセッション用にホストを設定するためにPPPoEの代わりにDHCPを使用できることは明らかだが、カプセル化も必要な場合はDHCPはPPPoEの完全な代替にはならない（ただし、VLANブリッジはこの機能を果たすことができる）こと、さらにDHCPは（加入者）認証を提供しないため、PPPoEなしで「完全なソリューション」を実現するにはIEEE 802.1Xも必要であることを指摘している。 [ 30 ] （この書籍では、ホスト構成のためのIPCPや認証のためのPAPまたはCHAPなど、カプセル化以外のPPPの他の機能にもPPPoEが活用されていることを前提としている。）
電力線通信ネットワークなどの（DSL/ATM以外の）共有媒体環境でPPPoEを使用するセキュリティ上の理由としては、顧客ごとに個別のトンネルを作成する必要があることが挙げられる。[ 31 ]
PPPoEはFTTxを含むWAN回線で広く利用されています。ISPが提供する多くのFTTx住宅用ゲートウェイには、ルーティング機能が統合されています。