広告
広告
https://www.7key.jp/rfc/2080/rfc2080_24.html#sourcehttps://www.7key.jp/rfc/2080/rfc2080_24.html#translationThis 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つのコマンドのみを支援する。
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.
リクエストはエントリごとに処理される。エントリがない場合は応答しない。ただし、1つ特別な場合がある。リクエストに1つの正確なエントリがあり、宛先プレフィックスがゼロで、プレフィックス長がゼロで、距離が無限（つまり、16）の場合、これは完全なルーティングテーブルを送信せよとのリクエストである。この場合、リクエストのあるアドレスとポートにルーティングテーブルを送信する出力プロセスがコールされる。この特別な場合を除いて、処理は極めて単純である。リクエストのそれぞれのRTEリストを調べる。各エントリについて、ルータのルーティングテーブルを検索し、もし経路があれば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.6 スプリットホライズンを参照）を含めて標準出力処理が行われる。リクエストが特定のエントリを望むものであれば、ルーティングテーブルを検索し、スプリットホライズンを行うことなく情報を返信する。この差の理由は、これらのリクエストが異なる目的に用いられる可能性が高いと思われるからである。ルータは起動した際、完全なルーティングテーブルを取得するために全ての接続ネットワークへマルチキャストリクエストを送信する。これらの完全なルーティングテーブルは、リクエスト送信ルータのルーティングテーブルの更新に用いられると想定される。このため、スプリットホライズンがなされなければならない。特定のネットワークのリクエストは診断ソフトウェアによって行われ、ルーティングには用いられないことが更に想定される。この場合、リクエスト送信ルータはルーティングテーブルの正確な内容を望み、情報を隠されたり修正されることは望まないだろう。
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ポートからのものでなければ無視されなければならない。データグラムのIPv6発信元アドレスは、データグラムが正しい隣接ノードからかどうかを確認すべきである。データグラムの発信元はリンクローカルアドレスでなければならない。応答がルータ自身のアドレスの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:
- 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)
データグラムが有効なものであれば、応答内のRTEを1つずつ処理する。そして再び、有効性の確認を始める。誤った距離やその他のフォーマットエラーは、通常態度の悪い隣接ノードを示し、管理者に注意を促すべきである。例えば、距離が無限大より大きいのであれば、そのエントリは無視するがイベントログには記載する。基本的な有効性の確認は次の通り：
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.
- 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.
- 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.
これらのテストに失敗するエントリは、現在の経路より悪いものとみなされ無視される。
広告