RFC1433 日本語訳
1433 Directed ARP. J. Garrett, J. Hagan, J. Wong. March 1993. (Format: TXT=41028 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Garrett
Request for Comments: 1433 AT&T Bell Laboratories
J. Hagan
University of Pennsylvania
J. Wong
AT&T Bell Laboratories
March 1993
コメントを求めるワーキンググループJ.ギャレットの要求をネットワークでつないでください: 大西洋標準時1433と1993年のTベル研究所のJ.ハーガンのペンシルバニア大学のJ.ウォンAT&Tベル研究所の行進
Directed ARP
指示されたARP
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
A router with an interface to two IP networks via the same link level interface could observe that the two IP networks share the same link level network, and could advertise that information to hosts (via ICMP Redirects) and routers (via dynamic routing protocols). However, a host or router on only one of the IP networks could not use that information to communicate directly with hosts and routers on the other IP network unless it could resolve IP addresses on the "foreign" IP network to their corresponding link level addresses. Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses.
同じリンク・レベルインタフェースを通して2つのIPネットワークへのインタフェースがあるルータは、2つのIPネットワークが同じリンク・レベルネットワークを共有するのを観測できて、ホスト(ICMP Redirectsを通した)とルータ(ダイナミックルーティングプロトコルを通した)にその情報の広告を出すかもしれません。 しかしながら、「外国」のIPネットワークに関するIPアドレスをそれらの対応するリンク・レベルアドレスに決議できないなら、IPネットワークの唯一の1つのホストかルータが、ホストとルータと共にもう片方のIPネットワークで直接伝達するのにその情報を使用できないでしょうに。 指示されたARPはホストとルータが外国IPネットワークに関する広告を出している潜在的次のホップIPアドレスをそれらの関連リンク・レベルアドレスに決議するのを可能にするダイナミックなアドレス解決手順です。
Acknowledgments
承認
The authors are indebted to Joel Halpern of Network Systems Corporation and David O'Leary who provided valuable comments and insight to the authors, as well as ongoing moral support as the presentation of this material evolved through many drafts. Members of the IPLPDN working group also provided valuable comments during presentations and through the IPLPDN mailing list. Chuck Hedrick of Rutgers University, Paul Tsuchiya of Bell Communications Research, and Doris Tillman of AT&T Bell Laboratories provided early insight as well as comments on early drafts.
作者は貴重なコメントと洞察を作者に提供したNetwork Systems社とデヴィッドオリアリーのジョエル・アルペルンの世話になっています、多くの草稿で発展されたこの材料のプレゼンテーションとしての進行中の精神的なサポートと同様に。 また、IPLPDNワーキンググループのメンバーはプレゼンテーションとIPLPDNメーリングリストを通して貴重なコメントを提供しました。 ラトガース大学のチャック・ヘドリック、ベルコミュニケーションズ・リサーチのポールTsuchiya、およびAT&Tベル研究所のドリス・ティルマンは早めの草稿のコメントと同様に早めの洞察を提供しました。
Garrett, Hagan & Wong [Page 1] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[1ページ]RFC1433
1. Terminology
1. 用語
A "link level network" is the upper layer of what is sometimes referred to (e.g., OSI parlance) as the "subnetwork", i.e., the layers below IP. The term "link level" is used to avoid potential confusion with the term "IP sub-network", and to identify addresses (i.e., "link level address") associated with the network used to transport IP datagrams.
「リンク・レベルネットワーク」は時々「サブネットワーク」(すなわち、IPの下の層)と呼ばれる(例えば、OSI話法)上側の層のことです。 「リンク・レベル」という用語は、「IPサブネットワーク」という用語への潜在的混乱を避けて、IPデータグラムを輸送するのに使用されるネットワークに関連しているアドレス(すなわち、「リンク・レベルアドレス」)を特定するのに使用されます。
From the perspective of a host or router, an IP network is "foreign" if the host or router does not have an address on the IP network.
ホストかルータの見解から、ホストかルータにIPネットワークに関するアドレスがないなら、IPネットワークは「外国です」。
2. Introduction
2. 序論
Multiple IP networks may be administered on the same link level network (e.g., on a large public data network). A router with a single interface on two IP networks could use existing routing update procedures to advertise that the two IP networks shared the same link level network. Cost/performance benefits could be achieved if hosts and routers that were not on the same IP network could use that advertised information, and exchange packets directly, rather than through the dual addressed router. But a host or router can not send packets directly to an IP address without first resolving the IP address to its link level address.
複数のIPネットワークが同じリンク・レベルネットワーク(例えば、大きい公衆データネットワークの)で管理されるかもしれません。 単一のインタフェースが2つのIPネットワークにあるルータは、2つのIPネットワークが同じリンク・レベルネットワークを共有したのは広告を出すのに既存のルーティングアップデート手順を用いるかもしれません。 同じIPネットワークになかったホストとルータが二元的な扱われたルータより直接、むしろその広告を出している情報、および交換パケットを使用できるなら、費用/性能利益を達成できるでしょうに。 しかし、最初にリンク・レベルアドレスにIPアドレスを決議しないで、ホストかルータが直接IPアドレスにパケットを送ることができません。
IP address resolution procedures are established independently for each IP network. For example, on an SMDS network [1], address resolution may be achieved using the Address Resolution Protocol (ARP) [2], with a separate SMDS ARP Request Address (e.g., an SMDS Multicast Group Address) associated with each IP network. A host or router that was not configured with the appropriate ARP Request Address would have no way to learn the ARP Request Address associated with an IP network, and would not send an ARP Request to the appropriate ARP Request Address. On an Ethernet network a host or router might guess that an IP address could be resolved by sending an ARP Request to the broadcast address. But if the IP network used a different address resolution procedure (e.g., administered address resolution tables), the ARP Request might go unanswered.
IPアドレス解決手順はそれぞれのIPネットワークのために独自に確立されます。 例えば、SMDSネットワーク[1]では、アドレス解決はAddress Resolutionプロトコル(ARP)[2]を使用することで達成されるかもしれません、それぞれのIPネットワークに関連している別々のSMDS ARP Request Address(例えば、SMDS Multicast Group Address)と共に。 適切なARP Request Addressによって構成されなかったホストかルータが、IPネットワークに関連しているARP Request Addressを学ぶ方法を全く持たないで、また適切なARP Request AddressにARP Requestを送らないでしょう。 イーサネットネットワークでは、ホストかルータが、ARP Requestを放送演説に送ることによってIPアドレスを決議できるだろうと推測するかもしれません。 しかし、IPネットワークが異なったアドレス解決手順(例えば、アドレス解決テーブルを管理する)を用いるなら、ARP Requestは答えがなくなるでしょうに。
Directed ARP is a procedure that enables a router advertising that an IP address is on a shared link level network to also aid in resolving the IP address to its associated link level address. By removing address resolution constraints, Directed ARP enables dynamic routing protocols such as BGP [3] and OSPF [4] to advertise and use routing information that leads to next-hop addresses on "foreign" IP networks. In addition, Directed ARP enables routers to advertise (via ICMP Redirects) next-hop addresses that are "foreign" to hosts, since the hosts can use Directed ARP to resolve the "foreign" next-
指示されたARPはまた、IPアドレスが共有されたリンク・レベルネットワークにあるルータ広告が関連リンク・レベルアドレスにIPアドレスを決議する際に支援されるのを可能にする手順です。 アドレス解決規制を取り除くことによって、Directed ARPは、BGP[3]やOSPF[4]などのダイナミックルーティングプロトコルが「外国」のIPネットワークに関する次のホップアドレスにつながるルーティング情報の広告を出して、使用するのを可能にします。 さらに、Directed ARPは、ルータがホストにとって、「外国である」次のホップアドレスの広告を出すのを(ICMP Redirectsを通して)可能にします、ホストが次に「外国」を決議するのにDirected ARPを使用できるので
Garrett, Hagan & Wong [Page 2] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[2ページ]RFC1433
hop addresses.
アドレスを飛び越してください。
3. Directed ARP
3. 指示されたARP
Directed ARP uses the normal ARP packet format, and is consistent with ARP procedures, as defined in [1] and [2], and with routers and hosts that implement those procedures.
指示されたARPは正常なARPパケット・フォーマットを使用して、ARP手順と一致しています、それらの手順を実装する[1]と[2]、ルータ、およびホストと共に定義されるように。
3.1 ARP Helper Address
3.1 ARPアシスタントアドレス
Hosts and routers maintain routing information, logically organized as a routing table. Each routing table entry associates one or more destination IP addresses with a next-hop IP address and a physical interface used to forward a packet to the next-hop IP address. If the destination IP address is local (i.e., can be reached without the aid of a router), the next-hop IP address is NULL (or a logical equivalent, such as the IP address of the associated physical interface). Otherwise, the next-hop IP address is the address of a next-hop router.
ホストとルータは経路指定テーブルとして論理的に組織化されたルーティング情報を保守します。 各経路指定テーブルのエントリー関連1か、より多くの目的地IPが、次のホップでIPがアドレスと次のホップIPアドレスにパケットを送るのに使用される物理インターフェースであると扱います。 送付先IPアドレスがローカルであるなら(すなわち、ルータの援助なしで達することができます)、次のホップIPアドレスはNULL(または、関連物理インターフェースのIPアドレスなどの論理的な同等物)です。 さもなければ、次のホップIPアドレスは次のホップルータのアドレスです。
A host or router that implements Directed ARP procedures associates an ARP Helper Address with each routing table entry. If the host or router has been configured to resolve the next-hop IP address to its associated link level address (or to resolve the destination IP address, if the next-hop IP address is NULL), the associated ARP Helper Address is NULL. Otherwise, the ARP Helper Address is the IP address of the router that provided the routing information indicating that the next-hop address was on the same link level network as the associated physical interface. Section 4 provides detailed examples of the determination of ARP Helper Addresses by dynamic routing procedures.
Directed ARPに手順を実装するホストかルータがそれぞれの経路指定テーブルエントリーにARP Helper Addressを関連づけます。 ホストかルータが次のホップIPアドレスを関連リンク・レベルアドレスに決議するために構成されたなら(送付先IPアドレスを決議するために、次のホップであるなら、IPアドレスはNULLです)、関連ARP Helper AddressはNULLです。 さもなければ、ARP Helper Addressは次のホップアドレスが関連物理インターフェースと同じリンク・レベルネットワークにあったのを示すルーティング情報を提供したルータのIPアドレスです。 セクション4はダイナミックルーティング手順によるARP Helper Addressesの決断の詳細な例を提供します。
3.2 Address Resolution Procedures
3.2 アドレス解決手順
To forward an IP packet, a host or router searches its routing table for an entry that is the best match based on the destination IP address and perhaps other factors (e.g., Type of Service). The selected routing table entry includes the IP address of a next-hop router (which may be NULL), the physical interface through which the IP packet should be forwarded, an ARP Helper Address (which may be NULL), and other information. The routing function passes the next- hop IP address, the physical interface, and the ARP Helper Address to the address resolution function. The address resolution function must then resolve the next-hop IP address (or destination IP address if the next-hop IP address is NULL) to its associated link level address. The IP packet, the link level address to which the packet should be forwarded, and the interface through which the packet should be forwarded are then passed to the link level driver
IPパケット、ホストまたはルータを進めるのは送付先IPアドレスに基づく中で最も良いマッチであるエントリーと恐らく他の要素(例えば、ServiceのType)のために経路指定テーブルを捜します。 選択された経路指定テーブルエントリーは次のホップルータのIPアドレス(NULLであるかもしれない)、IPパケットが進められるべきである物理インターフェース、ARP Helper Address(NULLであるかもしれない)、および他の情報を含んでいます。 経路選択機能は次のホップIPアドレス、物理インターフェース、およびARP Helper Addressをアドレス解決機能に渡します。 そして、アドレス解決機能は次のホップIPアドレス(または、IPが次のホップIPアドレスがNULLであるなら扱う目的地)を関連リンク・レベルアドレスに決議しなければなりません。 そして、IPパケット、パケットが送られるべきであるリンク・レベルアドレス、およびパケットが進められるべきであるインタフェースはリンク・レベルドライバーに渡されます。
Garrett, Hagan & Wong [Page 3] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[3ページ]RFC1433
associated with the physical interface. The link level driver encapsulates the IP packet in one or more link level frames (i.e., may do fragmentation) addressed to the associated link level address, and forwards the frame(s) through the appropriate physical interface. The details of the functions performed are described via C pseudo- code below.
物理インターフェースに関連しています。 リンク・レベルドライバーは、適切な物理インターフェースを通して関連リンク・レベルアドレスに扱われた、1個以上のリンク・レベルフレーム(すなわち、断片化するかもしれない)、およびフォワードのIPパケットがフレームであるとカプセル化します。 実行された機能の詳細は以下のC疑似コードで説明されます。
The procedures are organized as two functions, Route() and Resolve(), corresponding to routing and address resolution. In addition, the following low level functions are also used:
ルーティングとアドレス解決に対応している、手順は2つの機能、Route()、およびResolve()として組織化されます。 また、さらに、以下の低平らな機能は使用されます:
Get_Route(IP_Add,Other) returns a pointer to the routing table
entry with the destination field that best matches IP_Add. If no
matching entry is found, NULL is returned. Other information such
as Type of Service may be considered in selecting the best route.
Route(IP_Add、Other)が指針を返す_をIP_Addに最もよく合っているあて先フィールドがある経路指定テーブルエントリーに手に入れてください。 合っているエントリーを全く見つけないなら、NULLを返します。 ServiceのTypeなどの他の情報は最も良いルートを選択する際に考えられるかもしれません。
Forward(Packet,Link_Level_Add,Phys_Int) fragments Packet (if
needed), and encapsulates Packet in one or more Link Level Frames
addressed to Link_Level_Add, and forwards the frame(s) through
interface, Phys_Int.
前方に、(パケット、Link_Level_Add、Phys_Int)は、1のPacketかLink Level FramesがLink_Level_Addに扱った以上と、フォワードがフレームであるとPacket(必要であるなら)を断片化して、インタフェース(Phys_Int)を通してカプセル化します。
Look_Up_Add_Res_Table(IP_Add,Phys_Int) returns a pointer to the
link level address associated with IP_Add in the address
resolution table associated with interface, Phys_Int. If IP_Add
is not found in the address resolution table, NULL is returned.
インタフェース(Phys_Int)に関連づけられたアドレス解決テーブルで_リンク・レベルアドレスへの指針がIP_Addに関連づけたUp_Add_Res_Table(IP_Add、Phys_Int)リターンに見えてください。 アドレス解決テーブルでIP_Addを見つけないなら、NULLを返します。
Local_Add_Res(IP_Add,Phys_Int) returns a pointer to the Link Level
address associated with IP_Add, using address resolution
procedures associated with address, IP_Add, and interface,
Phys_Int. If address resolution is unsuccessful, NULL is
returned. Note that different address resolution procedures may
be used for different IP networks.
アドレス解決手順を用いて、Link Levelアドレスへの指針がIP_Addに関連づけた地方の_Add_Res(IP_Add、Phys_Int)リターンはアドレス、IP_Add、およびインタフェース(Phys_Int)と交際しました。 アドレス解決が失敗しているなら、NULLを返します。 異なったアドレス解決手順が異なったIPネットワークに用いられるかもしれないことに注意してください。
Receive_ARP_Response(IP_Add,Phys_Int) returns a pointer to an ARP
Response received through interface, Phys_Int, that resolves
IP_Add. If no ARP response is received, NULL is returned.
_ARP Responseへの指針がインタフェース、IP_Addを決議するPhys_Intを通して受けたARP_Response(IP_Add、Phys_Int)リターンを受けてください。 どんなARP応答も受け取られていないなら、NULLを返します。
Dest_IP_Add(IP_Packet) returns the IP destination address from
IP_Packet.
Dest_IP_Add(IP_Packet)はIP_Packetから受信者IPアドレスを返します。
Next_Hop(Entry) returns the IP address in the next-hop field of
(routing table) Entry.
次の_Hop(エントリー)は(経路指定テーブル)エントリーの次のホップ分野でIPアドレスを返します。
Interface(Entry) returns the physical interface field of (routing
table) Entry.
インタフェース(エントリー)は(経路指定テーブル)エントリーの物理インターフェース野原を返します。
ARP_Helper_Add(Entry) returns the IP address in the ARP Helper
Address field of (routing table) Entry.
ARP_Helper_Add(エントリー)は(経路指定テーブル)エントリーのARP Helper Address分野でIPアドレスを返します。
Garrett, Hagan & Wong [Page 4] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[4ページ]RFC1433
ARP_Request(IP_Add) returns an ARP Request packet with IP_Add as
the Target IP address.
ARP_Request(IP_Add)はTarget IPアドレスとしてIP_AddがあるARP Requestパケットを返します。
Source_Link_Level(ARP_Response) returns the link level address of
the sender of ARP_Response.
ソース_Link_Level(ARP_Response)はARP_Responseのリンク・レベル送信者のアドレスを返します。
ROUTE(IP_Packet)
{
Entry = Get_Route(Dest_IP_Add(IP_Packet),Other(IP_Packet));
If (Entry == NULL) /* No matching entry in routing table */
Return; /* Discard IP_Packet */
else
{ /* Resolve next-hop IP address to link level address */
If (Next_Hop(Entry) != NULL) /* Route packet via next-hop router */
Next_IP = Next_Hop(Entry);
else /* Destination is local */
Next_IP = Dest_IP_Add(IP_Packet);
L_L_Add = Resolve(Next_IP,Interface(Entry),ARP_Helper_Add(Entry));
If (L_L_Add != NULL)
Forward(IP_Packet,L_L_Add,Interface(Entry));
else /* Couldn't resolve next-hop IP address */
Return; /* Discard IP_Packet */
Return;
}
}
ルート(IP_パケット){ エントリー=は経路指定テーブル*/リターンにおけるエントリーに合っていない(エントリー=NULL)/*であるなら_Route(Dest_IP_Add(IP_Packet)、Other(IP_Packet))を手に入れます; }
Figure 1: C Pseudo-Code for the Routing function.
図1: ルート設定機能のためのC疑似コード。
Garrett, Hagan & Wong [Page 5] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[5ページ]RFC1433
Resolve(IP_Add,Interface,ARP_Help_Add)
{
If ((L_L_Add = Look_Up_Add_Res_Table(IP_Add,Interface)) != NULL)
{ /* Found it in Address Resolution Table */
Return L_L_Add;
}
else
{
If (ARP_Help_Add == NULL)
{ /* Do local Address Resolution Procedure */
Return Local_Add_Res(IP_Add,Interface);
}
else /* ARP_Help_Add != NULL */
{
L_L_ARP_Help_Add = Look_Up_Add_Res_Table(ARP_Help_Add,Interface);
If (L_L_ARP_Help_Add == NULL)
/* Not in Address Resolution Table */
L_L_ARP_Help_Add = Local_Add_Res(ARP_Help_Add,Interface);
If (L_L_ARP_Help_Add == NULL) /* Can't Resolve ARP Helper Add */
Return NULL; /* Address Resolution Failed */
else
{ /* ARP for IP_Add */
Forward(ARP_Request(IP_Add),L_L_ARP_Help_Add,Interface);
ARP_Resp = Receive_ARP_Response(IP_Add,Interface);
If (ARP_Resp == NULL) /* No ARP Response (after persistence) */
Return NULL; /* Address Resolution Failed */
else
Return Source_Link_Level(ARP_Resp);
}
}
}
}
}
決心(IP_は加えて、連結してください、そして、ARP_ヘルプ、_は加えます); ヘルプ..リターン..扱う..ほかに..フォワード..ヘルプ..受ける..固執..リターン..アドレス..ほか; }
Figure 2: C Pseudo-Code for Address Resolution function.
図2: Address Resolution機能のためのC疑似コード。
3.3 Forwarding ARP Requests
3.3 推進ARP要求
A host that implements Directed ARP procedures uses normal procedures to process received ARP Requests. That is, if the Target IP address is the host's address, the host uses normal procedures to respond to the ARP Request. If the Target IP address is not the host's address, the host silently discards the ARP Request.
Directed ARP手順用途が処理する正常な手順であると実装するホストはARP Requestsを受け取りました。 すなわち、Target IPアドレスがホストのアドレスであるなら、ホストは、ARP Requestに応じるのに正常な手順を用います。 Target IPアドレスがホストのアドレスでないなら、ホストは静かにARP Requestを捨てます。
If the Target IP address of an ARP Request received by a router is the router's address, the router uses normal procedures to respond to
ルータによって受け取られたARP RequestのTarget IPアドレスがルータのアドレスであるなら、ルータは応じる正常な手順を用います。
Garrett, Hagan & Wong [Page 6] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[6ページ]RFC1433
the ARP Request. But if the Target IP address is not the router's address, the router may forward the ARP Request back through the same interface it was received from, addressed to a Link Level Address that corresponds to an ARP Helper Address in the router's routing table. The procedures used to process an ARP Request are described via C pseudo-code below. The function Receive() describes procedures followed by hosts and routers, and the function Direct() describes additional procedures followed by routers. In addition, the following low level functions are also used:
ARP要求。 しかし、ルータはTarget IPアドレスがルータのアドレスでないなら、それが受け取られた同じインタフェースを通してARP Requestを送って戻すかもしれません、ルータの経路指定テーブルのARP Helper Addressに対応するLink Level Addressに扱われて。 ARP Requestを処理するのに用いられた手順は以下のC中間コードで説明されます。 機能Receive()はホストとルータがあとに続いた手順について説明します、そして、機能Direct()は追加手順について説明します、続いて、ルータについて説明します。 また、さらに、以下の低平らな機能は使用されます:
Is_Local_IP_Add(IP_Add,Phys_Int) returns TRUE if Phys_Int has been
assigned IP address, IP_Add. Otherwise, returns FALSE.
IP_Add、_Phys_Intが割り当てられたならAdd(IP_Add、Phys_Int)がTRUEを返すLocal_IP_はIPアドレスですか? そうでなければ、リターンFALSE。
Do_ARP_Processing(ARP_Request,Interface) processes ARP_Request
using ARP procedures described in [2].
[2]で説明されたARP手順を用いて、_ARP_Processing(ARP_Request、Interface)プロセスにARP_Requestをしてください。
I_Am_Router returns TRUE if device is a router and False if device
is a host.
デバイスがホストであるなら、RouterがデバイスであるならTRUEを返すI_Am_はルータとFalseです。
Target_IP(ARP_Request) returns the Target IP address from
ARP_Request.
目標_IP(ARP_Request)はARP_RequestからTarget IPアドレスを返します。
Filter(ARP_Request,Phys_Int) returns TRUE if ARP_Request passes
filtering constraints, and FALSE if filtering constraints are not
passed. See section 3.4.
ARP_Requestが規制をフィルターにかけながら通るなら、フィルタ(ARP_Request、Phys_Int)はTRUEを返します、そして、規制をフィルターにかけるなら、FALSEは渡されません。 セクション3.4を見てください。
Forward(Packet,Link_Level_Add,Phys_Int) fragments Packet (if
needed), and encapsulates Packet in one or more Link Level Frames
addressed to Link_Level_Add, and forwards the frame(s) through
interface, Phys_Int.
前方に、(パケット、Link_Level_Add、Phys_Int)は、1のPacketかLink Level FramesがLink_Level_Addに扱った以上と、フォワードがフレームであるとPacket(必要であるなら)を断片化して、インタフェース(Phys_Int)を通してカプセル化します。
Look_Up_Next_Hop_Route_Table(IP_Add) returns a pointer to the
routing table entry with the next-hop field that matches IP_Add.
If no matching entry is found, NULL is returned.
外観_Up_Next_Hop_Route_Table(IP_Add)はIP_Addに合っている次のホップ分野がある経路指定テーブルエントリーに指針を返します。 合っているエントリーを全く見つけないなら、NULLを返します。
Look_Up_Dest_Route_Table(IP_Add) returns a pointer to the routing
table entry with the destination field that best matches IP_Add.
If no matching entry is found, NULL is returned.
外観_Up_Dest_Route_Table(IP_Add)はIP_Addに最もよく合っているあて先フィールドがある経路指定テーブルエントリーに指針を返します。 合っているエントリーを全く見つけないなら、NULLを返します。
Link_Level_ARP_Req_Add(IP_Add,Phys_Int) returns the link level
address to which an ARP Request to resolve IP_Add should be
forwarded. If ARP is not used to perform local address resolution
of IP_Add, NULL is returned.
_Req_Add(IP_Add、Phys_Int)がIP_Addを決議するARP Requestが送られるべきであるリンク・レベルアドレスを返すLevel_ARP_をリンクしてください。 IP_Addのローカルアドレス解決を実行するのにARPを使用しないなら、NULLを返します。
Local_Add_Res(IP_Add,Phys_Int) returns a pointer to the Link Level
address associated with IP_Add, using address resolution
procedures associated with address, IP_Add, and interface,
Phys_Int. If address resolution is unsuccessful, NULL is
アドレス解決手順を用いて、Link Levelアドレスへの指針がIP_Addに関連づけた地方の_Add_Res(IP_Add、Phys_Int)リターンはアドレス、IP_Add、およびインタフェース(Phys_Int)と交際しました。 アドレス解決が失敗しているなら、NULLは失敗します。
Garrett, Hagan & Wong [Page 7] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[7ページ]RFC1433
returned. Note that different address resolution procedures may
be used for different IP networks.
返す。 異なったアドレス解決手順が異なったIPネットワークに用いられるかもしれないことに注意してください。
Next_Hop(Entry) returns the IP address in the next-hop field of
(routing table) Entry.
次の_Hop(エントリー)は(経路指定テーブル)エントリーの次のホップ分野でIPアドレスを返します。
Interface(Entry) returns the physical interface field of (routing
table) Entry.
インタフェース(エントリー)は(経路指定テーブル)エントリーの物理インターフェース野原を返します。
ARP_Helper_Add(Entry) returns the IP address in the ARP Helper
Address field of (routing table) Entry.
ARP_Helper_Add(エントリー)は(経路指定テーブル)エントリーのARP Helper Address分野でIPアドレスを返します。
Source_Link_Level(ARP_Request) returns the link level address of
the sender of ARP_Request.
ソース_Link_Level(ARP_Request)はARP_Requestのリンク・レベル送信者のアドレスを返します。
Receive(ARP_Request,Interface)
{
If (Is_Local_IP_Add(Target_IP(ARP_Request),Interface))
Do_ARP_Processing(ARP_Request,Interface);
else /* Not my IP Address */
If (I_Am_Router) /* Hosts don't Direct ARP Requests */
If (Filter(ARP_Request,Interface)) /* Passes Filter Test */
/* See Section 3.4 */
Direct(ARP_Request,Interface); /* Directed ARP Procedures */
Return;
}
(ARP_要求、インタフェース)を受けてください。((ARP_Request、Interface)をフィルターにかけます)/*がFilter Test*//*を通過するなら、_(_I Am_Router)/*ホストがしないならAdd(_IP(ARP_Request)を狙ってください、Interface)が_ARP_Processing(ARP_Request、Interface); 私のIP Address*/ではなく、/*をほかのするLocal_IP_はDirect ARP Requests*/です。(セクション3.4が*/ダイレクトであることを(ARP_Request、Interface)見てください; /*はARP Procedures*/リターンを指示しました。
Figure 3: C Pseudo-Code for Receiving ARP Requests.
図3: ARP要求を受け取るためのC中間コード。
Garrett, Hagan & Wong [Page 8] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[8ページ]RFC1433
Direct(ARP_Request,Phys_Int)
{
Entry = Look_Up_Next_Hop_Route_Table(Target_IP(ARP_Request));
If (Entry == NULL) /* Target_IP Address is not a next-hop */
{ /* in Routing Table */
Entry = Look_Up_Dest_Route_Table(Target_IP(ARP_Request));
If (Entry == NULL) /* Not a destination either */
Return; /* Discard ARP Request */
else
If (Next_Hop(Entry) != NULL) /* Not a next-hop and Not local */
Return; /* Discard ARP Request */
}
If (Interface(Entry) != Phys_Int)
/* Must be same physical interface */
Return; /* Discard ARP Request */
If (ARP_Helper_Add(Entry) != NULL)
{
L_L_ARP_Helper_Add = Resolve(ARP_Helper_Add(Entry),Phys_Int,NULL);
If (L_L_ARP_Helper_Add != NULL)
Forward(ARP_Request,L_L_ARP_Helper_Add,Phys_Int);
/* Forward ARP_Request to ARP Helper Address */
Return;
}
else /* Do local address resolution. */
{
L_L_ARP_Req_Add =
Link_Level_ARP_Req_Add(Target_IP(ARP_Request),Phys_Int);
If (L_L_ARP_Req_Add != NULL)
{ /* Local address resolution procedure is ARP. */
/* Forward ARP_Request. */
Forward(ARP_Request,L_L_ARP_Req_Add,Phys_Int);
Return;
}
else
{ /* Local address resolution procedure is not ARP. */
/* Do "published ARP" on behalf of Target IP Address */
Target_Link_Level =
Local_Add_Res(Target_IP(ARP_Request),Phys_Int);
If (Target_Link_Level != NULL) /* Resolved Address */
{
Forward(ARP_Response,Source_Link_Level(ARP_Request),Phys_Int);
}
Return;
}
}
}
(ARP_要求、Phys_Int)を指示してください。{ _次の_ホップ_ルート_テーブル(目標_IP(ARP_要求))への外観エントリー=_。 (エントリー=NULL)/*目標_IP Addressがa次のホップ*/でない、ルート設定Table*/エントリーにおける/*は外観_Up_Dest_Route_Table(目的の_IP(ARP_Request))と等しいです。 目的地ではなく、(エントリー=NULL)/*であるなら、*/は戻ります。 /*は次のホップではなく、*の、そして、Not ARP Request*/ほかのIf(次の_Hop(エントリー!)はNULLと等しい)/地方の*/リターンを捨てます。 /*破棄ARP Request*/、(インタフェース(エントリー!)はPhys_Intと等しいです)/*が同じ身体検査であるに違いないなら、*/リターンを連結してください。 /*がARP要求*/を捨てる、(ARP_アシスタント_は、(エントリー!)がヌルと等しいと言い足します)、L_L_ARP_アシスタント_は=決心を加えます(ARP_アシスタント_は(エントリー)、Phys_Int、ヌルを加えます)。 (L_L_ARP_アシスタント_は=ヌルを加えます)フォワード(ARP_要求、ARP_アシスタント_が加えるL_L_、Phys_Int)であるなら。 ARPアシスタントアドレス*/リターンへの/*前進のARP_要求。 ほかの/*はローカルアドレス解決をします。 */ { ARP_Req_がレベル_ARP_Req_が加えるリンク_(目標_IP(ARP_要求)、Phys_Int)と等しいと言い足すL_L_。 (L_L_ARP_Req_は=ヌルを加えます){ /*ローカルアドレス解決手順はARPです。 *//*前進のARP_要求。 */フォワード(ARP_要求、L_ARP_Req_が加えるL_、Phys_Int)。 戻ってください。 ほか{ /*ローカルアドレス解決手順はARPではありません。 *//*はTarget IP Address*/目標_Link_Level=地方の_Add_Res(目標_IP(ARP_Request)、Phys_Int)を代表して「発行されたARP」をします。 (目的の_リンク_レベル!はヌルと等しいです)/*がアドレス*/を決議した、フォワード(ARP_応答、ソース_リンク_レベル(ARP_要求)、Phys_Int)。 戻ってください。 } } }
Figure 4: C Pseudo_Code for Directing ARP Requests.
図4: C疑似_は、ARPを指示するために要求をコード化します。
Garrett, Hagan & Wong [Page 9] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[9ページ]RFC1433
3.4 Filtering Procedures
3.4 手順をフィルターにかけること。
A router performing Directed ARP procedures must filter the propagation of ARP Request packets to constrain the scope of potential "ARP floods" caused by misbehaving routers or hosts, and to terminate potential ARP loops that may occur during periods of routing protocol instability or as a result of inappropriate manual configurations. Specific procedures to filter the propagation of ARP Request packets are beyond the scope of this document. The following procedures are suggested as potential implementations that should be sufficient. Other procedures may be better suited to a particular implementation.
Directed ARP手順を実行するルータは、ふらちな事をしているルータかホストによって引き起こされた潜在的「ARP洪水」の範囲を抑制して、ルーティング・プロトコルの不安定性の期間か不適当な手動の構成の結果、現れるかもしれない潜在的ARP輪を終えるためにARP Requestパケットの伝播をフィルターにかけなければなりません。 ARP Requestパケットの伝播をフィルターにかける特定の手順はこのドキュメントの範囲を超えています。 以下の手順は十分であるべき潜在的実装として示されます。 他の手順は特定の実装に合うほうがよいです。
To control the propagation of an "ARP flood", a router performing Directed ARP procedures could limit the number of identical ARP Requests (i.e., same Source IP address and same Target IP address) that it would forward per small time interval (e.g., no more than one ARP Request per second). This is consistent with the procedure suggested in [5] to prevent ARP flooding.
「ARP洪水」の伝播を制御するために、Directed ARP手順を実行するルータはそれが小さい時間間隔(例えば、1秒あたり1ARP Request)単位で進める同じARP Requests(すなわち、同じSource IPアドレスと同じTarget IPアドレス)の数を制限するかもしれません。 これはARP氾濫を防ぐために[5]に示される手順と一致しています。
Forwarding of ARP Request packets introduces the possibility of ARP loops. The procedures used to control the scope of potential ARP floods may terminate some ARP loops, but additional procedures are needed if the time required to traverse a loop is longer than the timer used to control ARP floods. A router could refuse to forward more than N identical ARP Requests per T minutes, where N and T are administered numbers. If T and N are chosen so that T/N minutes is greater than the maximum time required to traverse a loop, such a filter would terminate the loop. In some cases a host may send more than one ARP Request with the same Source IP address,Target IP address pair (i.e., N should be greater than 1). For example, the first ARP Request might be lost. However, once an ARP Response is received, a host would normally save the associated information, and therefore would not generate an identical ARP Request for a period of time on the order of minutes. Therefore, T may be large enough to ensure that T/N is much larger than the time to traverse any loop.
ARP Requestパケットの推進はARP輪の可能性を導入します。 潜在的ARP洪水の範囲を制御するのに用いられた手順はいくつかのARP輪を終えるかもしれませんが、輪を横断するのに必要である時間がタイマが以前はよくARP洪水を制御していたより長いなら、追加手順が必要です。 ルータは、T分あたりN同じARP Requestsを進めるのを拒否するかもしれません。(そこでは、NとTが管理された数です)。 したがって、TとNが選ばれているなら最大の時間が輪を横断するのが必要であるというよりもN分間のそのT/がすばらしい、そのようなフィルタは輪を終えるでしょう。 いくつかの場合、ホストは同じSource IPアドレスがある1ARP Requestを送るかもしれません、Target IPアドレス組(すなわち、Nは1以上であるべきです)。 例えば、最初のARP Requestはなくされるかもしれません。 しかしながら、ARP Responseがいったん受け取られているようになると、ホストは、通常、関連情報を保存して、したがって、数分の注文ときにしばらく、同じARP Requestを生成しないでしょう。 したがって、TはT/Nが確実にどんな輪も横断する時間よりはるかに大きくなるようにすることができるくらい大きいかもしれません。
In some implementations the link level destination address of a frame used to transport an ARP Request to a router may be available to the router's Directed ARP filtering process. An important class of simple ARP loops will be prevented from starting if a router never forwards an ARP Request to the same link level address to which the received ARP Request was addressed. Of course, other procedures such as the one described in the paragraph above will stop all loops, and are needed, even if filters are implemented that prevent some loops from starting.
フレームのリンク・レベル送付先アドレスが以前はよく輸送していたいくつかの実装では、ルータへのARP RequestはルータのDirected ARPろ過過程に利用可能であるかもしれません。 重要なクラスの簡単なARP輪はルータが容認されたARP Requestが扱われたのと同じリンク・レベルアドレスにARP Requestを決して送らないなら始まるのが防がれるでしょう。 もちろん、上のパラグラフで説明されたものなどの他の手順が、すべての輪を止めて、必要です、いくつかの輪が始動するのを防ぐフィルタが実装されても。
Garrett, Hagan & Wong [Page 10] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[10ページ]RFC1433
Host requirements [5] specify that "the packet receive interface between the IP layer and the link layer MUST include a flag to indicate whether the incoming packet was addressed to a link-level broadcast address." An important class of simple ARP floods can be eliminated if routers never forward ARP Requests that were addressed to a link-level broadcast address.
ホスト要件[5]は、「パケットがIP層の間のインタフェースを受けます、そして、リンクレイヤは入って来るパケットがリンク・レベル放送演説に扱われたかどうかを示すために旗を含まなければなりません。」と指定します。 ルータがリンク・レベル放送演説に扱われたARP Requestsを決して進めないなら、重要なクラスの簡単なARP洪水を排除できます。
4. Use of Directed ARP by Routing
4. 指示されたARPのルート設定による使用
The exchange and use of routing information is constrained by available address resolution procedures. A host or router can not use a next-hop IP address learned via dynamic routing procedures if it is unable to resolve the next-hop IP address to the associated link level address. Without compatible dynamic address resolution procedures, a router may not advertise a next-hop address that is not on the same IP network as the host or router receiving the advertisement. Directed ARP is a procedure that enables a router that advertises routing information to make the routing information useful by also providing assistance in resolving the associated next-hop IP addresses.
ルーティング情報の交換と使用は利用可能なアドレス解決手順で抑制されます。 ホストかルータが次のホップIPアドレスを関連リンク・レベルアドレスに決議できないならダイナミックルーティング手順で学習された次のホップIPアドレスを使用できません。 コンパチブルダイナミックなアドレス解決手順がなければ、ルータは広告を受け取りながらホストかルータと同じIPネットワークにない次のホップアドレスの広告を出さないかもしれません。 指示されたARPはまた、関連次のホップIPアドレスを決議するのに支援を提供することによってルーティング情報を役に立つようにするように情報を発送するそれが広告を出すルータを可能にする手順です。
The following subsections describe the use of Directed ARP to expand the scope of ICMP Redirects [6], distance-vector routing protocols (e.g., BGP [3]), and link-state routing protocols (e.g., OSPF [4]).
以下の小区分はICMP Redirects[6]の範囲を広げるためにDirected ARPの使用について説明します、距離ベクトルルーティング・プロトコル、(例えば、BGP[3])、およびLinkState方式プロトコル、(例えば、OSPF[4])。
4.1 ICMP Redirect
4.1ICMP再直接です。
If a router forwards a packet to a next-hop address that is on the same link level network as the host that originated the packet, the router may send an ICMP Redirect to the host. But a host can not use a next-hop address advertised via an ICMP Redirect unless the host has a procedure to resolve the advertised next-hop address to its associated link level address. Directed ARP is a procedure that a host could use to resolve an advertised next-hop address, even if the host does not have an address on the same IP network as the advertised next-hop address.
ルータがパケットを溯源したホストと同じリンク・レベルネットワークにある次のホップアドレスにパケットを送るなら、ルータはICMP Redirectをホストに送るかもしれません。 しかし、ホストは、広告を出している次のホップアドレスを関連リンク・レベルアドレスに決議するのにホストに手順がない場合ICMP Redirectを通しての広告に掲載された次のホップアドレスを使用できません。 指示されたARPはホストが広告を出している次のホップアドレスを決議するのに用いることができた手順です、ホストに広告を出している次のホップアドレスと同じIPネットワークに関するアドレスがなくても。
A host that implements Directed ARP procedures includes an ARP Helper Address with each routing table entry. The ARP Helper Address associated with an entry learned via an ICMP Redirect is NULL if the associated next-hop address matches a routing table entry with a NULL next-hop and a NULL ARP Helper Address (i.e., the host already knows how to resolve the next-hop address). Otherwise, the ARP Helper Address is the IP address of the router that sent the ICMP Redirect. Note that the router that sent the ICMP Redirect is the current next-hop to the advertised destination [5]. Therefore, the host should have an entry in its address resolution table for the new ARP Helper Address. If the host is unable to resolve the next-hop IP
Directed ARPに手順を実装するホストはそれぞれの経路指定テーブルエントリーがあるARP Helper Addressを入れます。 関連次のホップアドレスがNULL次ホップとNULL ARP Helper Addressに経路指定テーブルエントリーに合っているなら(すなわち、ホストは既に次のホップアドレスを決議する方法を知ります)、ICMP Redirectを通して学習されるエントリーに関連しているARP Helper AddressはNULLです。 さもなければ、ARP Helper AddressはICMP Redirectを送ったルータのIPアドレスです。 ICMP Redirectを送ったルータが広告を出している目的地[5]への現在の次のホップであることに注意してください。 したがって、ホストは新しいARP Helper Addressのためのアドレス解決テーブルにエントリーを持つべきです。 ホストが次のホップIPを決議できないなら
Garrett, Hagan & Wong [Page 11] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[11ページ]RFC1433
address advertised in the ICMP Redirect (e.g., because the associated ARP Helper Address is on a foreign IP network; i.e., was learned via an old ICMP Redirect, and the address resolution table entry for that ARP Helper Address timed out), the host must flush the associated routing table entry. Directed ARP procedures do not recursively use Directed ARP to resolve an ARP Helper Address.
アドレスがICMP Redirectに広告を出した、(例えば、関連ARP Helper Addressが外国IPネットワークにあります; すなわち、外で調節されたそのARP Helper Addressのために古いICMP Redirect、およびアドレス解決テーブルエントリーを通って学習された、)、ホストは関連経路指定テーブルエントリーを洗い流さなければなりません。 指示されたARP手順は、ARP Helper Addressを決議するのにDirected ARPを再帰的に使用しません。
A router that performs Directed ARP procedures might advertise a foreign next-hop to a host that does not perform Directed ARP. Following existing procedures, the host would silently discard the ICMP Redirect. A router that does not implement Directed ARP should not advertise a next-hop on a foreign IP network, as specified by existing procedures. If it did, and the ICMP Redirect was received by a host that implemented Directed ARP procedures, the host would send an ARP Request for the foreign IP address to the advertising router, which would silently discard the ARP Request. When address resolution fails, the host should flush the associated entry from its routing table.
Directed ARP手順を実行するルータはDirected ARPを実行しないホストに外国次のホップの広告を出すかもしれません。 既存の手順に従って、ホストは静かにICMP Redirectを捨てるでしょう。 Directed ARPを実装しないルータは外国IPネットワークに次のホップの広告を出すべきではありません、既存の手順で指定されるように。 そうして、ICMP RedirectがDirected ARPに手順を実装したホストによって受け取られるなら、ホストは外国IPアドレスのために広告ルータにARP Requestを送るでしょうに。(静かに、それは、ARP Requestを捨てるでしょう)。 アドレス解決が失敗すると、ホストは経路指定テーブルから関連エントリーを洗い流すべきです。
For various reasons a host may ignore an ICMP Redirect and may continue to forward packets to the same router that sent the ICMP Redirect. For example, a host that does not implement Directed ARP procedures would silently discard an ICMP Redirect advertising a next-hop address on a foreign IP network. Routers should implement constraints to control the number of ICMP Redirects sent to hosts. For example, a router might limit the number of repeated ICMP Redirects sent to a host to no more than N ICMP Redirects per T minutes, where N and T are administered values.
ホストが、ICMP Redirectを無視して、同じルータにパケットを送り続けるかもしれない様々な理由で、それはICMP Redirectを送りました。 例えば、Directed ARPに手順を実装しないホストは静かに外国IPネットワークに関する次のホップアドレスの広告を出すICMP Redirectを捨てるでしょう。 ルータはホストに送られたICMP Redirectsの数を制御するという規制を実装するべきです。 例えば、ルータはN ICMP RedirectsだけのT分あたり1人のホストに送られた繰り返されたICMP Redirectsの数を制限するかもしれません。(そこでは、NとTが管理された値です)。
4.2 Distance Vector Routing Protocol
4.2 DistanceVector方式プロトコル
A distance-vector routing protocol provides procedures for a router to advertise a destination address (e.g., an IP network), an associated next-hop address, and other information (e.g., associated metric). But a router can not use an advertised route unless the router has a procedure to resolve the advertised next-hop address to its associated link level address. Directed ARP is a procedure that a router could use to resolve an advertised next-hop address, even if the router does not have an address on the same IP network as the advertised next-hop address.
距離ベクトルルーティング・プロトコルは、送付先アドレス(例えば、IPネットワーク)、関連次のホップアドレス、および他の情報(例えば、メートル法で、交際する)の広告を出すために手順をルータに提供します。 しかし、ルータに広告を出している次のホップアドレスを関連リンク・レベルアドレスに決議する手順がない場合、ルータは広告を出しているルートを使用できません。 指示されたARPはルータが広告を出している次のホップアドレスを決議するのに用いることができた手順です、ルータに広告を出している次のホップアドレスと同じIPネットワークに関するアドレスがなくても。
The following procedures assume a router only accepts routing updates if it knows the IP address of the sender of the update, can resolve the IP address of the sender to its associated link level address, and has an interface on the same link level network as the sender.
以下の手順は、アップデートのIP送信者のアドレスを知っていて、関連リンク・レベルアドレスにIP送信者のアドレスを決議できて、送付者と同じリンク・レベルネットワークにインタフェースを持っている場合にだけルータがルーティングアップデートを受け入れると仮定します。
A router that implements Directed ARP procedures includes an ARP Helper Address with each routing table entry. The ARP Helper Address
Directed ARPに手順を実装するルータはそれぞれの経路指定テーブルエントリーがあるARP Helper Addressを含んでいます。 ARPアシスタントアドレス
Garrett, Hagan & Wong [Page 12] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[12ページ]RFC1433
associated with an entry learned via a routing protocol update is NULL if the associated next-hop address matches a routing table entry with a NULL next-hop and NULL ARP Helper Address (i.e., the router already knows how to resolve the next-hop address). Otherwise, the ARP Helper Address is the IP address of the router that sent the routing update.
関連次のホップアドレスがNULLが次のホップであることでの経路指定テーブルエントリーとNULL ARP Helper Addressに合っているなら(すなわち、ルータは既に次のホップアドレスを決議する方法を知ります)、ルーティング・プロトコルアップデートで学習されるエントリーに関連しているのは、NULLです。 さもなければ、ARP Helper Addressはルーティングアップデートを送ったルータのIPアドレスです。
Some distance-vector routing protocols (e.g., BGP [3]) provide syntax that would permit a router to advertise an address on a foreign IP network as a next-hop. If a router that implements Directed ARP procedures advertises a foreign next-hop IP address to a second router that does not implement Directed ARP procedures, the second router can not use the advertised foreign next-hop. Depending on the details of the routing protocol implementation, it might be appropriate for the first router to also advertise a next-hop that is not on a foreign IP network (e.g., itself), perhaps at a higher cost. Or, if the routing relationship is an administered connection (e.g., BGP relationships are administered TCP/IP connections), the administrative procedure could determine whether foreign next-hop IP addresses should be advertised.
いくつかの距離ベクトルルーティング・プロトコル、(例えば、BGP[3])は、次のホップとして外国IPネットワークに関するアドレスの広告を出すために可能にする構文にルータを提供します。 Directed ARPに手順を実装するルータがDirected ARPに手順を実装しない2番目のルータに外国次のホップIPアドレスの広告を出すなら、2番目のルータは広告を出している外国次のホップを使用できません。 ルーティング・プロトコル実装の詳細によって、最初のルータに、また、外国IPネットワーク(例えば、それ自体)にない次のホップの広告を出すのは適切であるかもしれません、恐らくより高い費用で。 または、ルーティング関係が管理された接続(例えば、BGP関係は管理されたTCP/IP接続である)であるなら、行政手続は、外国次のホップIPアドレスが広告を出すべきであるかどうか決定するかもしれません。
A distance-vector routing protocol could advertise that a destination is directly reachable by specifying that the router receiving the advertisement is, itself, the next-hop to the destination. In addition, the advertised metric for the route might be zero. If the router did not already have a routing table entry that specified the advertised destination was local (i.e., NULL next-hop address), the router could add the new route with NULL next-hop, and the IP address of the router that sent the update as ARP Helper Address.
距離ベクトルルーティング・プロトコルは、広告を受け取るルータがそうであると指定することによって目的地に直接届いているのは広告を出すかもしれません、それ自体、目的地への次ホップ。 さらに、ルートにおける、メートル法の広告を出すのはゼロであるかもしれません。 ルータに指定した経路指定テーブルエントリーが既になかったなら広告を出している目的地が地方であった(すなわち、NULL次のホップアドレス)、ルータはNULLが次のホップであることでの新しいルート、およびARP Helper Addressとしてアップデートを送ったルータのIPアドレスを加えるかもしれません。
4.3 Link State Routing Protocol
4.3 リンク州のルーティング・プロトコル
A link-state routing protocol provides procedures for routers to identify links to other entities (e.g., other routers and networks), determine the state or cost of those links, reliably distribute link-state information to other routers in the routing domain, and calculate routes based on link-state information received from other routers. A router with an interface to two (or more) IP networks via the same link level interface is connected to those IP networks via a single link, as described above. If a router could advertise that it used the same link to connect to two (or more) IP networks, and would perform Directed ARP procedures, routers on either of the IP networks could forward packets directly to hosts and routers on both IP networks, using Directed ARP procedures to resolve addresses on the foreign IP network. With Directed ARP, the cost of the direct path to the foreign IP network would be less than the cost of the path through the router with addresses on both IP networks.
LinkState方式プロトコルは、他の実体(例えば、他のルータとネットワーク)へのリンクを特定して、それらのリンクの状態か費用を決定して、経路ドメインの他のルータにリンク州の情報を確かに分配して、他のルータから受け取られたリンク州の情報に基づくルートを計算するために手順をルータに提供します。 同じリンク・レベルインタフェースを通して2つ(さらに)のIPネットワークへのインタフェースがあるルータは単一のリンクを通してそれらのIPネットワークに関連づけられます、上で説明されるように。 ルータが2つ(さらに)のIPネットワークに接続するのに同じリンクを使用したのは広告を出すことができて、Directed ARP手順を実行するなら、IPネットワークのどちらかのルータは両方のIPネットワークで直接ホストとルータにパケットを送るかもしれません、外国IPネットワークに関するアドレスを決議するのにDirected ARP手順を用いて。 Directed ARP、外国IPネットワークへの直接路の費用と共に、両方のIPネットワークに関するアドレスがあるルータを通した経路の費用以下があるでしょう。
Garrett, Hagan & Wong [Page 13] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[13ページ]RFC1433
To benefit from Directed ARP procedures, the link-state routing protocol must include procedures for a router to advertise connectivity to multiple IP networks via the same link, and the routing table calculation process must include procedures to calculate ARP Helper Addresses and procedures to accurately calculate the reduced cost of the path to a foreign IP network reached directly via Directed ARP procedures.
Directed ARP手順の利益を得るなら、LinkState方式プロトコルは同じリンクを通して複数のIPネットワークに接続性の広告を出すためにルータのための手順を含まなければなりません、そして、経路指定テーブル計算過程は正確に直接Directed ARP手順で達した外国IPネットワークに経路の割引料金について計算するためにARP Helper Addressesと手順について計算するために手順を含まなければなりません。
The Shortest Path First algorithm for calculating least cost routes is based on work by Dijkstra [7], and was first used in a routing protocol by the ARPANET, as described by McQuillan [8]. A router constructs its routing table by building a shortest path tree, with itself as root. The process is iterative, starting with no entries on the shortest path tree, and the router, itself, as the only entry in a list of candidate vertices. The router then loops on the following two steps.
計算の最小費用ルートへのShortest Path Firstアルゴリズムは、ダイクストラ[7]で仕事に基づいて、最初にアルパネットによってルーティング・プロトコルに使用されました、マッキラン[8]によって説明されるように。 ルータは、根としてそれ自体で最短パス木を建てることによって、経路指定テーブルを組み立てます。 プロセスは繰り返しです、最短パス木、およびルータでエントリーから全く始めないで、それ自体、候補頭頂のリストにおける唯一のエントリーとして。 そして、ルータは以下の2ステップのときに輪にされます。
1. Remove the entry from the candidate list that is closest to
root, and add it to the shortest path tree.
1. それを根づいて、加えるために最も近くにある候補リストから最短パス木までのエントリーを取り除いてください。
2. Examine the link state advertisement from the entry added to
the shortest path tree in step 1. For each neighbor (i.e.,
router or IP network to which a link connects)
2. ステップ1における最短パス木に加えられたエントリーからリンク州の広告を調べてください。 各隣人のために(リンクが接続するすなわち、ルータかIPネットワーク)
- If the neighbor is already on the shortest path tree, do
nothing.
- 隣人が最短パス木の上に既にいるなら、何もしないでください。
- If the neighbor is on the candidate list, recalculate the
distance from root to the neighbor. Also recalculate the
next-hop(s) to the neighbor.
- 隣人がオンであるなら、候補は記載して、根から隣人までrecalculateは距離です。 隣人への次のrecalculateホップも。
- If the neighbor is not on the candidate list, calculate
the distance from root to the neighbor and the next-hop(s)
from root to the neighbor, and add the neighbor to the
candidate list.
- 隣人が候補リストにいないなら、根から隣人と次のホップまで距離について根から隣人まで計算してください、そして、候補リストに隣人を追加してください。
The process terminates when there are no entries on the candidate list.
エントリーが全く候補リストにないとき、プロセスは終わります。
To take advantage of Directed ARP procedures, the link-state protocol must provide procedures to advertise that a router accesses two or more IP networks via the same link. In addition, the Shortest Path First calculation is modified to calculate ARP Helper Addresses and recognize path cost reductions achieved via Directed ARP.
Directed ARP手順を利用するなら、リンク州のプロトコルは、ルータが同じリンクを通して2つ以上のIPネットワークにアクセスするのは広告を出すために手順を提供しなければなりません。 さらに、Shortest Path First計算は、ARP Helper Addressesについて計算して、Directed ARPを通して達成された経路コスト削減を認識するように変更されます。
1. If a neighbor under consideration is an IP network, and its
parent (i.e., the entry added to the shortest path tree in step
1, above) has advertised that the neighbor is reached via the
same link as a network that is already on the shortest path
1. 考慮している隣人がIPネットワークであり、親(すなわち、上でのステップ1における最短パス木に加えられたエントリー)が、隣人が最短パスに既にあるネットワークと同じリンクを通して連絡されているのは広告を出したなら
Garrett, Hagan & Wong [Page 14] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[14ページ]RFC1433
tree, the distance from root and next-hop(s) from root to the
neighbor are the same as the distance and next-hop(s)
associated with the network already on the shortest path tree.
If the ARP Helper Address associated with the network that is
already on the shortest path tree is not NULL, the neighbor
also inherits the ARP Helper Address from the network that is
already on the shortest path tree.
木、根からの距離と次の根から隣人までのホップは最短パス木で距離と次のホップが既にネットワークと交際したのと同じです。 また、最短パス木の上に既にあるネットワークに関連しているARP Helper AddressがNULLでないなら、隣人は最短パス木の上に既にあるネットワークからARP Helper Addressを引き継ぎます。
2. If the calculated next-hop to the neighbor is not NULL, the
neighbor inherits the ARP Helper Address from its parent.
Otherwise, except as described in item 1, the ARP Helper
Address is the IP address of the next-hop to the neighbor's
parent. Note that the next-hop to root is NULL.
2. 隣人への計算された次のホップがNULLでないなら、隣人は親からARP Helper Addressを引き継ぎます。 さもなければ、項目1で説明されるのを除いて、ARP Helper Addressは隣人の親への次のホップのIPアドレスです。 根づかせる次のホップがNULLであることに注意してください。
For each router or IP network on the shortest path tree, the Shortest Path First algorithm described above must calculate one or more next-hops that can be used to access the router or IP network. A router that advertises a link to an IP network must include an IP address that can be used by other routers on the IP network when using the router as a next-hop. A router might advertise that it was connected to two IP networks via the same link by advertising the same next-hop IP address for access from both IP networks. To accommodate the address resolution constraints of routers on both IP networks the router might advertise two IP addresses (one from each IP network) as next-hop IP addresses for access from both IP networks.
最短パス木の上のそれぞれのルータかIPネットワークのために、上で説明されたShortest Path FirstアルゴリズムはルータかIPネットワークにアクセスするのに使用できる1つ以上の次のホップについて計算しなければなりません。 IPネットワークへのリンクの広告を出すルータは次のホップとしてルータを使用するときIPネットワークの他のルータで使用できるIPアドレスを含まなければなりません。 ルータは、それが両方のIPネットワークからアクセスのための同じ次のホップIPアドレスの広告を出すのによる同じリンクを通して2つのIPネットワークに関連づけられたのは広告を出すかもしれません。 両方のIPネットワークにおけるルータのアドレス解決規制を収容するために、ルータはアクセスのための次のホップIPアドレスとして両方のIPネットワークから2つのIPアドレス(それぞれのIPネットワークからの1)の広告を出すかもしれません。
5. Robustness
5. 丈夫さ
Hosts and routers can use Directed ARP to resolve third-party next- hop addresses; i.e., next-hop addresses learned from a routing protocol peer or current next-hop router. Undetected failure of a third party next-hop can result in a routing "black hole". To avoid "black holes", host requirements [5] specify that a host "...MUST be able to detect the failure of a 'next-hop' gateway that is listed in its route cache and to choose an alternate gateway." A host may receive feedback from protocol layers above IP (e.g., TCP) that indicates the status of a next-hop router, and may use other procedures (e.g., ICMP echo) to test the status of a next-hop router. But the complexity of routing is borne by routers, whose routing information must be consistent with the information known to their peers. Routing protocols such as BGP [3], OSPF [4], and others, require that routers must stand behind routing information that they advertise. Routers tag routing information with the IP address of the router that advertised the information. If the information becomes invalid, the router that advertised the information must advertise that the old information is no longer valid. If a source of routing information becomes unavailable, all information received
ホストとルータは次のホップが演説する第三者を決議するのにDirected ARPを使用できます。 すなわち、次のホップアドレスはルーティング・プロトコル同輩か現在の次のホップルータから学びました。 ルーティング「ブラックホール」で第三者次のホップ缶の結果の失敗をUndetectedしました。 「「ブラックホール」を避けるために、ホスト要件[5]はそのaホストを指定します」…「経路キャッシュで記載されている'次のホップ'ゲートウェイの失敗を検出して、代替のゲートウェイを選ぶことができなければなりません」 ホストは、次のホップルータの状態を示すIP(例えば、TCP)の上のプロトコル層から反響を調べて、次のホップルータの状態をテストするのに、他の手順(例えば、ICMPは反響する)を用いるかもしれません。 しかし、ルーティングの複雑さはルーティング情報が彼らの同輩にとって知られている情報と一致しているに違いないルータで生まれます。 BGP[3]などのルーティング・プロトコル(OSPF[4]、および他のもの)は、ルータが広告を出すというルーティング情報の後ろに立たなければならないのを必要とします。 ルータは情報の広告を出したルータのIPアドレスをルーティング情報にタグ付けします。 情報が無効になるなら、情報の広告を出したルータは、旧情報がもう有効でないことは広告を出さなければなりません。 すべての情報が、ルーティング情報の源が入手できなくなるのを受けたなら
Garrett, Hagan & Wong [Page 15] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[15ページ]RFC1433
from that source must be marked as no longer valid. The complexity of dynamic routing protocols stems from procedures to ensure routers either receive routing updates sent by a peer, or are able to determine that they did not receive the updates (e.g., because connectivity to the peer is no longer available).
そのソースから、もう有効でないとしてマークしなければなりません。 ダイナミックルーティングプロトコルの複雑さはルータが、同輩によって送られたルーティングアップデートを受けるか、またはアップデートを受けなかったことを決定できるのを(例えば、同輩への接続性がもう利用可能でないので)保証する手順によります。
Third-party next-hops can also result in "black holes" if the underlying link layer network connectivity is not transitive. For example, SMDS filters [9] could be administered to permit communication between the SMDS addresses of router R1 and router R2, and between the SMDS addresses of router R2 and router R3, and to block communication between the SMDS addresses of router R1 and router R3. Router R2 could advertise router R3 as a next-hop to router R1, but SMDS filters would prevent direct communication between router R1 and router R3. Non-symmetric filters might permit router R3 to send packets to router R1, but block packets sent by router R1 addressed to router R3.
また、基本的なリンクレイヤネットワークの接続性が遷移的でないなら、第三者次ホップは「ブラックホール」をもたらすことができます。 例えば、ルータR1とルータR2のSMDSアドレスと、ルータR2とルータR3のSMDSアドレスとのコミュニケーションを可能にして、ルータR1とルータR3のSMDSアドレスのコミュニケーションを妨げるためにSMDSフィルタ[9]を管理できました。 ルータR2は次のホップとしてルータR1にルータR3の広告を出すことができましたが、SMDSフィルタはルータR1とルータR3とのダイレクトコミュニケーションを防ぐでしょう。 非左右対称のフィルタは、ルータR3がルータR1にパケットを送るのを可能にするかもしれませんが、ルータR1によって送られたブロックパケットはルータにR3を扱いました。
A host or router could verify link level connectivity with a next-hop router by sending an ICMP echo to the link level address of the next-hop router. (Note that the ICMP echo is sent directly to the link level address of the next-hop router, and is not routed to the IP address of the next-hop router. If the ICMP echo is routed, it may follow a path that does not verify link level connectivity.) This test could be performed before adding the associated routing table entry, or before the first use of the routing table entry. Detection of subsequent changes in link level connectivity is a dynamic routing protocol issue and is beyond the scope of this memo.
ホストかルータが、次のホップルータのリンク・レベルアドレスにICMPエコーを送ることによって、次のホップルータがあるリンク・レベルの接続性について確かめるかもしれません。 (ICMPエコーが直接次のホップルータのリンク・レベルアドレスに送られて、次のホップルータのIPアドレスに発送されないことに注意してください。 ICMPエコーが発送されるなら、それはリンク・レベルの接続性について確かめない経路に続くかもしれません。) 関連経路指定テーブルエントリーを加える前、または経路指定テーブルエントリーの最初の使用の前にこのテストを実行できました。 リンク・レベルの接続性におけるその後の変化の検出は、ダイナミックルーティングプロトコル問題であり、このメモの範囲を超えています。
References
参照
[1] Piscitello, D., and J. Lawrence, "The Transmission of IP
Datagrams over the SMDS Service", RFC 1209, Bell Communications
Research, March 1991.
[1]Piscitello、D.、およびJ.ローレンス、「SMDSサービスの上のIPデータグラムの送信」、RFC1209、ベルコミュニケーションズ・リサーチ(1991年3月)。
[2] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", RFC 826, Symbolics, Inc.,
November 1982.
[2] プラマー、D.、「イーサネットは解決プロトコルを扱います--、イーサネットハードウェアの上でトランスミッションのための48.bitイーサネットアドレスにネットワーク・プロトコルアドレスを変換する、」、RFC826、シンボリックス(1982年11月)
[3] Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-
3)", RFC 1267, cisco Systems and IBM T. J. Watson Research
Center, October 1991.
[3] ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP3)」、RFC1267、コクチマスSystemsとIBM T.J.ワトソン研究所(1991年10月)。
[4] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.
[4]Moy、J.、「OSPF、バージョン2インチ、RFC1247、Proteon Inc.、1991インチ年7月。
[5] Braden, R., editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, USC/Information Sciences
[5] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、USC/情報Sciences
Garrett, Hagan & Wong [Page 16] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[16ページ]RFC1433
Institute, October 1989.
1989年10月に、設けます。
[6] Postel, J., "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification", STD 5, RFC 792, USC/Information
Sciences Institute, September 1981.
[6] ポステル、J.、「インターネットはメッセージプロトコルを制御します--DARPAインターネットプログラムプロトコル仕様」、STD5、RFC792、科学が設けるUSC/情報、1981年9月。
[7] Dijkstra, E. W., "A Note on Two Problems in Connection with
Graphs", Numerische Mathematik, Vol. 1, pp. 269-271, 1959.
[7] ダイクストラ、E.W.、「グラフに関する2つの問題に関する注」、Numerische Mathematik、Vol.1、ページ 269-271, 1959.
[8] McQuillan, J. M., I. Richer, and E. C. Rosen, "The New Routing
Algorithm for the ARPANET", IEEE Transactions on Communications,
Vol. COM-28, May 1980.
[8] マッキラン、J.M.、I.リシェ、およびE.C.ローゼン、「アルパネットのための新しいルーティング・アルゴリズム」(コミュニケーションに関するIEEEトランザクション、Vol.COM-28)は1980がそうするかもしれません。
[9] "Generic System Requirements In Support of Switched Multi-
megabit Data Service", Technical Reference TR-TSV-000772, Bell
Communications Research Technical Reference, Issue 1, May 1991.
[9] 「Switched MultiメガビットData ServiceのジェネリックSystem Requirements In Support」、Technical Reference TR-TSV-000772、ベルコミュニケーションズ・リサーチTechnical Reference、Issue1(1991年5月)。
Garrett, Hagan & Wong [Page 17] RFC 1433 Directed ARP March 1993
ギャレット、ハーガン、および1993年のARP行進のときに指示されたウォン[17ページ]RFC1433
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
John Garrett AT&T Bell Laboratories 184 Liberty Corner Road Warren, N.J. 07060-0906
ジョンギャレットAT&Tベル研究所184の自由コーナーRoadウォレン、ニュージャージー州07060-0906
Phone: (908) 580-4719 EMail: jwg@garage.att.com
以下に電話をしてください。 (908) 580-4719 メールしてください: jwg@garage.att.com
John Dotts Hagan University of Pennsylvania Suite 221A 3401 Walnut Street Philadelphia, PA 19104-6228
クルミ通りフィラデルフィア、ジョンDottsハーガンペンシルバニア大学スイート221A3401PA19104-6228
Phone: (215) 898-9192 EMail: Hagan@UPENN.EDU
以下に電話をしてください。 (215) 898-9192 メールしてください: Hagan@UPENN.EDU
Jeffrey A. Wong AT&T Bell Laboratories 184 Liberty Corner Road Warren, N.J. 07060-0906
ジェフリーA.ウォンAT&Tベル研究所184の自由コーナーRoadウォレン、ニュージャージー州07060-0906
Phone: (908) 580-5361 EMail: jwong@garage.att.com
以下に電話をしてください。 (908) 580-5361 メールしてください: jwong@garage.att.com
Garrett, Hagan & Wong [Page 18]
ギャレット、ハーガン、およびウォン[18ページ]
一覧
スポンサーリンク
