RFC1722 日本語訳

Network Working Group                                          G. Malkin
Request for Comments: 1722                                Xylogics, Inc.
Category: Standards Track                                  November 1994

コメントを求めるワーキンググループG.マルキンの要求をネットワークでつないでください: 1722年のXylogics Inc.カテゴリ: 標準化過程1994年11月

             RIP Version 2 Protocol Applicability Statement

バージョン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

要約

   As required by Routing Protocol Criteria (RFC 1264), this report
   defines the applicability of the RIP-2 protocol within the Internet.
   This report is a prerequisite to advancing RIP-2 on the standards
   track.

必要に応じて、ルート設定プロトコルCriteria(RFC1264)で、このレポートはインターネットの中でRIP-2プロトコルの適用性を定義します。 このレポートは標準化過程の上でRIP-2を進めることへの前提条件です。

1.  Protocol Documents

1. プロトコルドキュメント

   The RIP-2 protocol analysis is documented in RFC 1721 [1].

RIP-2プロトコル分析はRFC1721[1]に記録されます。

   The RIP-2 protocol description is defined in RFC 1723 [2].  This memo
   obsoletes RFC 1388, which specifies an update to the "Routing
   Information Protocol" RFC 1058 (STD 34).

RIP-2プロトコル記述はRFC1723[2]で定義されます。 このメモはRFC1388を時代遅れにします。(RFCは「ルーティング情報プロトコル」RFC1058(STD34)にアップデートを指定します)。

   The RIP-2 MIB description is defined in RFC 1724 [3].  This memo will
   obsolete RFC 1389.

RIP-2 MIB記述はRFC1724[3]で定義されます。 このメモはRFC1389を時代遅れにするでしょう。

2.  Introduction

2. 序論

   This report describes how RIP-2 may be useful within the Internet.
   In essence, the environments in which RIP-2 is the IGP of choice is a
   superset of the environments in which RIP-1, as defined in RFC 1058
   [1], has traditionally been used.  It is important to remember that
   RIP-2 is an extension to RIP-1; RIP-2 is not a new protocol.  Thus,
   the operational aspects of distance-vector routing protocols, and
   RIP-1 in particular, within an autonomous system are well understood.

このレポートはRIP-2がインターネットの中でどう役に立つかもしれないかを説明します。 本質、RIP-2が選択のIGPである環境には、RFC1058[1]で定義されるRIP-1が伝統的に使用された環境のスーパーセットがあります。 RIP-2がRIP-1への拡大であることを覚えているのは重要です。 RIP-2は新しいプロトコルではありません。 したがって、自律システムの中の距離ベクトルのルーティング・プロトコル、および特にRIP-1の操作上の局面はよく理解されています。

   It should be noted that RIP-2 is not intended to be a substitute for
   OSPF in large autonomous systems; the restrictions on AS diameter and
   complexity which applied to RIP-1 also apply to RIP-2.  Rather, RIP-2
   allows the smaller, simpler, distance-vector protocol to be used in
   environments which require authentication or the use of variable

RIP-2が大きい自律システムのOSPFの代用品であることを意図しないことに注意されるべきです。 また、AS直径と複雑さにおけるRIP-1に適用された制限はRIP-2に適用されます。 むしろ、RIP-2は、より小さくて、より簡単な距離ベクトルプロトコルが変数の認証か使用を必要とする環境で使用されるのを許容します。

Malkin                                                          [Page 1]

RFC 1722                  RIP-2 Applicability              November 1994

1994年のマルキン[1ページ]RFC1722適用性11月2日裂け目-

   length subnet masks, but are not of a size or complexity which
   require the use of the larger, more complex, link-state protocol.

長さのサブネットがマスクをかける、 より大きく、より複雑(リンク州のプロトコル)の使用を必要とするaサイズか複雑さがありません。

   The remainder of this report describes how each of the extensions to
   RIP-1 may be used to increase the overall usefullness of RIP-2.

このレポートの残りはRIP-1へのそれぞれの拡張子がRIP-2の総合的なusefullnessを増加させるのにどう使用されるかもしれないかを説明します。

3.  Extension Applicability

3. 拡大の適用性

3.1 Subnet Masks

