要約

  • PPP の Echo-Reply は、対応付け用の Identifier を要求から引き継ぐ一方、Magic-Number には送信側自身の協議済みの値を用いる。
  • 数の一致だけではループバックを断定できない。パケットの種類、直前の要求や否定応答、双方の値の選び方が判断を支える。
  • 共通仕様は異常の見分け方を定めるが、相手の身元を認証せず、一律の復旧方法も命じない。検出と運用判断は別の仕事だった。

コピーする値、コピーしない値

PPP の LCP には Echo-Request と Echo-Reply がある。要求が届けば返事をするという名前通りの仕組みだが、応答全体を要求の複製と考えてはいけない。

1994年7月のRFC 1661では、Echo-Reply の Identifier は受信した要求からコピーする。どの要求への返事かを対応付けるためだ。一方、Magic-Number の協議が成功していれば、その欄には応答の送信者自身が協議した値を入れる。

要求元の数をそのまま返してしまえば、受信側は自分の数を再び見ることになる。ところが、この数は、自分の送信がそのまま戻ってきていないかを見分けるためにある。返事の対応関係と、返事を作った側の状態を、一つの値で兼ねてはいなかった。

ここには、診断情報を読むときの基本的な問題が表れている。同じパケットの中でも、欄ごとに証明できることは違う。対応する Identifier を見つけたからといって、相手が独立した値を送ってきたとは限らない。

壊れずに戻ることが問題になる

一本のポイントツーポイント回線なら、通信の関係は単純に見える。送る側があり、受ける側がある。しかし、途中の状態によっては、送ったフレームが同じ装置の受信側へ戻る。正しいビット列が届いていても、期待した相手が処理した結果ではないことがある。

これはフレームの破損とは異なる。RFC 1662が定めた HDLC に似た PPP のフレーム形式では、FCS によって対象となる部分の整合性を調べる。既定の FCS は2オクテットで、4オクテットの形式もある。だが、変更されずに一周してきたフレームなら、その検査を通ることもできる。

検査が弱いからではない。問うている事柄が違うのだ。FCS は対象のビット列と検査値の関係を見る。Magic-Number が必要としたのは、別の端点が独自の状態を持って応答しているという手掛かりだった。

したがって、この話のループは IP の経路ループでも、二つの UDP サービスが互いの返答を新しい要求として受け取る循環でもない。LCP が、自分の制御情報の折り返しを疑う場面である。

四つのオクテットには前史がある

Magic-Number を1994年の新発明として扱うと、PPP の拡張の仕方を見落とす。1989年11月のRFC 1134は、すでに PPP を封入形式、LCP、各ネットワーク層向けの NCP に分けていた。LCP でリンクを構成し、必要な NCP の設定を経て、ネットワーク層のデータを運べるようにする構想だった。

その Echo と Discard の形式にも、4オクテットの Magic-Number 欄がある。設定オプションによって変更されない限り、ゼロを送って受信時には無視する。さらに進んだ使い方は、そこでの説明の範囲外とされていた。

1990年7月のRFC 1172は、初期の設定オプションを具体化した。数の衝突、値を選び直すやり取り、乱数源の質、相手にも同じ機能を認める制約が、すでに説明されている。1992年5月のRFC 1331もこの仕組みを引き継いだ。

先に欄を設け、次に共有できる振る舞いを定める。この積み重ねが重要だった。仕様の発行だけで、動いている装置の初期化処理や乱数生成が変わるわけではない。共通の意味は、実装がその条件を満たして初めて働く。

同じ値を見つけたら、違いを作りにいく

オプションを提案する端点は、まず自分の Magic-Number を選ぶ。必要なのは世界中で重複しない番号ではなく、そのリンクの反対側と高い確率で異なる値だ。

Magic-Number を含む Configure-Request を受け取ると、直前に自分が送った Configure-Request の値と比べる。違っていれば、仕様が想定するモデルでは単純な折り返しではない。同じなら、まだ二つの可能性がある。自分の要求が戻ったのかもしれないし、実在する相手が偶然同じ数を選んだのかもしれない。

一致した場合は、別の値を指定した Configure-Nak を送る。ここで通常の処理を飛び越えて、新しい Configure-Request を直ちに追加するのではない。Nak の受信や再開タイマーの満了など、通常のきっかけに従って次へ進む。

さらに、受信した Nak の値は、直前に自分が送った Nak の値と比較する。Request と Nak の履歴を混ぜてはいけない。また一致すれば折り返しの疑いが強まり、新たな値を選ぶ必要がある。異なれば、想定された振る舞いの下で、別の端点の選択が見えてくる。

本物のループでは、要求も変更提案も自分に戻り続け得る。独立した二つの端点なら、値の選択は通常やがて分かれる。仕組みの中心は、一致したという事実そのものより、一致から抜け出すための手順にある。

