RFC2080 日本語訳
2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: TXT=47534 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Malkin
Request for Comments: 2080 Xylogics
Category: Standards Track R. Minnear
Ipsilon Networks
January 1997
コメントを求めるワーキンググループG.マルキンの要求をネットワークでつないでください: 2080年のXylogicsカテゴリ: 規格は1997年1月にR.Minnear Ipsilonネットワークを追跡します。
RIPng for IPv6
IPv6のためのRIPng
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 a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet.
このドキュメントはIPv6インターネットにルーティング・プロトコルを指定します。 それはIPv4インターネットで現在広い使用でのプロトコルとアルゴリズムに基づいています。
This specification represents the minimum change to the Routing Information Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723 [2], necessary for operation over IPv6 [3].
この仕様はルーティング情報プロトコル(RIP)への最小の変化を表します、RFC1058[1]とRFC1723[2]で指定されて、操作にIPv6[3]の上で必要であるとして。
Acknowledgements
承認
This document is a modified version of RFC 1058, written by Chuck Hedrick [1]. The modifications reflect RIP-2 and IPv6 enhancements, but the original wording is his.
このドキュメントはチャック・ヘドリック[1]によって書かれたRFC1058の変更されたバージョンです。 変更はRIP-2とIPv6増進を反映しますが、オリジナルの言葉遣いは彼のものです。
We'd like to thank Dennis Ferguson and Thomas Narten for their input.
彼らの入力についてデニスファーガソンとトーマスNartenに感謝申し上げます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Theoretical Underpinnings . . . . . . . . . . . . . . . . . 3 1.2 Limitations of the Protocol . . . . . . . . . . . . . . . . 3 2. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4 2.1 Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Addressing Considerations . . . . . . . . . . . . . . . . . 8 2.3 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 Input Processing . . . . . . . . . . . . . . . . . . . . . . 10 2.4.1 Request Messages . . . . . . . . . . . . . . . . . . . . . 10 2.4.2 Response Messages . . . . . . . . . . . . . . . . . . . . 11
1. プロトコル. . . . . . . . . . . . . . . . 3 2の.21.1の序論の理論上の基礎. . . . . . . . . . . . . . . . . 3 1.2制限。 問題. . . . . . . . . . . . . . . . . 8 2を記述する次の仕様. . . . . . . . . . . . . . . . . . . . 4 2.1メッセージ・フォーマット. . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1ホップ. . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2について議定書の中で述べてください; 3個のタイマ. . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4の入力処理. . . . . . . . . . . . . . . . . . . . . . 10 2.4.1の要求メッセージ. . . . . . . . . . . . . . . . . . . . . 10 2.4.2の応答メッセージ. . . . . . . . . . . . . . . . . . . . 11
Malkin & Minnear Standards Track [Page 1] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[1ページ]RFC2080RIPng
2.5 Output Processing . . . . . . . . . . . . . . . . . . . . . 14 2.5.1 Triggered Updates . . . . . . . . . . . . . . . . . . . . 14 2.5.2 Generating Response Messages . . . . . . . . . . . . . . . 15 2.6 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 16 3. Control Functions . . . . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
.1が引き金となった2.5出力処理. . . . . . . . . . . . . . . . . . . . . 14 2.5は.152.6に.142.5の.2発生応答メッセージをアップデートします。地平線. . . . . . . . . . . . . . . . . . . . . . . 16 3を分けてください。 機能. . . . . . . . . . . . . . . . . . . . . . 17 4を制御してください。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 18の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
1. 序論
This memo describes one protocol in a series of routing protocols 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.
このメモはBellman-フォード(または、距離ベクトル)アルゴリズムに基づく一連のルーティング・プロトコルの1つのプロトコルについて説明します。 アルパネットの初期以来このアルゴリズムはコンピュータネットワークにおけるルーティング計算に使用されています。 ここで説明された特定のパケット・フォーマットとプロトコルは「掘る」というプログラムに基づいています。(それは、Unixのバークレーの分配で含まれています)。
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. RIPng 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 version 1 (RIP-1) is expected to fit, see Braden and Postel [6].
インターネットなどの国際ネットワークでは、全体のネットワークに使用されて、ただ一つのルーティング・プロトコルがありそうもなくなるのは、非常にありそうもないです。 むしろ、ネットワークはAutonomous Systems(AS)の収集として組織化されるでしょう。一般に、それは単一体によってそれぞれ管理されるでしょう。 各ASには、それ自身のルーティング技術があるでしょう。(それは、ASのところで異なるかもしれません)。 ASの中で使用されたルーティング・プロトコルはInteriorゲートウェイプロトコル(IGP)と呼ばれます。 Exteriorゲートウェイプロトコル(EGP)と呼ばれる別々のプロトコルは、ルーティング情報をASのものに移すのに使用されます。 RIPngは、IGPとしてASの適度のサイズところで働くように設計されました。 それは、より複雑な環境における使用のために意図しません。 RIPバージョン1(RIP-1)が合うと予想される文脈の情報に関しては、ブレーデンとポステル[6]を見てください。
RIPng is one of a class of 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
RIPngはDistance Vectorアルゴリズムとして知られているアルゴリズムのクラスの1つです。作者にとって知られているこのクラスのアルゴリズムの最も早い記述がフォードとフルカーソン[8]にあります。 これのために、それらはフォード-フルカーソンアルゴリズムとして時々知られています。用語Bellman-フォードが、また、使用されて、定式化がBellmanの方程式[4]に基づいているという事実に由来しています。 プレゼンテーションは本書では密接に[5]に基づいています。 このドキュメントはプロトコル仕様を含んでいます。 ルーティング・アルゴリズムの数学への序論に関しては、[1]を見てください。 このプロトコルによって使用される基本的なアルゴリズムは1969年にはアルパネットにもうコンピュータルーティングで使用されました。 しかしながら、このプロトコルの特定の祖先はゼロックスネットワーク・プロトコルの中にいます。 PUPプロトコル[7]は、ルーティング情報を交換するのにゲートウェイ情報プロトコルを使用しました。 このプロトコルのいくらかアップデートされたバージョンはゼロックスNetwork Systems(XNS)構造のために採用されました、名前経路情報プロトコル[9]で。 発送されたものバークレーはルート設定と主に同じです。
Malkin & Minnear Standards Track [Page 2] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[2ページ]RFC2080RIPng
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.
情報プロトコル、XNSアドレスを取り扱いIPv4と他のタイプのアドレス、およびルーティングでできるより一般的なアドレス形式に取り替えていて、アップデートは30秒毎を1つに制限しました。 この類似性のために、用語経路情報プロトコル(または、まさしくRIP)は、XNSプロトコルと発送されることによって使用されるプロトコルの両方について言及するのに使用されます。
1.1 Theoretical Underpinnings
1.1 理論上の基礎
An introduction to the theory and math behind Distance Vector protocols is provided in [1]. It has not been incorporated in this document for the sake of brevity.
理論への序論とDistance Vectorプロトコルの後ろの数学を[1]に提供します。 それは本書では簡潔にするために法人組織ではありませんでした。
1.2 Limitations of the Protocol
1.2 プロトコルの制限
This protocol does not solve every possible routing problem. As mentioned above, it is primarily 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 RIPng is normally configured.
If the system administrator chooses to use larger costs, the upper
bound of 15 can easily become a problem.
- プロトコルは最も長い経路(ネットワークの直径)が15のホップであるネットワークに制限されます。 デザイナーは、より大きいネットワークに、基本プロトコルデザインが不適当であると信じています。 限界のこの声明が、1の費用が各ネットワークに使用されると仮定することに注意してください。 これは通常、RIPngが構成される方法です。 システム管理者が、より大きいコストを使用するのを選ぶなら、15の上限は容易に問題になることができます。
- The protocol depends upon "counting to infinity" to resolve certain
unusual situations (see section 2.2 in [1]). 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.
- プロトコルはある異例の状況を決議するために「無限勘定」であるのによります。([1])でセクション2.2を見てください。 ネットワークのシステムには数100のネットワークがあって、ルーティング輪がそれらに皆、かかわりながら形成されるなら、輪の決議は多くの時間(ルーティングアップデートの頻度が制限されたなら)か帯域幅のどちらかを必要とするでしょうに(変化が検出されたときはいつも、アップデートを送ったなら)。 修正される前にそのような輪は多量のネットワーク回線容量を消費するでしょう。 私たちは、遅い線以外の現実的な場合では、これが問題にならないと信じています。 その時でさえ、問題はかなり珍しくなるでしょう、多くの場合、これらの問題を防ぐべきである様々な注意が払われるので。
- 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.
- このプロトコルは、代替のルートを比較するのに固定「測定基準」を使用します。 状況には、それはルートがリアルタイムのパラメタに基づいてそのような測定遅れ、信頼性を選ぶか、またはロードすることである必要があるところで適切ではありません。 このタイプの測定基準を許す明白な拡大はプロトコルが扱うように設計されていない種類の不安定性を導入しそうです。
Malkin & Minnear Standards Track [Page 3] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[3ページ]RFC2080RIPng
2. Protocol Specification
2. プロトコル仕様
RIPng is intended to allow routers to exchange information for computing routes through an IPv6-based network. RIPng is a distance vector protocol, as described in [1]. RIPng should be implemented only in routers; IPv6 provides other mechanisms for router discovery [10]. Any router that uses RIPng 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 RIPng 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 IPv6 destination address prefix and prefix length associated with it. These are to be set by the system administrator in a manner not specified in this protocol.
RIPngが、ルータがIPv6を拠点とするネットワークを通してルートを計算するために情報交換するのを許容することを意図します。 RIPngは[1]で説明されるように距離ベクトルプロトコルです。 RIPngはルータだけで実行されるべきです。 IPv6はルータ発見[10]に他のメカニズムを提供します。 RIPngを使用するどんなルータもインタフェースを1つ以上のネットワークまで持っていると思われます。さもなければ、それは本当にルータではありません。 これらは直接接続されたネットワークと呼ばれます。 プロトコルはおよそそれぞれこれらのネットワークのある情報へのそれがメートル法であるという中でそれのもの最も重要であることであるアクセスに依存します。 ネットワークにおけるメートル法のRIPngは1〜15の整数的であって、包括的です。 それはこのプロトコルで指定されなかった何らかの方法で設定されます。 しかしながら、15の最大の経路限界を考えて、通常、1の値は使用されます。 実現で、システム管理者はそれぞれのネットワークのメートル法を設定できるべきです。 メートル法に加えて、各ネットワークには、それに関連しているIPv6目的地アドレス接頭語と接頭語の長さがあるでしょう。 これらはこのプロトコルで指定されなかった方法でシステム管理者によって設定されることになっています。
Each router that implements RIPng is assumed to have a routing table. This table has one entry for every destination that is reachable throughout the system operating RIPng. Each entry contains at least the following information:
RIPngを実行する各ルータが経路指定テーブルを持っていると思われます。 このテーブルには、各RIPngを操作しながらシステム中で届いている目的地あたり1つのエントリーがあります。 各エントリーは少なくとも以下の情報を含んでいます:
- The IPv6 prefix of the destination.
- 目的地のIPv6接頭語。
- 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.
- Aメートル法であり、どれがルータからその目的地までデータグラムを手に入れる総費用を表しますか? これほどメートル法であることは、目的地に着くように横断されるネットワークに関連しているコストの合計です。
- The IPv6 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.
- 目的地(すなわち、次のホップ)への次のルータの経路に沿ったIPv6アドレス。 目的地が直接接続されたネットワークの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 2.3 for more
details on timers.
- 様々なタイマはルートと交際しました。 タイマに関するその他の詳細に関してセクション2.3を見てください。
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 RIPng metric reduces to a simple hop-count. More complex metrics may be used when it is desirable to show preference for some
直接接続されたネットワークのためのエントリーはこのプロトコルで指定されなかった手段で集められた情報を使用するルータによってセットアップされます。 直接接続されたネットワークのためのメートル法はそのネットワークの費用に設定されます。 言及されるように、1は普通の費用です。 その場合、RIPng、メートル法、簡単なホップカウントに減少します。 いくつかのために優先するのが望ましいときに、より複雑な測定基準は使用されるかもしれません。
Malkin & Minnear Standards Track [Page 4] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[4ページ]RFC2080RIPng
networks over others (e.g., to indicate of differences in bandwidth or reliability).
他のもの(例えば帯域幅か信頼性の違いについて示す)の上のネットワーク。
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のあらゆるルータがプロトコルに参加しなければなりません。 複数のIGPsが使用中である場合には、プロトコルの間には、ルーティング情報を漏らすことができる少なくとも1つのルータがあるに違いありません。
2.1 Message Format
2.1 メッセージ・フォーマット
RIPng is a UDP-based protocol. Each router that uses RIPng has a routing process that sends and receives datagrams on UDP port number 521, the RIPng port. All communications intended for another router's RIPng process are sent to the RIPng port. All routing update messages are sent from the RIPng port. Unsolicited routing update messages have both the source and destination port equal to the RIPng port. Those 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 RIPng port, but they must be directed to the RIPng port on the target machine.
RIPngはUDPベースのプロトコルです。 RIPngを使用する各ルータがUDPポートNo.521でデータグラムを送って、受けるルーティングの過程を持っています、RIPngポート。 別のルータのRIPngの過程のために意図するすべてのコミュニケーションをRIPngポートに送ります。 RIPngポートからすべてのルーティングアップデートメッセージを送ります。 求められていないルーティングアップデートメッセージには、ソースと仕向港のRIPngポートと等しい両方があります。 要求に対応して送られたものを要求が来たポートに送ります。 RIPngポート以外のポートから特定の質問を送るかもしれませんが、ターゲットマシンの上のRIPngポートにそれらを向けなければなりません。
The RIPng packet format is:
RIPngパケット・フォーマットは以下の通りです。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Route Table Entry 1 (20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Route Table Entry N (20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コマンド(1)| バージョン(1)| ゼロが(2)であったならそうしなければなりません。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ルートテーブルエントリー1(20)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ルートテーブル項目N(20)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Malkin & Minnear Standards Track [Page 5] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[5ページ]RFC2080RIPng
where each Route Table Entry (RTE) has the following format:
各Route Table Entry(RTE)には以下があるところでは、以下をフォーマットしてください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 prefix (16) ~
| |
+---------------------------------------------------------------+
| route tag (2) | prefix len (1)| metric (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IPv6接頭語(16)~| | +---------------------------------------------------------------+ | ルートタグ(2)| 接頭語len(1)| メートル法の(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The maximum number of RTEs is defined below.
RTEsの最大数は以下で定義されます。
Field sizes are given in octets. Unless otherwise specified, fields contain binary integers, in network byte order, with the most- significant octet first (big-endian). Each tick mark represents one bit.
八重奏で分野サイズを与えます。 別の方法で指定されない場合、分野は最初に(ビッグエンディアン)、最も多くの重要な八重奏でネットワークバイトオーダーにおける2進整数を含みます。 各ダニ麻痺は1ビットを表します。
Every message contains a RIPng header which consists of a command and a version number. This document describes version 1 of the protocol (see section 2.4). The command field is used to specify the purpose of this message. The commands implemented in version 1 are:
あらゆるメッセージがコマンドとバージョン番号から成るRIPngヘッダーを含んでいます。 このドキュメントはプロトコルのバージョン1について説明します(セクション2.4を見てください)。 コマンド欄は、このメッセージの目的を指定するのに使用されます。 バージョン1で実行されたコマンドは以下の通りです。
1 - request A request for the responding system to send all or
part of its routing table.
1--応じるシステムがすべてを送るというA要求か経路指定テーブルの一部を要求してください。
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--送付者の経路指定テーブルのすべてか一部を含む応答Aメッセージ。 要求に対応してこのメッセージを送るかもしれませんか、それは送付者によって発生した求められていないルーティングアップデートであるかもしれません。
For each of these message types, the remainder of the datagram contains a list of RTEs. Each RTE in this list contains a destination prefix, the number of significant bits in the prefix, and the cost to reach that destination (metric).
これらのメッセージタイプ各人のために、データグラムの残りはRTEsのリストを含んでいます。 このリストの各RTEは、その目的地(メートル法の)に達するように接頭語、および費用に目的地接頭語、重要なビットの数を含んでいます。
The destination prefix is the usual 128-bit, IPv6 address prefix stored as 16 octets in network byte order.
目的地接頭語は16の八重奏としてネットワークバイトオーダーに格納された128ビットの普通のIPv6アドレス接頭語です。
The route tag 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" RIPng routes (routes for networks within the RIPng routing domain) from "external" RIPng routes, which may have been imported from an EGP or another IGP.
ルートタグ・フィールドは保持しなければならないルートに割り当てられて、ルートで「再-広告を出」す属性です。 ルートタグの意図している使用はEGPか別のIGPから輸入されたかもしれない「外部」のRIPngルートと「内部」のRIPngルート(RIPng経路ドメインの中のネットワークのためのルート)を切り離す方法を提供することです。
Malkin & Minnear Standards Track [Page 6] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[6ページ]RFC2080RIPng
Routers supporting protocols other than RIPng should be configurable to allow the route tag to be configured for routes imported from different sources. For example, routes imported from an EGP 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.
ルートタグがさまざまな原因から輸入されたルートに構成されるのを許容するのにおいてRIPng以外のプロトコルをサポートするルータは構成可能であるべきです。 例えば、EGPから輸入されたルートは任意の値に設定されるか、少なくともルートが学習されたAutonomous Systemの数のどちらかにそれらのルートタグを持っているはずであることができます。
Other uses of the route tag are valid, as long as all routers in the RIPng domain use it consistently.
RIPngドメインのすべてのルータが一貫してそれを使用する限り、ルートタグの他の用途は有効です。
The prefix length field is the length in bits of the significant part of the prefix (a value between 0 and 128 inclusive) starting from the left of the prefix.
接頭語長さの分野は接頭語の左から始める接頭語(0と128の間で包括的な値)のかなりの部分のビットの長さです。
The metric field contains a value between 1 and 15 inclusive, specifying the current metric for the destination; or the value 16 (infinity), which indicates that the destination is not reachable.
目的地における、メートル法の電流を指定して、メートル法の分野は包括的に値を1と15の間含んでいます。 または、値16(無限)。(その値は目的地に届いていないのを示します)。
The maximum datagram size is limited by the MTU of the medium over which the protocol is being used. Since an unsolicited RIPng update is never propagated across a router, there is no danger of an MTU mismatch. The determination of the number of RTEs which may be put into a given message is a function of the medium's MTU, the number of octets of header information preceeding the RIPng message, the size of the RIPng header, and the size of an RTE. The formula is:
最大のデータグラムサイズはプロトコルが使用されている媒体のMTUによって制限されます。 求められていないRIPngアップデートがルータの向こう側に決して伝播されないので、MTUミスマッチという危険が全くありません。 与えられたメッセージに入れられるかもしれないRTEsの数の決断は、媒体のMTUの機能と、RIPngメッセージをpreceedingするヘッダー情報の八重奏の数と、RIPngヘッダーのサイズと、RTEのサイズです。 公式は以下の通りです。
+- -+
| MTU - sizeof(IPv6_hdrs) - UDP_hdrlen - RIPng_hdrlen |
#RTEs = INT | --------------------------------------------------- |
| RTE_size |
+- -+
+- -+ | MTU--sizeof(IPv6_hdrs)--UDP_hdrlen--RIPng_hdrlen| #RTEsはINTと等しいです。| --------------------------------------------------- | | RTE_サイズ| +- -+
2.1.1 Next Hop
2.1.1 次のホップ
RIPng provides the ability to specify the immediate next hop IPv6 address to which packets to a destination specified by a route table entry (RTE) should be forwarded in much the same way as RIP-2 [2]. In RIP-2, each route table entry has a next hop field. Including a next hop field for each RTE in RIPng would nearly double the size of the RTE. Therefore, in RIPng, the next hop is specified by a special RTE and applies to all of the address RTEs following the next hop RTE until the end of the message or until another next hop RTE is encountered.
RIPngはルートテーブルエントリー(RTE)で指定された目的地へのパケットが大体同じようなやり方でRIP-2[2]として送られるべきである次の即座のホップIPv6アドレスを指定する能力を提供します。 RIP-2では、それぞれのルートテーブルエントリーは次のホップ分野を持っています。 RIPngの各RTEのための次のホップ分野を含んでいると、RTEのサイズはほとんど倍増するでしょう。 したがって、メッセージの終わりまで次のホップRTEに続いて、次のホップが、RIPngでは、特別なRTEによって指定されて、アドレスのすべてにRTEsを適用するか、または別のものまで、次のホップRTEは遭遇します。
A next hop RTE is identified by a value of 0xFF in the metric field of an RTE. The prefix field specifies the IPv6 address of the next hop. The route tag and prefix length in the next hop RTE must be set to zero on sending and ignored on receiption.
次のホップRTEはRTEのメートル法の分野の0xFFの値によって特定されます。 接頭語分野は次のホップのIPv6アドレスを指定します。 次のホップRTEのルートタグと接頭語の長さを発信のゼロに設定されて、receiptionで無視しなければなりません。
Malkin & Minnear Standards Track [Page 7] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[7ページ]RFC2080RIPng
The next hop Route Table Entry (RTE) has the following format:
次のホップRoute Table Entry(RTE)には、以下の形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 next hop address (16) ~
| |
+---------------------------------------------------------------+
| must be zero (2) |must be zero(1)| 0xFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 次のIPv6はアドレス(16)~、を飛び越します。| | +---------------------------------------------------------------+ | ゼロが(2)であったならそうしなければなりません。|ゼロが(1)であったならそうしなければなりません。| 0xFF| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Specifying a value of 0:0:0:0:0:0:0:0 in the prefix field of a next hop RTE indicates that the next hop address should be the originator of the RIPng advertisement. An address specified as a next hop must be a link-local address.
値を指定する、0:0:、0:0:0、:、0:0:0、接頭語で、次のホップRTEの分野は、次のホップアドレスがRIPng広告の創始者であるべきであることを示します。 アドレスは、次のホップがリンクローカルアドレスであるに違いないので、指定しました。
The purpose of the next hop RTE is to eliminate packets being routed through extra hops in the system. It is particularly useful when RIPng is not being run on all of the routers on a network. Note that next hop RTE is "advisory". That is, if the provided information is ignored, a possibly sub-optimal, but absolutely valid, route may be taken. If the received next hop address is not a link-local address, it should be treated as 0:0:0:0:0:0:0:0.
次のホップRTEの目的はシステムの余分なホップを通して発送されるパケットを排除することです。 RIPngがネットワークのルータのすべてにおける走行でないときに、それは特に役に立ちます。 次のホップRTEが「顧問である」と述べてください。 すなわち、提供された情報を無視するなら、ことによるとサブ最適の、しかし、絶対に有効なルートを取るかもしれません。 次の受け取られていているホップアドレスがリンクローカルアドレスでないなら、それとして扱われるべきである、0:0:、0:0:0、:、0:0:0
2.2 Addressing Considerations
2.2 問題を記述すること。
The distinction between network, subnet and host routes does not need to be made for RIPng because an IPv6 address prefix is unambiguous.
IPv6アドレス接頭語が明白であるので、RIPngのためにネットワークと、サブネットとホストルートの区別は作られている必要はありません。
Any prefix with a prefix length of zero is used to designate a default route. It is suggested that the prefix 0:0:0:0:0:0:0:0 be used when specifying the default route, though the prefix is essentially ignored. A default route is used when it is not convenient to list every possible network in the RIPng updates, and when one or more routers in the system are prepared to handle traffic to the networks that are not explicitly listed. These "default routers" use the default route as a path for all datagrams for which they have no explicit route. The decision as to how a router becomes a default router (i.e., how a default route entry is created) is left to the implementor. In general, the system administrator will be provided with a way to specify which routers should create and advertise default route entries. If this mechanism is used, the implementation should allow the network administrator to choose the metric associated with the default route advertisement. This will make it possible to establish a precedence amoung multiple default routers. The default route entries are handled by RIPng in exactly the same manner as any other destination prefix. System
ゼロの接頭語の長さがあるどんな接頭語も、デフォルトルートを指定するのに使用されます。 それが示される、それ、接頭語、0:0:、0:0:0、:、0:0:0、デフォルトルートを指定するときには、接頭語は本質的には無視されますが、使用されてください。 RIPngアップデートであらゆる可能なネットワークを記載するのが便利でなく、システムの1つ以上のルータが明らかに記載されていないネットワークへの交通を扱うために準備されるとき、デフォルトルートは使用されています。 これらの「デフォルトルータ」はそれらにはどんな明白なルートもないすべてのデータグラムに経路としてデフォルトルートを使用します。 ルータがどうデフォルトルータ(すなわち、デフォルトルートエントリーはどう作成される)になるかに関する決定は作成者に任せます。 一般に、どのルータがデフォルトルートエントリーを作成して、広告を出すべきであるかを指定する方法をシステム管理者に提供するでしょう。 このメカニズムが使用されているなら、実現で、ネットワーク管理者はデフォルトルート広告に関連しているメートル法を選ぶことができるべきです。 これで、先行amoung複数のデフォルトルータを確立するのは可能になるでしょう。 デフォルトルートエントリーはまさにいかなる他の目的地接頭語とも同じ方法でRIPngによって扱われます。 システム
Malkin & Minnear Standards Track [Page 8] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[8ページ]RFC2080RIPng
administrators should take care to make sure that default routes do not propagate further than is intended. Generally, each AS has its own preferred default router. Therefore, default routes should generally not leave the boundary of an AS. The mechanisms for enforcing this restriction are not specified in this document.
管理者は、デフォルトルートが意図するより遠くに伝播されないのを確実にするために注意するべきです。 一般に、各ASには、それ自身の都合のよいデフォルトルータがあります。 したがって、一般に、デフォルトルートはASの境界を残すはずがありません。 この制限を実施するためのメカニズムは本書では指定されません。
2.3 Timers
2.3 タイマ
This section describes all events that are triggered by timers.
このセクションはタイマによって引き起こされるすべての出来事について説明します。
Every 30 seconds, the RIPng process is awakened to send an unsolicited Response message, containing the complete routing table (see section 2.6 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 (see [13] for more details). Therefore, implementations are required to take one of two precautions:
RIPngの過程は求められていないResponseメッセージを送るために目を覚まします、完全な経路指定テーブルを含んでいて(Split Horizonの上のセクション2.6を見てください)、30秒毎、あらゆる隣接しているルータに。 多くのルータがただ一つのネットワークにあるとき、互いに連動する傾向があるので、それらは皆、同時に、アップデートを発行します。 30 2番目のタイマがシステムの上の処理負荷で影響を受けるときはいつも、これは起こることができます。 連動するようになるアップデートメッセージに、それは望ましくありません、放送網における不要な衝突に通じることができるので(その他の詳細のための[13]を見てください)。 したがって、実現が2つの注意の1つを取るのに必要です:
- 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 15
seconds) each time it is set. The offset is derived from: 0.5 *
the update period (i.e. 30).
- それが設定されるたびに30秒のタイマは小さい無作為の時間(+/-0〜15秒)までに相殺されます。 オフセットは以下から引き出されます。 0.5、*、アップデートの期間(すなわち、30)。
There are two timers associated with each route, a "timeout" and a "garbage-collection time." Upon expiration of the timeout, the route is no longer valid; however, it is retained in the routing table for a short time so that neighbors can be notified that the route has been dropped. Upon expiration of the garbage-collection timer, the route is finally removed from the routing table.
各ルート、「タイムアウト」、および「ガーベージコレクション時間」に関連している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秒がタイムアウトが初期化された最後の時から経過するなら、ルートが期限が切れたと考えられて、以下で説明された削除の過程はそのルートに始まります。
Malkin & Minnear Standards Track [Page 9] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[9ページ]RFC2080RIPng
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 2.4.2 for a discussion of processing updates from other routers). In either case, the following events happen:
削除は2つの理由の1つで起こることができます: タイムアウトが期限が切れるか、またはメートル法は現在のルータから受けられたアップデートのために16に設定されます(処理アップデートの議論に関して他のルータからセクション2.4.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 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 2.5.1.
また、引き起こされたアップデートは三流の人を使用します。 セクション2.5.1でしかしながら、これについて説明するのは最も良いです。
2.4 Input Processing
2.4 入力処理
This section will describe the handling of datagrams received on the RIPng port. Processing will depend upon the value in the command field. Version 1 supports only two commands: Request and Response.
このセクションはRIPngポートの上に受け取られたデータグラムの取り扱いについて説明するでしょう。 処理はコマンド欄の値に依存するでしょう。 バージョン1は2つのコマンドだけをサポートします: 要求と応答。
2.4.1 Request Messages
2.4.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 multicasts, from the RIPng 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 RIPng port. If such a Request is received, the router responds directly to the requestor's address and port with a globally valid source address since the requestor may not reside on the directly attached network.
Requestは、ルータの経路指定テーブルのすべてか一部を含む応答を求めるのに使用されます。 通常、マルチキャストとしてRequestsを送ります、RIPngポートから、ちょうど来て、できるだけはやくそれらの経路指定テーブルに記入しようとしているルータで。 しかしながら、状況(例えば、ルータモニター)がただ一つのルータだけの経路指定テーブルが必要であるところにあるかもしれません。 この場合、RequestをRIPngポート以外のUDPポートから直接そのルータに送るべきです。 そのようなRequestが受け取られているなら、要請者が直接付属しているネットワークに住まないかもしれないので、ルータはグローバルに有効なソースアドレスで直接要請者のアドレスとポートに応じます。
Malkin & Minnear Standards Track [Page 10] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[10ページ]RFC2080RIPng
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 a destination prefix of zero, a prefix length 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.
エントリーによってRequestは処理エントリーです。 エントリーが全くなければ、応答を全く与えません。 1つの特別なケースがあります。 要求における、あるエントリーがまさにあって、ゼロの目的地接頭語を持っているなら、無限(すなわち、16)におけるメートル法のゼロ、およびaの接頭語の長さに、これは全体の経路指定テーブルを送るという要求です。 その場合、要求アドレス/ポートに経路指定テーブルを送るのを出力の過程に電話をかけます。 この特別なケースを除いて、処理はかなり簡単です。 RequestでRTEsのリストをひとつずつ調べてください。 各エントリーに、ルータのルーティングデータベースの目的地を見上げてください、そして、ルートがあれば、RTEのメートル法の分野にメートル法であることでルートのそのものを置いてください。 指定された目的地へのどんな明白なルートもなければ、メートル法の分野に無限を置いてください。 一度すべてのエントリーが、記入されて、コマンドをRequestからResponseに変えて、データグラムを要請者に送り返します。
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 2.6 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.
特定の、そして、全体のテーブルの要求のためのメートル法の取り扱いの違いがあることに注意してください。 要求が完全な経路指定テーブルのためのものであるなら、基準出力処理をします、Split Horizonを含んでいて(Split Horizonの上のセクション2.6を見てください)。 特定のエントリーに要求があるなら、経路指定テーブルでそれらを調べます、そして、そのままで情報を返します。 処理が行われるSplit Horizonがありません。 この区別の理由は異なる役割に使用されて、おそらくこれらの要求がある期待です。 ルータであるときに、1番目は来て、それは完全な経路指定テーブルを求めるあらゆる接続ネットワークのマルチキャストa Requestです。 これらの完全な経路指定テーブルが要請者の経路指定テーブルをアップデートするのに使用されることになっていると思われます。 この理由で、Split Horizonをしなければなりません。 特定のネットワークのためのRequestが診断ソフトウェアだけによって作られて、ルーティングに使用されないとさらに思われます。 この場合、リクエスタは、経路指定テーブルの正確なコンテンツを知りたくて、どんな情報も隠されるか、または変更するのを必要がないでしょう。
2.4.2 Response Messages
2.4.2 応答メッセージ
A Response can be received for one of several different reasons:
いくつかの異なった理由の1つによってResponseを受け取ることができます:
- 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.
Responseがなぜ発生したとしても、処理は同じです。
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 RIPng port. The datagram's IPv6 source address should be checked to see whether the datagram is from a valid neighbor; the source of the datagram must be a link-local address. It is also worth checking to see whether the
Responseの処理がルータの経路指定テーブルをアップデートするかもしれないので、正当性がないかどうか丹念にResponseをチェックしなければなりません。 RIPngポートから来ていないなら、Responseを無視しなければなりません。 データグラムのIPv6ソースアドレスはデータグラムが有効な隣人から来ているかを確認するためにチェックされるべきです。 データグラムの源はリンクローカルアドレスであるに違いありません。 また、見るためにチェックする価値があります。
Malkin & Minnear Standards Track [Page 11] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[11ページ]RFC2080RIPng
response is from one of the router's own addresses. Interfaces on broadcast networks may receive copies of their own multicasts immediately. If a router processes its own output as new input, confusion is likely, and such datagrams must be ignored. As an additional check, periodic advertisements must have their hop counts set to 255, and inbound, multicast packets sent from the RIPng port (i.e. periodic advertisement or triggered update packets) must be examined to ensure that the hop count is 255. This absolutely guarantees that a packet is from a neighbor, because any intermediate node would have decremented the hop count. Queries and their responses may still cross intermediate nodes and therefore do not require the hop count test to be done.
応答はルータの自己のアドレスの1つから来ています。 放送網のインタフェースはすぐに、それら自身のマルチキャストのコピーを受けるかもしれません。 ルータが新しい入力としてそれ自身の出力を処理するなら、混乱はありそうです、そして、そのようなデータグラムを無視しなければなりません。 追加チェック、周期的な広告が調べなければならないように、カウントが255に設定するそれらのホップ、およびRIPngポートから送られた本国行きのマルチキャストパケット(すなわち、周期的な広告か引き起こされたアップデートパケット)は、ホップカウントが255であることを保証するために調べられたに違いありません。 どんな中間的ノードもホップカウントを減少させたでしょう、したがって、これはパケットが隣人から来ているのを絶対に保証します。 質問と彼らの応答は、まだ中間的ノードに交差しているかもしれなくて、したがって、ホップカウントテストが完了しているのを必要としません。
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:
全体でデータグラムがいったん有効にされた後、ResponseでRTEsをひとつずつ処理してください。 もう一度、合法化することによって、始まってください。 不正確な測定基準と他の形式誤りは、通常、ふらちな事をしている隣人を示して、たぶんアドミニストレータのものに注目していただかれるべきです。 例えば、メートル法が無限より大きいなら、エントリーを無視しなさい、ただし、出来事を登録してください。 基本的な合法化テストは以下の通りです。
- is the destination prefix valid (e.g., not a multicast prefix and
not a link-local address) A link-local address should never be
present in an RTE.
- is the prefix length valid (i.e., between 0 and 128, inclusive)
- is the metric valid (i.e., between 1 and 16, inclusive)
- 有効な(例えば、リンクローカルアドレスではなく、マルチキャスト接頭語でない)Aリンクローカルアドレスが決して現在であるべきでない目的地接頭語はRTEですか? - 接頭語の長さが有効である、(すなわち、0〜128、包括的である、)、--メートル法が有効である(すなわち、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,
エントリーがいったん有効にされた後、メッセージが到着したネットワークの費用を加えることによって、メートル法をアップデートしてください。 結果が無限より大きいなら、無限を使用してください。 That is,
metric = MIN (metric + cost, infinity)
メートル法の=MIN(メートル法の+費用、無限)
Now, check to see whether there is already an explicit route for the destination prefix. 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 unusable). Adding a route to the routing table consists of:
今度は、チェックして、目的地接頭語に関して明白なルートが既にあるかどうか確認してください。 そのようなルートが全くなければ、このルートを経路指定テーブルに加えてください、メートル法が無限(aがどれを発送するかと言い足す使用不可能などんな意味もない)でないなら。 経路指定テーブルにルートを加えるのは以下から成ります。
- Setting the destination prefix and length to those in the RTE.
- 目的地接頭語と長さをRTEのそれらに設定します。
- Setting the metric to the newly calculated metric (as described
above).
- 新たにメートル法で(上で説明されるように)計算されているのにメートル法を設定します。
Malkin & Minnear Standards Track [Page 12] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[12ページ]RFC2080RIPng
- Set the next hop address to be the address of the router from which
the datagram came or the next hop address specified by a next hop
RTE.
- 次のホップアドレスにデータグラムが来たか、または次のホップアドレスが次のホップRTEで指定したルータのアドレスであるように設定してください。
- Initialize the timeout for the route. If the garbage-collection
timer is running for this route, stop it (see section 2.3 for a
discussion of the timers).
- タイムアウトをルートに初期化してください。 ガーベージコレクションタイマがこのルートに立候補しているなら、それを止めてください(タイマの議論に関してセクション2.3を見てください)。
- Set the route change flag.
- ルート変化旗を設定してください。
- Signal the output process to trigger an update (see section 2.5).
- アップデートの引き金となるように出力の過程に合図してください(セクション2.5を見てください)。
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. That is, 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 reinitializing 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.
新しくメートル法が古い方と同じであるなら、さらに(上で指定されるとしてタイムアウトを再初期化することを超えて)何もしないのは最も簡単です。 しかし、適用できたヒューリスティックがあります。 通常、同じくらいが新しいルートで既存のルートとしてメートル法になるなら、ルートを置き換えるのは無意味です。 これで、ルートは前後まで弾むでしょう(堪え難い数の引き起こされたアップデートを発生させるでしょう)。 しかしながら、既存のルートがタイミングのサインを送り出しているなら、タイムアウトが起こるのを待っているよりすぐに、むしろ等しく良い代替のルートに切り替わるほうがよいかもしれません。 したがって、新しくメートル法が古い方と同じであるなら、既存のルートがないかどうかタイムアウトを調べてください。 それが満了ポイントに少なくとも途中なら、新しいルートに切り替わってください。 このヒューリスティックは、任意ですが、非常にお勧めです。
Malkin & Minnear Standards Track [Page 13] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[13ページ]RFC2080RIPng
Any entry that fails these tests is ignored, as it is no better than the current route.
それが現在のルートより良いというわけではないので、これらのテストに失敗するどんなエントリーも無視されます。
2.5 Output Processing
2.5出力処理
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. In this case, the
Response is sent to only one destination (i.e. the unicast address
of the requestor).
- Requestが受け取られているときの入力処理で。 この場合、1つの目的地(すなわち、要請者のユニキャストアドレス)だけにResponseを送ります。
- By the regular routing update. Every 30 seconds, a Response
containing the whole routing table is sent to every neighboring
router.
- 定期的なルーティングアップデートで。 30秒毎に、全体の経路指定テーブルを含むResponseをあらゆる隣接しているルータに送ります。
- By triggered updates. Whenever the metric for a route is changed,
an update is triggered.
- 引き起こされたアップデートで。 ルートへのメートル法を変えて、アップデートを引き起こすときはいつも。
The special processing required for a Request is described in section 2.4.1.
Requestに必要である特別な処理はセクション2.4.1で説明されます。
When a Response is to be sent to all neighbors (i.e., a regular or triggered update), a Response message is multicast to the multicast group FF02::9, the all-rip-routers multicast group, on all connected networks that support broadcasting or are point-to-point links. RIPng handles point-to-point links just like multicast links as multicasting can be trivially provided on such links. Thus, one Response is prepared for each directly-connected network, and sent to the all-rip-routers multicast group. 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.
Responseがすべての隣人(すなわち、通常の、または、引き起こされたアップデート)に送られることになっているとき、ResponseメッセージはマルチキャストグループFF02へのマルチキャストです:、:9、すべてに関するオールルータを裂いているマルチキャストグループは放送するのを支持するか、ポイントツーポイント接続であるネットワークを接続しました。 RIPngはそのようなリンクの上にマルチキャスティングを些細なことに提供できるようにまさしくマルチキャストリンクのようなポイントツーポイント接続を扱います。 したがって、1Responseをそれぞれの直接接続されたネットワークのために準備して、オールルータを裂いているマルチキャストグループに送ります。 多くの場合、これはすべての隣接しているルータに達します。 しかしながら、いくつかのケースがこれが十分良くないかもしれないところにあります。 これは放送網(例えば、アルパネット)でなくて、またまたは馬鹿なルータにかかわる状況でもないネットワークにかかわるかもしれません。 そのような場合、隣接しているルータの実際のリストを指定して、明らかにデータグラムをそれぞれに送るのが必要であるかもしれません。 そのようなメカニズムが必要であるかどうか決定して、それがリストがどう指定されるかを定義するのが作成者に残されます。
2.5.1 Triggered Updates
2.5.1 引き起こされたアップデート
Triggered updates require special handling for two reasons. First, experience shows that triggered updates can cause excessive loads 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
引き起こされたアップデートは2つの理由で特別な取り扱いを必要とします。 まず最初に、経験は、それらの上に多くのルータがある状態で引き起こされたアップデートが収容数の限界かネットワークと共にネットワークで負担過重を引き起こす場合があるのを示します。 したがって、プロトコルは、作成者が引き起こされたアップデートの頻度を制限するために条項を入れるのを必要とします。 引き起こされたアップデートを送った後に、無作為の間隔の間、タイマを1〜5秒設定するべきです。 アップデートの引き金となる他の変化が起こるなら
Malkin & Minnear Standards Track [Page 14] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[14ページ]RFC2080RIPng
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. Triggered updates may be suppressed if a regular update is due by the time the triggered update would be sent.
タイマが期限が切れる前に、タイマが期限が切れるとき、ただ一つのアップデートは引き起こされます。 そして、タイマは別の無作為の値に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 2.6). 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.
2番目に、引き起こされたアップデートは全体の経路指定テーブルを含む必要はありません。 変化したそれらのルートだけが、含まれる必要があります。 したがって、引き起こされたアップデートの一部が少なくともそれらのルート変化旗を持っているそれらのルートを含まなければならないとき発生するメッセージはセットしました。 彼らは作成者の裁量で追加ルートを含むかもしれません。 しかしながら、完全なルーティングアップデートを送るのは強くお勧めできないです。 引き起こされたアップデートが処理されるとき、メッセージはあらゆる直接接続されたネットワークのために発生するべきです。 発生が通常のアップデートと同様にアップデートの引き金となったとき(セクション2.6を見てください)、分裂Horizon処理をします。 変えられたルートが与えられたネットワークのためのSplit Horizon処理の後にそのネットワークで変わりがなく見えるなら(無限がメートル法で例えばそれは現れます)、ルートを送る必要はありません。 そのネットワークでルートを全く送る必要はないなら、アップデートを省略するかもしれません。 引き起こされたアップデートのすべてがいったん発生すると、ルート変化旗はきれいにされるべきです。
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.
引き起こされたアップデートと他のアップデートメッセージの唯一の違いは変化していないルートの可能な省略です。 次のセクションで説明された残っているメカニズムをすべてのアップデートに適用しなければなりません。
2.5.2 Generating Response Messages
2.5.2 応答メッセージを発生させること。
This section describes how a Response message is generated for a particular directly-connected network:
このセクションはResponseメッセージが特定の直接接続されたネットワークのためにどう発生するかを説明します:
The IPv6 source address must be a link-local address of the possible addresses of the sending router's interface, except when replying to a unicast Request Message from a port other than the RIPng port. In the latter case, the source address must be a globaly valid address. In the former case, it is important to use a link-local address because the source address is put into routing tables (as the next hop) in the routers which receive this Response. If an incorrect source address is used, other routers may be unable to route datagrams. Sometimes routers are set up with multiple IPv6 addresses on a single physical interface. Normally, this means that several logical IPv6 networks are being carried over one physical medium. It is possible that a router may have multiple link-local addresses for
IPv6ソースアドレスは送付ルータのインタフェースの可能なアドレスのリンクローカルアドレスであるに違いありません、RIPngポート以外のポートからユニキャストRequest Messageに答える時を除いて。 後者の場合では、ソースアドレスはglobalyに有効なアドレスであるに違いありません。 前の場合では、リンクローカルアドレスを使用するのは、このResponseを受けるルータで経路指定テーブル(次のホップとしての)にソースアドレスを入れるので、重要です。 不正確なソースアドレスが使用されているなら、他のルータはデータグラムを発送できないかもしれません。時々、ルータは単一の物理インターフェースに関する複数のIPv6アドレスでセットアップされます。 通常、これは、いくつかの論理的なIPv6ネットワークが1人の物理的な媒体の上まで運ばれることを意味します。 それはルータには複数のリンクローカルのアドレスがあるかもしれないのが可能です。
Malkin & Minnear Standards Track [Page 15] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[15ページ]RFC2080RIPng
a single interface. In this case, the router must only originate a single Response message with a source address of the designated link-local address for a given interface. The choice of which link- local address to use should only change when the current choice is no longer valid. This is necessary because nodes receiving Response messages use the source address to identify the sender. If multiple packets from the same router contain different source addresses, nodes will assume they come from different routers, leading to undesirable behavior.
単一のインタフェース。 この場合、ルータは指定されたリンクローカルアドレスのソースアドレスでただ一つのResponseメッセージを与えられたインタフェースに溯源するだけでよいです。 選択は、どのリンクローカルアドレスを使用するかを現在の選択がいつもう有効でないかを変えるだけであるべきです。 Responseメッセージを受け取るノードが送付者を特定するのにソースアドレスを使用するので、これが必要です。 同じルータからの複数のパケットが異なったソースアドレスを含んでいると、ノードは、異なったルータから来ると仮定するでしょう、好ましくない行動に通じて。
Set the version number to the current version of RIPng. The version described in this document is version 1. Set the command to Response. Set the bytes labeled "must be zero" to zero. Start filling in RTEs. Recall that the maximum datagram size is limited by the network's MTU. When there is no more space in the datagram, send the current Response and start a new one.
RIPngの最新版にバージョン番号を設定してください。 本書では説明されたバージョンはバージョン1です。 Responseにコマンドを設定してください。 バイトがラベルしたセットはゼロへの「ゼロでなければなりません」。 RTEsに記入し始めてください。 最大のデータグラムサイズがネットワークのMTUによって制限されると思い出してください。 それ以上のスペースが全くデータグラムにないとき、現在のResponseを送ってください、そして、新しいものを始めてください。
To fill in the RTEs, examine each route in the routing table. Routes to link-local addresses must never be included in an RTE. 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 prefix, prefix length, and metric are put into the RTE. The route tag is filled in as defined in section 2.1. Routes must be included in the datagram even if their metrics are infinite.
RTEsに記入するには、経路指定テーブルの各ルートを調べてください。 RTEにリンクローカルのアドレスへのルートを決して含んではいけません。 引き起こされたアップデートが発生しているなら、ルート変化旗が設定されるエントリーだけが含まれなければなりません。 Split Horizon処理の後にルートを含んでいないなら、それをスキップしてください。 ルートが含まれることであるなら、接頭語の長さの、そして、メートル法の目的地接頭語はそうです。RTEに入れます。 ルートタグはセクション2.1で定義されるように記入されます。 それらの測定基準が無限であっても、データグラムにルートを含まなければなりません。
2.6 Split Horizon
2.6 分裂地平線
Split Horizon is a algorithm for avoiding problems caused by including routes in updates sent to the gateway from which they were learned. The basic split horizon algorithm omits routes learned from one neighbor in updates sent to that neighbor. In the case of a broadcast network, all routes learned from any neighbor on that network are omitted from updates sent on that network.
分裂Horizonは、それらが学習されたゲートウェイに送られたアップデートにルートを含んでいることによって引き起こされた問題を避けるためのアルゴリズムです。 基本的な分裂地平線アルゴリズムは1人の隣人からその隣人に送られたアップデートで学習されたルートを省略します。 放送網の場合では、そのネットワークでどんな隣人からも学習されたすべてのルートがそのネットワークで送られたアップデートから省略されます。
Split Horizon with Poisoned Reverse (more simply, Poison Reverse) does include such routes in updates, but sets their metrics to infinity. In effect, advertising the fact that there routes are not reachable. This is the preferred method of operation; however, implementations should provide a per-interface control allowing no horizoning, split horizoning, and poisoned reverse to be selected.
Poisoned Reverseと共にHorizonを分割してください、(より簡単である、Poison Reverse) アップデートにそのようなルートを含んでいますが、それらの測定基準を無限で設定します。 事実上、そこでは、ルートが届いていないという事実の広告を出すこと。 これは操作の適した方法です。 しかしながら、horizoning、分裂horizoning、およびどんな当たっている逆も選択されないのを許容しながら、実現はインタフェース・コントロールを提供するべきです。
For a theoretical discussion of Split Horizon and Poison Reverse, and why they are needed, see section 2.1.1 of [1].
Split HorizonとPoison Reverseの理論上の議論、およびそれらが必要である理由には、[1]についてセクション2.1.1を見てください。
Malkin & Minnear Standards Track [Page 16] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[16ページ]RFC2080RIPng
3. Control Functions
3. コントロール機能
This section describes administrative controls. These are not part of the protocol per se; however, experience with existing networks suggests that they are important. Because they are not a necessary part of the protocol, they are considered optional. However, it is strongly recommend that at least some of them be included in every implementation. These controls are intended primarily to allow RIPng to be connected to networks whose routing may be unstable or subject to errors. Here are some examples:
このセクションは運営管理コントロールについて説明します。 これらはそういうもののプロトコルの一部ではありません。 しかしながら、既存のネットワークの経験は、それらが重要であると示唆します。 プロトコルの必要な部分でないので、それらは任意であると考えられます。 しかしながら、それは少なくともそれらのいくつかがあらゆる実現に含まれることを強く勧めることです。 これらのコントロールが、RIPngがルーティングが不安定であるかもしれないネットワークか誤りを条件として接続されるのを主として許容することを意図します。 ここに、いくつかの例があります:
- It is sometimes desirable to restrict the routers from which
updates will be accepted, or to which updates will be sent. This
is usually done for administrative, routing policy reasons.
- アップデートが受け入れられるか、またはアップデートが送られるルータを制限するのは時々望ましいです。 通常、管理の、そして、掘っている方針理由でこれをします。
- A number of sites limit the set of networks that they allow in
Response messages. Organization A may have a connection to
organization B that they use for direct communication. For security
or performance reasons A may not be willing to give other
organizations access to that connection. In such a case, A should
not include B's networks in updates that A sends to third parties.
- 多くのサイトがそれらがResponseメッセージに許容するネットワークのセットを制限します。 彼らがダイレクトコミュニケーションに使用する組織Bには組織Aが接続があるかもしれません。 セキュリティか性能において、理由Aはその接続への他の組織アクセスを与えることを望んでいないかもしれません。 このような場合には、AはAが第三者に送るアップデートにビーズネットワークを含むべきではありません。
Here are some typical controls. Note, however, that the RIPng protocol does not require these or any other controls.
ここに、いくつかの典型的なコントロールがあります。 しかしながら、RIPngプロトコルがこれらかいかなる他のコントロールも必要としないことに注意してください。
- A neighbor list which allows the network administrator to be able
to define a list of neighbors for each router. A router would
accept response messages only from routers on its list of
neighbors. A similar list for target routers should also be
available to the administrator. By default, no restrictions are
defined.
- ネットワーク管理者が各ルータのために隣人のリストを定義できるのを許容する隣人リスト。 ルータは隣人のリストで単にルータから応答メッセージを受け入れるでしょう。 また、管理者にとって、目標ルータのための同様のリストも利用可能であるべきです。 デフォルトで、制限は全く定義されません。
- A filter for specific destinations would permit the network admin-
istrator to be able to specify a list of destination prefixes to
allow or disallow. The list would be associated with a particular
interface in the incoming and/or outgoing directions. Only allowed
networks would be mentioned in Response messages going out or
processed in Response messages coming in. If a list of allowed
prefixes is specified, all other prefixes are disallowed. If a list
of disallowed prefixes is specified, all other prefixes are
allowed. By default, no filters are applied.
- 特定の目的地へのフィルタは、ネットワークアドミンistratorが許容するか、または禁じる目的地接頭語のリストを指定できるのを可能にするでしょう。 リストは入って来るそして/または、送信する指示で特定のインタフェースに関連しているでしょう。 許容ネットワークだけが、入りながら、出かけるResponseメッセージで言及されるか、またはResponseメッセージで処理されるでしょう。 許容接頭語のリストが指定されるなら、他のすべての接頭語が禁じられます。 禁じられた接頭語のリストが指定されるなら、他のすべての接頭語が許容されています。 デフォルトで、どんなフィルタも適用されていません。
Malkin & Minnear Standards Track [Page 17] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[17ページ]RFC2080RIPng
4. Security Considerations
4. セキュリティ問題
Since RIPng runs over IPv6, RIPng relies on the IP Authentication Header (see [11]) and the IP Encapsulating Security Payload (see [12]) to ensure integrity and authentication/confidentiality of routing exchanges.
[11])とIP Encapsulating Security有効搭載量を見てください。RIPngがIPv6をひくのでRIPngがIP Authentication Headerを当てにする、((ルーティング交換の保全と認証/秘密性を確実にする[12])を見てください。
References
参照
[1] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
University, June 1988.
[1] ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、ラトガース大学、1988年6月。
[2] Malkin, G., "RIP Version 2 - Carrying Additional Information",
RFC 1723, Xylogics, Inc., November, 1994.
[2] マルキン、G.が「追加情報を運んで、バージョン2をコピーする」、RFC1723、Xylogics Inc.、11月、1994
[3] Hinden, R., "IP Next Generation Overview",
Work in Progress.
[3] R.、「IP次世代概観」というHindenは進行中で働いています。
[4] Bellman, R., "Dynamic Programming", Princeton University
Press, Princeton, N.J., 1957.
[4] 触れ役、R.、「動的計画法」、プリンストン大学出版局、プリンストン、ニュージャージー州1957。
[5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice-
Hall, Englewood Cliffs, N.J., 1987.
[5] Bertsekas、D.P.とガラハー、R.G.、「データ網」、新米ホール、イングルウッドがけニュージャージー州、1987
[6] Braden, R., and J. Postel, "Requirements for Internet Gateways",
USC/Information Sciences Institute, STD 4, RFC 1009, June 1987.
[6] ブレーデン、R.とJ.ポステル、「インターネットゲートウェイのための要件」USC/情報科学研究所、STD4、RFC1009、1987年6月。
[7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M.,
"Pup: An Internetwork Architecture", IEEE Transactions on Commu-
nications, April 1980.
[7] ボッグズとD.R.とShochとJ.F.とタフト、E.A.とメトカルフェ、R.M.、「産んでください」 「Internetwork Architecture」、Commu- nicationsの上のIEEE Transactions、1980年4月。
[8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
Princeton University Press, Princeton, N.J., 1962.
[8] フォード、L.R.Jr.とフルカーソン、D.R.、「ネットワークの流れ」プリンストン大学出版局、プリンストン、ニュージャージー州1962。
[9] Xerox Corp., "Internet Transport Protocols", Xerox System Inte-
gration Standard XSIS 028112, December 1981.
[9]ゼロックス社、「インターネットトランスポート・プロトコル」、ゼロックスSystem Inte- gration Standard XSIS028112、1981年12月。
[10] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 1970, August 1996.
[10]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC1970、1996年8月。
[11] Atkinson, R., "IP Authentication Header", RFC 1826
Naval Research Laboratory, August 1995.
[11] アトキンソン、R.、「IP認証ヘッダー」、RFC1826海軍研究試験所、1995年8月。
Malkin & Minnear Standards Track [Page 18] RFC 2080 RIPng for IPv6 January 1997
IPv6 January 1997のためのマルキンとMinnear標準化過程[18ページ]RFC2080RIPng
[12] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 1827, Naval Research Laboratory, August 1995.
[12] アトキンソン、R.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC1827、海軍研究試験所、1995年8月。
[13] Floyd, S., and Jacobson, V., "The Synchronization of Periodic
Routing Messages", Proceedings of ACM SIGCOMM '93, September
1993.
ACM SIGCOMM93年、1993年9月の[13] フロイド、S.とジェーコブソン、V.、「周期的なルーティング・メッセージの同期」議事。
Authors' Addresses
作者のアドレス
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
Robert E. Minnear Ipsilon Networks, Inc. 2191 E. Bayshore Road, Suite 100 Palo Alto, CA 94303
ロバートE.Minnear IpsilonはInc.2191E.Bayshore道路、パロアルト、Suite100カリフォルニア 94303をネットワークでつなぎます。
Phone: (415) 846-4614 EMail: minnear@ipsilon.com
以下に電話をしてください。 (415) 846-4614 メールしてください: minnear@ipsilon.com
Malkin & Minnear Standards Track [Page 19]
マルキンとMinnear標準化過程[19ページ]
一覧
スポンサーリンク
