2.1 メッセージフォーマット

   RIPng is a UDP-based protocol.  Each router that uses RIPng has a
   routing process that sends and receives datagrams on UDP port number
   521, the RIPng port.  All communications intended for another
   router's RIPng process are sent to the RIPng port.  All routing
   update messages are sent from the RIPng port.  Unsolicited routing
   update messages have both the source and destination port equal to
   the RIPng port.  Those sent in response to a request are sent to the
   port from which the request came.  Specific queries may be sent from
   ports other than the RIPng port, but they must be directed to the
   RIPng port on the target machine.



   The RIPng packet format is:

       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
      |  command (1)  |  version (1)  |       must be zero (2)        |
      |                                                               |
      ~                Route Table Entry 1 (20)                       ~
      |                                                               |
      |                                                               |
      ~                         ...                                   ~
      |                                                               |
      |                                                               |
      ~                Route Table Entry N (20)                       ~
      |                                                               |


   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


   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.

全てのメッセージがコマンドとバージョン数からなるRIPngヘッダを含む。当文書は、プロトコルバージョン1について触れる(2.4 入力処理を参照)。コマンドフィールドは、このメッセージの目的を定義するために用いられる。バージョン1に実装されたコマンドは次の通り:

   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.


   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 ネクストホップ

   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


   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.


   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.



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