|
Network Working Group Request for Comments: 919 |
Jeffrey Mogul Computer Science Department Stanford University October 1984 |
ブロードキャストをサポートしているローカルなネットワークに、インターネットデータグラムをブロードキャストしたり、ブロードキャストをアドレス付けたり、ゲートウェイがそれらをどのように扱うべきかについての簡単な規則を提案する。
この RFC は、ARPA インターネット社会の提案プロトコルを提案し、改善のための議論と提案を求めている。このメモの配布は、制限されない。
この提案は、他の複数の人々との議論の結果である。特に J. Noel Chiappa と Christopher A. Kent は、重要な参照を指し示してくれた。
Table of Contents
1. 導入
2. 用語
3. なぜブロードキャストか?
4. ブロードキャストクラス
5. ブロードキャスト方法
6. ゲートウェイとブロードキャスト
7. ブロードキャスト IP アドレッシング - Proposed Standards
7.1 ARPサーバとブロードキャスト
8. 参照
特に高速なローカルエリアネットワーク上でのブロードキャストの使用は、多くのアプリケーションにとって優れた基盤である。ブロードキャストは、基本的な IP 規約 [13] ではカバーされていないので、それを行うための合意された方法が存在しない。よって、プロトコル設計者はまだそれを使用していない。(この問題は以前、[6] 等で触れられたが、標準の主題にはならなかった)。
ここでは、信頼性が無く、順序どおりでなく、重複が起こり得るデータグラムブロードキャストのケースのみを考慮する (TCP のブロードキャストの議論については [11] を参照されたい)。信頼性が無く、長さに制限があるが、データグラムブロードキャストは極めて有効である [1]。
ローカルネットワークのデータリンク層は、効率的なブロードキャストをサポートしていると仮定する。大半の一般的なローカルエリアネットワークは、実際にブロードキャストをサポートしている。例えば、イーサネット [7],[5]、カオスネット [10]、トークンリングネットワーク [2] 等がそうである。
しかし、ブロードキャストは確実に配送されるとは仮定しない。(ある人は、IP の上の層に信頼できるブロードキャストプロトコルの提供を検討しているかもしれない)。ブロードキャストの配送を保証することは、極めてコストがかかる。代わりに、ホストは送信されたブロードキャストの大半を受信するだろうと仮定する。これはブロードキャストの過度の使用を避けるために重要である。というのは、ネットワーク上の全てのホストは、少なくとも全てのブロードキャストの何らかの影響を受け、それらはコストのかかる事だからである。
データグラムがブロードキャストされる時、それを受信した全てのホストにコストを押し付ける。従って、ブロードキャストはむやみに使用すべきでなく、問題を解決する最善の方法である時にのみ使用すべきである。
注記: いくつかの組織では、標準 [8] が提案されたことで、IP ネットワークをサブネットに分割している。この RFC は、サブネットとブロードキャスト間の相互動作が絡む複雑さをカバーしていない。完全な議論については、[9] を参照されたい。
ブロードキャストは、ローカルネットワーク上で使用する特定のデータリンクに依存するので、物理ネットワークと論理ネットワークの両方に関して論じなければならない。
物理ネットワークを参照する際に使用する用語は、ブロードキャストを送信、又は転送するホストの観点から:
ローカルハードウェアネットワーク
(Local Hardware Network)
ホストが接続されている物理リンク。
リモートハードウェアネットワーク
(Remote Hardware Network)
少なくとも一つのゲートウェイによって、ホストから切り離されている物理ネットワーク。
ハードウェアネットワークの集まり
(Collection of Hardware Networks)
ゲートウェイによって (透過的に) 接続されたハードウェアネットワークの集合体。
IP の世界は、複数の種類の論理ネットワークを含んでいる。曖昧さを避けるために、以下の用語を使用する。
インターネット
(Internet)
IP ネットワークの DARPA インターネット集合
IP ネットワーク (IP Network)
1 つの特定の IP ネットワーク番号を持つ、1 つのハードウェアネットワーク、あるいは複数のハードウェアネットワークの集まり
ブロードキャストは、他のホストが何を供給できるか正確に知らずに情報を見つける必要がある時や、ホストがホストの大きな集合体に適宜情報を提供したい時に有効である。
ホストが一つ以上の隣接者が持つ情報を必要とする時、尋ねるための隣接者のリストを持つことが出来たり、誰かが応答するまで有り得る全ての隣接者に投げることが出来る。組み込みリストを使用すると、明らかにネットワーク管理の問題を引き起こす (早めの結合は融通性が無い)。一方、隣接者全てに尋ねる場合、もしもっともらしいホストアドレスを生成し、誰かが動作するまでそれを試みなければならないならば、遅くなるだろう。ARPANET では例えば、大体 65000 個のもっともらしいホスト番号が存在する。大半の IP 実装は、組み込みリストを使用していた (例えば "主要な" ゲートウェイのアドレス等)。幸運にも、ブロードキャストはホストが全ての隣接者に到達する高速で簡単な方法を提供する。
ホストは、ある情報を全ての隣接者に提供することにもブロードキャストを使用してもよい。例えば、ゲートウェイは他のゲートウェイに自分の存在をアナウンスしてもよい。
ブロードキャストを考察する一つの方法は、マルチキャストの不完全な代用として、ネットワーク上のホストのサブセットへのメッセージを送信することである。実際、ブロードキャストは、マルチキャストが望まれる場合に通常使用される。パケットはハードウェアレベルでブロードキャストされるが、受信側ホストのフィルタリングソフトウェアは、マルチキャストの効果を提供する。
より詳細なブロードキャストアプリケーションの例は、[1],[3] を参照されたい。
IP ブロードキャストには幾つかのクラスが存在する。
- ローカル
IP ネット上の単一宛先のデータグラムブロードキャスト
データグラムは特定の IP ホストに向けられるが、送信側ホストは恐らくルーティングすることを避けるためにデータリンクレベルでブロードキャストする。これは
IP ブロードキャストではないので、ホストは自分に向けられていないデータグラムを慌てず(例えばエラーメッセージを出力するなどせず)に破棄しなければならないことを除き、IP層は関係ない。
- ローカル IP ネット上の全てのホストへのブロードキャスト
IP アドレスのホスト番号部分で区別される値が、特定のホストの代わりにブロードキャストを示す。受信側の
IP 層は、自分自身のアドレスだけでなくこのアドレスも認識できなければならない。
しかし、特にゲートウェイにおいて、ブロードキャストと非ブロードキャストを上位レベルで区別することも有効である。これは最も有効なブロードキャストのケースであり、これによってホストはゲートウェイを組み込みテーブル無しで発見することが出来る。それは、アドレス解決プロトコルの基礎を成しており、ネームサーバやタイムサーバなどのユーティリティに、組み込みアドレスを必要とせずにアクセスすることも有効である。
- リモート IP ネットワーク上の全てのホストへのブロードキャスト
非ローカルネットワーク上の全てのホストにプロトコルを送信することは、時折有効である。例えば、ホスト名データベースの最新の版を見つけたり、ブートサーバ無しで
IP ネットワーク上のホストをブートロードしたり、IP
ネットワーク上のタイムサーバを監視するなどがある。このケースは、ローカルネットワークのブロードキャストと同じであり、データグラムは宛先の
IP ネットワークに接続されているゲートウェイに到達するまで、通常のメカニズムによって配送され、そのゲートウェイでブロードキャストされる。このブロードキャストのクラスは、"直接ブロードキャスト"
あるいは昔風に "手紙爆弾" [1] としても知られている。
- インターネット全体へのブロードキャスト
これは恐らく有効ではなく、ほぼ確実に望ましくない。
パフォーマンスやセキュリティの理由により、ゲートウェイはブロードキャストを転送しないことを選択してもよい。特に、ネットワークの自律グループへの、あるいは自律グループからのブロードキャストを禁ずることは良い考えかもしれない。
ホストの IP 受信層は、ブロードキャストをサポートするよう修正しなければならない。ブロードキャストがない時は、ホストは、宛先アドレスを自分の IP アドレスの全てと照合することによって、データを受信するか否か決定する。ブロードキャストを適用する場合、ホストは自分のアドレスだけでなく、そのホストにとって有り得るブロードキャストアドレスとも照合しなければならない。
ブロードキャストを送信する最善の方法についての問題は、[1], [3], [4], [14], [15] で詳細に論じられている。その問題はデータリンク層で既に解決されていると仮定しているので、ローカルのブロードキャストか直接のブロードキャストを送信したい IP のホストは、適切な宛先アドレスを指定して、通常通りにデータグラムを送信するだけでよい。洗練されたアルゴリズムが必要なのは、ゲートウェイだけである。
ブロードキャストをサポートする複雑さの大半は、ゲートウェイにある。もしゲートウェイが、接続していないネットワーク向けの直接ブロードキャストを受信したら、単に通常のメカニズムを使用して転送する。さもなくば、追加の動作を行わなければならない。
ゲートウェイがローカルのブロードキャストデータグラムを受信したら、処理しなければならない幾つかのことがある。条件は曖昧ではないが、無限ループを引き起こす可能性を考慮しなければならない。
ブロードキャストデータグラムの受信時における適切な動作は、幾つかの事に依存する。それは、受信されたサブネット、宛先ネットワーク、ゲートウェイのアドレスである。
もし異なる IP 実装が互換性を持とうするならば、"全てのホスト" を示すための識別番号が存在しなければならない。
自側のネットワーク層は、常に IP アドレスをデータリンク層のアドレスにマッピングすることが出来るので、"ホスト番号をブロードキャストする" IP の選択は、若干曖昧である。単純化するために、実ホストに割り当てられないような番号が一つ存在すべきである。全てのビットが 1 である番号は、この特性を持つ。この割り当ては最初に [6] で提案された。ホスト番号部がすべて 1 のアドレスを割り当てられたホストは希なケースであり、再番号付けを必要とすることは面倒ではなさそうである。
アドレス 255.255.255.255 は、転送されてはならないローカルハードウェアネットワーク上のブロードキャストを示す。このアドレスは、例えばネットワーク番号を知らないホストが、あるサーバに尋ねる時に使用される。
従ってネットワーク番号 36 上のホストは、例えば、
(注記: もしネットワークがサブネットに分割されていなければ、これらの二つの方法による効果は同じである。)
もし、IP アドレスのフィールドで "全て 1" の使用が "ブロードキャスト" を示すならば、"全て 0" の使用は "不特定" として見ることができる。ICMP 情報要求データグラムの送信元アドレス以外では、このアドレスが使用される理由は恐らくないだろう。しかし表記上の慣習として、ネットワークを参照する際に (ホストとは逆に) 0 のフィールドを使用している。例えば、36.0.0.0 は "ネットワーク番号 36" を意味し、36.255.255.255 は "ネットワーク番号 36 上の全てのホスト" を意味する。
[12] で規定されているアドレス解決プロトコル (ARP: Address Resolution Protocol) は、もし誤って実装されていたら、全てのホストがブロードキャストのアドレスが何かについての認識を共有しているわけではないネットワーク上で、ブロードキャストが使用されると、問題を引き起こす。IP ブロードキャストアドレスとハードウェアブロードキャストアドレス間のマッピングを提供するよう、ARP サーバを修正したい誘惑もある。
この誘惑は拒否しなければならない。ARP サーバは、ターゲットがブロードキャストアドレスである要求に応答してはならない。そのような要求は、ブロードキャストアドレスをブロードキャストアドレスとして認識していないホストからのみ来る。よって、それを生かすことはほぼ確実に転送ループを引き起こすだろう。もし、物理ネットワーク上にこのアドレスをブロードキャストとして認識していないホストが N 個存在したら、T の生存時間を持って送信されたデータグラムは、潜在的に T**N 個の誤った再ブロードキャストに跳ね上がるだろう。
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.