要約

  • Discoveryで双方が拡張への対応を示さなければ、PPPoEの上限は1492バイトのままである。未知のタグを無視した機器を、大きなサイズに同意した相手として扱ってはいけない。
  • PPPの終端が家庭用ゲートウェイへ移ると、LAN側の1500バイトと接続側の1492バイトの差を、そのゲートウェイが受け持つことになった。
  • 能力を示すタグ、LCPによる実際のMRU交渉、サイズ別の試験は別々の確認である。端点の合意だけでは、その間にあるEthernetの容量まで保証できない。

読み飛ばされた項目が残す境界

新しい機能を伝えるタグを送ったところ、相手から通常の応答が来た。これだけで拡張に成功したと判断すると、古い実装と共存するための仕組みが逆に危険になる。

PPPoEのDiscoveryでは、特に定めがない未知のタグを受信側が無視できる。知らない情報が一つあるだけで、従来の接続まで成立しなくなることを避けられる。しかし、無視された情報について相手が何かを約束したことにはならない。

2006年9月の RFC 4638 は、この違いをサイズ拡張の条件にした。Discoveryの段階で双方が対応を示さなければ、1492バイトという従来の制限を保つ。接続が進んだという事実から、より大きなパケットの許可を推測してはいけない。

互換性とは、全員が新機能を使うことではない。新機能を知らない相手とも、どこまでなら安全に共通動作を続けられるかを定めることである。PPPoEでは、その境界が具体的なバイト数になっていた。

最初から引かれていた八バイト

1999年2月の RFC 2516 は、Ethernet上でPPPを運ぶ方式を記述した。Discoveryで相手のEthernetアドレスとセッション識別子を確定し、その後にPPPのセッションへ進む。

クライアントはPADIをブロードキャストし、PADOで提示を受ける。選んだ相手へPADRを送り、PADSで確認される。ただし、ここまでで認証やネットワーク層の準備を含むすべてのPPP処理が終わるわけではない。まして、後から流れる最大サイズの通信を試したことにもならない。

元の計算では、Ethernetの最大ペイロード1500バイトからPPPoEヘッダーの6バイトとPPP Protocol-IDの2バイトを差し引く。残りは1492バイト。この8バイトは、接続の途中で不意に現れる余裕分ではなく、カプセル化に必要な領域だった。

ここでいう1500はEthernetのペイロードであり、ヘッダーやFCS、プリアンブルなどを含む伝送路上のフレーム全体ではない。同じ「サイズ」という表示でも、何を数えるかが違えば比較できない。

拡張後も8バイトは必要である。PPPのペイロードを1500バイトにしたければ、この6足す2の数え方では、下のEthernetペイロードに1508バイトを入れられなければならない。タグの追加でヘッダーが消えるわけではなく、容器側を広げるのである。

パソコンから見えなくなった制約

RFC 4638が示した動機は、サイズを大きくすること自体ではなかった。PPPの終端がどこに置かれるかが変化していた。

パソコン自身がPPPoEを開始する構成では、そのパソコンが1492バイトの制約を受け入れればよく、文書はこれを通常は問題のない条件として説明している。ところが家庭用ゲートウェイがLAN側のIP over Ethernetを受け、アクセス側でPPPoEを始める構成では事情が違う。

LANからは1500バイトのIPパケットが届き得る。一方、ゲートウェイが作るPPPの区間には1492という境界がある。送信元のパソコンは、その区間のLCP交渉に直接参加していない。使い勝手を簡単にするために、サイズの調整責任がゲートウェイへ移ったのである。

同じ文書はPPPoAからPPPoEへ移す場面も扱い、当時導入されていたPPPoAの顧客側機器の一部では1492への対応ができないと説明した。これは2006年の背景資料として読むべきで、現在の機器全体の性質や普及率を示すものではない。

ATMなら制限がない、という対比も正しくない。1998年7月の RFC 2364 は、PPP over AAL5のMRUを、その方向の仮想接続のトラフィック契約で許される最大CPCS-SDU以下にする。下位の方式が変われば、成立していた容量の前提も確認し直す必要があった。

受け取れる量と、使う量

MRUはMaximum-Receive-Unit、最大受信単位を表す。1994年7月の RFC 1661 では、InformationとPaddingの部分が対象であり、Protocolフィールドや外側のフレーム処理は含まない。

通常のPPPには1500という既定値がある。しかし、その一般則でPPPoE固有の1492制限を消すことはできない。また、大きいMRUを示すことは、相手に毎回そこまで詰めたパケットを送れと命令することでもない。受信能力の上限と、実際に流れたサイズは異なる。

