原文：ftp://ftp.rfc-editor.org/in-notes/rfc2453.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
この RFC、文中の参照先がところどころ変です。参照先セクションが存在しないのは明らかに間違いでしょうが、それ以外でも「これは違うだろ」っていうところは翻訳では修正し、訳注を入れています。
ソーシャルブックマーク：
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. この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況については "Internet Official Protocol Standards" (STD 1)を参照してほしい。この文書の配布に制限はない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
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. この文書は、[1] で定義されている Routing Information Protocol (RIP)の拡張版を規定し、RIP メッセージで運ばれる有用な情報の量を拡張し、セキュリティ対策を追加する。
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]. 対になる文書 [2] は RIP-2 のための SNMP MIB オブジェクトを定義する。追加文書 [3] は RIP-2 のための暗号セキュリティを定義する。
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 Working Group の助力に感謝したい。距離ベクトルプロトコルに関する議論のバックグラウンドの文書の大部分、および RIP の運用の説明の一部は、C. Hedrick による "Routing Information Protocol" [1] から取られている。この文書の最終版の一部は Scott Bradner によるものである。
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 と IS-IS の出現にともない、RIP は時代遅れになったと信じる人々がいる。新しい IGP ルーティングプロトコルが RIP よりはるかに優れているのは確かだが、RIP にも利点はある。第一に、小規模ネットワークにおいて、RIP は使用される帯域や構成・管理に要する時間に関するオーバーヘッドが非常に小さい。また RIP は、特に新しい IGP に比べて実装が非常に簡単である。
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. 加えて、OSPF と IS-IS とを合わせた数よりも、はるかに多くの RIP の実装が現役である。このような状況はまだ数年は続きそうである。
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 の利便性を向上させることは理にかなっている。変更のコストに比べ利益の方がはるかに大きいのなら、これは特に正しい。
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 は、自律システムや IGP/EGP による対話、サブネット化[11]、認証を考慮していない(これらが RIP-1 より後に実現されたためである)。ルータは経路を決定する方法を知るためにサブネットマスクを必要とするため、サブネットマスクの欠如は特に深刻な問題である。RIP-1 の経路がネットワーク経路(非ネットワークビットがすべてゼロ)の場合、サブネットマスクはネットワークマスクに等しい。しかしながら、非ネットワークビットの一部がセットされている場合、ルータはサブネットを判断できない。さらになお悪いことに、ルータは RIP-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 はベルマンフォード(または距離ベクトル)アルゴリズムに基づくルーティングプロトコルである。初期の ARPANET 以来、コンピュータネットワークにおけるルーティング計算にはこのアルゴリズムが使用されてきた。ここで説明される特定のパケットフォーマットとプロトコルとは、Unix の Berkeley ディストリビューションに含まれるプログラム、"routed" に基づいている。
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 によって異なる可能性がある。AS 内部で使用されるルーティングプロトコルは、Interior Gateway Protocol (IGP) と呼ばれる。別のプロトコルである Exterior Gateway Protocol (EGP) は、AS 間でルーティング情報を転送するために使用される。RIP は中規模の AS 内の IGP としてうまく動作するように設計されている。それより複雑な環境において使用されることは意図していない。RIP-1 が適合すると期待される状況についての情報は、Braden と Postel とによる [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)アルゴリズムとして知られるルーティングアルゴリズムのひとつを使用する。この種類のアルゴリズムの最初の解説書は、著者の知る限り Ford と Fulkerson とによる [8] である。そのためこれは時に、Ford-Fulkerson アルゴリズムとして知られている。Bellman-Ford という用語も使用され、これは公式が Bellman 方程式 [4] に基づくという事実に由来する。この文書における体裁は、[5] に密接に基づいている。この文書にはプロトコル仕様が含まれる。ルーティングアルゴリズムの数学の紹介については、[1] を参照してほしい。このプロトコルが使用する基本アルゴリズムは、早くも 1969 年には ARPANET においてコンピュータルーティングに使用されていた。しかしながら、このプロトコルの具体的な起源は、Xerox ネットワークプロトコルの中にある。PUP プロトコル [7] は、ルーティング情報の交換に Gateway Information Protocol を使用していた。このプロトコルの多少更新されたバージョンは、Routing Information Protocol [9] という名前で Xerox Network Systems (XNS) に採用された。Berkeley の routed はその Routing Information Protocol とほぼ同じで、XNS アドレスが IPv4 などのアドレスを処理する能力のあるより一般的なアドレスフォーマットに置き換えられ、ルーティング更新が 30 秒ごとに制限されている。この類似性のために、Routing Information Protocol (または単に RIP)という用語は、XNS プロトコルと routed の使用するプロトコルとの両方を表すために使用される。
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 データグラムを渡される。ルーティングは、ホストまたはルータがそのデータグラムの送信先を決定するのに使用する手段である。宛先がそのホストまたはルータに直接接続しているネットワーク上にある場合、データグラムを宛先に直接送信できるかもしれない。しかしながら注目すべきは、宛先に直接到達できない場合である。
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. その場合ホストまたはルータは、そのデータグラムを宛先により近いルータへと送信しようと試みる。ルーティングプロトコルの目的は非常に単純である：ルーティングを行うために必要となる情報を提供することである。
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 main body of this document is organized into two parts, which occupy the next two sections: この文書の本文は二つの部分にまとめられており、それらは以下の二つのセクションを占める：
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. これら二つのセクションはそれぞれ大部分が独立している。セクション 3.4 は、このアルゴリズムの数学的基盤の非公式なプレゼンテーションを与えようと試みている。このプレゼンテーションは "スパイラル(spiral)" 法に従う。初期の極めて単純なアルゴリズムが説明されている。次に後続のセクションにその改良版が追加されている。セクション 3.5 は実際のプロトコルの説明である。明確にセクション 3.4 を参照している部分を除き、セクション 3.5 で与えられる仕様から完全な RIP を実装することが可能なはずである。
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 の "インターネットモデル(Internet model)" において主に、送信元と宛先とのネットワーク間の一連のルータを探す問題を軽減する。メッセージまたはデータグラムが単一のネットワークまたはサブネットに留まる限り、あらゆる転送問題はそのネットワークに固有の技術の責務である。例えばイーサネットと ARPANET はそれぞれ、その単一ネットワーク内ですべての送信元が任意の特定の宛先と対話できるための方法を定義している。IP ルーティングは主に、メッセージがあるネットワーク上の送信元から別のネットワーク上の宛先に向かわなければならない場合に現れる。その場合メッセージは、それらのネットワークに接続するひとつまたは複数のルータを通して渡されなければならない。それらのネットワークが隣接していない場合、メッセージは間にあるいくつかのネットワークと、それらに接続するルータとを通して渡されるだろう。メッセージが宛先と同じネットワーク上にあるルータまで到達すると、その宛先に到達するためにそのネットワーク固有の技術が使用される。
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 addressing is in use. このセクション全体を通して用語 "ネットワーク(network)" は、単一のブロードキャストネットワーク(例えばイーサネット)、ポイントツーポイント回線、ARPANET などを網羅するために総称的に使用される。重要な点は、ネットワークが IP によって単独の実体として扱われることである。(ポイントツーポイント回線のように)転送判断は必要ないか、(イーサネットまたは ARPANET のように) IP がネットワーク全体を単一の完全に接続されたネットワークとして扱うことを可能にしながら、IP に対して透過的な方法で転送が行われる。IP アドレッシングの議論において、用語 "ネットワーク(network)" は多少異なる方法で使用されていることに注意してほしい。私たちは用語 "ネットワーク(network)" を、サブネットアドレッシングが使用されている場合におけるサブネットを参照するために使用している。
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. ネットワーク間の経路を見つけるための様々なアプローチが考えられる。それらのアプローチを分類する有用な方法のひとつは、経路を探せるようにするためにルータが交換する必要のある情報の種類に基づくものである。距離ベクトルアルゴリズムは少量の情報の交換に基づく。ルーティングプロトコルに参加する各エンティティ(ルータまたはホスト)は、そのシステム内のすべての宛先についての情報を保持する役割を担う。一般に、ひとつのネットワークに接続するすべてのエンティティについての情報は単一のエントリに集約され、それはそのネットワーク上のすべての宛先への経路を表す。IP に関する限り、ひとつのネットワーク内部のルーティングは不可視であるため、このような集約が可能となる。このルーティングデータベース内の各エントリは、そのエンティティに向けられたデータグラムが送信されるべき次のルータを含む。加えて、エンティティへの総距離を評価する "メトリック(metric)" を含む。この距離は多少一般化された概念であり、メッセージがエンティティに到達する際の時間遅延や、メッセージをそこに送信するための金銭的コストなどを網羅することができる。距離ベクトルアルゴリズムという名前は、交換される唯一の情報がそれらの距離のリストであるときに最適の経路を算出できるとう事実に由来する。また情報は、隣接するエンティティ(つまり、共通のネットワークを共有するエンティティ)の間でのみ交換される。
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 参照。) 実際には、あるホストまたはルータから別のルータまたはホストへの経路の観点から、この数学的展開はもっとも都合のよい考え方である。抽象的観点で議論する場合、ネットワークのためのルーティングエントリを、そのネットワークに接続するすべてのエンティティのためのルーティングエントリの省略形と考えるのが最良である。この種の省略形が意味を持つのは、私たちがネットワークを 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: 前述したように、各エンティティは組織内のあり得るすべての宛先ごとにひとつのエントリを持つルーティングデータベースを保持する。実際の実装は、各宛先ごとに以下の情報を保持する必要があるだろう：
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". 前述の通り、ルーティングの目的は、データグラムをその最終目的地に到達させるための道筋を見つけることである。距離ベクトルアルゴリズムは、システム内の各宛先への最適な経路をリストする各ルータ内のテーブルに基づいている。当然ながら、どの経路が最適かを定義するために、私たちはその適切さを計測する何らかの方法を必要とする。それは "メトリック(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. 単純なネットワークの場合、メッセージが通過しなければならないルータの数を単純にカウントしたメトリックを使用するのが一般的である。より複雑なネットワークの場合、メッセージに課される遅延や送信に要する費用、他の最小化してほしい数量などの総量を表すメトリックが選ばれる。主な要件は、個々のホップのための "コスト(costs)" の合計としてメトリックを表すことが可能でなければならないことである。
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 that make up the route. For the purposes of this memo, we assume that the costs are positive integers. 形式上、エンティティ i からエンティティ j に直接到達可能な場合(つまり、それらの間で別のルータを通過しない場合)、コスト d(i,j) は i と j との間のホップに対応する。あるネットワーク上のすべてのエンティティが同等と見なせるような通常の環境の場合、d(i,j) はネットワーク上のすべての宛先に対して等しく、そのネットワークを使用するコストを表す。ある経路の完全なメトリックを得るには、その経路を構成する個々のホップのコストを単純に合計すればよい。この文書の目的のために、私たちはコストが正の整数であると仮定する。
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
D(i,i) = 0, すべての i
D(i,j) = min [d(i,k) + D(k,j)], それ以外
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. 最適経路が i から始まり d(i,k) + D(k,j) が最小値になる隣接する 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 までの距離の推測値を送信させる。i は k から推測値を取得すると、そのそれぞれの数値に d(i,k) を加算する。これは単に、i と k との間のネットワークを横断するコストである。時々 i は、隣接エンティティからの複数の値を比較し、最小値を選択する。
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 time no matter what the starting point. Otherwise certain kinds of changes might lead to non-convergent behavior. トポロジーに変化が無い限りこのアルゴリズムが有限時間内に D(i,j) の正しい推定値に収束することの証明は、[2] に示されている。著者は、エンティティが情報を互いに送信したり最小値を再計算したりする順序について、ほとんど推測しない。基本的にエンティティは更新の送信とメトリックの再計算とを止められないし、ネットワークはいつまでもメッセージを遅延することはできない。(ルーティングエンティティの故障はトポロジーの変化である。) またそれらの証明は、D(i,j) の初期見積りについて、それが負の数ではないことを除き、何も仮定しない。極めて貧弱な仮定で十分であるというこの事実は重要である。いつ更新が送信されるかについて仮定する必要がないため、アルゴリズムを非同期に実行しても安全である。したがって各エンティティは、自身の時計にしたがって更新を送信できる。すべての更新が破棄されるのではない限り、ネットワークは更新を破棄してもよい。開始条件について仮定する必要がないため、アルゴリズムは変化に対応できる。システムが変化したとき、ルーティングアルゴリズムは開始点として以前の平衡状態を使用しながら、新たな平衡状態への移行を始める。開始点が何であれ、このアルゴリズムが有限時間内に収束することは重要である。そうでなければ、ある種の変化によって収束しない状態に陥る可能性がある。
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. 上記のアルゴリズムの説明(および証明)は、それぞれのエンティティが各隣接エンティティからの推定値のコピーを保持し、時々すべての隣接者にわたる最小化(min)を行うと仮定している。実際のところ、現実の実装がこれらを行う必要はなく、単純にそれまでに得た最善のメトリックと、それを送信した隣接者の身元とを覚えておくだけである。実装は、より適した(より小さい)メトリックを見つけた場合にはいつでもその情報を置き換える。これにより実装は、すべての隣接者からの情報を保持しなくとも、その都度最小値を算出することができる。
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 のような実際のプロトコルで使用されるプロトコルとの間には、もうひとつ別の違いがある：上記の説明は、各エンティティが自身のためのエントリを持ち、距離ゼロを表すとしている。実際のところ、これは一般には行われない。ネットワーク上のすべてのエンティティは、通常そのネットワークのための単一のエントリによってまとめられることを思い出してほしい。ネットワーク A に接続するホストまたはルータ G の状況を考える。C はネットワーク A を使用するコスト(普通はメトリック 1)を表す。(私たちはネットワークの内部構造が IP には見えず、したがってそのネットワーク上の任意の 2 つのエンティティ間のコストが同じであると仮定していることを思い出してほしい。) 原則として、G はネットワーク A 上のすべての他のエンティティ H からメッセージを得るべきであり、コストゼロはそのエンティティから自分自身へのコストを表す。次に G は、H までの距離として C + 0 を計算するだろう。G にこれらの同一メッセージをすべて見せる代わりに、単純に自身のテーブル内にネットワーク A のためのエンティティを作成し、それに C のメトリックを割り当てることから始める。ネットワーク A のためのこのエントリは、ネットワーク A 上の他のすべてのエンティティのためのエントリをまとめたものとして考えられるべきである。共通のエントリにまとめられない A 上の唯一のエンティティは G 自身である。なぜなら G から G へのコストは 0 であり、C ではないためである。しかし私たちはこれら 0 のエントリを必要としないため、ネットワーク A のための単一エントリに安全にしたがうことができる。この戦略のもうひとつ別の意味についての注意：私たちは 0 のエントリをまったく必要としないので、ルータとして動作しないホストは更新メッセージをまったく送信しなくてよい。明らかに、ルータとして機能しないホスト(つまり、ひとつのネットワークにだけ接続しているホスト)は、自身のエントリ D(i,i) = 0 より有用な情報を持てない。それらはインターフェイスをひとつしか持たないため、それらを経由する他のネットワークへの経路は、単純にそのインターフェイスへと入り、そこから出て行くことが簡単にわかる。したがってそのような経路のコストは、最適コストから少なくとも C だけ大きくなるだろう。私たちは 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 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 はその宛先のためのメトリックの現在の推定値(つまり、そこに到達するための総コスト)と、そのメトリックの元になった情報を持つ隣接ルータの身元とを保持する。宛先が G に直接接続するネットワーク上にある場合、G は単純にそのネットワークを使用するコストを表すエントリを使用し、実際にはルータを必要としない。いったん計算が正しいメトリックに収束すると、この手法によって記録される隣接者が実際にはその宛先までの経路上の先頭のルータであることは簡単に分かる。(適切さの等しい複数の経路が存在する場合、そのうちのひとつの経路上の先頭のルータとなる。) 宛先・メトリック・ルータの組み合わせは、一般に、そのルータを使用してそのメトリックを持つその宛先への経路を表す。
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.) より小さいメトリックが現れるまで既存のメトリックが保持されるため、これまでのところこの手法はメトリックを下げる手段しか持たない。最初の見積もりが低すぎる場合もありうる。そのため、メトリックを増加させる手段も必要である。結局、次の規則を使用すれば十分ということが分かる：宛先への現在の経路がメトリック D を持ち、ルータ G を使用すると仮定する。G 以外から新しい情報が到着した場合、その新しいメトリックが D より優れている場合にのみ経路が更新される。しかし、G 自身から新しい情報が到着した場合、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 プロトコルの説明ではないことに注意してほしい。追加されるべき改良がまだいくつかある。) 以下の手続きは、このルーティングプロトコルに参加するすべてのエンティティによって実行される。これにはシステム内のすべてのルータが含まれなければならない。ルータではないホストも同様に参加してよい。
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 を使用すると仮定する。G からの応答が 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 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. 以下で見るように、あるネットワークへの有効な経路が現時点で存在しないことを隣接者に知らせる方法を持つことは有益である。RIP は(この分野の他のいくつかのプロトコルと共に)、通常の更新メッセージを通してそのネットワークを到達不能とマークすることでそれを行う。到達不能な宛先を表すために特別なメトリック値を選択する。そのメトリック値は、私たちの期待する有効な最大のメトリックより大きい。既存の RIP 実装では 16 が使用される。この値は有効な最大のメトリックより大きいため、通常 "無限(infinity)" と見なされる。16 というのは驚くほど小さい数値に見えるかもしれない。私たちが簡単に参照するために、この小さい値が選択された。大部分の実装において経路が無効であることを通知するために、この同じ習慣が使用されている。
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. それは、アクセス不能になった経路を扱うために数学を拡張するほど簡単である。先に提示した習慣がうまく働くだろう。私たちは "無限(infinity)" を表すために大きなメトリック値を選択する。この値は、現実のメトリック値が超えないだけの十分に大きい値でなければならない。この例の目的のために、私たちは値 16 を使用する。あるネットワークがアクセス不能になったと仮定する。すべての直近のルータはタイムアウトし、そのネットワークのためのメトリックを 16 にセットする。私たちは分析の目的ために、すべての隣接ルータが、その消滅したネットワークにコスト 16 で直接接続する新しいハードウェア部品を得たと仮定することができる。それが消滅したネットワークへの唯一の接続であるため、その組織内の他のすべてのルータは、それらのルータのひとつを通る新しい経路に収束するだろう。いったん収束が起こると、すべてのルータがその消滅したネットワークに最低でも 16 のメトリックを持つことは簡単に理解できる。元の隣接者から 1 ホップだけ離れたルータは少なくとも 17 のメトリックで終わり、2 ホップ離れたルータは少なくとも 18 で終わるなどとなる。これらのメトリックは最大のメトリック値より大きいため、すべて 16 にセットされる。この段階で、その組織がすべてのルータにおいて消滅したネットワークに対しメトリック 16 に収束するであろうことは明らかである。
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 の正しい実装では起こらないことに注意してほしい。私たちは、ある種の機能がなぜ必要なのかを示そうとしている。以下の例において、各文字はルータを表し、線はネットワークを表している。
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 / C から D への直接接続はコスト 10
| / それ以外のネットワークはすべてコスト 1 である
|/
D
|<=== 目的のネットワーク
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 経由の経路、メトリック 2
C: B 経由の経路、メトリック 3
A: 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 への経路を使用するように調整されるはずだが、残念ながらそれが起こるにはしばらく時間が掛かる。ルーティングの変更は、D への経路が使用不能であることを 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
dir = directly connected
unreach = unreachable
時間 ------>
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
dir = 直接接続
unreach = 到達不能
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 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". ここで問題がある：B はタイムアウトメカニズムを使用することで故障した経路を削除することができるが、その経路の痕跡は長期間そのシステム内に残る。当初 A および C は、B を経由して D に到達可能と考える。そのため A および C は、メトリック 3 を表す更新を送信し続ける。次の段階で B は、A または C のどちらかを経由して D に到達可能であることを宣言するだろう。当然それはできない。A と C とによって宣言されている経路はすでに消滅しているが、それを知る方法がない。また A と C とは、B 経由の経路が失われたことを発見したときでも、他を経由する経路が存在すると考える。最終的にすべての計算があるべき状況になり、システムは収束する。しかしそれにはある程度の時間が必要だろう。最悪のケースは、ネットワークがシステムの一部から完全にアクセス不能になったときである。その場合、メトリックは前述のようなパターンで、最終的に無限(infinity)になるまでゆっくりと増加するだろう。そのためこの問題は、"無限までのカウント(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. "無限(infinity)" にできるだけ小さい値を選択した理由がこれで分かるはずである。ネットワークが完全にアクセス不能になった場合、私たちは無限までのカウントをできるだけ早く止めたい。無限は、実在する経路より大きくなければならない。しかし必要以上に大きくはないべきである。そのため無限の選択は、ネットワークのサイズと、無限までのカウントが発生した場合の収束速度とのトレードオフである。RIP の設計者は、本プロトコルが直径 16 以上のネットワークに実用的ではないだろうと考えた。
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 が使用するのは、"ポイズンリバース付き水平分割(split horizon with poisoned reverse)"、"トリガー更新(triggered updates)" である。
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 に到達可能であると主張する。情報を送信する場所についてもう少し注意することで、これを防ぐことができる。具体的にいうと、宛先ネットワークへの到達可能性を、その経路を学習した隣接者に宣言することは、まったくの無駄ということである。"水平分割(Split horizon)" は、ある経路をその経路を学習したルータに送信される更新に含むことにより引き起こされる問題を避ける方法である。"単純水平分割(simple split horizon)" は、ある隣接者から学習した経路をその隣接者に送信する更新から除く。"ポイズンリバース付き水平分割(Split horizon with poisoned reverse)" は、そのような経路を更新に含めるが、そのメトリックを無限大にセットする。
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 is used for C can be used for all other routers on the same network. Thus, update messages can be sent by broadcast. A が C 経由で D に到達可能と考えるなら、C へのメッセージは D が到達不能であることを示すべきである。C を通過するその経路が存在するなら、C は D への直接接続か、別のルータを通過する接続を持つ。C の経路が A に戻るとループを形成するため、それはできない。D が到達不能であることを C に伝えることで A は、C が混乱し、A を経由する経路が存在すると信じる可能性を簡単に防ぐことができる。ポイントツーポイント回線ではこれは明らかである。しかし、A と C とがイーサネットのようなブロードキャストネットワークによって接続され、ネットワーク上に別の経路が存在する可能性を考えよう。A が C を経由する経路を持つ場合、そのネットワーク上の他のどのルータと対話するときにも、A は D が到達不能であることを示すべきである。ネットワーク上の他のルータは自身で C に到達できる。それらは A 経由で C に到達する必要がないだろう。A の持つ最適な経路が実際に C を経由するのであれば、そのネットワーク上の他のルータは A が D に到達できることを知る必要がない。これは好都合である。なぜなら 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. 一般にポイズンリバース付き水平分割は単純水平分割より安全である。二つのルータが互いを指す経路を持つ場合、メトリック 16 を持つリバースルートを通知することで即座にループが遮断されるだろう。リバースルートが単純に通知されなかった場合、誤った経路はタイムアウトを待つことで削除されなければならないだろう。しかしながらポイズンリバースには、ルーティングメッセージのサイズを増加させるという欠点もある。多くの建物に接続する構内バックボーンを考えよう。それぞれの建物内に、ローカルネットワークをバックボーンに接続するルータが存在する。それらのルータがバックボーンネットワーク上でどのようなルーティング更新をブロードキャストするべきかを考えよう。そのネットワークの残りが各ルータに付いて本当に知る必要があることは、それがどのローカルネットワークに接続しているかということである。単純水平分割を使用すると、ルータによってバックボーンネットワークに送信される更新メッセージにはそれらの経路だけが現れるだろう。ポイズンリバース付き水平分割が使用される場合、ルータはバックボーンから学習したすべての経路がメトリック 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 を持たせて通知することは、何の追加情報も提供しない。ひとつのブロードキャストネットワーク上に多数のルータが存在すると、それらの余分なエントリが大幅に帯域を使用する可能性がある。それらの存在する意味は、動的な挙動を改善することである。トポロジーが変化したとき、そのルータを通るべきではない経路を、そうするべきである経路と同様に通知することで、収束を加速できる。しかしながら場合によっては、ネットワーク管理者はルーティングのオーバーヘッドを最小化するために、多少ゆっくりとした収束を受け入れることを好むかもしれない。したがって、実装者は自身の判断で、ポイズンリバース付き水平分割ではなく単純水平分割を実装したり、ネットワーク管理者がどちらの振る舞いを使用するかを選択できるようにする構成オプションを提供したりしてよい。また、メトリック 16 を持つ一部の経路を通知しそれ以外を省略するハイブリッドな仕組みも許される。そのような仕組みの例は、それらにかかわるルーティングの変化の後に一定期間だけリバースルートのためにメトリック 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 実装が水平分割を使用しなければならず、ポイズンリバースを無効化する仕組みが存在してもよいが、ポイズンリバース付き水平分割も使用するべきであると規定している。
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. ポイズンリバース付き水平分割は、ただ二つのルータが関わるルーティングループなら防ぐだろう。しかしながらそれでも、三つのルータが相いに偽装するようなパターンに陥る可能性はある。例えば、A は B を、B は C を、C は A を通過する経路をそれぞれ持つと信じる可能性がある。水平分割はそのようなループを止めることができない。このループは、メトリックが無限大に到達し、関与するネットワークが次に到達不能と宣言されたときにのみ、解決するだろう。トリガー更新は、この収束を加速させる試みである。トリガー更新を得るために、私たちは単純に、ルータが経路のメトリックを変更したときには常に、たとえ定期的な更新メッセージの時間に達していない場合でも、ほとんど即座に更新メッセージを送信することを要求するという規則を追加する。(タイミングの詳細はプロトコルによって異なるだろう。RIP を含む一部の距離ベクトル型プロトコルは、トリガー更新が過度のネットワークトラフィックを生成するのを避けるために、短い遅延を指定する。) これが新しいメトリックを計算するための規則とどのように組み合わされるかに注意してほしい。あるルータの持つ宛先 N への経路が ルータ G を経由すると仮定する。更新が G 自身から到着した場合、それを受信したルータは、新しいメトリックが古いメトリックより高くても低くても、その新しい情報を信用する必要がある。結果としてメトリックが変更された場合、それを受信したルータは次に、直接接続しているすべてのホストとルータとにトリガー更新を送信するだろう。それらは順々にその隣接者へと更新を送信するかもしれない。結果はトリガー更新の連鎖である。その連鎖にどのルータとホストとが関与するのかを示すのは簡単である。ルータ G が宛先 N への経路にタイムアウトしたと仮定する。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 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. 残念ながら物事はそううまくは行かない。トリガー更新が送信されている間に、定期更新が同時に起こる可能性がある。トリガー更新をまだ受信していないルータは、すでに存在しない経路に基づく情報を送り続けることになるだろう。トリガー更新がルータを通過した後で、それらのルータのうち命令をまだ受けていないものひとつから通常の更新を受信する可能性がある。これは不完全な経路の名残りを復活させるかもしれない。トリガー更新が十分急速に起こるなら、これはとてもありそうにない。しかしながら無限大までのカウントは、それでも可能である。
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 実装は、トリガー更新が送信されてよい速度を制限しなければならない。(セクション 3.10.1 参照)
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 を使用するすべてのルータはネットワークへのインターフェイスをひとつまたは複数持つと考えられる(そうでなければ、それは実際にはルータではない)。それらは直接接続されたネットワークと呼ばれる。このプロトコルは、それらの各ネットワークに関する特定の情報へのアクセスに依存する。その中でももっとも重要なのは、そのネットワークのメトリックである。ネットワークの 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 を使用するすべてのホストは、ネットワークへのインターフェイスをひとつまたは複数持つと考えられる。それらは "直接接続されたネットワーク(directly-connected networkds)" と呼ばれる。本プロトコルは、それらの各ネットワークに関する特定の情報へのアクセスに依存する。その中でももっとも重要なのは、そのネットワークのメトリックまたは "コスト(cost)" である。メトリックは 1 から 15 までの整数である。それは本プロトコルで規定されない何らかの方法で設定される。大部分の既存の実装は、常にメトリック 1 を使用する。新しい実装は、システム管理者が各ネットワークのコストを設定することを許可するべきである。コストに加えて、各ネットワークは 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 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 で規定されている規則は、各 IPv4 ネットワークに適用される単独のサブネットマスクが存在し、直接接続するネットワークのためのサブネットマスクのみが知られていると仮定している。単一のネットワーク内で異なるサブネットのための異なるサブネットマスクを使用する組織が存在するかもしれない。また、システムが遠隔地のネットワークのサブネットマスクを知るのが望ましい場合もあるかもしれない。ネットワーク内のすべてのルータが本文書で示されている拡張を実行している場合、異なるサブネットマスクを含むルーティング情報をネットワーク全体に配布することが可能となる。しかしながら、ネットワーク内のすべてのルータがそれらの拡張を実行しているわけではない場合、相互運用性の問題を避けるために、異なるサブネットマスクを含むルーティング情報の配布は制限されなければならない。サブネットの配布を管理する規則に付いては、セクション 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 を運用する組織を通して到達可能なすべての宛先ごとにひとつのエントリを持つ。各エントリは少なくとも以下の情報を含む：
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 メトリックは単純なホップ数(hop-count)に帰着する。(例えば帯域や信頼性の違いを表すために)一部のネットワークが他よりも優先することを示したい場合、より複雑なメトリックが使用されてもよい。
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 アドレスと合わせて)単一ネットワーク内の異なるサブネットはもちろん、遠隔地のネットワークのサブネットマスクも識別することを可能にする。
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. 実装者は、システム管理者が追加の経路を入力することを許可してもよい。それらはこのルーティングシステムの範囲外のホストまたはネットワークへの経路だろう。それらは "スタティックルート(static routes)" と呼ばれる。それらの初期経路以外の宛先へのエントリーは、以降のセクションで説明されるアルゴリズムによって追加・更新される。
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 内のすべてのルータが本プロトコルに参加しなければならない。複数の IGP が使用される場合、それらのプロトコル間でルーティング情報を渡すことのできるルータが、少なくともひとつは存在しなければならない。
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 ポート番号 520 (RIP-1/RIP-2 のポート)上でデータグラムを送受信するルーティングプロセスを持つ。別のルータの 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) |
+---------------+---------------+-------------------------------+
| |
~ RIP エントリ (20) ~
| |
+---------------+---------------+---------------+---------------+
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 とで実装されるコマンドは以下の通り：
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 の場合、これらのそれぞれのメッセージタイプに対し、データグラムの残りはルーティングエントリ(RTE)のリストを含む。このリスト内の各 RTE は、アドレスファミリ識別子(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 (無限大)を含む。
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 パケットのフォーマットは、さまざまな種類のアドレスを区別しない。"アドレス(address)" とラベル付けされたフィールドは、以下のいずれかを含むことができる：
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, 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-1 によって受信した情報を評価するとき、そのアドレスの解釈は、そのネットワークに適用されるサブネットマスクを知っているかどうかに依存する。知っていればそのアドレスの意味を判断することが可能である。例えばネットワーク 128.6 を考える。これは 255.255.255.0 のサブネットマスクを持つ。したがって、128.6.0.0 はネットワーク番号、128.6.4.0 はサブネット番号、128.6.4.1 はノードアドレスである。しかしながらノードがそのサブネットマスクを知らない場合、アドレスの評価はあいまいになる可能性がある。非ゼロのノード部がある場合、そのアドレスがサブネット番号なのかノードアドレスなのかを判断する明確な方法はない。サブネットマスクなしのサブネット番号は役に立たないだろうから、この状況ではアドレスはノードを表すと考えられる。このようなあいまいさを避けるために、バージョン 1 を使用する場合、ノードは適切なサブネットマスクを知っていることを期待できないノードにサブネット経路を送信しないべきである。通常、ホストは直接接続しているネットワークのサブネットだけを知っている。そのため特別な取り決めがない限り、サブネットへの経路はそのサブネットが一部であるネットワークの外へ送信されてはならない。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. この "サブネットフィルタリング(subnet filtering)" は、サブネット化されたネットワークの "境界(border)" にあるルータによって実行される。それらはそのネットワークを別のネットワークに接続するルータである。サブネット化されたネットワーク内において、各サブネットは個別のネットワークとして扱われる。各サブネットのためのルーティングエントリは 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. 同様に境界ルータは、他のネットワークへのメッセージにおいて、直接接続するネットワークの内部ノードのためのホスト経路を挙げてはならない。それらの経路はそのネットワーク全体のための単一エントリに含まれる。
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 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 はデフォルトルートを表すために使用される。デフォルトルートは、RIP 更新においてすべての取り得るネットワークをリストするのが不便な場合や、組織内のひとつまたは複数のルータが、明示的に示されていないネットワークへのトラフィックを処理する準備ができている場合に使用される。それらのルータは、アドレス 0.0.0.0 のための RIP エントリを、それらが接続しているネットワークであるかのように生成するべきである。ルータが 0.0.0.0 のためのエントリをどのように生成するかに付いての判断は実装者に任される。通常、どのルータが 0.0.0.0 のためのエントリを生成するべきかをシステム管理者が指定する方法を提供することになるだろうが、他のメカニズムも可能である。例えば実装者は、BGP を話す任意のルータがデフォルトルータになるように宣言されるべきであると判断してもよい。これらのエントリにおいて使用されるべきメトリックをネットワーク管理者が選択できるようにするのが有益かもしれない。デフォルトルータが二つ以上存在する場合、それによってあるルータの別のルータに対する優先順位を表現することが可能になるだろう。RIP は 0.0.0.0 のためのエントリを、そのアドレスを持つ実際のネットワークが存在する場合とまったく同じように扱う。システム管理者は、0.0.0.0 への経路が意図している以上に増殖しないことを確実にするように注意するべきである。一般にそれぞれの自治組織は、それ自身の推奨されるデフォルトルータを持つ。したがって 0.0.0.0 を含む経路は、一般に自治組織の境界上にあるはずである。それを強制するためのメカニズムは、本文書では規定されない。
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 プロセスは完全なルーティングテーブルを含む未承諾レスポンスメッセージをすべての隣接ルータに送信するために呼び起こされる(水平分割に付いてセクション 3.9 を参照)。単一ネットワーク内に多数のルータが存在する場合、それらは互いに連動する傾向があるため、すべてが同時に更新を発行する。これは 30 秒タイマーがシステム上の処理負荷に影響を受ける場合にはいつでも起こる可能性がある。更新メッセージが同期するのは、ブロードキャストネットワーク上の不必要なコリジョンの原因となるため望ましくない。したがって実装は、次の二つの予防策のひとつを取る必要がある：
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. 各経路には関連する二つのタイマー、"タイムアウト(timeout)" と "ガベージコレクション(garbage-collection)" がある。タイムアウトの期限が切れたとき、その経路はもはや有効ではない。しかしながら、その経路が破棄されたことが隣接者に通知されるように、短時間だけルーティングテーブルに保持される。ガベージコレクションタイマーの期限が切れた時点で、その経路はルーティングテーブルから削除される。
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: 削除は二つの理由により発生し得る：タイムアウトの期限切れ、または、最新のルータから受信した更新によりメトリックが 16 にセットされたとき(他のルータからの更新の処理の議論は 3.7.2 を参照してほしい)である。どちらの場合も以下のイベントが発生する：
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 で説明するのが最善である。
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 を参照してほしい。
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. リクエストは、ルータの持つルーティングテーブルのすべてまたは一部を含むレスポンスを要求するために使用される。リクエストは通常、立ち上がったばかりで出来るだけ早くルーティングテーブルを満たしたいルータによって、RIP ポートからブロードキャスト(RIP-2 の場合はマルチキャスト)として送信される。しかしながら、例えばルータの監視など、唯ひとつのルータのルーティングテーブルだけが必要な状況もあり得る。その場合、リクエストは RIP ポート以外の UDP ポートからそのルータに直接送信されるべきである。そのようなリクエストを受信した場合、ルータは要求者のアドレス/ポートに直接応答する。
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 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. リクエストはエントリごとに処理される。エントリが存在しなければ応答は返されない。特別なケースがひとつある。リクエスト内に正確にひとつのエントリが存在し、それがゼロのアドレスファミリ識別子と無限大のメトリック(つまり 16)を持つ場合、それはルーティングテーブル全体の送信を求めるリクエストである。その場合、要求されたアドレス/ポートにルーティングテーブルを送信するために出力プロセスの呼び出しが発生する。この特殊な場合を除き、処理は極めて単純である。リクエスト内の RTE のリストをひとつずつ検査する。各エントリごとに、そのルータの持つルーティングデータベース内の宛先を検索する。経路が存在する場合、その RTE のメトリックフィールド内にその経路のメトリックを置く。指定された宛先への明示的な経路が存在しない場合、そのメトリックフィールドに無限大をセットする。すべてのエントリが満たされた時点で、コマンドをリクエストからレスポンスに変更し、データグラムをリクエスト送信者に送り返す。
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. 個別のリクエストとテーブル全体のリクエストとでは、メトリックの処理に違いがあることに注意してほしい。リクエストが完全なルーティングテーブルを求める場合、水平分割を含め、通常の出力処理が行われる(水平分割に付いてはセクション 3.9 を参照)。リクエストが特定のエントリを求める場合、水平分割は行われず、それらはルーティングテーブル内を検索され、その情報がそのまま返される。この違いの理由は、これらのリクエストが異なる目的のために使用されるであろうという予測によるものである。ルータは始めて立ち上がったとき、完全なルーティングテーブルを求めるリクエストを、接続しているすべてのネットワークにマルチキャストする。それらの完全なルーティングテーブルは、要求者のルーティングテーブルを更新するために使用されると考えられる。そのため、水平分割が使用されなければならない。個別のネットワークを求めるリクエストは、診断ソフトウェアによってのみ生成され、ルーティングには使用されないと考えられる。その場合、要求者はルーティングテーブル内の正確な内容を知りたいと考え、どのような情報でも隠されたり修正されたりしないことを望むだろう。
A Response can be received for one of several different reasons: レスポンスはいくつかの異なる理由により受信される：
Processing is the same no matter why the Response was generated. レスポンスが生成された理由によらず、処理は同じである。
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. レスポンスの処理はルータのルーティングテーブルを更新する可能性があるため、レスポンスはその妥当性を慎重に確認されなければならない。RIP ポート以外からきたレスポンスは無視されなければならない。データグラムが有効な隣接者からのものかどうかを調べるために、データグラムの IPv4 送信元アドレスが確認されるべきである。データグラムの送信元は直接接続しているネットワーク上になければならない。レスポンスがそのルータ自身のアドレスのひとつから来たかどうかを確認するのも価値がある。ブロードキャストネットワーク上のインターフェイスは、自身によるブロードキャスト/マルチキャストのコピーを即座に受信する可能性がある。ルータが自身の出力を新しい入力として処理すると混乱が起こる可能性があるため、そのようなデータグラムは無視されなければならない。
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: データグラム全体の正当性が確認された時点で、レスポンス内の RTE をひとつずつ処理する。再び正当性の確認から始める。通常、誤ったメトリックや他のフォーマットエラーは不正な隣接者を表し、管理者の注意を引くべきである。例えばメトリックが無限大を超えている場合、そのエントリを無視するが、イベントは記録するべきである。基本的な妥当性確認は以下の通り：
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, エントリの正当性を確認するとすぐに、そのメッセージの到着したネットワークのコストを加算することでメトリックを更新する。結果が無限大を超える場合、無限大を使用する。つまり、
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: 次に、その宛先アドレスのための明示的な経路がすでに存在するかどうかを確認する。そのような経路が存在しない場合、そのメトリックが無限大でない限り(使用できない経路に加算しても意味がない)、ルーティングテーブルにその経路を追加する。ルーティングテーブルへの経路の追加は、以下の動作を含む：
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 than the old one; or, if the new metric is lower than the old one; do the following actions: 既存の経路が存在する場合、そのデータグラムの来たルータのアドレスと次ホップアドレスとを比較する。そのデータグラムが既存の経路と同じルータから来ている場合、タイムアウトを再初期化する。次にメトリックを比較する。そのデータグラムが既存の経路と同じルータから来ており、かつ新しいメトリックが古いものと異なる場合、または新しいメトリックが古いものより小さい場合、以下の動作を行う：
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. これらのテストを通らないエントリは現在の経路より劣っているため、無視される。
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: このセクションでは、ルーティングテーブルのすべてまたは一部を含むレスポンスメッセージを生成するために使用される処理を説明する。この処理は以下の何れかにより起こる：
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. レスポンスがすべての隣接者に送信されるべき場合(つまり定期更新またはトリガー更新の場合)、レスポンスメッセージは、各ポイントツーポイント回線の遠点にあるルータに直接向けられ、ブロードキャストをサポートするすべての接続済みネットワーク上にブロードキャスト(RIP-2 の場合はマルチキャスト)される。したがって、直接接続している各ネットワークのためにひとつのレスポンスが準備され、適切なアドレスに(直接またはブロードキャスト/マルチキャストで)送信される。多くの場合、これはすべての隣接するルータに到達する。しかしながら、これでは不十分な場合もある。これにはブロードキャストネットワークではないネットワーク(例えば ARPANET)が含まれたり、ダムルータが含まれる可能性がある。そのような場合、隣接するルータの実際のリストを特定し、それぞれに明示的にデータグラムを送信する必要があるかもしれない。そのようなメカニズムが必要かどうかの判断と、リストの指定方法の定義とは、実装者に任される。
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. 二つの理由によりトリガー更新は特別な扱いを必要とする。第一にトリガー更新は、限られた能力のネットワークまたは多数のルータを持つネットワークに過度の負荷を掛けることが、経験的に知られている。そのためこのプロトコルは、実装者がトリガー更新の頻度を制限する対策を含めることを要求する。トリガー更新が送信された後、タイマーは 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. 第二に、トリガー更新はルーティングテーブル全体を必要としない。原則として、変更された経路のみ含まれる必要がある。したがって、トリガー更新の一部として生成されるメッセージは、少なくとも経路変更フラグをセットされた経路を含まなければならない。実装者の判断で追加の経路が含まれてもよいが、全経路の更新を送信することは強く推奨されない。トリガー更新が処理されるとき、すべての直接接続しているネットワークのためにメッセージが生成されるべきである。通常の更新の場合と同様、トリガー更新の場合にも水平分割が行われる(セクション 3.9 参照)。ある特定のネットワークのための水平分割処理の後、変更された経路がそのネットワーク上で変更されていないように見える(例えば無限大のメトリックを持つ)場合、その経路が送信される必要はない。そのネットワーク上で送信する必要のある経路がまったくない場合、その更新は省略されてよい。すべてのトリガー更新が生成されたとき、経路変更フラグはクリアされるべきである。
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. トリガー更新と他の更新メッセージとの唯一の違いは、変更されていない経路を省略可能かどうかである。それ以外の仕組み(次のセクションで説明される)は、すべての更新に適用されなければならない。
This section describes how a Response message is generated for a particular directly-connected network: このセクションでは、直接接続された特定のネットワークのためにレスポンスメッセージを生成する方法を説明する。
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 をセットする。どちらのバージョンを送信するかを判断するメカニズムは実装固有だが、リクエストに対するレスポンスの場合、そのバージョンはリクエストのバージョンに一致するべきである。レスポンスにコマンドをセットする。"ゼロでなければならない(must be zero)" とラベル付けされているバイトにゼロをセットする。RTE の設定を開始する。レスポンスには RTE が 25 個までの制限があることを思い出してほしい。それ以上存在する場合、現在のレスポンスを送信し、新しいレスポンスを開始する。レスポンスを構成するデータグラム数に明確な制限はない。
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. RTE を埋めるために、ルーティングテーブル内の各経路を調べる。トリガー更新を生成中であれば、経路変更フラグがセットされているエントリのみを含める必要がある。水平分割の処理後にその経路を含めないべきであれば、それをスキップする。その経路を含めるべきであれば、その宛先アドレスとメトリックとを RTE に入れる。メトリックが無限大であったとしても、データグラム内にその経路を含めなければならない。
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.6 参照(※))。RIP-2 のための 20 オクテットの経路エントリ(RTE)のフォーマットは以下の通り：
※訳注：原文では参照先がセクション 3.4(距離ベクトルアルゴリズム)になっていますが、おそらく上記の通り「3.6 メッセージフォーマット」の間違いです。
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.
アドレスファミリ識別子・IP アドレス・メトリックは、セクション 3.6(※)で定義されている意味を持つ。バージョンフィールドは、認証を使用するか任意の新しく定義されたフィールドで情報を運ぶかする RIP メッセージのための、バージョン番号 2 を指定することになる。
※訳注：原文では参照先がセクション 3.4(距離ベクトルアルゴリズム)になっていますが、おそらく上記の通り「3.6 メッセージフォーマット」の間違いです。
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: 認証はメッセージ単位の機能であり、またメッセージヘッダ内には 2 オクテットのフィールドがひとつだけしかなく、さらにどのような合理的な認証スキームも 2 オクテットより多くを要求するため、RIP バージョン 2 のための認証スキームは、RIP エントリひとつ分の領域をすべて使用することになる。メッセージ内の最初のエントリのアドレスファミリ識別子が 0xFFFF の場合、そのエントリの残りは認証を含む。これは、そのメッセージの残りに最大 24 個の RIP エントリが存在し得ることを意味する。認証が使用されない場合、メッセージ内のどのエントリも 0xFFFF のアドレスファミリ識別子を含まないべきである。認証エントリを含む RIP メッセージは以下のフォーマットで始まる：
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). 現在のところ、唯一の認証タイプは単純なパスワードであり、そのタイプは 2 である。残りの 16 オクテットは平文パスワードを含む。パスワードが 16 オクテット未満の場合は左詰めで、右側はヌル(0x00)でパディングされなければならない。
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. 経路タグ(RT)フィールドは経路に割り当てられる属性であり、経路とともに保持され再配布されなければならない。経路タグの意図する使用法は、"内部(internal)" RIP 経路(RIP ルーティングドメイン内部のネットワークのための経路)と、EGP や他の IGP からインポートされた "外部(external)" 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. RIP 以外のプロトコルをサポートするルータは、異なる情報源からインポートされた経路のために経路タグを設定可能なように構成できるべきである。例えば EGP または BGP からインポートされた経路は、任意の値か、少なくともその経路を学習した自律システムの数か、どちらかを持てるべきである。
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 ドメイン内のすべてのルータが首尾一貫して使用する限り、経路タグの別の使用法も有効である。これは、BGP-RIP プロトコル連携の文書(これは通過ネットワークにおいてルーティングを同期させる手段を説明するだろう)の可能性を考慮している。
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. サブネットマスクフィールドは、アドレスの非ホスト部を生成するために 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 のルーティングエントリ内の情報を受けたり操作したりする可能性のあるインターフェイス上では、以下の規則が適用される：
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.0.0 を指定することは、その RIP 通知の発信者を経由してルーティングが行われるべきであることを表す。必然的に次ホップとして指定されるアドレスは、その通知が生成された論理的なサブネット上で直接到達可能でなければならない。
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. 次ホップフィールドの目的は、システム内の余計なホップを通してルーティングされるパケットを削減することである。これはネットワーク上のすべてのルータで RIP が実行されているとは限らない場合に特に有効である。簡単な例が付録 A に示されている。次ホップが "助言(advisory)" フィールドであることに注意してほしい。つまり提供された情報が無視された場合、おそらく次善の、しかし完全に妥当な経路がとられてもよい。受け取った次ホップが直接到達可能でない場合、それは 0.0.0.0 として扱われなければならない。
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 で説明されているマルチキャストアドレスの使用が設定可能である。マルチキャストを使用する場合、それをサポートするすべてのインターフェイス上で使用するべきである。
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 のリクエストを受信した場合、RIP-1 のレスポンスを返すべきである。ルータが RIP-2 メッセージのみを送信するように設定されている場合、RIP-1 のリクエストには応えないべきである。
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)フィールドがゼロでなければ破棄されるべきであり、1 より大きいバージョンの RIP メッセージは MBZ フィールドがゼロ以外の値を含むという単純な理由で破棄されるべきではないと規定している。これは、RIP の新しいバージョンが、仕様のこの部分を守る既存の RIP 実装と完全に互換性を持つことを意味する。
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. 互換性は二つの理由のために必要である。第一に、前述の RFC [1] に従わない RIP-1 の実装が存在するため。第二に、マルチキャストの使用は、RIP-1 のシステムが RIP-2 の更新を受信するのを防ぐためである(場合によっては望ましい機能かもしれない)。この切り替えはインターフェイスごとに設定可能であるべきである。
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-2 メッセージをブロードキャストする「RIP-1 互換」、RIP-2 メッセージをマルチキャストする「RIP-2」、RIP メッセージの送信を無効にする「"none"」である。デフォルト設定は RIP-1 または RIP-2 が推奨され、RIP-1 互換は推奨されない。これは、ある種のトポロジーで起こり得る潜在的な問題のためである。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. 完全性のために、ルータは RIP-1 のみ受け入れるか、RIP-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 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. RIP メッセージを認証するために以下のアルゴリズムを使用するべきである。ルータが RIP-2 メッセージを認証するように設定されていない場合、RIP-1 および未認証の RIP-2 メッセージは受け入れられ、認証済み RIP-2 メッセージは破棄されるべきである。ルータが RIP-2 メッセージを認証するように設定されている場合、RIP-1 メッセージおよび認証確認に合格した RIP-2 メッセージは受け入れられるべきであり、未認証および認証に失敗した RIP-2 メッセージは破棄されるべきである。最大限のセキュリティのためには、認証が使用されている場合に RIP-1 メッセージは無視されるべきであり(セクション 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. 認証エントリは 0xFFFF のアドレスファミリによってマークされるため、RIP-1 システムはそのエントリを IP 以外のアドレスファミリに属するものとして無視するだろう。したがって、認証を使用することで RIP-1 システムが RIP-2 メッセージを見ることを妨げるわけではないことに注意するべきである。必要なら、これはマルチキャストを使用して行われてもよい(セクション 4.5 および 5.1 参照)。
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. さらに互換性に関して人々が求めた項目がひとつある。無限大に対する加算である。これを行えない主な理由は、それが下位互換性に違反するためである。より大きい無限は、明らかに過去のバージョンの RIP を混乱させるだろう。よくてもそれらは、メトリック 16 を無視するのと同じようにその経路を無視するだろう。メトリックを単一オクテットにし、上位 3 オクテットを再利用するという提案もあったが、それはメトリックを 4 オクテットのエンティティとして扱う実装を狂わせるだろう。
As in RIP-1, addressless links will not be supported by RIP-2. RIP-1 と同様、RIP-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 のものに制限されるべきである。さもなければ、ブラックホール経路(つまり存在しないネットワークのための経路)を生成したり、バージョン 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. 一部の実装は、隣接する経路のグループを自動的に単一のエントリにまとめようと試みる。その目的はエントリの総数を削減することである。これは自動要約(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 とを両方使用する場合、ネットワーク全体を通して単一のサブネットマスクが使用されるべきである。さらに、そのようなネットワークでは自動要約メカニズムを無効にするべきであり、実装は自動要約を無効化するメカニズムを提供しなければならない。
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] で説明されているメカニズムによってセキュリティはさらに拡張される。
This is a simple example of the use of the next hop field in a rip entry. これは RIP エントリの次ホップフィールドを使用する単純な例である。
----- ----- ----- ----- ----- -----
|IR1| |IR2| |IR3| |XR1| |XR2| |XR3|
--+-- --+-- --+-- --+-- --+-- --+--
| | | | | |
--+-------+-------+---------------+-------+-------+--
<-------------RIP-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 を使用することを選択したひとつの(例えば構内の)管理下にある "内部(internal)" ルータであると仮定する。一方で XR1・XR2・XR3 は別の(例えばその構内がメンバーである地域ネットワークの)管理下にあり、何らかの別のルーティングプロトコル(例えば OSPF)を使用している。XR1・XR2・XR3 はそれらの間でルーティング情報を交換し、ネットワーク N1・N2 への最適な経路は XR1 経由であり、N3・N4・N5 へは XR2 経由、N6・N7 へは XR3 経由であることを知る。次ホップフィールドを正しく設定する(N3・N4・N5 は XR2 へ、N6・N7 は XR3 へ)ことで、XR1 を通る追加ホップなしで発生するルーティングのために、XR1 のみが IR1・IR2・IR3 と RIP-2 の交換を行う必要がある。次ホップがない場合(例えば RIP-1 が使用されている場合)、余分なホップを削減するために、XR2・XR3 も RIP-2 プロトコルに参加する必要があるだろう。
[1] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988.
[2] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1389, January 1993.
[3] Baker, F., and R. Atkinson, "RIP-II MD5 Authentication", RFC 2082, January 1997.
[4] Bellman, R. E., "Dynamic Programming", Princeton University Press, Princeton, N.J., 1957.
[5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice-Hall, Englewood Cliffs, N.J., 1987.
[6] Braden, R., and Postel, J., "Requirements for Internet Gateways", STD 4, RFC 1009, June 1987.
[7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., "Pup: An Internetwork Architecture", IEEE Transactions on Communications, April 1980.
[8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks", Princeton University Press, Princeton, N.J., 1962.
[9] Xerox Corp., "Internet Transport Protocols", Xerox System Integration Standard XSIS 028112, December 1981.
[10] Floyd, S., and V. Jacobson, "The synchronization of Periodic Routing Messages," ACM Sigcom '93 symposium, September 1993.
[11] Baker, F., "Requirements for IP Version 4 Routers." RFC 1812, June 1995.
Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 01821 Phone: (978) 916-4237 EMail: [email protected]
Copyright (C) The Internet Society (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.
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.