IPv6用RIPng（出力処理）

   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.

   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.

   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.

   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.

   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.

   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.