この文書はRFC2080の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group G. Malkin
Request for Comments: 2080 Xylogics
Category: Standards Track R. Minnear
Ipsilon Networks
January 1997
RIPng for IPv6
ＩＰｖ６のためのＲＩＰｎｇ
Status of this Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
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.
この文書はＩＰｖ６インターネットのためのルーティングプロトコルを指定
します。これはＩＰｖ４インターネットで現在広く使用中のプロトコルとア
ルゴリズムに基づいています。
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].
この仕様書は、RFC 1058[1]とRFC 1723[2]で指定されるルーティングインフォ
メーションプロトコル（RIP）に対する、ＩＰｖ６[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.
この文書は、チャック・ヘドリックによって書かれてRFC 1058[1]の修正バー
ジョンです。修正はRIP-2とＩＰｖ６拡張を反映します、しかしオリジナルの
言葉遣いは彼のです。
We'd like to thank Dennis Ferguson and Thomas Narten for their input.
我々はデニス・ファーガソンとトーマス・ナーテンのインプットに感謝します。
Table of Contents
目次
1. Introduction （はじめに）
1.1 Theoretical Underpinnings （理論的な柱）
1.2 Limitations of the Protocol （プロトコルの限界）
2. Protocol Specification （プロトコル仕様）
2.1 Message Format （メッセージフォーマット）
2.1.1 Next Hop （次の転送先）
2.2 Addressing Considerations （アドレスの考慮）
2.3 Timers （タイマ）
2.4 Input Processing （入力処理）
2.4.1 Request Messages （要求メッセージ）
2.4.2 Response Messages （応答メッセージ）
2.5 Output Processing （出力処理）
2.5.1 Triggered Updates （トリガアップデート）
2.5.2 Generating Response Messages （応答メッセージの生成）
2.6 Split Horizon （視界分割）
3. Control Functions （制御機能）
4. Security Considerations （セキュリティの考察）
References （参考文献）
Authors' Addresses （著者のアドレス）
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.
この文書は、ベルマン・フォード（あるいは距離ベクトル）アルゴリズムに
基づく一連のルーティングプロトコルの１つを記述します。このアルゴリズ
ムはARPANETの初期からコンピュータ・ネットワークでルーティング計算に
使われました。特有のパケットフォーマットとここに記述したプロトコルは、
ＵＮＩＸのバークレーディストリビューションに含まれる「routed」プログ
ラムに基づいています。
In an international network, such as the Internet, it is very
unlikely that a single routing protocol will used for the entire
network. Rather, the network will be organized as a collection of
Autonomous Systems (AS), each of which will, in general, be
administered by a single entity. Each AS will have its own routing
technology, which may differ among AS's. The routing protocol used
within an AS is referred to as an Interior Gateway Protocol (IGP). A
separate protocol, called an Exterior Gateway Protocol (EGP), is used
to transfer routing information among the AS's. 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].
インターネットのような国際的ネットワークでひとつのルーティングプロト
コルが全てのネットワークで使われることは考えられません。どちらかと言
うと、ネットワークは自律システム（AS）の集合として組織化され、それぞ
れのASは一般にひとつの要素として運営されるでしょう。それぞれのASがそ
れぞれのルーティング技術を持ち、それはAS毎に異なるでしょう。AS内で使
わるルーティングプロトコルは内部経路プロトコル（IGP）と言われます。別
のプロトコルが、外部経路プロトコル（EGP）と呼ばれ、AS間でルーティング
情報を転送するために使われます。RIPng は中ぐらいのサイズのASでIGPとし
て働くために設計されました。これは複雑な環境で使用する事を意図してい
ません。RIPバージョン１（RIP-1）が使われること期待されている事の情報
のために、BradenとPostel[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
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.
RIPngが距離ベクトルアルゴリズムとして知られているアルゴリズムの１つ
です。著者に知っているこのアルゴリズムの最も早い記述はフォードとフル
カーソン[8]にあります。このため、これらはフォード-フルカーソンアルゴ
リズムとも言われます。明確な説明がベルマンの式[4]に基づいているため、
ベルマン-フォードという用語も使われます。この文書の表現は注意深く[5]
に基づいています。この文書はプロトコル仕様書を含んでいます。ルーティ
ングアルゴリズムの数学的導入については[1]を見てください。このプロト
コルで使う基本的なアルゴリズムは1969ごろのARPANETのコンピュータルー
ティングで使われていました。しかし、このプロトコルの特定の先祖はゼ
ロックスネットワークプロトコルです。PUPプロトコル[7]はルーティング成
功を交換するために経路情報プロトコルを使いました。ゼロックスネットワー
クシステム（XNS）構造のための、このプロトコルの更新されたバージョンで、
ルーティング情報プロトコル[9]の名前が採用されました。バークレーの
routedはほとんどルーティング情報プロトコルと同じで、IPv4を扱えるように
XNSアドレスがより一般的なアドレスフォーマットに置き換えられ、ルーティ
ングアップデートが３０秒毎に限定されました。この類似性のため、ルーティ
ング情報プロトコル（又は単にRIP）という用語がXNSプロトコルとroutedで
使われてるプロトコルの両方を参照するのに使われます。
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.
距離ベクトルプロトコルの陰の理論と数学への入門が[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.
プロトコルはその最も長いパス（ネットワークの直径）が１５ホップの
ネットワークに限定されています。設計者はは基本的なプロトコルデザ
インがより大きいネットワークのために不適当であると信じます。この
限界の記述で各ネットワークのコストが１であると想定してる事を注意
してください。これは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章を参照）。もしネットワークシステムが数百のネットワー
クを持ち、そしてルーティングループがそれらを巻き込んで生成されたなら、
ループの解決はたくさんの時間（もしルーティングアップデートの頻度が限
定されていたなら）か、帯域（もし変更が検出された時はいつもアップデー
トを送るなら）を必要とするでしょう。このようなループは、ループが修正
される前に、大量のネットワーク帯域を消費するでしょう。遅い回線を除き、
現実的な場合にこれが問題になる事はないと信じます。さらに、たいていの
場合にこういった問題が出ないような様々な用心をしているので、問題が発
生する事はほとんどないでしょう。
- 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.
- このプロトコルは他の経路を比較するのに固定した「距離」を使います。こ
れは経路が遅延時間、信頼性、負荷などのリアルタイムパラメーターに依存
させたい状況には適切ではありません。このタイプの距離を使えるようにプ
ロトコルを拡張すると、プロトコル処理が意図しない種類の不安定性をもた
らす可能性が高いです。
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はＩＰｖ６ベースのネットワークでルータ間で経路計算ルートのための
情報を交換できるように意図されます。RIPngは[1]に記述するように距離ベ
クトルプロトコルです。RIPngはルーターにだけ実装されるべきです；IPv6は
他のルーターの探索メカニズムを提供します[10]。RIPngを使うルーターが１
つ以上のネットワークへのインタフェースを持つと考えられます、そうでな
ければそれは本当はルーターではありません。これらはルータに直接結ばれ
たネットワークであると言います。プロトコルはネットワークのある情報へ
のアクセスに依存し、その最も重要な情報が距離です。ネットワークのRIPng
距離は、１から１５の間に整数です。距離はこのプロトコルで指定しない何
らかの方法で設定されます；しかし、１５というパスの限界があるので、通
常１が使われます。実装者はシステム管理者が各ネットワークに距離をつけ
ることを許すべきです。距離のほかに、それぞれのネットワークには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の運用しているシステム上で到達可能なすべ
ての宛先毎に１つの項目を持っています。それぞれの項目が少なくとも次の
情報を含んでいます：
- The IPv6 prefix of the destination.
- 宛先のＩＰｖ６プレフィックス。
- A metric, which represents the total cost of getting a datagram
from the router to that destination. This metric is the sum of the
costs associated with the networks that would be traversed to get
to the destination.
- ルーターからその宛先までパケットを送る際の総コストを表す距離。この
距離は宛先に到達するために横切るネットワークのコストの総量です。
- The 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アドレス（すなわち、次の転送先）。
もし宛先がルータに直接結ばれたネットワークの１つにあるなら、この項
目は必要でありません。
- 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.
- 経路と関連したいくつかのタイマー。タイマーの詳細については２.３章
を見てください。
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
networks over others (e.g., to indicate of differences in bandwidth
or reliability).
直接結ばれたネットワークの項目は、このプロトコルで指定されない手段で
集められた情報を使って、ルーターによって準備されます。直接結ばれたネッ
トワークのための距離はそのネットワークのコストに設定されます。何度の
言うように、通常コストは１です。このような場合、 RIPng距離は単純なホッ
プカウントに縮退します。より複雑な距離が、あるネットワークを他のネッ
トワークより優先して使う事が望ましいときに使われるかもしれません（例
えば、帯域や信頼性の相違について）。
Implementors may also choose to allow the system administrator to
enter additional routes. These would most likely be routes to hosts
or networks outside the scope of the routing system. They are
referred to as "static routes." Entries for destinations other than
these initial ones are added and updated by the algorithms described
in the following sections.
実装者がシステム管理者に追加経路の項目を設定できるように決めるかもし
れません。これらはルーティングシステムの範囲外のホストやネットワーク
への経路なのでしょう。これらは「静的経路」と言われます。これらの最初
に設定される宛先項目以外の宛先項目は、以下の章に記述するアルゴリズム
によって追加と更新がされます。
In order for the protocol to provide complete information on routing,
every router in the AS must participate in the protocol. In cases
where multiple IGPs are in use, there must be at least one router
which can leak routing information between the protocols.
プロトコルがルーティングのための完全な情報を供給するために、AS内の全
てのルーターがプロトコルに参加しなくてはなりません。多数のIGPが使用
される場合は、プロトコル間にルーティング情報を流すことができる少なく
とも１つのルーターがあるに違いありません。
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ポート番号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) ~
| 経路テーブル項目Ｎ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each Route Table Entry (RTE) has the following format:
それぞれの経路テーブル項目(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) ~
| IPv6プレフィックス |
+---------------------------------------------------------------+
| route tag (2) | prefix len (1)| metric (1) |
| 経路タグ |プレフィクス長 | 距離 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The maximum number of RTEs is defined below.
RTEの最大数は後に定義されます。
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.
フィールドの大きさがオクテットで与えられます。特に指定されなければ、
フィールドは２進数整数を含み、これは上位オクテットが最初に来る（ビッ
グエンディアン)というネットワークバイトオーダーになります。それぞれの
カチカチマークが１ビットを表します。
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 - request A request for the responding system to send all or
part of its routing table.
1 - 要求 応答システムにルーティングテーブル全部か一部を送る
事を求める。
2 - response A message containing all or part of the sender's
routing table. This message may be sent in response
to a request, or it may be an unsolicited routing
update generated by the sender.
2 - 応答 送信者のルーティングテーブルの全部か一部を含むメッセー
ジ。このメッセージは要求に応えて送られるかもしれないし、
送信者が生成する自律的なルーティングアップデートである
かもしれません。
For each of these message types, 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).
これらのメッセージタイプの各データグラムの残りにRTEのリストを含みます。
リスト内の各RTEが宛先プレフィックスとプレフィックスの有効ビット数と宛
先までのコスト（距離）を含んでいます。
The destination prefix is the usual 128-bit, IPv6 address prefix
stored as 16 octets in network byte order.
宛先プレフィックスは通常１２８ビットの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.
経路タグフィールドは経路に割り当てられていて、経路とともに維持され
再広告される属性です。径路タグの意図的な使用方法は「内部」RIPng経路
（RIPngルーティングドメイン内のネットワークのための経路）を、EGPか
他のIGPからもたらされた「外部」RIPng経路から分離する方法の供給です。
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か
ら読み込まれた経路に任意の値か、経路を学んだ自律システムの番号を、経
路タグとして設定可能であるべきです。
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.
プレフィックス長フィールドはプレフィックスの左から始まるプレフィック
スの有効部分の長さです（０から１２８の間の値）。
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.
距離フィールドは、宛先への現在の距離を示す１から１５の間の値か、宛
先への到達が不可能なことを示す１６（無限）です。
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不一致の危険がありません。特定のメッセージに設定可能なRTE
の数の決定は、メディアのMTUとRIPngメッセージの前にあるヘッダ情報のオ
クテット数と、 RIPn ヘッダの大きさと経路の大きさの関数です。式は以下
です：
+- -+
| MTU - sizeof(IPv6_hdrs) - UDP_hdrlen - RIPng_hdrlen |
#RTEs = INT | --------------------------------------------------- |
| RTE_size |
+- -+
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は、RIP-2の機能[2]と同じく、経路テーブル項目(RTE)で示される宛先
へ送る場合に転送すべき次の直接の転送先のIPv6アドレスを指定する能力を
供給します。RIP-2でそれぞれの経路テーブル項目は次の転送先フィールドを
持っています。それぞれのRTEのためにRIPngに次の転送先フィールドを含め
ることはほとんどの経路の大きさを２倍にするでしょう。それ故に、RIPngで
次の転送先は特別なRTEで指定され、これは次の転送先RTE以降から、メッセー
ジの終わりかの他の次の転送先RTEまでの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の距離フィールドの０xFFの値によって識別されます。プ
レフィックスフィールドは次の転送先のＩＰｖ６アドレスを指定します。次
の転送先RTEの経路タグとプレフィックス長さは送信時にゼロが設定され、受
信者がこれを無視しなければなりません。
The next hop Route Table Entry (RTE) has the following format:
次の転送先径路テーブル項目(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) ~
| IPv6次の転送先アドレス |
+---------------------------------------------------------------+
| must be zero (2) |must be zero(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.
次の転送先RTEのプレフィックスフィールドで0:0:0:0:0:0:0:0の値を指定す
ることは次の転送先アドレスが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.
ネットワークとサブネットとホストルートの区別は、ＩＰｖ６アドレスプレ
フィックスが明確なので、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
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.
プレフィックス長がゼロのプレフィックスがデフォルトルートを指定する
のに使われます。本質的は無視されるが、プレフィックス0:0:0:0:0:0:0:0
をデフォルトルートを指定する時に使うことが提案されます。デフォルト
ルートが、 RIPngアップデートですべての可能なネットワークをリストアッ
プすることが都合が良くない時、システム内の１つ以上のルーターが明示
的にリストアップされないネットワークのトラフィックを処理する用意が
できている時に使われます。これらの「デフォルトルータ」は明示的な経
路がないすべてのデータグラムのためのデフォルトルートに使われます。
ルーターがデフォルトルータになる方法（つまり、デフォルトルート項目
を作る方法）は実装者に任せられます。一般に、システム管理者にはどの
ルーターにデフォルトルート項目を作り広告すべきかを指定する方法が提
供されるでしょう。もしデフォルトルートが使われるなら、実装者はネッ
トワーク管理者にデフォルトルート広告に関する距離を設定できるように
すべきです。これは複数のデフォルトルータの優先順位の確立を可能にす
るでしょう。デフォルトルート項目は他の宛先プレフィックスと同じ方法
でRIPngによって処理されます。システム管理者がデフォルトルートが意図
するより広まり過ぎないように面倒を見るべきです。一般に、それぞれの
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プロセスはすべての隣接するルーターに完全なルー
ティングテーブルを含む自律的な応答メッセージを送るため呼び起こされ
ます（2.6章の分割限界を参照）。ひとつのネットワークの上に多くのルー
ターがある時、それらが同時にアップデートを送信するように同期してし
ます傾向があります。これは３０秒のタイマーがシステム負荷の影響を受
ける際はいつも生じます。アップデートメッセージの同期はブロードキャ
ストネットワーク上でメッセージの衝突を引き起こすので望ましくありま
せん（詳細は[13]を参照）。それ故に、２つの用心のうち１つを実装する
ように要求されます：
- 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.
- ３０秒の更新は、前の更新タイマーによるサービス要求時刻や、システ
ム負荷の影響を受けない時計によって発生する。
- 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).
- ３０秒のタイマーは、設定する度に小さなランダムなオフセット（±０〜
１５秒）が追加されます。オフセットは更新時期（３０）＊０．５で計算
します。
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.
各経路に関連する２つのタイマ、「タイムアウト」と「ごみ収集」、があり
ます。「タイムアウト」が満了すると経路はもう利用できません；しかし、
隣人に経路が利用できないことを知らせられるため短期間ルーティングテー
ブルに残されます。ごみ収集タイマが満了したときは、経路がルーティング
テーブルから削除されます。
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.
「タイムアウト」は、径路が利用可能になるときと、経路のアップデートメッ
セージを受信したときに、初期化されます。もし「タイムアウト」が初期化さ
れてから１８０秒経過すると、径路は利用不可能と考えられ、以下の削除プロ
セスが始まります。
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:
削除が２つの理由で発生します：「タイムアウト」タイマが満了するか、現在
のルータから受取ったアップデートの距離が１６の場合（他のルーターからの
アップデートの処理は２.４.２章を参照）。いずれの場合でも、次のイベント
は起きます：。
- The garbage-collection timer is set for 120 seconds.
- ごみ収集タイマーは１２０秒間に設定されます。
- The metric for the route is set to 16 (infinity). This causes the
route to be removed from service.
- 径路の距離は１６（無限）に設定されます。これは径路を利用不可能にします。
- 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.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ポートで受信したデータグラムの扱いを記述します。処理がコ
マンドフィールドの価に頼ります。バージョン１は２つのコマンドだけをサ
ポートします：要求と応答。
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.
ルーターのルーティングテーブルの一部または全部を含む応答を求めるため
に要求が使われます。通常要求は、なるべく早くルーティングテーブル完成
させようとしているルータのRIPngポートからマルチキャストとして送られま
す。しかし、特定のルーターのルーティングテーブルが必要とされる状態
（例えば、ルーターモニタリング）があるかもしれません。この場合、要求は
RIPngポート以外のUDPポートから直接そのルーターに送られるべきです。もし
このような要求を受け取ったルーターは、要求者がつながっているネットワー
ク上ないかもしれないので、グローバルソースアドレスで要求者のアドレスと
ポートに直接返答します。
The Request is processed entry by entry. If there are no entries, no
response is given. There is one special case. If there is exactly
one entry in the request, and it has 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.
要求は項目毎に処理されます。もし項目がなければ応答をしません。１つ特
別なケースがあります。もし要求に正確に１つの項目があり、宛先プレフィッ
クスがゼロで、プレフィックス長がゼロで、宛先への距離が無限（すなわち
１６）なら、これは全部のルーティングテーブルを送る要求です。このよう
な場合、要求が求めるアドレス／ポートにルーティングテーブルを送る出力
処理が行われます。この特別な場合以外、処理は非常に単純です。要求のRTE
を１つずつ調ます。各項目について、ルーターのルーティングデータベース
で宛先を検索し、もし径路があればその経路の距離を距離フィールドに設定
します。もし指定された宛先に対する明確な経路がなければ、距離フィール
ドに無限を入れます。すべての項目が記入されると、コマンドを要求から応
答に変更し、データグラムを要求者に送り返します。
Note that there is a difference in metric handling for specific and
whole-table requests. If the request is for a complete routing
table, normal output processing is done, including Split Horizon (see
section 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.
特殊な全部のテーブルの要求の際に距離の扱いが異なることに注意してくだ
さい。もし要求が全てのルーティングテーブルであるなら、標準出力処理が
視界分割を含めて行われます（視界分割は２.６章を見てください）。特定項
目に対する要求であればルーチングテーブルを検索し、視界分割はせずに、
情報を返します。この区別の理由はこれらの要求が異る目的のために使われ
る可能性が高いだろうという事です。ルーターが起動すると、ルータはすべ
てのルーティングテーブルを求めるため、接続されたネットワーク上にマル
チキャストを送ります。全てのルーティングテーブルの応答が、要求者のルー
ティングテーブルの更新に使われると想定されます。このために、視界分割
が行われなければなりません。特定のネットワークの要求が診断ソフトウェ
アによって行われ、ルーティングに使われないとさらに想定されます。この
場合、要求者はルーティングテーブルの正確な内容を知ることを望み、情報
が隠されたり修正されるのを望まないでしょう。
2.4.2 Response Messages
2.4.2 応答メッセージ
A Response can be received for one of several different reasons:
応答がいくつかの異なる理由で受信されます：
- response to a specific query
- 特定の質問に対する回答。
- regular update (unsolicited response)
- 通常のアップデート（自律反応）。
- triggered update caused by a route change
- 経路変更によって発生したトリガアップデート。
Processing is the same no matter why the Response was generated.
処理は、なぜ応答を生成するかによらず同じです。
Because processing of a Response may update the router's routing
table, the Response must be checked carefully for validity. The
Response must be ignored if it is not from the 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 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.
応答の処理はルーターのルーティングテーブルを更新するかもしれないので、
回答は慎重に正しいかチェックしなくてはなりません。応答は、もしそれが
RIPngポートからでなければ無視されなくてはなりません。データグラムの
ＩＰｖ６ソースアドレスはデータグラムが正当な隣人からであるか確認する
ためにチェックです；データグラムのソースはリンクローカルアドレスに違
いありません。回答がルーター自身のアドレスの１つからかどうかを確認す
るのも価値があります。ブロードキャストネットワークの上のインタフェー
スが、自分自身の出したマルチキャストのコピーを受信するかもしれません。
もしルーターが新しい入力として自分自身の出力を処理するなら混乱してし
まうだろうから、このようなデータグラムは無視しなければなりません。追
加のチェックとして、周期的広告ではホップカウンタが２５５に設定され、
RIPngポートから送られた入力のマルチキャストで（つまり周期的な広告か、
経路更新によるトリガアップデートパケット）ではホップカウンタが２５５
に設定されてなければなりません。どんな中継ノードもホップカウントを減
少させるでしょうから、これで絶対的にパケットが近隣からであることを保
証できます。要求に対する応答は中継ノードを通るかもしれないので、ホッ
プカウントのテストを要求しません。
Once the datagram as a whole has been validated, process the RTEs in
the Response one by one. Again, start by doing validation.
Incorrect metrics and other format errors usually indicate
misbehaving neighbors and should probably be brought to the
administrator's attention. For example, if the metric is greater
than infinity, ignore the entry but log the event. The basic
validation tests are:
データグラムが全体として有効であれば、応答内のRTEを１つずつ処理します。
再び、確認を行います。誤った距離と他のフォーマットエラーが通常何か誤っ
ている隣人を示していて、恐らく管理者に注意をすべきです。例えば、もし
距離が無限より大きいなら、この項目を無視し、イベントをログファイルに
書いてください。基本的な確認テストは以下の通りです：
- 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)
- 距離が正しいか（１から１６の間か）。
If any check fails, ignore that entry and proceed to the next.
Again, logging the error is probably a good idea.
もしチェックに失敗したら、その項目を無視し、次の項目に進んでく
ださい。エラーをログファイルに書くことは恐らく良い考えです。
Once the entry has been validated, update the metric by adding the
cost of the network on which the message arrived. If the result is
greater than infinity, use infinity. That is,
項目が利用可能になったら、距離にメッセージが到着したネットワークの
コストを加えてください。もし結果が無限より大きければ、無限を使って
ください。すなわち、
metric = MIN (metric + cost, infinity)
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:
次に宛先プレフィックスに対する明示的経路があるかどうか調べてください。
もしこのような経路がないく、距離が無限（経路を追加できません）でなけれ
ば、ルーティングテーブルにこの経路を加えて下さい。ルーティングテーブル
への経路追加は以下様にします：
- Setting the destination prefix and length to those in the RTE.
- 宛先プレフィックスと長さをRTEの値に設定します。
- Setting the metric to the newly calculated metric (as described
above).
- 距離は（上記の）計算された値を設定します。
- Set the next hop address to be the address of the router from which
the datagram came 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).
- 経路の「タイムアウト」を初期化してください。もしごみ収集タイマーが
この経路に対して動作しているなら、それを止めてください（タイマーに
ついては２.３章を見てください）。
- Set the route change flag.
- 経路変化フラグを設定してください。
- Signal the output process to trigger an update (see section 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.
もし新しい距離が古いと同じなら、単純な場合、何もしません（上で指定す
る様に「タイムアウト」を最初期化します）；しかし発見的応用ができます。
通常、もし新しい経路が既存の経路と同じ距離を持つなら、経路の置き換え
は無意味です；これはルートをばたばた切り替えることになり、トリガアッ
プデートを余計に生成するでしょう。しかし、もし既存の経路がタイムアウ
トの予兆を示しているなら、タイムアウトが起きる前により良い代わりの経
路に切り替えても良いかもしれません。従って、もし新しい距離が古いのと
同じなら、既存経路のためにタイムアウトを調べてください。もしそれが満
了ポイントまでの中間点を越えてるなら、新しい経路に切り替えてください。
この発見的手法は任意ですが、大いに推薦されています。
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).
- 要求を受信した際の入力処理から。この場合、応答は１つの宛先に送られ
ます（すなわち要求者のユニキャストアドレス）。
- By the regular routing update. Every 30 seconds, a Response
containing the whole routing table is sent to every neighboring
router.
- 通常のルーティングアップデートによって。３０秒ごとに、ルーティン
グテーブル全体を含む応答が隣接するルーターに送られます。
- 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.
要求の際に必要な特別な処理は２.４.１章に記述します。
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.
応答がすべての隣人に送られる場合（つまり、通常のアップデートか、トリ
ガアップデート）、全てのブロードキャストネットワークとポイントポイン
トリンクで、応答メッセージは全RIPルータマルチキャストグループのFF02::9
にマルチキャストされます。マルチキャストリンク同様にポイントポイント
リンクでマルチキャストを送ることができるので、RIPngはポイントポイント
も扱えます。それのため、各直接結ばれたネットワーク毎に応答が作成でき
て、全RIPルータマルチキャストグループを送られます。たいていの場合、
これはすべての隣接するルーターに届きます。しかしながら、これで十分で
ないいくつかの場合があります。これはブロードキャストネットワークでな
い場合や（例えば、 ARPANET ）、RIPを話せないルータがある場合などです。
このような場合、隣接するルーターの実際のリストを指定して、明示的にデー
タグラムをそれぞれに送る必要があるかもしれません。このようなメカニズ
ムが必要かどうかと、どのようにリストを指定するかは実装者に任せられます。
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
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.
トリガアップデートは２つの理由で特別処理が必要です。最初に、経験上、
トリガアップデートは帯域が少なかったりルータが多いネットワークで極端な
負荷を発生させます。それ故、プロトコルは実装者にトリガアップデート頻度
を制限する機能の提供を要求します。トリガアップデート後、１秒から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.
第二に、トリガアップデートは全てのルーティングテーブルを送る必要があ
りません。原則として、変化した経路だけが含まれる必要があります。トリ
ガアップデートで生成されたメッセージが少なくとも経路変更フラグが設定
されている経路を含まなくてはなりません。実装者の裁量で、追加の経路を
含むかもしれません；しかし、完全な経路更新を送るべきではありません。
トリガアップデートを処理する時、メッセージはすべての直接結ばれたネッ
トワークで生成されるべきです。視界分割処理が、通常のアップデート同様
にトリガアップデートで実施されます（２.６章参照）。もし、視界分割処理
の後にあるネットワークに送るべき、変わった経路がそのネットワークに対
して変わっていないように見えるなら（例えば、距離が無限になってる場合）、
経路を送る必要がありません。もしネットワークへ送る経路がなければ、
アップデートは送られないかもしれません。トリガアップデートが生成され
ると、経路変更フラグはクリアされるべきです。
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:
この章はどのように応答メッセージが特定の直接結ばれたネットワークに
生成されるか記述します：
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
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.
ＩＰｖ６ソースアドレスは、RIPngポートから送られてきたユニキャスト
要求メッセージの応答を除き、送信ルーターのインタフェースのリンク
ローカルアドレスに違いありません。後の場合、ソースアドレスは正しい
グローバルアドレスに違いありません。前の場合、この応答を受け取る
ルーターでソースアドレスが（次の転送先として）ルーティングテーブル
に入れられるので、リンクローカルアドレスを使うことは重要です。もし
正しくないソースアドレスが使われるなら、他のルーターはデータグラム
の経路を決めることができないかもしれません。ルーターのひとつの物理
的インタフェースに多数のＩＰｖ６アドレスが設定されることがあります。
通常、これはいくつかの論理的ＩＰｖ６ネットワークが１つの物理メディ
ア上にあることを意味します。ルーターがひとつのインタフェースで多数
のリンクローカルアドレスを持つ事が可能です。この場合、ルーターは指
定インタフェースの指名されたリンクローカルアドレスをソースアドレス
としてひとつの応答メッセージだけを生成します。使用するリンクローカ
ルアドレスは、現在選択してるアドレスが無効になった場合だけ変更すべ
きです。これは、応答メッセージを受け取るノードが送信者を識別するた
めにソースアドレスを使うから、必要です。もし同じルーターからの多数
のパケットが異るソースアドレスを含むなら、ノードがそれらが異なるルー
タから来たものと想定し、望ましくない行動が発生するでしょう。
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版です。
コマンドに応答を設定します。「ゼロを設定」指定されたバイトをゼロを設定
します。RTEを埋め始めます。最大データグラムサイズがネットワークのMTUで
制限されることを思い出してください。データグラムにこれ以上のスペースが
ない時、現在の応答を送り、新しい応答を生成し始めてください。
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.
RTEを埋めるため、ルーティングテーブルの各経路を調べてください。リンク
ローカルアドレスを経路に入れてはなりません。もしトリガアップデートを
生成しているなら、経路変更フラグが設定されている項目だけを含む必要が
あります。もし、視界分割処理の後に、経路が含まれるべきではないなら、
それを省略してください。もし経路が含まれるなら、宛先プレフィックスと
プレフィックス長と距離は経路に入れられます。経路タグは、２.１章で定義
されるように、記入されます。経路は、たとえその距離が無限であっても、
データグラムに含めなければなりません。
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.
視界分割は経路を送ってきたゲートウェイに同じ経路を送り返す事による問
題を避けるアルゴリズムです。基本的な視界分割アルゴリズムはアップデー
トからその近隣が送ってきた経路を削除します。ブロードキャストネット
ワークの場合、ネットワークへ送るアップデートからそのネットワーク上の
近隣から学んだ全ての経路が除かれます。
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.
毒入逆送付の視界分割はこの様な経路を、距離を無限にして、アップデー
トに設定します。実際、これで経路が到達可能ではないという事実を広告
します。これは望ましい方法です；しかし、実装者は分割なし、視界分割、
毒入逆送をインターフェース毎に選択できる制御機能を提供するべきです。
For a theoretical discussion of Split Horizon and Poison Reverse, and
why they are needed, see section 2.1.1 of [1].
視界分割と毒入逆送とそれらが必要な理由の理論的な論議は[1]の２.１.１章
を見てください。
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.
- 多くのサイトが応答メッセージに設定できるネットワークを制限します。
組織Ａが組織Bへ直接通信する回線を持っているかもしれません。セキュリ
ティやパフォーマンスの理由でＡがその接続を他の組織に使わせたくない
と考えているかもしれません。このような場合、Ａが第三者に送るアップ
デートにＢのネットワークを含むべきではありません。
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.
- 特定の宛先のフィルターがネットワーク管理者に受入れや拒否すべき宛先プ
レフィックスのリストの指定を可能にするでしょう。リストは特定インター
フェースの入力や出力と結び付けられるでしょう。ただ許可されたネット
ワークだけ、応答メッセージで外に送られるか、応答メッセージを受け取っ
て処理されるでしょう。もし許可プレフィックスリストが指定されるなら、
他のプレフィックスは全て拒否されます。もし拒否プレフィックスリストが
指定されるなら、他のプレフィックスは全て許可されます。デフォルトで、
フィルターが適用されません。
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.
RIPngがＩＰｖ６上で動くので、RIPngはIP認証ヘッダ（［１１］参照）と
IP暗号化ヘッダ（［１２］参照）に、ルーチング交換の完全性と認証と機
密性を依存します。
References
参考文献
[1] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
University, June 1988.
[2] Malkin, G., "RIP Version 2 - Carrying Additional Information",
RFC 1723, Xylogics, Inc., November, 1994.
[3] Hinden, R., "IP Next Generation Overview",
Work in Progress.
[4] Bellman, R., "Dynamic Programming", Princeton University
Press, Princeton, N.J., 1957.
[5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice-
Hall, Englewood Cliffs, N.J., 1987.
[6] Braden, R., and J. Postel, "Requirements for Internet Gateways",
USC/Information Sciences Institute, STD 4, RFC 1009, June 1987.
[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.
[8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
Princeton University Press, Princeton, N.J., 1962.
[9] Xerox Corp., "Internet Transport Protocols", Xerox System Inte-
gration Standard XSIS 028112, December 1981.
[10] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 1970, August 1996.
[11] Atkinson, R., "IP Authentication Header", RFC 1826
Naval Research Laboratory, August 1995.
[12] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 1827, Naval Research Laboratory, August 1995.
[13] Floyd, S., and Jacobson, V., "The Synchronization of Periodic
Routing Messages", Proceedings of ACM SIGCOMM '93, September
1993.
Authors' Addresses
著者のアドレス
Gary Scott Malkin
Xylogics, Inc.
53 Third Avenue
Burlington, MA 01803
Phone: (617) 272-8140
EMail: gmalkin@Xylogics.COM
Robert E. Minnear
Ipsilon Networks, Inc.
2191 E. Bayshore Road, Suite 100
Palo Alto, CA 94303
Phone: (415) 846-4614
EMail: minnear@ipsilon.com