要約

  • RFC 2509から引き継いだTCP_SPACEとNON_TCP_SPACEはコンテキストIDの最大値を表すため、ゼロでもCID 0の一つが残る。
  • RFC 3544の3オクテットのサブオプション3はTCPまたは非TCPのコンテキスト数を明示的にゼロにし、その種類の圧縮を無効化できる。

紛らわしいのはフィールド名だ。TCP_SPACEとNON_TCP_SPACEはコンテキストの個数ではなく、番号の上限を示す。上限がゼロなら、ID空間にはCID 0が含まれる。最小構成には使えても、この二つのフィールドだけでは「この種類のパケットは圧縮しない」と表せなかった。

2003年7月にProposed Standardとして発行されたRFC 3544は、RFC 2509のPPPネゴシエーション用オプションを改訂しながら、ゼロの既存の意味は変えなかった。足りない区別を補うのがサブオプション3である。Typeは3、Lengthは3オクテット、残る1オクテットがパラメーターだ。値1はTCPコンテキスト数をゼロにし、値2は非TCPの数をゼロにする。これはIP Header Compressionオプション内のTCP_SPACEまたはNON_TCP_SPACEを上書きする。両方の値を含めれば、すべてのパケットで圧縮が無効になる。

ゼロを再定義するのではなく、明示的な上書きで互換性を保つ修正だ。旧フィールドは従来の意味を維持し、追加の信号がそれでは運べない意図を伝える。同じビット列を新旧の相手が違う意味に解釈する事態を避けられる。

二つのNCPで別々に交渉する

PPPはNetwork Control Protocolでリンクのパラメーターを交渉する。RFC 3544はIPv4用IPCPとIPv6用IPV6CPに同じ圧縮オプション形式を定義する。それぞれのNCPは、外側のネットワークヘッダーがそのバージョンであるパケットの圧縮を設定する。IPv4の圧縮交渉とIPv6の圧縮交渉は、単一のスイッチではなく別個の制御面上の結果だ。

さらに、IPv4とIPv6は交渉自体は独立していてもコンテキストID空間を共有する。パラメーター値が異なるとき、圧縮器は共通プールからIDを割り当て、展開器はコンテキスト状態を見て適用するパラメーターを判定する。TCPと非TCP/UDP/RTPはコンテキスト空間を共有しない。これらは仕様上の実行制約であり、特定の相手が構成や実トラフィックで利用した証明ではない。

RFC 3544はEnhanced RTP用Type 2サブオプションも追加した。旧RTPサブオプション1と併用するのではなく、置き換えて交渉する。九つのPPP Protocol Field値と合わせ、フレームの種類と許可された形式を受信側が識別できる。Protocol Fieldは多重分離の境界、サブオプションは設定意図を示す境界だ。

交渉はデータパスの証拠ではない

交渉に成功すれば、名前の付いたプロトコル識別子を使えるようになる。それだけでは、実装が圧縮フレームを送ったか、対向側が復号したか、データグラムが届けられたか、サイズが小さくなったかは分からない。いずれも経路上の異なる地点で確かめる別の事実だ。設定交換が示すのは合意したパラメーターであり、トラフィックの配送ではない。

仕様は隣接する曖昧さも明記する。RFC 1332は、このオプションが送信側と受信側のどちらの能力を表すか明確にしていない。RFC 3544は慣行に従い、Config-Reqを送る相手の展開器能力を表すものと仮定すると述べる。これは明示された仮定であって、RFC 1332への規範的な明確化ではない。これ以上に強く断定すれば、文書自身の留保を消してしまう。

データパスには別の条件がある。IPHCはTCPとRTPで差分符号化を使い、圧縮パケットは送受信双方のコンテキストに依存する。PPP自体はパケットを並べ替えないため、並べ替えへの保護は既定で無効だ。Multi-Class Multi-Link PPPなど並べ替えが起き得る仕組みを使うなら、同じ圧縮コンテキストを共有するパケットの順序を保つ必要がある。形式をネゴシエートしても、この伝送上の制約はなくならない。

歴史的な教訓は限定的だ。直感的な値にすでに有効な意味があるなら、プロトコルの進化には第二の信号が必要になることがある。RFC 3544は既存フィールドを保ち、明示的な上書きを加えた。能力、実際の送信、復号、配送、性能向上は、それぞれ個別に確認すべき事実として残る。

参照資料