PPP-Max-Payloadタグは、LCPより前のDiscoveryに能力の確認を加える。1492を超えて使いたいクライアントはPADIとPADRの両方にタグを含めなければならない。対応するサーバーは受け取ったタグをPADOとPADSに入れて返す。

タグの種類は0x0120、十進数では288である。値は2バイトの二進数で、クライアントが送受信の両方向で対応できる最大PPPペイロードを表す。288はサイズではなく項目の識別番号であり、値の2バイトはセッションの全パケットに追加される経常的な負担でもない。

返された数字は最終決定ではない

サーバーがDiscoveryで返すのは、クライアントのタグである。そこに自分の最終的な上限を毎回書き直す仕組みではない。その後のPPP交渉で、ローカルな条件を反映させる。

RFC 4638の処理は、まず1492を最大値とする。タグが存在し、その値が1492より大きければ、タグの値とインターフェースMTUから8を引いた値のうち、小さい方を交渉可能な上限にする。そこから通常のMRU交渉で実際の値を決める。

したがって、タグの回送と実際のMRUが違っていても、直ちに矛盾とはいえない。前者は拡張を理解していること、後者はその場で許される条件を示す。

タグが1500を超える場合も、その値だけで実際のMRUが自動的に増えるわけではない。拡張を使う条件が満たされていても、より大きなMRUが交渉されなければ、普通のPPPの既定値1500が残る。この話を、拡張に合意していない1492のセッションへ持ち込んではいけない。

端点同士では確認できないもの

端点は相手のタグを読み、LCPで合意できる。途中のEthernetブリッジはその合意の当事者ではない。小さいDiscoveryや制御メッセージが通ったからといって、大きいフレームまで通せると宣言したわけではない。

そこでRFC 4638は、セッションが開き、1492より大きいMRUを交渉した後に、MRUサイズのLCP Echo-Requestを一つ以上送れる選択肢を用意するよう求めた。応答がなければ1492バイトで繰り返してもよい。その小さい要求に応答があった場合、このセッションでは1492を超えて送信してはならない。

試験機能は既定で有効にすることが望ましいが、設定可能であり、ネットワークをあらかじめ把握している場合は無効にもできる。すべての接続が同じ回数、同じ待ち時間で試験するという規定ではない。

大きい要求が失敗して小さい要求が成功する比較は、運用上の制限を導く。しかし、故障した装置を一台に特定するものではない。両方とも応答がなければ、小さいサイズが使えるとさえ結論できない。

RFC 1661でEcho交換が許されるのはLCP Openedの状態であり、応答のIdentifierは要求に対応する。ただし、応答が必ず要求と同じ長さになるとはいえない。一度の往復で、両方向の最大容量が将来にわたり保証されたと説明するのは過大である。

接続の外側には別の経路がある

この試験は、Internet全体のPath MTU Discoveryを代行しない。1990年11月の RFC 1191 では、IPv4の送信元が断片化を禁止するDFを用い、断片化せずには転送できないルーターからのICMPを受けて経路MTUの推定を下げる。

その条件では、過大なパケットは単に途中で分割されるのではなく、破棄されて通知の対象になる。PPPoEのサイズ境界を説明するときも、すべての大きいIPv4パケットが必ず断片化されるとは書けない。

アクセス側のセッションで確認できたことと、さらに先の宛先まで確認できたことを分ける。小さな試験の価値は、その範囲を正確に保ってこそ残る。

登録は共通語を作る

RFC 4638はInformational文書であり、Internet Standardではない。冒頭のIESGの注意は、2006年当時の1500を超えるEthernetサイズに関する標準化状況を踏まえたものだ。それを2026年の標準の説明として引用してはいけない。

2007年6月の RFC 4937 はPPPoEの16ビットのタグ種類をIANAで登録する手続きを整え、PPP-Max-Payloadを288として記録した。今回確認した IANAのPPPoEパラメーター登録簿 にも対応関係が残る。

番号の登録は、同じ項目を同じ意味で読むための調整である。中間機器が大きいフレームを運べるようになった日時を示すものではない。1999年のカプセル化、2006年の拡張、2007年の登録手続きを一つの普及イベントにまとめることはできない。

この拡張の成果は、無言の相手に新しい能力を推定せず、明示的な合意の後にも現実の制約を残した点にある。接続できたこと、サイズを合意したこと、そのサイズで通ったことは、最後まで別の事実だった。