Network Working Group J. Mogul (Stanford) Request for Comments: 950 J. Postel (ISI) August 1985 Internet Standard Subnetting Procedure Status Of This Memo This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed. Distribution of this memo is unlimited. このメモについて このRFCはARPA-Internetコミュニティに対して定義するプロトコルです。 もし、subnet化されているのであれば、これらの手順に従う事を強く推奨 します。このメモの配布に関しては制限を行いません。 Overview This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940 [7]. 要約 このメモは、１つのインターネットの論理的に明確なサブ・セクション としてのインターネットの"subnet"ユーティリティを議論します。技術的 もしくは運用面において、多くの組織はインターネット番号のセットを得 る代わりに、１つのインターネットをいくつかのsubnetに分割する事を選 びます。このメモは、subnetの使い方に関する手順を定義します。これら の手順はホスト(ワークステーション等)に対するものです。この手順を内 部とsubnet間のゲートウエイで利用については十分に記述しません。一般 的なsubnetに関する重要な動機や背景の情報は、RFC-940 [7]にて提供され ています。 Acknowledgment This memo is based on RFC-917 [1]. Many people contributed to the development of the concepts described here. J. Noel Chiappa, Chris Kent, and Tim Mann, in particular, provided important suggestions. Additional contributions in shaping this memo were made by Zaw-Sing Su, Mike Karels, and the Gateway Algorithms and Data Structures Task Force (GADS). 確認事項 このメモは、RFC-917 [1]を基本に書かれてます。この概念の記述の進展 に多くの人々が貢献しました。特に、J.Noel Chiappa、Chris Kentそして Tim Mannは、重要な提案をして頂きました。このメモの編集はZaw-Sing Su、 Mike Karels、および、Gateway AlgorithmsとData Structures Task Force (GADS)によって行われました。 Mogul & Postel [Page 1] RFC 950 August 1985 Internet Standard Subnetting Procedure 1. Motivation 1. 動機 The original view of the Internet universe was a two-level hierarchy: the top level the Internet as a whole, and the level below it individual networks, each with its own network number. The Internet does not have a hierarchical topology, rather the interpretation of addresses is hierarchical. In this two-level model, each host sees its network as a single entity; that is, the network may be treated as a "black box" to which a set of hosts is connected. インターネットの世界の独自の視点では、２つのレベルの階層がありま す。トップレベルは全体的としてのインターネットであり、そして下位の レベルはそれぞれにネットワーク番号を持っている個々のネットワークで す。インターネットは階層的な構造を持たない、むしろ、アドレスの解釈 が階層的です。２つのレベルのモデルでは、互いのホストはそのネットワ ークの一つの実体として見えます。これは、おそらく、「ブラックボック ス」として扱われるネットワークにホストのセットが接続されているから です。 While this view has proved simple and powerful, a number of organizations have found it inadequate, and have added a third level to the interpretation of Internet addresses. In this view, a given Internet network is divided into a collection of subnets. この視点を簡潔かつ強力に証明する間、いくつかの団体は不適切なもの をつくり出し、そして、インターネットアドレスの解釈に３つ目のレベル を追加しました。この視点では、与えられたインターネットはsubnetの集 合に分割されます。 The three-level model is useful in networks belonging to moderately large organizations (e.g., Universities or companies with more than one building), where it is often necessary to use more than one LAN cable to cover a "local area". Each LAN may then be treated as a subnet. ３つのレベルのモデルは、１つ以上のLANケーブルで「Local Area」をカ バーして利用することがたびたび必要とする中規模団体が保有するネット ワークでは有用です。(例えば、１つ以上の建物の会社や大学等) 互いのLAN は、おそらくsubnetとして扱うでしょう。 There are several reasons why an organization might use more than one cable to cover a campus: ある団体が１つ以上のケーブルで敷地内をカバーして利用するような、い くつかの理由を下記に記述します。 - Different technologies: Especially in a research environment, there may be more than one kind of LAN in use; e.g., an organization may have some equipment that supports Ethernet, and some that supports a ring network. - 異なる技術： 主に、研究所の様な環境では、おそらく１種類以上 のLANを利用します。例えば、ある団体はおそらくイーサネットをサポ ートするいくつかの機器とリングネットワークをサポートするいくつ かの機器を所有します。 - Limits of technologies: Most LAN technologies impose limits, based on electrical parameters, on the number of hosts connected, and on the total length of the cable. It is easy to exceed these limits, especially those on cable length. - 技術の限界： 多くのLAN技術は、電気的パラメータや、接続されて いるホスト数、そして、ケーブルの全長を元に限界値を課しています。 主に、ケーブルの長さについては、その限界を越えることは容易です。 - Network congestion: It is possible for a small subset of the hosts on a LAN to monopolize most of the bandwidth. A common solution to this problem is to divide the hosts into cliques of high mutual communication, and put these cliques on separate cables. - ネットワークの輻輳： LAN上のホストが回線容量のほとんどを占 有するような小さなsubnetにでは我慢できる。この様な問題の共通の 解決策は、高い相互関係にある固まりにあるホストを分割し、また、 それらの固まり別にケーブルを施設する事です。 - Point-to-Point links: Sometimes a "local area", such as a university campus, is split into two locations too far apart to connect using the preferred LAN technology. In this case, high-speed point-to-point links might connect several LANs. - ポイント-ポイント間接続： 大学の敷地の様な「ローカルエリア」 では時々、優先的なLAN技術を利用して離れた２地点間を接続し分割 する。この様な場合はおそらく、高速なポイント-ポイント間接続で それらのLAN間を接続します。 An organization that has been forced to use more than one LAN has three choices for assigning Internet addresses: １つ以上のLANを利用しているような団体は、インターネットアドレスを 割り当てるための３つの選択があります。 Mogul & Postel [Page 2] RFC 950 August 1985 Internet Standard Subnetting Procedure 1. Acquire a distinct Internet network number for each cable; subnets are not used at all. 1. それぞれのケーブルに対して異なるインターネット番号を与え、 subnetは全く利用しない。 2. Use a single network number for the entire organization, but assign host numbers without regard to which LAN a host is on ("transparent subnets"). 2. 団体全体に対して１つのネットワーク番号を利用する、しかし、ど のLANのホストかにはかかわらず割り当てられたホスト番号は、利用 可能である("透過的Subtet化")。 3. Use a single network number, and partition the host address space by assigning subnet numbers to the LANs ("explicit subnets"). 3. １つのネットワーク番号を利用し、そして、LANを割り当てられた subnet番号によってホストアドレス空間を分割します("明白なsubnet 化")。 Each of these approaches has disadvantages. The first, although not requiring any new or modified protocols, results in an explosion in the size of Internet routing tables. Information about the internal details of local connectivity is propagated everywhere, although it is of little or no use outside the local organization. Especially as some current gateway implementations do not have much space for routing tables, it would be good to avoid this problem. それぞれのアプローチは不利な面を持っています。第一に、要求されない いくつかの新規もしくは変更されたプロトコルにもかかわらず、インターネ ットのルーティングテーブルのサイズは爆発している状態です。ローカルな 接続での内部の詳細に関する情報は、ローカルな団体の外部で、少し、また は、全く利用していないにもかかわらず、どこにで広告されている。特に、 最近のいくつかのゲートウエイのインプリメンテーションでは、ルーティン グテーブルに対する十分なスペースを持たない、それは、この問題を回避す るためには良い事でしょう。 The second approach requires some convention or protocol that makes the collection of LANs appear to be a single Internet network. For example, this can be done on LANs where each Internet address is translated to a hardware address using an Address Resolution Protocol (ARP), by having the bridges between the LANs intercept ARP requests for non-local targets, see RFC-925 [2]. However, it is not possible to do this for all LAN technologies, especially those where ARP protocols are not currently used, or if the LAN does not support broadcasts. A more fundamental problem is that bridges must discover which LAN a host is on, perhaps by using a broadcast algorithm. As the number of LANs grows, the cost of broadcasting grows as well; also, the size of translation caches required in the bridges grows with the total number of hosts in the network. 第二に、複数のLANを一つのインターネットワークに見せかける、手段や規 定が必要です。例えば、複数のLANの間に存在するブリッジに自分以外のLANに 対するアドレス変換プロトコル(ARP)要求を参照させることにより、ARPを利用 してインターネットアドレスをハードウエアアドレスに変換しているLANにお いては、このようなことが可能です。(RFC925を参照してください。)しかし、 全てのLAN技術についてこのようなことが可能ではなく、特に、ARPプロトコル が利用していなかったり、LANがブロードキャストをサポートしていなかった りする。もっと重要な問題は、ブリッジがおそらくブロードキャストアルゴリ ズムを利用してLAN上のホストを見つけ出さなくてはならないと言う事です。 LANの増加にともない、ブロードキャストのコストもまた増加します。なお、 ブリッジで必要とする変換キャッシュのサイズはネットワーク上のホスト数 と共に増加します。 The third approach is to explicitly support subnets. This does have a disadvantage, in that it is a modification of the Internet Protocol, and thus requires changes to IP implementations already in use (if these implementations are to be used on a subnetted network). However, these changes are relatively minor, and once made, yield a simple and efficient solution to the problem. Also, the approach avoids any changes that would be incompatible with existing hosts on non-subnetted networks. 第三のアプローチは明白にsubnetをサポートする事です。これは、インタ ーネットプロトコルを修正すると言う事において、不利な面を持っており、 そして、このような要求は既に利用されているIPのインプリメンテーション を変更します。(もし、これらのインプリメンテーションがsubnet化されてい るネットワークで利用されているのであればですが。)しかし、これらの変更 は比較的重要ではなく、また、かつて作られており、簡単に生産でき、そし て問題解決に効果があります。なお、このアプローチは、いくつかの変更に よりsubnet化されていないネットワーク上に存在するホストに矛盾すること を回避します。 Further, when appropriate design choices are made, it is possible for hosts which believe they are on a non-subnetted network to be used on a subnetted one, as explained in RFC-917 [1]. This is useful when it is not possible to modify some of the hosts to support subnets explicitly, or when a gradual transition is preferred. さらに、適当な仕様の選択がされた時、将来的にsubnet化されていないネッ トワークにおいて、subnet化されたネットワークが利用される様なホストに対 して可能です。 Mogul & Postel [Page 3] RFC 950 August 1985 Internet Standard Subnetting Procedure 2. Standards for Subnet Addressing 2. Subnetアドレス割り当ての標準 This section first describes a proposal for interpretation of Internet addresses to support subnets. Next it discusses changes to host software to support subnets. Finally, it presents a procedures for discovering what address interpretation is in use on a given network (i.e., what address mask is in use). この章の最初にはsubnetをサポートするインターネットアドレスの解釈に 対する提案を記述します。次に、subnetをサポートするホストのソフトウエ アへの変更について議論し、最後に、アドレス解釈が与えられたネットワー ク上での利用において発見するための手順を提供します。 2.1. Interpretation of Internet Addresses 2.1. インターネットアドレスの解釈 Suppose that an organization has been assigned an Internet network number, has further divided that network into a set of subnets, and wants to assign host addresses: how should this be done? Since there are minimal restrictions on the assignment of the "local address" part of the Internet address, several approaches have been proposed for representing the subnet number: ある団体がインターネット番号を割り当てられており、将来的にいくつ かのsubnetに分割し、ホストアドレスを割り当てたいと仮定します。この ような時はどうしますか？インターネットアドレスの一部である「ローカ ルアドレス」の割当を最小限に制限して以来、いくつかのアプローチは、 subnet番号を制限する事を提案しています。 1. Variable-width field: Any number of the bits of the local address part are used for the subnet number; the size of this field, although constant for a given network, varies from network to network. If the field width is zero, then subnets are not in use. 1. 可変長フィールド: ローカルアドレス部分のいくつかのビットは、 subnet番号として利用されます。このフィールドのサイズは、与え られるネットワークに対して一定ですが、ネットワーク間では可変 です。もし、フィールド長が０の場合、そのsubnetは利用されてい ません。 2. Fixed-width field: A specific number of bits (e.g., eight) is used for the subnet number, if subnets are in use. 2. 固定長フィールド: もし、subnetが利用されているのであれば、 特定のビット数(例えば８ビット)はsubnet番号として利用されま す。 3. Self-encoding variable-width field: Just as the width (i.e., class) of the network number field is encoded by its high-order bits, the width of the subnet field is similarly encoded. 3. 自己暗号化可変長フィールド: ネットワーク番号フィールドの長 さがちょうど良い(例えばClassとか)ときは、high-orderビットに よってエンコードされ、subnet長は同様なエンコードをします。 4. Self-encoding fixed-width field: A specific number of bits is used for the subnet number. 4. 自己暗号化固定長フィールド: 特定のビット数はsubnet番号とし て利用されます。 5. Masked bits: Use a bit mask ("address mask") to identify which bits of the local address field indicate the subnet number. 5. マスクビット: subnet番号を表すローカルアドレスフィールドの ビットと一致するビットマスク(「アドレスマスク」)を利用します。 What criteria can be used to choose one of these five schemes? First, should we use a self-encoding scheme? And, should it be possible to tell from examining an Internet address if it refers to a subnetted network, without reference to any other information? これら５つの案の内の１つを選択して利用する基準は何でしょうか？ 第一に、私達は自己暗号化の案を利用すべきでしょうか？そして、もし、 他のどの情報をも参照する事無く、subnet化されたネットワークを参照 させるのであれば、調査したインターネットアドレスから聞く事は可能 でしょうか？ An interesting feature of self-encoding is that it allows the Mogul & Postel [Page 4] RFC 950 August 1985 Internet Standard Subnetting Procedure address space of a network to be divided into subnets of different sizes, typically one subnet of half the address space and a set of small subnets. 自己暗号化の将来への興味は、アドレススペース半分の内の１つの subnetと小さなsubnetのセットの様な異なるサイズのsubnetに分割さ れたネットワークのアドレススペースを認める事です。 For example, consider a class C network that uses a self-encoding scheme with one bit to indicate if it is the large subnet or not and an additional three bits to identify the small subnet. If the first bit is zero then this is the large subnet, if the first bit is one then the following bits (3 in this example) give the subnet number. There is one subnet with 128 host addresses, and eight subnets with 16 hosts each. 例えば、Cクラスのネットワークを考えた場合、もし、そのネッ トワークが大きいsubnet、または、そうでないものと、小さいsubnet と一致する追加した３ビットなら、１ビットで表現する自己暗号化 の案を利用します。もし、最初のビットが０の場合は、大きいsubnet であり、また、最初のビットが１の場合は、フォローイングビット (この例では３)がsubnet番号に与えられます。 To establish a subnetting standard the parameters and interpretation of the self-encoding scheme must be fixed and consistent throughout the Internet. subnet化の標準のパラメータを定め、また、自己暗号化案の解釈を 決め、インターネットを通して一致させなくてはなりません。 It could be assumed that all networks are subnetted. This would allow addresses to be interpreted without reference to any other information. それは全てのネットワークがsubnet化されるように見られた。これは 他のどの情報も参照すること無く解釈されるアドレスを許すでしょう。 This is a significant advantage, that given the Internet address no additional information is needed for an implementation to determine if two addresses are on the same subnet. However, this can also be viewed as a disadvantage: it may cause problems for networks which have existing host numbers that use arbitrary bits in the local address part. In other words, it is useful to be able to control whether a network is subnetted independently from the assignment of host addresses. もし、２つのアドレスが同一subnet上にあるならば、与えられる 追加情報の無いインターネットアドレスはインプリメンテーション を限定する為に必要される重要な利得です。しかし、これもまた不 利なように見る事ができます。それは、ローカルアドレス部分にお いて任意のビットを利用するホスト番号が存在しているネットワー クに対して問題が起きるでしょう。他の言い方すれば、ネットワー クがホストアドレスの割当から独立してsubnet化されているかどう か、制御可能かどうかが有益です。 The alternative is to have the fact that a network is subnetted kept separate from the address. If one finds, somehow, that the network is subnetted then the standard self-encoded subnetted network address rules are followed, otherwise the non-subnetted network addressing rules are followed. どちらか一方は、ネットワークがアドレスからの分割を保持された subnet化を真実として持つことです。もし、ともかくネットワークが subnet化されているのが見付かれば、subnet化されていないネットワー クアドレス採番のルールがフォローされるものとは、別な方法で、標準 の自己暗号化のsubnet化ネットワークアドレスのルールはフォローされ ます。 If a self-encoding scheme is not used, there is no reason to use a fixed-width field scheme: since there must in any case be some per-network "flag" to indicate if subnets are in use, the additional cost of using an integer (a subnet field width or address mask) instead of a boolean is negligible. The advantage of using the address mask scheme is that it allows each organization to choose the best way to allocate relatively scarce bits of local address to subnet and host numbers. Therefore, we choose the address-mask scheme: it is the most flexible scheme, yet costs no more to implement than any other. もし、自己暗号化の案が利用されなければ、固定長フィールドの案を利 用する理由がりません。その点ではいくつかのプレネットワークの「フラ グ」に対して指摘がどんな場面においても必要になって以来、もし、subnet が利用していれば、論理型の代わりに整数型(subnetフィールド幅、もしく は、アドレスマスク)を利用するコストを追加することは取るに足らないこ とです。アドレスマスク案を利用する優位性は、それぞれの団体が、subnet とホスト番号へローカルアドレスのビットが比較的不足して配置する最良 方法を選択することを許すことです。その結果、我々はアドレスマスクの 案を選択します。それは、柔軟性に富んだ案であり、それにもかかわらず、 他の方法よりもインプリメントするためのコストがかかりません。 Mogul & Postel [Page 5] RFC 950 August 1985 Internet Standard Subnetting Procedure For example, the Internet address might be interpreted as: where the field is as defined by IP [3], the field is at least 1-bit wide, and the width of the field is constant for a given network. No further structure is required for the or fields. If the width of the field is zero, then the network is not subnetted (i.e., the interpretation of [3] is used). 例えば、インターネットアドレスは次の様に解釈されるでしょう。 フィールドはIPによって定義され、フ ィールドは、少なくとも１ビット幅です、そして、の幅 は、与えられるネットワークに対して不変です。それ以上の やフィールドに対して要求される構造は必要ありません。 もし、フィールドの幅が０ならば、ネットワークはsubnet 化されていません。(資料[3]の解釈を利用しています。) For example, on a Class B network with a 6-bit wide subnet field, an address would be broken down like this: 例えば、６ビット幅のsubnetフィールドを持つClass Bのネットワーク 上でのアドレスは下記の様に分解去れます。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| NETWORK | SUBNET | Host Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Since the bits that identify the subnet are specified by a bitmask, they need not be adjacent in the address. However, we recommend that the subnet bits be contiguous and located as the most significant bits of the local address. subnetを一致するためのビットがビットマスクによって指定されるよう になって以来、アドレスを連続させる必要性は無くなりました。しかし、 我々はsubnetビットが連続し、ローカルアドレスのビット最も重要視され るように配置されることを推奨します。 Special Addresses: 特別アドレス： From the Assigned Numbers memo [9]: [9]番に割り当てられたメモより： "In certain contexts, it is useful to have fixed addresses with functional significance rather than as identifiers of specific hosts. When such usage is called for, the address zero is to be interpreted as meaning "this", as in "this network". The address of all ones are to be interpreted as meaning "all", as in "all hosts". For example, the address 128.9.255.255 could be interpreted as meaning all hosts on the network 128.9. Or, the address 0.0.0.37 could be interpreted as meaning host 37 on this network." 「確かな状況では、指定するホストを同一視するよりもむしろ、 機能の重要を伴う固定化されたアドレスを持つことは利用しやす い。その様な利用方法が要求されるとき、０のアドレスは「この ネットワーク」を意味するように解釈されます。例えば、128.9. 255.255のアドレスは、128.9のネットワーク上の全てのホストを 意味するように解釈されることができます。または、0.0.0.37の アドレスは、ネットワーク上のホスト37を意味するように解釈で きます。」 It is useful to preserve and extend the interpretation of these special addresses in subnetted networks. This means the values of all zeros and all ones in the subnet field should not be assigned to actual (physical) subnets. subnet化されたネットワーク上でのこのような特別なアドレスの解 釈を広げ、維持することが有用です。これは、現実的に(物理的に) subnetに割り当てられていないような、subnetフィールドの全てが０、 および、全てが１であるという値を意味します。 In the example above, the 6-bit wide subnet field may have any value except 0 and 63. さらに例を言えば、６ビット幅のsubnetフィールドは、０と６３ を除く全ての値を持つでしょう。 Mogul & Postel [Page 6] RFC 950 August 1985 Internet Standard Subnetting Procedure Please note that there is no effect or new restriction on the addresses of hosts on non-subnetted networks. これらは、subnet化されていないネットワーク上のホストのアドレ スへの新しい決めごとであり、または、影響の無いものであることに 注意してください。 2.2. Changes to Host Software to Support Subnets 2.2. Subnetをサポートするためのホストのソフトウエアの変更 In most implementations of IP, there is code in the module that handles outgoing datagrams to decide if a datagram can be sent directly to the destination on the local network or if it must be sent to a gateway. IPの大体のインプリメンテーションでは、データグラムがローカルネッ トワーク上の目標に直接送信できるか、または、ゲートウエイに必ず送信 できるかを決めることによりデータグラムを発信する処理を行うモジュー ルにコード化されています。 Generally the code is something like this: 一般的にコードは以下の様になっています。 IF ip_net_number(dg.ip_dest) = ip_net_number(my_ip_addr) THEN send_dg_locally(dg, dg.ip_dest) ELSE send_dg_locally(dg, gateway_to(ip_net_number(dg.ip_dest))) (If the code supports multiply-connected networks, it will be more complicated, but this is irrelevant to the current discussion.) (もし、コードが複数接続をサポートしているなら、もっと複雑なはず です、しかし、これは、現在の議論では不適切です。) To support subnets, it is necessary to store one more 32-bit quantity, called my_ip_mask. This is a bit-mask with bits set in the fields corresponding to the IP network number, and additional bits set corresponding to the subnet number field. subnet化をサポートすること、それは、my_ip_maskと呼ばれる３２ビッ トの量をもう一つ蓄積することが必要です。これは、IPネットワーク番号 に相当するフィールドの中のビットセットに伴うビットマスクであり、そ して、追加のビットセットはsubnet番号フィールドに相当します。 The code then becomes: コードは以下の様になります。 IF bitwise_and(dg.ip_dest, my_ip_mask) = bitwise_and(my_ip_addr, my_ip_mask) THEN send_dg_locally(dg, dg.ip_dest) ELSE send_dg_locally(dg, gateway_to(bitwise_and(dg.ip_dest, my_ip_mask))) Of course, part of the expression in the conditional can be pre-computed. もちろん、条件部の式の部分は既に計算されています。 It may or may not be necessary to modify the "gateway_to" function, so that it too takes the subnet field bits into account when performing comparisons. subnetフィールドビットの実行性能を比較することを考慮したとしても "gateway_to"関数の修正をしてもしなくてもよいです。 To support multiply-connected hosts, the code can be changed to Mogul & Postel [Page 7] RFC 950 August 1985 Internet Standard Subnetting Procedure keep the "my_ip_addr" and "my_ip_mask" quantities on a per-interface basis; the expression in the conditional must then be evaluated for each interface. ホストの複数接続をサポートする場合、コードは、各インタフェース毎 にたくさんの"my_ip_addr"を確保できる様に変更しなくてはなりません。 それゆえに、条件部の式は、それぞれのインタフェースに対して評価され なくてはなりません。 2.3. Finding the Address Mask 2.3. アドレスマスクの検索 How can a host determine what address mask is in use on a subnet to which it is connected? The problem is analogous to several other "bootstrapping" problems for Internet hosts: how a host determines its own address, and how it locates a gateway on its local network. In all three cases, there are two basic solutions: "hardwired" information, and broadcast-based protocols. 利用中の接続されているsubnet上においてアドレスマスクをホストはど のように決定することができるのでしょうか？この問題はインターネット のホストに対する他のいくつかの「ブートストラップ」に関する問題と似 ています。たとえば、ホストはどのように自分自身のアドレスを決定する 方法、そして、ローカルネットワーク上にゲートウエイをどのように配置 するか等です。この３つ全て場合において、２つの基本的な解決方法があ ります。それは、「直接接続」情報、そして、ブロードキャストを基本と したプロトコルです。 Hardwired information is that available to a host in isolation from a network. It may be compiled-in, or (preferably) stored in a disk file. However, for the increasingly common case of a diskless workstation that is bootloaded over a LAN, neither hardwired solution is satisfactory. 直接接続の情報はネットワークから孤立した状態にあるホストに対して 有効です。それはおそらくコンパイルされ組み込まれているか、(願わく ば)ディスク上にファイルとして落し込まれているでしょう。しかし、増え ているディスクレスワークステーションの共通の場合に対しては、LAN上を 経由してブートがロードされるため、直接接続の解決方法としては満足で はありません。 Instead, since most LAN technology supports broadcasting, a better method is for the newly-booted host to broadcast a request for the necessary information. For example, for the purpose of determining its Internet address, a host may use the "Reverse Address Resolution Protocol" (RARP) [4]. 代わりに、大体のLAN技術においてブロードキャストがサポートされて以 来の良い方法は新しくブートされたホストがブロードキャストを行い必要 な情報を要求することです。例えば、インターネットアドレスを決定する ことを目的とするとき、ホストは逆アドレス解決プロトコル(RARP)[4]を利 用するでしょう。 However, since a newly-booted host usually needs to gather several facts (e.g., its IP address, the hardware address of a gateway, the IP address of a domain name server, the subnet address mask), it would be better to acquire all this information in one request if possible, rather than doing numerous broadcasts on the network. The mechanisms designed to boot diskless workstations can also load per-host specific configuration files that contain the required information (e.g., see RFC-951 [8]). It is possible, and desirable, to obtain all the facts necessary to operate a host from a boot server using only one broadcast message. しかし、新しくブートされたホストが通常いくつかの事実(例えば、IP アドレス、ゲートウエイのハードウエアアドレス、subnetのアドレスマス ク等)を収集することが必要になって以来、もし可能であれば、１回のリ クエストでこれら全ての情報を取得できたほうが良い、むしろ、ネットワ ーク上に多数のブロードキャストを行うよりは良いと言えます。ディスク レスワークステーションをブートするこのメカニズムの仕様は、必要とさ れる情報を含む特定の設定ファイルをあらかじめホストにロードしておく ことも可能です。(RFC-951[8]を御覧ください。)それは可能なことであり そして、魅力的であり、たった一つのブロードキャストメッセージを利用 することによりブートサーバからホストが動作するために必要な全ての事 実を取得することができます。 In the case where it is necessary for a host to find the address mask as a separate operation the following mechanism is provided: 別々に動作する様なアドレスマスクを見つけることがホストに対して必 要な場合でのメカニズムを下記に提供します。 To provide the address mask information the ICMP protocol [5] is extended by adding a new pair of ICMP message types, "Address Mask Request" and "Address Mask Reply", analogous to the "Information Request" and "Information Reply" ICMP messages. These are described in detail in Appendix I. アドレスマスク情報を提供するICMPプロトコル[5]は、ICMPメッセー ジの"Information Request"と"Information Reply"に似た、"Address Mask Request"と"Address Mask Reply"というICMPメッセージの新しい ペアを追加することにより拡張されます。これらは、Appendix Iに詳細 が記述去れています。 The intended use of these new ICMP messages is that a host, when booting, broadcast an "Address Mask Request" message. A Mogul & Postel [Page 8] RFC 950 August 1985 Internet Standard Subnetting Procedure gateway (or a host acting in lieu of a gateway) that receives this message responds with an "Address Mask Reply". If there is no indication in the request which host sent it (i.e., the IP Source Address is zero), the reply is broadcast as well. The requesting host will hear the response, and from it determine the address mask. これらの新しいICMPメッセージは、ホストがブートするときに利用 することが意図れれており、"Address Mask Request"メッセージをブ ロードキャストします。ゲートウエイ(または、ゲートウエイの代わり に稼働しているホスト)は、このメッセージの応答として"Address Mask Reply"を返します。もし、ホストが送ったリクエストに指示がない場 合(例えば、IPソースアドレスが０の場合等)、応答はブロードキャス トによって行われます。要求ホストはこの応答を聞くでしょう、そし て、その応答からアドレスマスクを決定します。 Since there is only one possible value that can be sent in an "Address Mask Reply" on any given LAN, there is no need for the requesting host to match the responses it hears against the request it sent; similarly, there is no problem if more than one gateway responds. We assume that hosts reboot infrequently, so the broadcast load on a network from use of this protocol should be small. これが、与えられるいかなるLAN上でも"Address Mask Reply"で送信 されることができるたった一つの可能な値なので、送信した要求に反 して聞き取る応答と適合する様な要求ホストに対しては必要ありませ ん。同様に、もし１つ以上のゲートウエイが応答した場合でも、これ は問題になりません。我々はホストがめったにリブートしないと思い ます、そのため、このプロトコルで利用するネットワーク上のブロー ドキャストの利用率は少ないでしょう。 If a host is connected to more than one LAN, it might have to find the address mask for each. もし、ホストが１つ以上のLANに接続されているならば、それぞれのLAN のアドレスマスクを見つけて取得する必要があります。 One potential problem is what a host should do if it can not find out the address mask, even after a reasonable number of tries. Three interpretations can be placed on the situation: １つの潜在的な問題は、ホストがもし適当な回数試みてもアドレスマス クを見つけ出せない場合、ホストはどのようにするかということです。下 記の３つの解釈は状況によって配置されることができます。 1. The local net exists in (permanent) isolation from all other nets. 1. ローカルなネットは他の全てのネットから(常に)孤立した中に存在 します。 2. Subnets are not in use, and no host can supply the address mask. 2. subnetは利用しません、そして、１つのホストもアドレスマスクを 提供できません。 3. All gateways on the local net are (temporarily) down. 3. ローカルネット上の全てのゲートウエイは(一時的に)ダウンしてい ます。 The first and second situations imply that the address mask is identical with the Internet network number mask. In the third situation, there is no way to determine what the proper value is; the safest choice is thus a mask identical with the Internet network number mask. Although this might later turn out to be wrong, it will not prevent transmissions that would otherwise succeed. It is possible for a host to recover from a wrong choice: when a gateway comes up, it should broadcast an "Address Mask Reply"; when a host receives such a message that disagrees with its guess, it should change its mask to conform to the received value. No host or gateway should send an "Address Mask Reply" based on a "guessed" value. １番目と２番目の状況は、アドレスマスクがインターネットワーク番号 のマスクと等しいと言うことを暗に含んでいます。３番目の状況では、適 正な値が何か決定する方法がありません。安全な選択は、インターネット 番号のマスクと等しいようなマスクです。たとえ、これが後に間違った判 断であったとしても、別な方法での成功した送信は妨げないでしょう。悪 い選択からホストを回復することは可能です。ゲートウエイが立ち上がっ た時に、"Address Mak Reply"をブロードキャストするでしょう。ホストが 同意できないと思われるそのようなメッセージを受け取った時、受け取っ た値と一致するマスクに変更するでしょう。ホストではないもの、または、 ゲートウエイは、「推測される」値を基本とした"Address Mask Reply"を 送信するでしょう。 Finally, note that no host is required to use this ICMP protocol to discover the address mask; it is perfectly reasonable for a host with non-volatile storage to use stored information (including a configuration file from a boot server). 最後に、注意すべき点はホストでないものは、アドレスマスクを発見す るために、このICMPプロトコルを利用することを要求します。それは、(ブ ートサーバからの設定ファイルを展開した記憶された情報を使うための不 揮発性の記憶装置を持つホストに対しては、大変合理的です。 Mogul & Postel [Page 9] RFC 950 August 1985 Internet Standard Subnetting Procedure Appendix I. Address Mask ICMP 追記 I. アドレスマスクICMP Address Mask Request or Address Mask Reply 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: IPフィールド： Addresses The address of the source in an address mask request message will be the destination of the address mask reply message. To form an address mask reply message, the source address of the request becomes the destination address of the reply, the source address of the reply is set to the replier's address, the type code changed to AM2, the address mask value inserted into the Address Mask field, and the checksum recomputed. However, if the source address in the request message is zero, then the destination address for the reply message should denote a broadcast. アドレスマスク要求メッセージのソースアドレスは、アドレスマ スク応答メッセージの目標となります。アドレスマスク応答メッセ ージの形は、要求のソースアドレスが応答の目標アドレスになり、 応答のソースアドレスは応答者アドレスに設定され、type codeは AM2に変更され、アドレスマスクの値は、アドレスマスクフィール ドに挿入され、そして、チェックサムが再計算されます。しかし、 もし、要求メッセージのソースアドレスが０の場合、応答に対する 目標アドレスはブロードキャストを表すでしょう。 ICMP Fields: ICMPフィールド： Type AM1 for address mask request message AM1はアドレスマスク要求メッセージを表します。 AM2 for address mask reply message AM2はアドレスマスク応答メッセージを表します。 Code 0 for address mask request message ０はアドレスマスク要求メッセージを表します。 0 for address mask reply message ０はアドレスマスク応答メッセージを表します。 Checksum The checksum is the 16-bit one's complement of the one's Mogul & Postel [Page 10] RFC 950 August 1985 Internet Standard Subnetting Procedure complement sum of the ICMP message starting with the ICMP Type. For computing the checksum, the checksum field should be zero. This checksum may be replaced in the future. チェックサムは、ICMP Typeから始まるICMPメッセージの１６ビ ットの１の補数です。チェックサムの計算については、チェックサ ムフィールドの値は０です。このチェックサムは将来的に置き換え られるでしょう。 Identifier An identifier to aid in matching requests and replies, may be zero. identifierは要求に対する応答を見つけるための助けになります。 おそらく０を設定します。 Sequence Number A sequence number to aid in matching requests and replies, may be zero. sequesnce numberは要求に対する応答を見つけ出すための助けに なります。おそらく０を設定します。 Address Mask A 32-bit mask. ３２ビットのマスクです。 Description A gateway receiving an address mask request should return it with the address mask field set to the 32-bit mask of the bits identifying the subnet and network, for the subnet on which the request was received. アドレスマスク要求を受信したゲートウエイは、アドレスマスクフィ ールドに要求を受け取ったところのsubnetにおける、subnetとネットワ ークと一致するビットの３２ビットマスクを設定します。 If the requesting host does not know its own IP address, it may leave the source field zero; the reply should then be broadcast. However, this approach should be avoided if at all possible, since it increases the superfluous broadcast load on the network. Even when the replies are broadcast, since there is only one possible address mask for a subnet, there is no need to match requests with replies. The "Identifier" and "Sequence Number" fields can be ignored. もし、要求するホストが自分自身のIPアドレスを知らない場合は、 sourceフィールドを０のままにしておきます。すると、その応答は、ブ ロードキャストされます。しかし、このアプローチは、ネットワーク上 の不必要なブロードキャストによる負荷を増加する全ての可能性から逃 れられるでしょう。応答がブロードキャストのとき、subnetに対するア ドレスマスクの可能性はたった一つであり、要求に対する応答を適合す る必要はありません。"Idetifier"と"Sequence Number"のフィールドは 無視できます。 Type AM1 may be received from a gateway or a host. タイプAM1は、ゲートウエイまたはホストから受信されるでしょう。 Type AM2 may be received from a gateway, or a host acting in lieu of a gateway. タイプAM2はゲートウエイまたは、ゲートウエイの代わりの稼働中の ホストから受信されるでしょう。 Mogul & Postel [Page 11] RFC 950 August 1985 Internet Standard Subnetting Procedure Appendix II. Examples 追記 II. 例 These examples show how a host can find out the address mask using the ICMP Address Mask Request and Address Mask Reply messages. For the following examples, assume that address 255.255.255.255 denotes "broadcast to this physical medium" [6]. これらの例は、ICMPアドレスマスク要求とICMPアドレスマスク応答を利用 して、ホストがどのようにアドレスマスクを見つけ出すことができるかを示 します。例を上げると、アドレス255.255.255.255は「この物理媒体にブロー ドキャストすること」を意味すると推測できます。(資料[6]を参照) 1. A Class A Network Case 1. クラスAのネットワークの場合 For this case, assume that the requesting host is on class A network 36.0.0.0, has address 36.40.0.123, that there is a gateway at 36.40.0.62, and that a 8-bit wide subnet field is in use, that is, the address mask is 255.255.0.0. 要求ホストがアドレス36.40.0.123をもつような、36.0.0.0のクラスAネ ットワークにあり、ゲトーウエイが36.40.0.62で、８ビット幅のsubnetフ ィールドを利用していると思われる場合に対するアドレスマスクは、 255.255.0.0です。 The most efficient method, and the one we recommend, is for a host to first discover its own address (perhaps using "RARP" [4]), and then to send the ICMP request to 255.255.255.255: もっとも効力があり、そして、一つの我々の勧める方法は、ホストに対 して最初に自分自身のアドレスを発見し(多分、"RARP"[4]を使います。)、 そして、ICMP要求を255.255.255.255に対して送信します。その内容は、 以下の通りです。 Source address: 36.40.0.123 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 The gateway can then respond directly to the requesting host. ゲートウエイは要求ホストに対して直接応答を返します。内容は以下の 通りです。 Source address: 36.40.0.62 Destination address: 36.40.0.123 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.0.0 Suppose that 36.40.0.123 is a diskless workstation, and does not know even its own host number. It could send the following datagram: 36.40.0.123がディスクレスワークステーションであり、そして、自分 自身のホスト番号を知らないと仮定します。そのときは、下記に示すデー タグラムを送ることができます。 Source address: 0.0.0.0 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 36.40.0.62 will hear the datagram, and should respond with this datagram: 36.40.0.62は、先のデータグラムを聞くでしょう。そして、次に示す このデータグラムを応答します。 Mogul & Postel [Page 12] RFC 950 August 1985 Internet Standard Subnetting Procedure Source address: 36.40.0.62 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.0.0 Note that the gateway uses the narrowest possible broadcast to reply. Even so, the over use of broadcasts presents an unnecessary load to all hosts on the subnet, and so the use of the "anonymous" (0.0.0.0) source address must be kept to a minimum. ゲートウエイは応答をブロードキャストする可能性をもっとも制限して 利用することに注意してください。たとえ、多くのブロードキャストによ りsubnet上の全てのホストの不必要な付加を与えたるような、"匿名"の (0.0.0.0)をソースアドレスとして利用することは最小限にとどめなくては なりません。 If broadcasting is not allowed, we assume that hosts have wired-in information about neighbor gateways; thus, 36.40.0.123 might send this datagram: もし、ブロードキャストを許さないのであれば、我々は、ホストが隣接 ゲートウエイに関する接続情報を持たなくてならないでしょう。従って、 36.40.0.123は下記のデータグラムを送るでしょう。 Source address: 36.40.0.123 Destination address: 36.40.0.62 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 36.40.0.62 should respond exactly as in the previous case. そして、36.40.0.62は先の様な場合でも正しい応答を返すでしょう。 Source address: 36.40.0.62 Destination address: 36.40.0.123 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.0.0 2. A Class B Network Case 2. クラスBネットワークの場合 For this case, assume that the requesting host is on class B network 128.99.0.0, has address 128.99.4.123, that there is a gateway at 128.99.4.62, and that a 6-bit wide subnet field is in use, that is, the address mask is 255.255.252.0. 要求ホストが128.99.0.0のクラスBネットワーク上にあり、そのホスト は128.99.4.123のアドレスを持ち、ゲートウエイが128.99.4.62であり、 subnetフィールドが６ビット幅を利用するような場合のアドレスマスク を255.255.252.0と仮定した場合を示します。 The host sends the ICMP request to 255.255.255.255: ホストはICMP要求を255.255.255.255に以下の情報で送付します。 Source address: 128.99.4.123 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 Mogul & Postel [Page 13] RFC 950 August 1985 Internet Standard Subnetting Procedure The gateway can then respond directly to the requesting host. ゲートウエイは要求ホストに対して直接下記の様な情報を応答するこ とができます。 Source address: 128.99.4.62 Destination address: 128.99.4.123 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.252.0 In the diskless workstation case the host sends: ホストがディスクレスワークステーションの場合は次の様になります。 Source address: 0.0.0.0 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 128.99.4.62 will hear the datagram, and should respond with this datagram: 128.99.4.62は先のデータグラムを聞くでしょう、そして、次に示す応 答を返すでしょう。 Source address: 128.99.4.62 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.252.0 If broadcasting is not allowed 128.99.4.123 sends: もし、ブロードキャストが128.99.4.123に許されていない場合は次の様 になります。 Source address: 128.99.4.123 Destination address: 128.99.4.62 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 128.99.4.62 should respond exactly as in the previous case. 128.99.4.62は先の場合には正しく応答を返すでしょう。 Source address: 128.99.4.62 Destination address: 128.99.4.123 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.252.0 Mogul & Postel [Page 14] RFC 950 August 1985 Internet Standard Subnetting Procedure 3. A Class C Network Case (illustrating non-contiguous subnet bits) 3. クラスCネットワークの場合(隣接しないsubnetのビットに関する説明) For this case, assume that the requesting host is on class C network 192.1.127.0, has address 192.1.127.19, that there is a gateway at 192.1.127.50, and that on network an 3-bit subnet field is in use (01011000), that is, the address mask is 255.255.255.88. 要求ホストが192.1.127.0のクラスCネットワーク上にあり、192.1.127.19 のアドレスを持ち、ゲートウエイが192.1.127.50であり、ネットワークで subnetのフィールド幅が(010111000)を利用した３ビットであるような場合 のアドレスマスクを255.255.255.88とします。 The host sends the ICMP request to 255.255.255.255: ホストは、ICMP要求を255.255.255.255に次の様な情報で送付します。 Source address: 192.1.127.19 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 The gateway can then respond directly to the requesting host. ゲートウエイは、要求ホストに対して次の様な情報を直接応答することが できます。 Source address: 192.1.127.50 Destination address: 192.1.127.19 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.255.88. In the diskless workstation case the host sends: ディスクレスワークステーションの場合は次の様な要求を送ります。 Source address: 0.0.0.0 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 192.1.127.50 will hear the datagram, and should respond with this datagram: 192.1.127.50はそのデータグラムを聞くでしょう、そして、次に示すデー タグラムを応答するでしょう。 Source address: 192.1.127.50 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.255.88. If broadcasting is not allowed 192.1.127.19 sends: もし、ブロードキャストすることを192.1.127.19が許さない場合は、次の 様な要求を送信します。 Mogul & Postel [Page 15] RFC 950 August 1985 Internet Standard Subnetting Procedure Source address: 192.1.127.19 Destination address: 192.1.127.50 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 192.1.127.50 should respond exactly as in the previous case. 192.1.127.50は先の様な場合には、次の様な正しい応答を返します。 Source address: 192.1.127.50 Destination address: 192.1.127.19 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.255.88 Appendix III. Glossary 追記 III. 用語解説 Bridge ブリッジ A node connected to two or more administratively indistinguishable but physically distinct subnets, that automatically forwards datagrams when necessary, but whose existence is not known to other hosts. Also called a "software repeater". あるノードは、管理上区別できないが、しかし、物理的には異なる様な subnetと１つ以上接続されており、必要な場合は自動的にデータグラムを 転送ます、しかし、そのような存在は他のホストは知りません。「ソフト ウエアリピータ」とも呼ばれます。 Gateway ゲートウエイ A node connected to two or more administratively distinct networks and/or subnets, to which hosts send datagrams to be forwarded. あるノードが管理上異なるネットワークまたは、subnetと１つ以上の接 続があるとき、そこにあるホストが送ったデータグラムはフォワードされ ます。 Host Field ホストフィールド The bit field in an Internet address used for denoting a specific host. インターネットアドレスでのビットフィールドは、ホストの定義を表す ために利用されます。 Internet インターネット The collection of connected networks using the IP protocol. IPプロトコルを利用したネットワークが接続された集合体です。 Local Address ローカルアドレス The rest field of the Internet address (as defined in [3]). インターネットアドレスの残りのフィールドです。(資料[3]にて定義さ れています。) Network ネットワーク A single Internet network (which may or may not be divided into subnets). (subnetに分割されているかどうかはわかりませんが、)１つのインター ネットのネットワークです。 Mogul & Postel [Page 16] RFC 950 August 1985 Internet Standard Subnetting Procedure Network Number ネットワーク番号 The network field of the Internet address. インターネットアドレスのネットワークフィールドです。 Subnet サブネット One or more physical networks forming a subset of an Internet network. A subnet is explicitly identified in the Internet address. １つ以上の物理ネットワークは一つのインターネットネットワークの subnetで形作られています。subnetはインターネットアドレスで確実に 認識されます。 Subnet Field subnetフィールド The bit field in an Internet address denoting the subnet number. The bits making up this field are not necessarily contiguous in the address. インターネットアドレス中のビットフィールドは、subnet番号を表し ます。このフィールドを作り上げるビット列はアドレス中で隣接する必 要はありません。 Subnet Number subnet番号 A number identifying a subnet within a network. 番号はネットワークに含まれるsubnetを認識します。 Appendix IV. Assigned Numbers 追記 IV. 割り当て番号 The following assignments are made for protocol parameters used in the support of subnets. The only assignments needed are for the Internet Control Message Protocol (ICMP) [5]. 以下にsubnetのサポートで利用するプロトコルパラメータに対して作られ た割り当てを記述します。これは、インターネット制御メッセージプロトコ ル(ICMP)に対してのみ割当が必要とされます。 ICMP Message Types AM1 = 17 AM2 = 18 Mogul & Postel [Page 17] RFC 950 August 1985 Internet Standard Subnetting Procedure References [1] Mogul, J., "Internet Subnets", RFC-917, Stanford University, October 1984. [2] Postel, J., "Multi-LAN Address Resolution", RFC-925, USC/Information Sciences Institute, October 1984. [3] Postel, J., "Internet Protocol", RFC-791, USC/Information Sciences Institute, September 1981. [4] Finlayson, R., T. Mann, J. Mogul, M. Theimer, "A Reverse Address Resolution Protocol", RFC-903, Stanford University, June 1984. [5] Postel, J., "Internet Control Message Protocol", RFC-792, USC/Information Sciences Institute, September 1981. [6] Mogul, J., "Broadcasting Internet Datagrams", RFC-919, Stanford University, October 1984. [7] GADS, "Towards an Internet Standard Scheme for Subnetting", RFC-940, Network Information Center, SRI International, April 1985. [8] Croft, B., and J. Gilmore, "BOOTP -- UDP Bootstrap Protocol", RFC-951, Stanford University, August 1985. [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-943, USC/Information Sciences Institute, April 1985. 訳 Dream Train Internet 近藤 邦昭 Mogul & Postel [Page 18]