要約

  • IPX-WAN を備えた実装は、必要な値が未確定でも IPXCP を Opened にしてよかった。IPX-WAN 自体が、その状態にならなければ交渉パケットを送れなかったためである。IPX-WAN がなければ、同じ未確定値は開通を止めるべきだった。
  • IPX-Configuration-Complete は双方向の助言的な合図であり、必須の合格証ではない。既定値や手動設定だけで要件が満たされる場合もあった。
  • RFC 1552 は 1993 年 12 月の Standards Track 文書で、現在は Historic とされる。どちらも文書上の事実であり、実装、通信、経路、利用結果の証明ではない。

「完了」の前に開けなければならない扉

ある PPP 回線で、物理的なキャリアが立ち、LCP がリンクを確立し、必要なら認証も終わった。IPXCP の状態表示は Opened に変わる。ここまでなら、IPX の設定も終わったと読みたくなる。

しかし、ネットワーク番号がまだ決まっていないかもしれない。その値を IPX-WAN が決める設計なら、IPXCP は先に開かなければならない。PPP から見て IPX-WAN の Timer Request は普通の IPX データグラムであり、IPXCP が開く前には通せないからだ。

先に開くことが、後で完了するための条件だった。

この順序を明文化したのが RFC 1552 である。1993 年 12 月に Standards Track として公開され、IETF の記録に文書の来歴が残る。RFC Editor の情報ページは現在 Historic とし、errata 検索は文献確認の窓口を提供する。

これらは製品の採用状況を証明しない。証明するのは、状態の意味が次に利用できる能力によって分岐するよう、仕様が書かれていたということだ。

PPP には複数の境界があった

当時の RFC 1548 は PPP を、データグラムのカプセル化、データリンクを確立・試験する LCP、ネットワーク層プロトコルごとの NCP に分けた。文書情報はその歴史的位置を示す。

物理リンク、LCP、任意の認証、Network-Layer Protocol フェーズ、IPXCP の交渉、IPX データグラムの搬送は、別々の証拠だった。RFC 1552 は正しいフェーズより前に届いた IPXCP パケットを黙って破棄し、IPXCP が Opened になるまでは IPX データグラムを運ばないよう定めた。

後年の RFC 1661 とその情報ページにも LCP/NCP の大枠は残る。ただし、それは後続仕様であり、RFC 1552 の普及を遡って証明するものではない。

「PPP up」という一行は、この階段を一つの段に潰してしまう。そして RFC 1552 では、IPXCP の段そのものにも条件付きの意味があった。

必要かどうかは各実装が決めた

RFC 1552 の Desired Parameter は、ある実装が正常動作に必要と考える値だった。全実装に共通の必須一覧ではない。一方に不可欠な値を、他方は必要としないことがある。

この定義は差異を隠さず、交渉によって「この二つは収束しない」という組み合わせを発見できるようにした。

IPX-WAN を利用できる実装では、Desired Parameter が不明で IPXCP オプションも成功していなくても、Opened に到達することが勧められた。その先で IPX-WAN が不足を埋められる。一方、IPX-WAN を持たない実装は、同じ条件で開いてはいけない。欠けた値を決める次の手段がないからだ。

RFC 1551 とその記録は IPX-WAN の仕組みを示す。文書が存在することと、特定の相手がその能力を持つことは別である。だからこそ能力確認が状態解釈の一部になる。

仕様が記録した相互接続の亀裂

RFC 1552 は、IPXCP オプションを使わずに IPXCP を動かしながら、設定完了には IPX-WAN を必須とする Novell の実装を記載した。その実装は IPX-WAN を持たない IPXCP 相手と相互接続できなかった。

ここから言えるのはその範囲までだ。製品版、導入数、障害規模、その後の挙動は資料にない。

ただし、互換性表の弱点は明確である。両者が IPXCP に対応していても、一方は IPXCP の外側に「設定の終点」を置いていた。共通のプロトコル名は、共通の完了経路を保証しなかった。

オプション機能が長く残ると、実際の依存関係は見えにくくなる。後でその機能を外したとき、基本プロトコルの退行に見えても、本当に失われたのは記録されなかった第二の完了経路かもしれない。

