要約

  • LCP が Opened であっても、相手が送るすべての PPP Protocol 値が実装済みとは限らない。未知の値には LCP Code 8 の Protocol-Reject を返す設計だった。
  • 拒否は二オクテットの Rejected-Protocol と、相手の MRU を超えない Rejected-Information で対象を限定した。
  • NCP の拒否は通常運用内の RXJ+ になり得るが、LCP 自身の拒否は RXJ- である。障害を局所化できるのは、拒否を運ぶ制御面が共有されている間だけだった。

「開いた」の対象はリンクだった

1989 年の RFC 1134 は、PPP を複数のネットワーク層プロトコルのデータグラムをポイント・ツー・ポイント回線で運ぶ方式として提示した。LCP が共通のリンクを確立・設定し、その上で複数の Network Control Protocol が個別のネットワーク層を扱う。リンクの合意と各プロトコルの利用可能性は、最初から別の状態だった。

この分離は、リンクが正常に Open した後の不一致を生む。一方が相手の知らない値を PPP Protocol フィールドに入れて送ることがある。LCP が Open の場合、RFC 1134 は受信側に Code 8 の Protocol-Reject を返させた。リンク全体を閉じるのではなく、理解できなかったプロトコルを名指しする応答である。

RFC 1331 は 1992 年、似て非なる状態を整理した。実装がプロトコルを知っていても対応する NCP がまだ Opened でなければ、パケットは黙って捨てる。Protocol 値そのものが未知なら、LCP Opened 中に Protocol-Reject を返す。前者は順序の問題、後者は能力の境界である。

したがって、応答がないことは対応済みの証明にならない。LCP が未開通、NCP が未開通、パケット損失、非準拠実装のいずれでも沈黙は起こる。反対に Code 8 が届いても、物理回線や認証の失敗を直接証明しない。分かったのは、共有リンク内の特定のプロトコルが相手に受け入れられなかったことだ。

返す証拠にも受信上限があった

RFC 1661 による完成形では、Code は 8、Identifier は Protocol-Reject を送るたびに変更しなければならない。Rejected-Protocol は二オクテットで、拒否されたパケットの PPP Protocol フィールドをそのまま格納する。

Rejected-Information は元パケットの Information フィールドから始まる。データリンク層ヘッダーと FCS は含まず、相手との間で確立した MRU に収まるよう必ず切り詰める。診断のための返送が、受信側の合意した最大サイズを破ってはならない。エラー報告自身もリンク契約の内側に置かれた。

このフィールドは完全なフレーム複製ではない。短くなり得るし、リンク層の外枠は最初から除外される。Identifier も永続的な障害番号ではない。Code 8 が与えるのは、拒否対象を特定し送信側が止められるだけの、型付きで有限な証拠である。

1993 年の RFC 1548 と 1994 年の RFC 1661 がこの機構を引き継いだ。仕様上の継続は設計の定着を示すが、個々の製品の実装品質や現在の利用率までは示さない。

受け取った側ではなく、送った側が止める

Protocol-Reject の受信後、実装は示されたプロトコルのパケット送信を「可能な限り早い機会」に停止しなければならない。すでにキューや回線上にあるパケットがゼロになる保証ではない。しかし、明示的な非対応を一時的損失として無限に再試行する余地もない。

NCP の例を見ると範囲が分かる。RFC 1332 の IPCP は PPP 上の IP を設定し、RFC 5072 の IPv6CP は IPv6 のための制御を定める。これは多重化構造の具体例であって、観測中の回線で使われている証拠ではない。ある NCP が拒否されれば、そのネットワーク層サービスは利用可能とは言えない。他のプロトコルが続けられるのは、それぞれが対応し設定済みの場合だけである。

Protocol-Reject を送れるのは LCP Opened 中だけで、別状態で受信したものは黙って破棄するべきだ。この制約は、共有状態を持たない拒否メッセージが相手の状態機械を動かすのを防ぐ。拒否する権限は、拒否を伝えるチャネルについて双方が合意した後に生まれる。

RXJ の符号は拒否対象で変わった

RFC 1331 の RXJ+ は許容可能な拒否受信である。NCP の Protocol-Reject はその例で、通常運用の範囲にあり、該当するパケット型を止めても LCP を維持できる。

RXJ- は破局的な拒否である。LCP が Protocol-Reject された場合、仕様は回復不能として接続を終了する。同じ Code 8 でも、拒否対象の階層が違う。個別の NCP を失っても、LCP が残れば「何が使えないか」を伝え続けられる。LCP 自身が未知とされたら、その不一致を局所化する共通言語がない。

ここでリンク継続とサービス継続は分かれる。LCP が開いたままでも、必要な唯一の NCP が拒否されればアプリケーションには全面停止に見える。キャリアが生きている事実を、利用目的が満たされた証拠にしてはならない。

登録値は実装の在庫表ではない

IANA の PPP 番号表 は LCP Code 8 を Protocol-Reject とし、Protocol フィールドの割当を公開している。番号の意味を解読する権威ある資料だが、装置が実装する機能、NCP の状態、現在のトラフィックを証明しない。

RFC 3818 は PPP 名前空間の割当方針を IETF Consensus に整理した。拡張可能な番号空間が管理されている証拠であり、普及率調査ではない。実際の対応を語るには、登録表に加え、設定、状態、パケット、拒否後の挙動を結ぶ必要がある。

出典