RFC919 日本語訳

0919 Broadcasting Internet Datagrams. J.C. Mogul. October 1984. (Format: TXT=16382 bytes) (Also STD0005) (Status: STANDARD)

RFC一覧
英語原文

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.

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

lastChild

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る