RIP Version 2 - Carrying Additional Information
RFC 1723

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                          G. Malkin
Request for Comments: 1723                                Xylogics, Inc.
Obsoletes: 1388                                            November 1994
Updates: 1058
Category: Standards Track

                             RIP Version 2
                    Carrying Additional Information

Status 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.

Abstract

   This document specifies an extension of the Routing Information
   Protocol (RIP), as defined in [1,2], to expand the amount of useful
   information carried in RIP messages and to add a measure of security.
   This memo obsoletes RFC 1388, which specifies an update to the
   "Routing Information Protocol" STD 34, RFC 1058.

   The RIP-2 protocol analysis is documented in RFC 1721 [4].

   The RIP-2 applicability statement is document in RFC 1722 [5].

   The RIP-2 MIB description is defined in RFC 1724 [3].  This memo
   obsoletes RFC 1389.

Acknowledgements

   I would like to thank the IETF ripv2 Working Group for their help in
   improving the RIP-2 protocol.

Malkin                                                          [Page 1]
RFC 1723                     RIP Version 2                 November 1994

Table of Contents

   1.  Justification . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 3
   3.1   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 4
   3.2   Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.3   Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.4   Next Hop  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.5   Multicasting  . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.6   Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.1   Compatibility Switch  . . . . . . . . . . . . . . . . . . . . 6
   4.2   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 6
   4.3   Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 7
   4.4   Addressless Links . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   Appendix A  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

1. 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 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 protocol does not consider autonomous systems and
   IGP/EGP interactions, subnetting, and authentication since
   implementations of these postdate RIP.  The lack of subnet masks is a

Malkin                                                          [Page 2]
RFC 1723                     RIP Version 2                 November 1994

   particularly serious problem for routers since they need a subnet
   mask to know how to determine a route.  If a RIP 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 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. Protocol Extensions

   This document does not change the RIP protocol per se.  Rather, it
   provides extensions to the message format which allows routers to