RFC917 日本語訳
0917 Internet subnets. J.C. Mogul. October 1984. (Format: TXT=47072 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Jeffrey Mogul
Request for Comments: 917 Computer Science Department
Stanford University
October 1984
コメントを求めるワーキンググループジェフリーの要人要求をネットワークでつないでください: 917 コンピュータサイエンス部のスタンフォード大学1984年10月
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つのインターネット網をいくつかのサブネットに分割するのを選びました、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。 クリスマスChiappa、クリス・ケントとティム・マンは重要な提案を特に提供しました。
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レベルの階層構造でした: 先端は全体でcatenetを平らにします、そして、それの下のレベルは「インターネットネットワーク」の収集を平らにします、それぞれそれ自身のNetwork Numberと共に。 (私たちは、インターネットには階層的なトポロジーがありますが、アドレスの解釈が階層的であると言っていません。)
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のレベルをインターネット・アドレスの解釈に追加しています。 または、この視点では、与えられたインターネットNetworkがそうするかもしれない、()、サブネットの収集に分割されるかもしれなくなってください。
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
オリジナルの、そして、2レベルの眺めはそのネットワークがただ一つの縁としてインターネット網のホストにとって見なされるかもしれないという強い推定を運びます。 言い換えれば、ネットワークは1セットのホストが接続されている「ブラックボックス」として扱われるかもしれません。 これは当てはまります。
Mogul [Page 1]
ムガール人[1ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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.
IMPsがそのネットワークにおける特定のリンクの使用にマスクをかけるのでアルパネット。 また、それもイーサネットかリングネットワークなどのほとんどのローカル・エリア・ネットワーク(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.
- 指すポイントはリンクされます: 時々、大学構内などの「局部」は都合のよいLAN技術を使用することで接続できないくらいかけ離れている2つの位置に分けられます。 この場合、高速ポイントツーポイント接続はいくつかの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に割り当てることによって、ホストアドレス空間を仕切ってください。 (「明白なサブネット」。)
Mogul [Page 2]
ムガール人[2ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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.
それぞれのこれらのアプローチには、損失があります。 1番目はインターネット経路指定テーブルのサイズにおける爆発をもたらしても、どんな新しいか変更されたプロトコルも必要としません。 ローカルの接続性の内部の詳細に関する情報はいたる所に伝播されます、それが地方の組織の外でほとんど役に立ちませんが。 特にいくつかの現在のゲートウェイ実装には経路指定テーブルのための多くのスペースがないように、この問題を避けてうれしいでしょう。
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の収集が現れる何らかのコンベンションかプロトコルがただ一つのインターネット網であることを必要とします。 例えば、各インターネット・アドレスがAddress Resolutionプロトコル(ARP)を使用することでハードウェア・アドレスに翻訳されるところでLANでこれができます、LANの間のブリッジに非ローカルの目標を求めるARP要求を妨害させることによって。 しかしながら、LANが放送をサポートしないなら、すべてのLAN技術、特にARPプロトコルが現在使用されないところのそれらのためにこれをするのにおいて可能ではありません。 より基本的な問題はブリッジが、ホストがどの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.
このドキュメントの残りはインターネットNetworksのサブネットにアプローチを説明します。
Mogul [Page 3]
ムガール人[3ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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
Catenet
The collection of connected Internet Networks
接続インターネット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つ以上の行政上異なったネットワーク、そして/または、サブネットに接続しました。(ホストは進められるデータグラムをサブネットに送ります)。
Mogul [Page 4]
ムガール人[4ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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]に提示された分割に続いて、私たちは、サブネットが基本的にアドレシングの問題であることを観測します。 このセクションで、私たちは最初に、インターネットAddressingの解釈がサブネットをサポートするという提案について説明します。 次に、私たちはこのアドレス形式と放送との相互作用について議論します。 最終的に、私たちは、どんなアドレス解釈が与えられたネットワークで使用中であるかを発見するためにプロトコルを提示します。
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セットのサブネットに分割して、ホスト・アドレスを割り当てたがっていると仮定してください: これはどのように完了しているべきですか? インターネット・アドレスの「ローカルアドレス」部分の課題には最小量の制限があるので、いくつかのアプローチがサブネット番号を表すために提案されました:
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
さもなければ、これらのすべての体系が最も重要な分野としてのサブネット野原を置くするのにおける利点が全くあるように思えないので
Mogul [Page 5]
ムガール人[5ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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.
ローカルアドレス部分。 また、Class Cアドレスのローカルアドレス部分が非常に小さいので、Class AとClass 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>のために問題を起こすかもしれません。 言い換えれば、ネットワークがホスト・アドレスの課題から独自に「副-網で覆」われるか否かに関係なく、できるコントロールであることは役に立ちます。 どんな自己コード化体系の別の不都合も少なくとも2の要素でローカルアドレススペースを減少させるということです。
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.
自己をコード化する体系が使用されていないなら、可変幅のサブネット分野が適切であることは、明確です。 サブネットが使用中であるなら示すいくつかの1ネットワークあたりの「旗」がどのような場合でもあるに違いないので、論理演算子の代わりに整数(サブネット欄の幅)を使用する別途費用は取るにたらないです。 可変幅のサブネット分野を使用する利点は各組織がそれでローカルアドレスの比較的不十分なビットをサブネットとホスト番号に割り当てる最も良い方法を選ぶことができるということです。
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.)
<ホスト番号>分野が[8]で幅少なくとも1ビットであることのように<ネットワーク・ナンバー>分野があって、与えられたネットワークに、サブネット番号>がさばく<の幅が一定であるところ。 さらなる構造は全くサブネット番号>か<ホスト番号>がさばく<に必要ではありません。 サブネット番号>がさばく<の幅がゼロであるなら、ネットワークは「副-網で覆」われません。(すなわち、[8]の解釈は使用されています。)
Mogul [Page 6]
ムガール人[6ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
For example, on a Class A network with an eight bit wide subnet
field, an address is broken down like this:
例えば、幅8ビットのサブネット分野があるClass 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| ネットワーク| サブネット| ホスト番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)))
ipの_のネットの_番号(私の_ip_addr)ipの_のネットの_番号(packet.ip_dest)=THENが_局所的(パケット、packet.ip_dest)に_パケットを送るなら、ELSEは_局所的に_パケットを送ります。(パケット、(ipの_のネットの_番号(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.
もうひとつの32ビットの量を保存するのがサブネットをサポートするのが私の_ip_マスクを呼んだのが必要です。 これはビットが始まってIPネットワーク・ナンバーに対応する分野に少しマスクをかけることです、そして、追加ビットは、サブネットナンバーフィールドに対応しながら、セットしました。 例えば、8ビットの広いサブネット分野を使用するマスクをClass Aに、255.255が.0であったなら.0にネットワークでつないでください。
The code then becomes:
次に、コードはなります:
Mogul [Page 7]
ムガール人[7ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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)))
bitwiseする、_と(packet.ip_dest、私の_のip_マスク)=は_をbitwiseして、(私の_ip_addr、私の_ip_マスク)THENは局所的にELSEが_局所的に_パケットを送る(パケット、packet.ip_dest)を_パケット_に送ります。(パケット、ゲートウェイ_、(_と(packet.ip_dest、私の_ip_マスク)をbitwiseします))
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.
それが変更するのに必要であるかもしれない、「同様に、比較を実行するための」 機能へのゲートウェイ_。
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.
多重連結のホストをサポートするなら、1インタフェースあたり1個のベースに「私の_ip_addr」と「私の_ip_マスク」量を保つためにコードを変えることができます。 そして、各インタフェースに条件付きの式を評価しなければなりません。
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.
サブネットが使用されているとき、状況はわずかに複雑になります。 まず最初に、可能性は現在、特定のサブネットに放送するのを存在させます。 2番目に、サブネット化したネットワークのすべてのホストに放送するのは追加メカニズムを必要とします。 [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.
すべてのものの送付先アドレス、(255.255 .255 aがローカルの物理ネットワークで放送されたように.255は)aデータグラムを送らせます。 どんなゲートウェイもそれを進めてはいけません。
Mogul [Page 8]
ムガール人[8ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
Specific network
特定のネットワーク
The destination address contains a valid network number; the
local address part is all ones (e.g., 36.255.255.255).
送付先アドレスは有効なネットワーク・ナンバーを含んでいます。 ローカルアドレス部分がすべてものである、(例えば、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).
送付先アドレスは有効なネットワーク・ナンバーと有効なサブネット番号を含んでいます。 ホスト分野がすべてものである、(例えば、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つの要素はただ一つの操作が送信元ホストにある状態でサブネット化したネットワークのすべてのホストに放送するのが可能であるということです。 放送するのは可能ではありません、ワンステップで、彼らが異なったネットワークにいるなら同じセットのホストに。
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の上でbootloadedされるディスクレスワークステーションのますます一般的なケースにおいて、どちらのハード・ワイヤードソリューションも満足できません。 代わりに、より良いメソッドはほとんどの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]を広げるよう提案します、「情報要求」と「情報回答」ICMPメッセージに類似しています。 これらはAppendix Iで詳細に説明されます。
The intended use of these new ICMPs is that a host, when booting,
ブートするとき、これらの新しいICMPsの意図している使用はそのaホストです。
Mogul [Page 9]
ムガール人[9ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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.
「アドレス形式要求」メッセージ<3>を放送してください。 このメッセージを受け取るゲートウェイ(または、ゲートウェイの代わりに行動しているホスト)は「アドレス形式回答」で応じます。 それのホストがそれを送った要求における指示が全くなければ(すなわち、IP Source Addressはゼロです)、また、回答は放送されます。 要求ホストは、応答を聞いて、それからサブネット分野の幅を測定するでしょう。
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が同じネットワークの一部であることを決定できて(LANの1つにおける応答から)、その結果、同じサブネット欄の幅を持ってはいけません。
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.
1番目と2番目の状況は、サブネット欄の幅がゼロであることを含意します。 3番目の状況に、固有値が何であるかを決定する方法が全くありません。 その結果、最も安全な選択はゼロです。 これは後で間違っていると判明するかもしれませんが、それはそうでなければ成功するトランスミッションを防がないでしょう。 ホストが間違った選択から回復するのは、可能です: ゲートウェイが来るとき、「アドレス形式回答」を放送するべきです。 ホストが推測と意見を異にするそのようなメッセージを受け取るとき、それは容認された値に従わせるデータ構造を調整するべきです。 どんなホストもゲートウェイも「推測された」値に基づく「アドレス形式回答」を送るはずがありません。
Mogul [Page 10]
ムガール人[10ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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.
最終的に、ホストが全くサブネット欄の幅を発見するのにこのICMPプロトコルを使用する必要はないことに注意してください。 非揮発性記憶装置をもっているホストが記憶された情報を使用するのは、完全に妥当です。
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 Host Redirectメッセージを当てにすることによって、この区別(事実上、すべてのルーティング選択を無視する)を無視できます。 しかしながら、これがゲートウェイかaのための効率的なメソッドでない、マルチ、家へ帰り、ホスト、a再直接ので、aの貧乏人のための化粧がルートの選択に頭文字をつけませんように。 そのようなホストはルーティング情報交換プロトコルを使用するべきですが、それはこのドキュメントの範囲を超えています。 どのような場合でも、サブネットが使用されてさえいないとき、問題は起こります。
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つを見つけるには、ゲートウェイを近所付き合いさせてください。 一方、これへの基本的な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>があるとき変更なしでいくつかの既存の実装を使用するのは可能です。 これが働くように、そのような実装はそうしなければなりません:
Mogul [Page 11]
ムガール人[11ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
- 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].
- Address Resolutionプロトコル(ARP)、そのような[7]を使用してください。
- 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.
この場合1つがサブネットゲートウェイで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つの問題はオリジナルのゲートウェイがダウンするなら、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.
N.B.: ARPベースのサブネッティングの使用は放送の使用で複雑にされます。 ARPサーバ[7]は目標が放送演説である要求に決して応じるべきではありません。 そのような要求はそういうもの、それを光栄に思うのがほぼ確実に推進輪に通じるように放送演説を認めないホストから来ることができるだけです。 物理ネットワークのこのアドレスが放送であると認めないそのようなNホストがいれば、生きるTimeと共にTについて送られたパケットは潜在的にT**Nへの上昇を偽りに与えるかもしれません。再放送します。
Mogul [Page 12]
ムガール人[12ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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年以来の数個のExperimental Ethernets[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だけゲートウェイはそれらのPup経路指定テーブルに応じてインターネットデータグラムを進めるように変更されました。 彼らは、そうでなければ、インターネットパケットを理解でないのを持って、事実上、インターネット・ヘッダーの生きるTime分野を調整しませんでした。 推進輪を引き起こしたバグが現れていないので、これは許容できるように思えます。 そして、インターネット・ホスト、マルチ、家へ帰り、その結果、ゲートウェイが生きるTime分野を調整するとき、役立つことができます。 すべて、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.
10Mbit Ethernetsが加えられたとき、ゲートウェイは以前のセクションで説明されたARPベースの体系を使用するように変更されました。 これは、変更されていないホストが10Mbit Ethernetsで使用されるのを許容しました。
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.
1982年前半以来IPサブネットは使用中です。 現在、およそ330人のホスト、18サブネット、および同様の数の使用中のサブネットゲートウェイがあります。 かつてのPup唯一のゲートウェイが本当のインターネット・ゲートウェイになるように変換されます、そして、インターネットを利用するルーティング交換プロトコルは紹介されるでしょう、そして、Pupは段階的に廃止されるでしょう。
Mogul [Page 13]
ムガール人[13ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
4.2. MIT
4.2. MIT
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サイトでした。 以来、ネットワーク・ナンバーがネットワーク・ナンバーが利用可能なアドレス空間の良い部分に使用したそれ自身のIPをMITの各リンクに割り当てたためにクラスに分割される前にこれは起こりました。 MITは、1つのIPネットワーク・ナンバーを使用して、24ビットの「休息」分野自体を管理すると決めました、それを3つの8ビットの分野に分割することによって。 「サブネット」、「」 ゼロが「ホスト」であったに違いないなら、予約されます。 既にMITでの使用でのCHAOSプロトコルが8ビットのサブネットナンバーフィールドを使用したので、両方のプロトコルの同じサブネット番号を各リンクに割り当てるのは可能でした。 最も利用可能なローカルのネットのハードウェアがその時8つのビット・アドレスを使用して以来、IPホスト分野は8ビットに設定されました、CHAOSプロトコルのように。 未来の数ビットを予約するのが賢明であると感じられました。
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サブネットゲートウェイの間のダイナミックルーティングプロトコルを使用することでした。 そのようないくつかのプロトコルが討議されましたが、だれも、1つを実装するのを苦しめていません。 スタティックルーティングテーブルはまだ使用されています。 この変更はすぐ、最終的に行われそうでしょう。
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がソフトウェアであることを意味した問題を解決するのは、「副-網で覆」われた環境(ホストIPソフトウェアにおける最少の変化に通じた操作のモデルが身体検査されたMIT)で働くために変更を必要としました。 これはIPゲートウェイがNetwork RedirectsよりむしろICMP Host Redirectsを送るモデルに通じました。 すべての内部のMIT IPゲートウェイが現在、そうします。 ホストと共に、それは、基礎、この1ホストあたり1つの獣皮に関する非ローカルのコミュニケーションのための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),
MITには、ただ一つの「承認された」プロトコルに近づくどんな即座の計画もありません。 これは、一部地方自治の度合いへの支払われるべきものとインストールされたソフトウェアの量であり、一部ただ一つの際立った業界基準の不足にそうです。 むしろ、取られたアプローチは、1セットの物理的なリンクとパケット交換機を提供して、ただ一つのセットのリンクの上にいくつかの「仮想」のプロトコルネットを層にすることです。 MITには、交換するトライのいくつかの悪い経験が別のものでプロトコルと包装1プロトコルの間に情報を発送しながら、ありました。 一般的方法は基本のハードウェアを共有するのを除いて、厳密にプロトコルを切り離し続けることです。 サブネット構造を隠すのにARPを使用するのは賛成していた状態でそれほど多くないです。 これがアドレス解決操作を積みすぎると感じられます。 複雑なシステム(すなわち、輪、および異形リンク速度がある1)で
Mogul [Page 14]
ムガール人[14ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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.
より洗練された情報交換がゲートウェイの間で必要でしょう。 これを明白なメカニズム(しかし、ホストから隔離されたもの)にするのは最も良いと感じられました。
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.
Class Bが現在ネットワークでつなぐ米カーネギーメロン大学用途は物理的なサブネット(2 3Mbit Experimental Ethernets、7 10Mbit Ethernets、および2個のProNetリング)を11に分割しました。 ホスト番号は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キャッシュに相談します。 その結果、ブリッジは、透過的にheterogenousマルチケーブル環境に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).
米カーネギーメロン大学で3Mbitイーサネットと10MbのproNETリングを支える実装がRFC-826 ARP(IPアドレスの4番目の八重奏として単に8ビットのハードウェア・アドレスを使用などなどの接合している何らかのマッピングの代わりに)を使用します。
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
米カーネギーメロン大学のネットワークはそれらのCS/ロードアイランドの中の中心に置かれた比較的小さくて、単独で関連している構成から成長しそうです。
Mogul [Page 15]
ムガール人[15ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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.
ケーブルの間には、5000-10000人のホストと余分な接続があるキャンパス全体のイントラ部門の構成への施設。 ARPベースのブリッジ体系がこのサイズに比例しないのが、可能であり、明白なサブネットのシステムが必要であるかもしれません。 しかしながら、中期目標は変更されていない実在(特にイーサネットが基礎づけた10Mb)のIP実装をインポートすることができる環境です。 ホスト見え透いた(その結果、ARPベースの)ルーティングメカニズムができるだけ長い状態で意図は残ることになっています。 米カーネギーメロン大学はサブネットがIP規格の一部になってもそれらが広く実装されないことを心配しています。 これは米カーネギーメロン大学での彼らの使用への重大な障害です。
Mogul [Page 16]
ムガール人[16ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、Code分野に挿入されたサブネット欄の幅に変化しました、そして、チェックサムは再計算されました。 しかしながら、要求メッセージのソースアドレスがゼロであるなら、応答メッセージのための送付先アドレスは放送を指示するべきです。
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
チェックサムが16ビットの1の補数である、人のもの
Mogul [Page 17]
ムガール人[17ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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 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).
アドレス形式要求がCode分野と共にそれを返すべきであるゲートウェイ受信はIPアドレスのデータグラムが扱われたネットワークのSubnet番号のビットの数にセットしました。 要求が放送であったなら、送信先ネットワークは「このネットワーク」です。 Subnet欄の幅は0から(31--N)に来ているかもしれません。そこでは、NがIPのネットのナンバーフィールド(すなわち、8、16、または24)のビット幅です。
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を受け取るかもしれません。
Mogul [Page 18]
ムガール人[18ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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.123 送付先アドレス: 36.255.255.255 議定書を作ってください: ICMP=1はタイプされます: アドレス形式要求はA1コードと等しいです: 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
ソースアドレス: 36.40.0.62 送付先アドレス: 36.40.0.123 議定書を作ってください: ICMP=1はタイプされます: アドレス形式回答はA2コードと等しいです: 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:
潜在的に多くのサブネットに関する要求を放送するので、前の例は効率が悪いです。 最も効率的なメソッド、および私たちが推薦するのはそれ自身のアドレスが最初にホストが発見されることです。(恐らく「逆のARP」プロトコルを使用すると[4])が中で説明された、そして、発信するために、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
ソースアドレス: 36.40.0.123 送付先アドレス: 255.255.255.255 議定書を作ってください: ICMP=1はタイプされます: アドレス形式要求はA1コードと等しいです: 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 ディスクレスワークステーションであり、それ自身のホスト番号さえ知りません。 それは以下のデータグラムを送るかもしれません:
Mogul [Page 19]
ムガール人[19ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
Source address: 0.0.0.0
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Format Request = A1
Code: 0
ソースアドレス: 0.0.0.0 送付先アドレス: 255.255.255.255 議定書を作ってください: ICMP=1はタイプされます: アドレス形式要求はA1コードと等しいです: 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
ソースアドレス: 36.40.0.62 送付先アドレス: 36.40.255.255 議定書を作ってください: ICMP=1はタイプされます: アドレス形式回答はA2コードと等しいです: 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.
すなわち、ゲートウェイが返答するのに可能な限り狭い放送を使用することに注意してください、(それが.255が意味する.255ですが、多くのサブネット(それが必要であるものであるだけではない)で伝えられて、回答を36.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.123 送付先アドレス: 36.40.0.62 議定書を作ってください: ICMP=1はタイプされます: アドレス形式要求はA1コードと等しいです: 0
36.40.0.62 should respond exactly as in the previous case.
36.40.0.62 ちょうど先の事件のように応じるべきです。
Mogul [Page 20]
ムガール人[20ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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ビットでそれらのClass 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>、これは、より早くただ一つのネットワークにおける透明で明白なサブネットの共存と呼ばれたことです。
Mogul [Page 21]
ムガール人[21ページ]
RFC 917 October 1984 Internet Subnets
RFC917 1984年10月のインターネットサブネット
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.
1. D.R.ボッグズ、J.F.Shoch、E.A.タフト、およびR.M.メトカルフェ。 「産んでください」 「インターネットワーク構造。」 1980年4月のCommunications COM-28、4、pp612-624の上のIEEE Transactions。
2. David D. Clark. Names, Addresses, Ports, and Routes. RFC-814,
MIT-LCS, July 1982.
2. デヴィッド・D.クラーク。 名前、アドレス、ポート、およびルート。 RFC-814、MIT-LCS、1982年7月。
3. Yogan K. Dalal and Robert M. Metcalfe. "Reverse Path Forwarding
of Broadcast Packets." Comm. ACM 21, 12, pp1040-1048, December
1978.
3. Yogan K.DalalとロバートM.メトカルフェ。 「放送パケットの経路推進を逆にしてください。」 Comm。 ACM21、12、pp1040-1048、1978年12月。
4. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A
Reverse Address Resolution Protocol. RFC-903, Stanford
University, June 1984.
4. ロスフィンリースン、ティモシー・マン、ジェフリー・ムガール人、マーヴィンTheimer。 逆アドレス解決プロトコル。 RFC-903、スタンフォード大学、1984年6月。
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.
5. R.M.メトカルフェとD.R.ボッグズ。 「イーサネット:」 「ローカル・コンピュータ・ネットワークのための分配されたパケット交換。」 Comm。 ACM19、7、pp395-404、1976年7月。 また、CSL-75-7(ゼロックスパロアルト研究センター)はCSL-80-2で翻刻しました。
6. Jeffrey Mogul. Broadcasting Internet Datagrams. RFC-919, Stanford
University, October 1984.
6. ジェフリー・ムガール人。 1984年10月にインターネットデータグラムRFC-919、スタンフォード大学を放送します。
7. David Plummer. An Ethernet Address Resolution Protocol. RFC-826,
Symbolics, September 1982.
7. デヴィッド・プラマー。 イーサネットは解決プロトコルを記述します。 RFC-826、信条学、1982年9月。
8. Jon Postel. Internet Protocol. RFC-791, USC-ISI, September 1981.
8. ジョン・ポステル。 インターネットプロトコル。 RFC-791、USC-ISI、1981年9月。
9. Jon Postel. Internet Control Message Protocol. RFC-792, USC-ISI,
September 1981.
9. ジョン・ポステル。 インターネット・コントロール・メッセージ・プロトコル。 RFC-792、USC-ISI、1981年9月。
Mogul [Page 22]
ムガール人[22ページ]
一覧
スポンサーリンク
