RFC 2080 (rfc2080) - Page 3 of 19
RIPng for IPv6
Alternative Format: Original Text Document
RFC 2080 RIPng for IPv6 January 1997
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.
1.1 Theoretical Underpinnings
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.
1.2 Limitations of the Protocol
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.
Malkin & Minnear Standards Track