PPPoEセッションを徹底解説:仕組み・ヘッダ・MTU問題・運用とトラブルシューティング

はじめに

PPPoE(Point-to-Point Protocol over Ethernet)は、ブロードバンド回線、特にADSLやFTTH初期のアクセスで広く使われてきた技術です。本コラムでは「PPPoEセッション」に焦点を絞り、プロトコルの仕組み、ディスカバリとセッションの流れ、ヘッダとオーバーヘッド、MTU/MSSの問題、認証やIPCPの役割、運用・監視・トラブルシューティング、セキュリティと代替技術までを深掘りします。実務で役立つコマンドやチェックポイントも含めて解説します。

PPPoEとは何か:概念と用途

PPPoEはイーサネットを介してPPPフレームを送受信するための方法です。イーサネットのブロードキャスト/スイッチド環境上で、個々の顧客ごとに論理的なPPPセッションを確立できるため、ISPはユーザ認証、アカウンティング(RADIUS連携)や動的IP割当てなどを実現できます。PPPoEはOSI参照モデルの観点ではデータリンク層(Layer 2)に位置づけられますが、その上でPPP(Point-to-Point Protocol)が動作します。

ディスカバリとセッション — 二つのフェーズ

  • ディスカバリフェーズ:クライアント(CPE)が接続先のアクセスコンセントレータ(AC, 通常はISP側機器)を見つけ、サービス名などを交渉します。代表的なパケット:PADI(発見), PADO(応答), PADR(要求), PADS(確立), PADT(切断)。ディスカバリ時はPPPoEのセッションIDは0に設定されます。
  • セッションフェーズ:ディスカバリで決まった相手とセッションIDを用いて、実際にPPPフレームをやり取りします。ここでPPPネゴシエーション(認証、IPCPによるIPアドレス交渉等)が行われ、IP通信が可能になります。

PPPoEヘッダとフレーム構成(オーバーヘッドの詳細)

PPPoEフレームは、イーサネットヘッダの上にPPPoEヘッダが載り、その下にPPPペイロードが入ります。PPPoEヘッダ自体は6バイト(バージョン/タイプ:1, コード:1, セッションID:2, 長さ:2)で、さらにPPPのプロトコルフィールド(通常2バイト)が入るため、合計で一般に8バイトのオーバーヘッドとして扱われます。イーサネットMTUが1500バイトの場合、PPPoEを使うとデフォルトのMTUは1492バイト(1500 - 8)になります。

ディスカバリのタグとセッションID

ディスカバリパケットはTLV(Type-Length-Value)形式のタグを持ち、代表的なタグにService-Name、AC-Name、Host-Uniqなどがあります。ISPはService-Nameで提供するサービスを識別し、AC-Nameでアクセス装置の識別を行えます。セッション確立時にACはセッションID(2バイト、0は予約)を割り当て、以降のPPPoEセッションフレームはこのセッションIDを含みます。

認証・PPPネゴシエーションの役割(PAP/CHAPとIPCP)

PPPoEはPPPを運ぶため、PPPの既存機能(PAP/CHAPによる認証、LCPによるリンクの設定、IPCPによるIPアドレスの割当てとオプション交渉)をそのまま利用します。一般的なフロー:

  • LCP(Link Control Protocol)でリンクパラメータをネゴシエート
  • PAP/CHAPでユーザ認証(CHAPの方がセキュア)
  • IPCPでIPアドレス、DNS、他のオプションを交渉

ISP側ではRADIUSサーバと連携して認証・課金を行うのが一般的です。

MTU/MSSの問題と対策

前述のとおり、PPPoEは最低8バイトのオーバーヘッドを持つため、パスMTUやTCP MSSに影響します。典型的にはPPPoE環境での最大MTUは1492であり、TCPのMSSは1492 - 20(IP) - 20(TCP) = 1452バイトが安全値です。よく取られる対策:

  • ブロードバンドルータでTCP MSSクランプ(MSSを1452に設定)
  • PMTUD(Path MTU Discovery)を利用するが、途中でICMPがブロックされると機能しないためMSSクランプが確実
  • 802.1Q VLANやその他のタグを使う場合はさらにオーバーヘッドが増える点に注意(例:VLANタグは+4バイト)

