IPv6用RIPng（序論）

   This memo describes one protocol in a series of routing protocols
   based on the Bellman-Ford (or distance vector) algorithm.  This
   algorithm has been used for routing computations in computer networks
   since the early days of the ARPANET.  The particular packet formats
   and protocol described here are based on the program "routed," which
   is included with the Berkeley distribution of Unix.

   In an international network, such as the Internet, it is very
   unlikely that a single routing protocol will used for the entire
   network.  Rather, the network will be organized as a collection of
   Autonomous Systems (AS), each of which will, in general, be
   administered by a single entity.  Each AS will have its own routing
   technology, which may differ among AS's.  The routing protocol used
   within an AS is referred to as an Interior Gateway Protocol (IGP).  A
   separate protocol, called an Exterior Gateway Protocol (EGP), is used
   to transfer routing information among the AS's.  RIPng was designed
   to work as an IGP in moderate-size AS's.  It is not intended for use
   in more complex environments.  For information on the context into
   which RIP version 1 (RIP-1) is expected to fit, see Braden and Postel
   [6].

   RIPng is one of a class of algorithms known as Distance Vector
   algorithms.  The earliest description of this class of algorithms
   known to the author is in Ford and Fulkerson [8].  Because of this,
   they are sometimes known as Ford-Fulkerson algorithms.  The term
   Bellman-Ford is also used, and derives from the fact that the
   formulation is based on Bellman's equation [4].  The presentation in
   this document is closely based on [5].  This document contains a
   protocol specification.  For an introduction to the mathematics of
   routing algorithms, see [1].  The basic algorithms used by this
   protocol were used in computer routing as early as 1969 in the
   ARPANET.  However, the specific ancestry of this protocol is within
   the Xerox network protocols.  The PUP protocols [7] used the Gateway
   Information Protocol to exchange routing information.  A somewhat
   updated version of this protocol was adopted for the Xerox Network
   Systems (XNS) architecture, with the name Routing Information
   Protocol [9].  Berkeley's routed is largely the same as the Routing
   Information Protocol, with XNS addresses replaced by a more general
   address format capable of handling IPv4 and other types of address,
   and with routing updates limited to one every 30 seconds.  Because of
   this similarity, the term Routing Information Protocol (or just RIP)
   is used to refer to both the XNS protocol and the protocol used by
   routed.

   An introduction to the theory and math behind Distance Vector
   protocols is provided in [1].  It has not been incorporated in this
   document for the sake of brevity.

   This protocol does not solve every possible routing problem.  As
   mentioned above, it is primarily intended for use as an IGP in
   networks of moderate size.  In addition, the following specific
   limitations are be mentioned:

   - The protocol is limited to networks whose longest path (the
     network's diameter) is 15 hops.  The designers believe that the
     basic protocol design is inappropriate for larger networks.  Note
     that this statement of the limit assumes that a cost of 1 is used
     for each network.  This is the way RIPng is normally configured.
     If the system administrator chooses to use larger costs, the upper
     bound of 15 can easily become a problem.

   - The protocol depends upon "counting to infinity" to resolve certain
     unusual situations (see section 2.2 in [1]).  If the system of
     networks has several hundred networks, and a routing loop was formed
     involving all of them, the resolution of the loop would require
     either much time (if the frequency of routing updates were limited)
     or bandwidth (if updates were sent whenever changes were detected).
     Such a loop would consume a large amount of network bandwidth
     before the loop was corrected.  We believe that in realistic cases,
     this will not be a problem except on slow lines.  Even then, the
     problem will be fairly unusual, since various precautions are taken
     that should prevent these problems in most cases.

   - This protocol uses fixed "metrics" to compare alternative routes.
     It is not appropriate for situations where routes need to be chosen
     based on real-time parameters such a measured delay, reliability,
     or load.  The obvious extensions to allow metrics of this type are
     likely to introduce instabilities of a sort that the protocol is
     not designed to handle.