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

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米ドル（2023年には561〜935米ドル）の範囲で、電話会社からのアクセス料金は月額300米ドルでした^{[要出典] 。これは、}家庭ユーザーが支払う金額をはるかに超えていました。そのため、当初の焦点は、~1.5 Mbit/s の T1 回線(当時は月額 800 ～ 1,500 米ドル) は経済的ではありませんでしたが、ダイヤルアップや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 対応のイーサネット専用ルーターに接続されている場合。

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

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

競合する WAN テクノロジ (T1、ISDN) では、顧客の敷地内にルーターが必要でした。PPPoE は異なるイーサネット フレーム タイプを使用し、DSL ハードウェアを単なるブリッジとして機能させ、一部のフレームを WAN に渡し、他のフレームを無視しました。このようなブリッジの実装は、ルーターよりも桁違いに簡単です。

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

PPPoE は当初、小規模な LAN にインターネット全体への個別の独立した接続を提供するために設計されましたが、プロトコル自体が軽量であるため、最終的に登場したときに期待されていた家庭での使用市場に影響を与えないようにもなっていました。2 番目の点の成功については議論の余地があるかもしれませんが (パケットあたり 8 バイトは多すぎるという不満の声もあります)、PPPoE は明らかに、サービス価格を家庭ユーザーが支払う価格まで引き下げるのに十分なボリュームをもたらすことに成功しました。

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

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

2 番目の使用例は、PPPoE プロトコル トリオが、より深いまたはより浅い深さまで上流に到達する 1 つ以上のインターネット アクセス リンクで使用されるもので、コンセンサスによると、歴史的な理由からのみ、現在でも使用されています。ただし、PPP は、ISP が卸売アクセス キャリア/再販業者を使用する場合に必要となるトンネリング プロトコルとして、または PPP の機能が必要であるため、またはその両方として、一部の ISP で依然として人気があります。

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

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

2 番目の使用例では、PPP+PPPoE+Ethernet MAC の使用は、さまざまな距離の上流まで拡張されます。これは、「ファースト マイル」、つまりモデムを含むADSLまたはVDSL2 / FTTCの銅ツイスト ペアに限定される場合もありますが、さらに上流まで拡張して、ログインを処理するかどうかは不明ですが、何らかのプロトコル コンバーターとして機能する BRAS「ブロードバンド リモート アクセス サーバー」または「アクセス コンセントレーター」まで拡張して使用される場合もあります。1 つの例では、PPPoE は上流まで拡張され、卸売業者が運営するノードで終了し、そこでL2TPトンネリング プロトコルに変換されて、ISP の IP POP (「プレゼンス ポイント」) にトンネリングされます。

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

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

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

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

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

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

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

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

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

ユーザーが DSL を使用してインターネットに「ダイヤルアップ」する場合、そのコンピューターはまず、ユーザーのインターネット サービス プロバイダーのプレゼンス ポイント(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 タグ
  タグ: サービス名
  タグ: Host-Uniq
    バイナリデータ: (16 バイト)

Src. (= ソース) は、PADI を送信するコンピュータの MAC アドレスを保持します。Dst
. (= 宛先) は、イーサネット ブロードキャスト アドレスです。PADI
パケットは、複数の DSL-AC によって受信される可能性があります。「Service-Name」タグを提供できる DSL-AC 機器のみが応答する必要があります。

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:df
PPP-over-Ethernet 検出
  バージョン: 1
  タイプ1
  コードアクティブディスカバリーオファー（PADO）
  セッションID: 0000
  ペイロード長: 36
PPPoE タグ
  タグ: 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はPPPoEアクティブ検出要求の略です。^[10]

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

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

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

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

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

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]このオーバーヘッドは、PPPoEoA の RFC 2684 で説明されている 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]}

この 44 バイトの AAL5 ペイロード オーバーヘッドの数値は、次の 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 の場合、イーサネット MAC FCS が存在する場合、ATM ペイロード オーバーヘッドの合計は 2 + 6 + 18 + 10 + 8 = 44 バイト、FCS がない場合は 2 + 6 + 14 + 10 + 8 = 40 バイトです。より効率的な VC-MUX の場合、ATM ペイロード オーバーヘッドは 2 + 6 + 18 + 2 + 8 = 36 バイト (FCS あり)、または 2 + 6 + 14 + 2 + 8 = 32 バイト(FCS なし) です。

しかし、送信される ATM ペイロード データの総量に関する真のオーバーヘッドは、単純に固定された追加値ではありません。ゼロまたは 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 バイトを送信するには、32 セル × セルあたり 48 バイト = 1536 バイトという利用可能なペイロード容量では十分ではないため、33 個の 48 バイトの ATM セルが必要です。これを 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 の比率です。^{[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 セルになります。この特殊なケースでのオーバーヘッドは、ヘッダー効率の高い PPPoA プロトコルを使用した場合よりも大きくありません。PPPoA プロトコルでも、1492 + 2 + 0 + 8 = 1502 バイトの ATM ペイロード = 32 セルが必要になります。^{[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 バイトに固定されます。

PPPoE 対応の DSL モデムが、イーサネット リンクを介してルーター(または PPPoE 対応の単一の PC) に PPP + PPPoE ペイロードを含むイーサネット フレームを送受信する場合、各イーサネット フレームのペイロードには、PPP + PPPoE によって 8 バイト = 2 (PPP) + 6 (PPPoE) の追加のオーバーヘッドが含まれます。この追加のオーバーヘッドにより、送受信される (たとえば) IP パケットの最大長制限 (いわゆる「MTU」または「MRU」 ) が 1500 − 8 = 1492 バイトに短縮されます。これは、標準のイーサネット ネットワークに適用される通常の 1500 バイトのイーサネット フレーム ペイロード長制限とは対照的です。一部のデバイスは 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 は標準イーサネットの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ネットワーク上で直接実行されるPPPoE 、またはATMでブリッジされたイーサネット上で実行されるPPPoEです。これは、PPPoEoA（PPPoE over ATM）と区別するためです。PPPoEoAは、RFC 2684とPPPoEのSNAPカプセル化を使用してATM仮想回線上で実行されるPPPoEです。^[要出典] （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]

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

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

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

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

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

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

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

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

• ATM 上のマルチプロトコル カプセル化
• ポイントツーポイント プロトコル デーモン
• ポイントツーポイント トンネリング プロトコル
• ATM 経由のポイントツーポイント プロトコル(PPPoA)
• X 経由のポイントツーポイント プロトコル(PPPoX)

• RFC 2516 - PPP over Ethernet (PPPoE) の送信方法
• RFC 3817 - PPP over Ethernet (PPPoE) 用のレイヤー 2 トンネリング プロトコル(L2TP) アクティブ ディスカバリ リレー
• RFC 4638 - ポイントツーポイント プロトコル オーバー イーサネット (PPPoE) で 1492 を超える最大転送単位/最大受信単位 (MTU/MRU) に対応する
• RFC 4938 - クレジット フローとリンク メトリックの PPP Over Ethernet (PPPoE) 拡張
• 米国特許 6891825 - パケット交換ネットワークへのマルチユーザーアクセスを提供する方法およびシステム
• TR-043 - ATM/DSL を使用してデータ ネットワークにアクセスするための U インターフェイスのプロトコル、発行 1.0、2001 年 8 月