Network Working Group Jeffrey Mogul Request for Comments: 919 Computer Science Department Stanford University October 1984 BROADCASTING INTERNET DATAGRAMS Status of this Memo ブロードキャストをサポートしているローカルなネットワークに、インタ ーネットデータグラムをブロードキャストしたり、ブロードキャストをア ドレス付けたり、ゲートウェイがそれらをどのように扱うべきかについて の簡単な規則を提案する。 この RFC は、ARPA インターネット社会の提案プロトコルを提案し、改善 のための議論と提案を求めている。このメモの配布は、制限されない。 Acknowledgement この提案は、他の複数の人々との議論の結果である。特に J. Noel Chiappa と Christopher A. Kent は、重要な参照を指し示してくれた。 1. 導入 特に高速なローカルエリアネットワーク上でのブロードキャストの使用は、 多くのアプリケーションにとって優れた基盤である。ブロードキャストは、 基本的な IP 規約 [13] ではカバーされていないので、それを行うための 合意された方法が存在しない。よって、プロトコル設計者はまだそれを使 用していない。(この問題は以前、[6] 等で触れられたが、標準の主題には ならなかった)。 ここでは、信頼性が無く、順序どおりでなく、重複が起こり得るデータグ ラムブロードキャストのケースのみを考慮する (TCP のブロードキャスト の議論については [11] を参照されたい)。信頼性が無く、長さに制限があ るが、データグラムブロードキャストは極めて有効である [1]。 ローカルネットワークのデータリンク層は、効率的なブロードキャストを サポートしていると仮定する。大半の一般的なローカルエリアネットワー クは、実際にブロードキャストをサポートしている。例えば、イーサネッ ト [7], [5]、カオスネット [10]、トークンリングネットワーク [2] 等が そうである。 しかし、ブロードキャストは確実に配送されるとは仮定しない。(ある人は、 IP の上の層に信頼できるブロードキャストプロトコルの提供を検討してい るかもしれない)。ブロードキャストの配送を保証することは、極めてコス トがかかる。代わりに、ホストは送信されたブロードキャストの大半を受 信するだろうと仮定する。これはブロードキャストの過度の使用を避ける ために重要である。というのは、ネットワーク上の全てのホストは、少な くとも全てのブロードキャストの何らかの影響を受け、それらはコストの かかる事だからである。 データグラムがブロードキャストされる時、それを受信した全てのホスト にコストを押し付ける。従って、ブロードキャストはむやみに使用すべき でなく、問題を解決する最善の方法である時にのみ使用すべきである。 注記: いくつかの組織では、標準 [8] が提案されたことで、IP ネットワ ークをサブネットに分割している。この RFC は、サブネットとブロードキャ スト間の相互動作が絡む複雑さをカバーしていない。完全な議論について は、[9] を参照されたい。 2. 用語 ブロードキャストは、ローカルネットワーク上で使用する特定のデータリ ンクに依存するので、物理ネットワークと論理ネットワークの両方に関し て論じなければならない。 物理ネットワークを参照する際に使用する用語は、ブロードキャストを送 信、又は転送するホストの観点から: ローカルハードウェアネットワーク (Local Hardware Network) ホストが接続されている物理リンク。 リモートハードウェアネットワーク (Remote Hardware Network) 少なくとも一つのゲートウェイによって、ホストから切り離されている 物理ネットワーク。 ハードウェアネットワークの集まり (Collection of Hardware Networks) ゲートウェイによって (透過的に) 接続されたハードウェアネットワー クの集合体。 IP の世界は、複数の種類の論理ネットワークを含んでいる。曖昧さを避け るために、以下の用語を使用する。 インターネット (Internet) IP ネットワークの DARPA インターネット集合 IP ネットワーク (IP Network) 1 つの特定の IP ネットワーク番号を持つ、1 つのハードウェアネット ワーク、あるいは複数のハードウェアネットワークの集まり 3. なぜブロードキャストか? ブロードキャストは、他のホストが何を供給できるか正確に知らずに情報 を見つける必要がある時や、ホストがホストの大きな集合体に適宜情報を 提供したい時に有効である。 ホストが一つ以上の隣接者が持つ情報を必要とする時、尋ねるための隣接 者のリストを持つことが出来たり、誰かが応答するまで有り得る全ての隣 接者に投げることが出来る。組み込みリストを使用すると、明らかにネッ トワーク管理の問題を引き起こす (早めの結合は融通性が無い)。一方、隣 接者全てに尋ねる場合、もしもっともらしいホストアドレスを生成し、誰 かが動作するまでそれを試みなければならないならば、遅くなるだろう。 ARPANET では例えば、大体 65000 個のもっともらしいホスト番号が存在す る。大半の IP 実装は、組み込みリストを使用していた (例えば "主要な" ゲートウェイのアドレス等)。幸運にも、ブロードキャストはホストが全て の隣接者に到達する高速で簡単な方法を提供する。 ホストは、ある情報を全ての隣接者に提供することにもブロードキャスト を使用してもよい。例えば、ゲートウェイは他のゲートウェイに自分の存 在をアナウンスしてもよい。 ブロードキャストを考察する一つの方法は、マルチキャストの不完全な代 用として、ネットワーク上のホストのサブセットへのメッセージを送信す ることである。実際、ブロードキャストは、マルチキャストが望まれる場 合に通常使用される。パケットはハードウェアレベルでブロードキャスト されるが、受信側ホストのフィルタリングソフトウェアは、マルチキャス トの効果を提供する。 より詳細なブロードキャストアプリケーションの例は、[1],[3] を参照さ れたい。 4. ブロードキャストクラス IP ブロードキャストには幾つかのクラスが存在する。 - ローカル IP ネット上の単一宛先のデータグラムブロードキャスト: データグラムは特定の IP ホストに向けられるが、送信側ホストは恐 らくルーティングさせることを避けるために、データリンク層でブロ ードキャストする。これは IP ブロードキャストではないので、ホス トは自分に向けられていないデータグラムを慌てず (例えばエラーメッ セージを出力するなどせず) に破棄すべきであることを除き、IP 層 は関係ない。 - ローカル IP ネット上の全てのホストへのブロードキャスト: IP ア ドレスのホスト番号部分で区別される値が、特定のホストの代わりに ブロードキャストを示す。受信側の IP 層は、自分自身のアドレスだ けでなくこのアドレスも認識できなければならない。 しかし、特にゲートウェイにおいて、ブロードキャストと非ブロード キャストを上位レベルで区別することも有効である。これは最も有効 なブロードキャストのケースであり、これによってホストはゲートウェ イを組み込みテーブル無しで発見することが出来る。それは、アドレ ス解決プロトコルの基礎を成しており、ネームサーバやタイムサーバ などのユーティリティに、組み込みアドレスを必要とせずにアクセス することも有効である。 - リモート IP ネットワーク上の全てのホストへのブロードキャスト: 非ローカルネットワーク上の全てのホストにプロトコルを送信するこ とは、時折有効である。例えば、ホスト名データベースの最新の版を 見つけたり、ブートサーバ無しで IP ネットワーク上のホストをブー トロードしたり、IP ネットワーク上のタイムサーバを監視するなど がある。このケースは、ローカルネットワークのブロードキャストと 同じであり、データグラムは宛先の IP ネットワークに接続されてい るゲートウェイに到達するまで、通常のメカニズムによって配送され、 そのゲートウェイでブロードキャストされる。このブロードキャスト のクラスは、"直接ブロードキャスト" あるいは昔風に "手紙爆弾" [1] としても知られている。 - インターネット全体へのブロードキャスト: これは恐らく有効ではな く、ほぼ確実に望ましくない。 パフォーマンスやセキュリティの理由により、ゲートウェイはブロードキャ ストを転送しないことを選択してもよい。特に、ネットワークの自律グル ープへの、あるいは自律グループからのブロードキャストを禁ずることは 良い考えかもしれない。 5. ブロードキャスト方法 ホストの IP 受信層は、ブロードキャストをサポートするよう修正しなけ ればならない。ブロードキャストがない時は、ホストは、宛先アドレスを 自分の IP アドレスの全てと照合することによって、データを受信するか 否か決定する。ブロードキャストを適用する場合、ホストは自分のアドレ スだけでなく、そのホストにとって有り得るブロードキャストアドレスと も照合しなければならない。 ブロードキャストを送信する最善の方法についての問題は、[1], [3], [4], [14], [15] で詳細に論じられている。その問題はデータリンク層で既に解 決されていると仮定しているので、ローカルのブロードキャストか直接の ブロードキャストを送信したい IP のホストは、適切な宛先アドレスを指 定して、通常通りにデータグラムを送信するだけでよい。洗練されたアル ゴリズムが必要なのは、ゲートウェイだけである。 6. ゲートウェイとブロードキャスト ブロードキャストをサポートする複雑さの大半は、ゲートウェイにある。 もしゲートウェイが、接続していないネットワーク向けの直接ブロードキャ ストを受信したら、単に通常のメカニズムを使用して転送する。さもなく ば、追加の動作を行わなければならない。 ゲートウェイがローカルのブロードキャストデータグラムを受信したら、 処理しなければならない幾つかのことがある。条件は曖昧ではないが、無 限ループを引き起こす可能性を考慮しなければならない。 ブロードキャストデータグラムの受信時における適切な動作は、幾つかの 事に依存する。それは、受信されたサブネット、宛先ネットワーク、ゲー トウェイのアドレスである。 - ループを避ける基本的な規則は、"受信したハードウェアネットワー ク上にはデータグラムをブロードキャストしない" ことである。ゲー トウェイが自分自身から受信したデータグラムのリピートを単純に避 けるだけでは十分でない。ハードウェアネットワーク上に複数のゲー トウェイが存在する場合は、依然としてループが起こり得る。 - もしデータグラムをそのアドレスがあるハードウェアネットワーク上 で受信したら、それを転送してはならない。しかし、ゲートウェイは 自分がデータグラムの宛先であると見なさなければならない (例えば、 それはルーティングテーブルの更新かもしれない)。 - さもなくば、もしデータグラムがゲートウェイに接続されているハー ドウェアネットワークのアドレスならば、そのネットワーク上に (デ ータリンク層の) ブロードキャストとして送信しなければならない。 また、ゲートウェイは自分がデータグラムの宛先であると見なさなけ ればならない。 - さもなくば、ゲートウェイは次のゲートウェイを選択する通常のルー ティング手続きを使用し、それに従ってデータグラムを送信しなけれ ばならない。 7. ブロードキャスト IP アドレッシング - Proposed Standards もし異なる IP 実装が互換性を持とうするならば、"全てのホスト" を示す ための識別番号が存在しなければならない。 自側のネットワーク層は、常に IP アドレスをデータリンク層のアドレス にマッピングすることが出来るので、"ホスト番号をブロードキャストする" IP の選択は、若干曖昧である。単純化するために、実ホストに割り当てら れないような番号が一つ存在すべきである。全てのビットが 1 である番号 は、この特性を持つ。この割り当ては最初に [6] で提案された。ホスト番 号部がすべて 1 のアドレスを割り当てられたホストは希なケースであり、 再番号付けを必要とすることは面倒ではなさそうである。 アドレス 255.255.255.255 は、転送されてはならないローカルハードウェ アネットワーク上のブロードキャストを示す。このアドレスは、例えばネッ トワーク番号を知らないホストが、あるサーバに尋ねる時に使用される。 従ってネットワーク番号 36 上のホストは、例えば、 - 255.255.255.255 を使用して、直近の隣接者の全てにブロードキャス トする。 - 36.255.255.255 を使用して、ネットワーク 36 の全てにブロードキャ ストする。 (注記: もしネットワークがサブネットに分割されていなければ、これらの 二つの方法による効果は同じである。) もし、IP アドレスのフィールドで "全て 1" の使用が "ブロードキャスト" を示すならば、"全て 0" の使用は "不特定" として見ることができる。 ICMP 情報要求データグラムの送信元アドレス以外では、このアドレスが使 用される理由は恐らくないだろう。しかし表記上の慣習として、ネットワ ークを参照する際に (ホストとは逆に) 0 のフィールドを使用している。 例えば、36.0.0.0 は "ネットワーク番号 36" を意味し、36.255.255.255 は "ネットワーク番号 36 上の全てのホスト" を意味する。 7.1 ARPサーバとブロードキャスト [12] で規定されているアドレス解決プロトコル (ARP: Address Resolution Protocol) は、もし誤って実装されていたら、全てのホス トがブロードキャストのアドレスが何かについての認識を共有している わけではないネットワーク上で、ブロードキャストが使用されると、問 題を引き起こす。IP ブロードキャストアドレスとハードウェアブロー ドキャストアドレス間のマッピングを提供するよう、ARP サーバを修正 したい誘惑もある。 この誘惑は拒否しなければならない。ARP サーバは、ターゲットがブロ ードキャストアドレスである要求に応答してはならない。そのような要 求は、ブロードキャストアドレスをブロードキャストアドレスとして認 識していないホストからのみ来る。よって、それを生かすことはほぼ確 実に転送ループを引き起こすだろう。もし、物理ネットワーク上にこの アドレスをブロードキャストとして認識していないホストが N 個存在 したら、T の生存時間を持って送信されたデータグラムは、潜在的に T**N 個の誤った再ブロードキャストに跳ね上がるだろう。 8. 参照 1. David Reeves Boggs. Internet Broadcasting. Ph.D. Th., Stanford University, January 1982. 2. D.D. Clark, K.T. Pogran, and D.P. Reed. "An Introduction to Local Area Networks". Proc. IEEE 66, 11, pp1497-1516, 1978. 3. Yogan Kantilal Dalal. Broadcast Protocols in Packet Switched Computer Networks. Ph.D. Th., Stanford University, April 1977. 4. Yogan K. Dalal and Robert M. Metcalfe. "Reverse Path Forwarding of Broadcast Packets". Comm. ACM 21, 12, pp1040-1048, December 1978. 5. The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications. Version 1.0, Digital Equipment Corporation, Intel, Xerox, September 1980. 6. Robert Gurwitz and Robert Hinden. IP - Local Area Network Addressing Issues. IEN-212, Bolt Beranek and Newman, September 1982. 7. R.M. Metcalfe and D.R. Boggs. "Ethernet: Distributed Packet Switching for Local Computer Networks". Comm. ACM 19, 7, pp395-404, July 1976. Also CSL-75-7, Xerox Palo Alto Research Center, reprinted in CSL-80-2. 8. Jeffrey Mogul. Internet Subnets. RFC-917, Stanford University, October 1984. 9. Jeffrey Mogul. Broadcasting Internet Packets in the Presence of Subnets. RFC-922, Stanford University, October 1984. 10. David A. Moon. Chaosnet. A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, June 1981. 11. William W. Plummer. Internet Broadcast Protocols. IEN-10, Bolt Beranek and Newman, March 1977. 12. David Plummer. An Ethernet Address Resolution Protocol. RFC-826, Symbolics, September 1982. 13. Jon Postel. Internet Protocol. RFC 791, ISI, September 1981. 14. David W. Wall. Mechanisms for Broadcast and Selective Broadcast. Ph.D. Th., Stanford University, June 1980. 15. David W. Wall and Susan S. Owicki. Center-based Broadcasting. Computer Systems Lab Technical Report TR189, Stanford University, June 1980.