rfc2080.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,067 行 · 第 1/4 页

   Triggered updates also use a small timer; however, this is best
   described in section 2.5.1.

2.4  Input Processing

   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  Request Messages

   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.




Malkin & Minnear            Standards Track                    [Page 10]

RFC 2080                     RIPng for IPv6                 January 1997


   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.4.2  Response Messages

   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



Malkin & Minnear            Standards Track                    [Page 11]

RFC 2080                     RIPng for IPv6                 January 1997


   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
     above).





Malkin & Minnear            Standards Track                    [Page 12]

RFC 2080                     RIPng for IPv6                 January 1997


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



Malkin & Minnear            Standards Track                    [Page 13]

RFC 2080                     RIPng for IPv6                 January 1997


   Any entry that fails these tests is ignored, as it is no better than
   the current route.

2.5  Output Processing

   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.

2.5.1  Triggered Updates

   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



Malkin & Minnear            Standards Track                    [Page 14]

RFC 2080                     RIPng for IPv6                 January 1997


   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.

   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