Network Working Group                                          G. MalkinRequest for Comments: 2453                                  Bay NetworksObsoletes: 1723, 1388                                      November 1998STD: 56Category: Standards Track                             RIP Version 2Status of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (1998).  All Rights Reserved.Abstract   This document specifies an extension of the Routing Information   Protocol (RIP), as defined in [1], to expand the amount of useful   information carried in RIP messages and to add a measure of security.   A companion document will define the SNMP MIB objects for RIP-2 [2].   An additional document will define cryptographic security   improvements for RIP-2 [3].Acknowledgements   I would like to thank the IETF RIP Working Group for their help in   improving the RIP-2 protocol. Much of the text for the background   discussions about distance vector protocols and some of the   descriptions of the operation of RIP were taken from "Routing   Information Protocol" by C. Hedrick [1]. Some of the final editing on   the document was done by Scott Bradner.Malkin                      Standards Track                     [Page 1]RFC 2453                     RIP Version 2                 November 1998Table of Contents   1.  Justification  . . . . . . . . . . . . . . . . . . . . . . . .  3   2.  Current RIP  . . . . . . . . . . . . . . . . . . . . . . . . .  3   3.  Basic Protocol . . . . . . . . . . . . . . . . . . . . . . . .  3   3.1   Introduction   . . . . . . . . . . . . . . . . . . . . . . .  3   3.2   Limitations of the Protocol  . . . . . . . . . . . . . . . .  5   3.3.  Organization of this document  . . . . . . . . . . . . . . .  6   3.4   Distance Vector Algorithms . . . . . . . . . . . . . . . . .  6   3.4.1    Dealing with changes in topology  . . . . . . . . . . . . 12   3.4.2    Preventing instability  . . . . . . . . . . . . . . . . . 13   3.4.3    Split horizon . . . . . . . . . . . . . . . . . . . . . . 15   3.4.4    Triggered updates . . . . . . . . . . . . . . . . . . . . 17   3.5   Protocol Specification   . . . . . . . . . . . . . . . . . . 18   3.6   Message Format . . . . . . . . . . . . . . . . . . . . . . . 20   3.7   Addressing Considerations  . . . . . . . . . . . . . . . . . 22   3.8   Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24   3.9   Input Processing . . . . . . . . . . . . . . . . . . . . . . 25   3.9.1    Request Messages  . . . . . . . . . . . . . . . . . . . . 25   3.9.2    Response Messages . . . . . . . . . . . . . . . . . . . . 26   3.10  Output Processing  . . . . . . . . . . . . . . . . . . . . . 28   3.10.1   Triggered Updates . . . . . . . . . . . . . . . . . . . . 29   3.10.2   Generating Response Messages. . . . . . . . . . . . . . . 30   4.  Protocol Extensions  . . . . . . . . . . . . . . . . . . . . . 31   4.1   Authentication . . . . . . . . . . . . . . . . . . . . . . . 31   4.2   Route Tag  . . . . . . . . . . . . . . . . . . . . . . . . . 32   4.3   Subnet Mask  . . . . . . . . . . . . . . . . . . . . . . . . 32   4.4   Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 33   4.5   Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 33   4.6   Queries  . . . . . . . . . . . . . . . . . . . . . . . . . . 33   5.  Compatibility  . . . . . . . . . . . . . . . . . . . . . . . . 34   5.1   Compatibility Switch . . . . . . . . . . . . . . . . . . . . 34   5.2   Authentication . . . . . . . . . . . . . . . . . . . . . . . 34   5.3   Larger Infinity  . . . . . . . . . . . . . . . . . . . . . . 35   5.4   Addressless Links  . . . . . . . . . . . . . . . . . . . . . 35   6.  Interaction between version 1 and version 2  . . . . . . . . . 35   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 36   Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37   References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 39Malkin                      Standards Track                     [Page 2]RFC 2453                     RIP Version 2                 November 19981.  Justification   With the advent of OSPF and IS-IS, there are those who believe that   RIP is obsolete.  While it is true that the newer IGP routing   protocols are far superior to RIP, RIP does have some advantages.   Primarily, in a small network, RIP has very little overhead in terms   of bandwidth used and configuration and management time.  RIP is also   very easy to implement, especially in relation to the newer IGPs.   Additionally, there are many, many more RIP implementations in the   field than OSPF and IS-IS combined.  It is likely to remain that way   for some years yet.   Given that RIP will be useful in many environments for some period of   time, it is reasonable to increase RIP's usefulness.  This is   especially true since the gain is far greater than the expense of the   change.2. Current RIP   The current RIP-1 message contains the minimal amount of information   necessary for routers to route messages through a network.  It also   contains a large amount of unused space, owing to its origins.   The current RIP-1 protocol does not consider autonomous systems and   IGP/EGP interactions, subnetting [11], and authentication since   implementations of these postdate RIP-1.  The lack of subnet masks is   a particularly serious problem for routers since they need a subnet   mask to know how to determine a route.  If a RIP-1 route is a network   route (all non-network bits 0), the subnet mask equals the network   mask.  However, if some of the non-network bits are set, the router   cannot determine the subnet mask.  Worse still, the router cannot   determine if the RIP-1 route is a subnet route or a host route.   Currently, some routers simply choose the subnet mask of the   interface over which the route was learned and determine the route   type from that.3.  Basic Protocol3.1 Introduction   RIP is a routing protocol 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.Malkin                      Standards Track                     [Page 3]RFC 2453                     RIP Version 2                 November 1998   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.  RIP 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-1 is expected to fit, see Braden and Postel [6].   RIP uses one of a class of routing 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.   RIP is intended for use within the IP-based Internet.  The Internet   is organized into a number of networks connected by special purpose   gateways known as routers.  The networks may be either point-to-point   links or more complex networks such as Ethernet or token ring.  Hosts   and routers are presented with IP datagrams addressed to some host.   Routing is the method by which the host or router decides where to   send the datagram.  It may be able to send the datagram directly to   the destination, if that destination is on one of the networks that   are directly connected to the host or router.  However, the   interesting case is when the destination is not directly reachable.Malkin                      Standards Track                     [Page 4]RFC 2453                     RIP Version 2                 November 1998   In this case, the host or router attempts to send the datagram to a   router that is nearer the destination.  The goal of a routing   protocol is very simple: It is to supply the information that is   needed to do routing.3.2 Limitations of the Protocol   This protocol does not solve every possible routing problem.  As   mentioned above, it is primary 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 RIP 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. (This will be explained in the next section.)     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