要約

  • RFC 1473 は、PPP 上の IP を管理する設定表と運用表を分けた。管理者の open は IPCP 状態機へ入るイベントであり、Opened 到達の保証ではない。
  • 圧縮設定の変更は次回のリンク再起動で効く。交渉完了前の方式とスロット値は未定義で、Opened 後の値もパケット到着やアプリケーション成功を証明しない。

RFC 1473 が 1993 年 6 月に定義した PPP IP Group は、驚くほど小さい。障害または設定管理に不可欠で、利用実績や有用性があり、他から単純に導けない対象だけを残す方針だった。

この少なさが、管理画面では見落とされやすい境界をはっきりさせた。希望する設定、状態機械が到達した場所、回線を通ったデータは、同じ時刻に成立するとは限らない。

管理者が投入したのは Open イベント

pppIpConfigAdminStatus は IP ネットワークプロトコルの「直ちに望む状態」を表した。open を書けば IPCP の有限状態機械に管理 Open イベントが入り、close なら Close が入る。

イベントは結果ではない。書き込み成功は、エージェントが要求を受理したことを示す。下位層が使えるか、相手が答えるか、双方が選択肢を受け入れるかは、その後の出来事である。

後の RFC 1661 でも、ネットワーク層プロトコルごとに NCP を個別設定し、各 NCP は独立に Opened と Closed を行き来できる。LCP が開いていることも、別の NCP が開いていることも、IPCP の結果を代行しない。

設定値は次の再起動を予約した

pppIpConfigCompression は、本端が交渉を試みる方式を none または Van Jacobson TCP/IP ヘッダー圧縮から選ぶ。RFC 1473 は、この値を変えた効果がリンクの次回再起動時に現れると明記した。

したがって、保存済みの新値は現行セッションの事実ではない。どの設定世代が、どの再起動に渡され、どの IPCP 要求となり、相手が何を返したかを結び付けて初めて「効いた」と言える。

RFC 1332 の IP-Compression-Protocol は、既定では圧縮なしだった。双方向に使うには、両端がそれぞれ受信能力を要求しなければならない。一方向の合意を、リンク全体の単一状態に丸めることはできない。

Opened より前は値そのものが未定義

読み取り専用表には pppIpOperStatus と、両方向の圧縮方式、Remote/Local Max-Slot-Id が並ぶ。ただし RFC 1473 は、これらの交渉済みパラメーターが利用可能になるのは IPCP が Opened に達した後だけだとした。

それ以前の内容は未定義で、アクセス時に何を返すかは実装依存である。

未定義は「少し古い」と同じではない。古い値なら、過去のある交渉には属していたかもしれない。未定義の値は、ゼロ、初期値、残骸のいずれでもよく、今回の相手との合意を語らない。型が正しい整数でも、証拠の資格はない。

Opened 後にも方向条件が残る。local-to-remote は本端が送る側、remote-to-local は受ける側の方式である。VJ 圧縮を使わない場合 Max-Slot-Id はゼロになるが、Opened 前のゼロから「圧縮なしで合意した」と推論してはならない。

Opened は通行条件であって配達票ではない

RFC 1332 は、PPP が Network-Layer Protocol phase に入り、IPCP が Opened になるまで IP パケットを通信できないとした。RFC 1661 も、対応 NCP が開いていない時に受けたネットワーク層パケットは破棄すると定めた。

Opened は確かに通行条件を変える。しかし記録しているのは状態遷移である。特定パケットの送信、カウンター増加、圧縮ヘッダーの復元、経路の存在、相手アプリケーションの応答までは記録しない。

RFC 1144 の圧縮は、低速回線で反復する TCP/IP ヘッダーを小さくするためのものだった。方式を交渉できたこと、パケットが実際に圧縮されたこと、正しく復元されたこと、利用者に届いたことは四つの別の観測である。

一つの緑ランプにしなかった

設定表は別の MIB view に置きやすいよう分離された。RFC 1473 のセキュリティ節は PPP の設定・制御権限をリスクとして扱い、読み取り専用化、保護された view、アクセス不能化を挙げる。関連する RFC 1471 は LCP、RFC 1472 は認証設定を管理した。この文書群は、全層を代表する一つの status を作らなかった。

運用で残すべきなのは連鎖である。変更者、エージェントの読戻し、設定世代、再起動 ID、双方向の要求と応答、Opened の出入り、その後のパケット・エラー・アプリケーション記録を結ぶ。

そうしなければ、再起動待ちの希望が現行設定に見え、未定義値が測定値に見え、Opened が配達済みに見える。

RFC 1473 は、管理可能性の出発点を示した。まだ成立していない事実を、成立した数値から区別することである。

出典