|
Network Working Group Request for Comments: 922 |
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. ゲートウェイとブロードキャスト
6.1. ローカルブロードキャスト
6.2. 複数サブネットブロードキャスト
6.3. 擬似アルゴルルーティングアルゴリズム
7. ブロードキャスト IP アドレッシング - Conventions
7.1 ARPサーバとブロードキャスト
8. 参照
特に高速なローカルエリアネットワーク上でのブロードキャストの使用は、多くのアプリケーションにとって優れた基盤である。ブロードキャストは、基本的な IP 規約 [12] ではカバーされていないので、それを行うための合意された方法が存在しない。よって、プロトコル設計者はまだそれを使用していない。(この問題は以前、[6] 等で触れられたが、標準の主題にはならなかった)。
ここでは、信頼性が無く、順序どおりでなく、重複が起こり得るデータグラムブロードキャストのケースのみを考慮する (TCP のブロードキャストの議論については [10] を参照されたい)。信頼性が無く、長さに制限があるが、データグラムブロードキャストは極めて有効である [1]。
ローカルネットワークのデータリンク層は、効率的なブロードキャストをサポートしていると仮定する。大半の一般的なローカルエリアネットワークは、実際にブロードキャストをサポートしている。例えば、イーサネット [7], [5]、カオスネット [9]、トークンリングネットワーク [2] 等がそうである。
しかし、ブロードキャストは確実に配送されるとは仮定しない。(ある人は、IP の上の層に信頼できるデータグラムブロードキャストプロトコルの提供を検討しているかもしれない)。ブロードキャストの配送を保証することは、極めてコストがかかる。代わりに、ホストは送信されたブロードキャストの大半を受信するだろうと仮定する。これはブロードキャストの過度の使用を避けるために重要である。というのは、ネットワーク上の全てのホストは、少なくとも全てのブロードキャストの何らかの影響を受け、それらはコストのかかる事だからである。
データグラムがブロードキャストされる時、それを受信した全てのホストにコストを押し付ける。従って、ブロードキャストはむやみに使用すべきでなく、問題を解決する最善の方法である時にのみ使用すべきである。
ブロードキャストは、ローカルネットワーク上で使用する特定のデータリンクに依存するので、物理ネットワークと論理ネットワークの両方に関して論じなければならない。
物理ネットワークを参照する際に使用する用語は、ブロードキャストを送信、又は転送するホストの観点から:
ローカルハードウェアネットワーク
(Local Hardware Network)
ホストが接続されている物理リンク。
リモートハードウェアネットワーク
(Remote Hardware Network)
少なくとも一つのゲートウェイによって、ホストから切り離されている物理ネットワーク。
ハードウェアネットワークの集まり
(Collection of Hardware Networks)
ゲートウェイによって (透過的に) 接続されたハードウェアネットワークの集合体。
IP の世界は、複数の種類の論理ネットワークを含んでいる。曖昧さを避けるために、以下の用語を使用する。
インターネット
(Internet)
IP ネットワークの DARPA インターネット集合
IP ネットワーク (IP Network)
1 つの特定の IP ネットワーク番号を持つ、1 つのハードウェアネットワーク、あるいは複数のハードウェアネットワークの集まり
サブネット (Subnet)
IP ネットワークを構成するハードウェアネットワークの集まりの単一メンバ。所定のサブネット上のホストアドレスは、 その
IP ネットワークの他の全てのサブネット上のホストと、IP
ネットワーク番号を共有する。しかし、ホストがどのサブネット上に存在するすを示すために、ローカルアドレス部はサブネット番号とホスト番号のフィールドに分けられる。我々は、ローカルアドレス部の特定の分割を仮定することはしない。これはネットワークによって変わりえる。
アドレス付けの階層にサブネットを導入することにより、IP 規定 [12] と相違が生じる。しかし、アドレス付け可能なサブネットの使用が急増しているので、ブロードキャストのスキームがサブネットをサポートすべきであることは明白である。サブネットについての詳細は [8] を参照されたい。
このドキュメントでは、"ホストアドレス" という用語は、サブネット化された IP ネットワークのサブネット上のホストアドレスフィールドを意味し、サブネット化されていなければホスト部のフィールドを意味する。
IP ネットワークは、単一のハードウェアネットワークかサブネットの集まりで構成されるかもしれないが、別の IP ネットワーク上のホストの観点から、それは問題ないはずである。
ブロードキャストは、他のホストが何を供給できるか正確に知らずに情報を見つける必要がある時や、ホストがホストの大きな集合体に適宜情報を提供したい時に有効である。
ホストが一つ以上の隣接者が持つ情報を必要とする時、尋ねるための隣接者のリストを持つことが出来たり、誰かが応答するまで有り得る全ての隣接者に投げることが出来る。組み込みリストを使用すると、明らかにネットワーク管理の問題を引き起こす (早めの結合は融通性が無い)。一方、隣接者全てに尋ねる場合、もしもっともらしいホストアドレスを生成し、誰かが動作するまでそれを試みなければならないならば、遅くなるだろう。ARPANET では例えば、大体 65000 個のもっともらしいホスト番号が存在する。大半の IP 実装は、組み込みリストを使用していた (例えば "主要な" ゲートウェイのアドレス等)。幸運にも、ブロードキャストはホストが全ての隣接者に到達する高速で簡単な方法を提供する。
ホストは、ある情報を全ての隣接者に提供することにもブロードキャストを使用してもよい。例えば、ゲートウェイは他のゲートウェイに自分の存在をアナウンスしてもよい。
ブロードキャストを考察する一つの方法は、マルチキャストの不完全な代用として、ネットワーク上のホストのサブセットへのメッセージを送信することである。実際、ブロードキャストは、マルチキャストが望まれる場合に通常使用される。データグラムはハードウェアレベルでブロードキャストされるが、受信側ホストのフィルタリングソフトウェアは、マルチキャストの効果を提供する。
より詳細なブロードキャストアプリケーションの例は、[1],[3] を参照されたい。
IP ブロードキャストには幾つかのクラスが存在する。
- ローカルハードウェアネット上の単一宛先のデータグラムブロードキャスト
データグラムは特定の IP ホストに向けられるが、送信側ホストは恐らくルーティングさせることを避けるために、データリンク層でブロードキャストする。これは IP ブロードキャストではないので、ホストは自分に向けられていないデータグラムを慌てず (例えばエラーメッセージを出力するなどせず) に破棄すべきであることを除き、IP 層は関係ない。
- ローカルハードウェアネット上の全てのホストへのブロードキャスト
IP アドレスのホスト番号部分で区別される値が、特定のホストの代わりにブロードキャストを示す。受信側の IP 層は、自分自身のアドレスだけでなくこのアドレスも認識できなければならない。
しかし、特にゲートウェイにおいて、ブロードキャストと非ブロードキャストを上位レベルで区別することも有効である。これは最も有効なブロードキャストのケースであり、これによってホストはゲートウェイを組み込みテーブル無しで発見することが出来る。それは、アドレス解決プロトコルの基礎を成しており、ネームサーバやタイムサーバなどのユーティリティに、組み込みアドレスを必要とせずにアクセスすることも有効である。
- リモートハードウェアネットワーク上にある全てのホストへのブロードキャスト
非ローカルネットワーク上の全てのホストにプロトコルを送信することは、時折有効である。例えば、ホスト名データベースの最新の版を見つけたり、ブートサーバ無しでサブネット上のホストをブートロードしたり、サブネット上のタイムサーバを監視するなどがある。このケースは、ローカルネットワークのブロードキャストと同じであり、データグラムは宛先のハードウェアネットワークに接続されているゲートウェイに到達するまで、通常のメカニズムによって配送され、そのゲートウェイでブロードキャストされる。このブロードキャストのクラスは、"直接ブロードキャスト" あるいは昔風に "手紙爆弾" [1] としても知られている。
- サブネット化された IP ネットワーク上の全てのホストへのブロードキャスト (複数サブネットブロードキャスト)
IP アドレスのサブネット番号部で区別される値は、"全てのサブネット" を示すために使用される。リモートのサブネット化された IP ネットワークの全てのホストにブロードキャストするには、単に一つのサブネットに直接ブロードキャストする。
- インターネット全体へのブロードキャスト
これは恐らく有効ではなく、ほぼ確実に望ましくない。
パフォーマンスやセキュリティの理由により、ゲートウェイはブロードキャストを転送しないことを選択してもよい。特に、ネットワークの自律グループへの、あるいは自律グループからのブロードキャストを禁ずることは良い考えかもしれない。
ホストの IP 受信層は、ブロードキャストをサポートするよう修正しなければならない。ブロードキャストがない時は、ホストは、宛先アドレスを自分の IP アドレスの全てと照合することによって、データを受信するか否か決定する。ブロードキャストを適用する場合、ホストは自分のアドレスだけでなく、そのホストにとって有り得るブロードキャストアドレスとも照合しなければならない。
ブロードキャストを送信する最善の方法についての問題は、[1], [3], [4], [13], [14] で詳細に論じられている。その問題はデータリンク層で既に解決されていると仮定しているので、ローカルのブロードキャストか直接のブロードキャストを送信したい IP のホストは、適切な宛先アドレスを指定して、通常通りにデータグラムを送信するだけでよい。洗練されたアルゴリズムが必要なのは、ゲートウェイだけである。
サブネット化された IP ネットワーク上の全てのホストにブロードキャストすることの問題は、見たところある程度困難そうである。しかしこのケースでも、ゲートウェイでないホストに複雑さを加える必要がない、最も良く知られたアルゴリズムが判明している。優れたブロードキャストの方法は、以下の追加標準に適合するだろう
最善と思われるアルゴリズムは、逆パス転送 (RPF: Reverse Path Forwarding) 方法 [4] である。RPF はコストや信頼性において最適ではないが、それは非常に優れており、実装するのは極めて容易で、ゲートウェイにデータ空間の追加を必要としない。
ブロードキャストをサポートする複雑さの大半は、ゲートウェイにある。もしゲートウェイが、接続していないネットワーク向けの直接ブロードキャストを受信したら、単に通常のメカニズムを使用して転送する。さもなくば、追加の動作を行わなければならない。
ゲートウェイがローカルのブロードキャストデータグラムを受信したら、処理しなければならない幾つかのことがある。条件は曖昧ではないが、無限ループを引き起こす可能性を考慮しなければならない。
ブロードキャストデータグラムの受信時における適切な動作は、幾つかの事に依存する。それは、受信されたサブネット、宛先ネットワーク、ゲートウェイのアドレスである。
ゲートウェイが IP ネットワークの全てのサブネットに向けられたブロードキャストを受信したとき、何をすべきかを決めるのに逆パス転送アルゴリズムを使用しなければならない。その方法は簡単である。もしデータグラムが、ゲートウェイとデータグラムの送信元との間の最善の経路の一部であるリンク上に到着したら、ゲートウェイは接続されている全てのリンクへデータグラムの複製を転送する。さもなくば、データグラムを破棄しなければならない。
もし幾つかの、あるいは全てのゲートウェイがそれらの間で追加情報を交換するならば、このアルゴリズムを改善してもよい。これは、他のホストや他のゲートウェイの観点から透過的に行うことが出来る。詳細は [4] [3] を参照されたい。
これは、ゲートウェイが使用しなければならないルーティングアルゴリズムの擬似アルゴルの説明である。アルゴリズムは、図 1 に示されている。以下は定義である。
RouteLink(host)
パラメタとしてホストアドレスを指定し、ゲートウェイからホストまでの第一ホップのリンクを返却する関数。
RouteHost(host)
上記関数と同様だが、第一ホップのホストアドレスを返却する。
ResolveAddress(host)
IP ホストのハードウェアアドレスを返却する。
IncomingLink
パケットが到達したリンク。
OutgoingLinkSet
パケットを送信しなければならないリンクのセット。
OutgoingHardwareHost
パケットを送信するところのハードウェアホストアドレス。
Destination.host
宛先アドレスのホスト部。
Destination.subnet
宛先アドレスのサブネット部。
Destination.ipnet
宛先アドレスの IP ネットワーク部。
BEGIN
IF Destination.ipnet IN AllLinks THEN
BEGIN
IF IsSubnetted(Destination.ipnet) THEN
BEGIN
IF Destination.subnet = BroadcastSubnet THEN
BEGIN /* 逆パス転送アルゴリズムを使用 */
IF IncomingLink = RouteLink(Source) THEN
BEGIN IF Destination.host = BroadcastHost THEN
OutgoingLinkSet <- AllLinks - IncomingLink;
OutgoingHost <- BroadcastHost;
有り得る内部使用についてパケットをチェック;
END
ELSE /* 別のゲートウェイからの複製、破棄する */
破棄;
END
ELSE
IF Destination.subnet = IncomingLink.subnet THEN
BEGIN /* 転送するとループを招く */
IF Destination.host = BroadcastHost THEN
有り得る内部使用についてパケットをチェック;
破棄;
END
ELSE BEGIN /* (有り得るローカルの)サブネットに転送する */
OutgoingLinkSet <- RouteLink(Destination);
OutgoingHost <- RouteHost(Destination);
END
END
ELSE BEGIN /* 自ローカルネットワークの誰か宛て */
IF Destination.ipnet = IncomingLink.ipnet THEN
BEGIN /* 転送するとループを招く */
IF Destination.host = BroadcastHost THEN
有り得る内部使用についてパケットをチェック;
破棄;
END
ELSE BEGIN /*ブロードキャストしてもよい */
OutgoingLinkSet <- RouteLink(Destination);
OutgoingHost <- RouteHost(Destination);
END
END
END
ELSE BEGIN /* 非ローカル IP ネットワークに転送 */
OutgoingLinkSet <- RouteLink(Destination);
OutgoingHost <- RouteHost(Destination);
END
OutgoingHardwareHost <- ResolveAddress(OutgoingHost);
END
もし異なる IP 実装が互換性を持とうするならば、"全てのホスト" と "全てのサブネット" を示すための識別番号の取り決めが存在しなければならない。
自側のネットワーク層は、常に IP アドレスをデータリンク層のアドレスにマッピングすることが出来るので、「ホスト番号をブロードキャストする」IP の選択は、幾分か曖昧である。単純化の為に、実ホストに割り当てられない番号が一つあるべきである。全てのビットが 1 である番号は、この特性を持つ。この割り当ては最初に [6] で提案された。ホスト番号部がすべて 1 のアドレスを割り当てられたホストは希なケースであり、再番号付けを必要とすることは困難であるようには見えない。 自側のネットワーク層は、常に IP アドレスをデータリンク層のアドレスにマッピングすることが出来るので、"ホスト番号をブロードキャストする" IP の選択は、若干曖昧である。単純化するために、実ホストに割り当てられないような番号が一つ存在すべきである。全てのビットが 1 である番号は、この特性を持つ。この割り当ては最初に [6] で提案された。ホスト番号部がすべて 1 のアドレスを割り当てられたホストは希なケースであり、再番号付けを必要とすることは面倒ではなさそうである。
"全てのサブネット" 番号もまた、全て 1 である。これは、リモートの IP ネットワーク上の全てのホストにブロードキャストすることを望んでいるホストが、宛先アドレスがどのようにサブネットとホストフィールドに区切られているか、あるいは分けられているか否かさえ知る必要が無いことを意味する。例えば、36.255.255.255 は、単一のハードウェアネットワーク上の全てのホストを示すかもしれないし、1 バイトのサブネットフィールドと 2 バイトのホストフィールドを持つサブネット化されて IP ネットワーク上の全てのホストかもしれない、あるいは他の有り得る区切りのものかもしれない。
アドレス 255.255.255.255 は、転送されてはならないローカルハードウェアネットワーク上のブロードキャストを示す。このアドレスは、例えばネットワーク番号を知らないホストが、あるサーバに尋ねる時に使用される。
従ってネットワーク番号 36 上のホストは、例えば、
これらは、ネットがサブネット化されているか否か知らずに行われる。もしサブネット化されていなければ、両方のアドレスによる効果は同じである。頑強なアプリケーションは前者のアドレスを試みて、もし何の応答も受信しなければ後者を試みる。"拡張リング検索" 技術の議論については [1] を参照されたい。
もし、IP アドレスのフィールドで "全て 1" の使用が "ブロードキャスト" を示すならば、"全て 0" の使用は "不特定" として見ることができる。ICMP 情報要求データグラムの送信元アドレス以外では、このアドレスが使用される理由は恐らくないだろう。しかし表記上の慣習として、ネットワークを参照する際に (ホストとは逆に) 0 のフィールドを使用している。例えば、36.0.0.0 は "ネットワーク番号 36" を意味し、36.255.255.255 は "ネットワーク番号 36 上の全てのホスト" を意味する。
[11] で規定されているアドレス解決プロトコル (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, November 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, BBN, 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]. David A. Moon. Chaosnet. A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, June 1981.
[10].William W. Plummer. Internet Broadcast Protocols. IEN-10, BBN, March 1977.
[11].David Plummer. An Ethernet Address Resolution Protocol. RFC-826, Symbolics, September 1982.
[12].Jon Postel. Internet Protocol. RFC-791, ISI, September 1981.
[13].David W. Wall. Mechanisms for Broadcast and Selective Broadcast. Ph.D. Th., Stanford University, June 1980.
[14].David W. Wall and Susan S. Owicki. Center-based Broadcasting. Computer Systems Lab Technical Report TR189, Stanford University, June 1980.