要約

  • Configure-Ackは、より良い値への修正や順序変更を許されなかった。最新のConfigure-RequestとIdentifier、オプション順、内容が完全に一致してこそ、受諾の証拠になった。
  • LCPの合意は双方向で独立していた。Nakは受け入れ可能な値を示し、Rejectは特定オプションの交渉を打ち切る。OpenedにはAckを送った事実と受け取った事実の両方が必要だった。

親切な修正でも「受諾」にはならなかった

端末Aが、自分の受信できる最大フレームサイズを提示したとする。BはMaximum-Receive-Unitを理解し、少し違う数値のほうが都合よいと考え、それをConfigure-Ackに書いて返す。人間同士なら小さな歩み寄りに見えるが、PPPでは無効な応答である。

RFC 1661はAckの自由を厳しく制限した。Identifierは直近の要求と対応し、オプションは順序も内容も変更してはならない。すべてが認識でき、すべての値をそのまま受け入れられる場合にだけAckを送る。

完全な複製は、分散した二つの状態を一致させる証拠になる。Ackが修正案を含められるなら、要求側は、元の案が承認されたのか、置き換えられたのか、第三の構成が生まれたのかを推測しなければならない。損失、再送、交差する要求が加われば、双方が別の合意を記憶しかねない。同じバイト列を返す規則なら、「この提案が受理された」という一点だけを検査できる。

Identifierは回答を特定の試行に結び付ける。内容を変えたとき、または以前の要求に有効な回答が届いた後には更新し、単なる再送では維持できる。ただし、これは相手の本人性を証明する番号ではない。古い会話を現在の合意と取り違えないための印である。

代案と拒絶には別の動詞が要った

Configure-Nakは、オプション自体は理解でき、交渉可能だが、その値を受け入れられない場合に使う。すでに問題のないオプションは応答から除き、争点だけを残して、Nak送信側が受け入れられる値を提示できる。地域方針上必要なのに要求から抜けているオプションを付け加えることもできる。

しかしNakは、送信中の要求を改変しない。要求側が提案を採用するなら、新しい内容とIdentifierを持つConfigure-Requestをもう一度送る。その新提案も、同一内容のAckを受けるまで有効にならない。

Configure-Rejectが示すのは、さらに硬い境界である。オプションを認識できない、実装していない、あるいは管理方針として交渉しない場合、相手は要求中の該当部分をそのまま返して拒絶する。次回の要求からは削除されるべきで、代替値を持たない真偽型オプションもRejectの対象になる。

Ackは確認、Nakは交渉余地、Rejectは交渉権そのものの否定である。どの応答にも、相手側のローカル方針を黙って書き換える権限はない。

一本の回線で二つの提案が進んだ

個別の規定がない限り、LCPオプションは片方向に適用され、通常はConfigure-Request送信側の受信方向を記述する。Aの要求は「BからAへ何を送れるか」を定め、Bは反対方向について別の要求を送る。

要求は回線上ですれ違える。Aは自分の要求に対するAckを得た一方で、Bの要求をAck、Nak、Rejectのどれで返すかまだ決めていないかもしれない。RFC 1171は、この状態をすでにAck-Receivedと呼んでいた。受け取った同意は、まだ与えていない同意を代行しない。

RFC 1331では、リンク確立の条件が明記された。Configure-Ackを送信し、かつ受信したときにLCPはOpenedへ進む。物理キャリアが上がったことや片方のAckだけでは、一端がリンク全体の開通を宣言できない。

この二重構造は現実の非対称性を受け入れる。受信容量、認証要求、圧縮能力、制御文字の扱いは左右で違ってよい。PPPが求めたのは同一の装置ではなく、各方向について証明できる互換状態だった。

書かれなかったオプションにも意味があった

Configure-Requestは能力一覧ではなく、標準の既定値から変えたい点を示す。RFC 1661は既定値のオプションを要求に含めないよう勧める。欠落は未知ではなく、既定値が続くという意味になる。

運用者が明示オプションだけを保存しても、実効構成は復元できない。受理された要求に既定値を補い、さらに方向を解釈する必要がある。

一つの要求に含まれるオプションは同時に評価される。Ackは順序付きリスト全体を受諾し、Nakは問題の値だけを示し、Rejectは交渉不能な項目だけを返す。原子的な回答を保ちつつ、装置に全能力の開示や全機能の採用を強制しない設計だった。

圧縮の合意がなくても制御言語は読めた

オプションによって後続フレームの形式そのものが変わる。Aだけが圧縮開始を信じ、Bが既定形式を読み続ければ、食い違いを修復する制御パケットまで理解できなくなる。

RFC 1548とRFC 1661は、構成、終了、Code-RejectのLCPパケットを、オプションが一切有効でない形式で送るよう定めた。Address、Control、Protocolフィールドの圧縮は、この制御経路には使わない。

これは合意を仮定する規則ではない。不一致を表現できる共通言語を残す規則である。データ面の効率化が、既定状態へ戻る道まで消してはならない。

沈黙にも終わらない値引き交渉にも上限があった

Configure-RequestはRestart timerと再送回数で損失に備える。Max-Configureは設定可能でなければならず、RFC 1661は既定として十回を推奨した。有効な応答が得られないことはローカルな中止理由になるが、攻撃や物理断を直接証明しない。

回答が来ても収束しない場合にはMax-Failureがある。推奨値は五回で、Nakが続いた後は、さらに送るはずのNakをRejectへ変え、自端が希望する追加オプションも付けなくなる。提案の距離が縮まらないなら、交渉空間を狭める。

LCPの開通はIPの開通ではなかった

四つの構成コードは1989年11月のRFC 1134にすでに登場し、RFC 1171、RFC 1331、RFC 1548を経て1994年7月のRFC 1661に残った。同時に、処理の段階も分離された。

下位層が物理経路の利用可能性を知らせ、LCPがネットワーク層に依存しない項目を調整する。認証を選んだ場合はその後に実行し、さらにNetwork Control ProtocolがIPなどを個別に開く。対応NCPがOpenedになる前に、そのネットワーク層のトラフィックを許可してはならない。

ゆえにConfigure-Ackが証明する範囲は狭い。相手の身元、認証成功、IPアドレス、経路、アプリケーション到達性は証明しない。回答者が特定のLCP提案をそのまま受け入れたことだけを示す。

現在のIANA PPPレジストリも、Request、Ack、Nak、Rejectをコード1から4として保持し、オプション番号を管理している。登録は共通語彙の証拠であり、現在の普及率や製品の正しさの証明ではない。

小さな同意が異なる装置をつないだ

PPPは「合意した」という曖昧な状態を避けた。受諾は完全一致、代案と拒絶は別のパケット、方向は別の状態、沈黙と反復には上限があり、上位層は独自に利用権を得る。

中央機関が個々のリンクのサイズ、圧縮、認証方式を決める必要はなく、片端が他端を支配する必要もなかった。共通仕様は両者が検査できる少数の事実だけを定め、残りの方針はリスクを負う側に残した。

情報源と限界

RFC 1134、RFC 1171、RFC 1331、RFC 1548、RFC 1661は歴史、形式、状態、収束限界を裏付け、IANAは現在の割当てを裏付ける。現代の利用率、実装適合性、性能、事業者慣行、普遍的なタイムアウトは示さない。完全一致を「薄い双方向の権限」と読む部分は、機構からの分析である。