要約

  • PPPMuxCPでは、受信側が方向ごとに多重化フレームの受信能力を申し出る。交渉成功は送信を許可するが、送信側に多重化フレームを出す義務を課さない。
  • 既定PIDは、省略されたプロトコル識別子をどう復元するかという約束にすぎない。PFFが実際にゼロで、フィールドが線上から消えたときだけ節約を確認できる。
  • 外側ヘッダーの共有は待ち時間や一括損失の範囲も変える。能力、実行、復元、リンク測定、アプリケーション結果は別々の証拠である。

小さなパケットほど外側の繰り返しが目立った

PPPの各フレームには、境界、プロトコル識別、検査のための情報が付く。アドレス／制御フィールドやプロトコルフィールドを圧縮しても、短いペイロードに対する固定費は残る。L2TPのようなトンネルに入れば、個別フレームごとの包みはさらに重なる。

RFC 3153は、複数のPPPパケットを一つの外側PPPフレームに収める方式を定めた。内側の各パケットはサブフレームとなり、その直前の短い区切りがプロトコルフィールドの有無と長さを示す。共有されるのは外側の包みであり、アプリケーションの内容そのものではない。

ただし、まだ到着していない二つ目のパケットは束ねられない。効率を上げるために待てば、先に来たパケットの遅延が増える。RFCは、集合を大きくするほど一パケット当たりのオーバーヘッドを減らせる一方、多重化と分離の遅延が増えるという交換条件を明記した。

したがって、機能の存在から速度向上を導くことはできない。実際の外側フレーム、サブフレーム数、区切り、欠落したフィールド、キュー待ち、送信時間、外側損失を同じ観測に置いて初めて、利益を語れる。

「読める」という申し出は一方向ずつ成立した

PPPMuxCPはNCP段階で使われる。多重化を送りたい側が一方的に有効化するのではない。受信側が、その方向の多重化フレームを受け取れると先に申し出る。申し出がなければ、相手はその形式を送ってはならない。

受信能力は方向別に交渉される。AがBから受け取れることは、BもAから受け取れることを意味しない。管理画面が一つの「enabled」に縮めれば、片方向の互換性を双方向の事実にしてしまう。

交渉が成功しても、送信側の判断は残る。RFC 3153は、PPPMuxCPの成功が多重化フレームの送信を義務づけないと明記する。送信側は対象を選び、適格なパケットを単独で送ることもできる。

制御の証拠は、許可された文法を示す。データの証拠は、0x0059の外側フレームがその方向に実在したことを示す。両方の時計を結ばなければ、「交渉済み」は実行履歴にならない。

既定PIDは省略を可能にしたが、省略を発生させなかった

PPPMuxCPは必ず既定PIDを交渉する。値を出すのは受信側で、最初のサブフレームにプロトコルフィールドがなければ、この値として解釈する。最初のパケットの種類が一致する場合、送信側はPFFをゼロにし、一または二バイトを省ける。

省かなくてもよい。最適化できる場面でも、送信側は明示フィールドを残せる。合意されたPIDは条件付きの解釈規則であって、節約済みバイト数ではない。

後続サブフレームでは、PFFが一なら新しいPIDが現れ、送信側のLast_PIDと受信側のLast_rcvd_PIDが更新される。PFFがゼロなら直前の明示値を引き継ぐ。最初の明示値より前は、交渉された既定値が状態の起点になる。

このため、節約を数えるには順番どおりに区切りを解析しなければならない。外側フレームの本数だけでは、どのPIDが省かれ、途中で何回切り替わったか分からない。同じ多重化率でも、プロトコル構成によって結果は変わる。

MRUは天井であって、満杯にする目標ではなかった

区切りにはPFFのほかLXTとLENがある。LXTは長さ欄が短形式か拡張形式かを決め、LENがサブフレーム境界を示す。例示された送信処理はローカルなMAX_SF_LENを使い、それを超える候補を入れない。集合全体もLCPで決まったMRUを越えられない。

次の候補が大きすぎる、追加するとMRUを越える、またはキューが空になると構築は止まる。実装はタイマーも加えられる。さらにRFCは、遅延やパケットエラーを考え、最大多重化サイズをMRUよりかなり小さくする選択にも触れている。