PPPoEとイーサネットの関係:MACアドレス、ブリッジ、VLAN

PPPoEはイーサネット上で動作するため、ディスカバリはブロードキャスト/マルチキャスト的な方法も利用されます。PPPoEセッション自体はCPEとBRAS/AC間での一対一の論理接続ですが、物理的には同一セグメントに多数のCPEが存在します。VLANと併用することで論理分離やQoSの適用が可能です。

運用・監視・トラブルシューティングの実践的チェックリスト

以下は現場でよく使われるチェック項目です。

  • ディスカバリが成功しているか:tcpdumpやWiresharkでPPPoEディスカバリパケット(Ethertype 0x8863)を確認。セッションパケットはEthertype 0x8864。
  • 認証が通っているか:PPPログ(pppdログ、またはCPEログ)でPAP/CHAPの結果を確認。
  • IPCPでIPアドレスが割り当てられているか:pppインターフェース(例:ppp0)の状態を確認。
  • MTU/MSSの問題:大きなパケットの断片化やHTTP/TCPの遅延がある場合はMSSクランプとICMPのブロック有無をチェック。
  • セッションの切断原因:PADTやLCPのTerminateが送られていないか。回線品質やDyingGasp等の物理層イベントも確認。
  • 多数のセッションでのスケーラビリティ:BRAS側のセッション数上限、CPU負荷、メモリ消費を監視。

実際のコマンド例(代表例):

  • tcpdump -i eth0 'ether proto 0x8863 or ether proto 0x8864' -w pppoe.pcap
  • Linux: ip link show, ifconfig/ ip addr show ppp0, tail -f /var/log/messages(pppdのログ)
  • Cisco/Juniper等の機器でも専用のshowコマンドでPPPoEセッションを確認可能

セキュリティ上の注意点

PPPoE自体はリンク確立のためのフレームを提供するに過ぎず、認証方式やRADIUS連携、トラフィックフィルタリング等でセキュリティを確保する必要があります。注意点:

  • PAPは平文送信のため推奨されず、CHAPを使うか追加のトンネルを併用する。
  • MACアドレス偽装によるセッションハイジャックのリスク:ISP側でMACバインディングやRADIUS属性での制限を行う。
  • ブロードバンドルータやBRASでのログ/アラートを整備し、短時間での再接続や大量の認証失敗を検知する。

PPPoEのパフォーマンスとスケーラビリティ

PPPoEは1セッションごとに状態(セッションID、認証情報等)を持つため、BRAS側で多数のセッションを裁く際にメモリやCPUの負荷が発生します。近年の大規模ISPではDPDK等を利用した高速パケット処理、セッション管理の分散化、あるいはIPoE(DHCPベース)への移行でスケール性を確保するケースが増えています。

代替技術および今後の動向

PPPoEの代替としてはIPoE(直接IPをEthernet上で配布し、DHCPv4/v6で管理)、またはTR-069等を用いた管理方式が用いられます。IPoEはオーバーヘッドが少なく、NATやブリッジ構成との親和性も高いため、光アクセスの普及に伴い移行が進んでいます。しかし、認証や課金を細かく制御したい環境では今でもPPPoEが選ばれる場面があります。

実務的なベストプラクティス

  • ルータでMSSクランプを設定(1452)してTCPの不具合を回避。
  • CHAPかさらに安全な認証方式を採用し、RADIUSと連携してログを収集。
  • ディスカバリ/セッションパケットの監視を行い、異常な切断や再接続を早期検知。
  • VLANやQoSを併用して顧客トラフィックの分離と優先制御を行う。
  • BRASのスケーリング計画(セッション数、CPU、メモリ)を定期的に見直す。

まとめ

PPPoEセッションは、物理的に共有されたイーサネット上でPPPの利点(認証・アカウンティング・IPネゴシエーション)を提供する堅実な技術です。MTUやMSSの微妙な影響、認証方式の選択、BRASの運用負荷など実務的な課題に注意を払えば、依然として有効に機能します。一方でIPoEなどの新しい方式への移行トレンドも無視できないため、導入・運用時には将来性と互換性を見据えた設計が必要です。

参考文献