3.1 サブネット仮面

   The original impetus behind the creation of RIP-2 was the desire to
   include subnet masks in the routing information exchanged by RIP.
   This was needed because subnetting was not defined when RIP was first
   created.  As long as the subnet mask was fixed for a network, and
   well known by all the nodes on that network, a heuristic could be
   used to determine if a route was a subnet route or a host route.
   With the advent of variable length subnetting, CIDR, and
   supernetting, it was no longer possible for a heuristic to reasonably
   distinguish between network, subnet, and host routes.

RIP-2の創造の後ろのオリジナルの起動力はRIPによって交換されたルーティング情報にサブネットマスクを含む願望でした。 サブネッティングが定義されないで、いつRIPが最初に作成されたかということであったので、これが必要でした。 サブネットマスクがそのネットワークのすべてのノードでネットワークのために固定されていて、よく知られていた限り、ルートがサブネットルートでしたかそれともホストルートであったかを決定するのにヒューリスティックを使用できました。 可変長サブネッティングの到来、CIDR、およびスーパーネッティングで、ヒューリスティックが合理的にネットワーク、サブネット、およびホストルートを見分けるのは、もう可能ではありませんでした。

   By using the 32-bit field immediately following the IP address in a
   RIP routing entry, it became possible to positively identify a
   route's type.  In fact, one could go so far as to say that the
   inclusion of the subnet mask effictively creates a 64-bit address
   which eliminates the network, subnet, host distinction.

すぐにRIPルーティングエントリーでIPアドレスに従って、32ビットの分野を使用することによって、明確にルートのタイプを特定するのは可能になりました。 事実上、人は、サブネットマスクの包含がeffictivelyにネットワークを排除する64ビットのアドレスを作成するのを極言できました、サブネット、ホスト区別。

   Therefore, the inclusion of subnet masks in RIP-2 allows it to be
   used in an AS which requires precise knowledge of the subnet mask for
   a given route, but does not otherwise require OSPF.

したがって、RIP-2でのサブネットマスクの包含は、それが与えられたルートにサブネットマスクに関する正確な知識を必要としますが、別の方法でOSPFは必要としないASで使用されるのを許容します。

3.2. Next Hop

3.2. 次のホップ

   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.
   Consider the following example topology:

Next Hop分野の目的はシステムの余分なホップを通して発送されるパケットを排除することです。 RIPがネットワークのルータのすべてにおける走行でないときに、それは特に役に立ちます。 以下の例がトポロジーであると考えてください:

      -----   -----         -----   -----
      |IR1|   |IR2|         |XR1|   |XR2|
      --+--   --+--         --+--   --+--
        |       |             |       |
      --+-------+-------------+-------+--
        |--------RIP-2--------|

----- ----- ----- ----- |IR1| |IR2| |XR1| |XR2| --+-- --+-- --+-- --+-- | | | | --+-------+-------------+-------+-- |--------裂け目-2--------|

   The Internal Routers (IR1 and IR2) are only running RIP-2.  The
   External Routers (XR1 and XR2) are both running BGP, for example;
   however, only XR1 is running BGP and RIP-2.  Since XR2 is not running
   RIP-2, the IRs will not know of its existance and will never use it

Internal Routers(IR1とIR2)はRIP-2を走らせているだけです。 External Routers(XR1とXR2)は例えばBGPをともに走らせています。 しかしながら、XR1だけがBGPとRIP-2を走らせています。 XR2がRIP-2を走らせていないので、IRはexistanceを知らないで、またそれを決して使用しないでしょう。

Malkin                                                          [Page 2]

RFC 1722                  RIP-2 Applicability              November 1994

1994年のマルキン[2ページ]RFC1722適用性11月2日裂け目-

   as a next hop, even if it is a better next hop than XR1.  Of course,
   XR1 knows this and can indicate, via the Next Hop field, that XR2 is
   the better next hop for some routes.

それが次のホップ次のXR1より良いホップであっても。 もちろん、XR1はこれを知って、Next Hop分野を通ってXR2がいくつかのルートへの次の、より良いホップであることを示すことができます。

   Another use for Next Hop has also been found.  Consider the following
   example topology:

また、Next Hopの別の使用は見つけられました。 以下の例がトポロジーであると考えてください:

           -----
           |COR|
           -----
           /   \
          /     \
      -----     -----     -----
      |RO1|-----|RO2|=====| R |
      -----     -----     -----

