RIP Version 2 Carrying Additional Information
draft-malkin-rip-05

Internet Engineering Task Force                                G. Malkin
Internet Draft                                                  Xylogics
Updates RFC 1058                                           November 1992

                             RIP Version 2
                    Carrying Additional Information

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 packets and to add a measure of security.

   A companion document will define the SNMP MIB objects for RIP-2 [2].

Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts).

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

   It is intended that this document will be submitted to the IESG for
   consideration as a standards document.  Distribution of this document
   is unlimited.

Acknowledgements

   I would like to thank the following for their contributions to this
   document: Fred Baker, Noel Chiappa and Vince Fuller.

Expiration: May 5, 1993                                         [Page 1]
Internet Draft               RIP Version 2                 November 1992

                             Table of Contents

   1.  Justification . . . . . . . . . . . . . . . . . . . . . . . . . 3

   2.  Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 3

   3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 3
   3.1   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 4
   3.2   Routing Domain  . . . . . . . . . . . . . . . . . . . . . . . 5
   3.3   Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.4   Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.5   Next Hop  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   3.6   Multicasting  . . . . . . . . . . . . . . . . . . . . . . . . 6

   4.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 7
   4.1   Compatibility Switch  . . . . . . . . . . . . . . . . . . . . 7
   4.2   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 7
   4.3   Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 7
   4.4   Addressless Links . . . . . . . . . . . . . . . . . . . . . . 8

   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8

   Appendicies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

   References  . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . .10

Expiration: May 5, 1993                                         [Page 2]
Internet Draft               RIP Version 2                 November 1992

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 packet contains the minimal amount of information
   necessary for routers to route packets 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
   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 datagram format which allows routers to
   share important additional information.

Expiration: May 5, 1993                                         [Page 3]
Internet Draft               RIP Version 2                 November 1992

   The new RIP datagram 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)   |       Routing Domain (2)      |
   +---------------+---------------+-------------------------------+
   | 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 datagrams which use authentication
   or carry information in any of the newly defined fields.

   All fields are coded in IP network byte order (big-endian).

3.1 Authentication

   Since authentication is a per packet function, and since there is
   only one 2-byte field available in the packet header, and since any
   reasonable authentication scheme will require more than two bytes,
   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 packet 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 packet.  If
   authentication is not in use, then no entries in the packet should
   have an Address Family Identifier of 0xFFFF.  A RIP packet which
   contains an authentication entry would have 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)   |       Routing Domain (2)      |
   +---------------+---------------+-------------------------------+
   |             0xFFFF            |    Authentication Type (2)    |
   +-------------------------------+-------------------------------+
   ~                       Authentication (16)                     ~
   +---------------------------------------------------------------+

Expiration: May 5, 1993                                         [Page 4]
Internet Draft               RIP Version 2                 November 1992

   Currently, the only Authentication Type is simple password and it
   is type 2.  The remaining 16 bytes contain the plain text password.  If
   the password is under 16 bytes, it must be left-justified and
   padded to the right with nulls (0x00).

3.2 Routing Domain

   The Routing Domain (RD) number is the number of the routing process to
   which this update belongs. This field is used to associate the routing
   update to a specific routing process on the receiving router. The RD
   is needed to allow multiple, independent RIP "clouds" to co-exist on
   the same physical wire.  This gives administrators the ability to run
   multiple, possibly parallel, instances of RIP in order to implement
   simple policy.  This means that a router operating within one routing
   domain, or a set of routing domains, should ignore RIP packets which
   belong to another routing domain.  RD 0 is the default routing domain.

