要約

  • RFC 919はホスト部の全ビット1を「全ホスト」とし、255.255.255.255を転送しないローカルブロードキャストにした。
  • RFC 922はIPデータグラムの形式を変えずに、この考え方をサブネットへ広げた。
  • RFC 1122は全ビット1の送信形式を標準化しながら、古い全ビット0形式も受信できるよう推奨した。

宛先が1台だけを指さなくなったとき

基本的なIP仕様には、データグラムを全ホストへ送る共通方式がなかった。RFC 919は、ローカルリンクがすでに持っていたブロードキャスト機能をIPの宛先表現に結び付け、複数のホストが自分宛てとして認識できる値を定めた。

ただし、この配送は信頼性を持たない。失われたり、順序が変わったり、重複したりする可能性があり、受信する各ホストにも処理負担がかかる。確実なグループ配送の仕組みではなかった。

なぜ全ビット1だったのか

相互運用には「全ホスト」を表す特別なホスト番号が必要だった。RFC 919は、実在のホストに割り当てられている可能性が低いとして、全ビット1を選んだ。

255.255.255.255は接続された物理ネットワーク上の全ホストを表し、転送してはならない。一方、36.255.255.255はネットワーク36の全ホストを表す。ゲートウェイはそこまで運び、最後にリンク層ブロードキャストへ展開できる。同じ1の並びでも、アドレス階層のどのフィールドにあるかで範囲が変わる。

ゼロのフィールドは未指定やネットワーク表記に使われた。標準は1を採用したが、ゼロを放送に使う既存実装を直ちに否定したわけではない。

サブネットで広がった階層

RFC 922は、IPデータグラムを変更せず、ネットワーク、サブネット、ホストの各フィールドに同じ解釈を適用した。どのフィールドが全ビット1か、そして有効なアドレスマスクが何かによって、宛先はローカルの物理ネットワーク、遠隔の物理ネットワーク、特定のサブネット、またはIPネットワーク内の全サブネットを表した。ゲートウェイはデータグラムが入ってきた物理ネットワークへ再度ブロードキャストしてはならなかった。

ARPとの境界でも認識が重要だった。ARPサーバーはブロードキャスト宛ての要求に応答してはならない。特殊な宛先を理解できないホストがいると、ループや再送の連鎖的な増加を招くためである。

標準化された送信と寛容な受信

RFC 1122は、限定ブロードキャスト {-1,-1}、ネットワーク指定 {network,-1}、サブネット指定 {network,subnet,-1}、全サブネット指定 {network,-1,-1}という4形式を定義した。

ホストは標準形式を認識しなければならず、4.2BSD系などが使った、-1をゼロに置き換える非標準形式も認識すべきだった。インターフェースは送信形式を選べたが、既定値は全ビット1であるべきだった。

古い入力を受け入れ、新しい形式を送るという非対称な移行である。リンク層のブロードキャスト宛てに送る場合、IP宛先は合法なブロードキャストまたはマルチキャストでなければならない。リンク層ブロードキャストとして受信したフレームのIP宛先がそのどちらでもなければ、ホストは静かに破棄すべきだった。

限定された範囲がもたらした頑健性

RFC 1122は接続ネットワークでは限定ブロードキャストを推奨した。ネットワーク番号やマスクを各機器が同じように理解していなくても使いやすいからである。指定ブロードキャストを転送するかどうかは、ゲートウェイの性能・安全性の方針に残された。

歴史の要点は、単純に1がゼロに勝ったことではない。送信では1が標準になり、ゼロは互換性のための受信入力として残った。その組合せが、リンクの機能を共通のIPv4アドレス契約へ変えたのである。ただし、信頼性や転送の保証を与えたわけではない。

出典