要約

  • 1991年10月の情報提供RFCであるRFC 1263は、当時RFC 1072とRFC 1185が提案したTCPの後方互換拡張に異議を唱え、同じヘッダーに機能を重ねるのではなく、プロトコルを明示的な版で進化させる方法を提案した。
  • 互換性は一斉更新を避け、変更を段階的に広げられる。しかし、変更の費用まで消えるわけではない。RFC 1263は、単一プロトコル内に複雑さが蓄積すると主張したが、自らの案が実装・展開されたことも、その方が安かったことも証明していない。

ヘッダーの外にも費用はある

RFC 1263の題名は、あらゆる拡張を否定するように読める。核心はむしろ、変更の費用をどこに置くかという問いだ。古い形式を保ち、追加の振る舞いをオプション欄に入れれば、破壊的な変更は避けられるように見える。だが作業は、能力交渉、パーサーの分岐、オプション領域の制約、組み合わせごとの実装・保守へ移り得る。

この文書は、プロトコルを新設する、後方互換のまま拡張する、旧ワイヤ形式を維持せず進化させる、という三つの道を比べる。新設にはインターフェースと普及が必要だ。互換拡張なら一斉配布せず各システムのペースで広がる。より自由な進化には、版の切り替え方を明示する必要がある。

著者は互換性に価値がないとは言っていない。その利点を「変更が無料」と取り違えるな、と注意する。ヘッダーへ簡単に追加できても、オプションと相互作用が増えるほど理解・保守が難しくなる。一方、二つの版を持つことも、無関係な設計を二つ作ることと同じではない。共通の仕組みが、端点に使う版を選べるからだ。

TCPを事例にした理由

例に挙がるのは、高遅延・高速パス向けのRFC 1072とRFC 1185である。RFC 1072はウィンドウ拡大、選択確認、エコー時刻情報などを扱い、RFC 1185は高速パス向け拡張を検討した。RFC 1263が疑問視したのは、機能の目的だけではなく、それらの意味を同じTCPのオプション方式に載せたまま互換性を保つ設計だった。

代案では、より大きくても構造の明快なヘッダーにプロトコル識別子を設け、TCPの版を見分ける。番号と確認番号を64ビット、ウィンドウを32ビットとし、エコー欄も追加する案だった。新機能が不要なシステムは従来のTCPを使い続け、必要な端点だけが選択レイヤーから新しい版を選べる。

著者は互換性の度合いが異なる選択肢も示した。旧TCPをそのままにして別版を選ぶ案、SYNでTCP VERSIONを交渉して単一のプロトコルに複数形式を持たせる案、追加情報をオプションに詰めてヘッダー形状を保つ案である。互換性を優先するほど、旧設計の制約も新しい版に持ち込まれる。

すでに二つの版が必要なのではないか

RFC 1263は、多くのシステムは結局TCPを二つの版で維持することになるだろうと述べる。選択肢は単純な「一つか二つ」ではない。条件分岐が増える一つのプロトコルにするのか、版の境界を定めてインフラに選ばせるのか、という問題だった。

二つの単純なプロトコルの方が、一つの複雑なプロトコルを保守するより安くなり得る、と文書は推測した。二つのコピーを保持するメモリーは追加費用として認めている。ただし、これは設計判断であって測定ではない。実環境の実装コストを比べる調査は示されていない。

互換性によって旧システムを止めずに新機能を広げられることはある。それでも運用面には、交渉、解析規則、限られたオプション領域、拡張間の相互作用、実装の長期保守が残る。版を分ければ責任が見えやすくなる一方、選択・配布・サポートの仕事が生まれる。

境界を引けば調整の場所が変わる

版選択の仕組みは、調整そのものをなくさない。利用可能な版を把握し、両端が共通の選択肢を見つけ、旧端点に理解できないヘッダーを送らないようにする必要がある。版識別子はソフトウェアに違いを示すが、中継機器や運用者が正しく扱う証拠にはならない。

RFC 1263が求めたのは、そうした費用を互換拡張の保守費用と正面から比べることだった。著者は、まれな出来事として既存プロトコルの内部へ隠すのではなく、繰り返す中で改善されるプロトコル配布基盤を望んだ。パケット形式だけでなく、技術と制度のインセンティブに関する主張でもある。

ただし、これは中立的な費用モデルではない。著者は単純な設計と迅速な進化を好み、当時の標準化プロセスを強く批判した。このRFCだけでは、その手続きが変更の決定的な障害だったとも、自らの配布案が成功したとも言えない。残る問いは、互換性が「誰も調整しなくてよい」と約束するとき、その費用を誰が負うのか、である。

文書が示すこと、示さないこと

RFC 1263は情報提供文書であり、TCPの最終標準を定めたものではない。新設・互換拡張・進化を比較するが、移行の完了、版選択基盤の展開、複数スタックの保守費用を記録してはいない。拡大したヘッダーと版選択はいずれも、この文書内の提案である。

歴史的な教訓は「後方互換は悪だ」ということではない。互換性は旧システムを動かしながら機能を普及させるのに役立つ。しかし、馴染みのある形式が将来の要求を無償で抱えるわけではない。明示的な版境界は責任を見えるようにするが、どちらが安いかまでは決めない。

出典と限界

本稿はRFC 1263, TCP Extensions Considered Harmful、RFC Editorの記録、RFC 1072, TCP Extensions for Long-Delay Paths、RFC 1185, TCP Extensions for High-Speed Pathsに基づく。これらは変更方式の比較、検討対象となったTCP案、版選択の代替案、および複雑さ・メモリー・配布費用に関する著者の主張を裏付ける。

これらの資料はRFC 1263案が実装・採用されたこと、実際に安価だったこと、あるいは後年のTCP設計を決定したことを証明しない。互換性が複雑さへ費用を移し得るという点は、このメモの主張と本稿による設計比較の解釈であり、実測値ではない。