3.3 Route Tag

   The Route Tag (RT) field exists as a support for EGPs.  The contents
   and use of this field are outside the scope of this protocol.  However,
   it is expected that the field will be used to carry Autonomous System
   numbers for EGP and BGP.  Any RIP system which receives a RIP entry
   which contains a non-zero RT value must re-advertise that value.  Those
   routes which have no RT value must advertise an RT value of zero.

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

   For compatibility with RIP-1, it is necessary that RIP-1 subsumption
   (see Appendix B) rules be followed in RIP-2.  As a bottom line, a
   route which RIP-2 believes is a subnet route may not, under any
   circumstances, be viewed by RIP-1 systems as a host route.  To achieve
   this, the following applies:

   1 - On an interface where the RIP-2 update is sent as a multicast, no
       subsumption of routes is required.  However, if any two network or
       subnet routes have the same set of next hops and route tags, and either:

       (a) Have differing subnet masks, and one subnet subsumes the
           other, or
       (b) Have the same subnet mask, and the two IP Addresses differ
           only in the least significant bit for which the Subnet Mask
           bit is a 1,

Expiration: May 5, 1993                                         [Page 5]
Internet Draft               RIP Version 2                 November 1992

       then only one route needs to be advertised.  In the former case,
       only the less restrictive network mask need be advertised, and in
       the latter, the differing bit and its corresponding subnet mask bit
       may be zeroed.  Clearly, this operation is recursive.

   2 - On an interface where a RIP-1 router may hear and operate on the
       information, the subsumption rules of RFC 1058 must be obeyed;
       information internal to another network number must never be
       advertised into another network number, and information about a
       more specific subnet may not be advertised where RIP-1 would
       consider it a host route.  In addition, the automatic subsumption
       of routes in (b) above may not occur, as it would reduce route
       information available.

   RIP-1 compatibility is determined by the compatibility switch defined
   in section 4.1.

3.5 Next Hop

   The immediate next hop IP address to which packets to the destination
   specified by this route entry should be forwarded.  Specifying a
   value of 0.0.0.0 in this field indicates that routing should be via
   the originator of the RIP advertisement.  An address specified as
   a next hop must, per force, be directly reachable on the logical
   subnet over which the advertisement is made.

   The purpose of the Next Hop field is to eliminate packets being routed
   through extra hops in the system.  It is particularly useful when RIP
   is not being run on all of the routers on a network.  A simple example
   is given in Appendix A.  Note that Next Hop is an "advisory" field.  That
   is, if the provided information is ignored, a possibly sub-optimal,
   but absolutely valid, route may be taken.

3.6 Multicasting

   In order to reduce unnecessary load on those hosts which are not
   listening to RIP-2 packets, an IP multicast address will be used for
   periodic broadcasts.  The IP multicast address is 224.0.0.9.  Note that
   IGMP is not needed since these are inter-router messages which are not
   forwarded.

   In order to maintain backwards compatibility, the use of the
   multicast address will be configurable, as described in section 4.1.  If
   multicasting is used, it should be used on all interfaces which support
   it.

Expiration: May 5, 1993                                         [Page 6]
Internet Draft               RIP Version 2                 November 1992

4. Compatibility

   RFC 1058 showed considerable forethought in its specification of
   the handling of version numbers.  It specifies that RIP packets of
   version 0 are to be discarded, that RIP packets of version 1 are
   to be discarded if any Must Be Zero (MBZ) field is non-zero, and that
   RIP packets of any version greater than 1 should not be discarded
   simply because an MBZ field contains a value other than zero.  This
   means that the new version of RIP is totally backwards compatible
   with existing RIP implementations which adhere to this part of the
   specification.

4.1 Compatibility Switch

   A compatibility switch is necessary for three reasons.  First, there
   are implementations of RIP-1 in the field which do not follow RFC
   1058 as described above.  Second, the use of multicasting would
   prevent RIP-1 systems from receiving RIP-2 updates (which may
   be a desired feature in some cases).  Third, the route subsumption
   rules (see section 3.4) differ for RIP-1 and RIP-2 in their handling
   of subnet routes.

   The switch has three settings: RIP-1, in which only RIP-1 packets
   are sent; RIP-1 compatibility, in which RIP-2 packets are broadcast
   using RIP-1 subsumption rules; and RIP-2, in which RIP-2 packets are
   multicast.  The recommended default for this switch is RIP-1 compatibility.

