Network Working Group                                          G. MalkinRequest for Comments: 1723                                Xylogics, Inc.Obsoletes: 1388                                            November 1994Updates: 1058Category: Standards Track                             RIP Version 2                    Carrying Additional InformationStatus 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 1994Table 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  . . . . . . . . . . . . . . . . . . . . . . . . . 91. 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 aMalkin                                                          [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   share important additional information.   The first four octets of a RIP message contain the RIP header.  The   remainder of the message is composed of 1 - 25 route entries (20   octets each).  The new RIP message format is:    0                   1                   2                   3 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)   |           unused              |   +---------------+---------------+-------------------------------+   | Address Family Identifier (2) |        Route Tag (2)          |   +-------------------------------+-------------------------------+   |                         IP Address (4)                        |   +---------------------------------------------------------------+   |                         Subnet Mask (4)                       |   +---------------------------------------------------------------+   |                         Next Hop (4)                          |   +---------------------------------------------------------------+   |                         Metric (4)                            |   +---------------------------------------------------------------+   The Command, Address Family Identifier (AFI), IP Address, and Metric   all have the meanings defined in RFC 1058.  The Version field will   specify version number 2 for RIP messages which use authentication or   carry information in any of the newly defined fields.  The contents   of the unused field (two octets) shall be ignored.   All fields are coded in IP network byte order (big-endian).Malkin                                                          [Page 3]RFC 1723                     RIP Version 2                 November 19943.1 Authentication   Since authentication is a per message function, and since there is   only one 2-octet field available in the message header, and since any   reasonable authentication scheme will require more than two octets,   the authentication scheme for RIP version 2 will use the space of an   entire RIP entry.  If the Address Family Identifier of the first (and   only the first) entry in the message is 0xFFFF, then the remainder of   the entry contains the authentication.  This means that there can be,   at most, 24 RIP entries in the remainder of the message.  If   authentication is not in use, then no entries in the message should   have an Address Family Identifier of 0xFFFF.  A RIP message which   contains an authentication entry would begin with the following   format:    0                   1                   2                   3 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)   |            unused             |   +---------------+---------------+-------------------------------+   |             0xFFFF            |    Authentication Type (2)    |   +-------------------------------+-------------------------------+   ~                       Authentication (16)                     ~   +---------------------------------------------------------------+   Currently, the only Authentication Type is simple password and it is   type 2.  The remaining 16 octets contain the plain text password.  If   the password is under 16 octets, it must be left-justified and padded   to the right with nulls (0x00).3.2 Route Tag   The Route Tag (RT) 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" RIP   routes (routes for networks within the RIP routing domain) from   "external" RIP routes, which may have been imported from an EGP or   another IGP.   Routers supporting protocols other than RIP should be configurable to   allow the Route Tag to be configured for routes imported from   different sources.  For example, routes imported from EGP or BGP   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   RIP domain use it consistently.  This allows for the possibility of aMalkin                                                          [Page 4]RFC 1723                     RIP Version 2                 November 1994   BGP-RIP protocol interactions document, which would describe methods   for synchronizing routing in a transit network.3.3 Subnet mask   The Subnet Mask field contains the subnet mask which is applied to   the IP address to yield the non-host portion of the address.  If this   field is zero, then no subnet mask has been included for this entry.   On an interface where a RIP-1 router may hear and operate on the   information in a RIP-2 routing entry the following rules apply:   1) information internal to one network must never be advertised into      another network,   2) information about a more specific subnet may not be advertised      where RIP-1 routers would consider it a host route, and   3) supernet routes (routes with a netmask less specific than the      "natural" network mask) must not be advertised where they could be      misinterpreted by RIP-1 routers.3.4 Next Hop