----- |心臓| ----- / \ / \ ----- ----- ----- |RO1|-----|RO2|=====| R| ----- ----- -----

   The three links between the Central Office Router (COR) and the
   Remote Office routers (RO1 and RO2) are all Dial-On-Demand (DOD)
   links.  The link between RO2 and R is a fixed link.  Once all of the
   routers have been initialized, the only routes they know about are
   the configured static routes for the DOD links.  Assume that
   connections between COR and RO1, and COR and RO2 are established and
   RIP information is passing between the routers.  RO1 will ignore
   COR's route to RO2 because it already has a better one; however, it
   will learn to reach R via COR.

セントラルオフィスRouter(COR)とRemoteオフィスルータ(RO1とRO2)との3個のリンクがすべて要求でのDial(DOD)リンクです。 RO2とRとのリンクは固定連結路です。 ルータのすべてがいったん初期化されると、彼らが知っている唯一のルートがDODリンクへの構成されたスタティックルートです。 それがCORとRO1との接続であると仮定して、CORとRO2は設立されます、そして、RIP情報はルータの間で終わっています。 それには、より良いものが既にあるので、RO1はCORのルートをRO2に無視するでしょう。 しかしながら、それは、CORを通してRに達することを学ぶでしょう。

   If we assume that RO1 and RO2 are only capable of establishing one
   link at a time, then RO1 will not be able to reach RO2; however, RO1
   will be able to reach R.  Worse still, if we assume that traffic
   stops and the DOD links drop due to inactivity, an attempt by RO1 to
   reach R will trigger the dialing of two links (through COR).  Of
   course, once RO1 establishes a link to RO2, the problem corrects
   itself because the new route to R is one hop shorter.

私たちが、RO1とRO2が一度に1個のリンクしか設立できないと思うと、RO1はRO2に達することができないでしょう。 しかしながら、RO1はまだR.Worseに達することができるでしょう、私たちが通行が止まって、DODリンクが不活発のため低下すると思うなら、Rに達するRO1による試みは2個のリンク(CORを通した)のダイヤルすることの引き金となるでしょう。 もちろん、RO1がいったんRO2へのリンクを設立すると、Rへの新しいルートが、より短い状態でワンバウンドであるので、問題はそれ自体を修正します。

   To correct this problem, the routers may use the Next Hop field to
   indicate their next hop.  Consider the following route advertisements
   during the period described above (before the RO1/RO2 link has ever
   been established):

この問題を修正するなら、ルータは、それらの次のホップを示すのにNext Hop分野を使用するかもしれません。 上で説明された期間、以下のルートが広告であると考えてください(RO1/RO2リンクが今までに設立されたことがある前に):

      Sender  Recvr   Route   NextHop  Metric
      =======================================
      RO2     COR     R       0        1
      ---------------------------------------
      COR     RO1     RO2     0        1
                      R       RO2      2
      ---------------------------------------

送付者Recvrはメートル法でNextHopを発送します。======================================= RO2心臓R0 1--------------------------------------- 心臓RO1 RO2 0 1R RO2 2---------------------------------------

Malkin                                                          [Page 3]

RFC 1722                  RIP-2 Applicability              November 1994

1994年のマルキン[3ページ]RFC1722適用性11月2日裂け目-

   When R01 receives the two routes from COR, it will ignore the route
   for RO2, as mentioned above.  However, since R is not in RO1's
   routing table, it will add it using a next hop of RO2 (because RO2 is
   directly connected, after a fashion).  Note that COR does count
   itself in R's metric; this is less than accurate, but entirely safe
   and correctable (when the RO1/RO2 link comes up).  Suppose, now, that
   the RO1/RO2 link did not exist.  RO1 would ignore the specification
   of RO2 as the next hop to R and use COR, as it would if no Next Hop
   had been specified.

R01がCORから2つのルートを受けるとき、それはRO2のために上に言及されるようにルートを無視するでしょう。 しかしながら、RがRO1の経路指定テーブルにないので、RO2の次のホップを使用することで(RO2がファッションの後に直接接続されるので)それはそれを加えるでしょう。 CORがRのところでメートル法でそれ自体を数えることに注意してください。 これは、正確であるよりそれほど、しかし、完全に安全であって、修正可能です(RO1/RO2リンクが来ると)。 今、RO1/RO2リンクが存在しなかったと仮定してください。 RO1は次のホップとしてRO2の仕様をRに無視して、CORを使用するでしょう、Next Hopが全く指定されていないならそうするように。

   Note that this is not a recursive algorithm; it only works to
   eliminate a single extra hop from the path.  There are methods by
   which this mechanism might be extended to include larger
   optimizations, but the potential to create routing loops has not been
   sufficiently analyzed to specify them here.

