RFC1723 日本語訳
1723 RIP Version 2 - Carrying Additional Information. G. Malkin. November 1994. (Format: TXT=18597 bytes) (Obsoletes RFC1388) (Obsoleted by RFC2453) (Updates RFC1058) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Malkin Request for Comments: 1723 Xylogics, Inc. Obsoletes: 1388 November 1994 Updates: 1058 Category: Standards Track
コメントを求めるワーキンググループG.マルキンの要求をネットワークでつないでください: 1723 Xylogics Inc.は以下を時代遅れにします。 1388 1994年11月は以下をアップデートします。 1058年のカテゴリ: 標準化過程
RIP Version 2
Carrying Additional Information
追加情報を運ぶバージョン2をコピーしてください。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies an extension of the Routing Information Protocol (RIP), as defined in [1,2], to expand the amount of useful information carried in RIP messages and to add a measure of security. This memo obsoletes RFC 1388, which specifies an update to the "Routing Information Protocol" STD 34, RFC 1058.
このドキュメントはルーティング情報プロトコル(RIP)の拡大を指定します、RIPメッセージで運ばれた役に立つ情報の量を広げて、セキュリティの基準を加えるために[1、2]で定義されるように。 このメモはRFC1388を時代遅れにします。(RFCは「ルーティング情報プロトコル」STD34、RFC1058にアップデートを指定します)。
The RIP-2 protocol analysis is documented in RFC 1721 [4].
RIP-2プロトコル分析はRFC1721[4]に記録されます。
The RIP-2 applicability statement is document in RFC 1722 [5].
RIP-2適用性証明はRFC1722[5]のドキュメントです。
The RIP-2 MIB description is defined in RFC 1724 [3]. This memo obsoletes RFC 1389.
RIP-2 MIB記述はRFC1724[3]で定義されます。 このメモはRFC1389を時代遅れにします。
Acknowledgements
承認
I would like to thank the IETF ripv2 Working Group for their help in improving the RIP-2 protocol.
彼らの助けについてRIP-2プロトコルを改良する際にIETF ripv2作業部会に感謝申し上げます。
Malkin [Page 1] RFC 1723 RIP Version 2 November 1994
マルキン[1ページ]RFC1723はバージョン1994年11月2日を裂きます。
Table of Contents
目次
1. Justification . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 6 4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 7 4.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. 正当化. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 潮境. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 拡大. . . . . . . . . . . . . . . . . . . . . . 3 3.1認証. . . . . . . . . . . . . . . . . . . . . . . 4 3.2ルートタグ. . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3サブネットマスク. . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4次のホップ. . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5マルチキャスティング. . . . . . . . . . . . . . . . . . . . . . . . 5 3.6質問. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4を議定書の中で述べてください。 互換性. . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1互換性スイッチ. . . . . . . . . . . . . . . . . . . . 6 4.2認証. . . . . . . . . . . . . . . . . . . . . . . 6 4.3の、より大きい無限. . . . . . . . . . . . . . . . . . . . . . . 7 4.4Addresslessは.7 5をリンクします。 作者の.8の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8のものが.9に記述するセキュリティ問題. . . . . . . . . . . . . . . . . . . . 7付録
1. Justification
1. 正当化
With the advent of OSPF and IS-IS, there are those who believe that RIP is obsolete. While it is true that the newer IGP routing protocols are far superior to RIP, RIP does have some advantages. Primarily, in a small network, RIP has very little overhead in terms of bandwidth used and configuration and management time. RIP is also very easy to implement, especially in relation to the newer IGPs.
そして、OSPFの到来、-、RIPが時代遅れであると信じている人がいます。 RIPより新しいIGPルーティング・プロトコルがはるかに優れているのが、本当である間、RIPには、いくつかの利点があります。 主として、小さいネットワークでは、RIPはほとんど、そして、帯域幅に関するオーバーヘッドが使用しなかった構成、および管理時間を持っています。 また、RIPは特により新しいIGPsと関連して非常に実行しやすいです。
Additionally, there are many, many more RIP implementations in the field than OSPF and IS-IS combined. It is likely to remain that way for some years yet.
そして、さらに、多くの、より多くのRIP実現がOSPFよりその分野にある、-、結合されています。 それはそのように数年間まだ残っていそうです。
Given that RIP will be useful in many environments for some period of time, it is reasonable to increase RIP's usefulness. This is especially true since the gain is far greater than the expense of the change.
RIPが多くの環境でいつかの期間の役に立つなら、RIPの有用性を増加させるのは妥当です。 利得が変化の費用よりはるかにすばらしいので、これは特に本当です。
2. Current RIP
2. 潮境
The current RIP 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メッセージはルータがネットワークを通してメッセージを発送するのに必要な最小量の情報量を含んでいます。 また、それは起源のために多量の未使用のスペースを含んでいます。
The current RIP protocol does not consider autonomous systems and IGP/EGP interactions, subnetting, and authentication since implementations of these postdate RIP. The lack of subnet masks is a
これらの実現がRIPに先日付を書くので、現在のRIPプロトコルは、自律システムとIGP/EGPが相互作用と、サブネッティングと、認証であると考えません。 サブネットマスクの不足はaです。
Malkin [Page 2] RFC 1723 RIP Version 2 November 1994
マルキン[2ページ]RFC1723はバージョン1994年11月2日を裂きます。
particularly serious problem for routers since they need a subnet mask to know how to determine a route. If a RIP 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 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ルートがネットワークルート(すべての非ネットワークビット0)であるなら、サブネットマスクはネットワークマスクと等しいです。 しかしながら、いくつかの非ネットワークビットが設定されるなら、ルータはサブネットマスクを決定できません。 よりひどく、それでも、ルータは、RIPルートがサブネットルートかそれともホストルートであるかを決定できません。 現在、いくつかのルータが、単にルートが学習されたインタフェースのサブネットマスクを選んで、それからルートタイプを決定します。
3. Protocol Extensions
3. プロトコル拡大
This document 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 first four octets of a RIP message contain the RIP header. The remainder of the message is composed of 1 - 25 route entries (20 octets each). The new RIP message format is:
RIPメッセージの最初の4つの八重奏がRIPヘッダーを含んでいます。 メッセージの残りは1--25のルートエントリー(それぞれ20の八重奏)で構成されます。 新しい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 |
+---------------+---------------+-------------------------------+
| Address Family Identifier (2) | Route Tag (2) |
+-------------------------------+-------------------------------+
| IP Address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
+---------------------------------------------------------------+
| Next Hop (4) |
+---------------------------------------------------------------+
| Metric (4) |
+---------------------------------------------------------------+
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コマンド(1)| バージョン(1)| 未使用| +---------------+---------------+-------------------------------+ | アドレス家族識別子(2)| ルートタグ(2)| +-------------------------------+-------------------------------+ | IPアドレス(4)| +---------------------------------------------------------------+ | サブネットマスク(4)| +---------------------------------------------------------------+ | 次のホップ(4)| +---------------------------------------------------------------+ | メートル法の(4)| +---------------------------------------------------------------+
The Command, Address Family Identifier (AFI), IP Address, and Metric all have the meanings defined in RFC 1058. The Version field will specify version number 2 for RIP messages which use authentication or carry information in any of the newly defined fields. The contents of the unused field (two octets) shall be ignored.
Command、Address Family Identifier(AFI)、IP Address、およびMetricには、RFC1058で定義された意味がすべてあります。 バージョン分野は新たに定義された分野のいずれでも認証を使用するか、または情報を運ぶRIPメッセージのバージョンNo.2を指定するでしょう。 未使用の分野(2つの八重奏)のコンテンツは無視されるものとします。
All fields are coded in IP network byte order (big-endian).
すべての分野がIPネットワークバイトオーダー(ビッグエンディアン)でコード化されます。
Malkin [Page 3] RFC 1723 RIP Version 2 November 1994
マルキン[3ページ]RFC1723はバージョン1994年11月2日を裂きます。
3.1 Authentication
3.1 認証
Since authentication is a per message function, and since there is only one 2-octet field available in the message header, and since any reasonable authentication scheme will require more than two octets, the authentication scheme for RIP version 2 will use the space of an entire RIP entry. If the Address Family Identifier of the first (and only the first) entry in the message is 0xFFFF, then the remainder of the entry contains the authentication. This means that there can be, at most, 24 RIP entries in the remainder of the message. If authentication is not in use, then no entries in the message should have an Address Family Identifier of 0xFFFF. A RIP message which contains an authentication entry would begin with the following format:
メッセージ機能あたり認証がaであり、メッセージヘッダーで利用可能なある2八重奏の分野しかなくて、どんな妥当な認証計画も2つ以上の八重奏を必要とするので、RIPバージョン2の認証計画は全体のRIPエントリーのスペースを使用するでしょう。 メッセージにおける最初(そして、1番目だけ)のエントリーのAddress Family Identifierが0xFFFFであるなら、エントリーの残りは認証を含んでいます。 これは、メッセージの残りには24のRIPエントリーが大部分にあることができることを意味します。 認証が使用中でないなら、メッセージにおけるどんなエントリーにも、0xFFFFのAddress Family Identifierがあるべきではありません。 認証エントリーを含むRIPメッセージは以下の形式で始まるでしょう:
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) | Version (1) | unused |
+---------------+---------------+-------------------------------+
| 0xFFFF | Authentication Type (2) |
+-------------------------------+-------------------------------+
~ Authentication (16) ~
+---------------------------------------------------------------+
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コマンド(1)| バージョン(1)| 未使用| +---------------+---------------+-------------------------------+ | 0xFFFF| 認証タイプ(2)| +-------------------------------+-------------------------------+ ~認証(16)~+---------------------------------------------------------------+
Currently, the only Authentication Type is simple password and it is type 2. The remaining 16 octets contain the plain text password. If the password is under 16 octets, it must be left-justified and padded to the right with nulls (0x00).
現在、唯一のAuthentication Typeが簡単なパスワードです、そして、それはタイプ2です。 残っている16の八重奏がプレーンテキストパスワードを含んでいます。 パスワードが16未満の八重奏であるなら、それを左で正当であり、ヌル(0×00)で右に水増ししなければなりません。
3.2 Route Tag
3.2 ルートタグ
The Route Tag (RT) field is an attribute assigned to a route which must be preserved and readvertised with a route. The intended use of the Route Tag is to provide a method of separating "internal" RIP routes (routes for networks within the RIP routing domain) from "external" RIP routes, which may have been imported from an EGP or another IGP.
Route Tag(RT)分野は保持しなければならないルートに割り当てられて、ルートで「再-広告を出」す属性です。 Route Tagの意図している使用はEGPか別のIGPから輸入されたかもしれない「外部」のRIPルートと「内部」のRIPルート(RIP経路ドメインの中のネットワークのためのルート)を切り離す方法を提供することです。
Routers supporting protocols other than RIP should be configurable to allow the Route Tag to be configured for routes imported from different sources. For example, routes imported from EGP or BGP should be able to have their Route Tag either set to an arbitrary value, or at least to the number of the Autonomous System from which the routes were learned.
Route Tagがさまざまな原因から輸入されたルートに構成されるのを許容するのにおいてRIP以外のプロトコルをサポートするルータは構成可能であるべきです。 例えば、EGPかBGPから輸入されたルートは任意の値に設定されるか、少なくともルートが学習されたAutonomous Systemの数のどちらかにそれらのRoute Tagを持っているはずであることができます。
Other uses of the Route Tag are valid, as long as all routers in the RIP domain use it consistently. This allows for the possibility of a
RIPドメインのすべてのルータが一貫してそれを使用する限り、Route Tagの他の用途は有効です。 これはaの可能性を考慮します。
Malkin [Page 4] RFC 1723 RIP Version 2 November 1994
マルキン[4ページ]RFC1723はバージョン1994年11月2日を裂きます。
BGP-RIP protocol interactions document, which would describe methods for synchronizing routing in a transit network.
BGP-RIPは相互作用ドキュメントについて議定書の中で述べます。(それは、トランジットネットワークでルーティングを同期させるための方法を説明するでしょう)。
3.3 Subnet mask
3.3 サブネットマスク
The Subnet Mask field contains the subnet mask which is applied to the IP address to yield the non-host portion of the address. If this field is zero, then no subnet mask has been included for this entry.
Subnet Mask分野はアドレスの非ホスト部分をもたらすためにIPアドレスに適用されるサブネットマスクを含んでいます。 この分野がゼロであるなら、サブネットマスクは全くこのエントリーに含められていません。
On an interface where a RIP-1 router may hear and operate on the information in a RIP-2 routing entry the following rules apply:
RIP-1ルータがRIP-2ルーティングエントリーにおける情報を聞いて、作動させるかもしれないインタフェースに、以下の規則は適用されます:
1) information internal to one network must never be advertised into
another network,
1) 決して1つのネットワークへの内部の情報の別のネットワークに広告を出してはいけません。
2) information about a more specific subnet may not be advertised
where RIP-1 routers would consider it a host route, and
そして2) より特定のサブネットの情報がRIP-1ルータがそれがホストルートであると考えるところに広告を出さないかもしれない。
3) supernet routes (routes with a netmask less specific than the
"natural" network mask) must not be advertised where they could be
misinterpreted by RIP-1 routers.
3) RIP-1ルータでそれらを誤解できたところにsupernetルート(ネットマスクが「自然な」ネットワークマスクほど特定でないことのルート)の広告を出してはいけません。
3.4 Next Hop
3.4 次のホップ
The immediate next hop IP address to which packets to the destination specified by this route entry should be forwarded. Specifying a value of 0.0.0.0 in this field indicates that routing should be via the originator of the RIP advertisement. An address specified as a next hop must, per force, be directly reachable on the logical subnet over which the advertisement is made.
目的地へのパケットがこのルートエントリーで指定した次の即座のホップIPアドレスを転送するべきです。 ルーティングはこの分野の.0が示す.0であるべきですが、RIP広告の創始者を通して0.0の値を指定します。 次のホップが広告がされる論理的なサブネットで力単位で直接届かなければならないので、アドレスは指定しました。
The purpose of the Next Hop field is to eliminate packets being routed through extra hops in the system. It is particularly useful when RIP is not being run on all of the routers on a network. A simple example is given in Appendix A. Note that Next Hop is an "advisory" field. That is, if the provided information is ignored, a possibly sub-optimal, but absolutely valid, route may be taken. If the received Next Hop is not directly reachable, it should be treated as 0.0.0.0.
Next Hop分野の目的はシステムの余分なホップを通して発送されるパケットを排除することです。 RIPがネットワークのルータのすべてにおける走行でないときに、それは特に役に立ちます。 簡単な例はNext Hopが「顧問」の分野であるならそうです。 すなわち、提供された情報を無視するなら、ことによるとサブ最適の、しかし、絶対に有効なルートを取るかもしれません。 届いて、それは容認されたNext Hopが直接そうでないなら0.0として扱われるべきです。.0 .0。
3.5 Multicasting
3.5 マルチキャスティング
In order to reduce unnecessary load on those hosts which are not listening to RIP-2 messages, an IP multicast address will be used for periodic broadcasts. The IP multicast address is 224.0.0.9. Note that IGMP is not needed since these are inter-router messages which are not forwarded.
RIP-2メッセージの聴取ではなく、そうするそれらのホストで不要な負荷を減少させて、IPマルチキャストアドレスは周期的な放送に使用されるでしょう。 IPマルチキャストアドレスはそうです。224.0 .0 .9。 IGMPはこれらが転送されない相互ルータメッセージであるので必要でないことに注意してください。
Malkin [Page 5] RFC 1723 RIP Version 2 November 1994
マルキン[5ページ]RFC1723はバージョン1994年11月2日を裂きます。
In order to maintain backwards compatibility, the use of the multicast address will be configurable, as described in section 4.1. If multicasting is used, it should be used on all interfaces which support it.
後方に互換性を維持するために、マルチキャストアドレスの使用はセクション4.1で説明されるように構成可能になるでしょう。 マルチキャスティングが使用されているなら、それはそれを支持するすべてのインタフェースで使用されるべきです。
3.6 Queries
3.6 質問
If a RIP-2 router receives a RIP-1 Request, it should respond with a RIP-1 Response. If the router is configured to send only RIP-2 messages, it should not respond to a RIP-1 Request.
RIP-2ルータがRIP-1 Requestを受けるなら、それはRIP-1 Responseと共に応じるべきです。 ルータがRIP-2メッセージだけを送るために構成されるなら、それはRIP-1 Requestに応じるべきではありません。
4. Compatibility
4. 互換性
RFC 1058 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.
RFC1058はバージョン番号の取り扱いの仕様にかなりの先見を示しました。 バージョン0に関するRIPメッセージが捨てることであり、バージョン1に関するRIPメッセージが何かMust Be Zero(MBZ)分野も非ゼロであるなら捨てることであり、単にMBZ分野がゼロ以外の値を含んでいるので1よりすばらしいどんなバージョンに関するRIPメッセージも捨てるべきでないのが指定します。 これは、RIPの新しいバージョンが完全に後方に仕様のこの部分を固く守る既存のRIP実現と互換性があった状態であることを意味します。
4.1 Compatibility Switch
4.1 互換性スイッチ
A compatibility switch is necessary for two reasons. First, there are implementations of RIP-1 in the field which do not follow RFC 1058 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つの理由に必要です。 まず最初に、その分野での上で説明されるようにRFC1058に続かないRIP-1の実現があります。 2番目に、マルチキャスティングの使用は、RIP-1システムがRIP-2アップデート(いくつかの場合、必要な特徴であるかもしれない)を受けるのを防ぐでしょう。 このスイッチは1インタフェースあたり1個のベースで構成可能であるべきです。
The switch has four settings: RIP-1, in which only RIP-1 messages are sent; RIP-1 compatibility, in which RIP-2 messages are broadcast; RIP-2, in which RIP-2 messages are multicast; and "none", which disables the sending of RIP messages. The recommended default for this switch is RIP-1 compatibility.
スイッチには、4つの設定があります: RIP-1であって、唯一のRIP-1メッセージがどれであるかで送られる。 RIP-1の互換性(RIP-2メッセージはそれで放送されます)。 RIP-2、どのRIP-2メッセージで、マルチキャストはそうであるか。 そして、RIPメッセージの発信を無能にする「なにも。」 このスイッチのためのお勧めのデフォルトは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.
完全性のために、ルータは制御するべきです、また、aが受ける道具が受け入れるかどうか決定するスイッチ、RIP-1だけ、単にと、RIP-2の両方、またはなにも制御しません。 また、それもaで構成可能であるべきである、-、インタフェース基礎。
4.2 Authentication
4.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;
以下のアルゴリズムは、RIPメッセージを認証するのに使用されるべきです。 RIP-2メッセージを認証するためにルータを構成しないと、RIP-1とunauthenticated RIP-2メッセージを受け入れるでしょう。
Malkin [Page 6] RFC 1723 RIP Version 2 November 1994
マルキン[6ページ]RFC1723はバージョン1994年11月2日を裂きます。
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).
認証されたRIP-2メッセージは捨てられるものとします。 RIP-2メッセージを認証するためにルータを構成するなら、認証テストに合格するRIP-1メッセージとRIP-2メッセージを受け入れるものとします。 非認証されて失敗した認証RIP-2メッセージは捨てられるものとします。 認証が使用中であるときに(セクション4.1を見てください)、最大のセキュリティには、RIP-1メッセージは無視されるべきです。
Since an authentication entry is marked with an Address Family Identifier of 0xFFFF, a RIP-1 system would ignore this entry since it would belong to an address family other than IP. It should be noted, therefore, that use of authentication will not prevent RIP-1 systems from seeing RIP-2 messages. If desired, this may be done using multicasting, as described in sections 3.5 and 4.1.
それはIP以外のアドレス家族のものでしょう、したがって、認証エントリーが0xFFFFのAddress Family Identifierと共に示されるとき、RIP-1システムがこのエントリーを無視するでしょう。 したがって、認証の使用が、RIP-1システムがRIP-2メッセージを見るのを防がないことに注意されるべきです。 望まれているなら、これはセクション3.5と4.1で説明されるようにマルチキャスティングを使用し終わるかもしれません。
4.3 Larger Infinity
4.3 より大きい無限
While on the subject of compatibility, there is one item which people have requested: increasing infinity. The primary reason that this cannot be done is that it would violate backwards compatibility. A larger infinity would obviously confuse older versions of rip. At best, they would ignore the route as they would ignore a metric of 16. There was also a proposal to make the Metric a single octet and reuse the high three octets, but this would break any implementations which treat the metric as a 4-octet entity.
人々が要求した1つの項目が互換性の問題を扱っていますが: 無限を増加させます。 これができない第一の理由は後方に互換性に違反するだろうということです。 より大きい無限は裂け目の旧式のバージョンを明らかに混乱させるでしょう。 せいぜい、彼らは16におけるメートル法のaを無視するようにルートを無視するでしょう。 また、Metricをただ一つの八重奏にして、高い3つの八重奏を再利用するという提案がありましたが、これは4八重奏の実体としてメートル法を扱うどんな実現も壊すでしょう。
4.4 Addressless Links
4.4 Addresslessリンク
As in RIP-1, addressless links will not be supported by RIP-2.
RIP-1のように、addresslessリンクはRIP-2によって支えられないでしょう。
5. Security Considerations
5. セキュリティ問題
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 3.1 and 4.2.
基本的なRIPプロトコルは安全なプロトコルではありません。 より現代のルーティング・プロトコルに沿ってRIP-2を持って来るために、広げることができる認証機構はプロトコル増進に組み入れられました。 このメカニズムはセクション3.1と4.2で説明されます。
Malkin [Page 7] RFC 1723 RIP Version 2 November 1994
マルキン[7ページ]RFC1723はバージョン1994年11月2日を裂きます。
Appendix A
付録A
This is a simple example of the use of the next hop field in a rip entry.
これは裂け目のエントリーにおける次のホップ分野の使用の簡単な例です。
----- ----- ----- ----- ----- -----
|IR1| |IR2| |IR3| |XR1| |XR2| |XR3|
--+-- --+-- --+-- --+-- --+-- --+--
| | | | | |
--+-------+-------+---------------+-------+-------+--
<-------------RIP-2------------->
----- ----- ----- ----- ----- ----- |IR1| |IR2| |IR3| |XR1| |XR2| |XR3| --+-- --+-- --+-- --+-- --+-- --+-- | | | | | | --+-------+-------+---------------+-------+-------+--<。-------------裂け目-2------------->。
Assume that IR1, IR2, and IR3 are all "internal" routers which are under one administration (e.g. a campus) which has elected to use RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under separate administration (e.g. a regional network, of which the campus is a member) and are using some other routing protocol (e.g. OSPF). XR1, XR2, and XR3 exchange routing information among themselves such that they know that the best routes to networks N1 and N2 are via XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for routing to occur without additional hops through XR1. Without the Next Hop (for example, if RIP-1 were used) it would be necessary for XR2 and XR3 to also participate in the RIP-2 protocol to eliminate extra hops.
IR1、IR2、およびIR3がすべて「内部」のルータであると仮定してください(IGPとしてRIP-2を使用するのを選んだ1つ未満の管理(例えば、キャンパス)です)。 他方では、XR1、XR2、およびXR3は別々の管理(例えば、キャンパスがメンバーである地域ネットワーク)の下にあって、ある他のルーティング・プロトコルを使用しています(例えば、OSPF)。 XR1、XR2、およびXR3は彼らが、XR1を通してネットワークのN1とN2への最も良いルートがあるのを知るように、自分たちの中でルーティング情報を交換します、N3に、N4、そして、N5はXR2を通してあって、XR3を通してN6とN7にはあります。 正しさ(N3/N4/N5のためのXR2、N6/N7のためのXR3に)にNext Hop分野を設定することによって、XR1だけがルーティングがXR1を通して追加ホップなしで起こるようにIR1/IR2/IR3と共に交換RIP-2ルートを必要とします。 Next Hop(RIP-1が例えば使用されたなら)がなければ、また、XR2とXR3が余分なホップを排除するためにRIP-2プロトコルに参加するのが必要でしょう。
References
参照
[1] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058,
Rutgers University, June 1988.
[1] ヘドリック、C.、「ルーティング情報プロトコル」、STD34、RFC1058、ラトガース大学、1988年6月。
[2] Malkin, G., "RIP Version 2 - Carrying Additional Information",
RFC 1388, Xylogics, Inc., January 1993.
[2] マルキン、G.が「追加情報を運んで、バージョン2をコピーする」、RFC1388、Xylogics Inc.、1月1993日
[3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC
1724, Xylogics, Inc., Cisco Systems, November 1994.
[3] マルキン、G.とF.ベイカー、「裂け目のバージョン2MIB拡張子」、RFC1724、Xylogics Inc.、シスコシステムズ、1994年11月。
[4] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721,
Xylogics, Inc., November 1994.
[4] マルキン、G.、「裂け目のバージョン2プロトコル分析」、RFC1721、Xylogics Inc.、1994年11月。
[5] Malkin, G., "RIP Version 2 Protocol Applicability Statement", RFC
1722, Xylogics, Inc., November 1994.
[5] マルキン、G.、「裂け目のバージョン2プロトコル適用性証明」、RFC1722、Xylogics Inc.、1994年11月。
Malkin [Page 8] RFC 1723 RIP Version 2 November 1994
マルキン[8ページ]RFC1723はバージョン1994年11月2日を裂きます。
Author's Address
作者のアドレス
Gary Scott Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803
ゲーリースコットマルキンXylogics Inc.53第3アベニューバーリントン、MA 01803
Phone: (617) 272-8140 EMail: gmalkin@Xylogics.COM
以下に電話をしてください。 (617) 272-8140 メールしてください: gmalkin@Xylogics.COM
Malkin [Page 9]
マルキン[9ページ]
一覧
スポンサーリンク
