RFC925 日本語訳
0925 Multi-LAN address resolution. J. Postel. October 1984. (Format: TXT=31137 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Postel
Request for Comments: 925 ISI
October 1984
コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 925 ISI1984年10月
Multi-LAN Address Resolution
マルチLANアドレス解決
STATUS OF THIS MEMO
このメモの状態
This memo is prompted by RFC-917 by Jeffery Mogul on "Internet Subnets". In that memo, Mogul makes a case for the use of "explicit subnets" in a multi-LAN environment. In this memo, I attempt to make a case for "transparent subnets". 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-917によってうながされます。 そのメモでは、ムガール人はマルチLAN環境における「明白なサブネット」の使用のために主張します。 このメモでは、私は、「透明なサブネット」のために主張するのを試みます。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。
INTRODUCTION
序論
The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. One proposal is to use "explicit subnets" [1]. The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network. In this note I urge another approach: the use of "transparent subnets" supported by a multi-LAN extension of the Address Resolution Protocol [2].
1つのインターネット網として1セットのローカル・エリア・ネットワーク(LAN)を扱うという問題は何らかの関心と関心を生みました。 サイトの中の各LANに異なったインターネットネットワーク・ナンバーを与えるのは不適当です。 サイトの外に人々、ゲートウェイ、およびホストからインタコネクトの詳細をサイトの中のLANの間に隠すのは望ましいです。 全くどのようにそれをするかというさえ質問は起こります。 1つの提案は「明白なサブネット」[1]を使用することです。 明白なサブネット計画はインターネットが1つのネットワークの中でLANを管理するという問題にネットワークを経営するのに使用するメカニズムを再帰的に適用するという要求です。 この注意では、私は別のアプローチを主張します: Address Resolutionプロトコル[2]のマルチLAN拡大で支持された「透明なサブネット」の使用。
OVERVIEW
概観
To quickly review the Address Resolution Protocol (ARP). Each host on a broadcast LAN knows both its own physical hardware address (HA) on the LAN and its own Internet Address (IA). When Host-A is given the IA of Host-B and told to send a datagram to it, Host-A must find the HA that corresponds to Host-B's IA. To do this Host-A forms an ARP packet that contains its own HA and IA and the IA of the destination host (Host-B). Host-A broadcasts this ARP packet. The hosts that receive this ARP packet check to see if they are destination sought. If so, they (it should be only Host-B) send a reply specifically addressed to the originator of the query (Host-A) and supplying the HA that was needed. The Host-A now has both the HA and the IA of the destination (Host-B). The Host-A adds this information to a local cache for future use.
すばやく、Address Resolutionプロトコル(ARP)を見直すために。 放送LANの各ホストはLANに関するそれ自身の物理的なハードウェア・アドレス(HA)とそれ自身のインターネットAddress(アイオワ)の両方を知っています。 Host-絶対に必要なものによって、いつHost-AをHost-Bのアイオワを与えて、データグラムをそれに送るように言うかHost-ビーズアイオワに対応するHAがわかります。 このHost-Aをするのはあて先ホスト(Bを接待している)のそれ自身のHA、アイオワ、およびアイオワを含むARPパケットを形成します。 ホストAはこのARPパケットを放送します。 彼らが目的地であるかどうか確認するためにこのARPパケットチェックを受けるホストは探しました。 そして、そうだとすれば、彼ら(それはHost-Bであるにすぎないべきである)が明確に質問の創始者に記述された回答を送る、(ホストa)、それをHAに供給するのが必要でした。 Host-Aには、現在、HAと目的地(Bを接待している)のアイオワの両方があります。 Host-Aは今後の使用のためにローカルなキャッシュにこの情報を加えます。
Note: The ARP is actually more general purpose than this brief
sketch indicates.
以下に注意してください。 ARPは実際にこの簡潔なスケッチが示すより汎用です。
Postel [Page 1]
ポステル[1ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
The idea in this memo is to extend the ARP to work in an environment of multiple interconnected LANs.
このメモによる考えは複数のインタコネクトされたLANの環境で働くためにARPを広げることです。
To see how this could work let us imagine a "magic box" (BOX) that is connected as if it were an ordinary host to two (or more) LANs.
これがどう働くことができたかを見るために、「魔法の箱」がまるでそれが普通のホストであるかのように接続された(BOX)であると2つ(さらに)のLANまで想像しましょう。
Hosts continue to behave exactly as they do with the basic ARP.
ホストは、ちょうど彼らが基本的なARPを処理するように振る舞い続けています。
When an ARP query is broadcast by any host the BOX reads it (as do all the hosts on that LAN). In addition to checking whether it is the host sought (and replying if it is), the BOX checks its cache of IA:HA address mappings in the cache that it keeps for each LAN it is attached to.
ARP質問がどんなホストによっても放送されるとき、BOXはそれ(そのLANのすべてのホストのような)を読みます。 それが探されたホスト(それが返答するなら返答して)であるかどうかチェックすることに加えて、BOXはアイオワのキャッシュをチェックします: それが付けられている各LANのために保つキャッシュにおけるHAアドレス・マッピング。
Case 1: If the mapping for the host is found in the cache for the
LAN that the query came from, the BOX does not respond (letting
the sought host respond for itself).
ケース1: ホストへのマッピングが質問が来たLANに関してキャッシュで見つけられるなら、BOXは応じません(探されたホストをそれ自体のために応じさせて)。
Case 2: If the mapping for the host is found in the cache for a
different LAN than the query came from, the BOX sends a reply
giving its own HA on the LAN the query came from. The BOX acts as
an agent for the destination host.
ケース2: ホストへのマッピングが異なったLANに関してキャッシュで見つけられるなら、BOXは、質問が来たLANでそれ自身のHAに与えながら、質問が来たより返信します。 BOXはあて先ホストのために手先になります。
Case 3: If the mapping is not found in any of the caches then, the
BOX must try to find out the the address, and then respond as in
case 1 or 2.
ケース3: マッピングがその時キャッシュのいずれでも見つけられないなら、BOXはケース1か2のようにアドレスを見つけようとして、こたえなければなりません。
In case 3, the BOX has to do some magic.
場合3では、BOXは何らかの魔法をしなければなりません。
The BOX keeps a search list of sought hosts. Each entry
includes the IA of the host sought, the interface the ARP was
received on, and the source addresses of the original request.
When case 3 occurs, the search list is checked. If the sought
host is already listed the search is terminated, if not the
search is propagated.
BOXは探されたホストの検索リストを保ちます。 各エントリーは探されたホストのアイオワを含んでいます、ARPを受け取って、情報筋が記述するオリジナルの要求のインタフェース。 ケース3が現れるとき、検索リストはチェックされます。 探されたホストが既に記載されるなら、検索が終えられるか、または検索は伝播されます。
To propagate the search, an entry is first made on the search
list, then the BOX composes and sends an ARP packet on each of
its interfaces except the interface the instigating ARP packet
was received on. If a reply is received, the information is
entered into the appropriate cache, the entry is deleted from
the search list and a response to the search instigating ARP is
made as in case 1 or 2. If no reply is received, give up and
do nothing -- no response is sent to the instigating host (the
entry stays on the search list).
最初に、検索を伝播するために、検索リストでエントリーをして、次に、扇動しているARPパケットが受け取られたインタフェースを除いて、BOXはARPパケットをそれぞれのインタフェースに構成して、送ります。 回答が受け取られているなら、適切なキャッシュに情報を入力します、そして、検索リストからエントリーを削除します、そして、ケース1か2のようにARPを扇動する検索への応答をします。 どんな回答も受け取られていて、何もあきらめて、しないでください--応答を全く扇動に送らないということでないなら、(検索リストにおけるエントリー滞在)を接待してください。
Postel [Page 2]
ポステル[2ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
To terminate the search, give up and do nothing -- no response
is sent to the instigating host (the entry stays on the search
list).
検索を終えるために、何もあきらめて、しないでください--応答を全く扇動しているホストに送りません(エントリーは検索リストに滞在しています)。
The entries in the caches and the search list must time out.
キャッシュと検索リストにおけるエントリーはタイムアウトがそうしなければなりません。
For every ARP request that is received, the BOX must also put the sending host's IA:HA address mapping into the cache for the LAN it was received on.
また、あらゆる受信されたARP要求のために、BOXは送付ホストのアイオワを置かなければなりません: それが受け取られたLANのためのキャッシュへのHAアドレス・マッピング。
THE MULTI-LAN ADDRESS RESOLUTION PROTOCOL
マルチLANアドレス解決プロトコル
The plan is to use ARP just as it is. The new element is the "magic
box" ("ARP-based bridge") that relays the ARP request into
neighboring LANs and acts as an agent for relaying datagrams to hosts
on other LANs.
プランはちょうどそれのようにARPを使用することです。 新しい要素は隣接しているLANにARP要求をリレーして、データグラムをリレーするために他のLANでホストに手先になる「魔法の箱」(「ARPベースの橋」)です。
The Details
詳細
Hosts continue to behave exactly as they do with the basic ARP.
ホストは、ちょうど彼らが基本的なARPを処理するように振る舞い続けています。
The LANs are connected together by BOXes (computers that are
attached to two or more LANs exactly as hosts are attached to
LANs). The BOXes implement the following procedure.
LANはBOXes(ホストがちょうどLANに付けられているように2つ以上のLANに取り付けられるコンピュータ)によって一緒に接続されます。 BOXesは以下の手順を実行します。
Each BOX keeps a table for each LAN it is connected to (or for
each LAN interface). Entries in these tables time out, so these
tables are caches of recent information. The entries in these
caches are the IA:HA address pairs for that LAN.
各BOXはそれが関連づけられる各LAN(またはそれぞれのLANインタフェースに)のためにテーブルを保ちます。 これらのエントリーがタイムアウトをテーブルの上に置くので、これらのテーブルは最近の情報のキャッシュです。 これらのキャッシュにおけるエントリーはアイオワです: そのLANのためのHAアドレス組。
When an ARP query is broadcast by any host the BOX reads it (as do
all the hosts on that LAN). In addition to checking to see if it
is the host sought (and replying if it is), the BOX checks its
cache of IA:HA address mappings in the table it keeps for each LAN
it is attached to.
ARP質問がどんなホストによっても放送されるとき、BOXはそれ(そのLANのすべてのホストのような)を読みます。 それが探されたホスト(それが返答するなら返答して)であるかどうか確認するためにチェックすることに加えて、BOXはアイオワのキャッシュをチェックします: それが付けられている各LANのために保つテーブルのHAアドレス・マッピング。
Case 1: If the mapping for the host is found in the cache for
the LAN that the query came from, the BOX does not respond
(letting the sought host respond for itself). The time out on
this entry is not reinitialized.
ケース1: ホストへのマッピングが質問が来たLANに関してキャッシュで見つけられるなら、BOXは応じません(探されたホストをそれ自体のために応じさせて)。 このエントリーでのタイムアウトは再初期化されません。
Case 2: If the mapping for the host is found in the cache for a
different LAN than the query came from, the BOX sends a reply
giving its own HA on the LAN the query came from. The time out
on this entry is not reinitialized.
ケース2: ホストへのマッピングが異なったLANに関してキャッシュで見つけられるなら、BOXは、質問が来たLANでそれ自身のHAに与えながら、質問が来たより返信します。 このエントリーでのタイムアウトは再初期化されません。
In this case the BOX is indicating that it will act as an
この場合、BOXはそれが機能する表示です。
Postel [Page 3]
ポステル[3ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
agent for the destination host. When an IP datagram arrives
at the BOX, the BOX must attempt to forward it using the
information in its address mapping caches.
あて先ホストのためのエージェント。 IPデータグラムがBOXに届くと、BOXは、アドレス・マッピングキャッシュに情報を使用することでそれを進めるのを試みなければなりません。
Case 3: If the mapping is not found in any of the caches, then
the BOX must try to find out the the address, and then respond
as in case 1 or 2. In this case, the BOX has to do some magic.
ケース3: マッピングがキャッシュのいずれでも見つけられないなら、BOXはケース1か2のようにアドレスを見つけようとして、こたえなければなりません。 この場合、BOXは何らかの魔法をしなければなりません。
The BOX keeps a search list of sought (but not yet found)
hosts. Each entry includes the IA of the host sought, the
interface the ARP was received on, and the source addresses
of the original request.
BOXは探されて(まだ見つけられていません)のホストの検索リストを保ちます。 各エントリーは探されたホストのアイオワを含んでいます、ARPを受け取って、情報筋が記述するオリジナルの要求のインタフェース。
When case 3 occurs, the search list is checked. If the
sought host is already listed the search is terminated, if
not the search is propagated.
ケース3が現れるとき、検索リストはチェックされます。 探されたホストが既に記載されるなら、検索が終えられるか、または検索は伝播されます。
To propagate the search, an entry is first made on the
search list, then the BOX composes and sends an ARP packet
on each of its interfaces. These ARP requests contain the
IA and HA of the BOX and the IA of the sought host, and
request the HA of the sought host. If a reply is received
to the ARP request, the information is entered into the
appropriate cache, the entry is deleted from the search list
and a response to the search instigating ARP requests is
made as in case 1 or 2 above. If no reply is received, give
up and do nothing -- no response is sent to the instigating
host (the entry stays on the search list).
最初に、検索を伝播するために、検索リストでエントリーをして、次に、BOXはARPパケットをそれぞれのインタフェースに構成して、送ります。 これらのARP要求は、BOXのアイオワとHAと探されたホストのアイオワを含んでいて、探されたホストのHAを要求します。 ARP要求に回答を受け取るなら、適切なキャッシュに情報を入力して、検索リストとARP要求を扇動するのがケース1のようにされる検索への応答か上記の2からエントリーを削除します。 どんな回答も受け取られていて、何もあきらめて、しないでください--応答を全く扇動に送らないということでないなら、(検索リストにおけるエントリー滞在)を接待してください。
Note that the BOX must make a reasonable effort with its
ARP requests, if it is normal for ordinary hosts to
retry ARP requests five times, then a BOX must also retry
it's ARP requests five times.
BOXがARP要求で妥当な努力をしなければならないというメモ、正常であるなら、普通のホストが次に、また、5回、BOXが再試行しなければならないというARP要求を再試行するように、それは5回ARP要求です。
To terminate the search, give up and do nothing -- no
response is sent to the instigating host (the entry stays on
the search list).
検索を終えるために、何もあきらめて、しないでください--応答を全く扇動しているホストに送りません(エントリーは検索リストに滞在しています)。
There is no negative feedback from an ARP request, so there
is no way to decide that a search was unsuccessful except by
means of a time out.
タイムアウト以外に、検索が失敗していたと決める方法が全くなくて、ARP要求からの負のフィードバックが全くありません。
For every ARP request that is received, the BOX must also put the
sending hosts IA:HA address mapping into the cache for the LAN it
was received on.
また、あらゆる受信されたARP要求のために、BOXは送付ホストアイオワを置かなければなりません: それが受け取られたLANのためのキャッシュへのHAアドレス・マッピング。
The entries in the caches and the search list must time out.
キャッシュと検索リストにおけるエントリーはタイムアウトがそうしなければなりません。
Postel [Page 4]
ポステル[4ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
The search list must be kept and the termination rule followed to
avoid an infinite relaying of an ARP request for a host that does
not respond. Once a host is listed in the search list, ARP
requests will not be relayed. If a host that is down (or
otherwise not responding to ARP requests), comes up (or otherwise
begins responding to ARP requests) it will still not become
available to hosts in other LANs until the search list entry times
out.
検索リストを保たなければなりませんでした、そして、終了規則は、応じないホストを求めるARP要求をリレーする無限を避けるために従いました。 ホストが検索リストにいったん記載されると、ARP要求はリレーされないでしょう。 それでも、下がって(別の方法でARP要求に応じないで)、それを来る(または、そうでなければ、ARP要求に応じ始めます)ホストが他のLANでホストにとって利用可能に検索までならないなら、外にエントリー時間を記載してください。
There are two approaches to this problem: first, to have a
relatively short time out on the search list entries; or
second, to have the BOX periodically send ARPs for each entry
on the search list.
この問題への2つのアプローチがあります: まず最初に、比較的短いタイムアウトを検索に持つには、エントリーを記載してください。 または、定期的にBOXを持つために、2番目に、検索リストで各エントリーにARPsを送ってください。
There are several time outs involved in this scheme.
この計画にかかわる数回のタイムアウトがあります。
First, the hosts try to get the address resolved using ARP.
They may actually make several attempts before giving up if a
host is not responding. One must have an good estimate of the
length of time that a host may keep trying. Call this time T1.
まず最初に、ホストは、ARPを使用することでアドレスを決議させていようとします。 彼らはホストが応じていないならあきらめる前に、実際に数個試みるかもしれません。 ホストが試み続けるかもしれない時間の長さの良い見積りがなければなりません。 T1に今回に電話をしてください。
Second, there is the time that an entry stays on the search
list, or the time between BOX generated ARPs to resolve these
addresses. Call this time T2.
2番目に、エントリーが検索リスト、またはこれらのアドレスを決議するBOXの発生しているARPsの間の時に滞在する時間があります。 T2に今回に電話をしてください。
Note that this time (T2) must be greater than the sum of the
T1s for the longest loop of LANs.
今回(T2)がT1sの合計よりLANの最も長い輪にすばらしいに違いないことに注意してください。
Third, there is the time that entries stay in the cache for
each LAN. Call this time T3.
3番目に、エントリーが各LANのためにキャッシュで滞在する時間があります。 T3に今回に電話をしてください。
The relationship must be T1 < T2 < T3.
関係はT1<T2<T3であるに違いありません。
One suggestion is that T1 be less than one minute, T2 be ten
minutes, and T3 be one hour.
10分と、T3になってください。T2、1つの提案がT1が1分未満であるということである、1時間になってください。
If the environment is very stable, making T3 longer will result
in fewer searches (less overhead in ARP traffic). If the
environment is very dynamic making T3 shorter will result in
more rapid adaptation to the changes.
環境が非常に安定していると、T3をより長くすると、より少ない検索(ARP交通における、より少ないオーバーヘッド)がもたらされるでしょう。 環境が非常にダイナミックであるなら、T3をより短くすると、変化への、より急速な適合はもたらされるでしょう。
Another possibility is to restart the timer on the cache
entries each time they are referenced, and have a small value
for T3. This would result in entries that are frequently used
staying in the cache, but infrequently used information being
discarded quickly. Unfortunately there is no necessary
relationship between frequency of use and correctness. This
別の可能性は、それらが参照をつけられるたびにキャッシュエントリーのときにタイマを再開して、T3のために小さい値を持つことです。 これは急速に捨てられて、キャッシュ、しかし、まれに使用された情報に滞在しながら頻繁に使用されるエントリーをもたらすでしょう。 残念ながら、使用と正当性の頻度の間には、どんな必要な関係もありません。 これ
Postel [Page 5]
ポステル[5ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
method could result in an out-of-date entry persisting in a
cache for a very long time if ARP requests for that address
mapping were received at just less than the time out period.
方法はタイムアウトの期間まさしく以下にそのアドレス・マッピングに関するARP要求を受け取ったなら非常に長い時間キャッシュに固執する時代遅れなエントリーをもたらすかもしれません。
When handling regular datagrams, the BOXes must decrement the IP
datagram Time-To-Live field (TTL) and update the IP header check
sum. If the TTL becomes zero the datagram is discarded (not
forwarded).
通常のデータグラムを扱うとき、BOXesはIPデータグラム生きるTime分野(TTL)を減少させて、IPヘッダーチェックサムをアップデートしなければなりません。 TTLがゼロになるなら、データグラムは捨てられます(進められません)。
ARP, as currently defined, will take the most recent information
as the best and most up-to-date. In a complicated multi-LAN
environment where there are loops in the connectivity it is likely
that one will get two (or more) responses to an ARP request for a
host on some other LAN. It is probable that the first response
will be from the BOX that is the most efficient path.
現在定義されているとしてのARPは最も良く最も最新であるとして最新の情報をみなすでしょう。 接続性には輪がある複雑なマルチLAN環境では、1つはある他のLANのホストを求めるARP要求への2つ(さらに)の応答を得そうでしょう。 最初の応答が最も効率的な経路であるBOXから来ているのは、ありえそうです。
The one change to the host implementation of ARP that is suggested
here is to prevent later responses from replacing the mapping
recorded from the first response.
ここに示されるARPのホスト導入への1回の変化が、後で応答が最初の応答から記録されたマッピングに取って代わるのを防ぐことになっています。
Potential Problems
潜在的な問題
Bad Cache Entries
悪いキャッシュエントリー
If some wrong information get into a cache entry, it will stay
there for time T3. The persistence of old information could
prevent communication (for a time) if a host changed its IA:HA
mapping.
何らかの間違った情報であるなら、キャッシュエントリーに興味を持ってください、そして、それは時間T3の間、そこに滞在するでしょう。 旧情報の固執はホストはアイオワを変えました: HAマッピングならコミュニケーション(時間の)を防ぐかもしれません。
One way to replace bad or out-of-date entries in a cache would
be to have the BOXes explicitly interpret a broadcast ARP reply
to require an entry with either this IA or HA to be replaced
with this new IA:HA mapping. One could have important servers
send a broadcast ARP reply when they come up.
キャッシュにおける悪いか時代遅れなエントリーを取り替える1つの方法はBOXesにこのアイオワかHAのどちらかとのエントリーがこの新しいアイオワに取り替えられるのが必要であるように放送ARP回答を明らかに解釈させるだろうことです: HAマッピング。 それらが来るとき、1つで、重要なサーバは放送ARP回答を送るかもしれません。
Non-ARP Hosts
非ARPホスト
It seems unrealistic to expect to use both ARP hosts and
non-ARP hosts on the same LAN and expect them to communicate.
If all the non-ARP hosts are on the same LAN the situation is
considered with under the next heading (Non-Broadcast LANs).
同じLANでARPホストと非ARPホストの両方を使用して、彼らが交信すると予想すると予想するのは非現実的に思えます。 すべての非ARPホストが同じLANにいるなら、状況で、次の見出し(非放送LAN)の下で考えられます。
Hosts that do not implement ARP must use some other means of
address mapping. Either they hold a complete table of all
hosts, or they access some such table in a server via some
protocol; or they expect to make all routing decisions based on
analysis of address fields.
ARPを実行しないホストはアドレス・マッピングのある他の手段を使用しなければなりません。 彼らがすべてのホストの完全なテーブルを持っているか、またはサーバで何らかのプロトコルで彼らはそのようなあるテーブルにアクセスします。 または、彼らは、すべてのルーティングをアドレス・フィールドの分析に基づく決定にすると予想します。
Postel [Page 6]
ポステル[6ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
Non-Broadcast LANs
非放送LAN
BOXes that are connected to LANs that do not have broadcast
capability and/or LANs where the hosts do not respond to ARP
may have a static or dynamic table of the IA:HA mappings for
that LAN (or the addresses may be computed from one another).
All the hosts on that LAN must be in the table.
ホストがARPに応じないところに放送能力、そして/または、LANを持っていないLANに接続されるBOXesはアイオワの静的であるかダイナミックなテーブルを持っているかもしれません: そのLAN(アドレスはお互いから計算されるかもしれない)のためのHAマッピング。 そのLANのすべてのホストがテーブルにいるに違いありません。
When a BOX must find the address mapping and would otherwise
send an ARP request into a non-broadcast LAN (this can only
happen when the sought host is not the non-broadcast LAN since
all the hosts are in the table), it must instead send an ARP
type request specifically to each of the other BOXes on that
LAN.
アドレス・マッピングを見つけなければならなくて、そうでなければ、BOXが非放送LANにARP要求を送るだろうというとき(すべてのホストがテーブルにいるので探されたホストが非放送LANでないときにだけ、これは起こることができます)、それは代わりにそのLANで特にそれぞれの他のBOXesにARPタイプ要求を送らなければなりません。
Size of Tables
テーブルのサイズ
The worst case of the size of the tables in the BOXes is the
number of hosts in the set of LANs for each table. That is,
the table kept for each LAN interface may (in the worst case)
grow to have an entry for each host in the entire set of LANs.
However, these tables are really caches of the entries needed
for current communication activity and the typical case will be
far from the worst case. Most hosts will communicate mostly
with other hosts on their own LAN and with a few hosts on other
LANs. Most communication on LANs is between work station hosts
and server hosts. It can be expected that there will be
frequent communication involving the main server hosts and that
these server hosts will be entered in the tables of most of the
BOXes most of the time.
BOXesのテーブルのサイズの最悪の場合は各テーブルのためのLANのセットで、ホストの数です。 すなわち、それぞれのLANインタフェースに保たれたテーブルは(最悪の場合には)全体のセットのLANで各ホストのためのエントリーを持つようになるかもしれません。 しかしながら、これらのテーブルは本当に現在のコミュニケーション活動に必要であるエントリーのキャッシュです、そして、典型的なケースは最悪の場合から遠いでしょう。 ほとんどのホストがそれら自身のLANと数人のホストと共に他のLANでほとんど他のホストとコミュニケートするでしょう。 ワークステーションホストとサーバー・ホストの間には、LANに関するほとんどのコミュニケーションがあります。 主なサーバー・ホストにかかわる頻繁なコミュニケーションがあって、これらのサーバー・ホストがたいていBOXesの大部分のテーブルに入れられると予想できます。
Infinite Transmission Loops
無限のトランスミッション輪
The possibility of infinite transmission loops through an
interconnected set of LANs is prevented by keeping search lists
in the BOXes and terminating the search when a request is
received for an address already on the list.
インタコネクトされたセットのLANを通した無限のトランスミッション輪の可能性は、アドレスのために既にリストに要求を受け取るとき、BOXesの検索リストを保って、検索を終えることによって、防がれます。
Transmission loops of regular datagrams can not persist because
them the BOXes must decrement the TTL, and discard the datagram
if the TTL is reduced to zero. For debugging purposes it would
be useful for a BOX to report to the implementer any datagrams
discarded for this reason.
通常のデータグラムのトランスミッション輪が持続できない、それら、TTLがゼロまで減少するなら、BOXesはTTLを減少させて、データグラムを捨てなければなりません。 デバッグ目的に、BOXが、どんなデータグラムもこの理由で捨てられたとimplementerに報告するのは、役に立つでしょう。
Postel [Page 7]
ポステル[7ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
Broadcast
放送
Note that broadcast does not really have anything to do with
either transparent subnets or explicit subnets. Since it was
discussed in [1], it will be discussed here, too. Two of the
three broadcast functions suggested in [1] work just the same
and have the same effects, the third can be supported, too.
放送は本当に透明なサブネットか明白なサブネットのどちらかと何らかの関係がないことに注意してください。 [1]で議論したので、また、ここでそれについて議論するでしょう。 [1]に示された3つの放送機能のうち2は、それでも働いていて、同じ効果を持って、また、3番目は支持できます。
It is also argued that the support for a broadcast
interpretation of IAs is a bigger issue that the question of
explicit subnets versus transparent subnets and it should be
decided separately.
また、サポートが、IAsの放送解釈が、より大きくaであるので明白なサブネットの対透明なサブネットとそれ問題が別々に決められるべきであるのを発行すると主張されます。
It is also suggested that broadcast is not really what is
desired, but rather multicast is the better function. It may
make sense to understand how to do an Internet multicast before
adopting a broadcast scheme.
また、放送されているのが、本当に望まれていることではありませんが、むしろマルチキャストが、より良い機能であると示唆されます。 それは放送計画を採用する前にインターネットマルチキャストをする方法を理解する意味になるかもしれません。
This IP Network
このIPネットワーク
If the IA of this network number and an all ones host number
(e.g., 36.255.255.255) is used, an IP level broadcast to all
hosts on this Network (all LANs) is intended. A BOX must
forward this datagram. A BOX must examine the datagram for
potential significance to the BOX itself.
このネットワーク・ナンバーとものホストの数のアイオワである、(例えば、36.255 .255 .255が)使用されている、このNetworkですべてのホストに放送されたIPレベル(すべてのLAN)は意図します。 BOXはこのデータグラムを進めなければなりません。 BOXは潜在的意味がないかどうかBOX自身にデータグラムを調べなければなりません。
To prevent infinite transmission loops each BOX must keep a
list of recent broadcasts. The entries in this list contain
the source IA and the Identification field from the datagram
header. If a broadcast is received and matches an entry on
the list it is discarded and not forwarded. The entries on
this list time out in time T2.
無限のトランスミッション輪を防ぐために、各BOXは最近の放送のリストを保たなければなりません。 このリストにおけるエントリーはデータグラムヘッダーからのソースアイオワとIdentification分野を含んでいます。 放送が受け取られていて、リストの上のエントリーに合っているなら、それは、捨てられて、進められません。 これのエントリーは時間T2のタイムアウトを記載します。
This LAN Only
このLAN専用
If the IA of all ones (i.e., 255.255.255.255) is used an IP
level broadcast to all hosts on this LAN only is intended.
A BOX must not forward this datagram. A BOX must examine
the datagram for potential significance to the BOX itself.
すなわち、すべてのもののアイオワである、(255.255 .255 .255は)使用されて、このLANですべてのホストに放送されたIPレベルだけが意図するということです。 BOXはこのデータグラムを進めてはいけません。 BOXは潜在的意味がないかどうかBOX自身にデータグラムを調べなければなりません。
Another LAN Only
別のLAN専用
Since the LANs are not individually identified in the IA
this can not be supported in the same way. Some have also
argued that this is a silly capability to provide.
LANがアイオワで個別に特定されないので、同様に、これを支持できません。 また、或るものは、これが提供する愚かな能力であると主張しました。
One way to provide it is to establish a specific IA for each
それを提供する1つの方法はそれぞれのために特定のアイオワを設置することです。
Postel [Page 8]
ポステル[8ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
LAN that means "broadcast on this LAN". For example,
36.255.255.128 means broadcast on LAN A, and 36.255.255.187
means broadcast on LAN B, etc. These addresses would be
specially interpreted by the BOXes attached to the specific
LAN where they had the special interpretation, other BOXes
would treat these address as any other IAs. Where these
addresses are specially interpreted they are converted to
the broadcast on this LAN only address.
それが意味するLANは「このLANでは、放送されました」。 例えば、36.255の.255.128手段がLAN A、および36.255.255でLAN Bなどで放送された.187の手段を放送します。 特に、これらのアドレスは彼らには特別な解釈があったところに特定のLANに取り付けられたBOXesによって解釈されて、他のBOXesはいかなる他のIAsとしてもこれらのアドレスを扱うでしょう。 特に、これらのアドレスが解釈されるところでは、それらが変えられます。このLANにおける放送は記述するだけです。
DISCUSSION
議論
The claim for the extended ARP scheme is that the average host need not even know it is in a multi-LAN environment.
拡張ARP計画のためのクレームは普通のホストが、それがマルチLAN環境にあるのを知る必要さえないということです。
If a host took the trouble to analyze its local cache of IA:AH
address mappings it might discover that several of the IAs mapped
to the same HA. And if it took timing measurements it might
discover that some hosts responded with less delay that others.
And further, it might be able to find a correlation between these
discoveries. But few hosts would take the trouble.
ホストがわざわざアイオワ: それが発見するかもしれないIAsの数個が同じHAに写像したAHアドレス・マッピングのローカルなキャッシュを分析したなら。 そして、それがタイミング測定値を取るなら、何人かのホストが、より少ない遅れでその他のものを反応させたと発見するでしょうに。 そして、さらに、それはこれらの発見の間の相関関係を見つけることができるかもしれません。 しかし、問題を取るホストは少ないでしょう。
Address Structure
アドレス構造
In the explicit subnet scheme, some IA bits are devoted to
identifying the subnet (i.e., the LAN). The address is broken up
into network, subnet, and host fields. Generally, when fields are
use the density of the assigned addresses in the address space
goes down. That is, there is a less efficient use of the address
space. Significant implementation problems may arise if more
subnets than planned are installed and it becomes necessary to
change the size of the subnet field. It seems totally impractical
to use the explicit subnet scheme with a class C IA.
明白なサブネット計画では、いくつかのアイオワビットがサブネット(すなわち、LAN)を特定するのにささげられます。 アドレスはネットワーク、サブネット、およびホスト分野に終えられます。 分野が使用であるときに、一般に、アドレス空間における、割り当てられたアドレスの密度は落ちます。 すなわち、アドレス空間のそれほど効率的でない使用があります。 計画されているより多くのサブネットがインストールされて、サブネット分野のサイズを変えるのが必要になるなら、重要な実現問題は起こるかもしれません。 aのクラスCアイオワがある明白なサブネット計画を使用するのは完全に非実用的に思えます。
In the extended ARP scheme the address is simply the network, and
host fields. The extended ARP scheme may be used with any class
of IA.
拡張ARP計画では、アドレスは、単にネットワークと、ホスト分野です。 拡張ARP計画はアイオワのどんなクラスと共にも使用されるかもしれません。
Relocating Hosts
ホストを移動させます。
In the explicit subnet scheme when a host is unplugged from one
LAN and plugged into another its IA must change.
明白なサブネット計画では、ホストが1つのLANからプラグを抜かれて、別のものにプラグを差し込まれるとき、アイオワは変化しなければなりません。
In the extended ARP scheme it may keep the same IA.
拡張ARP計画では、それは同じアイオワを保つかもしれません。
Postel [Page 9]
ポステル[9ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
One view of the situation suggests that there are really two problems:
状況の1つの視点が、2つの問題が本当にあるのを示します:
1. How does the host discover if the destination is in this LAN or
some other LAN?
1. ホストは、このLANかある他のLANで目的地があるかをどのように発見しますか?
This question assumes that a host should know the difference
and should do something different in the two cases, and further
that once the host knows the answer it also know how to send
the data (e.g., directly to the host, or to the box).
この質問が、ホストが違いを知るべきであると仮定して、ホストがいったん、データを送るまたそれがどのようにを知っている答え(直接ホスト、または、例えば、箱への)を知っていると、2つの場合において何か異なったことをして、それを促進するべきです。
The claim here is that the hosts should not know the
difference and should always do the same thing.
ホストが違いを知るべきでなくて、いつも同じことをするべきであるというクレームは、ここにあります。
2. How do the BOXes that connect LANs know which BOXes are the
routes to which LANs?
2. LANを接続するBOXesは、どのBOXesがどのLANへのルートであるかをどのように知っていますか?
This question assumes that the BOXes need some kind of
topological knowledge, and exchange BOX-to-BOX protocol
information about connectivity.
この質問は、BOXesがある種の位相的な知識、および交換BOXからBOXへの接続性に関するプロトコル情報を必要とすると仮定します。
The claim here is that the BOXes do not need topological
knowledge and do not need to explicitly know about the
existence of other BOXes.
BOXesが位相的な知識を必要としないで、他のBOXesの存在に関して明らかに知る必要はないというクレームは、ここにあります。
It has been suggested that there are two problems: first, how the hosts do routing; and second, how the BOXes do routing. A claim has been made that the competing strategies each have an approach to each problems and one could select a solution made up partly from one approach and partly from another.
2つの問題があることが提案されました: 1番目、ホストはどうルーティングするか。 2番目、BOXesはどうルーティングするか。 競争している戦略がそれぞれ問題と1つが一部一部1つのアプローチと別のものから作られた解決策を選択できたアプローチをそれぞれに持っているというクレームをしました。
For example: use ARP within the LAN and have the BOX send ARP
replies and act as a agent (as in the extended ARP scheme), but
use a BOX-to-BOX protocol to get the "which hosts are where"
information into the BOXes (as in the explicit subnet scheme).
例えば: LANの中でARPを使用してください、そして、BOXが回答をARPに送って、エージェントとして務めるのを持ってくださいが(拡張ARP計画のように)、BOXからBOXへのプロトコルを使用して(明白なサブネット計画のように)、「どこがどのホストであるか」という情報をBOXesに得てください。
There are two places where code is involved: a large number of hosts, and a small number of BOXes. In considering the trade off between explicit subnet scheme and extended ARP scheme, the work done in the hosts should weigh a lot more than the work done in the BOXes.
2つの場所がコードがかかわるところにあります: 多くのホスト、およびBOXesの少ない数。 取り引きが明白なサブネット計画と拡張ARP計画の間で取り止めになっていると考える際に、ホストで行われた仕事はBOXesで行われた仕事よりいろいろな事の重さがあるべきです。
What do hosts do?
ホストは何をしますか?
Explicit Subnet Scheme
明白なサブネット計画
The host must be able to decide if this IA is on this LAN or
またはホストが、このアイオワがこのLANにあるかを決めることができなければならない。
Postel [Page 10]
ポステル[10ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
some other LAN. If on this LAN then use some procedure to
find the HA. If on some other LAN then use some procedure
to find the HA of a BOX.
ある他のLAN。 このLANに関してHAを見つけるのに何らかの手順を用いてください。 ある他のLANに関してBOXのHAを見つけるのに何らかの手順を用いてください。
Extended ARP Scheme
拡張ARP計画
In every case the host uses ARP to get a IA:HA mapping.
あらゆる場合にホストはアイオワを得るのにARPを使用します: HAマッピング。
What do the BOXes do?
BOXesは何をしますか?
Explicit Subnet Scheme
明白なサブネット計画
The BOX must be able to decide which LAN within the site the
destination host is on. The BOXes must have some routing
table that tells for each LAN in the site which interface to
send datagrams on. This routing table must be kept up to
date, probably by a BOX-to-BOX protocol much like the
Internet Gateway-to-Gateway protocol.
BOXは、あて先ホストがサイトの中のどのLANでいるかを決めることができなければなりません。 BOXesには、サイトの各LANのためにどのインタフェースにデータグラムを送るかを言ういくらかの経路指定テーブルがなければなりません。 この経路指定テーブルはたぶんインターネットゲートウェイからゲートウェイへのプロトコルのようなBOXからBOXへのプロトコルによって時代について行かされなければなりません。
Extended ARP Scheme
拡張ARP体系
The BOX must keep caches for each LAN it is attached to of
IA:HA mappings, and it must keep a search list. It does not
run any BOX-to-BOX protocol, It does not even know if any
other BOXes exist.
BOXはそれがアイオワ: HAマッピングについて付けられている各LANのためにキャッシュを保たなければなりません、そして、それは検索リストを保たなければなりません。 それはBOXからBOXへのどんなプロトコルも述べないで、またItは、他のBOXesが存在するかどうかを知ってさえいません。
Topology and Implementation Complexity
トポロジーと実装の複雑さ
Trees
木
If the organization of the LANs and the BOXes is tree
structured, the BOXes may be very simple, they don't have to
keep the search lists at all, since there won't be any loops
for the ARP-request to traverse.
BOXesがLANとBOXesの組織が構造化された木であるなら、非常に簡単であるかもしれない、彼らは検索が全くリストであることを保つ必要はありません、横断するARP-要求のためのどんな輪もないので。
Loops
輪
If the organization has loops then the search lists are
essential. If the topology is kept balanced so that there are
no long loops (all loops are about the same size), and the LANs
are reasonably compatible in delay characteristics, then the
procedure described here will work well.
組織に輪があるなら、検索リストは不可欠です。 トポロジーが大わ節が全くない(すべての輪がほぼ同じくらいのサイズである)ようにバランスをとるように保たれて、LANは遅れの特性において合理的に互換性があると、ここで説明された手順がうまくいくでしょう。
Complex
複合体
If the organization is very complex, topologically unbalanced,
位相的に均衡を失わせられて、組織が非常に複雑であるなら
Postel [Page 11]
ポステル[11ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
and/or composed of mix of different types of LANS with vastly
different delay characteristics, then it may be better to use a
BOX-to-BOX routing protocol.
そして/または、広大に異なった遅れの特性があるLANSの異なったタイプのミックスを落ち着かせて、そして、BOXからBOXへのルーティング・プロトコルを使用しているほうがよいかもしれません。
SUMMARY
概要
It would be useful if the Internet community could come to some agreement on a solution to the multi-LAN network problem and could with a unified voice urge work station manufacturers to provide that solution built in.
インターネットコミュニティが、ソリューションの何らかの協定にマルチLANネットワーク問題に来ることができて、統一された声で築き上げられたその解決法を提供するようワークステーションメーカーに促すことができるなら、役に立つでしょうに。
I urge consideration of the extended ARP scheme expounded on here.
私はここで述べられた拡張ARP体系の考慮を主張します。
I think that most work stations will be connected to LANs that have a broadcast capability. I think that most work stations will be used in situations that do not require explicit subnets, and most will be used in situations where a class C Internet addresses would be appropriate (and explicit subnets impossible). Thus, i think it would be best to ask manufacturers to include support for ARP in work stations off the shelf. I also think we ought to get busy and create, develop, test, and produce the magic boxes I suggest so that they too are available off the shelf.
私は、ほとんどのワークステーションが放送能力を持っているLANに接続されると思います。 私は、ほとんどのワークステーションが明白なサブネットを必要としない状況で使用されて、大部分がCインターネットが演説するクラスが適切である状況(そして、不可能な明白なサブネット)で使用されると思います。 したがって、私は、ワークステーションですぐ入手できるARPのサポートを含めるようにメーカーに頼むのが最も十分であると思います。 私は、それらがも利用可能であるように、勧める魔法の箱をまた、私たちがすぐに取りかかるべきであると考えて、作成して、開発して、検査して、作り出します。すぐ入手できる。
Please note that neither this note nor [1] proposes a specific routing procedure or BOX-to-BOX protocol. This is because such a routing procedure is a very hard problem. The plan proposed here will let us get started on using multi-LAN environments in a reasonable way. If we later decide on a routing procedure to be used between the BOXes we can redo the BOXes without having to redo the hosts.
この注意も[1]も特定のルーティング手順かBOXからBOXへのプロトコルを提案しません。 これはそのようなルーティング手順が非常に困難な問題であるからです。 ここで提案されたプランで、私たちは使用のときに合理的な方法でマルチLAN環境で開始できるでしょう。 後でルーティング手順でBOXesの間で使用されると決めるなら、ホストをやり直す必要はなくて、私たちはBOXesをやり直すことができます。
Postel [Page 12]
ポステル[12ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
GLOSSARY
用語集
ARP
アルプ
Address Resolution Protocol (see [2]).
解決がプロトコルであると扱ってください。([2])を考えてください。
BOX
箱
Magic Box. A box (computer) connected to two or more LANs of the
same Network. Also called an "ARP-based bridge".
魔法箱。 箱(コンピュータ)は同じNetworkの2つ以上のLANに接続しました。 また、「ARPベースのブリッジ」と呼ばれます。
Bridge
ブリッジ
A node (computer) 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以上に関連づけました。 また、「ソフトウェアリピータ」と呼ばれます。
Datagram
データグラム
The unit of communication at the IP level.
IPレベルにおけるコミュニケーションのユニット。
Explicit Subnet
明白なサブネット
A Subnet explicitly identified in the the Internet Address by a
subnet address field, and so visible to others both in side and
out side the Network.
中で面があってください。そうすれば、Networkは外で面があるように、インターネットAddressでサブネットアドレス・フィールドによって明らかに特定されて、他のものの両方において、とても目に見えるSubnet。
Gateway
ゲートウェイ
A node (computer) connected to two or more administratively
distinct networks and/or subnets, to which hosts send datagrams to
be forwarded.
ノード(コンピュータ)は2つ以上の行政上異なったネットワーク、そして/または、サブネットに接続しました。(ホストは進められるデータグラムをサブネットに送ります)。
HA
ハ
Hardware Address, the address used in a packet on a LAN.
ハードウェアAddress、LANでパケットで使用されるアドレス。
Host Number
ホスト番号
The address of a host within an Network, the low-order part of an
IA.
Networkの中のホストのアドレス、アイオワの下位の地域。
IA
アイオワ
Internet Address, as defined in IP.
IPで定義されるようなインターネットAddress。
Postel [Page 13]
ポステル[13ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
Internet
インターネット
The collection of connected Internet Networks (also known as the
Catenet). A set of interconnected networks using IP.
接続インターネットNetworks(また、Catenetとして、知られている)の収集。 IPを使用する1セットの相互接続ネットワーク。
IP
IP
Internet Protocol (see [3]).
インターネットについて議定書の中で述べます。([3])を見てください。
LAN
LAN
Local Area Network.
ローカル・エリア・ネットワーク。
Multi-LAN Network
マルチLANネットワーク
A set of LANs treated as one Network, i.e., using one Network
Number in common. The individual LANs may be either Explicit
Subnets or Transparent Subnets.
すなわち、LANのセットは、1Networkとして一般的の1Network Numberを使用することで扱われました。 個々のLANは、Explicit SubnetsかTransparent Subnetsのどちらかであるかもしれません。
Network
ネットワーク
A single Internet Network (possibly divided into subnets or
composed of multiple LANs), identified by an individual Network
Number.
個々のNetwork Numberによって特定された独身のインターネットNetwork(ことによるとサブネットに分割されるか、または複数のLANで構成されます)。
Network Number
ネットワーク・ナンバー
An IP Network Number, the high-order part of an IA.
IP Network Number、アイオワの高位地域。
Packet
パケット
The unit of communication at the LAN hardware level.
LANハードウェアレベルにおけるコミュニケーションのユニット。
Subnet
サブネット
A subnet of Network. A portion of a Network (either logical or
physical).
Networkのサブネット。 Network(論理的であるか物理的な)の一部。
Transparent Subnet
透明なサブネット
A Subnet not identified in the Internet Address, and so invisible
to others, (see Multi-LAN Network).
インターネットAddressで特定されないで、したがって、他のものにとって、目に見えないSubnet、(Multi-LAN Networkを見ます。)
TTL
TTL
The IP Time-To-Live field.
IP生きるTime分野。
Postel [Page 14]
ポステル[14ページ]
RFC 925 October 1984 Multi-LAN Address Resolution
RFC925 1984年10月のマルチLANアドレス解決
REFERENCES
参照
[1] J. Mogul, "Internet Subnets", RFC-917, Stanford University,
October 1984.
[1] J.ムガール人、「インターネットサブネット」、RFC-917、スタンフォード大学、1984年10月。
[2] D. Plummer, "An Ethernet Address Resolution Protocol or
Converting Network Protocol Addresses to 48-bit Ethernet
Addresses for Transmission on Ethernet Hardware", RFC-826,
Symbolics, November 1982.
[2] D.プラマー、「イーサネットアドレス解決プロトコルかネットワーク・プロトコルを変換すると、トランスミッションのためのアドレスはイーサネットハードウェアの上で48ビットのイーサネットに扱われます」、RFC-826、信条学、1982年11月。
[3] J. Postel, "Internet Protocol", RFC-791, USC-ISI,
September 1981.
[3] J.ポステル、「インターネットプロトコル」、RFC-791、USC-ISI、1981年9月。
Postel [Page 15]
ポステル[15ページ]
一覧
スポンサーリンク
