この文書はRFC917の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
Network Working Group Jeffrey Mogul Request for Comments: 917 Computer Science Department Stanford University October 1984 INTERNET SUBNETS インターネットサブネット Status Of This Memo この文書の状態 This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. このRFCはARPAインターネット共同体に提案されたプロトコルを勧め て、そして改良のために議論と提案を求めます。このメモの配布は無制限で す。 Overview 概要 We discuss 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. 我々はインターネットネットワークの「サブネット」の有用性を論じ、そし てこれはひとつのインターネットネットワークの論理的細分です。管理上あ るいは技術的な理由で、多くの組織が複数のインターネットネットワーク番 号を獲得する代わりに、1つのインターネットネットワークをいくつかのサ ブネットに分けることに決めました。 We propose procedures for the use of subnets, and discuss approaches to solving the problems that arise, particularly that of routing. 我々はサブネットの用途に対して手順を提案して、そして発生する問題、特 にルーティングを解く方法を論じます。 Acknowledgment 謝辞 This proposal is the result of discussion with several other people. J. Noel Chiappa, Chris Kent, and Tim Mann, in particular, provided important suggestions. この提案は数人の他の人々との論議の結果です。J. Noel ChiappaとChris Kentとand Tim Mannは特に重要な提案を供給しました。 1. Introduction 1. はじめに The original view of the Internet universe was a two-level hierarchy: the top level the catenet as a whole, and the level below it a collection of "Internet Networks", each with its own Network Number. (We do not mean that the Internet has a hierarchical topology, but that the interpretation of addresses is hierarchical.) インターネット世界の元の想定は2レベル階層でした:一番上が全体で、下 のレベルがそれぞれがネットワーク番号を持つ「インターネットネットワー ク」の集合でした。(我々はインターネットが階層的なトポロジーを持つと 言ってるのではなく、アドレスの解釈が階層的だと言っています。) 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 might (or might not) be divided into a collection of subnets. この想定は単純で強力であると分かったが、多くの組織でそれが不適当であ ることを見いだし、そしてインターネットアドレスの解釈に3番目のレベル を加えました。この想定で、あるインターネットネットワークがサブネット の集合に分かれるかもしれません(そうでないかもしれません)。 The original, two-level, view carries a strong presumption that, to a host on an Internet network, that network may be viewed as a single edge; to put it another way, the network may be treated as a "black box" to which a set of hosts is connected. This is true of the ARPANET, because the IMPs mask the use of specific links in that network. It is also true of most local area network (LAN) technologies, such as Ethernet or ring networks. 元の2レベルの想定は、インターネットネットワーク上のホストがネットワー クがひとつの線と見るかもしれない、という強い推定を起こします;言い換 えると、ネットワークはホスト集合が接続されている「ブラックボックス」 として取り扱われるかもしれません。IMPはそのネットワークの特定のリ ンクの使用を隠すので、これはARPANETについて真実です。これはた いていの、イーサネットやリングネットワークのような、ローカルエリアネッ トワーク(LAN)技術でも真実です。 However, this presumption fails in many practical cases, because in moderately large organizations (e.g., Universities or companies with more than one building) it is often necessary to use more than one LAN cable to cover a "local area". For example, at this writing there are eighteen such cables in use at Stanford University, with more planned. しかしながら、この推定は多くの実用的な場合に失敗します、なぜなら適度 に大きい組織(例えば、大学あるいは1つ以上の建物を持っている会社)で 「ローカルエリア」をカバーするために1つ以上のLANケーブルを使うこ とはしばしば必要だからです。例えば、これを書いている時点で、スタン フォード大学にこのようなケーブルが18あり、さらに計画中です。 There are several reasons why an organization might use more than one cable to cover a campus: キャンパスをカバーする組織が1つ以上のケーブルを使ういくつかの理由が あります: - 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. - 異なる技術:特に研究環境で、使用中の1種類以上のLANがあるかも しれません;例えば、組織がイーサネットをサポートするいくつかの装 置とリングネットワークをサポートする装置を持っているかもしれませ ん。 - Limits of technologies: Most LAN technologies impose limits, based 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上の一部の ホストにとって可能です。この問題に対する一般的な解決策はホストを 相互通信の多い群に分けて、そして別のケーブルにこれらの群を置くこ とです。 - 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. - 1対1リンク:しばしば大学キャンパスのような「ローカルエリア」が、 LAN技術で結ぶには遠すぎる2つの場所に分かれます。この場合、高 速の1対1リンクがいくつかのLANを結ぶかもしれません。 An organization that has been forced to use more than one LAN has three choices for assigning Internet addresses: 1つ以上のLANを使うことを強いられた組織がインターネットアドレスの 割り当てに対して3つの選択を持ちます:。 1. Acquire a distinct Internet network number for each cable. 1. 各ケーブルに別のインターネットネットワーク番号を獲得する。 2. Use a single network number for the entire organization, but assign host numbers without regard to which LAN a host is on. (We will call this choice "transparent subnets".) 2. 組織全体にひとつのネットワーク番号を使い、ホストがどのLAN上 にあるかに関係なく、ホスト番号を割り当てる。(我々はこの選択を 「透過サブネット」と呼ぶでしょう。) 3. Use a single network number, and partition the host address space by assigning subnet numbers to the LANs. ("Explicit subnets".) 3. ひとつのネットワーク番号を使い、そしてサブネット番号をLANに 割り当てることによってホストアドレス空間を分割する。(「明示的 サブネット」) Each of these approaches has disadvantages. The first, although not requiring any new or modified protocols, does result 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 nice 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. 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. 2番目の方法は、LANの集合が1つのインターネットネットワークを作る、 ある約束あるいはプロトコルが必要です。例えば、これはそれぞれのインター ネットアドレスがアドレス解決プロトコル(ARP)を使ってハードウェア アドレスに変換されるLAN上で、LAN間ブリッジがローカルでないあて 先のARP要求を捕えるようにすることでできます。しかしながらこれは全 てのLANで使えるのではなく、特にARPプロトコルが現在使われないと ころや、LANがブロードキャストをサポートしない場合に可能ではありま せん。より基本的な問題はブリッジが、多分ブロードキャストアルゴリズム を使うことによって、ホストがどのLAN上にあるか分からなくてはならな いということです。LANの数が増加するにつれて、ブロードキャストのコ ストは同様に大きくなります;同じく、ブリッジで必要とした翻訳キャッシュ の大きさはネットワークのホストの合計数で増加します。 The third approach addresses the key problem: existing standards assume that all hosts on an Internet local network are on a single cable. The solution 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, we believe that these changes are relatively minor, and once made, yield a simple and efficient solution to the problem. Also, the approach we take in this document is to avoid any changes that would be incompatible with existing hosts on non-subnetted networks. 3番目の方法が鍵となる問題を扱います:既存の標準はすべてのインターネッ トのローカルネットワーク上のホストがひとつのケーブル上にあると想定し ます。解決策は明示的にサブネットをサポートすることです。これはインター ネット・プロトコルの修正で、そしてこれですでに使用中のIP実装に対す る変更を必要とするという点で、欠点です(もしこれらの実装がサブネット されたネットワーク上に使われるなら)。しかしながら、我々はこれらの変 更が比較的小さく、そして実行すれば問題に対する単純で効率的な解決をも たらす。と信じます。同じく、我々がこの文書でとる方法はサブネットされ ないネットワーク上の既存のホストと互換性がない変更を避けるはずです。 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 will be explained later. 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. Because of this, there seems little reason to use the second approach listed above. さらに、適切な設計選択がされる時、後に説明されるであろうように、サブ ネットされないネットワーク上にいると信じるホストをサブネットされたネッ トワーク上で使うことは可能です。これは、明示的にサブネットをサポート するためにあるホストの修正が可能ではない時、あるいはゆるやかな移行が 好まれる時、有用です。これのために、上でリストアップされた2番目の方 法を使う理由はほとんどないと思います。 The rest of this document describes approaches to subnets of Internet Networks. この文書の残りがインターネットネットワークのサブネットへの方法を記述 します。 1.1. Terminology 1.1. 専門用語 To avoid either ambiguity or prolixity, we will define a few terms, which will be used in the following sections: あいまい性あるいは冗長性を避けるために、我々は次の章で使われるで あろう少数の用語を定義するでしょう: Catenet カテネット The collection of connected Internet Networks 接続されたインターネットネットワークの集合。 Network ネットワーク A single Internet network (that may or may not be divided into subnets.) ひとつのインターネットネットワーク(サブネットに分けられるかも しれないし、そうしてないかもしれません)。 Subnet サブネット A subnet of an Internet network. インターネットネットワークのサブネット。 Network Number ネットワーク番号 As in [8]. [8]の通り。 Local Address ローカルアドレス The bits in an Internet address not used for the network number; also known as "rest field". ネットワーク番号に使われないインターネットアドレスのビット; 「残フィールド」として知られていてる。 Subnet Number サブネット番号 A number identifying a subnet within a network. ネットワークの中でサブネットを識別している番号。 Subnet Field サブネットフィールド The bit field in an Internet address used for the subnet number. インターネットアドレスでのサブネット番号を識別するビットフィー ルド。 Host Field ホストフィールド The bit field in an Internet address used for denoting a specific host. 特定のホストを意味するために使われたインターネットアドレスでの ビットフィールド。 Gateway ゲートウェイ A node connected to two or more administratively distinct networks and/or subnets, to which hosts send datagrams to be forwarded. ホストが転送するデータグラムを送る、2つ以上の管理の異なるネッ トワークやサブネットワークに接続したノード。 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 know to other hosts. Also called a "software repeater". 2つ以上の管理的には同じだが物理的には異なるサブネットを接続す るノードで、必要なら自動的にデータグラムを転送するが、その存在 を他のホストが知らないもの。「ソフトウェアリピータ」とも呼ばれ ます。 2. Standards for Subnet Addressing 2. サブネットアドレスの標準 Following the division presented in [2], we observe that subnets are fundamentally an issue of addressing. In this section, we first describe a proposal for interpretation of Internet Addressing to support subnets. We then discuss the interaction between this address format and broadcasting; finally, we present a protocol for discovering what address interpretation is in use on a given network. [2]で提出された割り算の後に続いて、我々はサブネットが基本的にアドレス の問題であると述べます。この章で、我々は最初にサブネットをサポートす るインターネットアドレスの解釈の提案を記述します。我々はこのアドレス フォーマットとブロードキャストの関係を論じます;最終的に、我々はある ネットワークでどのアドレス解釈が使用されているかわかるためのプロトコ ルを提出します。 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: 組織がインターネットネットワーク番号を割り当てられて、さらにそのネッ トワークをサブネットの集合に分け、そしてホストアドレスを割り当てる と考えます:どのようにこれはされるべきですか?インターネットアドレ スの一部を「ローカルアドレス」に割当てる際の最小の制限があるので、 サブネット番号を表すことに対していくつかのアプローチが提言されまし た: 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. 可変幅フィールド:ローカルアドレス部の任意のビット数をサブネッ ト番号に使用する;このフィールドのサイズは、あるネットワーク にとっては定数ですが、ネットワーク間では変動します。もしフィー ルド幅がゼロなら、サブネットが使用されていません。 2. Fixed-width field: A specific number of bits (e.g., eight) is used for the subnet number, if subnets are in use. 2. 固定幅フィールド:もしサブネットが使用中であるなら、特定のビッ ト数(例えば8)の指定がサブネット番号のために使われます。 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. 自己−コーディング変数幅フィールド:ちょうどネットワーク番号 フィールドの幅(すなわち、クラス)がその上位ビットでコード化 されるように、サブネットフィールド幅も同様にコード化されます。 4. Self-encoding fixed-width field: A specific number of bits is is used for the subnet number. Subnets are in use if the high-order bit of this field is one; otherwise, the entire local address part is used for host number. 4. 自己−コーディング固定長フィールド:サブネット番号に特定のビッ ト数を使用します。サブネットは、もしこのフィールドの上位ビッ トが1であるなら、使用中です;さもなければ、全部のローカルア ドレス部分はホスト番号のために使われます。 Since there seems to be no advantage in doing otherwise, all these schemes place the subnet field as the most significant field in the local address part. Also, since the local address part of a Class C address is so small, there is little reason to support subnets of other than Class A and Class B networks. 他に利点があるように思われないので、これらすべての案ではローカルア ドレス部の上位フィールドにサブネットフィールドを置きます。同じく、 クラスCアドレスのローカルアドレス部が小さいので、クラスAとクラス B以外でネットワークのサブネットをサポートする理由がほとんどありま せん。 What criteria can we use to choose one of these four schemes? First, do we want to use a self-encoding scheme; that is, should it be possible to tell from examining an Internet address if it refers to a subnetted network, without reference to any other information? これらの4つの案の1つを選択するために何の基準を使うことができます か?最初に、我々は自己コーディング案を使うことを望みます;すなわち、 インターネットアドレスを調べることで、他の情報参照なしで、サブネッ トされたネットワークかわかりますか? One advantage to self-encoding is that it allows one to determine if a non-local network has been divided into subnets. It is not clear that this would be of any use. The principle advantage, however, is that 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 non-subnetted networks which have existing host numbers that use arbitrary bits in the local address part <1>. In other words, it is useful to be able control whether a network is subnetted independently from the assignment of host addresses. Another disadvantage of any self-encoding scheme is that it reduces the local address space by at least a factor of two. 自己コーディングの1つの利点はそれが他の人がネットワークがサブネッ トに分けられたかどうか決定することを許すということです。これが役に 立つかどうかは明確ではありません。しかしながら、原理的な利点は、2 つのアドレスが同じサブネットにあるかどうかの決定で、実装が追加の情 報を必要としないということです。しかしながら、これは同じく欠点と見 ることができます:それはローカルアドレス部の任意ビットを使うホスト 番号が存在するサブネットされないネットワークで問題を起こすかもしれ ません<1>。言い換えれば、ホストアドレスの割り当てと、ネットワーク がサブネット化されているかが独立であることは、管理するために有用で す。 If a self-encoding scheme is not used, it is clear that a variable-width subnet field is appropriate. 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 (the subnet field width) instead of a boolean is negligible. The advantage of using a variable-width subnet field is that it allows each organization to choose the best way to allocate relatively scarce bits of local address to subnet and host numbers. 他の自己コーディング案の欠点は、それがローカルアドレス空間を少なく とも2のべき乗レベルで下げるということです。もし自己コーディング案 が使われないなら、可変幅サブネットフィールドが適切であることは明確 です。どの場合も何かネットワーク毎のサブネットが使用されているかの フラグが必要なので、論理値の代わりに整数(サブネット幅フィールド) を使う追加コストは問題になりません。可変幅サブネットフィールドを使 う利点は、それがそれぞれの組織がサブネットへのローカルアドレスとホ スト番号にビットを割り当てる最も良い方法を選択することを許すという ことです。 Our proposal, therefore, is that the Internet address be interpreted as: 我々の提案は、従ってインターネットアドレスを以下に解釈する事です: <network-number><subnet-number><host-number> where the <network-number> field is as in [8], the <host-number> field is at least one bit wide, and the width of the <subnet-number> field is constant for a given network. No further structure is required for the <subnet-number> or <host-number> fields. If the width of the <subnet-number> field is zero, then the network is not subnetted (i.e., the interpretation of [8] is used.) ここで<network-number>は[8]の通りで、<host-number>フィールドは最小 1ビットの幅で、<subnet-number>フィールドの幅は、与えられたネット ワークで定数です。<subnet-number>や<host-number>にこれ以上の構造は 必要ありません。もし<subnet-number>フィールド幅がゼロであるなら、 ネットワークはサブネット化されません(すなわち[8]の解釈が使われま す)。 For example, on a Class A network with an eight bit wide subnet field, an address is broken down like this: 例えば、8ビットのサブネットフィールドのクラスAネットワークで、 アドレスが以下のようになります:。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| NETWORK | SUBNET | Host number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We expect that, for reasons of simplicity and efficient implementation, that most organizations will choose a subnet field width that is a multiple of eight bits. However, an implementation must be prepared to handle other possible widths. 単純と効率的な実装の理由で、たいていの組織が8ビットの倍数のサブネッ トフィールド幅を選択することを、我々は期待します。しかしながら、実 装が他の可能な幅を処理する用意ができているに違いありません。 We reject the use of "recursive subnets", the division of the host field into "sub-subnet" and host parts, because: 我々は「再帰サブネット」、ホストフィールドを「サブサブネット」へ分 割するのを拒否します、なぜなら: - There is no obvious need for a four-level hierarchy. - 4レベル階層の明白な必要性がありません。 - The number of bits available in an IP address is not large enough to make this useful in general. - IPアドレスで利用可能なビット数は一般にこれを有用にするほど 十分大きくありません。 - The extra mechanism required is complex. - 必要とされる余分のメカニズムは複雑です。 2.2. Changes to Host Software to Support Subnets 2.2. サブネットをサポートするためにホストソフトウェア変更 In most implementations of IP, there is code in the module that handles outgoing packet that does something like: たいていのIP実装で、以下の様な外向パケットを処理するモジュールの コードがあります: IF ip_net_number(packet.ip_dest) = ip_net_number(my_ip_addr) THEN send_packet_locally(packet, packet.ip_dest) ELSE send_packet_locally(packet, gateway_to(ip_net_number(packet.ip_dest))) (If the code supports multiple 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. For example, on a Class A network using an eight-bit wide subnet field, the mask would be 255.255.0.0. サブネットをサポートするために、もうmy_ip_maskと呼ばれる32ビット 量を記憶することが必要です。これはIPネットワーク番号に対応するビッ トとサブネット番号フィールドに対応する追加ビットのビットマスクです。 例えば、8ビット幅のサブネットフィールドを使うクラスAネットワーク のマスクは255.255.0.0であるでしょう。 The code then becomes: コードは以下になります: IF bitwise_and(packet.ip_dest, my_ip_mask) = bitwise_and(my_ip_addr, my_ip_mask) THEN send_packet_locally(packet, packet.ip_dest) ELSE send_packet_locally(packet, gateway_to(bitwise_and(packet.ip_dest, my_ip_mask))) Of course, part of the expression in the conditionally can be pre-computed. もちろん、条件の式の一部は前もって計算できます。 It may or may not be necessary to modify the "gateway_to" function, so that it performs comparisons in the same way. 「gateway_to」機能を修正する必要があるか、ないかもしれません、それ で同じように比較を行います。 To support multiply-connected hosts, the code can be changed to 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」と「my_ip_mask」を保持する様に変えることができます; 条件文の式は各インタフェース毎に評価されなくてはなりません。 2.3. Subnets and Broadcasting 2.3. サブネットとブロードキャスト In the absence of subnets, there are only two kinds of broadcast possible within the Internet Protocol <2>: broadcast to all hosts on a specific network, or broadcast to all hosts on "this network"; the latter is useful when a host does not know what network it is on. サブネットなしで、インターネット・プロトコルで可能なブロードキャス トは2つです<2>:特定ネットワーク上のすべてのホストへのブロードキャ ストか、「このネットワーク」上のすべてのホストへのブロードキャスト; 後者はホストがどのネットワーク上にいるか知らない時に有用です。 When subnets are used, the situation becomes slightly more complicated. First, the possibility now exists of broadcasting to a specific subnet. Second, broadcasting to all the hosts on a subnetted network requires additional mechanism; in [6] the use of "Reverse Path Forwarding" [3] is proposed. Finally, the interpretation of a broadcast to "this network" is that it should not be forwarded outside of the original subnet. サブネットが使われる時、状態は少し複雑になります。最初に、特定のサ ブネットにブロードキャストする可能性が存在します。第二に、サブネッ トされたネットワーク上のすべてのホストにブロードキャストすることは 追加のメカニズムを必要とします;[6]で「逆パス転送」[3]の使用が提案 されます。最終的に、「このネットワーク」へのブロードキャストの解釈 はそれがオリジナルのサブネット外に転送されるべきではないということ です。 Implementations must therefore recognize three kinds of broadcast addresses, in addition to their own host addresses: 従って実装が、自分自身のホストアドレスのほかに、ブロードキャストア ドレスの3つの種類を認識しなくてはなりません: This physical network この物理ネットワーク A destination address of all ones (255.255.255.255) causes the a datagram to be sent as a broadcast on the local physical network; it must not be forwarded by any gateway. 全て1の宛先アドレス(255.255.255.255)は、データグ ラムを物理ネットワークのブロードキャストに送ります;これはゲー トウェイで転送されてはなりません。 Specific network 特定ネットワーク The destination address contains a valid network number; the local address part is all ones (e.g., 36.255.255.255). 宛先アドレスは正当なネットワーク番号を含んでいます;ローカルア ドレス部はすべて1です(例えば、36.255.255.255)。 Specific subnet 特定サブネット The destination address contains a valid network number and a valid subnet number; the host field is all ones (e.g., 36.40.255.255). 宛先アドレスは正当なネットワーク番号と正当なサブネット番号を含 んでいます;ホストフィールドはすべて1です(例えば、 36.40.255.255)。 For further discussion of Internet broadcasting, see [6]. インターネットブロードキャストのさらなる議論は[6]を見てください。 One factor that may aid in deciding whether to use subnets is that it is possible to broadcast to all hosts of a subnetted network with a single operation at the originating host. It is not possible to broadcast, in one step, to the same set of hosts if they are on distinct networks. サブネットを使うべきかどうか決める際の1つの要因は、出発点のホスト でひとつのオペレーションですべてのサブネットされたネットワークのホ ストにブロードキャストすることが可能かどうかです。ホスト群が異なる ネットワークにいるなら、1つのステップで同じホスト群内にブロードキャ ストできません。 2.4. Determining the Width of the Subnet Field 2.4. サブネットフィールド幅の決定 How can a host (or gateway) determine what subnet field width is in use on a network 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. どのようにホスト(あるいはゲートウェイ)の接続されたネットワークで 使用中のサブネットフィールド幅を決定しますか?問題はインターネット ホストのための他の「起動」問題に類似しています:どのようにホストが 自分自身のアドレスを決定するか、そしてどのようにローカルネットワー ク上のゲートウェイの場所を突き止めるか。すべての3つの場合で、2つ の基本的な解決があります:組み込み情報と、ブロードキャストベースプ ロトコル。 "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 hard-wired solution is satisfactory. 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" [4]. 組み込み情報はネットワークから孤立しているホストに入手可能です。こ れはコンパイルで組み込まれるか、あるいは(なるべく)ファイルをディ スクに保存します。しかしながら、LAN上で起動するディスクレスワー クステーションが一般的になる場合に、どの組込み解決策も満足ではあり ません。その代わりに、たいていのLAN技術がブロードキャストをサポー トするので、新しい起動ホストにより良い方法は必要な情報の要求をブロー ドキャストする事です。例えば、インターネットアドレスを決定する目的 で、ホストが「逆アドレス解決プロトコル」[4]を使ってもよいです。 We propose to extend the ICMP protocol [9] by adding a new pair of ICMP message types, "Address Format Request" and "Address Format Reply", analogous to the "Information Request" and "Information Reply" ICMP messages. These are described in detail in Appendix I. 我々は新しいICMPメッセージタイプのペア「アドレスフォーマット要 求」と「アドレスフォーマット応答」と、類似の「情報要求」と「情報応 答」とICMPプロトコル[9]に追加する拡張を提案します。これらは付 録Iで詳細に記述されます。 The intended use of these new ICMPs is that a host, when booting, broadcast an "Address Format Request" message <3>. A gateway (or a host acting in lieu of a gateway) that receives this message responds with an "Address Format 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 width of the subnet field. これらの新しいICMPの意図的な用途は、ホストが起動する時に、「ア ドレスフォーマット要求」メッセージをブロードキャストすることです<3>。 このメッセージを受取るゲートウェイ(あるいはゲートウェイの代行のホ スト)が「アドレスフォーマット応答」で返答します。もしどのホストが 要請を送ったかの表示がなければ(すなわち、IPソースアドレスがゼロ であるなら)、応答は同様にブロードキャストされます。要求ホストは応 答を聞き、それからサブネットフィールドの幅を決定するでしょう。 Since there is only one possible value that can be sent in an "Address Format 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で「アドレスフォーマット応答」で応答できる値は1つだけ なので、要求ホストは送った要求と応答を対応づける必要はありません; 同様に複数のゲートウェイが応答しても問題ありません。我々はホストが たまに再起動する想定します、それでこのプロトコルの使用によるネット ワーク上のブロードキャスト負荷は小さくあるべきです。 If a host is connected to more than one LAN, it must use this protocol on each, unless it can determine (from a response on one of the LANs) that several of the LANs are part of the same network, and thus must have the same subnet field width. もしホストが1つ以上のLANに接続しているなら、(LANの1からの 回答から)いくつかのLANが同じネットワークの一部で、したがって同 じサブネットフィールド幅を持つ決定できた場合を除き、それぞれにこの プロトコルを使用しなければなりません。 One potential problem is what a host should do if it receives no response to its "Address Format Request", even after a reasonable number of tries. Three interpretations can be placed on the situation: 1つの可能性がある問題は、ホストが合理的な回数の試みをしても「アド レスフォーマット要求」に対する応答を受け取らないなら、ホストは何を するべきかです。状況により3つの解釈ができます: 1. The local net exists in (permanent) isolation from all other nets. 1. ローカルネットは他のネットワークと(部分的に)孤立して存在し ます。 2. Subnets are not in use, and no host supports this ICMP request. 2. サブネットは使用中でなく、このICMP要求をサポートするホス トがありません。 3. All gateways on the local net are (temporarily) down. 3. すべてのローカルネットワーク上のゲートウェイは(一時的に)ダ ウンしています。 The first and second situations imply that the subnet field width is zero. In the third situation, there is no way to determine what the proper value is; the safest choice is thus zero. 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 Format Reply"; when a host receives such a message that disagrees with its guess, it should adjust its data structures to conform to the received value. No host or gateway should send an "Address Format Reply" based on a "guessed" value. 最初と2番目の状態はサブネットフィールド幅がゼロであることを意味し ます。3番目の状態で、適切な価値が何であるか決定する方法がありませ ん;最も安全な選択はゼロです。これが後に間違っていることが分かるか もしれないけれども、それは他が正しい伝達を妨げないでしょう。ホスト が間違った選択から回復することは可能です:ゲートウェイが起動する時 に「アドレスフォーマット応答」をブロードキャストするべきで、ホスト がその推測と意見が違うメッセージを受け取る時、データ構造を受信した 値に従うように調整するべきです。ホストあるいはゲートウェイが「推測」 値に基づいて「アドレスフォーマット応答」を送るべきではありません。 Finally, note that no host is required to use this ICMP protocol to discover the subnet field width; it is perfectly reasonable for a host with non-volatile storage to use stored information. 最終的に、ホストがサブネットフィールド幅を見つけるためにこのICM Pプロトコルを使うように要求されないことを注意してください;不発揮 性メモリを持つホストが保管された情報を使うことは完全に合理的です。 3. Subnet Routing Methods 3. サブネットルーティング方法 One problem that faces all Internet hosts is how to determine a route to another host. In the presence of subnets, this problem is only slightly modified. すべてのインターネットホストが直面する1つの問題は他のホストの経路を 決定する方法です。サブネットに関してこの問題はわずかに修正するだけで す。 The use of subnets means that there are two levels to the routing process, instead of one. If the destination host is on the same network as the source host, the routing decision involves only the subnet gateways between the hosts. If the destination is on a different network, then the routing decision requires the choice both of a gateway out of the source host's network, and of a route within the network to that gateway. サブネットの使用はルーティングプロセスに1つではなく2つのレベルがあ ることを意味します。もし宛先ホストがソースホストと同じネットワークの 上にあるなら、ルーティング決定はホストの間のサブネットゲートウェイだ けが関係します。もし宛先が異なるネットワーク上にあるなら、ルーティン グ決定はソースホストのネットワークの外に送るのにどのゲートウェイ選ぶ かと、ゲートウェイまでの経路の決定です。 Fortunately, many hosts can ignore this distinction (and, in fact, ignore all routing choices) by using a "default" gateway as the initial route to all destinations, and relying on ICMP Host Redirect messages to define more appropriate routes. However, this is not an efficient method for a gateway or for a multi-homed host, since a redirect may not make up for a poor initial choice of route. Such hosts should use a routing information exchange protocol, but that is beyond the scope of this document; in any case, the problem arises even when subnets are not used. 幸いに、多くのホストがすべての宛先で「デフォルト」ゲートウェイを最初 の経路として用いて、そしてICMPホストリダイレクトメッセージが適切 な経路を定義することを当てにするので、この区別を無視できます(そして、 実際、すべてのルーティング選択を無視します)。しかしながら、これはリ ダイレクトが経路の初期の簡単な選択に対してだけなので、ゲートウェイや マルチホームホストに対して効率的な方法ではありません。このようなホス トはルーティング情報交換プロトコルを使うべきですが、これはこの文書の 範囲外です;いずれの場合も問題はサブネットが使われない時でも起こりま す。 The problem for a singly-connected host is thus to find at least one neighbor gateway. Again, there are basic two solutions to this: use hard-wired information, or use broadcasts. We believe that the neighbor-gateway acquisition problem is the same with or without subnets, and thus the choice of solution is not affected by the use of subnets. 接続は1つのホストで問題は少なくとも1つの近隣ゲートウェイを見いだす ことです。これに対する基本的な2つの解決策があります:組込み情報かブ ロードキャスト。我々は近隣ゲートウェイ獲得問題がサブネットの有無にか かわらず同じであると信じます、それで解決策はサブネットの使用の影響を 受けません。 However, one problem remains: a source host must determine if datagram to a given destination address must be sent via a gateway, or sent directly to the destination host. In other words, is the destination host on the same physical network as the source? This particular phase of the routing process is the only one that requires an implementation to be explicitly aware of subnets; in fact, if broadcasts are not used, it is the only place where an Internet implementation must be modified to support subnets. しかしながら、1つの問題が残ります:ソースホストがある宛先アドレスへ のデータグラムをゲートウェイに送るか、直接宛先ホストに送るか決定しな くてはなりません。換言すれば、宛先ホストはソースと同じ物理ネットワー クの上にありますか?このルーティングプロセスの固有フェーズは実装に明 示的にサブネットに気付くように要求する唯一のものです;実際、もしブロー ドキャストが使われないなら、それは唯一のインターネット実装ががサブネッ トをサポートするために修正されなくてはならない所です。 Because of this, it is possible to use some existing implementations without modification in the presence of subnets <4>. For this to work, such implementations must: これのために、サブネットに対し修正なしである既存の実装を使うことは可 能です<4>。これが働くために、このような実装は以下でなければなりませ ん: - Be used only on singly-homed hosts, and not as a gateway. - ゲートウェイとしてではなく、単一ホームホストとしてだけ使うこと。 - Be used on a broadcast LAN. - ブロードキャストLAN上で使うこと。 - Use an Address Resolution Protocol (ARP), such [7]. - [7]のようなアドレス解決プロトコル(ARP)を使うこと。 - Not be required to maintain connections in the case of gateway crashes. - ゲートウェイ故障の場合に接続の持続を要求しないこと。 In this case, one can modify the ARP server module in a subnet gateway so that when it receives an ARP request, it checks the target Internet address to see if it is along the best route to the target. If it is, it sends to the requesting host an ARP response indicating its own hardware address. The requesting host thus believes that it knows the hardware address of the destination host, and sends packets to that address. In fact, the packets are received by the gateway, and forwarded to the destination host by the usual means. この場合、サブネットゲートウェイのARPサーバーモジュールを、ARP 要求を受け取る時に、宛先インターネットアドレスに対し自分が宛先への最 も良い経路上にあるかを検査するように修正することができます。もしそう なら、要求ホストに自分自身のハードウェアアドレスを示したARP回答を 送ります。要求ホストは宛先ホストのハードウェアアドレスを知ったと信じ、 そのアドレスへ送信します。実際、パケットはゲートウェイで受信され、そ して通常の手段で宛先ホストに転送されます。 This method requires some blurring of the layers in the gateways, since the ARP server and the Internet routing table would normally not have any contact. In this respect, it is somewhat unsatisfactory. Still, it is fairly easy to implement, and does not have significant performance costs. One problem is that if the original gateway crashes, there is no way for the source host to choose an alternate route even if one exists; thus, a connection that might otherwise have been maintained will be broken. この方法は、ARPサーバとインターネットルーティングテーブルが通常連 携しないので、ゲートウェイでいくらかレイヤについて汚れることを要求し ます。この点に関して、これは幾分不満足です。しかし、これはかなり実装 することが容易であり、性能に重大な問題を生じません。1つの問題はもし 元のゲートウェイが故障すると、ソースホストが他の経路があっても代わり の経路を選択する方法がないということです;それで、他の方法で保守され ていない接続が壊れるでしょう。 One should not confuse this method of "ARP-based subnetting" with the superficially similar use of ARP-based bridges. ARP-based subnetting is based on the ability of a gateway to examine an IP address and deduce a route to the destination, based on explicit subnet topology. In other words, a small part of the routing decision has been moved from the source host into the gateway. An ARP-based bridge, in contrast, must somehow locate each host without any assistance from a mapping between host address and topology. Systems built out of ARP-based bridges should not be referred to as "subnetted". この「ARPベースサブネット」の方法をARPベースのブリッジの外面的 に類似する使用と混同するべきではありません。ARPベースのサブネット は、ゲートウェイがIPアドレスを調べて明示的なサブネットトポロジーに 基づいて宛先への経路を推論する能力に基づいています。換言すれば、ルー ティング決定の小さい部分がソースホストからゲートウェイ中に動かされま した。ARPベースのブリッジはこれと対照的に、ホストアドレスとトポロ ジーの間のマッピングの援助なしで、それぞれのホストの場所を突き止めな くてはなりません。ARPベースのブリッジから構築されたシステムが、 「サブネット」として参照されるべきではありません。 N.B.: the use of ARP-based subnetting is complicated by the use of broadcasts. An ARP server [7] should never respond to a request whose target is a broadcast address. Such a request can only come from a host that does not recognize the broadcast address as such, and so honoring it would almost certainly lead to a forwarding loop. If there are N such hosts on the physical network that do not recognize this address as a broadcast, then a packet sent with a Time-To-Live of T could potentially give rise to T**N spurious re-broadcasts. 注意:ARPベースのサブネットの使用はブロードキャストの使用によって 複雑になります。ARPサーバ[7]は決して宛先がブロードキャストアドレス である要請に返答するべきではありません。このような要請はブロードキャ ストアドレスを理解していないホストから来るだけで、それでこれに対応す ることはほとんど確実に転送ループを導くでしょう。もし物理ネットワーク にN個のこのようなブロードキャストアドレスを認識しないホストがあるの ならあるなら、生存時間がTのパケットの送信は潜在的にT**Nの再ブロー ドキャストを発生します。 4. Case Studies 4. 事例 In this section, we briefly sketch how subnets have been used by several organizations. この小でで、我々は手短かにいくつかの組織によって使われたサブネットの 方法の概要を述べます。 4.1. Stanford University 4.1. スタンフォード大学 At Stanford, subnets were introduced initially for historical reasons. Stanford had been using the Pup protocols [1] on a collection of several Experimental Ethernets [5] since 1979, several years before Internet protocols came into use. There were a number of Pup gateways in service, and all hosts and gateways acquired and exchanged routing table information using a simple broadcast protocol. スタンフォードで、サブネットは歴史的理由のために導入されました。ス タンフォードは、インターネット・プロトコルの使用にかかわる数年前の 1979年から、いくつかの実験的なイーサネット[5]の集合体でPup プロトコル[1]を使っていました。サービス中の多くのPupゲートウェ イがありました、そしてすべてのホストとゲートウェイは単純なブロード キャストプロトコルを使ってルーティングテーブル情報を獲得して交換し ていました。 When the Internet Protocol was introduced, the decision was made to use an eight-bit wide subnet number; Internet subnet numbers were chosen to match the Pup network number of a given Ethernet, and the Pup host numbers (also eight bits) were used as the host field of the Internet address. インターネット・プロトコルが導入された時、8ビット幅のサブネット番 号を使う決定がされました;インターネットサブネット番号が既存イーサ ネットのPupネットワーク番号に合うように選ばれました、そしてPupホス ト番号(同じく8ビット)がインターネットアドレスのホストフィールド として用いられました。 The Pup-only gateways were then modified to forward Internet datagrams according to their Pup routing tables; they otherwise had no understanding of Internet packets and in fact did not adjust the Time-to-live field in the Internet header. This seems to be acceptable, since bugs that caused forwarding loops have not appeared. The Internet hosts that are multi-homed and thus can serve as gateways do adjust the Time-to-live field; since all of the currently also serve as Pup gateways, no additional routing information exchange protocol was needed. Pup-onlyゲートウェイはPupルーティングテーブルに基づいてインターネッ トデータグラムを転送するように修正されました;それいがいゲートウェ イはインターネットパケットを理解せず、事実インターネットヘッダの生 存時間フィールドを調整しませんでした。これは、ループ転送を起こすバ グが現われなかったので、許されると思います。インターネットホストは マルチホームで、生存時間を調整するゲートウェイの役を務める事が出来 ます;現在の所Pupゲートウェイが担っているので、追加のルーティング 情報交換プロトコルが必要ありませんでした。 Internet host implementations were modified to understand subnets (in several different ways, but with identical effects). Since all already had Pup implementations, the Internet routing tables were maintained by the same process that maintained the Pup routing tables, simply translating the Pup network numbers into Internet subnet numbers. インターネットホスト実装がサブネットを理解するために(同じ効果でい くつかの異なった方法で)修正されました。すべてがすでにPup実装を持っ ていたので、インターネットルーティングテーブルは、ただPupネットワー ク番号をインターネットサブネット番号に翻訳し、Pupルーティングテーブ ルを保守するのと同じプロセスによって保守されました。 When 10Mbit Ethernets were added, the gateways were modified to use the ARP-based scheme described in an earlier section; this allowed unmodified hosts to be used on the 10Mbit Ethernets. 10Mビットイーサネットが追加された時、ゲートウェイは前の章で記述 されたARPベースの案を使うために修正されました;これは無修正ホス トが10Mビットイーサネット上で使われることを許しました。 IP subnets have been in use since early 1982; currently, there are about 330 hosts, 18 subnets, and a similar number of subnet gateways in service. Once the Pup-only gateways are converted to be true Internet gateways, an Internet-based routing exchange protocol will be introduced, and Pup will be phased out. IPサブネットが1982年早くから使用中でした;現在、サービス中の およそ330のホストと18のサブネットと同様の数のサブネットゲート ウェイがあります。Pup-onlyゲートウェイがインターネットゲートウェイ に変更されると、インターネットベースのルーティング交換プロトコルが 導入されるでしょう、そしてPupは段階的に排除されるでしょう。 4.2. MIT 4.2. マサチューセッツ工科大学 MIT was the first IP site to accumulate a large collection of local network links. Since this happened before network numbers were divided into classes, to have assigned each link at MIT its own IP network number would have used up a good portion of the available address space. MIT decided to use one IP network number, and to manage the 24-bit "rest" field itself, by dividing it into three 8-bit fields; "subnet", "reserved, must be zero", and "host". Since the CHAOS protocol already in use at MIT used an 8-bit subnet number field, it was possible to assign each link the same subnet number in both protocols. The IP host field was set to 8 bits since most available local net hardware at that point used 8 bit addresses, as did the CHAOS protocol; it was felt that reserving some bits for the future was wise. MITはローカルネットワークリンクの大きい集団を蓄積する最初のIP サイトでした。たまたまネットワーク番号がクラスに分けられる前に、M ITのそれぞれのリンクにそれぞれのIPネットワーク番号をを割り当て たので、利用可能なアドレス空間の良い部分に当てはまりました。MIT は1つのIPネットワーク番号を使い、それぞれ残りの24ビットフィー ルを3つの8ビットフィールドに分割し、管理することに決めました; 「サブネット」と「予約、ゼロを設定」と「ホスト」。MITですでにカ オスプロトコルが使用中で8ビットのサブネット番号を使用していたので、 両方のプロトコルで同じサブネット番号を割り当てできました。IPホス トフィールドは、最も利用可能なローカルネットのハードウェアがその時 点で8つのビットアドレスを使ってたので8ビットに設定され、カオスプ ロトコルと同じです;将来のためにいくつかのビットを予約することは賢 明と感じました。 The initial plan was to use a dynamic routing protocol between the IP subnet gateways; several such protocols have been mooted but nobody has bothered to implement one; static routing tables are still used. It is likely that this change will finally be made soon. 最初の計画はIPサブネットゲートウェイ間に動的ルーティングプロトコ ルを使うことでした;このようなプロトコルがいくつか提案されましたが、 だれも実装の努力をしませんでした;静的ルーティングテーブルがまだ使 われています。まもなく最終的にこの変更がされることはありそうです。 To solve the problem that imported IP software always needed modification to work in the subnetted environment, MIT searched for a model of operation that led to the least change in host IP software. This led to a model where IP gateways send ICMP Host Redirects rather than Network Redirects. All internal MIT IP gateways now do so. With hosts that can maintain IP routing tables for non-local communication on a per host basis, this hides most of the subnet structure. The "minimum adjustment" for host software to work correctly in both subnetted and non-subnetted environments is the bit-mask algorithm mentioned earlier. 導入されているIPソフトウェアをサブネット環境で動くように修正を必 要とする問題を解くために、MITはホストIPソフトウェアの最少の変 更を導くオペレーションのモデルを捜しました。これはIPゲートウェイ がネットワークリダイレクトではなく、ICMPホストリダイレクトを送 るモデルを導きました。すべての内部のMITのIPゲートウェイは今そ うします。ローカル通信できないホスト毎のIPルーティングテーブルを 維持するホストにより、これはサブネット構造体の大部分を隠します。サ ブネット環境と非サブネット環境の両方で動作するホストソフトウェアの ための「最小調整」は、前に言ったビットマスクアルゴリズムです。 MIT has no immediate plans to move toward a single "approved" protocol; this is due partly to the degree of local autonomy and the amount of installed software, and partly to the lack of a single prominent industry standard. Rather, the approach taken has been to provide a single set of physical links and packet switches, and to layer several "virtual" protocol nets atop the single set of links. MIT has had some bad experiences with trying to exchange routing information between protocols and wrap one protocol in another; the general approach is to keep the protocols strictly separated except for sharing the basic hardware. Using ARP to hide the subnet structure is not much in favor; it is felt that this overloads the address resolution operation. In a complicated system (i.e. one with loops, and variant link speeds), a more sophisticated information interchange will be needed between gateways; making this an explicit mechanism (but one insulated from the hosts) was felt to be best. MITはひとつの「承認」プロトコルにする当面の計画を持ちません;こ れはある部分は自治と導入ソフトウェア量の程度によるもので、ある部分 は一つの卓越した工業規格がないためです。どちらかと言うと、とられた アプローチは物理的リンクとパケットスイッチのひとつのセットを供給し、 そしてひとつのリンク集合にいくつかに「仮想」プロトコルネットがを載 せました。MITはプロトコル間でルーティング情報を交換し、そして1 つのプロトコルを他のプロトコルでくるむことのある悪い経験を持ってい ました;一般的な方法は基本ハードウェアの共有以外、厳密にプロトコル を分離しておくことです。サブネット構造体を隠すためにARPを使うこ との賛成は多ありません;これはアドレス解決オペレーションに負荷をか け過ぎると感じられます。複雑なシステム(すなわちループと様々なリン ク速度を持つ)で、より洗練された情報交換がゲートウェイ間に必要とさ れるでしょう;これを明白な機構(ホストから切り離された)にすること は最も良いように感じられました。 4.3. Carnegie-Mellon University 4.3. カーネギー・メロン大学 CMU uses a Class B network currently divided into 11 physical subnets (two 3Mbit Experimental Ethernets, seven 10Mbit Ethernets, and two ProNet rings.) Although host numbers are assigned so that all addresses with a given third octet will be on the same subnet (but not necessarily vice versa), this is essentially an administrative convenience. No software currently knows the specifics of this allocation mechanism or depends on it to route between cables. CMUは現在11の物理的なサブネットに分けられたクラスBネットワー クを使います(2つの3Mビット実験イーサネットと、7つの10Mビッ トイーサネットと2つのProNetリング)。ホスト数は3番目のオクテット がある値であるアドレスが同じサブネット上にあるであろうように割り当 てられました(しかし逆は必ずしも真ではない)、これ本質的に管理上の 便利さのためです。ソフトウェアが現在このアロケーションメカニズムの 詳細を知ったりケーブル間の経路に依存したりしません。 Instead, an ARP-based bridge scheme is used. When a host broadcasts an ARP request, all bridges which receive it cache the original protocol address mapping and then forward the request (after the appropriate adjustments) as an ARP broadcast request onto each of their other connected cables. When a bridge receives a non-broadcast ARP reply with a target protocol address not its own, it consults its ARP cache to determine the cable onto which the reply should be forwarded. The bridges thus attempt to transparently extend the ARP protocol into a heterogenous multi-cable environment. They are therefore required to turn ARP broadcasts on a single cable into ARP broadcasts on all other connected cables even when they "know better". This algorithm works only in the absence of cycles in the network connectivity graph (which is currently the case). Work is underway to replace this simple-minded algorithm with a protocol implemented among the bridges, in support of redundant paths and to reduce the collective broadcast load. The intent is to retain the ARP base and host transparency, if possible. その代わりに、ARPベースブリッジ案が使われます。ホストがARPの リクエストをブロードキャストする時、それを受け取るすべてのブリッジ はオリジナルのプロトコルアドレスのマッピングをキャッシュし、そして 次に他の接続されたケーブルのそれぞれにARPブロードキャストのリク エストとして(適切な調整の後に)リクエストを転送します。ブリッジが 自分ではない目標プロトコルアドレスの非ブロードキャストARP応答を 受け取る時、答えが転送されるべきケーブルを決定するためにそのARP キャッシュを調べます。ブリッジはそれで異質な多ケーブル環境の中に明 白にARPプロトコルを拡張しようと試みます。従って「もっと良く知っ てる」時でさえ、ARPブロードキャストを他の全ての接続されたケーブ ル上に転送することを要求されます。このアルゴリズムはネットワーク接 続グラフでサイクルがない場合にだけ働きます(現在の場合)。重複する パスをサポートしブロードキャストの負荷を減らすため、でこの単純なア ルゴリズムをブリッジ間で実装されたプロトコルで置き換える仕事が進行 中です。意図は、もし可能であるなら、ARPベースとホスト透明度を維 持するはずです。 Implementations supporting the 3Mbit Ethernet and 10Mb proNET ring at CMU use RFC-826 ARP (instead of some wired-in mapping such as simply using the 8-bit hardware address as the the fourth octet of the IP address). CMUにおいて3Mビットイーサネット10MビットproNETリングをサポー トしている実装がRFC826ARPを使います(8ビットのハードウェ アアドレスをIPアドレスの4番目のオクテットとして用いるようなハー ドマッピングの代わりに)。 Since there are currently no redundant paths between cables, the issue of maintaining connections across bridge crashes is moot. With about 150 IP-capable hosts on the net, the bridge caches are still of reasonable size, and little bandwidth is devoted to ARP broadcast forwarding. 現在ケーブル間に重複するパスがないので、ブリッジ故障時に接続を持続 する問題は議論の余地があります。ネット上でおよそ150のIP対応ホ ストに対し、ブリッジキャッシュはまだ合理的な大きさのです、そしてバ ンド幅はほとんどARPブロードキャスト転送で埋まっていません。 CMU's network is likely to grow from its relatively small, singly-connected configuration centered within their CS/RI facility to a campus-wide intra-departmental configuration with 5000-10000 hosts and redundant connections between cables. It is possible that the ARP-based bridge scheme will not scale to this size, and a system of explicit subnets may be required. The medium-term goal, however, is an environment into which unmodified extant (especially 10Mb ethernet based) IP implementations can be imported; the intent is to stay with a host-transparent (thus ARP-based) routing mechanism as long as possible. CMU is concerned that even if subnets become part of the IP standard they will not be widely implemented; this is the major obstacle to their use at CMU. CMUのネットワークはCS/RI機能内に置かれた相対的に小さく単一 接続設定から、5000−10000のホストと重複接続によるキャンパ ス規模の部門内設定まで成長する可能性が高いです。ARPベースのブリッ ジ案はこれにサイズに対してスケールしないことはありえて、そして明示 的なサブネットシステムが必要とされるかもしれません。しかし中間目標 は拡張修正していないIP実装(とくに10Mビットイーサーネット)を 導入できることです;意志は可能な限り長い間、ホスト透過(それでAR Pベースの)ルーティングメカニズムでいる事です。CMUはたとえサブ ネットがIP標準の一部になるとしても、それらが広く実装されないこと を心配しています;これはCMUでのこれらの使用に主な障害です。 I. Address Format ICMP I.アドレスフォーマットICMP Address Format Request or Address Format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: IPフィールド Addresses アドレス The address of the source in an address format request message will be the destination of the address format reply message. To form an address format 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 A2, the subnet field width inserted into the Code 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. アドレスフォーマット要求メッセージのソースアドレスはアドレス フォーマット応答メッセージの宛先であるでしょう。アドレスフォー マット応答メッセージを構成するために、要求ソースアドレスは応 答の宛先アドレスで、応答ソースアドレスは応答者のアドレスで、 タイプコードはA2になり、サブネットフィールド幅がコードフィー ルドに入り、チェックサムは再計算されます。しかしながら、もし 要求メッセージのソースアドレスがゼロであるなら、応答メッセー ジの宛先アドレスはブロードキャストであるべきです。 ICMP Fields: ICMPフィールド: Type タイプ A1 for address format request message A1 アドレスフォーマット要求メッセージの場合 A2 for address format reply message A2 アドレスフォーマット応答メッセージの場合 Code コード 0 for address format request message 0 アドレスフォーマット要求メッセージの場合 Width of subnet field, in bits, for address format reply message ビット単位のサブネットフィールドの幅、アドレスフォーマット応 答メッセージの場合 Checksum チェックサム The checksum is the 16-bit one's complement of the one's 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メッセセージのICMPタイプからの1 の補数の合計の16ビットの1の補数です。チェックサムを計算す ることに対して、チェックサムフィールドはゼロであるべきです。 このチェックサムは将来置き換えられるかもしれません。 Identifier 識別子 An identifier to aid in matching request and replies, may be zero. 要求と応答の対応付けを助ける識別子、ゼロかもしれません。 Sequence Number シーケンス番号 A sequence number to aid in matching request and replies, may be zero. 要求と応答の対応付けを助けるシーケンス番号、ゼロかもしれません。 Description 記述 A gateway receiving an address format request should return it with the Code field set to the number of bits of Subnet number in IP addresses for the network to which the datagram was addressed. If the request was broadcast, the destination network is "this network". The Subnet field width may be from 0 to (31 - N), where N is the width in bits of the IP net number field (i.e., 8, 16, or 24). アドレスフォーマット要求を受信するゲートウェイは、コードフィー ルドにデータグラムが送られるネットワークのIPアドレスのサブネッ ト番号のビット数を設定し、返すべきです。もし要求がブロードキャ ストなら、宛先ネットワークは「このネットワーク」です。NをIP ネット番号フィールドのビット幅(すなわち8か16か24)とする と、サブネットフィールド幅は0から(31−N)でしょう。 If the requesting host does not know its own IP address, it may leave the source field zero; the reply should then be broadcast. Since there is only one possible address format for a network, there is no need to match requests with replies. However, this approach should be avoided if at all possible, since it increases the superfluous broadcast load on the network. もし要求ホストが自分自身のIPアドレスを知らないなら、ソースフィー ルドをゼロのままにしておくかもしれません;応答はブロードキャス トされるべきです。ネットワークで可能なアドレスフォーマットはた ただ1つだけなので、要求と応答を対応させる必要がありません。ネッ トワーク上に余計なブロードキャストを増やすので、このアプローチ は、可能であるなら、避けらるべきです。 Type A1 may be received from a gateway or a host. タイプA1がゲートウェイあるいはホストから送られるかもしれま せん。 Type A2 may be received from a gateway, or a host acting in lieu of a gateway. タイプA2がゲートウェイあるいはゲートウェイの代わりに動作し ているホストから送られるかもしれません。 II. Examples II. 例 For these examples, we assume that the requesting host has address 36.40.0.123, that there is a gateway at 36.40.0.62, and that on network 36.0.0.0, an 8-bit wide subnet field is in use. 例として、要求をするホストがアドレス36.40.0.123を持ち、 36.40.0.62にゲートウェイがあり、そしてネットワーク36.0.0.0 上で幅8ビットのサブネットフィールドが使用中であると想定します。 First, suppose that broadcasting is allowed, and that 36.40.0.123 knows its own address. It sends the following datagram: 最初にブロードキャストが許される、36.40.0.123が自分自身のアド レスを知っているとします。これは次のデータグラムを送ります:。 Source address: 36.40.0.123 Destination address: 36.255.255.255 Protocol: ICMP = 1 Type: Address Format Request = A1 Code: 0 36.40.0.62 will hear the datagram, and should respond with this datagram: 36.40.0.62がデータグラムを受取り、このデータグラムを返すべき です: Source address: 36.40.0.62 Destination address: 36.40.0.123 Protocol: ICMP = 1 Type: Address Format Reply = A2 Code: 8 For the following examples, assume that address 255.255.255.255 denotes "broadcast to this physical network", as described in [6]. 次の例で、アドレス255.255.255.255が[6]で記述されるように、 「この物理ネットワークのブロードキャスト」を意味すると想定してくださ い。 The previous example is inefficient, because it potentially broadcasts the request on many subnets. The most efficient method, and the one we recommend, is for a host to first discover its own address (perhaps using the "Reverse ARP" protocol described in [4]), and then to send the ICMP request to 255.255.255.255: 前の例は多くのサブネットの上で潜在的に要求をブロードキャストするので、 非能率的です。最も効率的な方法と我々が勧めるものは、ホストが最初に自 分自身のアドレスを発見し(多分[4]で記述された「逆ARP」プロトコルを 使って)、それからICMP要求を255.255.255.255に送ること です: Source address: 36.40.0.123 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Format Request = A1 Code: 0 The gateway can then respond directly to the requesting host. ゲートウェイは直接要求ホストに返答ができます。 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 Format Request = A1 Code: 0 36.40.0.62 will hear the datagram, and should respond with this datagram: 36.40.0.62がデータグラムを受信し、このデータグラムを返すべきで す: Source address: 36.40.0.62 Destination address: 36.40.255.255 Protocol: ICMP = 1 Type: Address Format Reply = A2 Code: 8 Note that the gateway uses the narrowest possible broadcast to reply (i.e., sending the reply to 36.255.255.255 would mean that it is transmitted on many subnets, not just the one on which it is needed.) Even so, the overuse of broadcasts presents an unnecessary load to all hosts on the subnet, and so we recommend that use of the "anonymous" (0.0.0.0) source address be kept to a minimum. ゲートウェイが応答に最も狭い範囲のブロードキャストを使うことに注意し てください。(すなわち、応答を36.255.255.255に送ることは、 必要とされるところだけでなく、多くのサブネット上に伝達されることを意 味するでしょう)。もしそうするとブロードキャストの過剰利用はサブネッ ト上のすべてのホストに不必要な負荷を与え、それで我々は「匿名」 (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 Format Request = A1 Code: 0 36.40.0.62 should respond exactly as in the previous case. 36.40.0.62が前の場合と同じ応答をするべきです。 Notes 注記 <1> For example, some host have addresses assigned by concatenating their Class A network number with the low-order 24 bits of a 48-bit Ethernet hardware address. <1> 例えば、あるホストで、48ビットイーサネットハードウェアアドレス の下位24ビットをクラスAネットワーク番号と連結することでアドレ スを割り当てるようにします。 <2> Our discussion of Internet broadcasting is based on [6]. <2> 我々の、インターネットブロードキャストの議論は[6]に基づいています。 <3> If broadcasting is not supported, them presumably a host "knows" the address of a neighbor gateway, and should send the ICMP to that gateway. <3> もしブロードキャストがサポートされないなら、多分ホストが近隣ゲー トウェイのアドレスを「知って」、そしてそのゲートウェイにICMP を送るべきです。 <4> This is what was referred to earlier as the coexistence of transparent and explicit subnets on a single network. <4> これはひとつのネットワーク上の透過で明示的なサブネットの共存とし て以前に参照されたものです。 References 参考文献 1. D.R. Boggs, J.F. Shoch, E.A. Taft, and R.M. Metcalfe. "Pup: An Internetwork Architecture." IEEE Transactions on Communications COM-28, 4, pp612-624, April 1980. 2. David D. Clark. Names, Addresses, Ports, and Routes. RFC-814, MIT-LCS, July 1982. 3. Yogan K. Dalal and Robert M. Metcalfe. "Reverse Path Forwarding of Broadcast Packets." Comm. ACM 21, 12, pp1040-1048, December 1978. 4. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A Reverse Address Resolution Protocol. RFC-903, Stanford University, June 1984. 5. 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. 6. Jeffrey Mogul. Broadcasting Internet Datagrams. RFC-919, Stanford University, October 1984. 7. David Plummer. An Ethernet Address Resolution Protocol. RFC-826, Symbolics, September 1982. 8. Jon Postel. Internet Protocol. RFC-791, USC-ISI, September 1981. 9. Jon Postel. Internet Control Message Protocol. RFC-792, USC-ISI, September 1981.