要約

  • RFC 6709の「通常」は、パッチが小さい、コードが短いという意味ではない。基盤プロトコルと稼働中の実装が害なく無視できる場合に限り、通常の拡張とみなせる。既存ソフトウェアが変わる必要があれば、通信形式がほとんど変わらなくても大きな変更になり得る。
  • 通常と分類されても専門家の審査が免除されるわけではない。RFC 6709は審査をほとんど行わない手続きを限定し、通常の拡張でも専門家の意見が役立つと述べる。RFC 4775も、新しいRADIUS属性には既存のアーキテクチャと利用状況を知る専門家との議論が必要だと説明する。

一つの言葉に二つの判断を押し込まない

プロトコルを審査するとき、二つの問いは混ざりやすい。この拡張は、すでに使われているプロトコルや実装に何をもたらすのか。ほかの人が依存する前に、提案をどの程度審査すべきか。「通常」という言葉は両方に答えるように聞こえるが、RFC 6709はそうではないと示している。

Internet Architecture Board（IAB）は2012年9月、RFC 6709をInformational文書として公開した。対象は基盤プロトコルと拡張の設計者だ。拡張性は段階的な進化を助ける一方、相互運用、運用、セキュリティ上の問題も招き得る。通常と大きな拡張の区別は、提案がもたらす影響と必要な審査の程度を結びつけるためのものだった。これは設計上の指針であり、Internet Standardでも、あらゆる提案に適用される承認規則でもない。

RFC 6709は、より長い議論の中に自らを置く。1991年のメモ RFC 1263「TCP Extensions Considered Harmful」を、拡張のコストに関する先行する警告として挙げる。ただしRFC 1263には独自の歴史的論点がある。RFC 6709は、TCPのバージョン境界をめぐる議論をやり直したわけではない。拡張設計の一般的な考慮事項が、それまで一つにまとめられていなかったと述べた。IETFプロトコルを拡張する手続きは、2006年にBCP 125として公開されたRFC 4775が扱っていた。RFC 6709は、その作業に使うアーキテクチャ上の判定軸を明示しようとした。

大きな変更かどうかは、パケットの大きさでは決まらない

RFC 6709は八つの観点を挙げる。基盤プロトコルの実装を変更する必要があるか。ステートレスとして設計されたプロトコルにセッション状態を要求するなど、明示的または暗黙のアーキテクチャ前提を変えるか。新しい用途や規模が、トラフィック、パケットサイズ、処理負荷を増やし、既存システムの能力を超えるか。基盤プロトコルが定めた拡張モデルに適合するか。構文を変更するか。複数プロトコルにまたがる変更を結びつけるか。セキュリティモデルや既存環境の性能に影響するか。

いずれか一つでも、拡張が大きな変更になる理由となる。新しいメッセージ形式やトランスポートは、新機能を使わない稼働中の実装にも更新を迫るかもしれない。通信上のバイト列が変わらなくても、新たな規模が従来のアルゴリズムの限界を超える場合がある。未知の拡張を安全かつ一貫して扱う方法が基盤プロトコルに定義されていなければ、見た目には小さな変更でも、自動的に大きな変更の側へ入る可能性がある。これはRFC 6709が示す設計テストであり、数値スコアでも、現行製品についての診断でもない。

根本の問いは、誰が変わらなければならず、変わらない側に何が起きるかだ。コード差分の大きさはよい代理指標ではない。短いフィールドでもメッセージの解析方法を変えることがある。一方、より長いベンダー定義値が基盤プロトコルには見えないままのこともある。RFC 6709の基準では、前者が大きな変更、後者が通常の拡張になり得る。ただし、実際に互換性の条件を満たす場合に限る。

「通常」には厳しい境界がある

大きな拡張の基準に当てはまらず、基盤プロトコルから見て不透明に処理できる場合に限り、通常の拡張とみなせる。メッセージと応答のパターンを大きく変えてはならない。基盤仕様や、すでに稼働している実装は、拡張を使うと選んだシステムを除いて変更不要であるべきだ。ほかの実装も影響を受けず、通常は悪影響なしにその拡張を無視できる必要がある。

