要約

  • RFC 2516はPPPoEのPPP MTUを1,492バイトに制限した。1,500バイトのEthernetペイロードのうち、6バイトをPPPoEヘッダー、2バイトをPPP Protocol IDが使うためだ。
  • RFC 4638は、より大きなMTU/MRUを任意の能力交渉にした。クライアント、アクセスコンセントレーター、インターフェース設定、途中のEthernet区間がすべて対応して初めて、追加の8バイトを運べる。

上限は引き算で決まった

Ethernetのペイロードが1,500バイトなら、1,500バイトのインターネットパケットも入るように見える。ところがPPPoEはパケットが回線に出る前に8バイトを使う。6バイトはPPPoE自身のヘッダー、2バイトはPPPのプロトコル識別子だ。1999年2月、RFC 2516は標準的なEthernet区間でPPP MTUを1,492バイトと定めた。

計算は単純だ。難しいのは、加入者側のアクセス機器がEthernetを使うようになっても、なぜブロードバンド事業者がPPPを残したのかという問いだった。

ブロードバンド事業者が欲しかったのはEthernetと加入者ごとのセッション

RFC 2516の理由は運用上のものだった。Ethernetなら加入者宅のブリッジの背後にある複数の端末を低コストで接続できる。PPPなら利用者ごとのアクセス制御、課金、サービスセッションを維持できる。家庭内では同じローカルネットワークを共有しつつ、事業者側では加入者ごとに別のPPPセッションを持てた。

その取引では、各パケットが8バイトを負担した。事業者はセッションの境界を保ち、加入者のIPパケットは標準的な1,500バイトのEthernetペイロード内で8バイト分の余地を失った。RFC 2516は次のリンクに余裕があるか機器に推測させず、上限を明示した。

片側が1,500バイトのPPP単位を想定し、もう片側が1,492バイトで交渉すると、その差が表面化する。RFC 4638の2006年の序文は、このように条件の異なるブロードバンド経路で大量のフラグメントが生じうると説明した。拡張の狙いは、新世代のブロードバンドネットワークでその分割を減らすことだった。

8バイトは能力交渉の対象になった

RFC 4638は、すべてのPPPoEセッションを1,492バイト超にしたわけではない。文書が説明する次世代ブロードバンド設計では、PPPoEサーバーとして動くBRASに、この値を超える交渉への対応を求めている。実際に使えるかは、任意の PPP-Max-Payload タグを使って個々のクライアントとサーバーが判断する。2バイトのタグ値は、クライアントが送受信の両方向で処理できるPPPペイロードの最大値を示す。1,492バイトを超える値を求めるクライアントはPADIとPADRにタグを付け、対応できるサーバーはPADOとPADSで返す。

サーバー側にも上限がある。RFC 4638は、サーバーが自分の設定とクライアントの申告値に基づいて大きなMRUを交渉できるとする。選べる値は、タグの値とサーバーのインターフェースMTUから8を引いた値の小さい方までだ。タグが交渉を始めても、物理インターフェースの限界や途中の区間の設定は変えられない。

数字ひとつが、経路に沿った複数の判断になった。クライアントは要求できる。コンセントレーターは自分が対応する範囲で返答する。ローカルのインターフェースにはカプセル化の余白がいる。経路上の各Ethernet区間が、結果のパケットを運ばなければならない。加入者側の画面に1,500バイトと表示されても、家庭からコンセントレーターまでのすべてのスイッチがそれを認めたことにはならない。

経路にも拒否する機会がある

RFC 4638はセッション開始後の試験も記述している。送信側はMRUサイズのEcho-Requestを受信端と中間のEthernet機器に通す。大きなプローブにはEcho-Replyがなく、1,492バイトのプローブには返答がある場合、送信側はそのセッションでより大きなパケットを送ってはならない。

このフォールバックが大切だ。タグが交換されない場合や、どちらかの端に大きな設定がなければ、RFC 2516の1,492バイト上限が残る。大きなパケットの試験に経路が通らなくても、接続は低い上限に戻れる。古い合意を動作する下限として残し、対応する経路だけが上を交渉できる。

RFCに書かれてもEthernet標準が拡張されたわけではない

RFC 4638はInformational RFCだ。付記されたIESGノートは、文書公開時点で1,500バイトを超えるMTUのジャンボフレームを支える現行IEEE標準はなく、標準外の拡張では相互運用性と信頼性を保証できないと警告した。PPPoEの相手同士が大きな値を提案しても、各Ethernetポートが実際に受け入れなければならない。

だからこれは「1,492が自動的に1,500になった」という年表ではない。RFC 4638は経路が必要とする旧上限を残し、能力のやり取りを定義し、大きなサイズを試す方法を実装者に示した。プロトコルは提案を書ける。提案が成立するかは、参加機器と経路が決める。

2つのRFCが記録するのは設計と分割削減の目標であり、どのアクセスネットワークがタグを導入したかではない。特定ネットワークでの導入を確認するには、日付入りのコンセントレーター設定、または実際の発見メッセージの記録が必要だ。

出典