RFC2453 日本語訳
2453 RIP Version 2. G. Malkin. November 1998. (Format: TXT=98462 bytes) (Obsoletes RFC1723) (Updated by RFC4822) (Also STD0056) (Status: STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Malkin Request for Comments: 2453 Bay Networks Obsoletes: 1723, 1388 November 1998 STD: 56 Category: Standards Track
コメントを求めるワーキンググループG.マルキンの要求をネットワークでつないでください: 2453 ベイネットワークスは以下を時代遅れにします。 1723、1388 1998年11月のSTD: 56カテゴリ: 標準化過程
RIP Version 2
バージョン2をコピーしてください。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document specifies an extension of the Routing Information Protocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP messages and to add a measure of security.
このドキュメントはルーティング情報プロトコル(RIP)の拡大を指定します、RIPメッセージで運ばれた役に立つ情報の量を広げて、セキュリティの基準を加えるために[1]で定義されるように。
A companion document will define the SNMP MIB objects for RIP-2 [2]. An additional document will define cryptographic security improvements for RIP-2 [3].
仲間ドキュメントはRIP-2[2]のためにSNMP MIB物を定義するでしょう。 追加ドキュメントはRIP-2[3]のために暗号のセキュリティ改良を定義するでしょう。
Acknowledgements
承認
I would like to thank the IETF RIP Working Group for their help in improving the RIP-2 protocol. Much of the text for the background discussions about distance vector protocols and some of the descriptions of the operation of RIP were taken from "Routing Information Protocol" by C. Hedrick [1]. Some of the final editing on the document was done by Scott Bradner.
彼らの助けについてRIP-2プロトコルを改良する際にIETF RIP作業部会に感謝申し上げます。 距離ベクトルプロトコルについてのバックグラウンド議論とRIPの操作の記述のいくつかのテキストの多くがC.ヘドリック[1]によって「ルーティング情報プロトコル」から取られました。 ドキュメントにおける最終的な編集のいくつかがスコット・ブラドナーによって行われました。
Malkin Standards Track [Page 1] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[1ページ]RFC2453はバージョン1998年11月2日を裂きます。
Table of Contents
目次
1. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Basic Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Limitations of the Protocol . . . . . . . . . . . . . . . . 5 3.3. Organization of this document . . . . . . . . . . . . . . . 6 3.4 Distance Vector Algorithms . . . . . . . . . . . . . . . . . 6 3.4.1 Dealing with changes in topology . . . . . . . . . . . . 12 3.4.2 Preventing instability . . . . . . . . . . . . . . . . . 13 3.4.3 Split horizon . . . . . . . . . . . . . . . . . . . . . . 15 3.4.4 Triggered updates . . . . . . . . . . . . . . . . . . . . 17 3.5 Protocol Specification . . . . . . . . . . . . . . . . . . 18 3.6 Message Format . . . . . . . . . . . . . . . . . . . . . . . 20 3.7 Addressing Considerations . . . . . . . . . . . . . . . . . 22 3.8 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.9 Input Processing . . . . . . . . . . . . . . . . . . . . . . 25 3.9.1 Request Messages . . . . . . . . . . . . . . . . . . . . 25 3.9.2 Response Messages . . . . . . . . . . . . . . . . . . . . 26 3.10 Output Processing . . . . . . . . . . . . . . . . . . . . . 28 3.10.1 Triggered Updates . . . . . . . . . . . . . . . . . . . . 29 3.10.2 Generating Response Messages. . . . . . . . . . . . . . . 30 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 31 4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . 32 4.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.5 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 33 4.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 34 5.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 34 5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34 5.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . 35 5.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . 35 6. Interaction between version 1 and version 2 . . . . . . . . . 35 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 39
1. 正当化. . . . . . . . . . . . . . . . . . . . . . . . 3 2。 潮境. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 プロトコル. . . . . . . . . . . . . . . . 5 3.3の基本プロトコル. . . . . . . . . . . . . . . . . . . . . . . . 3 3.1序論. . . . . . . . . . . . . . . . . . . . . . . 3 3.2制限。 この組織が.63.4Distance Vector Algorithmsを記録する、.63.4、.1Dealing、トポロジー. . . . . . . . . . . . 12 3.4.2Preventingの不安定性における変化で…; 13 3.4 .3 分裂地平線. . . . . . . . . . . . . . . . . . . . . . 15 3.4.4Triggeredは.173.5プロトコルSpecification. . . . . . . . . . . . . . . . . . 18 3.6Message Formatをアップデートします…; .203.7 問題. . . . . . . . . . . . . . . . . 22 3.8をタイマ. . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.9入力処理. . . . . . . . . . . . . . . . . . . . . . 25 3.9.1の要求メッセージ. . . . . . . . . . . . . . . . . . . . 25 3.9.2の応答メッセージ. . . . . . . . . . . . . . . . . . . . 26 3.10の出力処理. . . . . . . . . . . . . . . . . . . . . 28 3.10.1が引き金となった記述すると、.2発生Respoは.29 3.10にアップデートされます。nse Messages。 . . . . . . . . . . . . . . 30 4. 拡大. . . . . . . . . . . . . . . . . . . . . 31 4.1認証. . . . . . . . . . . . . . . . . . . . . . . 31 4.2ルートタグ. . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3サブネットマスク. . . . . . . . . . . . . . . . . . . . . . . . 32 4.4次のホップ. . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.5マルチキャスティング. . . . . . . . . . . . . . . . . . . . . . . . 33 4.6質問. . . . . . . . . . . . . . . . . . . . . . . . . . 33 5を議定書の中で述べてください。 互換性. . . . . . . . . . . . . . . . . . . . . . . . 34 5.1互換性スイッチ. . . . . . . . . . . . . . . . . . . . 34 5.2認証. . . . . . . . . . . . . . . . . . . . . . . 34 5.3の、より大きい無限. . . . . . . . . . . . . . . . . . . . . . 35 5.4Addresslessは.356をリンクします。 バージョン1とバージョン2.357の間の相互作用。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 36付録. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37参照. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37作者のアドレスの.38の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 39
Malkin Standards Track [Page 2] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[2ページ]RFC2453はバージョン1998年11月2日を裂きます。
1. Justification
1. 正当化
With the advent of OSPF and IS-IS, there are those who believe that RIP is obsolete. While it is true that the newer IGP routing protocols are far superior to RIP, RIP does have some advantages. Primarily, in a small network, RIP has very little overhead in terms of bandwidth used and configuration and management time. RIP is also very easy to implement, especially in relation to the newer IGPs.
そして、OSPFの到来、-、RIPが時代遅れであると信じている人がいます。 RIPより新しいIGPルーティング・プロトコルがはるかに優れているのが、本当である間、RIPには、いくつかの利点があります。 主として、小さいネットワークでは、RIPはほとんど、そして、帯域幅に関するオーバーヘッドが使用しなかった構成、および管理時間を持っています。 また、RIPは特により新しいIGPsと関連して非常に実行しやすいです。
Additionally, there are many, many more RIP implementations in the field than OSPF and IS-IS combined. It is likely to remain that way for some years yet.
そして、さらに、多くの、より多くのRIP実現がOSPFよりその分野にある、-、結合されています。 それはそのように数年間まだ残っていそうです。
Given that RIP will be useful in many environments for some period of time, it is reasonable to increase RIP's usefulness. This is especially true since the gain is far greater than the expense of the change.
RIPが多くの環境でいつかの期間の役に立つなら、RIPの有用性を増加させるのは妥当です。 利得が変化の費用よりはるかにすばらしいので、これは特に本当です。
2. Current RIP
2. 潮境
The current RIP-1 message contains the minimal amount of information necessary for routers to route messages through a network. It also contains a large amount of unused space, owing to its origins.
現在のRIP-1メッセージはルータがネットワークを通してメッセージを発送するのに必要な最小量の情報量を含んでいます。 また、それは起源のために多量の未使用のスペースを含んでいます。
The current RIP-1 protocol does not consider autonomous systems and IGP/EGP interactions, subnetting [11], and authentication since implementations of these postdate RIP-1. The lack of subnet masks is a particularly serious problem for routers since they need a subnet mask to know how to determine a route. If a RIP-1 route is a network route (all non-network bits 0), the subnet mask equals the network mask. However, if some of the non-network bits are set, the router cannot determine the subnet mask. Worse still, the router cannot determine if the RIP-1 route is a subnet route or a host route. Currently, some routers simply choose the subnet mask of the interface over which the route was learned and determine the route type from that.
これらの実現がRIP-1に先日付を書くので、現在のRIP-1プロトコルは、自律システムとIGP/EGPが相互作用と、サブネッティング[11]と、認証であると考えません。 彼らがルートを決定する方法を知るためにサブネットマスクを必要とするので、サブネットマスクの不足はルータのための特に重大な問題です。 RIP-1ルートがネットワークルート(すべての非ネットワークビット0)であるなら、サブネットマスクはネットワークマスクと等しいです。 しかしながら、いくつかの非ネットワークビットが設定されるなら、ルータはサブネットマスクを決定できません。 よりひどく、それでも、ルータは、RIP-1ルートがサブネットルートかそれともホストルートであるかを決定できません。 現在、いくつかのルータが、単にルートが学習されたインタフェースのサブネットマスクを選んで、それからルートタイプを決定します。
3. Basic Protocol
3. 基本プロトコル
3.1 Introduction
3.1 序論
RIP is a routing protocol based on the Bellman-Ford (or distance vector) algorithm. This algorithm has been used for routing computations in computer networks since the early days of the ARPANET. The particular packet formats and protocol described here are based on the program "routed," which is included with the Berkeley distribution of Unix.
RIPはBellman-フォード(または、距離ベクトル)アルゴリズムに基づくルーティング・プロトコルです。 アルパネットの初期以来このアルゴリズムはコンピュータネットワークにおけるルーティング計算に使用されています。 ここで説明された特定のパケット・フォーマットとプロトコルは「掘る」というプログラムに基づいています。(それは、Unixのバークレーの分配で含まれています)。
Malkin Standards Track [Page 3] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[3ページ]RFC2453はバージョン1998年11月2日を裂きます。
In an international network, such as the Internet, it is very unlikely that a single routing protocol will used for the entire network. Rather, the network will be organized as a collection of Autonomous Systems (AS), each of which will, in general, be administered by a single entity. Each AS will have its own routing technology, which may differ among AS's. The routing protocol used within an AS is referred to as an Interior Gateway Protocol (IGP). A separate protocol, called an Exterior Gateway Protocol (EGP), is used to transfer routing information among the AS's. RIP was designed to work as an IGP in moderate-size AS's. It is not intended for use in more complex environments. For information on the context into which RIP-1 is expected to fit, see Braden and Postel [6].
インターネットなどの国際ネットワークでは、全体のネットワークに使用されて、ただ一つのルーティング・プロトコルがありそうもなくなるのは、非常にありそうもないです。 むしろ、ネットワークはAutonomous Systems(AS)の収集として組織化されるでしょう。一般に、それは単一体によってそれぞれ管理されるでしょう。 各ASには、それ自身のルーティング技術があるでしょう。(それは、ASのところで異なるかもしれません)。 ASの中で使用されたルーティング・プロトコルはInteriorゲートウェイプロトコル(IGP)と呼ばれます。 Exteriorゲートウェイプロトコル(EGP)と呼ばれる別々のプロトコルは、ルーティング情報をASのものに移すのに使用されます。 RIPは、IGPとしてASの適度のサイズところで働くように設計されました。 それは、より複雑な環境における使用のために意図しません。 RIP-1が合うと予想される文脈の情報に関しては、ブレーデンとポステル[6]を見てください。
RIP uses one of a class of routing algorithms known as Distance Vector algorithms. The earliest description of this class of algorithms known to the author is in Ford and Fulkerson [8]. Because of this, they are sometimes known as Ford-Fulkerson algorithms. The term Bellman-Ford is also used, and derives from the fact that the formulation is based on Bellman's equation [4]. The presentation in this document is closely based on [5]. This document contains a protocol specification. For an introduction to the mathematics of routing algorithms, see [1]. The basic algorithms used by this protocol were used in computer routing as early as 1969 in the ARPANET. However, the specific ancestry of this protocol is within the Xerox network protocols. The PUP protocols [7] used the Gateway Information Protocol to exchange routing information. A somewhat updated version of this protocol was adopted for the Xerox Network Systems (XNS) architecture, with the name Routing Information Protocol [9]. Berkeley's routed is largely the same as the Routing Information Protocol, with XNS addresses replaced by a more general address format capable of handling IPv4 and other types of address, and with routing updates limited to one every 30 seconds. Because of this similarity, the term Routing Information Protocol (or just RIP) is used to refer to both the XNS protocol and the protocol used by routed.
RIPはDistance Vectorアルゴリズムとして知られているルーティング・アルゴリズムのクラスの1つを使用します。作者にとって知られているこのクラスのアルゴリズムの最も早い記述がフォードとフルカーソン[8]にあります。 これのために、それらはフォード-フルカーソンアルゴリズムとして時々知られています。用語Bellman-フォードが、また、使用されて、定式化がBellmanの方程式[4]に基づいているという事実に由来しています。 プレゼンテーションは本書では密接に[5]に基づいています。 このドキュメントはプロトコル仕様を含んでいます。 ルーティング・アルゴリズムの数学への序論に関しては、[1]を見てください。 このプロトコルによって使用される基本的なアルゴリズムは1969年にはアルパネットにもうコンピュータルーティングで使用されました。 しかしながら、このプロトコルの特定の祖先はゼロックスネットワーク・プロトコルの中にいます。 PUPプロトコル[7]は、ルーティング情報を交換するのにゲートウェイ情報プロトコルを使用しました。 このプロトコルのいくらかアップデートされたバージョンはゼロックスNetwork Systems(XNS)構造のために採用されました、名前経路情報プロトコル[9]で。 発送されたものバークレーはルーティング情報プロトコルと主に同じです、XNSアドレスをできる取り扱いIPv4と他のタイプのアドレス、およびルーティングアップデートが30秒毎に1つに制限されている状態で、より一般的なアドレス形式に取り替えていて。 この類似性のために、用語経路情報プロトコル(または、まさしくRIP)は、XNSプロトコルと発送されることによって使用されるプロトコルの両方について言及するのに使用されます。
RIP is intended for use within the IP-based Internet. The Internet is organized into a number of networks connected by special purpose gateways known as routers. The networks may be either point-to-point links or more complex networks such as Ethernet or token ring. Hosts and routers are presented with IP datagrams addressed to some host. Routing is the method by which the host or router decides where to send the datagram. It may be able to send the datagram directly to the destination, if that destination is on one of the networks that are directly connected to the host or router. However, the interesting case is when the destination is not directly reachable.
RIPはIPベースのインターネットの中の使用のために意図します。 インターネットはルータとして知られている専用ゲートウェイによって接続された多くのネットワークに組織化されます。 ネットワークは、イーサネットかトークンリングなどのポイントツーポイント接続か、より複雑なネットワークのどちらかであるかもしれません。 ホストに記述されたIPデータグラムをホストとルータに与えます。 ルート設定はホストかルータがデータグラムをどこに送るかを決める方法です。 それは直接目的地にデータグラムを送ることができるかもしれません、その目的地が直接ホストかルータに接続されるネットワークの1つにあるなら。 しかしながら、おもしろいケースは目的地が直接届いていない時です。
Malkin Standards Track [Page 4] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[4ページ]RFC2453はバージョン1998年11月2日を裂きます。
In this case, the host or router attempts to send the datagram to a router that is nearer the destination. The goal of a routing protocol is very simple: It is to supply the information that is needed to do routing.
この場合、ホストかルータが、より多くの目的地の近くにあるルータにデータグラムを送るのを試みます。 ルーティング・プロトコルの目標は非常に簡単です: それはルーティングするのに必要である情報を提供することになっています。
3.2 Limitations of the Protocol
3.2 プロトコルの制限
This protocol does not solve every possible routing problem. As mentioned above, it is primary intended for use as an IGP in networks of moderate size. In addition, the following specific limitations are be mentioned:
このプロトコルはあらゆる可能なルーティング問題を解決するというわけではありません。 以上のように、それは使用のためにIGPとして適度のサイズのネットワークで意図していた状態で第一です。 さらに、以下の特定の制限はそうです。言及されてください:
- The protocol is limited to networks whose longest path (the
network's diameter) is 15 hops. The designers believe that the
basic protocol design is inappropriate for larger networks. Note
that this statement of the limit assumes that a cost of 1 is used
for each network. This is the way RIP is normally configured. If
the system administrator chooses to use larger costs, the upper
bound of 15 can easily become a problem.
- プロトコルは最も長い経路(ネットワークの直径)が15のホップであるネットワークに制限されます。 デザイナーは、より大きいネットワークに、基本プロトコルデザインが不適当であると信じています。 限界のこの声明が、1の費用が各ネットワークに使用されると仮定することに注意してください。 これは通常、RIPが構成される方法です。 システム管理者が、より大きいコストを使用するのを選ぶなら、15の上限は容易に問題になることができます。
- The protocol depends upon "counting to infinity" to resolve certain
unusual situations. (This will be explained in the next section.)
If the system of networks has several hundred networks, and a
routing loop was formed involving all of them, the resolution of
the loop would require either much time (if the frequency of
routing updates were limited) or bandwidth (if updates were sent
whenever changes were detected). Such a loop would consume a large
amount of network bandwidth before the loop was corrected. We
believe that in realistic cases, this will not be a problem except
on slow lines. Even then, the problem will be fairly unusual,
since various precautions are taken that should prevent these
problems in most cases.
- プロトコルはある異例の状況を決議するために「無限勘定」であるのによります。 (これは次のセクションで説明されるでしょう。) ネットワークのシステムには数100のネットワークがあって、ルーティング輪がそれらに皆、かかわりながら形成されるなら、輪の決議は多くの時間(ルーティングアップデートの頻度が制限されたなら)か帯域幅のどちらかを必要とするでしょうに(変化が検出されたときはいつも、アップデートを送ったなら)。 修正される前にそのような輪は多量のネットワーク回線容量を消費するでしょう。 私たちは、遅い線以外の現実的な場合では、これが問題にならないと信じています。 その時でさえ、問題はかなり珍しくなるでしょう、多くの場合、これらの問題を防ぐべきである様々な注意が払われるので。
- This protocol uses fixed "metrics" to compare alternative routes.
It is not appropriate for situations where routes need to be chosen
based on real-time parameters such a measured delay, reliability,
or load. The obvious extensions to allow metrics of this type are
likely to introduce instabilities of a sort that the protocol is
not designed to handle.
- このプロトコルは、代替のルートを比較するのに固定「測定基準」を使用します。 状況には、それはルートがリアルタイムのパラメタに基づいてそのような測定遅れ、信頼性を選ぶか、またはロードすることである必要があるところで適切ではありません。 このタイプの測定基準を許す明白な拡大はプロトコルが扱うように設計されていない種類の不安定性を導入しそうです。
Malkin Standards Track [Page 5] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[5ページ]RFC2453はバージョン1998年11月2日を裂きます。
3.3. Organization of this document
3.3. このドキュメントの組織
The main body of this document is organized into two parts, which occupy the next two sections:
このドキュメントの本体は2つの部品に組織化されます:(部品は次の2つのセクションを占領します)。
A conceptual development and justification of distance vector
algorithms in general.
一般に、距離ベクトルアルゴリズムの概念発達と正当化。
The actual protocol description.
実際のプロトコル記述。
Each of these two sections can largely stand on its own. Section 3.4 attempts to give an informal presentation of the mathematical underpinnings of the algorithm. Note that the presentation follows a "spiral" method. An initial, fairly simple algorithm is described. Then refinements are added to it in successive sections. Section 3.5 is the actual protocol description. Except where specific references are made to section 3.4, it should be possible to implement RIP entirely from the specifications given in section 3.5.
それぞれのこれらの2つのセクションがそれ自身のところに主に立つことができます。 セクション3.4は、アルゴリズムの数学の基礎の非公式のプレゼンテーションをするのを試みます。 プレゼンテーションが「らせん状」の方法に従うことに注意してください。 初期の、そして、かなり簡単なアルゴリズムは説明されます。 そして、気品は連続したセクションでそれに加えられます。 セクション3.5は実際のプロトコル記述です。 特定指示がセクション3.4にされるところを除いて、完全にセクション3.5で与えられた仕様からRIPを実行するのは可能であるべきです。
3.4 Distance Vector Algorithms
3.4 距離ベクトルアルゴリズム
Routing is the task of finding a path from a sender to a desired destination. In the IP "Internet model" this reduces primarily to a matter of finding a series of routers between the source and destination networks. As long as a message or datagram remains on a single network or subnet, any forwarding problems are the responsibility of technology that is specific to the network. For example, Ethernet and the ARPANET each define a way in which any sender can talk to any specified destination within that one network. IP routing comes in primarily when messages must go from a sender on one network to a destination on a different one. In that case, the message must pass through one or more routers connecting the networks. If the networks are not adjacent, the message may pass through several intervening networks, and the routers connecting them. Once the message gets to a router that is on the same network as the destination, that network's own technology is used to get to the destination.
ルート設定は送付者から必要な目的地に経路を見つけるタスクです。 IP「インターネットモデル」では、これは主としてソースと送信先ネットワークの間の一連のルータを見つける問題に減少します。 メッセージかデータグラムがただ一つのネットワークかサブネットに残っている限り、どんな推進問題もネットワークに特定の技術の責任です。 例えば、イーサネットとアルパネットはそれぞれ、どんな送付者もその1つのネットワークの中のどんな指定された目的地とも話すことができる方法を定義します。 主としてメッセージが1つのネットワークの送付者から目的地まで異なったものに行かなければならないとき、IPルーティングは入ります。 その場合、メッセージはネットワークを接続する1つ以上のルータを通り抜けなければなりません。 ネットワークが隣接していないなら、メッセージはいくつかの介入しているネットワーク、およびそれらを接続するルータを通り抜けるかもしれません。 メッセージがいったん目的地と同じネットワークにあるルータを始めると、そのネットワークの自己の技術は、目的地に着くのに使用されます。
Throughout this section, the term "network" is used generically to cover a single broadcast network (e.g., an Ethernet), a point to point line, or the ARPANET. The critical point is that a network is treated as a single entity by IP. Either no forwarding decision is necessary (as with a point to point line), or that forwarding is done in a manner that is transparent to IP, allowing IP to treat the entire network as a single fully-connected system (as with an Ethernet or the ARPANET). Note that the term "network" is used in a somewhat different way in discussions of IP addressing. We are using the term "network" here to refer to subnets in cases where subnet
このセクション中では、「ネットワーク」という用語は、ただ一つの放送網(例えば、イーサネット)、ポイント・ツー・ポイント線、またはアルパネットをカバーするのに一般的に使用されます。 臨界点はネットワークがIPによって単一体として扱われるということです。 どんな推進決定も必要でないか(ポイント・ツー・ポイントのように、立ち並んでください)、またはIPに見え透いた方法でその推進をします、IPがただ一つの完全に接続されたシステムとして全体のネットワークを扱うのを許容して(イーサネットやアルパネットのように)。 「ネットワーク」という用語がIPアドレシングの議論にいくらか異なった方法で使用されることに注意してください。 私たち、ここのサブネットが参照される「ネットワーク」がどこをケースに入れる用語を使用するのは、サブネットです。
Malkin Standards Track [Page 6] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[6ページ]RFC2453はバージョン1998年11月2日を裂きます。
addressing is in use.
アドレシングは使用中です。
A number of different approaches for finding routes between networks are possible. One useful way of categorizing these approaches is on the basis of the type of information the routers need to exchange in order to be able to find routes. Distance vector algorithms are based on the exchange of only a small amount of information. Each entity (router or host) that participates in the routing protocol is assumed to keep information about all of the destinations within the system. Generally, information about all entities connected to one network is summarized by a single entry, which describes the route to all destinations on that network. This summarization is possible because as far as IP is concerned, routing within a network is invisible. Each entry in this routing database includes the next router to which datagrams destined for the entity should be sent. In addition, it includes a "metric" measuring the total distance to the entity. Distance is a somewhat generalized concept, which may cover the time delay in getting messages to the entity, the dollar cost of sending messages to it, etc. Distance vector algorithms get their name from the fact that it is possible to compute optimal routes when the only information exchanged is the list of these distances. Furthermore, information is only exchanged among entities that are adjacent, that is, entities that share a common network.
ネットワークの間のルートを見つけるための多くの異なるアプローチが可能です。 これらのアプローチを分類する1つの役に立つ方法が、ルートを見つけることができるようにルータが交換する必要がある情報の種類のベースにあります。 距離ベクトルアルゴリズムは少量の情報だけの交換に基づいています。 ルーティング・プロトコルに参加する各実体(ルータかホスト)がシステムの中に目的地のすべての情報を保つと思われます。 一般に、1つのネットワークに関連づけられたすべての実体の情報は単一のエントリーでまとめられます。(それは、そのネットワークのすべての目的地にルートを説明します)。 IPは関係があるときネットワークの中のルーティングが同じくらい遠くに目に見えないので、この総括は可能です。 このルーティングデータベースにおける各エントリーは実体のために運命づけられたデータグラムが送られるべきである次のルータを含んでいます。 さらに、それは、総距離を実体に測定しながら、「メートル法」を含んでいます。 距離はいくらか一般化された概念です。(その概念はメッセージを実体に得る時間遅れ、メッセージをそれに送るドル費用などに関するかもしれません)。 交換された唯一の情報がこれらの距離のリストであるときに、距離ベクトルアルゴリズムは最適のルートを計算するのが可能であるという事実からそれらの名前を得ます。 その上、すなわち、隣接している実体、一般的なネットワークを共有する実体の中で情報を交換するだけです。
Although routing is most commonly based on information about networks, it is sometimes necessary to keep track of the routes to individual hosts. The RIP protocol makes no formal distinction between networks and hosts. It simply describes exchange of information about destinations, which may be either networks or hosts. (Note however, that it is possible for an implementor to choose not to support host routes. See section 3.2.) In fact, the mathematical developments are most conveniently thought of in terms of routes from one host or router to another. When discussing the algorithm in abstract terms, it is best to think of a routing entry for a network as an abbreviation for routing entries for all of the entities connected to that network. This sort of abbreviation makes sense only because we think of networks as having no internal structure that is visible at the IP level. Thus, we will generally assign the same distance to every entity in a given network.
ルーティングは最も一般的にネットワークの情報に基づいていますが、個々のホストにルートの動向をおさえるのが時々必要です。 RIPプロトコルはネットワークとホストの間でどんな正式な区別もしません。 それは目的地に関して単に情報交換について説明します。(ネットワークか目的地はホストのどちらかであるかもしれません)。 (しかしながら、作成者が、そうしないのを選ぶのが、可能であることがホストルートを支えることに注意してください。 セクション3.2を見てください。) 事実上、数学の開発はルートで1つのホストかルータから別のルータまで最も便利に考えられます。 抽象名辞でアルゴリズムについて議論するとき、実体のすべてのためのルーティングエントリーへの略語がそのネットワークに接続したので、ネットワークのためにルーティングエントリーを考えるのは最も良いです。 単に私たちがどんなIPレベルで目に見える内部の構造も持っていないとネットワークを考えるので、この種類の略語は理解できます。 したがって、一般に、私たちは与えられたネットワークにおけるあらゆる実体に同じ距離を割り当てるつもりです。
We said above that each entity keeps a routing database with one entry for every possible destination in the system. An actual implementation is likely to need to keep the following information about each destination:
私たちは、上で各実体がシステムの各可能な目的地あたり1つのエントリーでルーティングデータベースを保つと言いました。 実際の実現が各目的地の以下の情報を保つのが必要でありそうです:
Malkin Standards Track [Page 7] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[7ページ]RFC2453はバージョン1998年11月2日を裂きます。
- address: in IP implementations of these algorithms, this will be
the IP address of the host or network.
- アドレス: これらのアルゴリズムのIP実現では、これはホストかネットワークのIPアドレスになるでしょう。
- router: the first router along the route to the destination.
- ルータ: 目的地へのルートに沿った最初のルータ。
- interface: the physical network which must be used to reach the
first router.
- 以下を連結してください。 最初のルータに達するのに使用しなければならない物理ネットワーク。
- metric: a number, indicating the distance to the destination.
- メートル法: 距離を目的地に示す数。
- timer: the amount of time since the entry was last updated.
- タイマ: エントリー以来の時間をアップデートしました。
In addition, various flags and other internal information will probably be included. This database is initialized with a description of the entities that are directly connected to the system. It is updated according to information received in messages from neighboring routers.
さらに、様々な旗と他の内部の情報はたぶん含まれるでしょう。 このデータベースは直接システムに接続される実体の記述で初期化されます。 メッセージに隣接しているルータから受け取られた情報によると、それをアップデートします。
The most important information exchanged by the hosts and routers is carried in update messages. Each entity that participates in the routing scheme sends update messages that describe the routing database as it currently exists in that entity. It is possible to maintain optimal routes for the entire system by using only information obtained from neighboring entities. The algorithm used for that will be described in the next section.
ホストとルータによって交換される中で最も重要な情報はアップデートメッセージで運ばれます。 ルーティング計画に参加する各実体が現在その実体で存在するときルーティングデータベースについて説明するアップデートメッセージを送ります。 全体のシステムのために隣接している実体から得られた情報だけを使用することによって最適のルートを維持するのは可能です。 それに使用されるアルゴリズムは次のセクションで説明されるでしょう。
As we mentioned above, the purpose of routing is to find a way to get datagrams to their ultimate destinations. Distance vector algorithms are based on a table in each router listing the best route to every destination in the system. Of course, in order to define which route is best, we have to have some way of measuring goodness. This is referred to as the "metric".
私たちが上に言及したように、ルーティングの目的はそれらの最終仕向地にデータグラムを届ける方法を見つけることです。 距離ベクトルアルゴリズムはシステムのあらゆる目的地に記載する中でルート最も良い各ルータでテーブルに基づいています。 もちろん、どのルートが最も良いかを定義するために、私たちには善良を測定する何らかの方法がなければなりません。 これは「メートル法」と呼ばれます。
In simple networks, it is common to use a metric that simply counts how many routers a message must go through. In more complex networks, a metric is chosen to represent the total amount of delay that the message suffers, the cost of sending it, or some other quantity which may be minimized. The main requirement is that it must be possible to represent the metric as a sum of "costs" for individual hops.
簡単なネットワークでは、そんなに単にメートル法でaを使用するコモンがメッセージが行かなければならないいくつのルータを数えるかということです。 より複雑なネットワークでは、aメートル法であることは、選ばれて、合計を表すのが達するということです。メッセージが受ける遅れ、それを送る費用、または最小にされるかもしれないある他の量について。 主な要件は個々のホップのために「コスト」の合計としてのメートル法を表すのが可能であるに違いないということです。
Formally, if it is possible to get from entity i to entity j directly (i.e., without passing through another router between), then a cost, d(i,j), is associated with the hop between i and j. In the normal case where all entities on a given network are considered to be the same, d(i,j) is the same for all destinations on a given network, and represents the cost of using that network. To get the metric of a complete route, one just adds up the costs of the individual hops
正式に、それが実体iから実体jまで直接得るのにおいて可能であるなら(すなわち、間に別のルータを通り抜けることのない)、費用(d(i、j))はiとjの間のホップに関連しています。 与えられたネットワークのすべての実体が同じであると考えられる正常な場合では、d(i、j)は、与えられたネットワークのすべての目的地に同じであり、そのネットワークを使用する費用を表します。 完全なルートのメートル法を得るために、人はただ個々のホップのコストを合計します。
Malkin Standards Track [Page 8] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[8ページ]RFC2453はバージョン1998年11月2日を裂きます。
that make up the route. For the purposes of this memo, we assume that the costs are positive integers.
それはルートを作ります。 このメモの目的のために、私たちは、コストが正の整数であると思います。
Let D(i,j) represent the metric of the best route from entity i to entity j. It should be defined for every pair of entities. d(i,j) represents the costs of the individual steps. Formally, let d(i,j) represent the cost of going directly from entity i to entity j. It is infinite if i and j are not immediate neighbors. (Note that d(i,i) is infinite. That is, we don't consider there to be a direct connection from a node to itself.) Since costs are additive, it is easy to show that the best metric must be described by
D(i、j)に最も良いルートのメートル法を実体iから実体jまで表させてください。 それはすべての組の実体のために定義されるべきです。d(i、j)は独特のステップのコストを表します。 正式に、d(i、j)に直接実体iから実体jまで行く費用を表させてください。 iとjがすぐ隣の人でないなら無限です。 (d(i、i)が無限であることに注意してください。 すなわち、私たちは、ダイレクトノードからそれ自体までの接続があると考えません。) コストが付加的であるので、それは最もよくメートル法について説明しなければならないショーに簡単です。
D(i,i) = 0, all i
D(i,j) = min [d(i,k) + D(k,j)], otherwise
k
and that the best routes start by going from i to those neighbors k
for which d(i,k) + D(k,j) has the minimum value. (These things can
be shown by induction on the number of steps in the routes.) Note
that we can limit the second equation to k's that are immediate
neighbors of i. For the others, d(i,k) is infinite, so the term
involving them can never be the minimum.
D(i、i)はそうでなければ、0、すべてのi D(i、j)=分[d(i、k)+D(k、j)]、kと等しいです、そして、最も良いルートがどのd(i、k)+D(k、j)にiからそれらの隣人kまで行くかによって始動するのにおいて、最小値があります。 (ルートによるステップの数における誘導でこれらのことを示すことができます。) 私たちが二次方程式をiのすぐ隣の人であるkのものに制限できることに注意してください。 他のものにとって、d(i、k)が無限であるので、彼らにかかわる用語は最小限であるはずがありません。
It turns out that one can compute the metric by a simple algorithm based on this. Entity i gets its neighbors k to send it their estimates of their distances to the destination j. When i gets the estimates from k, it adds d(i,k) to each of the numbers. This is simply the cost of traversing the network between i and k. Now and then i compares the values from all of its neighbors and picks the smallest.
人がこれに基づく簡単なアルゴリズムによるメートル法を計算できると判明します。 実体iで、隣人kは目的地jへのそれらの距離に関する彼らの見積りをそれに送ります。 私がkから見積りを得るとき、それはd(i、k)をそれぞれの数に加えます。 これは単にiとkの間のネットワークを横断する費用です。 時折、私はその隣人と選択のすべてから値を最も小さく比較します。
A proof is given in [2] that this algorithm will converge to the correct estimates of D(i,j) in finite time in the absence of topology changes. The authors make very few assumptions about the order in which the entities send each other their information, or when the min is recomputed. Basically, entities just can't stop sending updates or recomputing metrics, and the networks can't delay messages forever. (Crash of a routing entity is a topology change.) Also, their proof does not make any assumptions about the initial estimates of D(i,j), except that they must be non-negative. The fact that these fairly weak assumptions are good enough is important. Because we don't have to make assumptions about when updates are sent, it is safe to run the algorithm asynchronously. That is, each entity can send updates according to its own clock. Updates can be dropped by the network, as long as they don't all get dropped. Because we don't have to make assumptions about the starting condition, the algorithm can handle changes. When the system changes, the routing algorithm starts moving to a new equilibrium, using the old one as its starting point. It is important that the algorithm will converge in finite
このアルゴリズムがトポロジー変化がないとき有限時間でD(i、j)の適度の見積りに一点に集める[2]で証拠を与えます。 作者が実体が互いを送るオーダーに関するほんのわずかな仮定をそれらの情報にするか、またはいつ、分があるかは再計算されました。 基本的に、実体は、測定基準をアップデートするか、または再計算しながら発信するのをただ止めることができません、そして、ネットワークはいつまでも、メッセージを遅らせることができません。. (ルーティング実体のクラッシュはトポロジー変化です。) また、それらの証拠は彼らが非否定的であるに違いない以外に、少しの仮定もD(i、j)の初期のおよそ見積りにしません。 これらのかなり弱い仮定が十分良いという事実は重要です。 私たちがアップデートが送られる時に関する仮定をする必要はないので、アルゴリズムを非同期に走らせるのは安全です。 それ自身の時計に応じて、すなわち各実体はアップデートを送ることができます。 それらがすべて落とされない限り、ネットワークはアップデートを落とすことができます。 私たちが始めの状態に関する仮定をする必要はないので、アルゴリズムは変化を扱うことができます。 システムが変化するとき、ルーティング・アルゴリズムは新しい均衡に発進します、出発点として古い方を使用して。 アルゴリズムが有限で一点に集まるのは、重要です。
Malkin Standards Track [Page 9] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[9ページ]RFC2453はバージョン1998年11月2日を裂きます。
time no matter what the starting point. Otherwise certain kinds of changes might lead to non-convergent behavior.
出発点が何であっても、調節してください。 そうでなければ、ある種類の変化は非集中的な振舞いに通じるかもしれません。
The statement of the algorithm given above (and the proof) assumes that each entity keeps copies of the estimates that come from each of its neighbors, and now and then does a min over all of the neighbors. In fact real implementations don't necessarily do that. They simply remember the best metric seen so far, and the identity of the neighbor that sent it. They replace this information whenever they see a better (smaller) metric. This allows them to compute the minimum incrementally, without having to store data from all of the neighbors.
上に与えられたアルゴリズム(そして、証拠)の声明は、各実体が隣人各人から来る見積りのコピーを妨げて、隣人を皆、時折分やり直すと仮定します。 事実上、本当の実現は必ずそれをするというわけではありません。 彼らは単に今までのところ見られている最もよくメートル法、およびそれを送った隣人のアイデンティティを覚えています。 aが、より良いのを(より小さい)メートル法で見るときはいつも、彼らはこの情報を置き換えます。 これで、隣人のすべてからデータを格納する必要はなくて、彼らは最小限を増加して計算できます。
There is one other difference between the algorithm as described in texts and those used in real protocols such as RIP: the description above would have each entity include an entry for itself, showing a distance of zero. In fact this is not generally done. Recall that all entities on a network are normally summarized by a single entry for the network. Consider the situation of a host or router G that is connected to network A. C represents the cost of using network A (usually a metric of one). (Recall that we are assuming that the internal structure of a network is not visible to IP, and thus the cost of going between any two entities on it is the same.) In principle, G should get a message from every other entity H on network A, showing a cost of 0 to get from that entity to itself. G would then compute C + 0 as the distance to H. Rather than having G look at all of these identical messages, it simply starts out by making an entry for network A in its table, and assigning it a metric of C. This entry for network A should be thought of as summarizing the entries for all other entities on network A. The only entity on A that can't be summarized by that common entry is G itself, since the cost of going from G to G is 0, not C. But since we never need those 0 entries, we can safely get along with just the single entry for network A. Note one other implication of this strategy: because we don't need to use the 0 entries for anything, hosts that do not function as routers don't need to send any update messages. Clearly hosts that don't function as routers (i.e., hosts that are connected to only one network) can have no useful information to contribute other than their own entry D(i,i) = 0. As they have only the one interface, it is easy to see that a route to any other network through them will simply go in that interface and then come right back out it. Thus the cost of such a route will be greater than the best cost by at least C. Since we don't need the 0 entries, non- routers need not participate in the routing protocol at all.
テキストで説明されるアルゴリズムとRIPなどの本当のプロトコルに使用されるものの間には、他の1つの違いがあります: 上の記述で、ゼロの距離を示して、各実体はそれ自体のためのエントリーを含んでいるでしょう。 事実上、一般に、これをしません。 通常、ネットワークのすべての実体がネットワークに、単一のエントリーでまとめられたと思い出してください。 ネットワークA.Cに接されるホストかルータGの状況がネットワークA(通常1におけるメートル法のa)を使用する費用を表すと考えてください。 (私たちが、ネットワークの内部の構造がIPに目に見えないと思っていて、その結果、それのどんな2つの実体も取り持つ費用が同じであると思い出してください。) 原則として、GはネットワークAで他のあらゆる実体Hからメッセージを得るべきです、その実体からそれ自体まで得る0の費用を示して。 次に、GはGをこれらの同じメッセージについて全く見させるより距離としてC+0をH.ラザーに計算するでしょう、そして、テーブルのネットワークAのために記帳することによって、単に始めます、そして、ネットワークAにおける、C.Thisエントリーにおけるメートル法のaをそれに割り当てるのは他のすべての実体のためのエントリーをネットワークA.へまとめると考えられるべきです。Aのその一般的なエントリーでまとめることができない唯一の実体がG自体です; GからGまで行く費用が0であるときに、それらの0つのエントリーを決して必要としないので、C.Butではなく、私たちはネットワークA.Note1のためにまさしく単一のエントリーと共にこの戦略の他の含意を安全に得ることができます: 私たちが何にも0つのエントリーを使用する必要はないので、ルータとして機能しないホストはどんなアップデートメッセージも送る必要はありません。 明確に、ルータ(すなわち、1つのネットワークだけに接続されるホスト)として機能しないホストはそれら自身のエントリーD(i、i)=0以外に、寄付しない役に立つ情報を全く持つことができます。 彼らに1つのインタフェースしかないとき、それらを通したいかなる他のネットワークへのルートも単にそのインタフェースに入って、次に、それの手を引きに真直に来るのを確実にするのは簡単です。 したがって、そのようなルートの費用は少なくともC.Sinceによる最も良い費用より偉大な私たちが0つのエントリーを必要としないで、非ルータが全くルーティング・プロトコルに参加する必要はないということでしょう。
Let us summarize what a host or router G does. For each destination in the system, G will keep a current estimate of the metric for that destination (i.e., the total cost of getting to it) and the identity
ホストかルータGがすることをまとめましょう。 システムの各目的地に関しては、Gは、その目的地へのメートル法の現状見積金額が(すなわち、それを始める総費用)とアイデンティティであることを保つでしょう。
Malkin Standards Track [Page 10] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[10ページ]RFC2453はバージョン1998年11月2日を裂きます。
of the neighboring router on whose data that metric is based. If the destination is on a network that is directly connected to G, then G simply uses an entry that shows the cost of using the network, and the fact that no router is needed to get to the destination. It is easy to show that once the computation has converged to the correct metrics, the neighbor that is recorded by this technique is in fact the first router on the path to the destination. (If there are several equally good paths, it is the first router on one of them.) This combination of destination, metric, and router is typically referred to as a route to the destination with that metric, using that router.
そんなにメートル法のデータがだれのものであるかに基づく隣接しているルータについて。 目的地が直接Gに接続されるネットワークにあるなら、Gは単にルータは全く目的地に着くのに必要でないことをネットワーク、および事実を使用する費用に示すエントリーを使用します。 事実上、計算がいったん正しい測定基準に一点に集まると、このテクニックで記録される隣人が目的地への経路の最初のルータであることを示すのは簡単です。 (いくつかの等しく良い経路があれば、それはそれらの1つの最初のルータです。) それがメートル法でメートル法の目的地のこの組み合わせとルータは目的地へのルートと通常呼ばれます、そのルータを使用して。
4.ne The method so far only has a way to lower the metric, as the existing metric is kept until a smaller one shows up. It is possible that the initial estimate might be too low. Thus, there must be a way to increase the metric. It turns out to be sufficient to use the following rule: suppose the current route to a destination has metric D and uses router G. If a new set of information arrived from some source other than G, only update the route if the new metric is better than D. But if a new set of information arrives from G itself, always update D to the new value. It is easy to show that with this rule, the incremental update process produces the same routes as a calculation that remembers the latest information from all the neighbors and does an explicit minimum. (Note that the discussion so far assumes that the network configuration is static. It does not allow for the possibility that a system might fail.)
4. 方法が今までのところメートル法と、存在としてのメートル法を下ろすのが、より小さいものが目立つまで続けられる方法を持っているだけであるNe。 初期の見積りが低過ぎるのは、可能です。 したがって、メートル法を増加させる方法があるに違いありません。 それは以下の規則を使用するために十分であると判明します: G、目的地への現在のルートがメートル法のDを持って、Ifのa新しい情報がソースから到着したルータG.を使用するなら、新しい情報がG自体から到着するなら新しくメートル法がD.Butより良いなら、単にルートをアップデートしてください、いつも新しい値へのアップデートD。 この規則で、アップデート増加の過程がすべての隣人から最新情報を覚えていて、明白な最小限をする計算と同じルートを作成するのを示すのは簡単です。 (議論が、今までのところネットワーク・コンフィギュレーションが静的であると仮定することに注意してください。 システムが失敗するかもしれないのが可能性を考慮しません。)
To summarize, here is the basic distance vector algorithm as it has been developed so far. (Note that this is not a statement of the RIP protocol. There are several refinements still to be added.) The following procedure is carried out by every entity that participates in the routing protocol. This must include all of the routers in the system. Hosts that are not routers may participate as well.
まとめるためにある、ここに、今までのところそれを開発してあるとき、基本的な距離ベクトルアルゴリズムがあります。 (これがRIPプロトコルの声明でないことに注意してください。 まだ加えられているために、いくつかの気品があります。) 以下の手順がルーティング・プロトコルに参加するあらゆる実体によって行われます。 これはシステムにルータのすべてを含まなければなりません。 また、ルータでないホストは参加するかもしれません。
- Keep a table with an entry for every possible destination in the
system. The entry contains the distance D to the destination, and
the first router G on the route to that network. Conceptually,
there should be an entry for the entity itself, with metric 0, but
this is not actually included.
- システムのあらゆる可能な目的地のためのエントリーがあるテーブルを保ってください。 エントリーは目的地への距離D、およびそのネットワークへのルートの上の最初のルータGを含んでいます。 概念的に、実体自体のためのエントリーがメートル法の0と共にあるべきですが、これは実際に含まれていません。
- Periodically, send a routing update to every neighbor. The update
is a set of messages that contain all of the information from the
routing table. It contains an entry for each destination, with the
distance shown to that destination.
- 定期的に、ルーティングアップデートをすべての隣人に送ってください。 アップデートは経路指定テーブルからの情報のすべてを含む1セットのメッセージです。 それは距離がその目的地に案内されている各目的地のためのエントリーを含んでいます。
- When a routing update arrives from a neighbor G', add the cost
associated with the network that is shared with G'. (This should
be the network over which the update arrived.) Call the resulting
- 'ルーティングアップデートは隣人Gから到着する'とき、G'と共有されるネットワークに関連している費用を加えてください。 (これはアップデートが到着したネットワークであるべきです。) 結果になることに電話をしてください。
Malkin Standards Track [Page 11] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[11ページ]RFC2453はバージョン1998年11月2日を裂きます。
distance D'. Compare the resulting distances with the current
routing table entries. If the new distance D' for N is smaller
than the existing value D, adopt the new route. That is, change
the table entry for N to have metric D' and router G'. If G' is
the router from which the existing route came, i.e., G' = G, then
use the new metric even if it is larger than the old one.
'Dを遠ざけてください'。 現在の経路指定テーブルエントリーと結果として起こる距離を比べてください。 'Nのための新しい距離D'が既存の値Dよりわずかであるなら、新しいルートを採用してください。 'それはそうであり、変化はNにはメートル法のD'とルータGがあるテーブル項目です'。 'G'が既存のルートが来たルータ、すなわち、G'=Gであるなら、それが古い方よりさらに大きいなら、メートル法で新しさを使用してください。
3.4.1 Dealing with changes in topology
3.4.1 トポロジーの変化に対処すること。
The discussion above assumes that the topology of the network is fixed. In practice, routers and lines often fail and come back up. To handle this possibility, we need to modify the algorithm slightly.
上の議論は、ネットワークのトポロジーが固定されていると仮定します。 実際には、ルータと線は、しばしば失敗して、来て戻ります。 この可能性を扱うために、私たちは、アルゴリズムをわずかに変更する必要があります。
The theoretical version of the algorithm involved a minimum over all immediate neighbors. If the topology changes, the set of neighbors changes. Therefore, the next time the calculation is done, the change will be reflected. However, as mentioned above, actual implementations use an incremental version of the minimization. Only the best route to any given destination is remembered. If the router involved in that route should crash, or the network connection to it break, the calculation might never reflect the change. The algorithm as shown so far depends upon a router notifying its neighbors if its metrics change. If the router crashes, then it has no way of notifying neighbors of a change.
アルゴリズムの理論上のバージョンはすべてのすぐ隣の人の上で最小限を伴いました。 トポロジーが変化するなら、隣人のセットは変化します。 したがって、変化は計算をする次の時に反映されるでしょう。 しかしながら、以上のようの、そして、実際の実現は最小化の増加のバージョンを使用します。 どんな与えられた目的地への最も良いルートだけも覚えていられます。 そのルートにかかわるルータがクラッシュするべきであるか、またはそれへのネットワーク接続が中断しているなら、計算は変化を決して反映しないかもしれません。 今までのところ示されるアルゴリズムは測定基準が変化するなら隣人に通知するルータによります。 ルータがクラッシュするなら、それには、変化について隣人に通知する方法が全くありません。
In order to handle problems of this kind, distance vector protocols must make some provision for timing out routes. The details depend upon the specific protocol. As an example, in RIP every router that participates in routing sends an update message to all its neighbors once every 30 seconds. Suppose the current route for network N uses router G. If we don't hear from G for 180 seconds, we can assume that either the router has crashed or the network connecting us to it has become unusable. Thus, we mark the route as invalid. When we hear from another neighbor that has a valid route to N, the valid route will replace the invalid one. Note that we wait for 180 seconds before timing out a route even though we expect to hear from each neighbor every 30 seconds. Unfortunately, messages are occasionally lost by networks. Thus, it is probably not a good idea to invalidate a route based on a single missed message.
この種類の問題を扱うために、距離ベクトルプロトコルはタイミングへの何らかの設備を出ているルートにしなければなりません。 詳細は特定のプロトコルによります。 例として、RIPでは、ルーティングに参加するあらゆるルータが30秒に一度アップデートメッセージをすべての隣人に送ります。 ネットワークNのための現在のルートがルータG.Ifを使用するなら、私たちが180秒間のGから聞かないか、私たちが、ルータがクラッシュしたと思うことができますか、またはそれに私たちに接するネットワークは使用不可能になりました。 したがって、私たちは、ルートが無効であるとマークします。 私たちが有効なルートを持っている別の隣人からNまで聞くと、有効なルートは無効のものを取り替えるでしょう。 私たちが私たちが、30秒毎に各隣人から連絡をいただくと予想しますが、ルートから調節する前に180秒間待つことに注意してください。 残念ながら、メッセージは時折ネットワークによって失われています。 したがって、ただ一つの逃されたメッセージに基づくルートを無効にするのは、たぶん名案ではありません。
As we will see below, it is useful to have a way to notify neighbors that there currently isn't a valid route to some network. RIP, along with several other protocols of this class, does this through a normal update message, by marking that network as unreachable. A specific metric value is chosen to indicate an unreachable destination; that metric value is larger than the largest valid metric that we expect to see. In the existing implementation of RIP, 16 is used. This value is normally referred to as "infinity", since
私たちが以下を見るように、有効なルートが現在、ないように隣人に通知する方法を何らかのネットワークに持っているのは役に立ちます。 RIPはこのクラスの他のいくつかのプロトコルと共に正常なアップデートメッセージを通してこれをします、手の届かないとしてそのネットワークをマークすることによって。 特定のメートル法の数値は手の届かない目的地を示すために選ばれています。 そのメートル法の数値が有効な状態で極めて大きい、メートル法、私たちは、見ると予想します。 16はRIPの既存の実現が使用されています。 通常、この値は以来、「無限」と呼ばれます。
Malkin Standards Track [Page 12] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[12ページ]RFC2453はバージョン1998年11月2日を裂きます。
it is larger than the largest valid metric. 16 may look like a surprisingly small number. It is chosen to be this small for reasons that we will see shortly. In most implementations, the same convention is used internally to flag a route as invalid.
それは有効な状態で極めて大きいです。メートル法。 16は驚くほど少ない数に似るかもしれません。 理由による小さくこれになるように、私たちがまもなく見るのが選ばれています。 ほとんどの実現では、同じコンベンションは、無効の同じくらいルートに旗を揚げさせるのに内部的に使用されます。
3.4.2 Preventing instability
3.4.2 不安定性を防ぐこと。
The algorithm as presented up to this point will always allow a host or router to calculate a correct routing table. However, that is still not quite enough to make it useful in practice. The proofs referred to above only show that the routing tables will converge to the correct values in finite time. They do not guarantee that this time will be small enough to be useful, nor do they say what will happen to the metrics for networks that become inaccessible.
この時点までに提示されるアルゴリズムは、正しい経路指定テーブルについて計算するためにいつもホストかルータを許容するでしょう。 しかしながら、それは、それを実際には役に立つようにするようにまだかなり十分であるというわけではありません。 ルーティングが見送るショーだけを超えて示された証拠は有限時間の後に正しい値に一点に集まるでしょう。 彼らは、今回が役に立つことができるくらい小さくなるのを保証しません、そして、近づきがたくなるネットワークのために測定基準がどうなるかを言いません。
It is easy enough to extend the mathematics to handle routes becoming inaccessible. The convention suggested above will do that. We choose a large metric value to represent "infinity". This value must be large enough that no real metric would ever get that large. For the purposes of this example, we will use the value 16. Suppose a network becomes inaccessible. All of the immediately neighboring routers time out and set the metric for that network to 16. For purposes of analysis, we can assume that all the neighboring routers have gotten a new piece of hardware that connects them directly to the vanished network, with a cost of 16. Since that is the only connection to the vanished network, all the other routers in the system will converge to new routes that go through one of those routers. It is easy to see that once convergence has happened, all the routers will have metrics of at least 16 for the vanished network. Routers one hop away from the original neighbors would end up with metrics of at least 17; routers two hops away would end up with at least 18, etc. As these metrics are larger than the maximum metric value, they are all set to 16. It is obvious that the system will now converge to a metric of 16 for the vanished network at all routers.
それは近づきがたくなるルートを扱うために数学を広げるほど簡単です。 コンベンションは、それが上で大丈夫であることを示しました。 私たちは、「無限」を表すために大きいメートル法の数値を選びます。 この値は全くメートル法であることでいいえ大きくなければなりません。かつて、そんなに大きくなるでしょう。 この例の目的のために、私たちは値16を使用するつもりです。 ネットワークが近づきがたくなると仮定してください。 それのためのメートル法が16までネットワークでつなぐすぐに隣接しているルータタイムアウトとセットのすべて。 分析の目的のために、私たちは、すべての隣接しているルータが直接消えているネットワークにそれらを接続する新しいハードウェアを手に入れたと思うことができます、16の費用で。 それが消えているネットワークへの唯一の接続であるので、システムの他のすべてのルータがそれらのルータの1つを通る新しいルートに一点に集まるでしょう。 集合がいったん起こると、すべてのルータには消えているネットワークのための少なくとも16の測定基準があるのがわかるのは簡単です。 オリジナルの隣人からの遠くのワンバウンドのルータは少なくとも17の測定基準で終わるでしょう。 遠くの2つのホップが少なくとも18などで終わらせるルータ これらの測定基準が最大のメートル法の数値より大きいときに、それらは16にすべて設定されます。 システムが現在全く消えているネットワークにおける、16におけるメートル法のaにルータを一点に集めるのは、明白です。
Unfortunately, the question of how long convergence will take is not amenable to quite so simple an answer. Before going any further, it will be useful to look at an example (taken from [2]). Note that what we are about to show will not happen with a correct implementation of RIP. We are trying to show why certain features are needed. In the following example the letters correspond to routers, and the lines to networks.
残念ながら、集合がどれくらいかかるかに関する質問はそんなに簡単な答えに従順ではありません。 これ以上行く前に、例を見るのは役に立ちます。([2])から、取ります。 私たちが示していようとしていることがRIPの正しい実現で起こらないことに注意してください。 私たちは、ある特徴がなぜ必要であるかを示そうとしています。 以下の例では、手紙はルータ、およびネットワークへの線に一致しています。
Malkin Standards Track [Page 13] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[13ページ]RFC2453はバージョン1998年11月2日を裂きます。
A-----B
\ / \
\ / |
C / all networks have cost 1, except
| / for the direct link from C to D, which
|/ has cost 10
D
|<=== target network
A-----B\/\\/| すべてがネットワークでつなぐC/は1かかって、除いてください。| CからDまでの直リンクのための/、どれ|/には、費用10Dがあります。|<== 目標ネットワーク
Each router will have a table showing a route to each network.
各ルータで、テーブルは各ネットワークにルートを見せるでしょう。
However, for purposes of this illustration, we show only the routes from each router to the network marked at the bottom of the diagram.
しかしながら、このイラストの目的のために、私たちは各ルータからダイヤグラムの下部でマークされたネットワークまでルートだけを見せています。
D: directly connected, metric 1
B: route via D, metric 2
C: route via B, metric 3
A: route via B, metric 3
D: 直接接続されて、メートル法の1、B: D、メートル法の2Cを通して以下を発送してください。 Bを通したルート、メートル法の3A: Bを通したルート、メートル法の3
Now suppose that the link from B to D fails. The routes should now adjust to use the link from C to D. Unfortunately, it will take a while for this to this to happen. The routing changes start when B notices that the route to D is no longer usable. For simplicity, the chart below assumes that all routers send updates at the same time. The chart shows the metric for the target network, as it appears in the routing table at each router.
今度は、BからDへのリンクが失敗すると仮定してください。 ルートは現在CからD.Unfortunatelyへのリンクを使用するために適応するはずであり、それは、これへのこれが起こるにはしばらくかかるでしょう。 Bが、Dへのルートがもう使用可能でないのに気付くと、ルーティング変化は始まります。 簡単さのために、以下の図は、すべてのルータが同時にアップデートを送ると仮定します。 図は経路指定テーブルに各ルータに現れるように目標ネットワークのためのメートル法を示しています。
time ------>
時間------>。
D: dir, 1 dir, 1 dir, 1 dir, 1 ... dir, 1 dir, 1
B: unreach C, 4 C, 5 C, 6 C, 11 C, 12
C: B, 3 A, 4 A, 5 A, 6 A, 11 D, 11
A: B, 3 C, 4 C, 5 C, 6 C, 11 C, 12
D: dir、1dir、1dir、1dir、1…dir、1dir、1、B: 「非-範囲」C、4Cと、5Cと、6Cと、11Cと、12C: B、3、A、4、A、5、A、6、A、11、D、11A: B、3C、4C、5C、6C、11C、12
dir = directly connected
unreach = unreachable
=直接接続された「非-範囲」=dirに手が届きません。
Here's the problem: B is able to get rid of its failed route using a timeout mechanism, but vestiges of that route persist in the system for a long time. Initially, A and C still think they can get to D via B. So, they keep sending updates listing metrics of 3. In the next iteration, B will then claim that it can get to D via either A or C. Of course, it can't. The routes being claimed by A and C are now gone, but they have no way of knowing that yet. And even when they discover that their routes via B have gone away, they each think there is a route available via the other. Eventually the system converges, as all the mathematics claims it must. But it can take some time to do so. The worst case is when a network becomes
ここに、問題があります: Bはタイムアウトメカニズムを使用するのにおいて失敗したルートを取り除くことができますが、そのルートの痕跡は長い間システムに固執します。 初めは、AとCは、彼らがB.Soを通してDを始めることができるとまだ思っていて、彼らはアップデートに3の測定基準を記載させ続けます。 次の繰り返しでは、次に、Bは、AかC.Ofコースのどちらかを通ってDを始めることができると主張して、それはそうすることができません。 AとCで要求されるルートは現在、ないのですが、それらには、まだそれを知っている方法が全くありません。 そして、彼らが、Bを通したそれらのルートが遠ざかったと発見さえするとき、それらは、もう片方を通して利用可能なルートがあるとそれぞれ思います。 結局、すべての数学が、そうしなければならないと主張するとき、システムは一点に集まります。 しかし、そうするにはいくらかの時間がかかるかもしれません。 最悪の場合はネットワークがなる時です。
Malkin Standards Track [Page 14] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[14ページ]RFC2453はバージョン1998年11月2日を裂きます。
completely inaccessible from some part of the system. In that case, the metrics may increase slowly in a pattern like the one above until they finally reach infinity. For this reason, the problem is called "counting to infinity".
システムの何らかの部分から完全に近づきがたいです。 その場合、最終的に無限に達するまで、測定基準はゆっくり上のもののようなパターンを増やすかもしれません。 この理由で、問題は「無限勘定」であると呼ばれます。
You should now see why "infinity" is chosen to be as small as possible. If a network becomes completely inaccessible, we want counting to infinity to be stopped as soon as possible. Infinity must be large enough that no real route is that big. But it shouldn't be any bigger than required. Thus the choice of infinity is a tradeoff between network size and speed of convergence in case counting to infinity happens. The designers of RIP believed that the protocol was unlikely to be practical for networks with a diameter larger than 15.
あなたは、今、「無限」が選ばれている理由ができるだけ小さいと考えるべきです。 ネットワークが完全に近づきがたくなるなら、私たちは、できるだけ早く無限で数えるのを止めて欲しいと思います。 無限はどんな本当のルートもそんなに大きくないほど大きくなければなりません。 しかし、それは必要とされるより少しも大きいはずがありません。 したがって、無限で数えるのが起こるといけないので、無限の選択は集合のネットワークの規模と速度の間の見返りです。 RIPのデザイナーは、直径が15より大きい状態でプロトコルがネットワークに実用的でありそうにないと信じていました。
There are several things that can be done to prevent problems like this. The ones used by RIP are called "split horizon with poisoned reverse", and "triggered updates".
このような問題を防ぐためにできるいくつかのことがあります。 RIPによって使用されたのは「当たっている逆がある分裂地平線と、引き起こされたアップデート」と呼ばれます。
3.4.3 Split horizon
3.4.3 分裂地平線
Note that some of the problem above is caused by the fact that A and C are engaged in a pattern of mutual deception. Each claims to be able to get to D via the other. This can be prevented by being a bit more careful about where information is sent. In particular, it is never useful to claim reachability for a destination network to the neighbor(s) from which the route was learned. "Split horizon" is a scheme for avoiding problems caused by including routes in updates sent to the router from which they were learned. The "simple split horizon" scheme omits routes learned from one neighbor in updates sent to that neighbor. "Split horizon with poisoned reverse" includes such routes in updates, but sets their metrics to infinity.
AとCが互いの詐欺のパターンに従事しているという事実によって上の問題のいくつかが引き起こされることに注意してください。 それぞれが、もう片方でDを始めることができると主張します。 情報が送られるところに関して慎重なもう少しによって、これを防ぐことができます。 ルートが学習された隣人への送信先ネットワークに可到達性の代金を請求するのは特に、決して役に立ちません。 「分裂地平線」はそれらが学習されたルータに送られたアップデートにルートを含んでいることによって引き起こされた問題を避けることの計画です。 「簡単な分裂地平線」計画は1人の隣人からその隣人に送られたアップデートで学習されたルートを省略します。 「当たっている逆がある分裂地平線」は、アップデートにそのようなルートを含んでいますが、それらの測定基準を無限で設定します。
If A thinks it can get to D via C, its messages to C should indicate that D is unreachable. If the route through C is real, then C either has a direct connection to D, or a connection through some other router. C's route can't possibly go back to A, since that forms a loop. By telling C that D is unreachable, A simply guards against the possibility that C might get confused and believe that there is a route through A. This is obvious for a point to point line. But consider the possibility that A and C are connected by a broadcast network such as an Ethernet, and there are other routers on that network. If A has a route through C, it should indicate that D is unreachable when talking to any other router on that network. The other routers on the network can get to C themselves. They would never need to get to C via A. If A's best route is really through C, no other router on that network needs to know that A can reach D. This is fortunate, because it means that the same update message that
Aが、Cを通してDを始めることができると思うなら、Cへのメッセージは、Dが手が届かないのを示すべきです。 Cを通したルートが本当であるなら、Cには、Dへのダイレクト関係、またはある他のルータを通した関係があります。 それが輪を形成するので、CのルートはAに戻ることができません。 Dが手が届かないとCに言うことによって、ポイントが線を指すように、A.Thisを通してあるCが得るかもしれない可能性に対する単に番人がそれを混乱して、ルートを信じているAは明白です。 しかし、AとCがイーサネットなどの放送網によって接続される可能性を考えてください。そうすれば、他のルータがそのネットワークにあります。 AがCを通してルートを持っているなら、それは、そのネットワークに関していかなる他のルータとも話すとき、Dが手が届かないのを示すべきです。 ネットワークの他のルータは自分たちをCに得ることができます。 彼らは、A缶の範囲D.Thisが幸いであることを知るのに決して本当にC、他のルータを通してではなくIf Aの最も良いルートがあるA.を通したネットワークが必要とするCを始める必要がありません、同じアップデートがそれを通信させることを意味するので
Malkin Standards Track [Page 15] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[15ページ]RFC2453はバージョン1998年11月2日を裂きます。
is used for C can be used for all other routers on the same network. Thus, update messages can be sent by broadcast.
Cに使用されて、同じネットワークの他のすべてのルータに使用できます。 したがって、放送でアップデートメッセージを送ることができます。
In general, split horizon with poisoned reverse is safer than simple split horizon. If two routers have routes pointing at each other, advertising reverse routes with a metric of 16 will break the loop immediately. If the reverse routes are simply not advertised, the erroneous routes will have to be eliminated by waiting for a timeout. However, poisoned reverse does have a disadvantage: it increases the size of the routing messages. Consider the case of a campus backbone connecting a number of different buildings. In each building, there is a router connecting the backbone to a local network. Consider what routing updates those routers should broadcast on the backbone network. All that the rest of the network really needs to know about each router is what local networks it is connected to. Using simple split horizon, only those routes would appear in update messages sent by the router to the backbone network. If split horizon with poisoned reverse is used, the router must mention all routes that it learns from the backbone, with metrics of 16. If the system is large, this can result in a large update message, almost all of whose entries indicate unreachable networks.
一般に、当たっている逆がある分裂地平線は簡単な分裂地平線より安全です。 ルートが2つのルータで互いを指し示すと、16におけるメートル法のaで逆のルートの広告を出すと、輪はすぐに、壊れるでしょう。 逆のルートが絶対に広告に掲載されないと、誤ったルートは、タイムアウトを待つことによって、排除されなければならないでしょう。 しかしながら、当たっている逆には、不都合があります: それはルーティング・メッセージのサイズを増加させます。 キャンパス背骨接続に関するケースが多くの異なったビルであると考えてください。 各ビルに、背骨を企業内情報通信網に接続するルータがあります。 それらのルータが背骨ネットワークでどんなルーティングアップデートを放送するべきであるか考えてください。 ネットワークの残りが本当に各ルータに関して知る必要があるすべてはそれがどんな企業内情報通信網に関連づけられるかということです。 簡単な分裂地平線を使用して、それらのルートだけがルータによって背骨ネットワークに送られたアップデートメッセージに現れるでしょう。 当たっている逆がある分裂地平線が使用されているなら、ルータはそれが背骨から学ぶすべてのルートに言及しなければなりません、16の測定基準で。 システムが大きいなら、これはエントリーのほとんどすべてが手の届かないネットワークを示す大きいアップデートメッセージをもたらすことができます。
In a static sense, advertising reverse routes with a metric of 16 provides no additional information. If there are many routers on one broadcast network, these extra entries can use significant bandwidth. The reason they are there is to improve dynamic behavior. When topology changes, mentioning routes that should not go through the router as well as those that should can speed up convergence. However, in some situations, network managers may prefer to accept somewhat slower convergence in order to minimize routing overhead. Thus implementors may at their option implement simple split horizon rather than split horizon with poisoned reverse, or they may provide a configuration option that allows the network manager to choose which behavior to use. It is also permissible to implement hybrid schemes that advertise some reverse routes with a metric of 16 and omit others. An example of such a scheme would be to use a metric of 16 for reverse routes for a certain period of time after routing changes involving them, and thereafter omitting them from updates.
平衡感覚には、16におけるメートル法のaで逆のルートの広告を出すのは追加情報を全く提供しません。 多くのルータが1つの放送網にあれば、これらの余分なエントリーは重要な帯域幅を使用できます。 彼らがそこにいる理由は動的挙動を改良することです。 トポロジーが変化するとき、それらと同様にそうするべきであるルータに直面しているはずがないルートに言及すると、集合を早くできます。 しかしながら、いくつかの状況で、ネットワークマネージャは、ルーティングオーバーヘッドを最小にするためにいくらか遅い集合を受け入れるのを好むかもしれません。 したがって、作成者が彼らの選択のときに当たっている逆で分裂地平線よりむしろ簡単な分裂地平線を実行するかもしれませんか、または彼らはネットワークマネージャがどの振舞いを使用したらよいかを選ぶことができる設定オプションを提供するかもしれません。 また、16におけるメートル法のaでいくつかの逆のルートの広告を出して、他のものを省略するハイブリッド計画を実行するのも許されています。 そのような計画に関する例はアップデートからそれらにかかわる変化を発送した後に、ある期間の間の16における逆のルートにおけるメートル法の、そして、その後省略しているそれらを使用するだろうことです。
The router requirements RFC [11] specifies that all implementation of RIP must use split horizon and should also use split horizon with poisoned reverse, although there may be a knob to disable poisoned reverse.
ルータ要件RFC[11]は、RIPのすべての実現が分裂地平線を使用しなければならなくて、また、当たっている逆がある分裂地平線を使用するべきであると指定します、当たっている逆を無能にするノブがあるかもしれませんが。
Malkin Standards Track [Page 16] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[16ページ]RFC2453はバージョン1998年11月2日を裂きます。
3.4.4 Triggered updates
3.4.4 引き起こされたアップデート
Split horizon with poisoned reverse will prevent any routing loops that involve only two routers. However, it is still possible to end up with patterns in which three routers are engaged in mutual deception. For example, A may believe it has a route through B, B through C, and C through A. Split horizon cannot stop such a loop. This loop will only be resolved when the metric reaches infinity and the network involved is then declared unreachable. Triggered updates are an attempt to speed up this convergence. To get triggered updates, we simply add a rule that whenever a router changes the metric for a route, it is required to send update messages almost immediately, even if it is not yet time for one of the regular update message. (The timing details will differ from protocol to protocol. Some distance vector protocols, including RIP, specify a small time delay, in order to avoid having triggered updates generate excessive network traffic.) Note how this combines with the rules for computing new metrics. Suppose a router's route to destination N goes through router G. If an update arrives from G itself, the receiving router is required to believe the new information, whether the new metric is higher or lower than the old one. If the result is a change in metric, then the receiving router will send triggered updates to all the hosts and routers directly connected to it. They in turn may each send updates to their neighbors. The result is a cascade of triggered updates. It is easy to show which routers and hosts are involved in the cascade. Suppose a router G times out a route to destination N. G will send triggered updates to all of its neighbors. However, the only neighbors who will believe the new information are those whose routes for N go through G. The other routers and hosts will see this as information about a new route that is worse than the one they are already using, and ignore it. The neighbors whose routes go through G will update their metrics and send triggered updates to all of their neighbors. Again, only those neighbors whose routes go through them will pay attention. Thus, the triggered updates will propagate backwards along all paths leading to router G, updating the metrics to infinity. This propagation will stop as soon as it reaches a portion of the network whose route to destination N takes some other path.
当たっている逆がある分裂地平線は2つのルータだけにかかわるどんなルーティング輪も防ぐでしょう。 しかしながら、3つのルータが互いの詐欺に従事しているパターンで終わるのはまだ可能です。 例えば、Aは、Bを通してルートを持っていると信じるかもしれません、BからC、A.Split地平線を通るCはそのような輪を止めることができません。 次に、無限とネットワークがかかわったメートル法の範囲が手が届かないと宣言されるときだけ、この輪は決議されるでしょう。 引き起こされたアップデートはこの集合を早くする試みです。 引き起こされたアップデートを得るために、私たちは単に、ルータがルートへのメートル法を変えるときはいつも、それがほぼすぐにアップデートメッセージを送るのに必要であるという規則を加えます、しかし、通常のアップデートメッセージの1つの時間でなくても。 (タイミングの詳細は議定書の中で述べるプロトコルと異なるでしょう。 RIPを含むいくつかの距離ベクトルプロトコルが小さい時間遅れを指定します、引き起こされたアップデートに過度のネットワークトラフィックを発生させるのを避けるために。) これがどう新しい測定基準を計算するための規則に結合するように注意してくださいか。 目的地NへのルータのルートがルータG.Ifを通るなら、アップデートはG自体から到着して、受信ルータが、新情報、新しくメートル法が、より高いか、そして、または老人より少ない1つを信じるのに必要です。 結果がメートル法で変化であるなら、受信ルータは直接それに接されたすべてのホストとルータに引き起こされたアップデートを送るでしょう。 彼らは順番にそれぞれアップデートを隣人に送るかもしれません。 結果は引き起こされたアップデートの滝です。 どのルータとホストが滝にかかわるかを示すのは簡単です。 目的地N.Gへのルートからの回が送るルータGが隣人のすべてにアップデートの引き金となったと仮定してください。 しかしながら、新情報を信じている唯一の隣人がNのためのルートがG. 他のルータに直面しているそれらであり、ホストは、彼らが既に使用しているものより悪い新しいルートの情報であるとこれをみなして、それを無視するでしょう。 ルートがGを通る隣人は、彼らの隣人のすべてにそれらの測定基準をアップデートして、引き起こされたアップデートを送るでしょう。 ルートがそれらを通るそれらの隣人だけが注意を向けるでしょう。 したがって、測定基準を無限でアップデートして、引き起こされたアップデートは、ルータGに通じながら、すべての経路に沿って後方に伝播されるでしょう。 目的地Nへのルートがある他の経路を取るネットワークの一部に達するとすぐに、この伝播は止まるでしょう。
If the system could be made to sit still while the cascade of triggered updates happens, it would be possible to prove that counting to infinity will never happen. Bad routes would always be removed immediately, and so no routing loops could form.
引き起こされたアップデートの滝が起こっている間、システムはまだ座らされることができるなら、無限で数えるのが決して起こらないと立証するのが可能でしょうに。 悪いルートはすぐにいつも取り外されるでしょう、したがって、ルーティング輪を全く形成できませんでした。
Unfortunately, things are not so nice. While the triggered updates are being sent, regular updates may be happening at the same time. Routers that haven't received the triggered update yet will still be sending out information based on the route that no longer exists. It
残念ながら、いろいろなことはそれほど良くはありません。 引き起こされたアップデートを送る間、定期的なアップデートは同時に、起こる予定であるかもしれません。 まだ引き起こされたアップデートを受けていないルータがまだもう存在しないルートに基づく情報を出しているでしょう。 それ
Malkin Standards Track [Page 17] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[17ページ]RFC2453はバージョン1998年11月2日を裂きます。
is possible that after the triggered update has gone through a router, it might receive a normal update from one of these routers that hasn't yet gotten the word. This could reestablish an orphaned remnant of the faulty route. If triggered updates happen quickly enough, this is very unlikely. However, counting to infinity is still possible.
引き起こされたアップデートの後のそれがルータに直面していたのが可能です、それはまだ耳にしていないこれらのルータの1つから通常のアップデートを受けるかもしれません。 これは不完全なルートの親のない残りを回復させるかもしれません。 引き起こされるならアップデートが十分急速に起こるので、これは非常にありそうもないです。 しかしながら、無限で数えるのはまだ可能です。
The router requirements RFC [11] specifies that all implementation of RIP must implement triggered update for deleted routes and may implement triggered updates for new routes or change of routes. RIP implementations must also limit the rate which of triggered updates may be trandmitted. (see section 3.10.1)
ルータ要件RFC[11]は、RIPのすべての実現が削除されたルートに引き起こされたアップデートを実行しなければならなくて、ルートの新しいルートか変化のために引き起こされたアップデートを実行するかもしれないと指定します。 また、RIP実現は引き起こされたアップデートについてtrandmittedされるかもしれないレートを制限しなければなりません。 (セクション3.10.1を見ます)
3.5 Protocol Specification
3.5 プロトコル仕様
RIP is intended to allow routers to exchange information for computing routes through an IPv4-based network. Any router that uses RIP is assumed to have interfaces to one or more networks, otherwise it isn't really a router. These are referred to as its directly- connected networks. The protocol relies on access to certain information about each of these networks, the most important of which is its metric. The RIP metric of a network is an integer between 1 and 15, inclusive. It is set in some manner not specified in this protocol; however, given the maximum path limit of 15, a value of 1 is usually used. Implementations should allow the system administrator to set the metric of each network. In addition to the metric, each network will have an IPv4 destination address and subnet mask associated with it. These are to be set by the system administrator in a manner not specified in this protocol.
RIPが、ルータがIPv4を拠点とするネットワークを通してルートを計算するために情報交換するのを許容することを意図します。 RIPを使用するどんなルータもインタフェースを1つ以上のネットワークまで持っていると思われます。さもなければ、それは本当にルータではありません。 これらは直接接続されたネットワークと呼ばれます。 プロトコルはおよそそれぞれこれらのネットワークのある情報へのそれがメートル法であるという中でそれのもの最も重要であることであるアクセスに依存します。 ネットワークにおけるメートル法のRIPは1〜15の整数的であって、包括的です。 それはこのプロトコルで指定されなかった何らかの方法で設定されます。 しかしながら、15の最大の経路限界を考えて、通常、1の値は使用されます。 実現で、システム管理者はそれぞれのネットワークのメートル法を設定できるべきです。 メートル法に加えて、各ネットワークはそれに関連しているIPv4送付先アドレスとサブネットマスクを持つでしょう。 これらはこのプロトコルで指定されなかった方法でシステム管理者によって設定されることになっています。
Any host that uses RIP is assumed to have interfaces to one or more networks. These are referred to as its "directly-connected networks". The protocol relies on access to certain information about each of these networks. The most important is its metric or "cost". The metric of a network is an integer between 1 and 15 inclusive. It is set in some manner not specified in this protocol. Most existing implementations always use a metric of 1. New implementations should allow the system administrator to set the cost of each network. In addition to the cost, each network will have an IPv4 network number and a subnet mask associated with it. These are to be set by the system administrator in a manner not specified in this protocol.
RIPを使用するどんなホストもインタフェースを1つ以上のネットワークまで持っていると思われます。 これらは「直接接続されたネットワーク」と呼ばれます。 プロトコルはおよそそれぞれこれらのネットワークのある情報へのアクセスに依存します。 最も重要であるのは、それがメートル法であるということです。「かかる」または。 ネットワークのメートル法は1と15の間で包括的な整数です。 それはこのプロトコルで指定されなかった何らかの方法で設定されます。 ほとんどの既存の実装がいつも1におけるメートル法のaを使用します。 新しい実装で、システム管理者はそれぞれのネットワークの費用を設定できるべきです。 費用に加えて、各ネットワークはIPv4ネットワーク・ナンバーとそれに関連しているサブネットマスクを持つでしょう。 これらはこのプロトコルで指定されなかった方法でシステム管理者によって設定されることになっています。
Note that the rules specified in section 3.7 assume that there is a single subnet mask applying to each IPv4 network, and that only the subnet masks for directly-connected networks are known. There may be systems that use different subnet masks for different subnets within a single network. There may also be instances where it is desirable
セクション3.7で指定された規則が、それぞれのIPv4ネットワークに適用される単一のサブネットマスクがあると仮定して、直接接続されたネットワークのためのサブネットマスクだけが知られていることに注意してください。 異なったサブネットにただ一つのネットワークの中で異なったサブネットマスクを使用するシステムがあるかもしれません。 また、インスタンスがそれが望ましいところにあるかもしれません。
Malkin Standards Track [Page 18] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[18ページ]RFC2453はバージョン1998年11月2日を裂きます。
for a system to know the subnets masks of distant networks. Network- wide distribution of routing information which contains different subnet masks is permitted if all routers in the network are running the extensions presented in this document. However, if all routers in the network are not running these extensions distribution of routing information containing different subnet masks must be limited to avoid interoperability problems. See sections 3.7 and 4.3 for the rules governing subnet distribution.
システムが遠方のネットワークのサブネットマスクを知るように。 ネットワークにおけるすべてのルータが本書では提示された拡大を実行しているなら、異なったサブネットマスクを含むルーティング情報のネットワーク広範な分布は受入れられます。 しかしながら、ネットワークにおけるすべてのルータがこれらを実行していないなら、相互運用性問題を避けるために異なったサブネットマスクを含むルーティング情報の拡大分配を制限しなければなりません。サブネット分配を治める規則に関してセクション3.7と4.3を見てください。
Each router that implements RIP is assumed to have a routing table. This table has one entry for every destination that is reachable throughout the system operating RIP. Each entry contains at least the following information:
RIPを実装する各ルータが経路指定テーブルを持っていると思われます。 このテーブルには、各RIPを操作しながらシステム中で届いている目的地あたり1つのエントリーがあります。 各エントリーは少なくとも以下の情報を含んでいます:
- The IPv4 address of the destination.
- 目的地のIPv4アドレス。
- A metric, which represents the total cost of getting a datagram
from the router to that destination. This metric is the sum of the
costs associated with the networks that would be traversed to get
to the destination.
- Aメートル法であり、どれがルータからその目的地までデータグラムを手に入れる総費用を表しますか? これほどメートル法であることは、目的地に着くように横断されるネットワークに関連しているコストの合計です。
- The IPv4 address of the next router along the path to the
destination (i.e., the next hop). If the destination is on one of
the directly-connected networks, this item is not needed.
- 目的地(すなわち、次のホップ)への次のルータの経路に沿ったIPv4アドレス。 目的地が直接接続されたネットワークの1つにあるなら、この項目は必要ではありません。
- A flag to indicate that information about the route has changed
recently. This will be referred to as the "route change flag."
- ルートのその情報を示す旗は最近、変化しました。 これは「ルート変化旗」と呼ばれるでしょう。
- Various timers associated with the route. See section 3.6 for more
details on timers.
- 様々なタイマはルートと交際しました。 タイマに関するその他の詳細に関してセクション3.6を見てください。
The entries for the directly-connected networks are set up by the router using information gathered by means not specified in this protocol. The metric for a directly-connected network is set to the cost of that network. As mentioned, 1 is the usual cost. In that case, the RIP metric reduces to a simple hop-count. More complex metrics may be used when it is desirable to show preference for some networks over others (e.g., to indicate of differences in bandwidth or reliability).
直接接続されたネットワークのためのエントリーはこのプロトコルで指定されなかった手段で集められた情報を使用するルータによってセットアップされます。 直接接続されたネットワークのためのメートル法はそのネットワークの費用に設定されます。 言及されるように、1は普通の費用です。 その場合、RIP、メートル法、簡単なホップカウントに減少します。 いくつかのネットワークのために他のもの(例えば帯域幅か信頼性の違いについて示す)の上で優先するのが望ましいときに、より複雑な測定基準は使用されるかもしれません。
To support the extensions detailed in this document, each entry must additionally contain a subnet mask. The subnet mask allows the router (along with the IPv4 address of the destination) to identify the different subnets within a single network as well as the subnets masks of distant networks.
このドキュメントで詳細な拡大をサポートするために、各エントリーはさらに、サブネットマスクを含まなければなりません。 サブネットマスクで、ルータ(目的地のIPv4アドレスに伴う)は遠方のネットワークのサブネットマスクと同様にただ一つのネットワークの中で異なったサブネットを特定できます。
Malkin Standards Track [Page 19] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[19ページ]RFC2453はバージョン1998年11月2日を裂きます。
Implementors may also choose to allow the system administrator to enter additional routes. These would most likely be routes to hosts or networks outside the scope of the routing system. They are referred to as "static routes." Entries for destinations other than these initial ones are added and updated by the algorithms described in the following sections.
また、作成者は、システム管理者が追加ルートに入るのを許可するのを選ぶかもしれません。 これらはたぶんホストかルーティングシステムの範囲の外のネットワークへのルートでしょう。 それらは「スタティックルート」と呼ばれます。 以下のセクションで説明されたアルゴリズムで、これらの初期のもの以外の目的地のためのエントリーを加えて、アップデートします。
In order for the protocol to provide complete information on routing, every router in the AS must participate in the protocol. In cases where multiple IGPs are in use, there must be at least one router which can leak routing information between the protocols.
プロトコルがルーティングの完全な情報を提供するように、ASのあらゆるルータがプロトコルに参加しなければなりません。 複数のIGPsが使用中である場合には、プロトコルの間には、ルーティング情報を漏らすことができる少なくとも1つのルータがあるに違いありません。
3.6 Message Format
3.6 メッセージ・フォーマット
RIP is a UDP-based protocol. Each router that uses RIP has a routing process that sends and receives datagrams on UDP port number 520, the RIP-1/RIP-2 port. All communications intended for another routers's RIP process are sent to the RIP port. All routing update messages are sent from the RIP port. Unsolicited routing update messages have both the source and destination port equal to the RIP port. Update messages sent in response to a request are sent to the port from which the request came. Specific queries may be sent from ports other than the RIP port, but they must be directed to the RIP port on the target machine.
RIPはUDPベースのプロトコルです。 RIPを使用する各ルータがUDPポートNo.520でデータグラムを送って、受けるルーティングプロセスを持っています、RIP-1/RIP-2ポート。 別のルータsのRIPプロセスのために意図するすべてのコミュニケーションをRIPポートに送ります。 RIPポートからすべてのルーティングアップデートメッセージを送ります。 求められていないルーティングアップデートメッセージには、ソースと仕向港のRIPポートと等しい両方があります。 要求に対応して送られたアップデートメッセージを要求が来たポートに送ります。 RIPポート以外のポートから特定の質問を送るかもしれませんが、ターゲットマシンの上のRIPポートにそれらを向けなければなりません。
The RIP packet format is:
RIPパケット・フォーマットは以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| |
~ RIP Entry (20) ~
| |
+---------------+---------------+---------------+---------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コマンド(1)| バージョン(1)| ゼロが(2)であったならそうしなければなりません。| +---------------+---------------+-------------------------------+ | | ~ エントリー(20)~、を裂いてください。| | +---------------+---------------+---------------+---------------+
Malkin Standards Track [Page 20] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[20ページ]RFC2453はバージョン1998年11月2日を裂きます。
There may be between 1 and 25 (inclusive) RIP entries. A RIP-1 entry has the following format:
1〜25の(包括的)のRIPエントリーがあるかもしれません。 RIP-1エントリーには、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IPv4 address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレスファミリー識別子(2)| ゼロが(2)であったならそうしなければなりません。| +-------------------------------+-------------------------------+ | IPv4アドレス(4)| +---------------------------------------------------------------+ | ゼロが(4)であったならそうしなければなりません。| +---------------------------------------------------------------+ | ゼロが(4)であったならそうしなければなりません。| +---------------------------------------------------------------+ | メートル法の(4)| +---------------------------------------------------------------+
Field sizes are given in octets. Unless otherwise specified, fields contain binary integers, in network byte order, with the most- significant octet first (big-endian). Each tick mark represents one bit.
八重奏で分野サイズを与えます。 別の方法で指定されない場合、分野は最初に(ビッグエンディアン)、最も多くの重要な八重奏でネットワークバイトオーダーにおける2進整数を含みます。 各ダニ麻痺は1ビットを表します。
Every message contains a RIP header which consists of a command and a version number. This section of the document describes version 1 of the protocol; section 4 describes the version 2 extensions. The command field is used to specify the purpose of this message. The commands implemented in version 1 and 2 are:
あらゆるメッセージがコマンドとバージョン番号から成るRIPヘッダーを含んでいます。 ドキュメントのこのセクションはプロトコルのバージョン1について説明します。 セクション4はバージョン2拡大について説明します。 コマンド欄は、このメッセージの目的を指定するのに使用されます。 バージョン1と2で実装されたコマンドは以下の通りです。
1 - request A request for the responding system to send all or
part of its routing table.
1--応じるシステムがすべてを送るというA要求か経路指定テーブルの一部を要求してください。
2 - response A message containing all or part of the sender's
routing table. This message may be sent in response
to a request, or it may be an unsolicited routing
update generated by the sender.
2--送付者の経路指定テーブルのすべてか一部を含む応答Aメッセージ。 要求に対応してこのメッセージを送るかもしれませんか、それは送付者によって生成された求められていないルーティングアップデートであるかもしれません。
For each of these message types, in version 1, the remainder of the datagram contains a list of Route Entries (RTEs). Each RTE in this list contains an Address Family Identifier (AFI), destination IPv4 address, and the cost to reach that destination (metric).
これらのメッセージタイプ各人のために、バージョン1では、データグラムの残りはRoute Entries(RTEs)のリストを含んでいます。 このリストの各RTEはその目的地(メートル法の)に達するAddress Family Identifier(AFI)、送付先IPv4アドレス、および費用を含んでいます。
The AFI is the type of address. For RIP-1, only AF_INET (2) is generally supported.
AFIはアドレスのタイプです。 一般に、RIP-1に関しては、AF_INET(2)だけがサポートされます。
The metric field contains a value between 1 and 15 (inclusive) which specifies the current metric for the destination; or the value 16 (infinity), which indicates that the destination is not reachable.
メートル法の分野は1と15(包括的な)の間の目的地における、メートル法の電流を指定する値を含んでいます。 または、値16(無限)。(その値は目的地に届いていないのを示します)。
Malkin Standards Track [Page 21] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[21ページ]RFC2453はバージョン1998年11月2日を裂きます。
3.7 Addressing Considerations
3.7 問題を扱うこと。
Distance vector routing can be used to describe routes to individual hosts or to networks. The RIP protocol allows either of these possibilities. The destinations appearing in request and response messages can be networks, hosts, or a special code used to indicate a default address. In general, the kinds of routes actually used will depend upon the routing strategy used for the particular network. Many networks are set up so that routing information for individual hosts is not needed. If every node on a given network or subnet is accessible through the same routers, then there is no reason to mention individual hosts in the routing tables. However, networks that include point-to-point lines sometimes require routers to keep track of routes to certain nodes. Whether this feature is required depends upon the addressing and routing approach used in the system. Thus, some implementations may choose not to support host routes. If host routes are not supported, they are to be dropped when they are received in response messages (see section 3.7.2).
個々のホスト、または、ネットワークにルートを説明するのに距離ベクトルルーティングを使用できます。 RIPプロトコルはこれらの可能性のどちらかを許容します。 要求と応答メッセージに現れる目的地は、ネットワーク、ホスト、またはデフォルトアドレスを示すのに使用される特別なコードであるかもしれません。 一般に、実際に使用されるルートの種類は特定のネットワークに使用されるルーティング戦略に依存するでしょう。 多くのネットワークが、個々のホストへのルーティング情報は必要でないように、設立されます。 与えられたネットワークかサブネットのあらゆるノードが同じルータを通してアクセス可能であるなら、経路指定テーブルで個々のホストについて言及する理由が全くありません。 しかしながら、二地点間系列を含んでいるネットワークは、あるノードにルートの動向をおさえるために時々ルータを必要とします。 この特徴が必要であるかどうかがアプローチがシステムで使用したアドレシングとルーティングによります。 したがって、いくつかの実装が、ホストにルートを支えないのを選ぶかもしれません。 応答メッセージでそれらを受け取るとき(セクション3.7.2を見てください)、ホストルートを支えないなら、それらを下げることになっています。
The RIP-1 packet format does not distinguish among various types of address. Fields that are labeled "address" can contain any of the following:
RIP-1パケット・フォーマットは様々なタイプのアドレスの中で区別されません。 「アドレス」とラベルされる分野は以下のどれかを含むことができます:
host address subnet number network number zero (default route)
ホスト・アドレスサブネット数のネットワーク・ナンバーゼロ(デフォルトルート)
Entities which use RIP-1 are assumed to use the most specific information available when routing a datagram. That is, when routing a datagram, its destination address must first be checked against the list of node addresses. Then it must be checked to see whether it matches any known subnet or network number. Finally, if none of these match, the default route is used.
データグラムを発送するとき、RIP-1を使用する実体が利用可能な最も特定の情報を使用すると思われます。 すなわち、データグラムを発送するとき、最初に、ノードアドレスのリストに対して送付先アドレスをチェックしなければなりません。 そして、それが何か知られているサブネットやネットワーク・ナンバーに合っているかどうか確認するためにそれをチェックしなければなりません。 最終的に、これらのいずれも合っていないなら、デフォルトルートは使用されています。
When a node evaluates information that it receives via RIP-1, its interpretation of an address depends upon whether it knows the subnet mask that applies to the net. If so, then it is possible to determine the meaning of the address. For example, consider net 128.6. It has a subnet mask of 255.255.255.0. Thus 128.6.0.0 is a network number, 128.6.4.0 is a subnet number, and 128.6.4.1 is a node address. However, if the node does not know the subnet mask, evaluation of an address may be ambiguous. If there is a non-zero node part, there is no clear way to determine whether the address represents a subnet number or a node address. As a subnet number would be useless without the subnet mask, addresses are assumed to represent nodes in this situation. In order to avoid this sort of ambiguity, when using version 1, nodes must not send subnet routes to nodes that cannot be expected to know the appropriate subnet mask. Normally hosts only know the subnet masks for directly-connected networks. Therefore, unless special provisions have been made,
ノードがRIP-1を通して受信するという情報を評価するとき、アドレスの解釈はそれがネットに適用されるサブネットマスクを知っているかどうかによります。 そうだとすれば、その時、アドレスの意味を決定するのは可能です。 例えば、ネットの128.6を考えてください。 それは255.255のサブネットマスクを持っています。.255 .0。 .0は、サブネット番号と、128.6です。このようにして、128.6 .0 .0がネットワーク・ナンバーである、128.6、.4、.4 .1はノードアドレスです。 しかしながら、ノードがサブネットマスクを知らないなら、アドレスの評価はあいまいであるかもしれません。 非ゼロノード一部があれば、アドレスがサブネット番号かノードアドレスを表すかどうか決定するどんな明確な方法もありません。 サブネット番号はサブネットマスクなしで役に立たないでしょう、したがって、アドレスがこの状況でノードを表すと思われます。 バージョン1を使用するとき、この種類のあいまいさを避けるために、ノードは適切なサブネットマスクを知ることを期待できないノードにサブネットルートを送ってはいけません。 通常、ホストは直接接続されたネットワークでサブネットマスクを知っているだけです。 特別条項がしたがって、作られていないなら
Malkin Standards Track [Page 22] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[22ページ]RFC2453はバージョン1998年11月2日を裂きます。
routes to a subnet must not be sent outside the network of which the subnet is a part. RIP-2 (see section 4) eliminates the subnet/host ambiguity by including the subnet mask in the routing entry.
サブネットが部分であるネットワークの外でサブネットへのルートを送ってはいけません。 RIP-2(セクション4を見る)は、ルーティングエントリーにサブネットマスクを含んでいることによって、サブネット/ホストのあいまいさを排除します。
This "subnet filtering" is carried out by the routers at the "border" of the subnetted network. These are routers which connect that network with some other network. Within the subnetted network, each subnet is treated as an individual network. Routing entries for each subnet are circulated by RIP. However, border routers send only a single entry for the network as a whole to nodes in other networks. This means that a border router will send different information to different neighbors. For neighbors connected to the subnetted network, it generates a list of all subnets to which it is directly connected, using the subnet number. For neighbors connected to other networks, it makes a single entry for the network as a whole, showing the metric associated with that network. This metric would normally be the smallest metric for the subnets to which the router is attached.
この「サブネットフィルタリング」がサブネット化したネットワークの「境界」のルータによって行われます。 これらはそのネットワークをある他のネットワークに接続するルータです。 サブネット化したネットワークの中では、各サブネットは個々のネットワークとして扱われます。 RIPは各サブネットのためのルート設定エントリーを循環させます。 しかしながら、境界ルータは全体でネットワークのために他のネットワークにおけるノードに単一のエントリーだけを送ります。 これは、境界ルータが異なった情報を異なった隣人に送ることを意味します。 サブネット化したネットワークに接続された隣人に関しては、それが直接関連づけられるすべてのサブネットのリストを生成します、サブネット番号を使用して。 他のネットワークに接続された隣人に関しては、全体でネットワークのために単一のエントリーをします、そのネットワークに関連しているメートル法を示して。 通常、これほどメートル法であることは、ルータが付けているサブネットにおける、メートル法の最も小さいものでしょう。
Similarly, border routers must not mention host routes for nodes within one of the directly-connected networks in messages to other networks. Those routes will be subsumed by the single entry for the network as a whole.
同様に、境界ルータはノードのためにメッセージの直接接続されたネットワークの1つの中でホストルートを他のネットワークに言ってはいけません。 それらのルートは全体でネットワークに、単一のエントリーで包括されるでしょう。
The router requirements RFC [11] specifies that all implementation of RIP should support host routes but if they do not then they must ignore any received host routes.
そしてそうしないなら、ルータ要件RFC[11]は、RIPのすべての実装がホストにルートを支えるべきであると指定しますが、彼らはどんな容認されたホストルートも無視しなければなりません。
The special address 0.0.0.0 is used to describe a default route. A default route is used when it is not convenient to list every possible network in the RIP updates, and when one or more closely- connected routers in the system are prepared to handle traffic to the networks that are not listed explicitly. These routers should create RIP entries for the address 0.0.0.0, just as if it were a network to which they are connected. The decision as to how routers create entries for 0.0.0.0 is left to the implementor. Most commonly, the system administrator will be provided with a way to specify which routers should create entries for 0.0.0.0; however, other mechanisms are possible. For example, an implementor might decide that any router which speaks BGP should be declared to be a default router. It may be useful to allow the network administrator to choose the metric to be used in these entries. If there is more than one default router, this will make it possible to express a preference for one over the other. The entries for 0.0.0.0 are handled by RIP in exactly the same manner as if there were an actual network with this address. System administrators should take care to make sure that routes to 0.0.0.0 do not propagate further than is intended. Generally, each autonomous system has its own preferred default
.0が使用されている特別なアドレス0.0.0はデフォルトルートを説明します。 RIPアップデートであらゆる可能なネットワークを記載するのが便利でなく、システムの1つ以上の密接に接続されたルータが明らかに記載されていないネットワークにトラフィックを扱うために準備されるとき、デフォルトルートは使用されています。 これらのルータがアドレスのためのRIPエントリーを作成するべきである、0.0、.0、.0、まるでまさしくそれがそれらが関連しているネットワークであるかのように。 ルータは0.0のためのエントリーを作成します。決定、どのように、.0 .0 作成者に残されるか。 最も一般的に、どのルータが0.0のためのエントリーを作成するべきであるかを指定する方法をシステム管理者に提供する、.0、.0。 しかしながら、他のメカニズムは可能です。 例えば、作成者は、BGPを話すどんなルータもデフォルトルータであると宣言されるべきであると決めるかもしれません。 ネットワーク管理者がこれらのエントリーで使用されるためにメートル法を選ぶのを許容するのは役に立つかもしれません。 1つ以上のデフォルトルータがあると、これで、もう片方の上で1のための優先を言い表すのは可能になるでしょう。 エントリー、0.0 .0 まるでこのアドレスがある実際のネットワークがあるかのように.0はまさに同じ方法でRIPによって扱われます。 システム管理者は、確実にそれをルートに0.0までするように、.0がする.0が意図するより遠くに伝播されないことに注意するべきです。 一般に、各自律システムには、それ自身の都合のよいデフォルトがあります。
Malkin Standards Track [Page 23] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[23ページ]RFC2453はバージョン1998年11月2日を裂きます。
router. Thus, routes involving 0.0.0.0 should generally not leave the boundary of an autonomous system. The mechanisms for enforcing this are not specified in this document.
ルータ。 その結果、0.0に一般に、.0が自律システムの境界を残すべきでない.0を伴うルート。 これを実施するためのメカニズムは本書では指定されません。
3.8 Timers
3.8 タイマ
This section describes all events that are triggered by timers.
このセクションはタイマによって引き起こされるすべてのイベントについて説明します。
Every 30 seconds, the RIP process is awakened to send an unsolicited Response message containing the complete routing table (see section 3.9 on Split Horizon) to every neighboring router. When there are many routers on a single network, there is a tendency for them to synchronize with each other such that they all issue updates at the same time. This can happen whenever the 30 second timer is affected by the processing load on the system. It is undesirable for the update messages to become synchronized, since it can lead to unnecessary collisions on broadcast networks. Therefore, implementations are required to take one of two precautions:
30秒毎、RIPプロセスは、完全な経路指定テーブル(Split Horizonの上のセクション3.9を見る)をあらゆる隣接しているルータに含む求められていないResponseメッセージを送るために目を覚まします。 多くのルータがただ一つのネットワークにあるとき、互いに連動する傾向があるので、それらは皆、同時に、アップデートを発行します。 30 2番目のタイマがシステムの上の処理負荷で影響を受けるときはいつも、これは起こることができます。 連動するようになるアップデートメッセージに、それは、放送網における不要な衝突に通じることができるので、望ましくありません。 したがって、実装が2つの注意の1つを取るのに必要です:
- The 30-second updates are triggered by a clock whose rate is not
affected by system load or the time required to service the
previous update timer.
- 30秒のアップデートがレートがシステム・ロードで影響を受けない時計で引き起こされるか、または時間が前のアップデートタイマを調整するのが必要です。
- The 30-second timer is offset by a small random time (+/- 0 to 5
seconds) each time it is set. (Implementors may wish to consider
even larger variation in the light of recent research results [10])
- それが設定されるたびに30秒のタイマは小さい無作為の時間(+/-0〜5秒)までに相殺されます。 (作成者は最近の研究結果[10])の見地からさらに大きい変化を考えたがっているかもしれません。
There are two timers associated with each route, a "timeout" and a "garbage-collection" time. Upon expiration of the timeout, the route is no longer valid; however, it is retained in the routing table for a short time so that neighbors can be notified that the route has been dropped. Upon expiration of the garbage-collection timer, the route is finally removed from the routing table.
各ルート、「タイムアウト」、および「ガーベージコレクション」時間に関連している2個のタイマがあります。 タイムアウトの満了のときに、ルートはもう有効ではありません。 しかしながら、それは、ルートが下げられたことに隣人に通知できるように短い間経路指定テーブルで保有されます。 ガーベージコレクションタイマの満了のときに、ルートは経路指定テーブルから最終的に取り外されます。
The timeout is initialized when a route is established, and any time an update message is received for the route. If 180 seconds elapse from the last time the timeout was initialized, the route is considered to have expired, and the deletion process described below begins for that route.
ルートを確立するとき、タイムアウトを初期化します、そして、いつでも、アップデートメッセージをルートに受け取ります。 180秒がタイムアウトが初期化された最後の時から経過するなら、ルートが期限が切れたと考えられて、以下で説明された削除プロセスはそのルートに始まります。
Deletions can occur for one of two reasons: the timeout expires, or the metric is set to 16 because of an update received from the current router (see section 3.7.2 for a discussion of processing updates from other routers). In either case, the following events happen:
削除は2つの理由の1つで起こることができます: タイムアウトが期限が切れるか、またはメートル法は現在のルータから受けられたアップデートのために16に設定されます(処理アップデートの議論に関して他のルータからセクション3.7.2を見てください)。 どちらの場合ではも、以下のイベントは起こります:
Malkin Standards Track [Page 24] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[24ページ]RFC2453はバージョン1998年11月2日を裂きます。
- The garbage-collection timer is set for 120 seconds.
- ガーベージコレクションタイマは120秒間、設定されます。
- The metric for the route is set to 16 (infinity). This causes the
route to be removed from service.
- ルートへのメートル法は16(無限)に設定されます。 これで、サービスからルートを取り外します。
- The route change flag is set to indicate that this entry has been
changed.
- ルート変化旗が、このエントリーが変えられたのを示すように設定されます。
- The output process is signalled to trigger a response.
- 出力プロセスが応答の引き金となるように合図されます。
Until the garbage-collection timer expires, the route is included in all updates sent by this router. When the garbage-collection timer expires, the route is deleted from the routing table.
ガーベージコレクションタイマが期限が切れるまで、ルートはこのルータによって送られたすべてのアップデートに含まれています。 ガーベージコレクションタイマが期限が切れるとき、ルートは経路指定テーブルから削除されます。
Should a new route to this network be established while the garbage- collection timer is running, the new route will replace the one that is about to be deleted. In this case the garbage-collection timer must be cleared.
ゴミ収集タイマが動いている間、このネットワークへの新しいルートが確立されると、新しいルートは削除されようとしているものを取り替えるでしょう。 この場合、ガーベージコレクションタイマをきれいにしなければなりません。
Triggered updates also use a small timer; however, this is best described in section 3.9.1.
また、引き起こされたアップデートは三流の人を使用します。 セクション3.9.1でしかしながら、これについて説明するのは最も良いです。
3.9 Input Processing
3.9 入力処理
This section will describe the handling of datagrams received on the RIP port. Processing will depend upon the value in the command field.
このセクションはRIPポートの上に受け取られたデータグラムの取り扱いについて説明するでしょう。 処理はコマンド欄の値に依存するでしょう。
See sections 4.6 and 5.1 for details on handling version numbers.
取り扱いバージョン番号に関する詳細に関してセクション4.6と5.1を見てください。
3.9.1 Request Messages
3.9.1 要求メッセージ
A Request is used to ask for a response containing all or part of a router's routing table. Normally, Requests are sent as broadcasts (multicasts for RIP-2), from the RIP port, by routers which have just come up and are seeking to fill in their routing tables as quickly as possible. However, there may be situations (e.g., router monitoring) where the routing table of only a single router is needed. In this case, the Request should be sent directly to that router from a UDP port other than the RIP port. If such a Request is received, the router responds directly to the requestor's address and port.
Requestは、ルータの経路指定テーブルのすべてか一部を含む応答を求めるのに使用されます。 通常、放送(RIP-2のためのマルチキャスト)としてRequestsを送ります、RIPポートから、ちょうど来て、できるだけはやくそれらの経路指定テーブルに記入しようとしているルータで。 しかしながら、状況(例えば、ルータモニター)がただ一つのルータだけの経路指定テーブルが必要であるところにあるかもしれません。 この場合、RequestをRIPポート以外のUDPポートから直接そのルータに送るべきです。 そのようなRequestが受け取られているなら、ルータは直接要請者のアドレスとポートに応じます。
The Request is processed entry by entry. If there are no entries, no response is given. There is one special case. If there is exactly one entry in the request, and it has an address family identifier of zero and a metric of infinity (i.e., 16), then this is a request to send the entire routing table. In that case, a call is made to the output process to send the routing table to the requesting
エントリーによってRequestは処理エントリーです。 エントリーが全くなければ、応答を全く与えません。 1つの特別なケースがあります。 要求における、あるエントリーがまさにあって、ゼロとaに関するアドレスファミリー識別子を無限(すなわち、16)でメートル法にするなら、これは全体の経路指定テーブルを送るという要求です。 その場合、経路指定テーブルを要求に送るのを出力プロセスに電話をかけます。
Malkin Standards Track [Page 25] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[25ページ]RFC2453はバージョン1998年11月2日を裂きます。
address/port. Except for this special case, processing is quite simple. Examine the list of RTEs in the Request one by one. For each entry, look up the destination in the router's routing database and, if there is a route, put that route's metric in the metric field of the RTE. If there is no explicit route to the specified destination, put infinity in the metric field. Once all the entries have been filled in, change the command from Request to Response and send the datagram back to the requestor.
アドレス/ポート。 この特別なケースを除いて、処理はかなり簡単です。 RequestでRTEsのリストをひとつずつ調べてください。 各エントリーに、ルータのルーティングデータベースの目的地を見上げてください、そして、ルートがあれば、RTEのメートル法の分野にメートル法であることでルートのそのものを置いてください。 指定された目的地へのどんな明白なルートもなければ、メートル法の分野に無限を置いてください。 一度すべてのエントリーが、記入されて、コマンドをRequestからResponseに変えて、データグラムを要請者に送り返します。
Note that there is a difference in metric handling for specific and whole-table requests. If the request is for a complete routing table, normal output processing is done, including Split Horizon (see section 3.9 on Split Horizon). If the request is for specific entries, they are looked up in the routing table and the information is returned as is; no Split Horizon processing is done. The reason for this distinction is the expectation that these requests are likely to be used for different purposes. When a router first comes up, it multicasts a Request on every connected network asking for a complete routing table. It is assumed that these complete routing tables are to be used to update the requestor's routing table. For this reason, Split Horizon must be done. It is further assumed that a Request for specific networks is made only by diagnostic software, and is not used for routing. In this case, the requester would want to know the exact contents of the routing table and would not want any information hidden or modified.
特定の、そして、全体のテーブルの要求のためのメートル法の取り扱いの違いがあることに注意してください。 要求が完全な経路指定テーブルのためのものであるなら、基準出力処理をします、Split Horizonを含んでいて(Split Horizonの上のセクション3.9を見てください)。 特定のエントリーに要求があるなら、経路指定テーブルでそれらを調べます、そして、そのままで情報を返します。 処理が行われるSplit Horizonがありません。 この区別の理由は異なる役割に使用されて、おそらくこれらの要求がある期待です。 ルータであるときに、1番目は来て、それは完全な経路指定テーブルを求めるあらゆる接続ネットワークのマルチキャストa Requestです。 これらの完全な経路指定テーブルが要請者の経路指定テーブルをアップデートするのに使用されることになっていると思われます。 この理由で、Split Horizonをしなければなりません。 特定のネットワークのためのRequestが診断ソフトウェアだけによって作られて、ルーティングに使用されないとさらに思われます。 この場合、リクエスタは、経路指定テーブルの正確なコンテンツを知りたくて、どんな情報も隠されるか、または変更するのを必要がないでしょう。
3.9.2 Response Messages
3.9.2 応答メッセージ
A Response can be received for one of several different reasons:
いくつかの異なった理由の1つによってResponseを受け取ることができます:
- response to a specific query - regular update (unsolicited response) - triggered update caused by a route change
- 特定の質問への応答(定期的なアップデート(求められていない応答))はルート変化によって引き起こされたアップデートの引き金となりました。
Processing is the same no matter why the Response was generated.
Responseがなぜ生成されたとしても、処理は同じです。
Because processing of a Response may update the router's routing table, the Response must be checked carefully for validity. The Response must be ignored if it is not from the RIP port. The datagram's IPv4 source address should be checked to see whether the datagram is from a valid neighbor; the source of the datagram must be on a directly-connected network. It is also worth checking to see whether the response is from one of the router's own addresses. Interfaces on broadcast networks may receive copies of their own broadcasts/multicasts immediately. If a router processes its own output as new input, confusion is likely so such datagrams must be ignored.
Responseの処理がルータの経路指定テーブルをアップデートするかもしれないので、正当性がないかどうか丹念にResponseをチェックしなければなりません。 RIPポートから来ていないなら、Responseを無視しなければなりません。 データグラムのIPv4ソースアドレスはデータグラムが有効な隣人から来ているかを確認するためにチェックされるべきです。 データグラムの源が直接接続されたネットワークにあるに違いありません。 また、応答がルータの自己のアドレスの1つから来ているかを確認するためにチェックする価値があります。 放送網のインタフェースはすぐに、それら自身の放送/マルチキャストのコピーを受けるかもしれません。 ルータが新しい入力としてそれ自身の出力を処理するなら、混乱はしたがって、そのようなデータグラムを無視しなければならない傾向があります。
Malkin Standards Track [Page 26] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[26ページ]RFC2453はバージョン1998年11月2日を裂きます。
Once the datagram as a whole has been validated, process the RTEs in the Response one by one. Again, start by doing validation. Incorrect metrics and other format errors usually indicate misbehaving neighbors and should probably be brought to the administrator's attention. For example, if the metric is greater than infinity, ignore the entry but log the event. The basic validation tests are:
全体でデータグラムがいったん有効にされた後、ResponseでRTEsをひとつずつ処理してください。 もう一度、合法化することによって、始まってください。 不正確な測定基準と他の形式誤りは、通常、ふらちな事をしている隣人を示して、たぶんアドミニストレータのものに注目していただかれるべきです。 例えば、メートル法が無限より大きいなら、エントリーを無視しなさい、ただし、イベントを登録してください。 基本的な合法化テストは以下の通りです。
- is the destination address valid (e.g., unicast; not net 0 or 127) - is the metric valid (i.e., between 1 and 16, inclusive)
- 送付先アドレスは有効です(例えば、ユニキャスト; 0か127を網で覆いません)--、メートル法は有効です。(すなわち、1〜16、包括的である、)
If any check fails, ignore that entry and proceed to the next. Again, logging the error is probably a good idea.
何かチェックが失敗するなら、そのエントリーを無視してください、そして、次に続いてください。 一方、誤りを登録するのは、たぶん名案です。
Once the entry has been validated, update the metric by adding the cost of the network on which the message arrived. If the result is greater than infinity, use infinity. That is,
エントリーがいったん有効にされた後、メッセージが到着したネットワークの費用を加えることによって、メートル法をアップデートしてください。 結果が無限より大きいなら、無限を使用してください。 That is,
metric = MIN (metric + cost, infinity)
メートル法の=MIN(メートル法の+費用、無限)
Now, check to see whether there is already an explicit route for the destination address. If there is no such route, add this route to the routing table, unless the metric is infinity (there is no point in adding a route which is unusable). Adding a route to the routing table consists of:
今度は、チェックして、送付先アドレスに関して明白なルートが既にあるかどうか確認してください。 何かそのようなルートがなければ、このルートを経路指定テーブルに加えてください、メートル法が無限(使用不可能なルートを加える意味が全くない)でないなら。 経路指定テーブルにルートを加えるのは以下から成ります。
- Setting the destination address to the destination address in the
RTE
- RTEの送付先アドレスに送付先アドレスを設定します。
- Setting the metric to the newly calculated metric (as described
above)
- 新たにメートル法で計算されているのにメートル法を設定します。(上で説明されるように)
- Set the next hop address to be the address of the router from which
the datagram came
- 次のホップアドレスにデータグラムが来たルータのアドレスであるように設定してください。
- Initialize the timeout for the route. If the garbage-collection
timer is running for this route, stop it (see section 3.6 for a
discussion of the timers)
- タイムアウトをルートに初期化してください。 ガーベージコレクションタイマがこのルートに立候補しているなら、それを止めてください。(タイマの議論に関してセクション3.6を見ます)
- Set the route change flag
- ルート変化旗を設定してください。
- Signal the output process to trigger an update (see section 3.8.1)
- アップデートの引き金となるように出力プロセスに合図してください。(セクション3.8.1を見ます)
If there is an existing route, compare the next hop address to the address of the router from which the datagram came. If this datagram is from the same router as the existing route, reinitialize the timeout. Next, compare the metrics. If the datagram is from the same router as the existing route, and the new metric is different
既存のルートがあれば、データグラムが来たルータのアドレスに次のホップアドレスをたとえてください。 このデータグラムが既存のルートと同じルータから来ていて、タイムアウトを再初期化するなら。 次に、測定基準を比較してください。 データグラムが既存のルートと同じルータから来ていて、新しくメートル法が異なるなら
Malkin Standards Track [Page 27] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[27ページ]RFC2453はバージョン1998年11月2日を裂きます。
than the old one; or, if the new metric is lower than the old one; do the following actions:
古い方より。 または、新しさであるなら、メートル法であることは、古い方より下ろすことです。 以下の動作をしてください:
- Adopt the route from the datagram (i.e., put the new metric in and
adjust the next hop address, if necessary).
- データグラムからルートを採用してください(必要なら、すなわち、新しいメートル法のコネを置いてください、そして、次のホップアドレスを調整してください)。
- Set the route change flag and signal the output process to trigger
an update
- ルート変化旗を設定してください、そして、アップデートの引き金となるように出力プロセスに合図してください。
- If the new metric is infinity, start the deletion process
(described above); otherwise, re-initialize the timeout
- 新しくメートル法であるなら、無限、始めは削除プロセス(上で、説明される)です。 さもなければ、タイムアウトを再初期化してください。
If the new metric is infinity, the deletion process begins for the route, which is no longer used for routing packets. Note that the deletion process is started only when the metric is first set to infinity. If the metric was already infinity, then a new deletion process is not started.
新しさであるなら、メートル法であることは、無限、削除プロセスがルートに始まるということです、ルーティングパケットにもう使用されないどれ。 メートル法であるときにだけ、削除プロセスが始められるというメモは無限第一セットです。 メートル法が既に無限であったなら、新しい削除プロセスは始められません。
If the new metric is the same as the old one, it is simplest to do nothing further (beyond re-initializing the timeout, as specified above); but, there is a heuristic which could be applied. Normally, it is senseless to replace a route if the new route has the same metric as the existing route; this would cause the route to bounce back and forth, which would generate an intolerable number of triggered updates. However, if the existing route is showing signs of timing out, it may be better to switch to an equally-good alternative route immediately, rather than waiting for the timeout to happen. Therefore, if the new metric is the same as the old one, examine the timeout for the existing route. If it is at least halfway to the expiration point, switch to the new route. This heuristic is optional, but highly recommended.
新しくメートル法が古い方と同じであるなら、さらに(上で指定されるとしてタイムアウトを再初期化することを超えて)何もしないのは最も簡単です。 しかし、適用できたヒューリスティックがあります。 通常、同じくらいが新しいルートで既存のルートとしてメートル法になるなら、ルートを置き換えるのは無意味です。 これで、ルートは前後まで弾むでしょう(堪え難い数の引き起こされたアップデートを生成するでしょう)。 しかしながら、既存のルートがタイミングのサインを送り出しているなら、タイムアウトが起こるのを待っているよりすぐに、むしろ等しく良い代替のルートに切り替わるほうがよいかもしれません。 したがって、新しくメートル法が古い方と同じであるなら、既存のルートがないかどうかタイムアウトを調べてください。 それが満了ポイントに少なくとも途中なら、新しいルートに切り替わってください。 このヒューリスティックは、任意ですが、非常にお勧めです。
Any entry that fails these tests is ignored, as it is no better than the current route.
それが現在のルートより良いというわけではないので、これらのテストに失敗するどんなエントリーも無視されます。
3.10 Output Processing
3.10出力処理
This section describes the processing used to create response messages that contain all or part of the routing table. This processing may be triggered in any of the following ways:
このセクションは経路指定テーブルのすべてか一部を含む応答メッセージを作成するのに使用される処理について説明します。 この処理は以下の方法のどれかに引き起こされるかもしれません:
- By input processing, when a Request is received (this Response is
unicast to the requestor; see section 3.7.1)
- Requestが受け取られているときの入力処理で(このResponseは要請者へのユニキャストです; セクション3.7.1を見てください)
- By the regular routing update (broadcast/multicast every 30
seconds) router.
- 通常のルーティングで、ルータをアップデートしてください(30秒毎の放送/マルチキャスト)。
- By triggered updates (broadcast/multicast when a route changes)
- 引き起こされたアップデートで(ルートが変化するときの放送/マルチキャスト)
Malkin Standards Track [Page 28] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[28ページ]RFC2453はバージョン1998年11月2日を裂きます。
When a Response is to be sent to all neighbors (i.e., a regular or triggered update), a Response message is directed to the router at the far end of each connected point-to-point link, and is broadcast (multicast for RIP-2) on all connected networks which support broadcasting. Thus, one Response is prepared for each directly- connected network, and sent to the appropriate address (direct or broadcast/multicast). In most cases, this reaches all neighboring routers. However, there are some cases where this may not be good enough. This may involve a network that is not a broadcast network (e.g., the ARPANET), or a situation involving dumb routers. In such cases, it may be necessary to specify an actual list of neighboring routers and send a datagram to each one explicitly. It is left to the implementor to determine whether such a mechanism is needed, and to define how the list is specified.
Responseがすべての隣人(すなわち、通常の、または、引き起こされたアップデート)に送られることになっているとき、Responseメッセージは、それぞれの接続ポイントツーポイント接続の遠端でルータに向けられて、放送をサポートするすべての接続ネットワークで放送されます(RIP-2のためのマルチキャスト)。 したがって、1Responseをそれぞれの直接接続されたネットワークのために準備して、適切なアドレスに送ります(ダイレクトであるか放送/マルチキャスト)。 多くの場合、これはすべての隣接しているルータに達します。 しかしながら、いくつかのケースがこれが十分良くないかもしれないところにあります。 これは放送網(例えば、アルパネット)でなくて、またまたは馬鹿なルータにかかわる状況でもないネットワークにかかわるかもしれません。 そのような場合、隣接しているルータの実際のリストを指定して、明らかにデータグラムをそれぞれに送るのが必要であるかもしれません。 そのようなメカニズムが必要であるかどうか決定して、それがリストがどう指定されるかを定義するのが作成者に残されます。
3.10.1 Triggered Updates
3.10.1 引き起こされたアップデート
Triggered updates require special handling for two reasons. First, experience shows that triggered updates can cause excessive load on networks with limited capacity or networks with many routers on them. Therefore, the protocol requires that implementors include provisions to limit the frequency of triggered updates. After a triggered update is sent, a timer should be set for a random interval between 1 and 5 seconds. If other changes that would trigger updates occur before the timer expires, a single update is triggered when the timer expires. The timer is then reset to another random value between 1 and 5 seconds. A triggered update should be suppressed if a regular update is due by the time the triggered update would be sent.
引き起こされたアップデートは2つの理由で特別な取り扱いを必要とします。 まず最初に、経験は、それらの上に多くのルータがある状態で引き起こされたアップデートが収容数の限界かネットワークと共にネットワークで負担過重を引き起こす場合があるのを示します。 したがって、プロトコルは、作成者が引き起こされたアップデートの頻度を制限するために条項を入れるのを必要とします。 引き起こされたアップデートを送った後に、無作為の間隔の間、タイマを1〜5秒設定するべきです。 タイマが期限が切れるとき、タイマが期限が切れる前にアップデートの引き金となる他の変化が起こるなら、ただ一つのアップデートは引き起こされます。 そして、タイマは別の無作為の値に1〜5秒リセットされます。 定期的なアップデートが引き起こされたアップデートを送るだろうという時までに予定されているなら、引き起こされたアップデートは抑圧されるべきです。
Second, triggered updates do not need to include the entire routing table. In principle, only those routes which have changed need to be included. Therefore, messages generated as part of a triggered update must include at least those routes that have their route change flag set. They may include additional routes, at the discretion of the implementor; however, sending complete routing updates is strongly discouraged. When a triggered update is processed, messages should be generated for every directly-connected network. Split Horizon processing is done when generating triggered updates as well as normal updates (see section 3.9). If, after Split Horizon processing for a given network, a changed route will appear unchanged on that network (e.g., it appears with an infinite metric), the route need not be sent. If no routes need be sent on that network, the update may be omitted. Once all of the triggered updates have been generated, the route change flags should be cleared.
2番目に、引き起こされたアップデートは全体の経路指定テーブルを含む必要はありません。 変化したそれらのルートだけが、含まれる必要があります。 したがって、引き起こされたアップデートの一部が少なくともそれらのルート変化旗を持っているそれらのルートを含まなければならないので生成されたメッセージはセットしました。 彼らは作成者の裁量で追加ルートを含むかもしれません。 しかしながら、完全なルーティングアップデートを送るのは強くお勧めできないです。 引き起こされたアップデートが処理されるとき、メッセージはあらゆる直接接続されたネットワークのために生成されるべきです。 生成するのが通常のアップデートと同様にアップデートの引き金となったとき(セクション3.9を見てください)、分裂Horizon処理をします。 変えられたルートが与えられたネットワークのためのSplit Horizon処理の後にそのネットワークで変わりがなく見えるなら(無限がメートル法で例えばそれは現れます)、ルートを送る必要はありません。 そのネットワークでルートを全く送る必要はないなら、アップデートを省略するかもしれません。 引き起こされたアップデートのすべてがいったん生成されると、ルート変化旗はきれいにされるべきです。
Malkin Standards Track [Page 29] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[29ページ]RFC2453はバージョン1998年11月2日を裂きます。
If input processing is allowed while output is being generated, appropriate interlocking must be done. The route change flags should not be changed as a result of processing input while a triggered update message is being generated.
出力を生成している間、入力処理を許すなら、適切な連動をしなければなりません。 引き起こされたアップデートメッセージが生成されている間に入力された処理の結果、ルート変化旗を変えるべきではありません。
The only difference between a triggered update and other update messages is the possible omission of routes that have not changed. The remaining mechanisms, described in the next section, must be applied to all updates.
引き起こされたアップデートと他のアップデートメッセージの唯一の違いは変化していないルートの可能な省略です。 次のセクションで説明された残っているメカニズムをすべてのアップデートに適用しなければなりません。
3.10.2 Generating Response Messages
3.10.2 応答メッセージを生成すること。
This section describes how a Response message is generated for a particular directly-connected network:
このセクションはResponseメッセージが特定の直接接続されたネットワークのためにどう生成されるかを説明します:
Set the version number to either 1 or 2. The mechanism for deciding which version to send is implementation specific; however, if this is the Response to a Request, the Response version should match the Request version. Set the command to Response. Set the bytes labeled "must be zero" to zero. Start filling in RTEs. Recall that there is a limit of 25 RTEs to a Response; if there are more, send the current Response and start a new one. There is no defined limit to the number of datagrams which make up a Response.
1か2にバージョン番号を設定してください。 どのバージョンを送ったらよいかを決めるためのメカニズムは実装特有です。 しかしながら、これがRequestへのResponseであるなら、ResponseバージョンはRequestバージョンに合うべきです。 Responseにコマンドを設定してください。 バイトがラベルしたセットはゼロへの「ゼロでなければなりません」。 RTEsに記入し始めてください。 25RTEsのResponseへの限界があったと思い出してください。 以上があれば、現在のResponseを送ってください、そして、新しいものを始めてください。 Responseを作るデータグラムの数への定義された限界が全くありません。
To fill in the RTEs, examine each route in the routing table. If a triggered update is being generated, only entries whose route change flags are set need be included. If, after Split Horizon processing, the route should not be included, skip it. If the route is to be included, then the destination address and metric are put into the RTE. Routes must be included in the datagram even if their metrics are infinite.
RTEsに記入するには、経路指定テーブルの各ルートを調べてください。 引き起こされたアップデートが生成されているなら、ルート変化旗が設定されるエントリーだけが含まれなければなりません。 Split Horizon処理の後にルートを含んでいないなら、それをスキップしてください。 ルートが含むことであるなら、送付先アドレスとメートル法をRTEに入れます。 それらの測定基準が無限であっても、データグラムにルートを含まなければなりません。
Malkin Standards Track [Page 30] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[30ページ]RFC2453はバージョン1998年11月2日を裂きます。
4. Protocol Extensions
4. プロトコル拡大
This section does not change the RIP protocol per se. Rather, it provides extensions to the message format which allows routers to share important additional information.
このセクションはそういうものとしてRIPプロトコルを変えません。 むしろ、それはルータが重要な追加情報を共有できるメッセージ・フォーマットに拡大を提供します。
The same header format is used for RIP-1 and RIP-2 messages (see section 3.4). The format for the 20-octet route entry (RTE) for RIP-2 is:
同じヘッダー形式はRIP-1とRIP-2メッセージに使用されます(セクション3.4を見てください)。 RIP-2のための20八重奏のルートエントリー(RTE)への形式は以下の通りです。
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Identifier (2) | Route Tag (2) |
+-------------------------------+-------------------------------+
| IP Address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
+---------------------------------------------------------------+
| Next Hop (4) |
+---------------------------------------------------------------+
| Metric (4) |
+---------------------------------------------------------------+
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレスファミリー識別子(2)| ルートタグ(2)| +-------------------------------+-------------------------------+ | IPアドレス(4)| +---------------------------------------------------------------+ | サブネットマスク(4)| +---------------------------------------------------------------+ | 次のホップ(4)| +---------------------------------------------------------------+ | メートル法の(4)| +---------------------------------------------------------------+
The Address Family Identifier, IP Address, and Metric all have the meanings defined in section 3.4. The Version field will specify version number 2 for RIP messages which use authentication or carry information in any of the newly defined fields.
Address Family Identifier、IP Address、およびMetricには、セクション3.4で定義された意味がすべてあります。 バージョン分野は新たに定義された分野のいずれでも認証を使用するか、または情報を運ぶRIPメッセージのバージョンNo.2を指定するでしょう。
4.1 Authentication
4.1 認証
Since authentication is a per message function, and since there is only one 2-octet field available in the message header, and since any reasonable authentication scheme will require more than two octets, the authentication scheme for RIP version 2 will use the space of an entire RIP entry. If the Address Family Identifier of the first (and only the first) entry in the message is 0xFFFF, then the remainder of the entry contains the authentication. This means that there can be, at most, 24 RIP entries in the remainder of the message. If authentication is not in use, then no entries in the message should have an Address Family Identifier of 0xFFFF. A RIP message which contains an authentication entry would begin with the following format:
メッセージ機能あたり認証がaであり、メッセージヘッダーで利用可能なある2八重奏の分野しかなくて、どんな妥当な認証体系も2つ以上の八重奏を必要とするので、RIPバージョン2の認証体系は全体のRIPエントリーのスペースを使用するでしょう。 メッセージにおける最初(そして、1番目だけ)のエントリーのAddress Family Identifierが0xFFFFであるなら、エントリーの残りは認証を含んでいます。 これは、メッセージの残りには24のRIPエントリーが大部分にあることができることを意味します。 認証が使用中でないなら、メッセージにおけるどんなエントリーにも、0xFFFFのAddress Family Identifierがあるべきではありません。 認証エントリーを含むRIPメッセージは以下の形式で始まるでしょう:
Malkin Standards Track [Page 31] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[31ページ]RFC2453はバージョン1998年11月2日を裂きます。
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) | Version (1) | unused |
+---------------+---------------+-------------------------------+
| 0xFFFF | Authentication Type (2) |
+-------------------------------+-------------------------------+
~ Authentication (16) ~
+---------------------------------------------------------------+
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コマンド(1)| バージョン(1)| 未使用| +---------------+---------------+-------------------------------+ | 0xFFFF| 認証タイプ(2)| +-------------------------------+-------------------------------+ ~認証(16)~+---------------------------------------------------------------+
Currently, the only Authentication Type is simple password and it is type 2. The remaining 16 octets contain the plain text password. If the password is under 16 octets, it must be left-justified and padded to the right with nulls (0x00).
現在、唯一のAuthentication Typeが簡単なパスワードです、そして、それはタイプ2です。 残っている16の八重奏がプレーンテキストパスワードを含んでいます。 パスワードが16未満の八重奏であるなら、それを左で正当であり、ヌル(0×00)で右に水増ししなければなりません。
4.2 Route Tag
4.2 ルートタグ
The Route Tag (RT) field is an attribute assigned to a route which must be preserved and readvertised with a route. The intended use of the Route Tag is to provide a method of separating "internal" RIP routes (routes for networks within the RIP routing domain) from "external" RIP routes, which may have been imported from an EGP or another IGP.
Route Tag(RT)分野は保持しなければならないルートに割り当てられて、ルートで「再-広告を出」す属性です。 Route Tagの意図している使用はEGPか別のIGPからインポートされたかもしれない「外部」のRIPルートと「内部」のRIPルート(RIP経路ドメインの中のネットワークのためのルート)を切り離すメソッドを提供することです。
Routers supporting protocols other than RIP should be configurable to allow the Route Tag to be configured for routes imported from different sources. For example, routes imported from EGP or BGP should be able to have their Route Tag either set to an arbitrary value, or at least to the number of the Autonomous System from which the routes were learned.
Route Tagがさまざまな原因からインポートされたルートに構成されるのを許容するのにおいてRIP以外のプロトコルをサポートするルータは構成可能であるべきです。 例えば、EGPかBGPからインポートされたルートは任意の値に設定されるか、少なくともルートが学習されたAutonomous Systemの数のどちらかにそれらのRoute Tagを持っているはずであることができます。
Other uses of the Route Tag are valid, as long as all routers in the RIP domain use it consistently. This allows for the possibility of a BGP-RIP protocol interactions document, which would describe methods for synchronizing routing in a transit network.
RIPドメインのすべてのルータが一貫してそれを使用する限り、Route Tagの他の用途は有効です。 これはBGP-RIPプロトコル相互作用ドキュメントの可能性を考慮します。(ドキュメントはトランジットネットワークでルーティングを同期させるためのメソッドを説明するでしょう)。
4.3 Subnet mask
4.3 サブネットマスク
The Subnet Mask field contains the subnet mask which is applied to the IP address to yield the non-host portion of the address. If this field is zero, then no subnet mask has been included for this entry.
Subnet Mask分野はアドレスの非ホスト部分をもたらすためにIPアドレスに適用されるサブネットマスクを含んでいます。 この分野がゼロであるなら、サブネットマスクは全くこのエントリーに含められていません。
On an interface where a RIP-1 router may hear and operate on the information in a RIP-2 routing entry the following rules apply:
RIP-1ルータがRIP-2ルーティングエントリーにおける情報を聞いて、作動させるかもしれないインタフェースに、以下の規則は適用されます:
1) information internal to one network must never be advertised into
another network,
1) 決して1つのネットワークへの内部の情報の別のネットワークに広告を出してはいけません。
Malkin Standards Track [Page 32] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[32ページ]RFC2453はバージョン1998年11月2日を裂きます。
2) information about a more specific subnet may not be advertised
where RIP-1 routers would consider it a host route, and
そして2) より特定のサブネットの情報がRIP-1ルータがそれがホストルートであると考えるところに広告を出さないかもしれない。
3) supernet routes (routes with a netmask less specific than the
"natural" network mask) must not be advertised where they could be
misinterpreted by RIP-1 routers.
3) RIP-1ルータでそれらを誤解できたところにsupernetルート(ネットマスクが「自然な」ネットワークマスクほど特定でないことのルート)の広告を出してはいけません。
4.4 Next Hop
4.4 次のホップ
The immediate next hop IP address to which packets to the destination specified by this route entry should be forwarded. Specifying a value of 0.0.0.0 in this field indicates that routing should be via the originator of the RIP advertisement. An address specified as a next hop must, per force, be directly reachable on the logical subnet over which the advertisement is made.
目的地へのパケットがこのルートエントリーで指定した次の即座のホップIPアドレスを転送するべきです。 ルーティングはこの分野の.0が示す.0であるべきですが、RIP広告の創始者を通して0.0の値を指定します。 次のホップが広告がされる論理的なサブネットで力単位で直接届かなければならないので、アドレスは指定しました。
The purpose of the Next Hop field is to eliminate packets being routed through extra hops in the system. It is particularly useful when RIP is not being run on all of the routers on a network. A simple example is given in Appendix A. Note that Next Hop is an "advisory" field. That is, if the provided information is ignored, a possibly sub-optimal, but absolutely valid, route may be taken. If the received Next Hop is not directly reachable, it should be treated as 0.0.0.0.
Next Hop分野の目的はシステムの付加的なホップを通して発送されるパケットを排除することです。 RIPがネットワークのルータのすべてにおける走行でないときに、それは特に役に立ちます。 簡単な例はNext Hopが「顧問」の分野であるならそうです。 すなわち、提供された情報を無視するなら、ことによるとサブ最適の、しかし、絶対に有効なルートを取るかもしれません。 届いて、それは容認されたNext Hopが直接そうでないなら0.0として扱われるべきです。.0 .0。
4.5 Multicasting
4.5 マルチキャスティング
In order to reduce unnecessary load on those hosts which are not listening to RIP-2 messages, an IP multicast address will be used for periodic broadcasts. The IP multicast address is 224.0.0.9. Note that IGMP is not needed since these are inter-router messages which are not forwarded.
RIP-2メッセージの聴取ではなく、そうするそれらのホストで不要な負荷を減少させて、IPマルチキャストアドレスは周期的な放送に使用されるでしょう。 IPマルチキャストアドレスはそうです。224.0 .0 .9。 IGMPはこれらが転送されない相互ルータメッセージであるので必要でないことに注意してください。
On NBMA networks, unicast addressing may be used. However, if a response addressed to the RIP-2 multicast address is received, it should be accepted.
NBMAネットワークでは、ユニキャストアドレシングは使用されるかもしれません。 しかしながら、RIP-2マルチキャストアドレスに扱われた応答が受け取られているなら、それを受け入れるべきです。
In order to maintain backwards compatibility, the use of the multicast address will be configurable, as described in section 5.1. If multicasting is used, it should be used on all interfaces which support it.
後方に互換性を維持するために、マルチキャストアドレスの使用はセクション5.1で説明されるように構成可能になるでしょう。 マルチキャスティングが使用されているなら、それはそれをサポートするすべてのインタフェースで使用されるべきです。
4.6 Queries
4.6 質問
If a RIP-2 router receives a RIP-1 Request, it should respond with a RIP-1 Response. If the router is configured to send only RIP-2 messages, it should not respond to a RIP-1 Request.
RIP-2ルータがRIP-1 Requestを受けるなら、それはRIP-1 Responseと共に応じるべきです。 ルータがRIP-2メッセージだけを送るために構成されるなら、それはRIP-1 Requestに応じるべきではありません。
Malkin Standards Track [Page 33] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[33ページ]RFC2453はバージョン1998年11月2日を裂きます。
5. Compatibility
5. 互換性
RFC [1] showed considerable forethought in its specification of the handling of version numbers. It specifies that RIP messages of version 0 are to be discarded, that RIP messages of version 1 are to be discarded if any Must Be Zero (MBZ) field is non-zero, and that RIP messages of any version greater than 1 should not be discarded simply because an MBZ field contains a value other than zero. This means that the new version of RIP is totally backwards compatible with existing RIP implementations which adhere to this part of the specification.
RFC[1]はバージョン番号の取り扱いの仕様にかなりの先見を示しました。 バージョン0に関するRIPメッセージが捨てることであり、バージョン1に関するRIPメッセージが何かMust Be Zero(MBZ)分野も非ゼロであるなら捨てることであり、単にMBZ分野がゼロ以外の値を含んでいるので1よりすばらしいどんなバージョンに関するRIPメッセージも捨てるべきでないのが指定します。 これは、RIPの新しいバージョンが完全に後方に仕様のこの部分を固く守る既存のRIP実装と互換性があった状態であることを意味します。
5.1 Compatibility Switch
5.1 互換性スイッチ
A compatibility switch is necessary for two reasons. First, there are implementations of RIP-1 in the field which do not follow RFC [1] as described above. Second, the use of multicasting would prevent RIP-1 systems from receiving RIP-2 updates (which may be a desired feature in some cases). This switch should be configurable on a per-interface basis.
互換性スイッチが2つの理由に必要です。 まず最初に、その分野の[1] 上で説明されるようにRFCに続かないRIP-1の実装があります。 2番目に、マルチキャスティングの使用は、RIP-1システムがRIP-2アップデート(いくつかの場合、必要な特徴であるかもしれない)を受けるのを防ぐでしょう。 このスイッチは1インタフェースあたり1個のベースで構成可能であるべきです。
The switch has four settings: RIP-1, in which only RIP-1 messages are sent; RIP-1 compatibility, in which RIP-2 messages are broadcast; RIP-2, in which RIP-2 messages are multicast; and "none", which disables the sending of RIP messages. It is recommended that the default setting be either RIP-1 or RIP-2, but not RIP-1 compatibility. This is because of the potential problems which can occur on some topologies. RIP-1 compatibility should only be used when all of the consequences of its use are well understood by the network administrator.
スイッチには、4つの設定があります: RIP-1であって、唯一のRIP-1メッセージがどれであるかで送られる。 RIP-1の互換性(RIP-2メッセージはそれで放送されます)。 RIP-2、どのRIP-2メッセージで、マルチキャストはそうであるか。 そして、RIPメッセージの発信を無効にする「なにも。」 既定の設定がRIP-1の互換性ではなく、RIP-1かRIP-2のどちらかであることがお勧めです。 いくらかのtopologiesに起こることができる潜在的な問題のためにこれはそうです。 使用の結果のすべてがネットワーク管理者によく解釈されるときだけ、RIP-1の互換性は使用されるべきです。
For completeness, routers should also implement a receive control switch which would determine whether to accept, RIP-1 only, RIP-2 only, both, or none. It should also be configurable on a per- interface basis. It is recommended that the default be compatible with the default chosen for sending updates.
完全性のために、ルータは制御するべきです、また、aが受ける道具が受け入れるかどうか決定するスイッチ、RIP-1だけ、単にと、RIP-2の両方、またはなにも制御しません。 また、それもaで構成可能であるべきである、-、インタフェース基礎。 デフォルトは送付アップデートに選ばれているデフォルトと互換性があるのが、お勧めです。
5.2 Authentication
5.2 認証
The following algorithm should be used to authenticate a RIP message. If the router is not configured to authenticate RIP-2 messages, then RIP-1 and unauthenticated RIP-2 messages will be accepted; authenticated RIP-2 messages shall be discarded. If the router is configured to authenticate RIP-2 messages, then RIP-1 messages and RIP-2 messages which pass authentication testing shall be accepted; unauthenticated and failed authentication RIP-2 messages shall be discarded. For maximum security, RIP-1 messages should be ignored
以下のアルゴリズムは、RIPメッセージを認証するのに使用されるべきです。 RIP-2メッセージを認証するためにルータを構成しないと、RIP-1とunauthenticated RIP-2メッセージを受け入れるでしょう。 認証されたRIP-2メッセージは捨てられるものとします。 RIP-2メッセージを認証するためにルータを構成するなら、認証テストに合格するRIP-1メッセージとRIP-2メッセージを受け入れるものとします。 非認証されて失敗した認証RIP-2メッセージは捨てられるものとします。 最大のセキュリティのために、RIP-1メッセージは無視されるべきです。
Malkin Standards Track [Page 34] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[34ページ]RFC2453はバージョン1998年11月2日を裂きます。
when authentication is in use (see section 4.1); otherwise, the routing information from authenticated messages will be propagated by RIP-1 routers in an unauthenticated manner.
認証が使用中であるときに(セクション4.1を見てください)。 さもなければ、認証されたメッセージからのルーティング情報はRIP-1ルータによって非認証された方法で伝播されるでしょう。
Since an authentication entry is marked with an Address Family Identifier of 0xFFFF, a RIP-1 system would ignore this entry since it would belong to an address family other than IP. It should be noted, therefore, that use of authentication will not prevent RIP-1 systems from seeing RIP-2 messages. If desired, this may be done using multicasting, as described in sections 4.5 and 5.1.
それはIP以外のアドレスファミリーのものでしょう、したがって、認証エントリーが0xFFFFのAddress Family Identifierと共に示されるとき、RIP-1システムがこのエントリーを無視するでしょう。 したがって、認証の使用が、RIP-1システムがRIP-2メッセージを見るのを防がないことに注意されるべきです。 望まれているなら、これはセクション4.5と5.1で説明されるようにマルチキャスティングを使用し終わるかもしれません。
5.3 Larger Infinity
5.3 より大きい無限
While on the subject of compatibility, there is one item which people have requested: increasing infinity. The primary reason that this cannot be done is that it would violate backwards compatibility. A larger infinity would obviously confuse older versions of rip. At best, they would ignore the route as they would ignore a metric of 16. There was also a proposal to make the Metric a single octet and reuse the high three octets, but this would break any implementations which treat the metric as a 4-octet entity.
人々が要求した1つの項目が互換性の問題を扱っていますが: 無限を増強します。 これができないプライマリ理由は後方に互換性に違反するだろうということです。 より大きい無限は裂け目の旧式のバージョンを明らかに混乱させるでしょう。 せいぜい、彼らは16におけるメートル法のaを無視するようにルートを無視するでしょう。 また、Metricをただ一つの八重奏にして、高い3つの八重奏を再利用するという提案がありましたが、これは4八重奏の実体としてメートル法を扱うどんな実装も壊すでしょう。
5.4 Addressless Links
5.4 Addresslessリンク
As in RIP-1, addressless links will not be supported by RIP-2.
RIP-1のように、addresslessリンクはRIP-2によって支えられないでしょう。
6. Interaction between version 1 and version 2
6. バージョン1とバージョン2との相互作用
Because version 1 packets do not contain subnet information, the semantics employed by routers on networks that contain both version 1 and version 2 networks should be limited to that of version 1. Otherwise it is possible either to create blackhole routes (i.e., routes for networks that do not exist) or to create excessive routing information in a version 1 environment.
バージョン1パケットがサブネット情報を含んでいないので、バージョン1とバージョン2ネットワークの両方を含むネットワークでルータによって使われた意味論はバージョン1のものに制限されるべきです。 さもなければ、blackholeルート(すなわち、存在しないネットワークのためのルート)を作成するか、またはバージョン1環境における過度のルーティング情報を作成するのが可能です。
Some implementations attempt to automatically summarize groups of adjacent routes into single entries, the goal being to reduce the total number of entries. This is called auto-summarization.
自動的に隣接しているルートのグループを単一のエントリーへまとめる何らかの実装試み、目標はエントリーの総数を減少させることです。 これは自動総括であると呼ばれます。
Specifically, when using both version 1 and version 2 within a network, a single subnet mask should be used throughout the network. In addition, auto-summarization mechanisms should be disabled for such networks, and implementations must provide mechanisms to disable auto-summarization.
ネットワークの中でバージョン1とバージョン2の両方を使用するとき、明確に、単一のサブネットマスクはネットワーク中で使用されるべきです。 さらに、自動総括メカニズムはそのようなネットワークのために無効にされるべきです、そして、実装は自動総括を無効にするためにメカニズムを提供しなければなりません。
Malkin Standards Track [Page 35] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[35ページ]RFC2453はバージョン1998年11月2日を裂きます。
7. Security Considerations
7. セキュリティ問題
The basic RIP protocol is not a secure protocol. To bring RIP-2 in line with more modern routing protocols, an extensible authentication mechanism has been incorporated into the protocol enhancements. This mechanism is described in sections 4.1 and 5.2. Security is further enhanced by the mechanism described in [3].
基本的なRIPプロトコルは安全なプロトコルではありません。 より現代のルーティング・プロトコルに沿ってRIP-2を持って来るために、広げることができる認証機構はプロトコル増進に組み入れられました。 このメカニズムはセクション4.1と5.2で説明されます。 セキュリティは[3]で説明されたメカニズムによってさらに高められます。
Malkin Standards Track [Page 36] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[36ページ]RFC2453はバージョン1998年11月2日を裂きます。
Appendix A
付録A
This is a simple example of the use of the next hop field in a rip entry.
これは裂け目のエントリーにおける次のホップ分野の使用の簡単な例です。
----- ----- ----- ----- ----- -----
|IR1| |IR2| |IR3| |XR1| |XR2| |XR3|
--+-- --+-- --+-- --+-- --+-- --+--
| | | | | |
--+-------+-------+---------------+-------+-------+--
<-------------RIP-2------------->
----- ----- ----- ----- ----- ----- |IR1| |IR2| |IR3| |XR1| |XR2| |XR3| --+-- --+-- --+-- --+-- --+-- --+-- | | | | | | --+-------+-------+---------------+-------+-------+--<。-------------裂け目-2------------->。
Assume that IR1, IR2, and IR3 are all "internal" routers which are under one administration (e.g. a campus) which has elected to use RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under separate administration (e.g. a regional network, of which the campus is a member) and are using some other routing protocol (e.g. OSPF). XR1, XR2, and XR3 exchange routing information among themselves such that they know that the best routes to networks N1 and N2 are via XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for routing to occur without additional hops through XR1. Without the Next Hop (for example, if RIP-1 were used) it would be necessary for XR2 and XR3 to also participate in the RIP-2 protocol to eliminate extra hops.
IR1、IR2、およびIR3がすべて「内部」のルータであると仮定してください(IGPとしてRIP-2を使用するのを選んだ1つ未満の管理(例えば、キャンパス)です)。 他方では、XR1、XR2、およびXR3は別々の管理(例えば、キャンパスがメンバーである地域ネットワーク)の下にあって、ある他のルーティング・プロトコルを使用しています(例えば、OSPF)。 XR1、XR2、およびXR3は彼らが、XR1を通してネットワークのN1とN2への最も良いルートがあるのを知るように、自分たちの中でルーティング情報を交換します、N3に、N4、そして、N5はXR2を通してあって、XR3を通してN6とN7にはあります。 正しさ(N3/N4/N5のためのXR2、N6/N7のためのXR3に)にNext Hop分野を設定することによって、XR1だけがルーティングがXR1を通して追加ホップなしで起こるようにIR1/IR2/IR3と共に交換RIP-2ルートを必要とします。 Next Hop(RIP-1が例えば使用されたなら)がなければ、また、XR2とXR3が付加的なホップを排除するためにRIP-2プロトコルに参加するのが必要でしょう。
References
参照
[1] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058,
Rutgers University, June 1988.
[1] ヘドリック、C.、「ルーティング情報プロトコル」、STD34、RFC1058、ラトガース大学、1988年6月。
[2] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC
1389, January 1993.
[2] マルキン、G.とF.ベイカー、「裂け目のバージョン2MIB拡張子」、RFC1389、1993年1月。
[3] Baker, F., and R. Atkinson, "RIP-II MD5 Authentication", RFC
2082, January 1997.
[3] ベイカー、F.、およびR.アトキンソン、「裂け目II MD5認証」、RFC2082、1997年1月。
[4] Bellman, R. E., "Dynamic Programming", Princeton University
Press, Princeton, N.J., 1957.
[4]触れ役、R.E.、「動的計画法」、プリンストン大学出版局、プリンストン、ニュージャージー州1957。
[5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks",
Prentice-Hall, Englewood Cliffs, N.J., 1987.
[5] Bertsekas、D.P.とガラハー、R.G.、「データ網」、新米のホールイングルウッドがけ、ニュージャージー州、1987
[6] Braden, R., and Postel, J., "Requirements for Internet Gateways",
STD 4, RFC 1009, June 1987.
[6] ブレーデン、R.とポステル、J.、「インターネットゲートウェイのための要件」STD4、1987年6月のRFC1009。
Malkin Standards Track [Page 37] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[37ページ]RFC2453はバージョン1998年11月2日を裂きます。
[7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M.,
"Pup: An Internetwork Architecture", IEEE Transactions on
Communications, April 1980.
[7] ボッグズとD.R.とShochとJ.F.とタフト、E.A.とメトカルフェ、R.M.、「産んでください」 「インターネットワークアーキテクチャ」、コミュニケーションに関するIEEEトランザクション、1980年4月。
[8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
Princeton University Press, Princeton, N.J., 1962.
[8] フォード、L.R.Jr.とフルカーソン、D.R.、「ネットワークの流れ」プリンストン大学出版局、プリンストン、ニュージャージー州1962。
[9] Xerox Corp., "Internet Transport Protocols", Xerox System
Integration Standard XSIS 028112, December 1981.
[9]ゼロックス社、「インターネットトランスポート・プロトコル」、ゼロックスのシステムインテグレーションの標準のXSIS028112、1981年12月。
[10] Floyd, S., and V. Jacobson, "The synchronization of Periodic
Routing Messages," ACM Sigcom '93 symposium, September 1993.
1993年9月の[10] フロイド、S.とV.ジェーコブソン、「Periodicルート設定Messagesの同期」ACM Sigcom93年のシンポジウム。
[11] Baker, F., "Requirements for IP Version 4 Routers." RFC 1812,
June 1995.
[11] ベイカー、F.、「IPバージョン4ルータのための要件。」 1995年6月のRFC1812。
Author's Address
作者のアドレス
Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 01821
ビルリカ、ゲーリースコットマルキンベイネットワークス8の連邦政府の通りMA 01821
Phone: (978) 916-4237 EMail: gmalkin@baynetworks.com
以下に電話をしてください。 (978) 916-4237 メールしてください: gmalkin@baynetworks.com
Malkin Standards Track [Page 38] RFC 2453 RIP Version 2 November 1998
マルキン標準化過程[38ページ]RFC2453はバージョン1998年11月2日を裂きます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Malkin Standards Track [Page 39]
マルキン標準化過程[39ページ]
一覧
スポンサーリンク
