rfc2080.txt

xorp源码hg

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         ...                                   ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                Route Table Entry N (20)                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




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


   where each Route Table Entry (RTE) has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                        IPv6 prefix (16)                       ~
      |                                                               |
      +---------------------------------------------------------------+
      |         route tag (2)         | prefix len (1)|  metric (1)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The maximum number of RTEs is defined below.

   Field sizes are given in octets.  Unless otherwise specified, fields
   contain binary integers, in network byte order, with the most-
   significant octet first (big-endian).  Each tick mark represents one
   bit.

   Every message contains a RIPng header which consists of a command and
   a version number.  This document describes version 1 of the protocol
   (see section 2.4).  The command field is used to specify the purpose
   of this message.  The commands implemented in version 1 are:

   1 - request    A request for the responding system to send all or
                  part of its routing table.

   2 - response   A message containing all or part of the sender's
                  routing table.  This message may be sent in response
                  to a request, or it may be an unsolicited routing
                  update generated by the sender.

   For each of these message types, the remainder of the datagram
   contains a list of RTEs.  Each RTE in this list contains a
   destination prefix, the number of significant bits in the prefix, and
   the cost to reach that destination (metric).

   The destination prefix is the usual 128-bit, IPv6 address prefix
   stored as 16 octets in network byte order.

   The route tag field is an attribute assigned to a route which must be
   preserved and readvertised with a route.  The intended use of the
   route tag is to provide a method of separating "internal" RIPng
   routes (routes for networks within the RIPng routing domain) from
   "external" RIPng routes, which may have been imported from an EGP or
   another IGP.





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


   Routers supporting protocols other than RIPng should be configurable
   to allow the route tag to be configured for routes imported from
   different sources.  For example, routes imported from an EGP should
   be able to have their route tag either set to an arbitrary value, or
   at least to the number of the Autonomous System from which the routes
   were learned.

   Other uses of the route tag are valid, as long as all routers in the
   RIPng domain use it consistently.

   The prefix length field is the length in bits of the significant part
   of the prefix (a value between 0 and 128 inclusive) starting from the
   left of the prefix.

   The metric field contains a value between 1 and 15 inclusive,
   specifying the current metric for the destination; or the value 16
   (infinity), which indicates that the destination is not reachable.

   The maximum datagram size is limited by the MTU of the medium over
   which the protocol is being used.  Since an unsolicited RIPng update
   is never propagated across a router, there is no danger of an MTU
   mismatch.  The determination of the number of RTEs which may be put
   into a given message is a function of the medium's MTU, the number of
   octets of header information preceeding the RIPng message, the size
   of the RIPng header, and the size of an RTE.  The formula is:

               +-                                                   -+
               | MTU - sizeof(IPv6_hdrs) - UDP_hdrlen - RIPng_hdrlen |
   #RTEs = INT | --------------------------------------------------- |
               |                      RTE_size                       |
               +-                                                   -+

2.1.1  Next Hop

   RIPng provides the ability to specify the immediate next hop IPv6
   address to which packets to a destination specified by a route table
   entry (RTE) should be forwarded in much the same way as RIP-2 [2].
   In RIP-2, each route table entry has a next hop field.  Including a
   next hop field for each RTE in RIPng would nearly double the size of
   the RTE.  Therefore, in RIPng, the next hop is specified by a special
   RTE and applies to all of the address RTEs following the next hop RTE
   until the end of the message or until another next hop RTE is
   encountered.

   A next hop RTE is identified by a value of 0xFF in the metric field
   of an RTE.  The prefix field specifies the IPv6 address of the next
   hop.  The route tag and prefix length in the next hop RTE must be set
   to zero on sending and ignored on receiption.



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


   The next hop Route Table Entry (RTE) has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    IPv6 next hop address (16)                 ~
   |                                                               |
   +---------------------------------------------------------------+
   |        must be zero (2)       |must be zero(1)|     0xFF      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Specifying a value of 0:0:0:0:0:0:0:0 in the prefix field of a next
   hop RTE indicates that the next hop address should be the originator
   of the RIPng advertisement.  An address specified as a next hop must
   be a link-local address.

   The purpose of the next hop RTE is to eliminate packets being routed
   through extra hops in the system.  It is particularly useful when
   RIPng is not being run on all of the routers on a network.  Note that
   next hop RTE is "advisory".  That is, if the provided information is
   ignored, a possibly sub-optimal, but absolutely valid, route may be
   taken.  If the received next hop address is not a link-local address,
   it should be treated as 0:0:0:0:0:0:0:0.