RFC 6709は、DHCPのベンダー固有オプション、RADIUSのVendor-Specific Attributes、MIBモジュール用の企業OID、ベンダー定義のMIMEタイプを例に挙げる。重要なのは、追加部分が小さいことではない。プロトコルが用意した拡張領域に収まり、参加しないシステムに新しい動作を要求しないことだ。

同じ箇所は、安易な読み方も防ぐ。RFC 6709は、First Come First Servedのように審査をほとんど、または全く行わない仕組みを使う場面は限定すべきだとする。相互運用、セキュリティ、運用上の危険が起きにくい場合に限る。さらに、通常の拡張にも専門家の審査が役立つと述べている。DHCPが不透明なデータとして受け取る値でも、構造がまったくなければクライアントやサーバーが扱いにくくなる。

RADIUSが示す二つの判断の違い

手続きを扱う関連文書のRFC 4775は、この違いを具体化する。基礎仕様に明確なIANA Considerationsがある通常のパラメーター割り当ては、定められた手順に沿って扱える。その範囲を超えれば、IETF専門家による明示的なプロトコル審査が必要になる。同文書は、新しいRADIUS属性について、プロトコルのアーキテクチャと既存の利用状況を知る専門家との議論を求める。そうしなければ相互運用や機能上の失敗が起きる危険が高いからだ。

一方RFC 6709は、RADIUSのベンダー固有属性を通常の拡張例に挙げている。矛盾ではない。二つの文書は別の問いに答えている。「通常」は、拡張がアーキテクチャに適合し、それを使わないシステムが安全に無視できるかを問う。RFC 4775は、どの手続きと専門知識で提案を扱うべきかを問う。RFC 6709自身が、通常の判定を通過しても専門家の審査を行えると明示している。

この区別は重要だ。文書の公開やパラメーターの割り当てだけでは、拡張の安全性、実装の有無、運用者による採用は証明されない。審査は提案が進む前に問題を見つけられるが、実装のテストや実際の展開を示す証拠の代わりにはならない。

ラベルではなく、三つの根拠を残す

有用なレビュー記録では三つの問いを分ける。第一に、基盤プロトコル、設計上の前提、メッセージ動作、資源需要の何が変わるのか。第二に、拡張を選ばない実装は安全に無視できるのか。第三に、その二つの答えから見て、プロトコル、安全、運用をどの程度審査する必要があるのか。

既存ソフトウェアの変更、メッセージ順序の変化、新しい状態の追加、複数プロトコルの連動、セキュリティ前提の変更があるなら、通常と呼ぶにはより強い説明が必要だ。拡張が本当に不透明で、使わない側に影響しないなら、通常と分類できる根拠になる。それでも専門家の審査を禁じるものではない。実装がどう振る舞うかをテストケースで示す必要がある。値が登録されたという事実だけで、稼働中の経路が正しく運べるとは限らない。

RFC 6709は、必要な範囲を超えて拡張機構を作り込まないようにも促す。将来の用途をすべて予見できないことは認めつつ、初期設計が考え得るあらゆる需要を満たす必要はないとする。安全に変更できる場所は用意する。ただし、あとから来るどんな用途でもそこに収まると思い込まない。そういう節度が読み取れる。

記録が示す範囲と、その外側

RFC 6709はIABの設計上の考え方を記録した文書であり、実装の実態調査ではない。RFC 4775が記録するのは手続きであって、各提案がその手続きを守ったことの証明ではない。出典から確認できるのは、文書が掲げた基準と注意点だ。展開された拡張の数、特定ネットワークでの採用、個別の事故発生は示されていない。

Heng LuのNote 64は別の編集上の視点を示す。相互運用に必要な共通ルールだけを初期仕様に定め、可能なら将来の選択を参加者に残し、実装と採用を通じて変化が運用上の現実になると見る考え方だ。これはBTWによる後年の解釈であり、IABの意図を示すものではない。この視点では、「通常」は互換性の境界を表す。公開、登録、審査の結果だけでは採用を証明できない。

RFC 6709の歴史的価値は、避けにくい問いを残したことにある。古いシステムは、この拡張を害なく無視できるのか。それとも変更を迫られるのか。答えが見えれば、その後で審査の強度を選べる。「通常」は無害の同義語ではなく、「大きな変更」はコード行数を数えた結果でもない。

出典