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.


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.


   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.


   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.


   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)


   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

   - 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

   - 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日