要約

  • 1998年6月のRFC 2360は、標準を書く人のためのBCP 22であり、プロトコルそのものではない。明瞭な文書は相互運用の可能性を高めるが、保証はしないと明記した。
  • 中心課題は正常系の外側だった。不正入力を部分利用するか全棄却するか、棄却後に接続や隣接状態を残すか、資源限界でどの仕事を守るかを共通動作として書く必要があった。
  • 要求語、形式文法、パケット図、要約表、状態機械は互いを補う。どれも実装・試験・運用観測を代行しない。

解析の成功は、判断の一致ではない

パケット図は安心を与える。幅、位置、順序、フラグの意味が同じなら、二つの実装は同じプロトコルを話しているように見える。

RFC 2360は、その図が終わる場所から始めた。ルーティング更新の個数欄と実データ量が一致しないとき、末尾を無視する実装と、追加経路として採用する実装と、更新全体を疑う実装が生まれる。三者とも既知のフィールドを正しく解析できる。それでも転送状態は三つに分かれる。

Gregor D. Scottが編集した本書は、成功例と失敗例から得た標準記述上の教訓をまとめた。ただし、その背後にある個別事故を列挙してはいない。確認できる主張は限定される。曖昧な仕様は独立実装の相互運用を妨げる。明瞭さはその障害を減らすが、実装が一致したという観測にはならない。

この限界は、文書の権限を正しい場所に置く。IETFは共通動作を宣言できる。各製品のコードを実行したり、あらゆるメモリ圧迫やタイミングを先に経験したりはできない。

「破棄」の後に何が残るか

RFC 2360が仕様外動作を独立項目にしたのは、そこで実装判断が割れやすかったからだ。破棄、エラー処理、部分回復のどれも、状況によって合理的になりうる。危険なのは文書が選ばず、各実装の常識に任せることだった。

無効フレームを未着として扱えば、既存タイマーは進み、隣接関係は残るかもしれない。同じフレームを同期喪失の証拠とみなせば、接続をリセットする。双方ともデータは採用しないが、共有履歴は一致しない。

資源枯渇もプロトコル動作である。キュー、識別子、メモリ、処理能力の上限に達したとき、新規処理を拒むのか、古い状態を捨てるのか、相手に通知するのか。ローカルな生存策が隣接ノードに見えなければ、拒否と損失の区別さえつかない。

だから本書は「送信は保守的に、受信は寛容に」を無限定の免許にしなかった。送信規則と受信規則を分け、利用可能部分を救う範囲とエラー手続きへ移る境界を記すよう求めた。曖昧な経路情報を受け入れるプロトコルでは、寛容さ自体が障害を拡散しうる。

状態機械は時間と記憶を書く

パケット図が空間を示すのに対し、状態機械は時間を示す。同じメッセージが開始中には合法で、終了後には不正となる。タイムアウトが再送を起こす状態もあれば、無視される状態もある。アクション順序が逆なら、相手が観測する途中状態も変わる。

RFC 2360は、状態、変数、イベント、遷移、アクションを記し、必要なら実行順も示すよう勧めた。しかし図表を正文より上位には置かなかった。状態図や表、時間線は補助であり、矛盾時には詳細な本文が優先する。同一要求を複数箇所で説明するなら、どれが拘束的かを明確にする必要がある。

要約表は別の失敗を減らす。長い文書で必須・任意・禁止の機能を落とさないための索引になる。網羅を助けるが、適合を証明しない。

MUSTは動詞を強めても、状態を作らない

RFC 2119の要求語は、相互運用に必要な義務や有害動作の制限を見つけやすくした。RFC 2360はその定義を独自に変えないよう求めた。

それでも「MUST reject」だけでは足りない。何を、いつ、どの単位で拒否するのか。応答するのか。シーケンス番号は進むのか。既存セッションは使えるのか。強い言葉は、書かれていない遷移を生成しない。

形式文法も同じである。合法な文字列は定義できるが、送信者の権限、コマンドの効果、資源不足からの回復は単独で決められない。機械が読めても人間が理解しにくい記法は、明瞭な説明の代わりにならないと本書は警告した。

OPTIONALは判断を消さず、出会いまで運ぶ

任意機能は合意を作りやすい。しかし二つの製品が出会えば、対応能力、既定値、フォールバック、組み合わせの互換性を決めなければならない。RFC 2360は、実在する要件、使用時と不使用時の効果、排他的選択を明記するよう求めた。

基本機能から任意機能を省いた実装が、それだけで相互運用不能になってはならない。特にセキュリティ機能の既定値は、利便性のため保護が無言で消えないよう注意が要る。

後年のRFC 6709は拡張の危険を詳しく扱った。比較はできるが、RFC 2360からの直接因果を示す資料ではない。1998年の要点は、OPTIONALという一語の背後に互換性費用を隠さないことだった。

決定理由は次の実装者への証拠になる

変更履歴、版の差、決定史は、昔の合意を永久化する仕組みではない。元の参加者が去った後も、なぜ容易な代案が退けられたのかを検証できるようにするものだ。

理由が消えると、境界を守っていた規則は儀式に見える。理由が残れば、新しい実装経験、試験結果、攻撃事例を基に明示的に変更できる。

セキュリティ、管理、規模、安定性、国際化、番号割当の記述も同様に、パケット外の前提を表へ出す。誰が共通番号を管理するか、どのトポロジーで収束しないか、どの資源が有限か、運用者が何を観測できるかは、プロトコルの一部である。

文書・コード・観測を混ぜない

Lu HengのRunning-Code PrimacyとReality Layersに従えば、RFC 2360の価値を誇張せずに読める。仕様は期待動作を述べる。実装は一つの解釈を示す。相互運用試験は限定した版と条件での一致を記録する。運用観測は実負荷と敵対入力の結果を示す。

完全な状態表はコードの遵守を証明しない。二製品の会話成功は文書適合を証明しない。正常系テストは枯渇時の一致を証明しない。無事故運用は全オプション組み合わせの安全性を証明しない。

最小の共通仕様には、文法だけでなく共有状態を変える判断が必要になる。RFC 2360が残した歴史はそこにある。プロトコルとは送信されたビットだけでなく、理想条件が崩れた後に双方が取る次の一手でもある。

出典と限界

出版情報と本文はRFC 2360の記録およびRFC 2360全文による。標準化過程はRFC 2026、要求語はRFC 2119、設計原則はRFC 1958、当時の執筆指針はRFC 2223を参照した。例として挙げられた文書にはRFC 1122とRFC 2328があり、RFC 6709は後年の比較材料である。証拠の境界にはLu HengのRunning-Code Primacy、Minimum Initial Specification、Reality Layersを用いた。現在の適合率、各助言の背後にある特定事件、後続RFCの全面遵守はこれらの資料からは確定できない。