要約

  • RFC 791は、次のプロトコルを示す八ビットのProtocolフィールドを定義したが、各値の意味は別のAssigned Numbers体系に委ねた。
  • RFC 3232は定期的なRFCのスナップショットをIANAのオンラインデータベースに置き換え、RFC 5237は256値の有限空間に対する割り当て方針を明確にした。

IPv4の受信側は、データ部を次にどのプロトコルへ渡すかを知る必要がある。Protocolフィールドが運ぶのは八ビットの値であって、プロトコル名、バージョン、実装方法を内包した自己記述情報ではない。RFC 791はフィールドの幅と位置を固定し、その値の意味をAssigned Numbersで確認する構成を採った。

この分離により、パケット形式とプロトコル目録は異なる速度で変化できる。パケットの解釈方法を保ったまま、共有される語彙を別の管理面で更新できるからだ。値は分用の指示であり、実際の有用性は仕様、送信者、受信者、実装が同じ意味を共有することにかかる。

固定された八ビットと外部の語彙

可能な値は256個しかない。フィールドは実装の存在を交渉せず、アプリケーションを特定せず、ペイロードを認証もしない。示すのは意図された次段の解釈だけである。

1977年11月から1994年10月まで、IANAはAssigned NumbersというRFCで割り当て表を定期公開した。1994年10月のRFC 1700がその系列の最後のスナップショットだった。

スナップショットから現在のレジストリへ

RFC 3232は、その後RFC系列がIANAのオンラインデータベースに置き換わったと記録する。RFC 1700はHistoricとなり、内容は不完全で一部は誤っている可能性があるとされた。変わったのは現在の調整情報を置く場所であり、IPv4の線上形式ではない。ルーターが各データグラムごとにIANAへ問い合わせるわけでもない。

希少性が政策を要求する

RFC 5237は、2008年時点で256値の55％が使用中だったと述べる。Standards ActionとIESG Approvalを残し、非開示に結び付いたExpert Reviewの経路を削除し、公開して検討できる仕様を求めた。安定した仕様、利用するコミュニティ、重複の回避、プロトコル番号が適切な仕組みかどうかも判断材料になる。

登録上の割り当ては、実装や経路上の対応を保証しない。レジストリは調整を改善するが、実装の遅れや中間装置の制限までは解消しない。

IPv4が長く使われた理由は、変えるべき場所を限定したことにある。八ビットの形は固定し、その意味と割り当てを更新可能な公共レジストリに託したのだ。

出典