2.2  Addressing Considerations

   The distinction between network, subnet and host routes does not need
   to be made for RIPng because an IPv6 address prefix is unambiguous.

   Any prefix with a prefix length of zero is used to designate a
   default route.  It is suggested that the prefix 0:0:0:0:0:0:0:0 be
   used when specifying the default route, though the prefix is
   essentially ignored.  A default route is used when it is not
   convenient to list every possible network in the RIPng updates, and
   when one or more routers in the system are prepared to handle traffic
   to the networks that are not explicitly listed.  These "default
   routers" use the default route as a path for all datagrams for which
   they have no explicit route.  The decision as to how a router becomes
   a default router (i.e., how a default route entry is created) is left
   to the implementor.  In general, the system administrator will be
   provided with a way to specify which routers should create and
   advertise default route entries.  If this mechanism is used, the
   implementation should allow the network administrator to choose the
   metric associated with the default route advertisement.  This will
   make it possible to establish a precedence amoung multiple default
   routers.  The default route entries are handled by RIPng in exactly
   the same manner as any other destination prefix.  System



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


   administrators should take care to make sure that default routes do
   not propagate further than is intended.  Generally, each AS has its
   own preferred default router.  Therefore, default routes should
   generally not leave the boundary of an AS.  The mechanisms for
   enforcing this restriction are not specified in this document.

2.3  Timers

   This section describes all events that are triggered by timers.

   Every 30 seconds, the RIPng process is awakened to send an
   unsolicited Response message, containing the complete routing table
   (see section 2.6 on Split Horizon), to every neighboring router.
   When there are many routers on a single network, there is a tendency
   for them to synchronize with each other such that they all issue
   updates at the same time.  This can happen whenever the 30 second
   timer is affected by the processing load on the system.  It is
   undesirable for the update messages to become synchronized, since it
   can lead to unnecessary collisions on broadcast networks (see [13]
   for more details).  Therefore, implementations are required to take
   one of two precautions:

   - The 30-second updates are triggered by a clock whose rate is not
     affected by system load or the time required to service the
     previous update timer.

   - The 30-second timer is offset by a small random time (+/- 0 to 15
     seconds) each time it is set.  The offset is derived from: 0.5 *
     the update period (i.e. 30).

   There are two timers associated with each route, a "timeout" and a
   "garbage-collection time."  Upon expiration of the timeout, the route
   is no longer valid; however, it is retained in the routing table for
   a short time so that neighbors can be notified that the route has
   been dropped.  Upon expiration of the garbage-collection timer, the
   route is finally removed from the routing table.

   The timeout is initialized when a route is established, and any time
   an update message is received for the route.  If 180 seconds elapse
   from the last time the timeout was initialized, the route is
   considered to have expired, and the deletion process described below
   begins for that route.









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


   Deletions can occur for one of two reasons: the timeout expires, or
   the metric is set to 16 because of an update received from the
   current router (see section 2.4.2 for a discussion of processing
   updates from other routers).  In either case, the following events
   happen:

   - The garbage-collection timer is set for 120 seconds.

   - The metric for the route is set to 16 (infinity).  This causes the
     route to be removed from service.

   - The route change flag is to indicate that this entry has been
     changed.

   - The output process is signalled to trigger a response.

   Until the garbage-collection timer expires, the route is included in
   all updates sent by this router.  When the garbage-collection timer
   expires, the route is deleted from the routing table.

   Should a new route to this network be established while the garbage-
   collection timer is running, the new route will replace the one that
   is about to be deleted.  In this case the garbage-collection timer
   must be cleared.