RFC922 日本語訳
0922 Broadcasting Internet datagrams in the presence of subnets. J.C.Mogul. October 1984. (Format: TXT=24147 bytes) (Also STD0005) (Status: STANDARD)
RFC一覧
英語原文
Network Working Group Jeffrey Mogul
Request for Comments: 922 Computer Science Department
Stanford University
October 1984
BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF SUBNETS
Status of this Memo
ブロードキャストをサポートするローカルネットワーク上で、インターネ
ットデータグラムをブロードキャストしたり、ブロードキャストをアドレ
ス付けたり、ゲートウェイがそれらをどのように扱うべきかについての簡
単な規則を提案する。
この RFC は、ARPA インターネット社会の提案プロトコルを提案し、改善
のための議論と提案を求めている。このメモの配布は、制限されない。
Acknowledgement
この提案は、他の複数の人々との議論の結果である。特に J. Noel
Chiappa と Christopher A. Kent は、重要な参照を指し示してくれた。
1. 導入
特に高速なローカルエリアネットワーク上でのブロードキャストの使用は、
多くのアプリケーションにとって優れた基盤である。ブロードキャストは、
基本的な IP 規約 [12] ではカバーされていないので、それを行うための
合意された方法が存在しない。よって、プロトコル設計者はまだそれを使
用していない。(この問題は以前、[6] 等で触れられたが、標準の主題には
ならなかった)。
ここでは、信頼性が無く、順序どおりでなく、重複が起こり得るデータグ
ラムブロードキャストのケースのみを考慮する (TCP のブロードキャスト
の議論については [10] を参照されたい)。信頼性が無く、長さに制限があ
るが、データグラムブロードキャストは極めて有効である [1]。
ローカルネットワークのデータリンク層は、効率的なブロードキャストを
サポートしていると仮定する。大半の一般的なローカルエリアネットワー
クは、実際にブロードキャストをサポートしている。例えば、イーサネッ
ト [7], [5]、カオスネット [9]、トークンリングネットワーク [2] 等が
そうである。
しかし、ブロードキャストは確実に配送されるとは仮定しない。(ある人は、
IP の上の層に信頼できるデータグラムブロードキャストプロトコルの提供
を検討しているかもしれない)。ブロードキャストの配送を保証することは、
極めてコストがかかる。代わりに、ホストは送信されたブロードキャスト
の大半を受信するだろうと仮定する。これはブロードキャストの過度の使
用を避けるために重要である。というのは、ネットワーク上の全てのホス
トは、少なくとも全てのブロードキャストの何らかの影響を受け、それら
はコストのかかる事だからである。
データグラムがブロードキャストされる時、それを受信した全てのホスト
にコストを押し付ける。従って、ブロードキャストはむやみに使用すべき
でなく、問題を解決する最善の方法である時にのみ使用すべきである。
2. 用語
ブロードキャストは、ローカルネットワーク上で使用する特定のデータリ
ンクに依存するので、物理ネットワークと論理ネットワークの両方に関し
て論じなければならない。
物理ネットワークを参照する際に使用する用語は、ブロードキャストを送
信、又は転送するホストの観点から:
ローカルハードウェアネットワーク (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 ネットワーク上のホストの観点
から、それは問題ないはずである。
3. なぜブロードキャストか?
ブロードキャストは、他のホストが何を供給できるか正確に知らずに情報
を見つける必要がある時や、ホストがホストの大きな集合体に適宜情報を
提供したい時に有効である。
ホストが一つ以上の隣接者が持つ情報を必要とする時、尋ねるための隣接
者のリストを持つことが出来たり、誰かが応答するまで有り得る全ての隣
接者に投げることが出来る。組み込みリストを使用すると、明らかにネッ
トワーク管理の問題を引き起こす (早めの結合は融通性が無い)。一方、隣
接者全てに尋ねる場合、もしもっともらしいホストアドレスを生成し、誰
かが動作するまでそれを試みなければならないならば、遅くなるだろう。
ARPANET では例えば、大体 65000 個のもっともらしいホスト番号が存在す
る。大半の IP 実装は、組み込みリストを使用していた (例えば "主要な"
ゲートウェイのアドレス等)。幸運にも、ブロードキャストはホストが全て
の隣接者に到達する高速で簡単な方法を提供する。
ホストは、ある情報を全ての隣接者に提供することにもブロードキャスト
を使用してもよい。例えば、ゲートウェイは他のゲートウェイに自分の存
在をアナウンスしてもよい。
ブロードキャストを考察する一つの方法は、マルチキャストの不完全な代
用として、ネットワーク上のホストのサブセットへのメッセージを送信す
ることである。実際、ブロードキャストは、マルチキャストが望まれる場
合に通常使用される。データグラムはハードウェアレベルでブロードキャ
ストされるが、受信側ホストのフィルタリングソフトウェアは、マルチキャ
ストの効果を提供する。
より詳細なブロードキャストアプリケーションの例は、[1],[3] を参照さ
れたい。
4. ブロードキャストクラス
IP ブロードキャストには幾つかのクラスが存在する。
- ローカルハードウェアネット上の単一宛先のデータグラムブロードキャ
スト: データグラムは特定の IP ホストに向けられるが、送信側ホス
トは恐らくルーティングさせることを避けるために、データリンク層
でブロードキャストする。これは IP ブロードキャストではないので、
ホストは自分に向けられていないデータグラムを慌てず (例えばエラ
ーメッセージを出力するなどせず) に破棄すべきであることを除き、
IP 層は関係ない。
- ローカルハードウェアネット上の全てのホストへのブロードキャスト:
IP アドレスのホスト番号部分で区別される値が、特定のホストの代
わりにブロードキャストを示す。受信側の IP 層は、自分自身のアド
レスだけでなくこのアドレスも認識できなければならない。しかし、
特にゲートウェイにおいて、ブロードキャストと非ブロードキャスト
を上位レベルで区別することも有効である。これは最も有効なブロー
ドキャストのケースであり、これによってホストはゲートウェイを組
み込みテーブル無しで発見することが出来る。それは、アドレス解決
プロトコルの基礎を成しており、ネームサーバやタイムサーバなどの
ユーティリティに、組み込みアドレスを必要とせずにアクセスするこ
とも有効である。
- リモートハードウェアネットワーク上にある全てのホストへのブロー
ドキャスト: 非ローカルネットワーク上の全てのホストにプロトコル
を送信することは、時折有効である。例えば、ホスト名データベース
の最新の版を見つけたり、ブートサーバ無しでサブネット上のホスト
をブートロードしたり、サブネット上のタイムサーバを監視するなど
がある。このケースは、ローカルネットワークのブロードキャストと
同じであり、データグラムは宛先のハードウェアネットワークに接続
されているゲートウェイに到達するまで、通常のメカニズムによって
配送され、そのゲートウェイでブロードキャストされる。このブロー
ドキャストのクラスは、"直接ブロードキャスト" あるいは昔風に
"手紙爆弾" [1] としても知られている。
- サブネット化された IP ネットワーク上の全てのホストへのブロード
キャスト (複数サブネットブロードキャスト): IP アドレスのサブネ
ット番号部で区別される値は、"全てのサブネット" を示すために使
用される。リモートのサブネット化された IP ネットワークの全ての
ホストにブロードキャストするには、単に一つのサブネットに直接ブ
ロードキャストする。
- インターネット全体へのブロードキャスト: これは恐らく有効ではな
く、ほぼ確実に望ましくない。
パフォーマンスやセキュリティの理由により、ゲートウェイはブロードキャ
ストを転送しないことを選択してもよい。特に、ネットワークの自律グル
ープへの、あるいは自律グループからのブロードキャストを禁ずることは
良い考えかもしれない。
5. ブロードキャスト方法
ホストの IP 受信層は、ブロードキャストをサポートするよう修正しなけ
ればならない。ブロードキャストがない時は、ホストは、宛先アドレスを
自分の IP アドレスの全てと照合することによって、データを受信するか
否か決定する。ブロードキャストを適用する場合、ホストは自分のアドレ
スだけでなく、そのホストにとって有り得るブロードキャストアドレスと
も照合しなければならない。
ブロードキャストを送信する最善の方法についての問題は、[1], [3], [4],
[13], [14] で詳細に論じられている。その問題はデータリンク層で既に解
決されていると仮定しているので、ローカルのブロードキャストか直接の
ブロードキャストを送信したい IP のホストは、適切な宛先アドレスを指
定して、通常通りにデータグラムを送信するだけでよい。洗練されたアル
ゴリズムが必要なのは、ゲートウェイだけである。
サブネット化された IP ネットワーク上の全てのホストにブロードキャス
トすることの問題は、見たところある程度困難そうである。しかしこのケ
ースでも、ゲートウェイでないホストに複雑さを加える必要がない、最も
良く知られたアルゴリズムが判明している。優れたブロードキャストの方
法は、以下の追加標準に適合するだろう
- IP データグラム形式の変更はない。
- 過剰な複製の生成回数や選択されたパスのコストの点からみて妥当な
効率
- コードやデータ空間の両方におけるゲートウェイの修正の最小化
- 配送の高い見こみ
最善と思われるアルゴリズムは、逆パス転送 (RPF: Reverse Path
Forwarding) 方法 [4] である。RPF はコストや信頼性において最適ではな
いが、それは非常に優れており、実装するのは極めて容易で、ゲートウェ
イにデータ空間の追加を必要としない。
6. ゲートウェイとブロードキャスト
ブロードキャストをサポートする複雑さの大半は、ゲートウェイにある。
もしゲートウェイが、接続していないネットワーク向けの直接ブロードキャ
ストを受信したら、単に通常のメカニズムを使用して転送する。さもなく
ば、追加の動作を行わなければならない。
6.1. ローカルブロードキャスト
ゲートウェイがローカルのブロードキャストデータグラムを受信したら、
処理しなければならない幾つかのことがある。条件は曖昧ではないが、
無限ループを引き起こす可能性を考慮しなければならない。
ブロードキャストデータグラムの受信時における適切な動作は、幾つか
の事に依存する。それは、受信されたサブネット、宛先ネットワーク、
ゲートウェイのアドレスである。
- ループを避ける基本的な規則は、"受信したハードウェアネットワ
ーク上にはデータグラムをブロードキャストしない" ことである。
ゲートウェイが自分自身から受信したデータグラムのリピートを
単純に避けるだけでは十分でない。ハードウェアネットワーク上
に複数のゲートウェイが存在する場合は、依然としてループが起
こり得る。
- もしデータグラムをそのアドレスがあるハードウェアネットワー
ク上で受信したら、それを転送してはならない。しかし、ゲート
ウェイは自分がデータグラムの宛先であると見なさなければなら
ない (例えば、それはルーティングテーブルの更新かもしれない)。
- さもなくば、もしデータグラムがゲートウェイに接続されている
ハードウェアネットワークのアドレスならば、そのネットワーク
上に (データリンク層の) ブロードキャストとして送信しなけれ
ばならない。また、ゲートウェイは自分がデータグラムの宛先で
あると見なさなければならない。
- さもなくば、ゲートウェイは次のゲートウェイを選択する通常の
ルーティング手続きを使用し、それに従ってデータグラムを送信
しなければならない。
6.2. 複数サブネットブロードキャスト
ゲートウェイが IP ネットワークの全てのサブネットに向けられたブロ
ードキャストを受信したとき、何をすべきかを決めるのに逆パス転送ア
ルゴリズムを使用しなければならない。その方法は簡単である。もしデ
ータグラムが、ゲートウェイとデータグラムの送信元との間の最善の経
路の一部であるリンク上に到着したら、ゲートウェイは接続されている
全てのリンクへデータグラムの複製を転送する。さもなくば、データグ
ラムを破棄しなければならない。
もし幾つかの、あるいは全てのゲートウェイがそれらの間で追加情報を
交換するならば、このアルゴリズムを改善してもよい。これは、他のホ
ストや他のゲートウェイの観点から透過的に行うことが出来る。詳細は
[4] [3] を参照されたい。
6.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
図 1: ゲートウェイによるルーティングブロードキャストのための擬似アルゴ
ルアルゴリズム
7. ブロードキャスト IP アドレッシング - Conventions
もし異なる IP 実装が互換性を持とうするならば、"全てのホスト" と "全
てのサブネット" を示すための識別番号の取り決めが存在しなければなら
ない。
自側のネットワーク層は、常に IP アドレスをデータリンク層のアドレス
にマッピングすることが出来るので、"ホスト番号をブロードキャストする"
IP の選択は、若干曖昧である。単純化するために、実ホストに割り当てら
れないような番号が一つ存在すべきである。全てのビットが 1 である番号
は、この特性を持つ。この割り当ては最初に [6] で提案された。ホスト番
号部がすべて 1 のアドレスを割り当てられたホストは希なケースであり、
再番号付けを必要とすることは面倒ではなさそうである。
"全てのサブネット" 番号もまた、全て 1 である。これは、リモートの IP
ネットワーク上の全てのホストにブロードキャストすることを望んでいる
ホストが、宛先アドレスがどのようにサブネットとホストフィールドに区
切られているか、あるいは分けられているか否かさえ知る必要が無いこと
を意味する。例えば、36.255.255.255 は、単一のハードウェアネットワー
ク上の全てのホストを示すかもしれないし、1 バイトのサブネットフィー
ルドと 2 バイトのホストフィールドを持つサブネット化されて IP ネット
ワーク上の全てのホストかもしれない、あるいは他の有り得る区切りのも
のかもしれない。
アドレス 255.255.255.255 は、転送されてはならないローカルハードウェ
アネットワーク上のブロードキャストを示す。このアドレスは、例えばネッ
トワーク番号を知らないホストが、あるサーバに尋ねる時に使用される。
従ってネットワーク番号 36 上のホストは、例えば、
- 255.255.255.255 を使用して、直近の隣接者の全てにブロードキャス
トする。
- 36.255.255.255 を使用して、ネットワーク 36 の全てにブロードキャ
ストする。
これらは、ネットがサブネット化されているか否か知らずに行われる。も
しサブネット化されていなければ、両方のアドレスによる効果は同じであ
る。頑強なアプリケーションは前者のアドレスを試みて、もし何の応答も
受信しなければ後者を試みる。"拡張リング検索" 技術の議論については
[1] を参照されたい。
もし、IP アドレスのフィールドで "全て 1" の使用が "ブロードキャスト
" を示すならば、"全て 0" の使用は "不特定" として見ることができる。
ICMP 情報要求データグラムの送信元アドレス以外では、このアドレスが使
用される理由は恐らくないだろう。しかし表記上の慣習として、ネットワ
ークを参照する際に (ホストとは逆に) 0 のフィールドを使用している。
例えば、36.0.0.0 は "ネットワーク番号 36" を意味し、36.255.255.255
は "ネットワーク番号 36 上の全てのホスト" を意味する。
7.1 ARPサーバとブロードキャスト
[11] で規定されているアドレス解決プロトコル (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,
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.
一覧
スポンサーリンク