同じ数が正解になる応答もある

ただし、どの受信値も一律にこの比較へ入れてよいわけではない。Configure-Ack は、要求された設定オプションを変更も並べ替えもせず返す必要がある。Identifier も対応していなければならない。

したがって、自分が提案した数が有効な Ack に入って戻るのは正常だ。相手の新しい Request に同じ数が入る場合とは意味が違う。要求の種類を見ずに「自分と同じ数を受信した回数」を数えるだけでは、正常な確認を障害へ変えてしまう。

この点は、冒頭の Echo の話ともつながる。Ack では提案された値を保つ必要があり、Echo-Reply では送信者の協議済みの値を使う。同じ数字でも、どの動作に属するかによって扱いが変わる。魔術数には、単独で読める普遍的な判定規則はない。

乱数という名前では独立性を保証できない

歴史的な RFC には、32ビットの一様な選択を仮定した衝突確率が示されている。一度の一致は約2.3×10^-10という理想化された見積もりだ。これは、実際の装置群で測った誤検出率ではない。

同じ初期状態から同じ手順で値を作る二台は、独立した抽選を行っているとは限らない。同じ要求を何度受け取っても、その分だけ独立な試行が増えるわけではない。また、オプションとして提案するゼロは不正なので、合法な非ゼロ値だけを一様に選ぶ実装の候補数は、単純な32ビット全体とはわずかに異なる。

重要なのは、小数点以下の見栄えではなく前提だ。値を分岐させるだけの良い一意性や乱数性の源がなければ、オプションを自分から提案しない方がよい、と仕様は勧めている。相手の提案には確認または拒否で対応できるが、弱い生成方法から信頼できる局所検出能力が生まれるわけではない。

機能を使わない選択を認めることと、能力の不足を隠すことは違う。PPP はこの差を残していた。

相手の拒否が役に立つ理由

自分が Magic-Number を提案するなら、相手が同じオプションを提案したときに Configure-Reject で拒否してはならない。この相互制約には、診断上の意味もある。

自分の提案に対して Configure-Reject が届けば、規則に従う自分自身はその動作を作らない。仕様のモデルでは、別の実装が拒否したと判断できる。RFC 1661は、相手が Magic-Number を使わないことを理解した上で、協議が成功したかのように進める扱いを示している。

これは双方が同じ能力を獲得したという意味ではない。まして、拒否した相手の所属や権限が証明されたわけでもない。自分ならしない動作を観測したという限定的な情報である。悪意のある相手まで常に規則通りに振る舞うという保証は、ここにはない。

ゼロを正しく残す

通常動作時の適用対象となる診断欄では、成功した協議がなければゼロを送る。相手が自分の数を協議していないなら、そのゼロには既定の意味がある。一方、設定オプションの候補としてゼロを出すことは許されず、オプションを拒否しないのであれば Nak を返す必要がある。

協議済みの自分の値を受信すれば、モデル上は折り返しを示す。予想された相手の値、または相手の正当な既定値であるゼロなら通常のケースだ。それ以外の値は、異なる相手との通信になっている可能性を示す。

Echo-Request と Echo-Reply は LCP の Opened 状態でのみ送信するという制約も守らなければならない。状態の外で届いたものは黙って破棄すべきとされる。こうした条件を取り去ってから数字だけを分析しても、仕様通りの結論には戻れない。

番号の意味と相手の身元を分ける

IANA の PPP 登録表には、Magic-Number が LCP 設定オプションの型5として載る。全体の長さは6オクテットで、型と長さの後に4オクテットの数が続く。登録表が共有するのは「型5の意味」であり、個々の端点が選ぶ数の割り当てではない。

同じ表で Authentication-Protocol は別の型3である。認証には別の根拠が要る。1996年8月のRFC 1994が説明する CHAP は、チャレンジと共有秘密を用いた計算結果で相手を検証する。ここで旧来の方式を引用するのは役割の違いを示すためで、現在の導入を勧めるためではない。

Magic-Number は見える局所状態であり、秘密を知っていることの証明ではない。相手が存在するらしいこと、相手が誰であるか、その相手との上位サービスが正常であることを、一つの判定へまとめてはいけない。

復旧の一手は仕様の外に残された

RFC 1661は、異常後の復旧手順を一つに固定しなかった。Down として扱い再開する方法や、適切な状態で Echo を使い折り返しの終了を見る方法などを例示する。すべての装置に共通の回数や待ち時間を命じてはいない。

同じ証拠を互換性のある方法で読むことと、同じ費用を払って復旧することは別だからだ。PPP の小さな欄は、相手からの返事を見分ける助けになった。しかし、その助けを身元証明や運用上の命令へ拡張しないことも、設計の一部だった。