MRUは受信可能性の上限で、効率の推奨値ではない。MAX_SF_LENは候補の入口で、最適値の測定ではない。タイマーは送信側の待ち方で、受信側から与えられた能力ではない。

大きく束ねるほど外側の繰り返しは薄まるが、早いパケットは長く待つ。一つの外側フレームが壊れたり失われたりすれば、同居する内側パケットも同じ事故範囲に入る。リンク速度、誤り率、バースト、パケット分布、アプリケーションの遅延許容が判断を変える。

分離できても、順序を変えてよいわけではない

受信側は0x0059を見つけると、サブフレームを先頭から読む。長さを取り、PIDを明示値または状態から復元し、通常のPPP処理へ渡す。宣言された長さが残りのデータを超えれば最後のサブフレームを捨てる。ただし不正な長さは最後ではなく、それ以前にあって解析位置をずらした可能性もある。

多重化フレームを別の多重化フレームに入れることはできず、LCPフレームも内側に入れてはならない。単独フレームと多重化フレームが混在しても、送受信側はパケット順を変えるべきではない。

だから「三つ復元した」という集計だけでは不十分だ。外側の到着順、単独フレームの位置、内側境界、復元後の引き渡し順を保存しなければ、隣接パケットとの逆転を見落とす。

また、PPP処理への引き渡しはアプリケーション到達ではない。後段で破棄、遅延、変換されることがある。復元は一つの層の結果にとどまる。

MP、圧縮、暗号化との位置は互換性の一部だった

Multilink PPPでは、PPPMuxは個々のメンバーリンクではなくbundleに対して交渉される。送信時はPPP多重化を先に行い、その外側にMPを適用する。したがってMPヘッダーはPPPMuxヘッダーの外にあり、Multilinkフレーム自体をサブフレームにしてはならない。

CCPとECPにも順序がある。PPPMuxはbundleレベルのCCP/ECPより後、MPおよびリンク別CCP/ECPより前に実行される。リンク別形式の上にPPPMuxを置けない実装は、PPPMux交渉時にそのリンク別プロトコルをProtocol-Rejectしなければならない。

機能一覧に「多重化、Multilink、圧縮、暗号化」が並んでも、この順序は証明されない。順序によって各処理が見るバイト列が変わる。MPの前で採ったbundleのキャプチャと、メンバーリンク上のキャプチャも同じものではない。

ECPの制御応答が成功しても、特定の多重化フレームが実際に暗号化された証明にはならない。ここでも能力と実行を結ぶ必要がある。

「追加の安全性考慮なし」は安全機能の追加ではない

RFC 3153は、PPPとPPP上のヘッダー圧縮方式を超える安全性考慮を追加しないと述べる。これは文書が新しい脅威分類を主張しないという範囲であり、PPPMuxに認証、完全性、機密性、リプレイ防御を与える文ではない。

不正な長さ、解析器の差、PID状態のずれは運用障害になり得る。形式どおり復元できたパケットでも、相手の認証や後段の認可まで保証しない。

安全性はPPP認証、実際のECP状態、フレーム完全性、異常入力の拒否、後段の作用を別途確認する必要がある。文法の理解は相互運用性であり、信頼ではない。

共通仕様は許可の境界までを厳密にした

RFC 3153が共通化したのは、受信側の事前申し出、プロトコル値、フラグと長さ、PID復元、順序、他のPPP処理との位置だった。その内側で、現在のキューを束ねるかどうかは送信側に残した。

交渉後に使わないことは無効ではない。申し出のない相手に送ることは互換性境界を越える。共通層は決定論的で、採用はローカルかつ任意だった。

証拠も同じ境界に従う。Configure-Ackは許可、0x0059は使用、PFF/LXT/LENは符号化、受信トレースは復元、比較測定はバイトと時間、アプリケーション観測は最終作用を示す。

RFC 3153の教訓は「まとめれば得」という標語ではない。受信側が「読める」と言ったあとにも、送信側は「今使うか」を判断し、ネットワークは「本当に得だったか」を証明しなければならなかった。

出典