IPv6用RIPng(入力処理)

広告

広告

原文

最終更新
2006-11-01T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/2080/rfc2080_24.html#source

IPv6用RIPng(和訳)

最終更新
2006-11-03T16:23:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/2080/rfc2080_24.html#translation

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 リクエストメッセージ

   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 スプリットホライズンを参照)を含めて標準出力処理が行われる。リクエストが特定のエントリを望むものであれば、ルーティングテーブルを検索し、スプリットホライズンを行うことなく情報を返信する。この差の理由は、これらのリクエストが異なる目的に用いられる可能性が高いと思われるからである。ルータは起動した際、完全なルーティングテーブルを取得するために全ての接続ネットワークへマルチキャストリクエストを送信する。これらの完全なルーティングテーブルは、リクエスト送信ルータのルーティングテーブルの更新に用いられると想定される。このため、スプリットホライズンがなされなければならない。特定のネットワークのリクエストは診断ソフトウェアによって行われ、ルーティングには用いられないことが更に想定される。この場合、リクエスト送信ルータはルーティングテーブルの正確な内容を望み、情報を隠されたり修正されることは望まないだろう。

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ポートからのものでなければ無視されなければならない。データグラムの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.

これらのテストに失敗するエントリは、現在の経路より悪いものとみなされ無視される。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年11月01日 最終更新:2006年11月03日