Configuration-Complete は判子ではなかった

IPX-Configuration-Complete は、静的設定と提示中の IPXCP オプションによって、自分側の Desired Parameters がすべて満たされると示すためのオプションだった。助言的で、Configure-Nak に入れるものではなかった。

IPX-WAN がなく、必要値が不明な実装は、この合図がない、または拒否されたことを早期の失敗判断に使えた。IPX-WAN を持つ双方が両方向で合図を確認すれば、各自の要件が満たされたとして IPX-WAN を省略できた。

片方向だけでは、相手側の要件まで証明しない。

さらに、合図がなくても設定は成功し得た。既定値や手動設定で Desired Parameters がそろっている場合である。したがって不在は万能な失敗証跡ではなく、存在もあらゆる層の成功を保証しない。

「Complete」という語の効力は、誰が、どちら向きに、どの入力について述べたかという範囲の中にだけあった。

開いた後の失敗には運用判断が残った

IPX-WAN を試しても Desired Parameter が不明のままなら、既定の勧告は接続終了だった。ただし、その値なしでも動ける実装には、設定可能な例外を認めた。

共有プロトコルは未解決状態を見せ、第二の交渉を可能にする。実装は値の必要性を決め、運用者は縮退を許すか決める。Opened だけを保存すれば後二者が消え、IPX-WAN の失敗だけを保存すれば、それが致命的だったか分からない。

優先順位は値ごとに違った

ネットワーク番号とノード番号では、IPX-WAN の情報が対応する IPXCP オプションに優先した。圧縮では逆に IPXCP の交渉結果が優先した。圧縮が IPX-WAN の観測するパケットを変え得るためだ。ルーティングプロトコル情報は置換ではなく追加になる場合があった。

「後の交渉が勝つ」という一律規則は成り立たない。最終値には、その出所と選択規則が必要だった。

RFC 1553 と情報ページは CIPX 圧縮を独立の機構として区切る。圧縮の成立は番号、経路、アプリケーションの成立ではない。IANA PPP Numbers も識別子の割当を示すだけで、実際の交渉を示さない。

初期値と運用中の観測

RFC 1552 は、IPX-WAN 初期化時の遅延測定が実負荷を反映せず、測定値を六倍して扱うと注意した。タイムスタンプ付き LCP Echo なら、リンクや機器負荷の変化に合わせて往復時間を継続的に再評価できる。

初期推定、後の測定、データグラム搬送、経路収束、アプリケーション応答、利用者の結果はそれぞれ別だ。IPX パケットを一つ見ても、それが IPX-WAN 設定、ルーティング、利用データのどれかを分類しなければならない。

文書の地位は稼働実績ではない

1993 年の Standards Track と現在の Historic は、別時点の文書分類である。Security Considerations は安全上の問題を論じないと記す。これは安全の保証でも、未確認の脆弱性を語る根拠でもない。

Heng Lu の Running-Code Primacy は、文書による調整と実装・運用の証拠を分ける。Minimum Initial Specification, Localized Future Decision and Voluntary Adoption は、共通の最低条件と実装固有の判断を分離する視点を与える。reality layers は文書、設定、観測、結果の相互代用を防ぐ。これらは現代の分析枠であり、当時の著者の内心を示す史料ではない。

状態には残りの担当者を添える

RFC 1552 の Opened は曖昧なのではない。遷移を許す能力分岐を伴って、初めて正確だった。IPX-WAN があれば、先に開くことが完了への道になる。なければ、必要値が不明なまま開くことは終端的な不一致を隠す。

運用記録には、物理状態、LCP、認証、PPP フェーズ、IPXCP オプション、Desired Parameter と出所、両方向の Configuration-Complete、IPX-WAN の交換と結果、終了・例外方針、後続測定、実データグラム、経路、アプリケーション結果を別々に残すべきだ。

そうして初めて Opened は有用な短縮語になる。何に対して開いたのか、残りを誰が所有するのか、その完了をどの証拠が示すのかまで、後から展開できるからである。

出典