[要約] RFC 2453はRIP Version 2の仕様を定義しており、RIPプロトコルの拡張として使用されます。目的は、ネットワーク間の経路情報の交換とルーティングテーブルの更新を効率的に行うことです。
Network Working Group G. Malkin
Request for Comments: 2453 Bay Networks
Obsoletes: 1723, 1388 November 1998
STD: 56
Category: Standards Track
RIP Version 2
RIPバージョン2
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document specifies an extension of the Routing Information Protocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP messages and to add a measure of security.
このドキュメントでは、[1]で定義されているルーティング情報プロトコル（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].
関連ドキュメントは、RIP-2 [2]のSNMP MIBオブジェクトを定義します。追加のドキュメントでは、RIP-2の暗号化セキュリティの改善を定義します[3]。
Acknowledgements
謝辞
I would like to thank the IETF RIP Working Group for their help in improving the RIP-2 protocol. Much of the text for the background discussions about distance vector protocols and some of the descriptions of the operation of RIP were taken from "Routing Information Protocol" by C. Hedrick [1]. Some of the final editing on the document was done by Scott Bradner.
RIP-2プロトコルの改善に協力してくれたIETF RIPワーキンググループに感謝します。距離ベクトルプロトコルに関する背景の議論のためのテキストの多くとRIPの操作の説明の一部は、C。ヘドリックによる「ルーティング情報プロトコル」[1]から引用されました。ドキュメントの最終編集の一部は、Scott Bradnerによって行われました。
Table of Contents
目次
1. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Limitations of the Protocol . . . . . . . . . . . . . . . . 5
3.3. Organization of this document . . . . . . . . . . . . . . . 6
3.4 Distance Vector Algorithms . . . . . . . . . . . . . . . . . 6
3.4.1 Dealing with changes in topology . . . . . . . . . . . . 12
3.4.2 Preventing instability . . . . . . . . . . . . . . . . . 13
3.4.3 Split horizon . . . . . . . . . . . . . . . . . . . . . . 15
3.4.4 Triggered updates . . . . . . . . . . . . . . . . . . . . 17
3.5 Protocol Specification . . . . . . . . . . . . . . . . . . 18
3.6 Message Format . . . . . . . . . . . . . . . . . . . . . . . 20
3.7 Addressing Considerations . . . . . . . . . . . . . . . . . 22
3.8 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Input Processing . . . . . . . . . . . . . . . . . . . . . . 25
3.9.1 Request Messages . . . . . . . . . . . . . . . . . . . . 25
3.9.2 Response Messages . . . . . . . . . . . . . . . . . . . . 26
3.10 Output Processing . . . . . . . . . . . . . . . . . . . . . 28
3.10.1 Triggered Updates . . . . . . . . . . . . . . . . . . . . 29
3.10.2 Generating Response Messages. . . . . . . . . . . . . . . 30
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 31
4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 34
5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . 35
6. Interaction between version 1 and version 2 . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 39
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プロトコルは、これらの日付後のRIP-1の実装以降、自律システムとIGP / EGPの相互作用、サブネット化[11]、および認証を考慮していません。ルーターはルートを決定する方法を知るためにサブネットマスクを必要とするため、サブネットマスクの欠如はルーターにとって特に深刻な問題です。 RIP-1ルートがネットワークルート（すべての非ネットワークビット0）の場合、サブネットマスクはネットワークマスクと同じです。ただし、一部の非ネットワークビットが設定されている場合、ルーターはサブネットマスクを判別できません。さらに悪いことに、ルーターは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は、Bellman-Ford（または距離ベクトル）アルゴリズムに基づくルーティングプロトコルです。このアルゴリズムは、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].
インターネットなどの国際ネットワークでは、ネットワーク全体で単一のルーティングプロトコルが使用されることはほとんどありません。むしろ、ネットワークは自律システム（AS）の集合として編成され、それぞれが一般に単一のエンティティーによって管理されます。各ASには独自のルーティング技術があり、AS間で異なる場合があります。 AS内で使用されるルーティングプロトコルは、Interior Gateway Protocol（IGP）と呼ばれます。外部ゲートウェイプロトコル（EGP）と呼ばれる別のプロトコルは、AS間でルーティング情報を転送するために使用されます。 RIPは中程度のサイズのASでIGPとして機能するように設計されています。より複雑な環境での使用は想定されていません。 RIP-1が適合することが期待されるコンテキストについては、Braden and 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は、距離ベクトルアルゴリズムと呼ばれるルーティングアルゴリズムのクラスの1つを使用します。著者が知っているこのクラスのアルゴリズムの最も初期の説明は、Ford and Fulkerson [8]にあります。このため、Ford-Fulkersonアルゴリズムと呼ばれることもあります。ベルマン・フォードという用語も使用されており、定式化はベルマンの方程式[4]に基づいているという事実から派生しています。このドキュメントのプレゼンテーションは、[5]に密接に基づいています。このドキュメントには、プロトコル仕様が含まれています。ルーティングアルゴリズムの数学の概要については、[1]を参照してください。このプロトコルで使用されている基本的なアルゴリズムは、ARPANETの1969年にコンピュータルーティングで使用されていました。ただし、このプロトコルの特定の祖先はゼロックスネットワークプロトコル内にあります。 PUPプロトコル[7]は、ゲートウェイ情報プロトコルを使用してルーティング情報を交換しました。 Xerox Network Systems（XNS）アーキテクチャーには、ルーティング情報プロトコル[9]という名前で、このプロトコルのやや更新されたバージョンが採用されました。バークレーのルーティングは、ルーティング情報プロトコルとほぼ同じです。XNSアドレスは、IPv4およびその他のタイプのアドレスを処理できるより一般的なアドレス形式に置き換えられ、ルーティングの更新は30秒ごとに1回に制限されています。この類似性のため、ルーティング情報プロトコル（または単にRIP）という用語は、XNSプロトコルとルーティングで使用されるプロトコルの両方を指すために使用されます。
RIP is intended for use within the IP-based Internet. The Internet is organized into a number of networks connected by special purpose gateways known as routers. The networks may be either point-to-point links or more complex networks such as Ethernet or token ring. Hosts and routers are presented with IP datagrams addressed to some host. Routing is the method by which the host or router decides where to send the datagram. It may be able to send the datagram directly to the destination, if that destination is on one of the networks that are directly connected to the host or router. However, the interesting case is when the destination is not directly reachable.
RIPは、IPベースのインターネット内での使用を目的としています。インターネットは、ルーターと呼ばれる専用ゲートウェイによって接続されたいくつかのネットワークに編成されています。ネットワークは、ポイントツーポイントリンクか、イーサネットやトークンリングなどのより複雑なネットワークのいずれかです。ホストとルーターには、一部のホスト宛のIPデータグラムが表示されます。ルーティングは、ホストまたはルーターがデータグラムの送信先を決定する方法です。宛先がホストまたはルーターに直接接続されているネットワークの1つにある場合、宛先に直接データグラムを送信できる場合があります。ただし、興味深いケースは、宛先に直接到達できない場合です。
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 protocol is limited to networks whose longest path (the network's diameter) is 15 hops. The designers believe that the basic protocol design is inappropriate for larger networks. Note that this statement of the limit assumes that a cost of 1 is used for each network. This is the way RIP is normally configured. If the system administrator chooses to use larger costs, the upper bound of 15 can easily become a problem.
- プロトコルは、最長パス（ネットワークの直径）が15ホップであるネットワークに制限されています。設計者は、基本的なプロトコル設計は大規模ネットワークには不適切であると考えています。この制限のステートメントでは、各ネットワークでコスト1が使用されることを前提としています。これは、RIPが通常構成されている方法です。システム管理者がより大きなコストを使用することを選択した場合、上限の15が問題になる可能性があります。
- The protocol depends upon "counting to infinity" to resolve certain unusual situations. (This will be explained in the next section.) If the system of networks has several hundred networks, and a routing loop was formed involving all of them, the resolution of the loop would require either much time (if the frequency of routing updates were limited) or bandwidth (if updates were sent whenever changes were detected). Such a loop would consume a large amount of network bandwidth before the loop was corrected. We believe that in realistic cases, this will not be a problem except on slow lines. Even then, the problem will be fairly unusual, since various precautions are taken that should prevent these problems in most cases.
- プロトコルは、特定の異常な状況を解決するために、「無限に数える」ことに依存しています。 （これについては次のセクションで説明します。）ネットワークのシステムに数百のネットワークがあり、それらすべてを含むルーティングループが形成された場合、ループの解決には長い時間が必要になります（ルーティングの更新頻度が制限付き）または帯域幅（変更が検出されたときに更新が送信された場合）。このようなループは、ループが修正される前に大量のネットワーク帯域幅を消費します。現実的なケースでは、これは低速回線以外では問題にならないと考えています。それでも、ほとんどの場合、これらの問題を防ぐためのさまざまな予防策が講じられているため、問題はかなり珍しいでしょう。
- This protocol uses fixed "metrics" to compare alternative routes. It is not appropriate for situations where routes need to be chosen based on real-time parameters such a measured delay, reliability, or load. The obvious extensions to allow metrics of this type are likely to introduce instabilities of a sort that the protocol is not designed to handle.
- このプロトコルは、固定された「メトリック」を使用して代替ルートを比較します。測定された遅延、信頼性、負荷などのリアルタイムのパラメーターに基づいてルートを選択する必要がある状況には適していません。このタイプのメトリックを許可する明らかな拡張は、プロトコルが処理するように設計されていない種類の不安定性をもたらす可能性があります。
The main body of this document is organized into two parts, which occupy the next two sections:
このドキュメントの本体は、次の2つのセクションを占める2つの部分に分かれています。
A conceptual development and justification of distance vector algorithms in general.
一般的な距離ベクトルアルゴリズムの概念的な開発と正当化。
The actual protocol description.
実際のプロトコルの説明。
Each of these two sections can largely stand on its own. Section 3.4 attempts to give an informal presentation of the mathematical underpinnings of the algorithm. Note that the presentation follows a "spiral" method. An initial, fairly simple algorithm is described. Then refinements are added to it in successive sections. Section 3.5 is the actual protocol description. Except where specific references are made to section 3.4, it should be possible to implement RIP entirely from the specifications given in section 3.5.
これらの2つのセクションはそれぞれ、それ自体で大部分を占めることができます。セクション3.4は、アルゴリズムの数学的基盤を非公式に提示することを試みています。プレゼンテーションは「スパイラル」方式に従うことに注意してください。最初のかなり単純なアルゴリズムについて説明します。次に、後続のセクションで詳細が追加されます。セクション3.5は実際のプロトコルの説明です。セクション3.4を具体的に参照する場合を除き、セクション3.5で指定された仕様から完全にRIPを実装できるはずです。
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の「インターネットモデル」では、これは主に、送信元ネットワークと宛先ネットワークの間の一連のルーターを見つけるという問題に限定されます。メッセージまたはデータグラムが単一のネットワークまたはサブネットに残っている限り、転送の問題はネットワーク固有のテクノロジーの責任です。たとえば、イーサネットとARPANETはそれぞれ、送信者がその1つのネットワーク内の指定された宛先と通信する方法を定義します。 IPルーティングは主に、あるネットワークの送信者から別のネットワークの送信先にメッセージを送信する必要がある場合に発生します。その場合、メッセージはネットワークを接続する1つ以上のルーターを通過する必要があります。ネットワークが隣接していない場合、メッセージはいくつかの介在するネットワークとそれらを接続するルーターを通過する可能性があります。メッセージが宛先と同じネットワーク上にあるルーターに到達すると、そのネットワーク独自のテクノロジーを使用して宛先に到達します。
Throughout this section, the term "network" is used generically to cover a single broadcast network (e.g., an Ethernet), a point to point line, or the ARPANET. The critical point is that a network is treated as a single entity by IP. Either no forwarding decision is necessary (as with a point to point line), or that forwarding is done in a manner that is transparent to IP, allowing IP to treat the entire network as a single fully-connected system (as with an Ethernet or the ARPANET). Note that the term "network" is used in a somewhat different way in discussions of IP addressing. We are using the term "network" here to refer to subnets in cases where subnet addressing is in use.
このセクション全体で、「ネットワーク」という用語は、単一のブロードキャストネットワーク（イーサネットなど）、ポイントツーポイント回線、またはARPANETを総称して使用します。重要な点は、ネットワークがIPによって単一のエンティティとして扱われることです。 （ポイントツーポイント回線の場合のように）転送を決定する必要がないか、転送がIPに対して透過的な方法で行われるため、IPはネットワーク全体を単一の完全に接続されたシステムとして扱うことができます（イーサネットまたはARPANET）。 「ネットワーク」という用語は、IPアドレッシングの説明では多少異なる方法で使用されることに注意してください。ここでは、「ネットワーク」という用語を使用して、サブネットアドレス指定が使用されている場合のサブネットを指します。
A number of different approaches for finding routes between networks are possible. One useful way of categorizing these approaches is on the basis of the type of information the routers need to exchange in order to be able to find routes. Distance vector algorithms are based on the exchange of only a small amount of information. Each entity (router or host) that participates in the routing protocol is assumed to keep information about all of the destinations within the system. Generally, information about all entities connected to one network is summarized by a single entry, which describes the route to all destinations on that network. This summarization is possible because as far as IP is concerned, routing within a network is invisible. Each entry in this routing database includes the next router to which datagrams destined for the entity should be sent. In addition, it includes a "metric" measuring the total distance to the entity. Distance is a somewhat generalized concept, which may cover the time delay in getting messages to the entity, the dollar cost of sending messages to it, etc. Distance vector algorithms get their name from the fact that it is possible to compute optimal routes when the only information exchanged is the list of these distances. Furthermore, information is only exchanged among entities that are adjacent, that is, entities that share a common network.
ネットワーク間のルートを見つけるためのさまざまなアプローチが可能です。これらのアプローチを分類する1つの有用な方法は、ルートを見つけることができるようにするためにルーターが交換する必要がある情報のタイプに基づいています。距離ベクトルアルゴリズムは、少量の情報の交換のみに基づいています。ルーティングプロトコルに参加する各エンティティ（ルーターまたはホスト）は、システム内のすべての宛先に関する情報を保持していると見なされます。一般に、1つのネットワークに接続されているすべてのエンティティに関する情報は、そのネットワーク上のすべての宛先へのルートを示す単一のエントリによって要約されます。 IPに関する限り、ネットワーク内のルーティングは見えないため、この要約が可能です。このルーティングデータベースの各エントリには、エンティティ宛てのデータグラムの送信先となる次のルーターが含まれています。さらに、エンティティまでの合計距離を測定する「メトリック」が含まれています。距離はやや一般化された概念であり、エンティティへのメッセージの取得の時間遅延、エンティティへのメッセージ送信のコストなどをカバーする可能性があります。距離ベクトルアルゴリズムは、最適なルートを計算できる場合にその名前を取得します。交換される情報のみがこれらの距離のリストです。さらに、情報は隣接するエンティティ、つまり共通のネットワークを共有するエンティティ間でのみ交換されます。
Although routing is most commonly based on information about networks, it is sometimes necessary to keep track of the routes to individual hosts. The RIP protocol makes no formal distinction between networks and hosts. It simply describes exchange of information about destinations, which may be either networks or hosts. (Note however, that it is possible for an implementor to choose not to support host routes. See section 3.2.) In fact, the mathematical developments are most conveniently thought of in terms of routes from one host or router to another. When discussing the algorithm in abstract terms, it is best to think of a routing entry for a network as an abbreviation for routing entries for all of the entities connected to that network. This sort of abbreviation makes sense only because we think of networks as having no internal structure that is visible at the IP level. Thus, we will generally assign the same distance to every entity in a given network.
ルーティングは最も一般的にはネットワークに関する情報に基づいていますが、個々のホストへのルートを追跡する必要がある場合があります。 RIPプロトコルは、ネットワークとホストを正式に区別しません。ネットワークまたはホストのいずれかである宛先に関する情報の交換について簡単に説明します。 （ただし、実装者がホストルートをサポートしないことを選択することもできます。セクション3.2を参照してください。）実際、数学的開発は、1つのホストまたはルーターから別のホストまたはルーターへのルートに関して最も便利に考えられます。アルゴリズムを抽象的な用語で説明する場合、ネットワークのルーティングエントリは、そのネットワークに接続されているすべてのエンティティのルーティングエントリの省略形と考えるのが最善です。この種の略語は、ネットワークがIPレベルで見える内部構造を持たないと考えているためにのみ意味があります。したがって、通常は、特定のネットワーク内のすべてのエンティティに同じ距離を割り当てます。
We said above that each entity keeps a routing database with one entry for every possible destination in the system. An actual implementation is likely to need to keep the following information about each destination:
上記のとおり、各エンティティは、システム内のすべての可能な宛先に対して1つのエントリを持つルーティングデータベースを保持しています。実際の実装では、各宛先について次の情報を保持する必要があります。
- address: in IP implementations of these algorithms, this will be the IP address of the host or network.
- address：これらのアルゴリズムのIP実装では、これはホストまたはネットワークのIPアドレスになります。
- router: the first router along the route to the destination.
- router：宛先へのルートに沿った最初のルーター。
- interface: the physical network which must be used to reach the first router.
- インターフェース：最初のルーターに到達するために使用する必要がある物理ネットワーク。
- metric: a number, indicating the distance to the destination.
- メトリック：目的地までの距離を示す数値。
- timer: the amount of time since the entry was last updated.
- timer：エントリが最後に更新されてからの時間。
In addition, various flags and other internal information will probably be included. This database is initialized with a description of the entities that are directly connected to the system. It is updated according to information received in messages from neighboring routers.
さらに、さまざまなフラグやその他の内部情報が含まれる可能性があります。このデータベースは、システムに直接接続されているエンティティの説明で初期化されます。隣接ルータからのメッセージで受信した情報に応じて更新されます。
The most important information exchanged by the hosts and routers is carried in update messages. Each entity that participates in the routing scheme sends update messages that describe the routing database as it currently exists in that entity. It is possible to maintain optimal routes for the entire system by using only information obtained from neighboring entities. The algorithm used for that will be described in the next section.
ホストとルーターによって交換される最も重要な情報は、更新メッセージで伝えられます。ルーティングスキームに参加する各エンティティは、そのエンティティに現在存在するルーティングデータベースを説明する更新メッセージを送信します。隣接するエンティティから取得した情報のみを使用して、システム全体の最適なルートを維持することが可能です。そのために使用されるアルゴリズムについては、次のセクションで説明します。
As we mentioned above, the purpose of routing is to find a way to get datagrams to their ultimate destinations. Distance vector algorithms are based on a table in each router listing the best route to every destination in the system. Of course, in order to define which route is best, we have to have some way of measuring goodness. This is referred to as the "metric".
前述のように、ルーティングの目的は、データグラムを最終的な宛先に到達させる方法を見つけることです。距離ベクトルアルゴリズムは、システム内のすべての宛先への最適なルートをリストする各ルーターのテーブルに基づいています。もちろん、どのルートが最適かを定義するために、良さを測定する何らかの方法が必要です。これは「メトリック」と呼ばれます。
In simple networks, it is common to use a metric that simply counts how many routers a message must go through. In more complex networks, a metric is chosen to represent the total amount of delay that the message suffers, the cost of sending it, or some other quantity which may be minimized. The main requirement is that it must be possible to represent the metric as a sum of "costs" for individual hops.
単純なネットワークでは、メッセージが通過しなければならないルーターの数を単純に数えるメトリックを使用するのが一般的です。より複雑なネットワークでは、メッセージが被る遅延の総量、メッセージの送信コスト、または最小化できるその他の量を表すメトリックが選択されます。主な要件は、個々のホップの「コスト」の合計としてメトリックを表すことが可能でなければならないことです。
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 and that the best routes start by going from i to those neighbors k for which d(i,k) + D(k,j) has the minimum value. (These things can be shown by induction on the number of steps in the routes.) Note that we can limit the second equation to k's that are immediate neighbors of i. For the others, d(i,k) is infinite, so the term involving them can never be the minimum.
D（i、i）= 0、すべてのi D（i、j）= min [d（i、k）+ D（k、j）]、それ以外の場合はkであり、iからそれらのネイバーに向かうことから最良のルートが始まるd（i、k）+ D（k、j）が最小値を持つk。 （これらは、ルートのステップ数の帰納法で示すことができます。）2番目の方程式を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の間のネットワークを通過するコストです。時々私はそのすべての隣人からの値を比較し、最小のものを選びます。
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.
[2]では、トポロジ変更がない場合に、このアルゴリズムが有限時間でD（i、j）の正しい推定値に収束することの証明が示されています。著者は、エンティティがお互いに情報を送信する順序について、または最小値が再計算されるときの仮定をほとんど行いません。基本的に、エンティティは更新の送信やメトリックの再計算を停止することはできず、ネットワークはメッセージを永遠に遅延させることはできません。 （ルーティングエンティティのクラッシュはトポロジの変更です。）また、それらの証明は、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.
上記のアルゴリズムの説明（および証明）は、各エンティティがそれぞれの近隣からの推定値のコピーを保持し、すべての近隣に対して時々最小化を行うことを前提としています。実際、実際の実装では必ずしもそうとは限りません。彼らは、これまでに見られた最良のメトリックと、それを送信したネイバーのアイデンティティを覚えているだけです。より良い（より小さな）メトリックが表示されると、この情報が置き換えられます。これにより、すべての近傍からのデータを保存する必要なく、最小値を段階的に計算できます。
There is one other difference between the algorithm as described in texts and those used in real protocols such as RIP: the description above would have each entity include an entry for itself, showing a distance of zero. In fact this is not generally done. Recall that all entities on a network are normally summarized by a single entry for the network. Consider the situation of a host or router G that is connected to network A. C represents the cost of using network A (usually a metric of one). (Recall that we are assuming that the internal structure of a network is not visible to IP, and thus the cost of going between any two entities on it is the same.) In principle, G should get a message from every other entity H on network A, showing a cost of 0 to get from that entity to itself. G would then compute C + 0 as the distance to H. Rather than having G look at all of these identical messages, it simply starts out by making an entry for network A in its table, and assigning it a metric of C. This entry for network A should be thought of as summarizing the entries for all other entities on network A. The only entity on A that can't be summarized by that common entry is G itself, since the cost of going from G to G is 0, not C. But since we never need those 0 entries, we can safely get along with just the single entry for network A. Note one other implication of this strategy: because we don't need to use the 0 entries for anything, hosts that do not function as routers don't need to send any update messages. Clearly hosts that don't function as routers (i.e., hosts that are connected to only one network) can have no useful information to contribute other than their own entry D(i,i) = 0. As they have only the one interface, it is easy to see that a route to any other network through them will simply go in that interface and then come right back out it. Thus the cost of such a route will be greater than the best cost by at least C. Since we don't need the 0 entries, non-routers need not participate in the routing protocol at all.
テキストで説明されているアルゴリズムとRIPなどの実際のプロトコルで使用されているアルゴリズムには、もう1つの違いがあります。上記の説明では、各エンティティにゼロの距離を示すエントリが含まれています。実際、これは一般的に行われていません。通常、ネットワーク上のすべてのエンティティは、ネットワークの単一のエントリによって要約されます。ネットワークAに接続されているホストまたはルーターGの状況を考えてみます。CはネットワークAの使用コストを表します（通常は1のメトリック）。 （ネットワークの内部構造はIPから見えないことを前提としているため、ネットワーク上の2つのエンティティ間を移動するコストは同じです。）原則として、Gは他のすべてのエンティティHからメッセージを取得する必要があります。ネットワークA、そのエンティティからそれ自体に到達するためのコスト0を示しています。次に、GはC + 0をHまでの距離として計算します。Gがこれらすべての同一のメッセージを確認するのではなく、GがテーブルにネットワークAのエントリを作成し、それにCのメトリックを割り当てることから始めます。ネットワークAは、ネットワークA上の他のすべてのエンティティのエントリを要約するものと考える必要があります。GからGに移動するコストが0であるため、共通エントリによって要約できないA上のエンティティはGのみです。 Cではありませんが、これらの0エントリは必要ないため、ネットワークAの単一のエントリだけで安全に対処できます。この戦略のもう1つの影響に注意してください。0エントリを使用する必要がないため、ホストルーターは更新メッセージを送信する必要がないため、機能しません。明らかに、ルーターとして機能しないホスト（つまり、1つのネットワークにのみ接続されているホスト）は、自身のエントリD（i、i）= 0以外の情報を提供することができません。インターフェースが1つしかないため、それらを介した他のネットワークへのルートは、単にそのインターフェイスに入り、その後すぐに戻ってくることが簡単にわかります。したがって、そのようなルートのコストは、少なくとも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はその宛先のメトリックの現在の見積もり（つまり、その宛先に到達するための総コスト）と、そのメトリックが基づいているデータを持つ隣接ルーターのIDを保持します。宛先が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.)
4.neこれまでの方法では、既存のメトリックが小さいメトリックが表示されるまで保持されるため、メトリックを下げる方法しかありません。最初の見積もりが低すぎる可能性があります。したがって、メトリックを増やす方法が必要です。次のルールを使用すれば十分であることがわかります。宛先への現在のルートにメトリック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プロトコルのステートメントではないことに注意してください。追加されるいくつかの改良点があります。）次の手順は、ルーティングプロトコルに参加するすべてのエンティティによって実行されます。これには、システム内のすべてのルーターが含まれている必要があります。ルーターではないホストも参加できます。
- Keep a table with an entry for every possible destination in the system. The entry contains the distance D to the destination, and the first router G on the route to that network. Conceptually, there should be an entry for the entity itself, with metric 0, but this is not actually included.
- システム内のすべての可能な宛先のエントリを持つテーブルを保持します。エントリには、宛先までの距離Dと、そのネットワークへのルート上の最初のルーターGが含まれています。概念的には、エンティティ自体のエントリがあり、メトリックは0ですが、実際には含まれていません。
- Periodically, send a routing update to every neighbor. The update is a set of messages that contain all of the information from the routing table. It contains an entry for each destination, with the distance shown to that destination.
- 定期的に、ルーティングアップデートをすべてのネイバーに送信します。更新は、ルーティングテーブルからのすべての情報を含むメッセージのセットです。これには、各目的地のエントリが含まれ、その目的地までの距離が表示されます。
- When a routing update arrives from a neighbor G', add the cost associated with the network that is shared with G'. (This should be the network over which the update arrived.) Call the resulting distance D'. Compare the resulting distances with the current routing table entries. If the new distance D' for N is smaller than the existing value D, adopt the new route. That is, change the table entry for N to have metric D' and router G'. If G' is the router from which the existing route came, i.e., G' = G, then use the new metric even if it is larger than the old one.
- ルーティング更新がネイバーG 'から到着したら、G'と共有されているネットワークに関連するコストを追加します。 （これは、更新が到着したネットワークでなければなりません。）結果の距離D 'を呼び出します。結果の距離を現在のルーティングテーブルエントリと比較します。 Nの新しい距離D 'が既存の値Dより小さい場合は、新しいルートを採用します。つまり、Nのテーブルエントリを変更して、メトリックD 'とルーターG'を設定します。 G 'が既存のルートの取得元のルーターである場合、つまりG' = Gの場合、古いメトリックよりも大きい場合でも、新しいメトリックを使用します。
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秒ごとに1回、すべてのネイバーに更新メッセージを送信します。ネットワークNの現在のルートがルーターGを使用しているとします。Gから180秒間応答がない場合は、ルーターがクラッシュしたか、ルーターに接続しているネットワークが使用できなくなったと考えられます。したがって、ルートを無効としてマークします。 Nへの有効なルートを持つ別のネイバーから連絡があると、有効なルートが無効なルートを置き換えます。 30秒ごとに各ネイバーからの応答を期待している場合でも、ルートをタイムアウトする前に180秒待機することに注意してください。残念ながら、メッセージはネットワークによって失われることがあります。したがって、1つのメッセージの欠落に基づいてルートを無効にすることは、おそらくお勧めできません。
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が使用されます。この値は、有効な最大メトリックよりも大きいため、通常「無限大」と呼ばれます。 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.
数学を拡張して、アクセスできなくなったルートを処理するのは簡単です。上記で提案された規約はそれを行います。 「無限」を表すために大きなメトリック値を選択します。この値は、実際のメトリックがこれほど大きくならないように十分に大きくする必要があります。この例では、値16を使用します。ネットワークにアクセスできなくなったとします。すぐに隣接するすべてのルーターがタイムアウトし、そのネットワークのメトリックを16に設定します。分析のために、すべての隣接ルーターは、コストをかけて、消失したネットワークに直接接続する新しいハードウェアを入手したと想定できます。これは消失したネットワークへの唯一の接続であるため、システム内の他のすべてのルーターは、これらのルーターの1つを経由する新しいルートに収束します。コンバージェンスが発生すると、すべてのルーターは、消失したネットワークに対して少なくとも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
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が気づいたときに始まります。簡単にするために、以下の図では、すべてのルーターが同時に更新を送信することを前提としています。このグラフは、各ルーターのルーティングテーブルに表示されるターゲットネットワークのメトリックを示しています。
time ------>
D: dir, 1 dir, 1 dir, 1 dir, 1 ... dir, 1 dir, 1 B: unreach C, 4 C, 5 C, 6 C, 11 C, 12 C: B, 3 A, 4 A, 5 A, 6 A, 11 D, 11 A: B, 3 C, 4 C, 5 C, 6 C, 11 C, 12
D：dir、1 dir、1 dir、1 dir、1 ... dir、1 dir、1 B：到達しない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
dir =直接接続されているunreach = unreachable
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に到達できると考えています。したがって、3のメトリックをリストする更新を送信し続けます。次の反復では、BはAまたはC経由でDに到達できると主張します。もちろん、できません。 AとCが主張しているルートはなくなったが、まだそれを知る方法がない。そして、B経由のルートがなくなったことに気付いたとしても、お互いに経由できるルートがあると考えています。すべての数学者が必然的に主張するように、最終的にシステムは収束します。しかし、それには時間がかかる場合があります。最悪の場合は、システムの一部からネットワークに完全にアクセスできなくなる場合です。その場合、メトリックは最終的に無限に達するまで、上記のようなパターンでゆっくりと増加する可能性があります。このため、この問題は「無限カウント」と呼ばれています。
You should now see why "infinity" is chosen to be as small as possible. If a network becomes completely inaccessible, we want counting to infinity to be stopped as soon as possible. Infinity must be large enough that no real route is that big. But it shouldn't be any bigger than required. Thus the choice of infinity is a tradeoff between network size and speed of convergence in case counting to infinity happens. The designers of RIP believed that the protocol was unlikely to be practical for networks with a diameter larger than 15.
「無限大」が可能な限り小さくなるように選択された理由が表示されます。ネットワークに完全にアクセスできなくなった場合は、可能な限り早く停止して無限にカウントする必要があります。インフィニティは、実際のルートがそれほど大きくないほど十分に大きくなければなりません。しかし、必要以上に大きくすべきではありません。したがって、無限大の選択は、無限大までカウントされる場合のネットワークサイズと収束速度とのトレードオフです。 RIPの設計者は、このプロトコルは直径が15よりも大きいネットワークには実用的ではないと考えていました。
There are several things that can be done to prevent problems like this. The ones used by RIP are called "split horizon with poisoned reverse", and "triggered updates".
このような問題を防ぐためにできることはいくつかあります。 RIPで使用されるものは、「有害な逆のスプリットホライズン」と「トリガーされた更新」と呼ばれます。
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に到達できると主張しています。これは、情報の送信先について少し注意することで防ぐことができます。特に、ルートが学習されたネイバーへの宛先ネットワークの到達可能性を主張することは決して役に立ちません。 「スプリットホライズン」は、ルートを取得したルータに送信されるアップデートにルートを含めることによって引き起こされる問題を回避するためのスキームです。 「単純なスプリットホライズン」スキームは、そのネイバーに送信されるアップデートで、そのネイバーから学習したルートを省略します。 「ポイズンリバースを使用したスプリットホライズン」には、そのようなルートが更新に含まれていますが、メトリックは無限に設定されています。
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を経由するルートを持っている場合、そのネットワーク上の他のルーターと通信しているときにDに到達できないことを示しているはずです。ネットワーク上の他のルーターはC自体に到達できます。 A経由でCに到達する必要はありません。Aの最適ルートが実際にC経由である場合、そのネットワーク上の他のルーターは、AがDに到達できることを知る必要はありません。これは幸いです。 for Cは、同じネットワーク上の他のすべてのルーターに使用できます。したがって、更新メッセージをブロードキャストで送信できます。
In general, split horizon with poisoned reverse is safer than simple split horizon. If two routers have routes pointing at each other, advertising reverse routes with a metric of 16 will break the loop immediately. If the reverse routes are simply not advertised, the erroneous routes will have to be eliminated by waiting for a timeout. However, poisoned reverse does have a disadvantage: it increases the size of the routing messages. Consider the case of a campus backbone connecting a number of different buildings. In each building, there is a router connecting the backbone to a local network. Consider what routing updates those routers should broadcast on the backbone network. All that the rest of the network really needs to know about each router is what local networks it is connected to. Using simple split horizon, only those routes would appear in update messages sent by the router to the backbone network. If split horizon with poisoned reverse is used, the router must mention all routes that it learns from the backbone, with metrics of 16. If the system is large, this can result in a large update message, almost all of whose entries indicate unreachable networks.
一般的に、ポイズンリバースのあるスプリットホライズンは、単純なスプリットホライズンよりも安全です。 2つのルーターが互いに向き合うルートを持っている場合、メトリックが16の逆ルートをアドバタイズすると、ループがただちに切断されます。リバースルートが単にアドバタイズされない場合、タイムアウトを待つことにより、誤ったルートを排除する必要があります。ただし、ポイズンリバースには欠点があります。ルーティングメッセージのサイズが大きくなります。複数の異なる建物を接続するキャンパスバックボーンの場合を考えます。各建物には、バックボーンをローカルネットワークに接続するルーターがあります。これらのルーターがバックボーンネットワークでブロードキャストする必要のあるルーティング更新を検討します。ネットワークの残りの部分が実際に各ルーターについて知る必要があるのは、接続されているローカルネットワークだけです。単純なスプリットホライズンを使用すると、これらのルートのみが、ルータからバックボーンネットワークに送信される更新メッセージに表示されます。ポイズンリバース付きのスプリットホライズンが使用されている場合、ルーターは、バックボーンから学習したすべてのルートをメトリック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のリバースルートをアドバタイズしても、追加情報はありません。 1つのブロードキャストネットワークに多くのルーターがある場合、これらの追加のエントリはかなりの帯域幅を使用する可能性があります。それらが存在する理由は、動的動作を改善するためです。トポロジーが変更された場合は、ルーターを経由してはならないルートと、収束を高速化できるルートについて言及します。ただし、状況によっては、ルーティングのオーバーヘッドを最小限に抑えるために、ネットワーク管理者がやや遅い収束を受け入れることを好む場合があります。したがって、インプリメンターは、ポイズンリバースを使用したスプリットホライズンではなく、単純なスプリットホライズンを実装するか、ネットワークマネージャが使用する動作を選択できるようにする構成オプションを提供できます。また、メトリック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.
ポイズンリバースを含むスプリットホライズンは、2つのルーターのみを含むルーティングループを防止します。ただし、3つのルーターが相互に欺瞞するパターンになる可能性は依然としてあります。たとえば、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.
残念ながら、物事はそれほど良くありません。トリガーされた更新が送信されている間、定期的な更新が同時に行われている可能性があります。トリガーされた更新をまだ受信していないルーターは、存在しないルートに基づいて情報を送信し続けます。トリガーされた更新がルーターを通過した後、まだ知られていないこれらのルーターの1つから通常の更新を受信する可能性があります。これにより、誤ったルートの孤立した残りが再確立される可能性があります。トリガーされた更新が迅速に行われる場合、これはほとんどありません。ただし、無限にカウントすることは可能です。
The router requirements RFC [11] specifies that all implementation of RIP must implement triggered update for deleted routes and may implement triggered updates for new routes or change of routes. RIP implementations must also limit the rate which of triggered updates may be trandmitted. (see section 3.10.1)
ルータ要件RFC [11]は、RIPのすべての実装が削除されたルートのトリガー更新を実装する必要があり、新しいルートまたはルートの変更のトリガー更新を実装する場合があることを指定しています。 RIP実装は、トリガーされた更新が送信されるレートを制限する必要もあります。 （セクション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を使用するルーターは、1つまたは複数のネットワークへのインターフェースを備えていると想定されます。これらは、直接接続されたネットワークと呼ばれます。プロトコルは、これらの各ネットワークに関する特定の情報へのアクセスに依存しています。その中で最も重要なのは、そのメトリックです。ネットワークのRIPメトリックは、1〜15の整数です。このプロトコルで指定されていない方法で設定されます。ただし、最大パス制限が15の場合、通常は1の値が使用されます。実装では、システム管理者が各ネットワークのメトリックを設定できるようにする必要があります。メトリックに加えて、各ネットワークにはIPv4宛先アドレスとサブネットマスクが関連付けられています。これらは、このプロトコルで指定されていない方法でシステム管理者によって設定されます。
Any host that uses RIP is assumed to have interfaces to one or more networks. These are referred to as its "directly-connected networks". The protocol relies on access to certain information about each of these networks. The most important is its metric or "cost". The metric of a network is an integer between 1 and 15 inclusive. It is set in some manner not specified in this protocol. Most existing implementations always use a metric of 1. New implementations should allow the system administrator to set the cost of each network. In addition to the cost, each network will have an IPv4 network number and a subnet mask associated with it. These are to be set by the system administrator in a manner not specified in this protocol.
RIPを使用するすべてのホストは、1つ以上のネットワークへのインターフェースを持っていると想定されます。これらは「直接接続されたネットワーク」と呼ばれます。プロトコルは、これらの各ネットワークに関する特定の情報へのアクセスに依存しています。最も重要なのは、そのメトリックまたは「コスト」です。ネットワークのメトリックは、1〜15の整数です。このプロトコルでは指定されていない方法で設定されます。ほとんどの既存の実装では、常に1のメトリックを使用します。新しい実装では、システム管理者が各ネットワークのコストを設定できるようにする必要があります。コストに加えて、各ネットワークには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を操作するシステム全体で到達可能なすべての宛先に対して1つのエントリがあります。各エントリには、少なくとも次の情報が含まれています。
- The IPv4 address of the destination.
- 宛先のIPv4アドレス。
- A metric, which represents the total cost of getting a datagram from the router to that destination. This metric is the sum of the costs associated with the networks that would be traversed to get to the destination.
- ルーターからその宛先にデータグラムを取得するための総コストを表すメトリック。このメトリックは、宛先に到達するために通過するネットワークに関連するコストの合計です。
- The IPv4 address of the next router along the path to the destination (i.e., the next hop). If the destination is on one of the directly-connected networks, this item is not needed.
- 宛先へのパスに沿った次のルーターのIPv4アドレス（つまり、次のホップ）。宛先が直接接続されたネットワークの1つにある場合、この項目は不要です。
- A flag to indicate that information about the route has changed recently. This will be referred to as the "route change flag."
- ルートに関する情報が最近変更されたことを示すフラグ。これを「ルート変更フラグ」と呼びます。
- Various timers associated with the route. See section 3.6 for more details on timers.
- ルートに関連付けられたさまざまなタイマー。タイマーの詳細については、セクション3.6を参照してください。
The entries for the directly-connected networks are set up by the router using information gathered by means not specified in this protocol. The metric for a directly-connected network is set to the cost of that network. As mentioned, 1 is the usual cost. In that case, the RIP metric reduces to a simple hop-count. More complex metrics may be used when it is desirable to show preference for some networks over others (e.g., to indicate of differences in bandwidth or reliability).
直接接続されたネットワークのエントリは、このプロトコルで指定されていない方法で収集された情報を使用して、ルーターによって設定されます。直接接続されたネットワークのメトリックは、そのネットワークのコストに設定されます。前述のように、1は通常のコストです。その場合、RIPメトリックは単純なホップカウントに減少します。帯域幅や信頼性の違いを示すためなど、一部のネットワークの優先度を他のネットワークより優先することが望ましい場合は、より複雑なメトリックを使用できます。
To support the extensions detailed in this document, each entry must additionally contain a subnet mask. The subnet mask allows the router (along with the IPv4 address of the destination) to identify the different subnets within a single network as well as the subnets masks of distant networks.
このドキュメントで説明されている拡張機能をサポートするには、各エントリにさらにサブネットマスクが含まれている必要があります。サブネットマスクを使用すると、ルーターは（宛先のIPv4アドレスと共に）単一のネットワーク内のさまざまなサブネットと、離れたネットワークのサブネットマスクを識別できます。
Implementors may also choose to allow the system administrator to enter additional routes. These would most likely be routes to hosts or networks outside the scope of the routing system. They are referred to as "static routes." Entries for destinations other than these initial ones are added and updated by the algorithms described in the following sections.
実装者は、システム管理者が追加のルートを入力できるようにすることもできます。これらは、ルーティングシステムの範囲外のホストまたはネットワークへのルートである可能性が最も高いです。それらは「静的ルート」と呼ばれます。これらの最初の宛先以外の宛先のエントリーは、以下のセクションで説明するアルゴリズムによって追加および更新されます。
In order for the protocol to provide complete information on routing, every router in the AS must participate in the protocol. In cases where multiple IGPs are in use, there must be at least one router which can leak routing information between the protocols.
プロトコルがルーティングに関する完全な情報を提供するためには、AS内のすべてのルーターがプロトコルに参加する必要があります。複数のIGPが使用されている場合、プロトコル間でルーティング情報をリークする可能性のあるルーターが少なくとも1つ必要です。
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を使用する各ルーターには、RIP-1 / RIP-2ポートであるUDPポート番号520でデータグラムを送受信するルーティングプロセスがあります。別のルーターの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) ~
| |
+---------------+---------------+---------------+---------------+
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) |
+---------------------------------------------------------------+
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.
フィールドサイズはオクテットで指定されます。特に指定のない限り、フィールドにはバイナリバイトがネットワークバイトオーダーで含まれ、最上位オクテットが最初（ビッグエンディアン）になります。各目盛りは1ビットを表します。
Every message contains a RIP header which consists of a command and a version number. This section of the document describes version 1 of the protocol; section 4 describes the version 2 extensions. The command field is used to specify the purpose of this message. The commands implemented in version 1 and 2 are:
すべてのメッセージには、コマンドとバージョン番号で構成されるRIPヘッダーが含まれています。ドキュメントのこのセクションでは、プロトコルのバージョン1について説明します。セクション4では、バージョン2の拡張機能について説明します。コマンドフィールドは、このメッセージの目的を指定するために使用されます。バージョン1および2に実装されているコマンドは次のとおりです。
1 - request A request for the responding system to send all or part of its routing table.
1-要求応答システムがそのルーティングテーブルのすべてまたは一部を送信するための要求。
2 - response A message containing all or part of the sender's routing table. This message may be sent in response to a request, or it may be an unsolicited routing update generated by the sender.
2-応答送信者のルーティングテーブルのすべてまたは一部を含むメッセージ。このメッセージは、要求に応じて送信される場合と、送信者によって生成された非送信請求ルーティング更新である場合があります。
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パケット形式は、さまざまなタイプのアドレスを区別しません。 「アドレス」というラベルの付いたフィールドには、次のいずれかを含めることができます。
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.
この「サブネットフィルタリング」は、サブネット化されたネットワークの「境界」にあるルーターによって実行されます。これらは、そのネットワークを他のネットワークに接続するルーターです。サブネット化されたネットワーク内では、各サブネットは個別のネットワークとして扱われます。各サブネットのルーティングエントリは、RIPによって循環されます。ただし、境界ルーターは、ネットワーク全体で1つのエントリのみを他のネットワークのノードに送信します。つまり、境界ルータは異なるネイバーに異なる情報を送信します。サブネット化されたネットワークに接続されているネイバーについては、サブネット番号を使用して、直接接続されているすべてのサブネットのリストを生成します。他のネットワークに接続されているネイバーの場合、ネットワーク全体の単一のエントリを作成し、そのネットワークに関連付けられているメトリックを示します。このメトリックは通常、ルーターが接続されているサブネットの最小メトリックです。
Similarly, border routers must not mention host routes for nodes within one of the directly-connected networks in messages to other networks. Those routes will be subsumed by the single entry for the network as a whole.
同様に、境界ルーターは、他のネットワークへのメッセージで、直接接続されたネットワークの1つ内のノードのホストルートに言及してはなりません。これらのルートは、ネットワーク全体の単一のエントリに含まれます。
The router requirements RFC [11] specifies that all implementation of RIP should support host routes but if they do not then they must ignore any received host routes.
ルータ要件RFC [11]は、RIPのすべての実装がホストルートをサポートする必要があることを指定していますが、サポートしていない場合、受信したホストルートを無視する必要があります。
The special address 0.0.0.0 is used to describe a default route. A default route is used when it is not convenient to list every possible network in the RIP updates, and when one or more closely-connected routers in the system are prepared to handle traffic to the networks that are not listed explicitly. These routers should create RIP entries for the address 0.0.0.0, just as if it were a network to which they are connected. The decision as to how routers create entries for 0.0.0.0 is left to the implementor. Most commonly, the system administrator will be provided with a way to specify which routers should create entries for 0.0.0.0; however, other mechanisms are possible. For example, an implementor might decide that any router which speaks BGP should be declared to be a default router. It may be useful to allow the network administrator to choose the metric to be used in these entries. If there is more than one default router, this will make it possible to express a preference for one over the other. The entries for 0.0.0.0 are handled by RIP in exactly the same manner as if there were an actual network with this address. System administrators should take care to make sure that routes to 0.0.0.0 do not propagate further than is intended. Generally, each autonomous system has its own preferred default 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更新ですべての可能なネットワークを一覧表示することが不都合な場合、およびシステム内の1つ以上の密接に接続されたルーターが、明示的に一覧表示されていないネットワークへのトラフィックを処理する準備ができている場合に使用されます。これらのルーターは、接続されているネットワークであるかのように、アドレス0.0.0.0のRIPエントリを作成する必要があります。ルーターが0.0.0.0のエントリを作成する方法に関する決定は、実装者に委ねられます。最も一般的には、システム管理者には0.0.0.0のエントリを作成するルーターを指定する方法が提供されます。ただし、他のメカニズムも可能です。たとえば、実装者は、BGPを話すすべてのルーターをデフォルトルーターとして宣言する必要があると決定する場合があります。ネットワーク管理者がこれらのエントリで使用されるメトリックを選択できるようにすると便利な場合があります。デフォルトのルーターが複数ある場合は、これにより、一方のルーターを他方のルーターよりも優先させることができます。 0.0.0.0のエントリは、このアドレスを持つ実際のネットワークが存在する場合とまったく同じ方法でRIPによって処理されます。システム管理者は、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秒のタイマーがシステムの処理負荷の影響を受けるたびに発生します。ブロードキャストネットワークで不要な衝突が発生する可能性があるため、更新メッセージが同期されることは望ましくありません。したがって、実装では次の2つの予防策のいずれかを実行する必要があります。
- The 30-second updates are triggered by a clock whose rate is not affected by system load or the time required to service the previous update timer.
- 30秒の更新は、システムの負荷や以前の更新タイマーの処理に必要な時間に影響されない速度のクロックによってトリガーされます。
- The 30-second timer is offset by a small random time (+/- 0 to 5 seconds) each time it is set. (Implementors may wish to consider even larger variation in the light of recent research results [10])
- 30秒タイマーは、設定されるたびに小さなランダム時間（+/- 0〜5秒）によってオフセットされます。 （実装者は、最近の研究結果[10]に照らして、さらに大きな変動を検討することを望む場合があります）
There are two timers associated with each route, a "timeout" and a "garbage-collection" time. Upon expiration of the timeout, the route is no longer valid; however, it is retained in the routing table for a short time so that neighbors can be notified that the route has been dropped. Upon expiration of the garbage-collection timer, the route is finally removed from the routing table.
各ルートには、「タイムアウト」と「ガベージコレクション」の2つのタイマーが関連付けられています。タイムアウトになると、ルートは無効になります。ただし、ルートがドロップされたことをネイバーに通知できるように、それはルーティングテーブルに短時間保持されます。ガベージコレクションタイマーが満了すると、ルートは最終的にルーティングテーブルから削除されます。
The timeout is initialized when a route is established, and any time an update message is received for the route. If 180 seconds elapse from the last time the timeout was initialized, the route is considered to have expired, and the deletion process described below begins for that route.
タイムアウトは、ルートが確立されたとき、およびルートの更新メッセージを受信したときに初期化されます。タイムアウトが最後に初期化されてから180秒が経過した場合、ルートは期限切れであると見なされ、そのルートに対して以下で説明する削除プロセスが開始されます。
Deletions can occur for one of two reasons: the timeout expires, or the metric is set to 16 because of an update received from the current router (see section 3.7.2 for a discussion of processing updates from other routers). In either case, the following events happen:
削除は、タイムアウトが発生するか、現在のルーターから更新を受信したためにメトリックが16に設定される2つの理由のいずれかで発生します（他のルーターからの更新の処理については、セクション3.7.2を参照）。どちらの場合も、次のイベントが発生します。
- The garbage-collection timer is set for 120 seconds.
- ガベージコレクションタイマーは120秒に設定されています。
- The metric for the route is set to 16 (infinity). This causes the route to be removed from service.
- ルートのメトリックは16（無限）に設定されます。これにより、ルートがサービスから削除されます。
- The route change flag is set to indicate that this entry has been changed.
- ルート変更フラグは、このエントリが変更されたことを示すために設定されます。
- The output process is signalled to trigger a response.
- 出力プロセスは、応答をトリガーするように通知されます。
Until the garbage-collection timer expires, the route is included in all updates sent by this router. When the garbage-collection timer expires, the route is deleted from the routing table.
ガベージコレクションタイマーが期限切れになるまで、ルートはこのルーターによって送信されるすべての更新に含まれます。ガベージコレクションタイマーが期限切れになると、ルートはルーティングテーブルから削除されます。
Should a new route to this network be established while the garbage-collection timer is running, the new route will replace the one that is about to be deleted. In this case the garbage-collection timer must be cleared.
ガベージコレクションタイマーの実行中にこのネットワークへの新しいルートが確立された場合、削除しようとしているルートが新しいルートに置き換えられます。この場合、ガベージコレクションタイマーをクリアする必要があります。
Triggered updates also use a small timer; however, this is best described in section 3.9.1.
トリガーされた更新も小さなタイマーを使用します。ただし、これはセクション3.9.1で最もよく説明されています。
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-2のマルチキャスト）として、RIPポートから、起動したばかりのルーターからルーティングテーブルにできるだけ早く入力しようとしているルーターによって送信されます。ただし、1つのルーターのみのルーティングテーブルが必要な状況（ルーターの監視など）がある場合があります。この場合、リクエストは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.
リクエストはエントリごとに処理されます。エントリがない場合、応答はありません。特別なケースが1つあります。リクエストにエントリが1つだけあり、そのアドレスファミリIDがゼロで、メトリックが無限（16）である場合、これはルーティングテーブル全体を送信するリクエストです。その場合、出力プロセスを呼び出して、ルーティングテーブルを要求元のアドレス/ポートに送信します。この特別な場合を除いて、処理は非常に簡単です。要求内のRTEのリストを1つずつ調べます。各エントリについて、ルーターのルーティングデータベースで宛先を検索し、ルートがある場合は、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:
応答は、いくつかの理由のいずれかで受信されます。
- response to a specific query - regular update (unsolicited response) - triggered update caused by a route change
- 特定のクエリへの応答-定期的な更新（一方的な応答）-ルートの変更によって引き起こされた更新
Processing is the same no matter why the Response was generated.
応答が生成された理由に関係なく、処理は同じです。
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送信元アドレスをチェックして、データグラムが有効なネイバーからのものかどうかを確認する必要があります。データグラムのソースは、直接接続されたネットワーク上にある必要があります。応答がルーター自身のアドレスの1つからのものであるかどうかを確認することも確認する価値があります。ブロードキャストネットワーク上のインターフェイスは、独自のブロードキャスト/マルチキャストのコピーをすぐに受信できます。ルーターが独自の出力を新しい入力として処理する場合、混乱が生じる可能性があるため、そのようなデータグラムは無視する必要があります。
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を1つずつ処理します。ここでも、検証を開始することから始めます。不正なメトリックやその他のフォーマットエラーは通常、近隣の動作に問題があることを示しており、おそらく管理者の注意を引く必要があります。たとえば、メトリックが無限より大きい場合は、エントリを無視してイベントをログに記録します。基本的な検証テストは次のとおりです。
- is the destination address valid (e.g., unicast; not net 0 or 127) - is the metric valid (i.e., between 1 and 16, inclusive)
- 有効な宛先アドレスです（例：ユニキャスト、net 0または127ではありません）-有効なメトリックです（つまり、1から16まで）
If any check fails, ignore that entry and proceed to the next. Again, logging the error is probably a good idea.
チェックに失敗した場合は、そのエントリを無視して次へ進みます。繰り返しますが、エラーをログに記録することをお勧めします。
Once the entry has been validated, update the metric by adding the cost of the network on which the message arrived. If the result is greater than infinity, use infinity. That is,
エントリが検証されたら、メッセージが到着したネットワークのコストを追加してメトリックを更新します。結果が無限大より大きい場合は、無限大を使用します。あれは、
metric = MIN (metric + cost, infinity)
メトリック= MIN（メトリック+コスト、無限大）
Now, check to see whether there is already an explicit route for the destination address. If there is no such route, add this route to the routing table, unless the metric is infinity (there is no point in adding a route which is unusable). Adding a route to the routing table consists of:
次に、宛先アドレスの明示的なルートがすでに存在するかどうかを確認します。そのようなルートがない場合は、メトリックが無限でない限り、このルートをルーティングテーブルに追加します（使用できないルートを追加しても意味がありません）。ルーティングテーブルへのルートの追加は、以下で構成されます。
- Setting the destination address to the destination address in the RTE
- 宛先アドレスをRTEの宛先アドレスに設定する
- Setting the metric to the newly calculated metric (as described above)
- メトリックを新しく計算されたメトリックに設定する（上記のとおり）
- Set the next hop address to be the address of the router from which the datagram came
- ネクストホップアドレスを、データグラムの送信元のルーターのアドレスに設定します
- Initialize the timeout for the route. If the garbage-collection timer is running for this route, stop it (see section 3.6 for a discussion of the timers)
- ルートのタイムアウトを初期化します。このルートでガベージコレクションタイマーが実行されている場合は、それを停止します（タイマーの説明については、セクション3.6を参照してください）。
- Set the route change flag
- ルート変更フラグを設定する
- Signal the output process to trigger an update (see section 3.8.1)
- 更新をトリガーするように出力プロセスに通知します（セクション3.8.1を参照）
If there is an existing route, compare the next hop address to the address of the router from which the datagram came. If this datagram is from the same router as the existing route, reinitialize the timeout. Next, compare the metrics. If the datagram is from the same router as the existing route, and the new metric is different than the old one; or, if the new metric is lower than the old one; do the following actions:
既存のルートがある場合は、ネクストホップアドレスを、データグラムの送信元のルーターのアドレスと比較します。このデータグラムが既存のルートと同じルーターからのものである場合は、タイムアウトを再初期化します。次に、メトリックを比較します。データグラムが既存のルートと同じルーターからのものであり、新しいメトリックが古いものと異なる場合。または、新しいメトリックが古いメトリックよりも低い場合。次のアクションを実行します。
- Adopt the route from the datagram (i.e., put the new metric in and adjust the next hop address, if necessary).
- データグラムからルートを採用します（つまり、新しいメトリックを入力し、必要に応じてネクストホップアドレスを調整します）。
- Set the route change flag and signal the output process to trigger an update
- ルート変更フラグを設定し、更新をトリガーするように出力プロセスに通知します
- If the new metric is infinity, start the deletion process (described above); otherwise, re-initialize the timeout
- 新しいメトリックが無限の場合は、削除プロセス（上記）を開始します。それ以外の場合は、タイムアウトを再初期化します
If the new metric is infinity, the deletion process begins for the route, which is no longer used for routing packets. Note that the deletion process is started only when the metric is first set to infinity. If the metric was already infinity, then a new deletion process is not started.
新しいメトリックが無限大の場合、ルートの削除プロセスが開始され、パケットのルーティングには使用されなくなります。削除プロセスは、メトリックが最初に無限に設定されたときにのみ開始されることに注意してください。メトリックがすでに無限大だった場合、新しい削除プロセスは開始されません。
If the new metric is the same as the old one, it is simplest to do nothing further (beyond re-initializing the timeout, as specified above); but, there is a heuristic which could be applied. Normally, it is senseless to replace a route if the new route has the same metric as the existing route; this would cause the route to bounce back and forth, which would generate an intolerable number of triggered updates. However, if the existing route is showing signs of timing out, it may be better to switch to an equally-good alternative route immediately, rather than waiting for the timeout to happen. Therefore, if the new metric is the same as the old one, examine the timeout for the existing route. If it is at least halfway to the expiration point, switch to the new route. This heuristic is optional, but highly recommended.
新しいメトリックが古いメトリックと同じである場合、それ以上何もしないのが最も簡単です（上記のようにタイムアウトを再初期化する以外に）。しかし、適用できるヒューリスティックがあります。通常、新しいルートが既存のルートと同じメトリックを持つ場合、ルートを置き換えることは意味がありません。これにより、ルートが前後に跳ね返り、許容できない数のトリガーされた更新が生成されます。ただし、既存のルートがタイムアウトの兆候を示している場合は、タイムアウトが発生するのを待たずに、すぐに同等の良好な代替ルートに切り替える方が適切な場合があります。したがって、新しいメトリックが古いメトリックと同じである場合は、既存のルートのタイムアウトを調べます。有効期限の半分以上の場合は、新しいルートに切り替えます。このヒューリスティックはオプションですが、強くお勧めします。
Any entry that fails these tests is ignored, as it is no better than the current route.
これらのテストに失敗したエントリは無視されます。現在のルートよりも優れていないためです。
This section describes the processing used to create response messages that contain all or part of the routing table. This processing may be triggered in any of the following ways:
このセクションでは、ルーティングテーブルのすべてまたは一部を含む応答メッセージを作成するために使用される処理について説明します。この処理は、次のいずれかの方法でトリガーされます。
- By input processing, when a Request is received (this Response is unicast to the requestor; see section 3.7.1)
- 入力処理により、リクエストを受信したとき（このレスポンスはリクエスタにユニキャストされます。セクション3.7.1を参照）
- By the regular routing update (broadcast/multicast every 30 seconds) router.
- 通常のルーティング更新（30秒ごとのブロードキャスト/マルチキャスト）ルーター。
- By triggered updates (broadcast/multicast when a route changes) 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のマルチキャスト）されます。したがって、直接接続されたネットワークごとに1つの応答が準備され、適切なアドレス（直接またはブロードキャスト/マルチキャスト）に送信されます。ほとんどの場合、これはすべての隣接ルーターに到達します。ただし、これでは不十分な場合もあります。これには、ブロードキャストネットワークではないネットワーク（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.
トリガーされた更新には、2つの理由で特別な処理が必要です。まず、トリガーされた更新により、容量が制限されているネットワークや、ルーターが多数あるネットワークに過度の負荷がかかることが経験上示されています。したがって、このプロトコルでは、トリガーされた更新の頻度を制限するための規定を実装者が含める必要があります。トリガーされた更新が送信された後、1〜5秒のランダムな間隔でタイマーを設定する必要があります。タイマーが期限切れになる前に更新をトリガーする他の変更が発生した場合、タイマーが期限切れになると単一の更新がトリガーされます。その後、タイマーは1〜5秒のランダムな値にリセットされます。トリガーされた更新が送信される時間までに通常の更新が予定されている場合は、トリガーされた更新を抑制する必要があります。
Second, triggered updates do not need to include the entire routing table. In principle, only those routes which have changed need to be included. Therefore, messages generated as part of a triggered update must include at least those routes that have their route change flag set. They may include additional routes, at the discretion of the implementor; however, sending complete routing updates is strongly discouraged. When a triggered update is processed, messages should be generated for every directly-connected network. Split Horizon processing is done when generating triggered updates as well as normal updates (see section 3.9). If, after Split Horizon processing for a given network, a changed route will appear unchanged on that network (e.g., it appears with an infinite metric), the route need not be sent. If no routes need be sent on that network, the update may be omitted. Once all of the triggered updates have been generated, the route change flags should be cleared.
次に、トリガーされた更新にルーティングテーブル全体を含める必要はありません。原則として、変更されたルートのみを含める必要があります。したがって、トリガーされた更新の一部として生成されるメッセージには、少なくともルート変更フラグが設定されているルートが含まれている必要があります。実装者の裁量で、追加のルートを含めることができます。ただし、完全なルーティング更新を送信することは強くお勧めしません。トリガーされた更新が処理されると、直接接続されているすべてのネットワークに対してメッセージが生成されます。スプリットホライズン処理は、トリガーされた更新と通常の更新を生成するときに行われます（セクション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に設定します。送信するバージョンを決定するメカニズムは実装固有です。ただし、これが要求に対する応答である場合、応答バージョンは要求バージョンと一致する必要があります。コマンドをResponseに設定します。 「ゼロでなければならない」というラベルの付いたバイトをゼロに設定します。 RTEの入力を開始します。応答には25 RTEの制限があることを思い出してください。それ以上ある場合は、現在の応答を送信して、新しい応答を開始します。応答を構成するデータグラムの数に制限はありません。
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.4を参照）。 RIP-2の20オクテットルートエントリ（RTE）の形式は次のとおりです。
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Identifier (2) | Route Tag (2) |
+-------------------------------+-------------------------------+
| IP Address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
+---------------------------------------------------------------+
| Next Hop (4) |
+---------------------------------------------------------------+
| Metric (4) |
+---------------------------------------------------------------+
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.4で定義された意味を持っています。バージョンフィールドは、認証を使用するか、新しく定義されたフィールドのいずれかに情報を運ぶRIPメッセージのバージョン番号2を指定します。
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オクテットフィールドは1つしかないため、および適切な認証方式では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) ~
+---------------------------------------------------------------+
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.
Route Tag（RT）フィールドは、ルートに割り当てられた属性であり、ルートで保存および再アドバタイズする必要があります。ルートタグの使用目的は、「内部」RIPルート（RIPルーティングドメイン内のネットワークのルート）を、EGPまたは別のIGPからインポートされた「外部」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ルーティングエントリの情報を聞いて操作できるインターフェイスでは、次のルールが適用されます。
1) information internal to one network must never be advertised into another network,
1）1つのネットワーク内部の情報を別のネットワークに決して宣伝してはなりません。
2) information about a more specific subnet may not be advertised where RIP-1 routers would consider it a host route, and
2）RIP-1ルーターがそれをホストルートと見なす場合、より具体的なサブネットに関する情報はアドバタイズされない可能性があります。
3) supernet routes (routes with a netmask less specific than the "natural" network mask) must not be advertised where they could be misinterpreted by RIP-1 routers.
3）スーパーネットルート（「自然な」ネットワークマスクよりも具体性の低いネットマスクを持つルート）は、RIP-1ルーターによって誤って解釈される可能性がある場所でアドバタイズしてはなりません。
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.
Next Hopフィールドの目的は、システム内の余分なホップを介してルーティングされるパケットを排除することです。これは、RIPがネットワーク上のすべてのルーターで実行されていない場合に特に役立ちます。簡単な例を付録Aに示します。NextHopは「助言」フィールドであることに注意してください。つまり、提供された情報が無視されると、おそらく最適ではないが絶対的に有効なルートが使用される可能性があります。受信したネクストホップに直接到達できない場合は、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メッセージが破棄されること、ゼロでなければならない（MBZ）フィールドがゼロ以外の場合にバージョン1のRIPメッセージが破棄されること、および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.
互換性スイッチは2つの理由で必要です。まず、上記のRFC [1]に従わないRIP-1の実装があります。第2に、マルチキャストを使用すると、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メッセージはマルチキャストです。 「none」は、RIPメッセージの送信を無効にします。デフォルト設定を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.
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.
互換性の問題については、人々が要求している項目が1つあります。それは、無限大の増加です。これを実行できない主な理由は、下位互換性に違反するためです。より大きな無限大は明らかに古いバージョンの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.
一部の実装では、隣接するルートのグループを自動的に1つのエントリに要約しようとしますが、その目的は、エントリの総数を減らすことです。これは自動要約と呼ばれます。
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]で説明されているメカニズムによってさらに強化されます。
Appendix A
付録A
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を使用することを選択した1つの管理（キャンパスなど）の下にある「内部」ルーターであると想定します。一方、XR1、XR2、およびXR3は別々の管理下にあり（キャンパスがメンバーとなっている地域ネットワークなど）、他のルーティングプロトコル（OSPFなど）を使用しています。 XR1、XR2、およびXR3は相互にルーティング情報を交換するため、ネットワークN1およびN2への最良のルートはXR1を経由し、N3、N4、およびN5はXR2を経由し、N6およびN7はXR3を経由します。 Next Hopフィールドを正しく（N3 / N4 / N5のXR2に、N6 / N7のXR3に）設定することにより、XR1を介した追加のホップなしでルーティングを行うために、XR1のみがIR1 / IR2 / IR3でRIP-2ルートを交換する必要があります。ネクストホップがない場合（たとえば、RIP-1が使用されている場合）、XR2とXR3もRIP-2プロトコルに参加して、余分なホップを排除する必要があります。
References
参考文献
[1] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988.
[1] Hedrick、C。、「ルーティング情報プロトコル」、STD 34、RFC 1058、ラトガース大学、1988年6月。
[2] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1389, January 1993.
[2] Malkin、G。、およびF. Baker、「RIPバージョン2 MIB拡張」、RFC 1389、1993年1月。
[3] Baker, F., and R. Atkinson, "RIP-II MD5 Authentication", RFC 2082, January 1997.
[3] ベイカー、F。、およびR.アトキンソン、「RIP-II MD5認証」、RFC 2082、1997年1月。
[4] Bellman, R. E., "Dynamic Programming", Princeton University Press, Princeton, N.J., 1957.
[4] ベルマン、R。E.、「ダイナミックプログラミング」、プリンストン大学出版局、プリンストン、ニュージャージー州、1957年。
[5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice-Hall, Englewood Cliffs, N.J., 1987.
[5] Bertsekas、D。P.、および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.
[6] Braden、R。、およびPostel、J。、「インターネットゲートウェイの要件」、STD 4、RFC 1009、1987年6月。
[7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., "Pup: An Internetwork Architecture", IEEE Transactions on Communications, April 1980.
[7] Boggs、D。R.、Shoch、J。F.、Taft、E。A.、およびMetcalfe、R。M。、「Pup：An Internetwork Architecture」、IEEE Transactions on Communications、1980年4月。
[8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks", Princeton University Press, Princeton, N.J., 1962.
[8] フォード、L。R.ジュニア、およびフルカーソン、D。R。、「Flows in Networks」、プリンストン大学出版局、プリンストン、ニュージャージー州、1962年。
[9] Xerox Corp., "Internet Transport Protocols", Xerox System Integration Standard XSIS 028112, December 1981.
[9] Xerox Corp。、「Internet Transport Protocols」、Xerox System Integration Standard XSIS 028112、1981年12月。
[10] Floyd, S., and V. Jacobson, "The synchronization of Periodic Routing Messages," ACM Sigcom '93 symposium, September 1993.
[10] フロイド、S。、およびV.ジェイコブソン、「定期的なルーティングメッセージの同期」、ACM Sigcom '93シンポジウム、1993年9月。
[11] Baker, F., "Requirements for IP Version 4 Routers." RFC 1812, June 1995.
[11] ベイカー、F。、「IPバージョン4ルーターの要件」 RFC 1812、1995年6月。
Author's Address
著者のアドレス
Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 01821
Gary Scott Malkin Bay Networks 8 Federal Street Billerica、MA 01821
Phone: (978) 916-4237 EMail: gmalkin@baynetworks.com
電話：（978）916-4237メール：gmalkin@baynetworks.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。