これが再帰的なアルゴリズムでないことに注意してください。 それは、経路から単一の余分なホップを排除するために働いているだけです。 このメカニズムが、より大きい最適化を含むように広げられるかもしれない方法がありますが、ルーティング輪を作成する可能性はここでそれらを指定するくらいには分析されていません。

3.3 Authentication

3.3 認証

   The need for authentication in a routing protocol is obvious.  It is
   not usually important to conceal the information in the routing
   messages, but it is essential to prevent the insertion of bogus
   routing information into the routers.  So, while the authentication
   mechanism specified in RIP-2 is less than ideal, it does prevent
   anyone who cannot directly access the network (i.e., someone who
   cannot sniff the routing packets to determine the password) from
   inserting bogus routing information.

ルーティング・プロトコルにおける認証の必要性は明白です。 ルーティング・メッセージの情報を隠すのが通常重要ではありませんが、にせのルーティング情報の挿入をルータに防ぐのは不可欠です。 それで、RIP-2で指定された認証機構があまり理想的でない間、それによって、直接、ネットワーク(すなわち、パスワードを決定するためにルーティングパケットのにおいをかぐことができないだれか)にアクセスできないだれもにせのルーティング情報を挿入できません。

   However, the specification does allow for additional types of
   authentication to be incorporated into the protocol.  Unfortunately,
   because of the original format of RIP packets, the amount of space
   available for providing authentication information is only 16 octets.

しかしながら、仕様は、追加タイプの認証がプロトコルに組み入れられるのを許容します。 残念ながら、RIPパケットの元の形式のために、認証情報を提供するのに有効なスペースの合計は16の八重奏にすぎません。

3.4 Multicasting

3.4 マルチキャスティング

   The RIP-2 protocol provides for the IP multicasting of periodic
   advertisements.  This feature was added to decrease the load on
   systems which do not support RIP-2.  It also provides a mechanism
   whereby RIP-1 routers will never receive RIP-2 routes.  This is a
   feature when correct use of an advertised route depends on knowing
   the precise subnet mask, which would be ignored by a RIP-1 router.

RIP-2プロトコルは周期的な広告のIPマルチキャスティングに備えます。 この特徴は、RIP-2を支持しないシステムの上で負荷を減少させるために加えられました。 また、それはRIP-1ルータがRIP-2ルートを決して受けないメカニズムを提供します。 広告を出しているルートの正しい使用がよるとき、これはRIP-1ルータによって無視されるだろう正確なサブネットマスクを知ることに関する特徴です。

4.  Conclusion

4. 結論

   Because the basic protocol is unchanged, RIP-2 is as correct a
   routing protocol as RIP-1.  The enhancements make RIP-2 useful in
   environments which RIP-1 could not handle, but which do not
   necessitate the use of OSPF by virtue of requirements which RIP-2
   does not satisfy.

基本プロトコルが変わりがないので、RIP-2はRIP-1と同じくらい正しいルーティング・プロトコルです。 増進で、RIP-1が扱うことができませんでしたが、RIP-2がする要件によってOSPFの使用を必要としない環境で役に立つRIP-2は満足させません。

Malkin                                                          [Page 4]

RFC 1722                  RIP-2 Applicability              November 1994

1994年のマルキン[4ページ]RFC1722適用性11月2日裂け目-

5.  References

5. 参照

   [1] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721,
       Xylogics, Inc., November 1994.

[1] マルキン、G.、「裂け目のバージョン2プロトコル分析」、RFC1721、Xylogics Inc.、1994年11月。

   [2] Malkin, G., "RIP Version 2 - Carrying Additional Information",
       RFC 1723, Xylogics, Inc., November 1994.

[2] マルキン、G.が「追加情報を運んで、バージョン2をコピーする」、RFC1723、Xylogics Inc.、11月1994日

   [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月。

6.  Security Considerations

6. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

7.  Author's Address

7. 作者のアドレス

   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 5]

マルキン[5ページ]