RFC1388 日本語訳
1388 RIP Version 2 Carrying Additional Information. G. Malkin. January 1993. (Format: TXT=16227 bytes) (Obsoleted by RFC1723) (Updates RFC1058) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Malkin Request for Comments: 1388 Xylogics, Inc. Updates: RFC 1058 January 1993
コメントを求めるワーキンググループG.マルキンの要求をネットワークでつないでください: 1388のXylogics Inc.アップデート: RFC1058 1993年1月
RIP Version 2
Carrying Additional Information
追加情報を運ぶバージョン2をコピーしてください。
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
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 packets and to add a measure of security. A companion document will define the SNMP MIB objects for RIP-2 [2].
このドキュメントはルーティング情報プロトコル(RIP)の拡大を指定します、RIPパケットで運ばれた役に立つ情報の量を広げて、セキュリティの基準を加えるために[1]で定義されるように。 仲間ドキュメントはRIP-2[2]のためにSNMP MIB物を定義するでしょう。
Acknowledgements
承認
I would like to thank the following for their contributions to this document: Fred Baker, Noel Chiappa and Vince Fuller. This memo is a product of the RIP-2 Working Group of the Internet Engineering Task Force (IETF).
感謝申し上げます。これへの彼らの貢献のための以下は以下を記録します。 フレッド・ベイカー、クリスマスChiappa、およびビンス・フラー。 このメモはRIP-2インターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。
Table of Contents
目次
1. Justification . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 2 3.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Routing Domain . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.6 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 5 4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 6 4.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1. 正当化. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 潮境. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 拡大. . . . . . . . . . . . . . . . . . . . . . 2 3.1認証. . . . . . . . . . . . . . . . . . . . . . . 3 3.2経路ドメイン.43.3ルートタグ. . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4サブネットマスク. . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5次のホップ. . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.6マルチキャスティング. . . . . . . . . . . . . . . . . . . . . . . . 5 4について議定書の中で述べてください。 互換性. . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1互換性スイッチ. . . . . . . . . . . . . . . . . . . . 5 4.2認証. . . . . . . . . . . . . . . . . . . . . . . 6 4.3の、より大きい無限. . . . . . . . . . . . . . . . . . . . . . . 6 4.4Addresslessリンクス.6付録は.6の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7です。
Malkin [Page 1] RFC 1388 RIP Version 2 January 1993
マルキン[1ページ]RFC1388はバージョン1993年1月2日を裂きます。
Security Considerations . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
セキュリティ問題. . . . . . . . . . . . . . . . . . . . . . 7作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . . 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 packet contains the minimal amount of information necessary for routers to route packets 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 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に先日付を書くので、現在のRIPプロトコルは、自律システムとIGP/EGPが相互作用と、サブネッティングと、認証であると考えません。 彼らがルートを決定する方法を知るためにサブネットマスクを必要とするので、サブネットマスクの不足はルータのための特に重大な問題です。 RIPルートがネットワークルート(すべての非ネットワークビット0)であるなら、サブネットマスクはネットワークマスクと等しいです。 しかしながら、いくつかの非ネットワークビットが設定されるなら、ルータはサブネットマスクを決定できません。 よりひどく、それでも、ルータは、RIPルートがサブネットルートかそれともホストルートであるかを決定できません。 現在、いくつかのルータが、単にルートが学習されたインタフェースのサブネットマスクを選んで、それからルートタイプを決定します。
3. Protocol Extensions
3. プロトコル拡大
This document does not change the RIP protocol per se. Rather, it provides extensions to the datagram format which allows routers to share important additional information.
このドキュメントはそういうものとしてRIPプロトコルを変えません。 むしろ、それはルータが重要な追加情報を共有できるデータグラム形式に拡大を提供します。
Malkin [Page 2] RFC 1388 RIP Version 2 January 1993
マルキン[2ページ]RFC1388はバージョン1993年1月2日を裂きます。
The new RIP datagram format is:
新しい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) | Routing Domain (2) |
+---------------+---------------+-------------------------------+
| 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)| ルートタグ(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 datagrams which use authentication or carry information in any of the newly defined fields.
Command、Address Family Identifier(AFI)、IP Address、およびMetricには、RFC1058で定義された意味がすべてあります。 バージョン分野は新たに定義された分野のいずれでも認証を使用するか、または情報を運ぶRIPデータグラムのバージョンNo.2を指定するでしょう。
All fields are coded in IP network byte order (big-endian).
すべての分野がIPネットワークバイトオーダー(ビッグエンディアン)でコード化されます。
3.1 Authentication
3.1 認証
Since authentication is a per packet function, and since there is only one 2-byte field available in the packet header, and since any reasonable authentication scheme will require more than two bytes, 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 packet 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 packet. If authentication is not in use, then no entries in the packet should have an Address Family Identifier of 0xFFFF. A RIP packet which contains an authentication entry would have 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) | Routing Domain (2) |
+---------------+---------------+-------------------------------+
| 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)| 経路ドメイン(2)| +---------------+---------------+-------------------------------+ | 0xFFFF| 認証タイプ(2)| +-------------------------------+-------------------------------+ ~認証(16)~+---------------------------------------------------------------+
Malkin [Page 3] RFC 1388 RIP Version 2 January 1993
マルキン[3ページ]RFC1388はバージョン1993年1月2日を裂きます。
Currently, the only Authentication Type is simple password and it is type 2. The remaining 16 bytes contain the plain text password. If the password is under 16 bytes, it must be left-justified and padded to the right with nulls (0x00).
現在、唯一のAuthentication Typeが簡単なパスワードです、そして、それはタイプ2です。 残っている16バイトはプレーンテキストパスワードを含んでいます。 パスワードが16バイト未満であるなら、それを左で正当であり、ヌル(0×00)で右に水増ししなければなりません。
3.2 Routing Domain
3.2 経路ドメイン
The Routing Domain (RD) number is the number of the routing process to which this update belongs. This field is used to associate the routing update to a specific routing process on the receiving router. The RD is needed to allow multiple, independent RIP "clouds" to co- exist on the same physical wire. This gives administrators the ability to run multiple, possibly parallel, instances of RIP in order to implement simple policy. This means that a router operating within one routing domain, or a set of routing domains, should ignore RIP packets which belong to another routing domain. RD 0 is the default routing domain.
ルート設定Domain(RD)番号はこのアップデートが属するルーティングの過程の数です。 この分野は、受信ルータの特定のルーティングの過程にルーティングアップデートを関連づけるのに使用されます。 RDが、複数の、そして、独立しているRIP「雲」が同じ物理的なワイヤの上に共同存在するのを許容するのが必要です。 これは簡単な政策を実施するためにRIPの複数の、そして、ことによると平行な例を走らせる能力を管理者に与えます。 これは、1つの経路ドメインの中で作動するルータ、または1セットの経路ドメインが別の経路ドメインに属すRIPパケットを無視するべきであることを意味します。 RD0はデフォルト経路ドメインです。
3.3 Route Tag
3.3 ルートタグ
The Route Tag (RT) field exists as a support for EGPs. The contents and use of this field are outside the scope of this protocol. However, it is expected that the field will be used to carry Autonomous System numbers for EGP and BGP. Any RIP system which receives a RIP entry which contains a non-zero RT value must re- advertise that value. Those routes which have no RT value must advertise an RT value of zero.
Route Tag(RT)分野はEGPsのサポートとして存在しています。 このプロトコルの範囲の外にこの分野のコンテンツと使用があります。 しかしながら、分野がEGPとBGPのAutonomous System番号を運ぶのに使用されると予想されます。 非ゼロRT価値を含むRIPエントリーを受けるどんなRIPシステムもその値の再広告を出さなければなりません。 RT値を全く持っていないそれらのルートはゼロのRT値の広告を出さなければなりません。
3.4 Subnet mask
3.4 サブネットマスク
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 two rules apply:
RIP-1ルータがRIP-2ルーティングエントリーにおける情報を聞いて、作動させるかもしれないインタフェースに、以下の2つの規則が適用されます:
1) information internal to one network must never be advertised into
another network, and
そして1) 決して1つのネットワークへの内部の情報の別のネットワークに広告を出してはいけない。
2) information about a more specific subnet may not be advertised
where RIP-1 routers would consider it a host route.
2) より特定のサブネットの情報はRIP-1ルータがそれがホストルートであると考えるところに広告を出さないかもしれません。
3.5 Next Hop
3.5 次のホップ
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
目的地へのパケットがこのルートエントリーで指定した次の即座のホップIPアドレスを転送するべきです。 を通してルーティングがこの分野の.0が示す.0であるべきですが、0.0のa値を指定する。
Malkin [Page 4] RFC 1388 RIP Version 2 January 1993
マルキン[4ページ]RFC1388はバージョン1993年1月2日を裂きます。
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.
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.
Next Hop分野の目的はシステムの余分なホップを通して発送されるパケットを排除することです。 RIPがネットワークのルータのすべてにおける走行でないときに、それは特に役に立ちます。 簡単な例はNext Hopが「顧問」の分野であるならそうです。 すなわち、提供された情報を無視するなら、ことによるとサブ最適の、しかし、絶対に有効なルートを取るかもしれません。
3.6 Multicasting
3.6 マルチキャスティング
In order to reduce unnecessary load on those hosts which are not listening to RIP-2 packets, 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はこれらが転送されない相互ルータメッセージであるので必要でないことに注意してください。
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で説明されるように構成可能になるでしょう。 マルチキャスティングが使用されているなら、それはそれを支持するすべてのインタフェースで使用されるべきです。
4. Compatibility
4. 互換性
RFC 1058 showed considerable forethought in its specification of the handling of version numbers. It specifies that RIP packets of version 0 are to be discarded, that RIP packets of version 1 are to be discarded if any Must Be Zero (MBZ) field is non-zero, and that RIP packets 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パケットを捨てることになっていて、何かMust Be Zero(MBZ)分野も非ゼロであるならバージョン1のRIPパケットを捨てることになっていて、単に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).
互換性スイッチが2つの理由に必要です。 まず最初に、その分野での上で説明されるようにRFC1058に続かないRIP-1の実現があります。 2番目に、マルチキャスティングの使用は、RIP-1システムがRIP-2アップデート(いくつかの場合、必要な特徴であるかもしれない)を受けるのを防ぐでしょう。
The switch has three settings: RIP-1, in which only RIP-1 packets are sent; RIP-1 compatibility, in which RIP-2 packets are broadcast; and RIP-2, in which RIP-2 packets are multicast. The recommended default for this switch is RIP-1 compatibility.
スイッチには、3つの設定があります: RIP-1であって、唯一のRIP-1パケットがどれであるかで送られる。 RIP-1の互換性(RIP-2パケットはそれで放送されます)。 そして、RIP-2。(そこでは、RIP-2パケットがマルチキャストです)。 このスイッチのためのお勧めのデフォルトはRIP-1の互換性です。
Malkin [Page 5] RFC 1388 RIP Version 2 January 1993
マルキン[5ページ]RFC1388はバージョン1993年1月2日を裂きます。
4.2 Authentication
4.2 認証
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 packets. If desired, this may be done using multicasting, as described in sections 3.6 and 4.1.
それはIP以外のアドレス家族のものでしょう、したがって、認証エントリーが0xFFFFのAddress Family Identifierと共に示されるとき、RIP-1システムがこのエントリーを無視するでしょう。 したがって、認証の使用が、RIP-1システムがRIP-2パケットを見るのを防がないことに注意されるべきです。 望まれているなら、これはセクション3.6と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 byte and reuse the high three bytes, but this would break any implementations which treat the metric as a long.
人々が要求した1つの項目が互換性の問題を扱っていますが: 無限を増加させます。 これができない第一の理由は後方に互換性に違反するだろうということです。 より大きい無限は裂け目の旧式のバージョンを明らかに混乱させるでしょう。 せいぜい、彼らは16におけるメートル法のaを無視するようにルートを無視するでしょう。 また、Metricを1バイトにして、高値を3バイト再利用するという提案がありましたが、これは長さにメートル法を扱うどんな実現も壊すでしょう。
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によって支えられないでしょう。
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
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が例えば使用されたなら)であるだろうことなしで
Malkin [Page 6] RFC 1388 RIP Version 2 January 1993
マルキン[6ページ]RFC1388はバージョン1993年1月2日を裂きます。
necessary for XR2 and XR3 to also participate in the RIP-2 protocol to eliminate extra hops.
また、XR2とXR3が余分なホップを排除するためにRIP-2プロトコルに参加するように、必要です。
References
参照
[1] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
University, June 1988.
[1] ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、ラトガース大学、1988年6月。
[2] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC
1389, Xylogics, Inc., Advanced Computer Communications, January
1993.
1993年1月の[2] RFC1389(Xylogics Inc.)が進めたマルキン、G.、およびF.ベイカー、「裂け目のバージョン2MIB拡張子」コンピュータコミュニケーション。
[3] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1387,
Xylogics, Inc., January 1993.
[3] マルキン、G.、「裂け目のバージョン2プロトコル分析」、RFC1387、Xylogics Inc.、1993年1月。
Security Considerations
セキュリティ問題
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で説明されます。
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 7]
マルキン[7ページ]
一覧
スポンサーリンク
