要約

  • RFC 1365は、固定された送信元・宛先アドレス欄にクラスFの印を置き、アドレスの残りをIPオプションから読む方式を提案した。
  • 同じ文書は、クラスFを知らないホストはデータグラムを無視すると認めた。外形を保つことと、旧機器と通信できることは別だった。

封筒の寸法を変えずに、宛名だけ長くする。そんな工夫が必要とされた時代があった。Karanjit Siyanが1992年9月に公表したRFC 1365は、従来のアドレス区分ではネットワーク番号が足りなくなるという問題に対し、IPヘッダーのオプション欄を使うことを提案した。文書はInformationalであり、意見を求める提案だった。

使える余白は決まっていた。ヘッダー長を示す４ビットの欄が表せるのは、４オクテットの語で最大15語。基本部分が５語を使い、残りは10語だ。Siyanは通常のオプションに６語を残し、新たな拡張アドレス用に４語を充てようとした。無限の空間を見つけたのではなく、既存の上限の中で配分を変えたのである。

送信元と宛先の固定欄には、新しいクラスFを示す上位ビット111110を置く。同じ欄のオフセットは、オプション欄にあるアドレス後半の位置を語単位で指す。受信側は全オプションを順に探さず、その位置へ移れる。後半はタイプ・長さ・値の形式で、文書にはF-4とF-8という形が出てくる。Fの印を設けるため、予約済みのクラスEの定義も11110へ狭める案だった。

問題は受信プログラムがその合図を理解するかだ。文書の相互運用性の節は、未対応ホストならデータグラムを無視し、既存ホストとは通信できないと明記する。受信処理を追加するコードの概略まで示した。新しいヘッダーや別のプロトコルを導入するより改修量が小さい、というのが著者の主張である。改修不要とは書いていない。

同時期のRFC 1375にも「クラスF」が現れるが、そちらは小規模ネットワークに適したアドレス区分の話だ。RFC 1365の焦点は、アドレスを固定欄とオプション欄に分ける仕組みと、それを旧ホストが読めないという境界にある。同じ文字を一つの設計史にまとめると、肝心の違いを失う。

原文から確認できるのは設計と、著者自身が記した互換性の問題までだ。導入したネットワークの数は示されていない。残るのは単純な場面である。封筒は同じ形でも、宛名の読み方が変われば、古い受信者は受け取れない。