要約

  • MPPCではPPPの両端が同じ8192バイトのスライディング履歴を保つ必要があり、各パケットの12ビット整合カウントが欠落や順序のずれを露出させた。
  • 値が合わなければ受信側はパケットを捨ててReset-Requestを送る。送信側は履歴を消去し、次のパケットにFLUSHEDを立てる。そのパケットが受信側の履歴と基準値を更新するため、Reset-Ackは要らない。
  • そこで確認できるのは新しい圧縮履歴の境界だけである。失われたデータ、信頼できる配送、内容の完全性、相手の身元、権限、アプリケーション完了は証明しない。

制御応答を待たず、次のデータが答えになった

RFC 1962の一般的なCCP手順では、復号側はReset-Requestを送り、識別子の合うReset-Ackを受け取るまで後続の圧縮パケットを捨てる。初期状態への復帰は、その応答と結び付いている。

RFC 2118のMPPCは別の証拠を採った。期待した整合カウントと異なる値が来ると、受信側はそのパケットを破棄してReset-Requestを送信する。圧縮側は要求を受けて履歴を消去し、次のMPPCパケットにFLUSHEDを付ける。復号側はそのパケットで自分の履歴を消去し、パケット内のカウントを新しい基準にする。Reset-Ackなしで同期が戻る。

次のパケットは古い履歴に依存せず復号できるため、新しいepochの実動証拠になる。ただし過去は直さない。落ちたパケットは戻らず、Reset-Requestの配送事実や上位層への到達も確定しない。

オプション18が許したのは一つの変換だけ

MPPCはPPPに自動的に付随するものではない。CCPのType 18、Length 6のオプションで交渉し、Supported Bitsの最下位ビットだけがMPPC利用希望を示した。最終的に合意できなければ圧縮は行わない。現在のIANA PPPレジストリもCCPオプション18をMicrosoft PPCとして記録している。

PPPがNetwork-Layer Protocol段階に入り、CCPがOpenedになって初めてMPPCデータグラムを送れる。圧縮データのPPP Protocolは0x00FDで、CCP自体の0x80FDとは異なる。0x00FDは圧縮データ経路を示すが、アルゴリズム名は先行する交渉が与える。

対象は0x0021から0x00FAまでのPPP Protocolで、その他は元の番号のままMPPCを通らない。オプション受諾は能力の合意であり、すべてのパケットが圧縮されたという事実ではない。

8192バイトの記憶が効率と依存を同時に生んだ

LZ方式の履歴は連続していた。圧縮データを8192バイト送った後は、flushされない限り8192バイト分を参照できる。後のパケットが前のパケットから学んだ内容を使えるので帯域を節約できる反面、両端の記憶が一歩でも違えば同じ符号を同じように解釈できない。

Aビット、すなわちFLUSHEDは、送信側がパケット生成前に履歴を初期化したことを示す。Bビットは履歴ポインタをバッファ先頭へ戻し、圧縮データ8192バイトごとに少なくとも一度必要だった。Cビットは当該データが圧縮されているかを示す。いずれも圧縮状態の情報であって、アプリケーション配送の情報ではない。

圧縮でデータが大きくなる場合、元データを非圧縮MPPCパケットとして送った。その後再び圧縮する前に履歴を消去し、次の送信パケットへFLUSHEDを付ける。現在の膨張を避ける判断が、将来使えたはずの文脈を失わせる。

12ビットが示すのは切れ目であって内容ではない

整合カウントはゼロから始まり、MPPCパケットごとに一つ進み、4095の次でゼロへ戻る。期待値との差は欠落または順序異常を示す。この仕組みによりMPPCは信頼性のあるリンクを必須としなかった。RFC 1663には信頼性付きPPPモードがあるが、RFC 2118は通常その追加負荷を不要とした。

同時にRFC 2118は、履歴再同期には順序どおりの配送が必要だと述べる。「信頼性リンク不要」は、自由な並べ替えを許すという意味ではない。カウント一致も内容検証ではない。Security Considerationsは安全性を論じていないと明記するだけで、機密性、暗号学的完全性、身元、認可、リプレイ防止を与えない。

Informational文書と当時のライセンス面

RFC 2118は1997年3月にInformationalとして公開され、Internet Standardではない。ライセンス節はMPPCの利用をMPPC/PPPとの相互運用を目的とするPPP製品に限定し、Stac Electronicsのライセンス窓口を示した。これは当時の運用条件を示す史料であり、現在のライセンス、特許、配備を証明するものではない。

解釈の規律にはHeng LuのRunning-Code PrimacyとMinimum Initial Specificationを用いる。各信号を、実装が検証できる最小の主張にとどめる。オプションは能力、カウントは順序差、Reset-Requestは修復要求、FLUSHEDは新履歴を示す。別の層の成果を宣言する権限はない。

出典と証拠の限界

一次記録はRFC EditorのRFC 2118 HTML、テキスト版、情報ページ、正誤情報入口、そしてRFC 1962、RFC 1661、RFC 1663、IANAレジストリである。Heng Luの論考は解釈の枠であり、プロトコル史料の代わりではない。これらは仕様と文書上の地位を示すが、現在の実装、性能、安全性、個別パケットのアプリケーション結果は示さない。