4.2 Authentication

   Since an authentication entry is marked with an Address Family
   Identifier of 0xFFFF, a RIP-1 system would ignore this entry since
   it would belong to an address family other than IP.  It should
   be noted, therefore, that use of authentication will not prevent
   RIP-1 systems from seeing RIP-2 packets.  If desired, this may
   be done using multicasting, as described in sections 3.6 and 4.1.

4.3 Larger Infinity

   While on the subject of compatibility, there is one item which people
   have requested: increasing infinity.  The primary reason that this
   cannot be done is that it would violate backwards compatibility.  A
   larger infinity would obviously confuse older versions of rip.  At
   best, they would ignore the route as they would ignore a metric of
   16.  There was also a proposal to make the Metric a single byte and reuse
   the high three bytes, but this would break any implementations which
   treat the metric as a long.

Expiration: May 5, 1993                                         [Page 7]
Internet Draft               RIP Version 2                 November 1992

4.4 Addressless Links

   As in RIP-1, addressless links will not be supported by RIP-2.

5. Security Considerations

   The basic RIP protocol is not a secure protocol.  To bring RIP-2
   in line with more modern routing protocols, an extensible authentication
   mechanism has been incorporated into the protocol enhancements.  This
   mechanism is described in sections 3.1 and 4.2.

Expiration: May 5, 1993                                         [Page 8]
Internet Draft               RIP Version 2                 November 1992

Appendix A

   This is a simple example of the use of the next hop field in a rip entry.

      -----   -----   -----           -----   -----   -----
      |IR1|   |IR2|   |IR3|           |XR1|   |XR2|   |XR3|
      --+--   --+--   --+--           --+--   --+--   --+--
        |       |       |               |       |       |
      --+-------+-------+---------------+-------+-------+--
        <-------------RIP-2------------->

   Assume that IR1, IR2, and IR3 are all "internal" routers which are
   under one administration (e.g. a campus) which has elected to use
   RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under
   separate administration (e.g. a regional network, of which the campus
   is a member) and are using some other routing protocol (e.g. OSPF).
   XR1, XR2, and XR3 exchange routing information among themselves such
   that they know that the best routes to networks N1 and N2 are via
   XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By
   setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for
   N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for
   routing to occur without additional hops through XR1. Without the
   Next Hop (for example, if RIP-1 were used) it would be necessary for
   XR2 and XR3 to also participate in the RIP-2 protocol to eliminate
   extra hops.

Appendix B

   Route subsumption is basic to IP routing.  The idea is to reduce the
   amount of information other routers need to know in order to route
   packets correctly.  Here are generic and specific examples.

   Consider the subnets A.B.C.0 and A.B.D.0, where D = C + 1.  It would
   only be necessary to advertise A.B.C.0 with a subnet mask one bit
   shorter.

   Consider the following specific example:

        Address       Mask           Next hop
        ----------------------------------------
        191.154.88.0  255.255.255.0  191.154.3.8   Subnet route 1
        191.154.89.0  255.255.255.0  191.154.3.8   Subnet route 2
        ----------------------------------------
        191.154.88.0  255.255.254.0  191.154.3.8   Advertised route

Expiration: May 5, 1993                                         [Page 9]
Internet Draft               RIP Version 2                 November 1992

References

   [1] Hedrick, C., Routing Information Protocol, Request For Comments
       (RFC) 1058, Rutgers University, June 1988.

   [2] Malkin, G., and F. Baker, draft-ietf-ripv2-mibext-01.txt,
       Xylogics, ACC, May 8, 1992.

Author's Address

   Gary Scott Malkin
   Xylogics, Inc.
   53 Third Avenue
   Burlington, MA 01803

   Phone:  (617) 272-8140
   EMail:  gmalkin@Xylogics.COM

Expiration: May 5, 1993                                        [Page 10]