home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-ripv2-protocol-v2-01.txt < prev    next >
Text File  |  1996-10-23  |  57KB  |  1,286 lines
  1.  
  2. Draft-ietf-ripv2-protocol-v2-01.txt                               G. Malkin
  3. Obsoletes RFCs 1723, 1388                                   Bay Networks
  4.                                                             October 1996
  5.  
  6.  
  7.                              RIP Version 2
  8.                     Carrying Additional Information
  9.  
  10.  
  11. Abstract
  12.  
  13.    This document specifies an extension of the Routing Information
  14.    Protocol (RIP), as defined in [1,2], to expand the amount of useful
  15.    information carried in RIP messages and to add a measure of security.
  16.  
  17.    A companion document will define the SNMP MIB objects for RIP-2 [3].
  18.    An additional document will define cryptographic security
  19.    improvements for RIP-2 [10].
  20.  
  21.  
  22. Status of this Memo
  23.  
  24.    This document is an Internet Draft.  Internet Drafts are working
  25.    documents of the Internet Engineering Task Force (IETF), its Areas,
  26.    and its Working Groups.  Note that other groups may also distribute
  27.    working documents as Internet Drafts.
  28.  
  29.    Internet Drafts are draft documents valid for a maximum of six
  30.    months. Internet Drafts may be updated, replaced, or obsoleted by
  31.    other documents at any time.  It is not appropriate to use Internet
  32.    Drafts as reference material or to cite them other than as a "working
  33.    draft" or "work in progress."
  34.  
  35.    Please check the I-D abstract listing contained in each Internet
  36.    Draft directory to learn the current status of this or any other
  37.    Internet Draft.
  38.  
  39.    It is intended that this document will be submitted to the IESG for
  40.    consideration as a standards document.  Distribution of this document
  41.    is unlimited.
  42.  
  43.  
  44. Acknowledgements
  45.  
  46.    I would like to thank the IETF RIP Working Group for their help in
  47.    improving the RIP-2 protocol.
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Malkin                      Expires: 22Apr97                    [Page 1]
  54.  
  55. Internet Draft               RIP Version 2                  October 1996
  56.  
  57.  
  58.                              Table of Contents
  59.  
  60.  
  61.    1.  Justification  . . . . . . . . . . . . . . . . . . . . . . . .  3
  62.  
  63.    2.  Current RIP  . . . . . . . . . . . . . . . . . . . . . . . . .  3
  64.  
  65.    3.  Basic Protocol . . . . . . . . . . . . . . . . . . . . . . . .  3
  66.    3.1   Introduction   . . . . . . . . . . . . . . . . . . . . . . .  3
  67.    3.2   Limitations of the Protocol  . . . . . . . . . . . . . . . .  4
  68.    3.3   Protocol Specification . . . . . . . . . . . . . . . . . . .  5
  69.    3.4   Message Format . . . . . . . . . . . . . . . . . . . . . . .  6
  70.    3.5   Addressing Considerations  . . . . . . . . . . . . . . . . .  8
  71.    3.6   Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
  72.    3.7   Input Processing . . . . . . . . . . . . . . . . . . . . . . 11
  73.    3.8   Output Processing  . . . . . . . . . . . . . . . . . . . . . 15
  74.    3.9   Split Horizon  . . . . . . . . . . . . . . . . . . . . . . . 16
  75.  
  76.    4.  Protocol Extensions  . . . . . . . . . . . . . . . . . . . . . 17
  77.    4.1   Authentication . . . . . . . . . . . . . . . . . . . . . . . 17
  78.    4.2   Route Tag  . . . . . . . . . . . . . . . . . . . . . . . . . 18
  79.    4.3   Subnet Mask  . . . . . . . . . . . . . . . . . . . . . . . . 19
  80.    4.4   Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 19
  81.    4.5   Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 19
  82.    4.6   Queries  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
  83.  
  84.    5.  Compatibility  . . . . . . . . . . . . . . . . . . . . . . . . 20
  85.    5.1   Compatibility Switch . . . . . . . . . . . . . . . . . . . . 20
  86.    5.2   Authentication . . . . . . . . . . . . . . . . . . . . . . . 20
  87.    5.3   Larger Infinity  . . . . . . . . . . . . . . . . . . . . . . 21
  88.    5.4   Addressless Links  . . . . . . . . . . . . . . . . . . . . . 21
  89.  
  90.    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
  91.  
  92.    Appendicies  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
  93.  
  94.    References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
  95.  
  96.    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Malkin                      Expires: 22Apr97                    [Page 2]
  110.  
  111. Internet Draft               RIP Version 2                  October 1996
  112.  
  113.  
  114. 1.  Justification
  115.  
  116.    With the advent of OSPF and IS-IS, there are those who believe that
  117.    RIP is obsolete.  While it is true that the newer IGP routing
  118.    protocols are far superior to RIP, RIP does have some advantages.
  119.    Primarily, in a small network, RIP has very little overhead in terms
  120.    of bandwidth used and configuration and management time.  RIP is also
  121.    very easy to implement, especially in relation to the newer IGPs.
  122.  
  123.    Additionally, there are many, many more RIP implementations in the
  124.    field than OSPF and IS-IS combined.  It is likely to remain that way
  125.    for some years yet.
  126.  
  127.    Given that RIP will be useful in many environments for some period of
  128.    time, it is reasonable to increase RIP's usefulness.  This is
  129.    especially true since the gain is far greater than the expense of the
  130.    change.
  131.  
  132.  
  133. 2.  Current RIP
  134.  
  135.    The current RIP-1 message contains the minimal amount of information
  136.    necessary for routers to route messages through a network.  It also
  137.    contains a large amount of unused space, owing to its origins.
  138.  
  139.    The current RIP-1 protocol does not consider autonomous systems and
  140.    IGP/EGP interactions, subnetting, and authentication since
  141.    implementations of these postdate RIP-1.  The lack of subnet masks is
  142.    a particularly serious problem for routers since they need a subnet
  143.    mask to know how to determine a route.  If a RIP-1 route is a network
  144.    route (all non-network bits 0), the subnet mask equals the network
  145.    mask.  However, if some of the non-network bits are set, the router
  146.    cannot determine the subnet mask.  Worse still, the router cannot
  147.    determine if the RIP-1 route is a subnet route or a host route.
  148.    Currently, some routers simply choose the subnet mask of the
  149.    interface over which the route was learned and determine the route
  150.    type from that.
  151.  
  152.  
  153. 3.  Basic Protocol
  154.  
  155.    Much of the material in this section has been taken from [1].
  156.  
  157. 3.1 Introduction
  158.  
  159.    RIP is a routing protocol based on the Bellman-Ford (or distance
  160.    vector) algorithm.  This algorithm has been used for routing
  161.    computations in computer networks since the early days of the
  162.  
  163.  
  164.  
  165. Malkin                      Expires: 22Apr97                    [Page 3]
  166.  
  167. Internet Draft               RIP Version 2                  October 1996
  168.  
  169.  
  170.    ARPANET.  The particular packet formats and protocol described here
  171.    are based on the program "routed," which is included with the
  172.    Berkeley distribution of Unix.
  173.  
  174.    In an international network, such as the Internet, it is very
  175.    unlikely that a single routing protocol will used for the entire
  176.    network.  Rather, the network will be organized as a collection of
  177.    Autonomous Systems (AS), each of which will, in general, be
  178.    administered by a single entity.  Each AS will have its own routing
  179.    technology, which may differ among AS's.  The routing protocol used
  180.    within an AS is referred to as an Interior Gateway Protocol (IGP).  A
  181.    separate protocol, called an Exterior Gateway Protocol (EGP), is used
  182.    to transfer routing information among the AS's.  RIP was designed to
  183.    work as an IGP in moderate-size AS's.  It is not intended for use in
  184.    more complex environments.  For information on the context into which
  185.    RIP-1 is expected to fit, see Braden and Postel [6].
  186.  
  187.    RIP uses one of a class of routing algorithms known as Distance
  188.    Vector algorithms.  The earliest description of this class of
  189.    algorithms known to the author is in Ford and Fulkerson [8].  Because
  190.    of this, they are sometimes known as Ford-Fulkerson algorithms.  The
  191.    term Bellman-Ford is also used, and derives from the fact that the
  192.    formulation is based on Bellman's equation [4].  The presentation in
  193.    this document is closely based on [5].  This document contains a
  194.    protocol specification.  For an introduction to the mathematics of
  195.    routing algorithms, see [1].  The basic algorithms used by this
  196.    protocol were used in computer routing as early as 1969 in the
  197.    ARPANET.  However, the specific ancestry of this protocol is within
  198.    the Xerox network protocols.  The PUP protocols [7] used the Gateway
  199.    Information Protocol to exchange routing information.  A somewhat
  200.    updated version of this protocol was adopted for the Xerox Network
  201.    Systems (XNS) architecture, with the name Routing Information
  202.    Protocol [9].  Berkeley's routed is largely the same as the Routing
  203.    Information Protocol, with XNS addresses replaced by a more general
  204.    address format capable of handling IPv4 and other types of address,
  205.    and with routing updates limited to one every 30 seconds.  Because of
  206.    this similarity, the term Routing Information Protocol (or just RIP)
  207.    is used to refer to both the XNS protocol and the protocol used by
  208.    routed.
  209.  
  210.    An introduction to the theory and math behind Distance Vector
  211.    protocols is provided in [1].  It has not been incorporated in this
  212.    document for the sake of brevity.
  213.  
  214. 3.2 Limitations of the Protocol
  215.  
  216.    This protocol does not solve every possible routing problem.  As
  217.    mentioned above, it is primary intended for use as an IGP in networks
  218.  
  219.  
  220.  
  221. Malkin                      Expires: 22Apr97                    [Page 4]
  222.  
  223. Internet Draft               RIP Version 2                  October 1996
  224.  
  225.  
  226.    of moderate size.  In addition, the following specific limitations
  227.    are be mentioned:
  228.  
  229.    - The protocol is limited to networks whose longest path (the
  230.      network's diameter) is 15 hops.  The designers believe that the
  231.      basic protocol design is inappropriate for larger networks.  Note
  232.      that this statement of the limit assumes that a cost of 1 is used
  233.      for each network.  This is the way RIP is normally configured.  If
  234.      the system administrator chooses to use larger costs, the upper
  235.      bound of 15 can easily become a problem.
  236.  
  237.    - The protocol depends upon "counting to infinity" to resolve certain
  238.      unusual situations (see section 2.2 in [1]).  If the system of
  239.      networks has several hundred networks, and a routing loop was
  240.      formed involving all of them, the resolution of the loop would
  241.      require either much time (if the frequency of routing updates were
  242.      limited) or bandwidth (if updates were sent whenever changes were
  243.      detected).  Such a loop would consume a large amount of network
  244.      bandwidth before the loop was corrected.  We believe that in
  245.      realistic cases, this will not be a problem except on slow lines.
  246.      Even then, the problem will be fairly unusual, since various
  247.      precautions are taken that should prevent these problems in most
  248.      cases.
  249.  
  250.    - This protocol uses fixed "metrics" to compare alternative routes.
  251.      It is not appropriate for situations where routes need to be chosen
  252.      based on real-time parameters such a measured delay, reliability,
  253.      or load.  The obvious extensions to allow metrics of this type are
  254.      likely to introduce instabilities of a sort that the protocol is
  255.      not designed to handle.
  256.  
  257. 3.3 Protocol Specification
  258.  
  259.    RIP is intended to allow routers to exchange information for
  260.    computing routes through an IPv4-based network.  Any router that uses
  261.    RIP is assumed to have interfaces to one or more networks, otherwise
  262.    it isn't really a router.  These are referred to as its directly-
  263.    connected networks.  The protocol relies on access to certain
  264.    information about each of these networks, the most important of which
  265.    is its metric.  The RIP metric of a network is an integer between 1
  266.    and 15, inclusive.  It is set in some manner not specified in this
  267.    protocol; however, given the maximum path limit of 15, a value of 1
  268.    is usually used.  Implementations should allow the system
  269.    administrator to set the metric of each network.  In addition to the
  270.    metric, each network will have an IPv4 destination address and subnet
  271.    mask associated with it.  These are to be set by the system
  272.    administrator in a manner not specified in this protocol.
  273.  
  274.  
  275.  
  276.  
  277. Malkin                      Expires: 22Apr97                    [Page 5]
  278.  
  279. Internet Draft               RIP Version 2                  October 1996
  280.  
  281.  
  282.    Each router that implements RIP is assumed to have a routing table.
  283.    This table has one entry for every destination that is reachable
  284.    throughout the system operating RIP.  Each entry contains at least
  285.    the following information:
  286.  
  287.    - The IPv4 address of the destination.
  288.  
  289.    - A metric, which represents the total cost of getting a datagram
  290.      from the router to that destination.  This metric is the sum of the
  291.      costs associated with the networks that would be traversed to get
  292.      to the destination.
  293.  
  294.    - The IPv4 address of the next router along the path to the
  295.      destination (i.e., the next hop).  If the destination is on one of
  296.      the directly-connected networks, this item is not needed.
  297.  
  298.    - A flag to indicate that information about the route has changed
  299.      recently.  This will be referred to as the "route change flag."
  300.  
  301.    - Various timers associated with the route.  See section 3.6 for more
  302.      details on timers.
  303.  
  304.    The entries for the directly-connected networks are set up by the
  305.    router using information gathered by means not specified in this
  306.    protocol.  The metric for a directly-connected network is set to the
  307.    cost of that network.  As mentioned, 1 is the usual cost.  In that
  308.    case, the RIP metric reduces to a simple hop-count.  More complex
  309.    metrics may be used when it is desirable to show preference for some
  310.    networks over others (e.g., to indicate of differences in bandwidth
  311.    or reliability).
  312.  
  313.    Implementors may also choose to allow the system administrator to
  314.    enter additional routes.  These would most likely be routes to hosts
  315.    or networks outside the scope of the routing system.  They are
  316.    referred to as "static routes."  Entries for destinations other than
  317.    these initial ones are added and updated by the algorithms described
  318.    in the following sections.
  319.  
  320.    In order for the protocol to provide complete information on routing,
  321.    every router in the AS must participate in the protocol.  In cases
  322.    where multiple IGPs are in use, there must be at least one router
  323.    which can leak routing information between the protocols.
  324.  
  325. 3.4 Message Format
  326.  
  327.    RIP is a UDP-based protocol.  Each router that uses RIP has a routing
  328.    process that sends and receives datagrams on UDP port number 520, the
  329.    RIP-1/RIP-2 port.  All communications intended for another routers's
  330.  
  331.  
  332.  
  333. Malkin                      Expires: 22Apr97                    [Page 6]
  334.  
  335. Internet Draft               RIP Version 2                  October 1996
  336.  
  337.  
  338.    RIP process are sent to the RIP port.  All routing update messages
  339.    are sent from the RIP port.  Unsolicited routing update messages have
  340.    both the source and destination port equal to the RIP port.  Update
  341.    messages sent in response to a request are sent to the port from
  342.    which the request came.  Specific queries may be sent from ports
  343.    other than the RIP port, but they must be directed to the RIP port on
  344.    the target machine.
  345.  
  346.    The RIP packet format is:
  347.  
  348.        0                   1                   2                   3
  349.        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
  350.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  351.       |  command (1)  |  version (1)  |       must be zero (2)        |
  352.       +---------------+---------------+-------------------------------+
  353.       |                                                               |
  354.       ~                         RIP Entry (20)                        ~
  355.       |                                                               |
  356.       +---------------+---------------+---------------+---------------+
  357.  
  358.    There may be between 1 and 25 (inclusive) RIP entries.  A RIP-1 entry
  359.    has the following format:
  360.  
  361.        0                   1                   2                   3
  362.        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
  363.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  364.       | address family identifier (2) |      must be zero (2)         |
  365.       +-------------------------------+-------------------------------+
  366.       |                        IPv4 address (4)                       |
  367.       +---------------------------------------------------------------+
  368.       |                        must be zero (4)                       |
  369.       +---------------------------------------------------------------+
  370.       |                        must be zero (4)                       |
  371.       +---------------------------------------------------------------+
  372.       |                           metric (4)                          |
  373.       +---------------------------------------------------------------+
  374.  
  375.    Field sizes are given in octets.  Unless otherwise specified, fields
  376.    contain binary integers, in network byte order, with the most-
  377.    significant octet first (big-endian).  Each tick mark represents one
  378.    bit.
  379.  
  380.    Every message contains a RIP header which consists of a command and a
  381.    version number.  This section of the document describes version 1 of
  382.    the protocol; section 4 describes the version 2 extensions.  The
  383.    command field is used to specify the purpose of this message.  The
  384.    commands implemented in version 1 and 2 are:
  385.  
  386.  
  387.  
  388.  
  389. Malkin                      Expires: 22Apr97                    [Page 7]
  390.  
  391. Internet Draft               RIP Version 2                  October 1996
  392.  
  393.  
  394.    1 - request    A request for the responding system to send all or
  395.                   part of its routing table.
  396.  
  397.    2 - response   A message containing all or part of the sender's
  398.                   routing table.  This message may be sent in response
  399.                   to a request, or it may be an unsolicited routing
  400.                   update generated by the sender.
  401.  
  402.    For each of these message types, in version 1, the remainder of the
  403.    datagram contains a list of Route Entries (RTEs).  Each RTE in this
  404.    list contains an Address Family Identifier (AFI), destination IPv4
  405.    address, and the cost to reach that destination (metric).
  406.  
  407.    The AFI is the type of address.  For RIP-1, only AF_INET (2) is
  408.    generally supported.
  409.  
  410.    The metric field contains a value between 1 and 15 (inclusive) which
  411.    specifies the current metric for the destination; or the value 16
  412.    (infinity), which indicates that the destination is not reachable.
  413.  
  414. 3.5 Addressing Considerations
  415.  
  416.    Distance vector routing can be used to describe routes to individual
  417.    hosts or to networks.  The RIP protocol allows either of these
  418.    possibilities.  The destinations appearing in request and response
  419.    messages can be networks, hosts, or a special code used to indicate a
  420.    default address.  In general, the kinds of routes actually used will
  421.    depend upon the routing strategy used for the particular network.
  422.    Many networks are set up so that routing information for individual
  423.    hosts is not needed.  If every node on a given network or subnet is
  424.    accessible through the same gateways, then there is no reason to
  425.    mention individual hosts in the routing tables.  However, networks
  426.    that include point-to-point lines sometimes require gateways to keep
  427.    track of routes to certain nodes.  Whether this feature is required
  428.    depends upon the addressing and routing approach used in the system.
  429.    Thus, some implementations may choose not to support host routes.  If
  430.    host routes are not supported, they are to be dropped when they are
  431.    received in response messages (see section 3.7.2).
  432.  
  433.    The RIP-1 packet format does not distinguish among various types of
  434.    address.  Fields that are labeled "address" can contain any of the
  435.    following:
  436.  
  437.       host address
  438.       subnet number
  439.       network number
  440.       zero (default route)
  441.  
  442.  
  443.  
  444.  
  445. Malkin                      Expires: 22Apr97                    [Page 8]
  446.  
  447. Internet Draft               RIP Version 2                  October 1996
  448.  
  449.  
  450.    Entities which use RIP-1 are assumed to use the most specific
  451.    information available when routing a datagram.  That is, when routing
  452.    a datagram, its destination address must first be checked against the
  453.    list of node addresses.  Then it must be checked to see whether it
  454.    matches any known subnet or network number.  Finally, if none of
  455.    these match, the default route is used.
  456.  
  457.    When a node evaluates information that it receives via RIP-1, its
  458.    interpretation of an address depends upon whether it knows the subnet
  459.    mask that applies to the net.  If so, then it is possible to
  460.    determine the meaning of the address.  For example, consider net
  461.    128.6.  It has a subnet mask of 255.255.255.0.  Thus 128.6.0.0 is a
  462.    network number, 128.6.4.0 is a subnet number, and 128.6.4.1 is a node
  463.    address.  However, if the node does not know the subnet mask,
  464.    evaluation of an address may be ambiguous.  If there is a non-zero
  465.    node part, there is no clear way to determine whether the address
  466.    represents a subnet number or a node address.  As a subnet number
  467.    would be useless without the subnet mask, addresses are assumed to
  468.    represent nodes in this situation.  In order to avoid this sort of
  469.    ambiguity, when using version 1, nodes must not send subnet routes to
  470.    nodes that cannot be expected to know the appropriate subnet mask.
  471.    Normally hosts only know the subnet masks for directly-connected
  472.    networks.  Therefore, unless special provisions have been made,
  473.    routes to a subnet must not be sent outside the network of which the
  474.    subnet is a part.  RIP-2 (see section 4) eliminates the subnet/host
  475.    ambiguity by including the subnet mask in the routing entry.
  476.  
  477.    This filtering is carried out by the routers at the "border" of the
  478.    subnetted network.  These are routers which connect that network with
  479.    some other network.  Within the subnetted network, each subnet is
  480.    treated as an individual network.  Routing entries for each subnet
  481.    are circulated by RIP.  However, border routers send only a single
  482.    entry for the network as a whole to nodes in other networks.  This
  483.    means that a border router will send different information to
  484.    different neighbors.  For neighbors connected to the subnetted
  485.    network, it generates a list of all subnets to which it is directly
  486.    connected, using the subnet number.  For neighbors connected to other
  487.    networks, it makes a single entry for the network as a whole, showing
  488.    the metric associated with that network.  This metric would normally
  489.    be the smallest metric for the subnets to which the gateway is
  490.    attached.
  491.  
  492.    Similarly, border routers must not mention host routes for nodes
  493.    within one of the directly-connected networks in messages to other
  494.    networks.  Those routes will be subsumed by the single entry for the
  495.    network as a whole.
  496.  
  497.    The special address 0.0.0.0 is used to describe a default route.  A
  498.  
  499.  
  500.  
  501. Malkin                      Expires: 22Apr97                    [Page 9]
  502.  
  503. Internet Draft               RIP Version 2                  October 1996
  504.  
  505.  
  506.    default route is used when it is not convenient to list every
  507.    possible network in the RIP updates, and when one or more closely-
  508.    connected gateways in the system are prepared to handle traffic to
  509.    the networks that are not listed explicitly.  These gateways should
  510.    create RIP entries for the address 0.0.0.0, just as if it were a
  511.    network to which they are connected.  The decision as to how gateways
  512.    create entries for 0.0.0.0 is left to the implementor.  Most
  513.    commonly, the system administrator will be provided with a way to
  514.    specify which gateways should create entries for 0.0.0.0; however,
  515.    other mechanisms are possible.  For example, an implementor might
  516.    decide that any gateway which speaks BGP should be declared to be a
  517.    default gateway.  It may be useful to allow the network administrator
  518.    to choose the metric to be used in these entries.  If there is more
  519.    than one default gateway, this will make it possible to express a
  520.    preference for one over the other.  The entries for 0.0.0.0 are
  521.    handled by RIP in exactly the same manner as if there were an actual
  522.    network with this address.  System administrators should take care to
  523.    make sure that routes to 0.0.0.0 do not propagate further than is
  524.    intended.  Generally, each autonomous system has its own preferred
  525.    default gateway.  Thus, routes involving 0.0.0.0 should generally not
  526.    leave the boundary of an autonomous system.  The mechanisms for
  527.    enforcing this are not specified in this document.
  528.  
  529. 3.6 Timers
  530.  
  531.    This section describes all events that are triggered by timers.
  532.  
  533.    Every 30 seconds, the RIP process is awakened to send an unsolicited
  534.    Response message containing the complete routing table (see section
  535.    3.9 on Split Horizon) to every neighboring router.  When there are
  536.    many routers on a single network, there is a tendency for them to
  537.    synchronize with each other such that they all issue updates at the
  538.    same time.  This can happen whenever the 30 second timer is affected
  539.    by the processing load on the system.  It is undesirable for the
  540.    update messages to become synchronized, since it can lead to
  541.    unnecessary collisions on broadcast networks.  Therefore,
  542.    implementations are required to take one of two precautions:
  543.  
  544.    - The 30-second updates are triggered by a clock whose rate is not
  545.      affected by system load or the time required to service the
  546.      previous update timer.
  547.  
  548.    - The 30-second timer is offset by a small random time (+/- 0 to 5
  549.      seconds) each time it is set.
  550.  
  551.    There are two timers associated with each route, a "timeout" and a
  552.    "garbage-collection" time.  Upon expiration of the timeout, the route
  553.    is no longer valid; however, it is retained in the routing table for
  554.  
  555.  
  556.  
  557. Malkin                      Expires: 22Apr97                   [Page 10]
  558.  
  559. Internet Draft               RIP Version 2                  October 1996
  560.  
  561.  
  562.    a short time so that neighbors can be notified that the route has
  563.    been dropped.  Upon expiration of the garbage-collection timer, the
  564.    route is finally removed from the routing table.
  565.  
  566.    The timeout is initialized when a route is established, and any time
  567.    an update message is received for the route.  If 180 seconds elapse
  568.    from the last time the timeout was initialized, the route is
  569.    considered to have expired, and the deletion process described below
  570.    begins for that route.
  571.  
  572.    Deletions can occur for one of two reasons: the timeout expires, or
  573.    the metric is set to 16 because of an update received from the
  574.    current router (see section 3.7.2 for a discussion of processing
  575.    updates from other routers).  In either case, the following events
  576.    happen:
  577.  
  578.    - The garbage-collection timer is set for 120 seconds.
  579.  
  580.    - The metric for the route is set to 16 (infinity).  This causes the
  581.      route to be removed from service.
  582.  
  583.    - The route change flag is set to indicate that this entry has been
  584.      changed.
  585.  
  586.    - The output process is signalled to trigger a response.
  587.  
  588.    Until the garbage-collection timer expires, the route is included in
  589.    all updates sent by this router.  When the garbage-collection timer
  590.    expires, the route is deleted from the routing table.
  591.  
  592.    Should a new route to this network be established while the garbage-
  593.    collection timer is running, the new route will replace the one that
  594.    is about to be deleted.  In this case the garbage-collection timer
  595.    must be cleared.
  596.  
  597.    Triggered updates also use a small timer; however, this is best
  598.    described in section 3.9.1.
  599.  
  600. 3.7 Input Processing
  601.  
  602.    This section will describe the handling of datagrams received on the
  603.    RIP port.  Processing will depend upon the value in the command
  604.    field.
  605.  
  606. 3.7.1 Request Messages
  607.  
  608.    A Request is used to ask for a response containing all or part of a
  609.    routers's routing table.  Normally, Requests are sent as broadcasts
  610.  
  611.  
  612.  
  613. Malkin                      Expires: 22Apr97                   [Page 11]
  614.  
  615. Internet Draft               RIP Version 2                  October 1996
  616.  
  617.  
  618.    (multicasts for RIP-2), from the RIP port, by routers which have just
  619.    come up and are seeking to fill in their routing tables as quickly as
  620.    possible.  However, there may be situations (e.g., router monitoring)
  621.    where the routing table of only a single router is needed.  In this
  622.    case, the Request should be sent directly to that router from a UDP
  623.    port other than the RIP port.  If such a Request is received, the
  624.    router responds directly to the requestor's address and port.
  625.  
  626.    The Request is processed entry by entry.  If there are no entries, no
  627.    response is given.  There is one special case.  If there is exactly
  628.    one entry in the request, and it has an address family identifier of
  629.    zero and a metric of infinity (i.e., 16), then this is a request to
  630.    send the entire routing table.  In that case, a call is made to the
  631.    output process to send the routing table to the requesting
  632.    address/port.  Except for this special case, processing is quite
  633.    simple.  Examine the list of RTEs in the Request one by one.  For
  634.    each entry, look up the destination in the router's routing database
  635.    and, if there is a route, put that route's metric in the metric field
  636.    of the RTE.  If there is no explicit route to the specified
  637.    destination, put infinity in the metric field.  Once all the entries
  638.    have been filled in, change the command from Request to Response and
  639.    send the datagram back to the requestor.
  640.  
  641.    Note that there is a difference in metric handling for specific and
  642.    whole-table requests.  If the request is for a complete routing
  643.    table, normal output processing is done, including Split Horizon (see
  644.    section 3.9 on Split Horizon).  If the request is for specific
  645.    entries, they are looked up in the routing table and the information
  646.    is returned as is; no Split Horizon processing is done.  The reason
  647.    for this distinction is the expectation that these requests are
  648.    likely to be used for different purposes.  When a router first comes
  649.    up, it multicasts a Request on every connected network asking for a
  650.    complete routing table.  It is assumed that these complete routing
  651.    tables are to be used to update the requestor's routing table.  For
  652.    this reason, Split Horizon must be done.  It is further assumed that
  653.    a Request for specific networks is made only by diagnostic software,
  654.    and is not used for routing.  In this case, the requester would want
  655.    to know the exact contents of the routing table and would not want
  656.    any information hidden or modified.
  657.  
  658. 3.7.2 Response Messages
  659.  
  660.    A Response can be received for one of several different reasons:
  661.  
  662.    - response to a specific query
  663.    - regular update (unsolicited response)
  664.    - triggered update caused by a route change
  665.  
  666.  
  667.  
  668.  
  669. Malkin                      Expires: 22Apr97                   [Page 12]
  670.  
  671. Internet Draft               RIP Version 2                  October 1996
  672.  
  673.  
  674.    Processing is the same no matter why the Response was generated.
  675.  
  676.    Because processing of a Response may update the router's routing
  677.    table, the Response must be checked carefully for validity.  The
  678.    Response must be ignored if it is not from the RIP port.  The
  679.    datagram's IPv4 source address should be checked to see whether the
  680.    datagram is from a valid neighbor; the source of the datagram must be
  681.    on a directly-connected network.  It is also worth checking to see
  682.    whether the response is from one of the router's own addresses.
  683.    Interfaces on broadcast networks may receive copies of their own
  684.    broadcasts immediately.  If a router processes its own output as new
  685.    input, confusion is likely so such datagrams must be ignored.
  686.  
  687.    Once the datagram as a whole has been validated, process the RTEs in
  688.    the Response one by one.  Again, start by doing validation.
  689.    Incorrect metrics and other format errors usually indicate
  690.    misbehaving neighbors and should probably be brought to the
  691.    administrator's attention.  For example, if the metric is greater
  692.    than infinity, ignore the entry but log the event.  The basic
  693.    validation tests are:
  694.  
  695.    - is the destination address valid (e.g., unicast; not net 0 or 127)
  696.    - is the metric valid (i.e., between 1 and 16, inclusive)
  697.  
  698.    If any check fails, ignore that entry and proceed to the next.
  699.    Again, logging the error is probably a good idea.
  700.  
  701.    Once the entry has been validated, update the metric by adding the
  702.    cost of the network on which the message arrived.  If the result is
  703.    greater than infinity, use infinity.  That is,
  704.  
  705.       metric = MIN (metric + cost, infinity)
  706.  
  707.    Now, check to see whether there is already an explicit route for the
  708.    destination address.  If there is no such route, add this route to
  709.    the routing table, unless the metric is infinity (there is no point
  710.    in adding a route which is unusable).  Adding a route to the routing
  711.    table consists of:
  712.  
  713.    - Setting the destination address to the destination address in the
  714.      RTE
  715.  
  716.    - Setting the metric to the newly calculated metric (as described
  717.      above)
  718.  
  719.    - Set the next hop address to be the address of the router from which
  720.      the datagram came
  721.  
  722.  
  723.  
  724.  
  725. Malkin                      Expires: 22Apr97                   [Page 13]
  726.  
  727. Internet Draft               RIP Version 2                  October 1996
  728.  
  729.  
  730.    - Initialize the timeout for the route.  If the garbage-collection
  731.      timer is running for this route, stop it (see section 3.6 for a
  732.      discussion of the timers)
  733.  
  734.    - Set the route change flag
  735.  
  736.    - Signal the output process to trigger an update (see section 3.8.1)
  737.  
  738.    If there is an existing route, compare the next hop address to the
  739.    address of the router from which the datagram came.  If this datagram
  740.    is from the same router as the existing route, reinitialize the
  741.    timeout.  Next, compare the metrics.  If the datagram is from the
  742.    same router as the existing route, and the new metric is different
  743.    than the old one; or, if the new metric is lower than the old one; do
  744.    the following actions:
  745.  
  746.    - Adopt the route from the datagram (i.e., put the new metric in and
  747.      adjust the next hop address, if necessary).
  748.  
  749.    - Set the route change flag and signal the output process to trigger
  750.      an update
  751.  
  752.    - If the new metric is infinity, start the deletion process
  753.      (described above); otherwise, re-initialize the timeout
  754.  
  755.    If the new metric is infinity, the deletion process begins for the
  756.    route, which is no longer used for routing packets.  Note that the
  757.    deletion process is started only when the metric is first set to
  758.    infinity.  If the metric was already infinity, then a new deletion
  759.    process is not started.
  760.  
  761.    If the new metric is the same as the old one, it is simplest to do
  762.    nothing further (beyond re-initializing the timeout, as specified
  763.    above); but, there is a heuristic which could be applied.  Normally,
  764.    it is senseless to replace a route if the new route has the same
  765.    metric as the existing route; this would cause the route to bounce
  766.    back and forth, which would generate an intolerable number of
  767.    triggered updates.  However, if the existing route is showing signs
  768.    of timing out, it may be better to switch to an equally-good
  769.    alternative route immediately, rather than waiting for the timeout to
  770.    happen.  Therefore, if the new metric is the same as the old one,
  771.    examine the timeout for the existing route.  If it is at least
  772.    halfway to the expiration point, switch to the new route.  This
  773.    heuristic is optional, but highly recommended.
  774.  
  775.    Any entry that fails these tests is ignored, as it is no better than
  776.    the current route.
  777.  
  778.  
  779.  
  780.  
  781. Malkin                      Expires: 22Apr97                   [Page 14]
  782.  
  783. Internet Draft               RIP Version 2                  October 1996
  784.  
  785.  
  786. 3.8 Output Processing
  787.  
  788.    This section describes the processing used to create response
  789.    messages that contain all or part of the routing table.  This
  790.    processing may be triggered in any of the following ways:
  791.  
  792.    - By input processing, when a Request is received (this Response is
  793.      unicast to the requestor; see section 3.7.1)
  794.  
  795.    - By the regular routing update (broadcast every 30 seconds) router.
  796.  
  797.    - By triggered updates (broadcast when a route changes)
  798.  
  799.    When a Response is to be sent to all neighbors (i.e., a regular or
  800.    triggered update), a Response message is directed to the router at
  801.    the far end of each connected point-to-point link, and is broadcast
  802.    (multicast for RIP-2) on all connected networks which support
  803.    broadcasting.  Thus, one Response is prepared for each directly-
  804.    connected network, and sent to the appropriate address (direct or
  805.    broadcast).  In most cases, this reaches all neighboring routers.
  806.    However, there are some cases where this may not be good enough.
  807.    This may involve a network that is not a broadcast network (e.g., the
  808.    ARPANET), or a situation involving dumb routers.  In such cases, it
  809.    may be necessary to specify an actual list of neighboring routers and
  810.    send a datagram to each one explicitly.  It is left to the
  811.    implementor to determine whether such a mechanism is needed, and to
  812.    define how the list is specified.
  813.  
  814. 3.8.1 Triggered Updates
  815.  
  816.    Triggered updates require special handling for two reasons.  First,
  817.    experience shows that triggered updates can cause excessive load on
  818.    networks with limited capacity or networks with many routers on them.
  819.    Therefore, the protocol requires that implementors include provisions
  820.    to limit the frequency of triggered updates.  After a triggered
  821.    update is sent, a timer should be set for a random interval between 1
  822.    and 5 seconds.  If other changes that would trigger updates occur
  823.    before the timer expires, a single update is triggered when the timer
  824.    expires.  The timer is then reset to another random value between 1
  825.    and 5 seconds.  A triggered update should be suppressed if a regular
  826.    update is due by the time the triggered update would be sent.
  827.  
  828.    Second, triggered updates do not need to include the entire routing
  829.    table.  In principle, only those routes which have changed need to be
  830.    included.  Therefore, messages generated as part of a triggered
  831.    update must include at least those routes that have their route
  832.    change flag set.  They may include additional routes, at the
  833.    discretion of the implementor; however, sending complete routing
  834.  
  835.  
  836.  
  837. Malkin                      Expires: 22Apr97                   [Page 15]
  838.  
  839. Internet Draft               RIP Version 2                  October 1996
  840.  
  841.  
  842.    updates is strongly discouraged.  When a triggered update is
  843.    processed, messages should be generated for every directly-connected
  844.    network.  Split Horizon processing is done when generating triggered
  845.    updates as well as normal updates (see section 3.9).  If, after Split
  846.    Horizon processing for a given network, a changed route will appear
  847.    unchanged on that network (e.g., it appears with an infinite metric),
  848.    the route need not be sent.  If no routes need be sent on that
  849.    network, the update may be omitted.  Once all of the triggered
  850.    updates have been generated, the route change flags should be
  851.    cleared.
  852.  
  853.    If input processing is allowed while output is being generated,
  854.    appropriate interlocking must be done.  The route change flags should
  855.    not be changed as a result of processing input while a triggered
  856.    update message is being generated.
  857.  
  858.    The only difference between a triggered update and other update
  859.    messages is the possible omission of routes that have not changed.
  860.    The remaining mechanisms, described in the next section, must be
  861.    applied to all updates.
  862.  
  863. 3.8.2  Generating Response Messages
  864.  
  865.    This section describes how a Response message is generated for a
  866.    particular directly-connected network:
  867.  
  868.    Set the version number to either 1 or 2.  The mechanism for deciding
  869.    which version to send is implementation specific; however, if this is
  870.    the Response to a Request, the Response version should match the
  871.    Request version.  Set the command to Response.  Set the bytes labeled
  872.    "must be zero" to zero.  Start filling in RTEs.  Recall that there is
  873.    a limit of 25 RTEs to a Response; if there are more, send the current
  874.    Response and start a new one.  There is no defined limit to the
  875.    number of datagrams which make up a Response.
  876.  
  877.    To fill in the RTEs, examine each route in the routing table.  If a
  878.    triggered update is being generated, only entries whose route change
  879.    flags are set need be included.  If, after Split Horizon processing,
  880.    the route should not be included, skip it.  If the route is to be
  881.    included, then the destination address and metric are put into the
  882.    RTE.  Routes must be included in the datagram even if their metrics
  883.    are infinite.
  884.  
  885. 3.9  Split Horizon
  886.  
  887.    Split Horizon is a algorithm for avoiding problems caused by
  888.    including routes in updates sent to the gateway from which they were
  889.    learned.  The basic split horizon algorithm omits routes learned from
  890.  
  891.  
  892.  
  893. Malkin                      Expires: 22Apr97                   [Page 16]
  894.  
  895. Internet Draft               RIP Version 2                  October 1996
  896.  
  897.  
  898.    one neighbor in updates sent to that neighbor.  In the case of a
  899.    broadcast network, all routes learned from any neighbor on that
  900.    network are omitted from updates sent on that network.
  901.  
  902.    Split Horizon with Poisoned Reverse (more simply, Poison Reverse)
  903.    does include such routes in updates, but sets their metrics to
  904.    infinity.  In effect, advertising the fact that these routes are not
  905.    reachable.  This is the preferred method of operation; however,
  906.    implementations should provide a per-interface control allowing no
  907.    horizoning, split horizoning, and poisoned reverse to be selected.
  908.  
  909.    For a theoretical discussion of Split Horizon and Poison Reverse, and
  910.    why they are needed, see section 2.1.1 of [1].
  911.  
  912.  
  913. 4. Protocol Extensions
  914.  
  915.    This section does not change the RIP protocol per se.  Rather, it
  916.    provides extensions to the message format which allows routers to
  917.    share important additional information.
  918.  
  919.    The first four octets of a RIP message contain the RIP header (as
  920.    defined in section 3.4).  The same header format is used for RIP-1
  921.    and RIP-2.  The remainder of the message is composed of 1 - 25
  922.    (inclusive) 20-octet route entries (RTEs).  The RIP-2 RTE format is:
  923.  
  924.     0                   1                   2                   3 3
  925.     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
  926.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  927.    | Address Family Identifier (2) |        Route Tag (2)          |
  928.    +-------------------------------+-------------------------------+
  929.    |                         IP Address (4)                        |
  930.    +---------------------------------------------------------------+
  931.    |                         Subnet Mask (4)                       |
  932.    +---------------------------------------------------------------+
  933.    |                         Next Hop (4)                          |
  934.    +---------------------------------------------------------------+
  935.    |                         Metric (4)                            |
  936.    +---------------------------------------------------------------+
  937.  
  938.    The Address Family Identifier, IP Address, and Metric all have the
  939.    meanings defined in section 3.4.  The Version field will specify
  940.    version number 2 for RIP messages which use authentication or carry
  941.    information in any of the newly defined fields.
  942.  
  943. 4.1 Authentication
  944.  
  945.    Since authentication is a per message function, and since there is
  946.  
  947.  
  948.  
  949. Malkin                      Expires: 22Apr97                   [Page 17]
  950.  
  951. Internet Draft               RIP Version 2                  October 1996
  952.  
  953.  
  954.    only one 2-octet field available in the message header, and since any
  955.    reasonable authentication scheme will require more than two octets,
  956.    the authentication scheme for RIP version 2 will use the space of an
  957.    entire RIP entry.  If the Address Family Identifier of the first (and
  958.    only the first) entry in the message is 0xFFFF, then the remainder of
  959.    the entry contains the authentication.  This means that there can be,
  960.    at most, 24 RIP entries in the remainder of the message.  If
  961.    authentication is not in use, then no entries in the message should
  962.    have an Address Family Identifier of 0xFFFF.  A RIP message which
  963.    contains an authentication entry would begin with the following
  964.    format:
  965.  
  966.     0                   1                   2                   3 3
  967.     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
  968.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  969.    | Command (1)   | Version (1)   |            unused             |
  970.    +---------------+---------------+-------------------------------+
  971.    |             0xFFFF            |    Authentication Type (2)    |
  972.    +-------------------------------+-------------------------------+
  973.    ~                       Authentication (16)                     ~
  974.    +---------------------------------------------------------------+
  975.  
  976.    Currently, the only Authentication Type is simple password and it
  977.    is type 2.  The remaining 16 octets contain the plain text password.  If
  978.    the password is under 16 octets, it must be left-justified and
  979.    padded to the right with nulls (0x00).
  980.  
  981. 4.2 Route Tag
  982.  
  983.    The Route Tag (RT) field is an attribute assigned to a route which
  984.    must be preserved and readvertised with a route.  The intended use
  985.    of the Route Tag is to provide a method of separating "internal"
  986.    RIP routes (routes for networks within the RIP routing domain)
  987.    from "external" RIP routes, which may have been imported from an
  988.    EGP or another IGP.
  989.  
  990.    Routers supporting protocols other than RIP should be configurable
  991.    to allow the Route Tag to be configured for routes imported from
  992.    different sources.  For example, routes imported from EGP or BGP
  993.    should be able to have their Route Tag either set to an arbitrary
  994.    value, or at least to the number of the Autonomous System from
  995.    which the routes were learned.
  996.  
  997.    Other uses of the Route Tag are valid, as long as all routers in
  998.    the RIP domain use it consistently.  This allows for the
  999.    possibility of a BGP-RIP protocol interactions document, which
  1000.    would describe methods for synchronizing routing in a transit
  1001.    network.
  1002.  
  1003.  
  1004.  
  1005. Malkin                      Expires: 22Apr97                   [Page 18]
  1006.  
  1007. Internet Draft               RIP Version 2                  October 1996
  1008.  
  1009.  
  1010. 4.3 Subnet mask
  1011.  
  1012.    The Subnet Mask field contains the subnet mask which is applied to
  1013.    the IP address to yield the non-host portion of the address.  If this
  1014.    field is zero, then no subnet mask has been included for this entry.
  1015.  
  1016.    On an interface where a RIP-1 router may hear and operate on the
  1017.    information in a RIP-2 routing entry the following rules apply:
  1018.  
  1019.    1) information internal to one network must never be advertised into
  1020.       another network,
  1021.  
  1022.    2) information about a more specific subnet may not be advertised
  1023.       where RIP-1 routers would consider it a host route, and
  1024.  
  1025.    3) supernet routes (routes with a netmask less specific than
  1026.       the "natural" network mask) must not be advertised where they
  1027.       could be misinterpreted by RIP-1 routers.
  1028.  
  1029. 4.4 Next Hop
  1030.  
  1031.    The immediate next hop IP address to which packets to the destination
  1032.    specified by this route entry should be forwarded.  Specifying a
  1033.    value of 0.0.0.0 in this field indicates that routing should be via
  1034.    the originator of the RIP advertisement.  An address specified as
  1035.    a next hop must, per force, be directly reachable on the logical
  1036.    subnet over which the advertisement is made.
  1037.  
  1038.    The purpose of the Next Hop field is to eliminate packets being routed
  1039.    through extra hops in the system.  It is particularly useful when RIP
  1040.    is not being run on all of the routers on a network.  A simple example
  1041.    is given in Appendix A.  Note that Next Hop is an "advisory" field.  That
  1042.    is, if the provided information is ignored, a possibly sub-optimal,
  1043.    but absolutely valid, route may be taken.  If the received Next Hop
  1044.    is not directly reachable, it should be treated as 0.0.0.0.
  1045.  
  1046. 4.5 Multicasting
  1047.  
  1048.    In order to reduce unnecessary load on those hosts which are not
  1049.    listening to RIP-2 messages, an IP multicast address will be used for
  1050.    periodic broadcasts.  The IP multicast address is 224.0.0.9.  Note that
  1051.    IGMP is not needed since these are inter-router messages which are not
  1052.    forwarded.
  1053.  
  1054.    In order to maintain backwards compatibility, the use of the
  1055.    multicast address will be configurable, as described in section 4.1.  If
  1056.    multicasting is used, it should be used on all interfaces which support
  1057.    it.
  1058.  
  1059.  
  1060.  
  1061. Malkin                      Expires: 22Apr97                   [Page 19]
  1062.  
  1063. Internet Draft               RIP Version 2                  October 1996
  1064.  
  1065.  
  1066. 4.5 Queries
  1067.  
  1068.    If a RIP-2 router receives a RIP-1 Request, it should respond with a
  1069.    RIP-1 Response.  If the router is configured to send only RIP-2
  1070.    messages, it should not respond to a RIP-1 Request.
  1071.  
  1072.  
  1073. 5. Compatibility
  1074.  
  1075.    RFC 1058 showed considerable forethought in its specification of
  1076.    the handling of version numbers.  It specifies that RIP messages of
  1077.    version 0 are to be discarded, that RIP messages of version 1 are
  1078.    to be discarded if any Must Be Zero (MBZ) field is non-zero, and that
  1079.    RIP messages of any version greater than 1 should not be discarded
  1080.    simply because an MBZ field contains a value other than zero.  This
  1081.    means that the new version of RIP is totally backwards compatible
  1082.    with existing RIP implementations which adhere to this part of the
  1083.    specification.
  1084.  
  1085. 5.1 Compatibility Switch
  1086.  
  1087.    A compatibility switch is necessary for two reasons.  First, there
  1088.    are implementations of RIP-1 in the field which do not follow RFC
  1089.    1058 as described above.  Second, the use of multicasting would
  1090.    prevent RIP-1 systems from receiving RIP-2 updates (which may
  1091.    be a desired feature in some cases).  This switch should be configurable
  1092.    on a per-interface basis.
  1093.  
  1094.    The switch has four settings: RIP-1, in which only RIP-1 messages are
  1095.    sent; RIP-1 compatibility, in which RIP-2 messages are broadcast;
  1096.    RIP-2, in which RIP-2 messages are multicast; and "none", which
  1097.    disables the sending of RIP messages.  It is recommended that the
  1098.    default setting be either RIP-1 or RIP-2, but not RIP-1 compatibility.
  1099.    This is because of the potential problems which can occur on some
  1100.    topologies.  RIP-1 compatibility should only be used when all of the
  1101.    consequences of its use are well understood by the network administrator.
  1102.  
  1103.    For completeness, routers should also implement a receive control
  1104.    switch which would determine whether to accept, RIP-1 only, RIP-2
  1105.    only, both, or none.  It should also be configurable on a
  1106.    per-interface basis.  It is recommended that the default be compatible
  1107.    with the default chosen for sending updates.
  1108.  
  1109. 5.2 Authentication
  1110.  
  1111.    The following algorithm should be used to authenticate a RIP message.  If
  1112.    the router is not configured to authenticate RIP-2 messages, then RIP-1
  1113.    and unauthenticated RIP-2 messages will be accepted; authenticated
  1114.  
  1115.  
  1116.  
  1117. Malkin                      Expires: 22Apr97                   [Page 20]
  1118.  
  1119. Internet Draft               RIP Version 2                  October 1996
  1120.  
  1121.  
  1122.    RIP-2 messages shall be discarded.  If the router is configured to
  1123.    authenticate RIP-2 messages, then RIP-1 messages and RIP-2 messages
  1124.    which pass authentication testing shall be accepted; unauthenticated
  1125.    and failed authentication RIP-2 messages shall be discarded.  For
  1126.    maximum security, RIP-1 messages should be ignored when authentication
  1127.    is in use (see section 4.1).
  1128.  
  1129.    Since an authentication entry is marked with an Address Family
  1130.    Identifier of 0xFFFF, a RIP-1 system would ignore this entry since
  1131.    it would belong to an address family other than IP.  It should
  1132.    be noted, therefore, that use of authentication will not prevent
  1133.    RIP-1 systems from seeing RIP-2 messages.  If desired, this may
  1134.    be done using multicasting, as described in sections 3.5 and 4.1.
  1135.  
  1136. 5.3 Larger Infinity
  1137.  
  1138.    While on the subject of compatibility, there is one item which people
  1139.    have requested: increasing infinity.  The primary reason that this
  1140.    cannot be done is that it would violate backwards compatibility.  A
  1141.    larger infinity would obviously confuse older versions of rip.  At
  1142.    best, they would ignore the route as they would ignore a metric of
  1143.    16.  There was also a proposal to make the Metric a single octet and reuse
  1144.    the high three octets, but this would break any implementations which
  1145.    treat the metric as a 4-octet entity.
  1146.  
  1147. 5.4 Addressless Links
  1148.  
  1149.    As in RIP-1, addressless links will not be supported by RIP-2.
  1150.  
  1151.  
  1152. 6. Security Considerations
  1153.  
  1154.    The basic RIP protocol is not a secure protocol.  To bring RIP-2
  1155.    in line with more modern routing protocols, an extensible authentication
  1156.    mechanism has been incorporated into the protocol enhancements.  This
  1157.    mechanism is described in sections 4.1 and 5.2.  Security is further
  1158.    enhanced by the mechanism described in [10].
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173. Malkin                      Expires: 22Apr97                   [Page 21]
  1174.  
  1175. Internet Draft               RIP Version 2                  October 1996
  1176.  
  1177.  
  1178. Appendix A
  1179.  
  1180.    This is a simple example of the use of the next hop field in a rip entry.
  1181.  
  1182.       -----   -----   -----           -----   -----   -----
  1183.       |IR1|   |IR2|   |IR3|           |XR1|   |XR2|   |XR3|
  1184.       --+--   --+--   --+--           --+--   --+--   --+--
  1185.         |       |       |               |       |       |
  1186.       --+-------+-------+---------------+-------+-------+--
  1187.         <-------------RIP-2------------->
  1188.  
  1189.    Assume that IR1, IR2, and IR3 are all "internal" routers which are
  1190.    under one administration (e.g. a campus) which has elected to use
  1191.    RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under
  1192.    separate administration (e.g. a regional network, of which the campus
  1193.    is a member) and are using some other routing protocol (e.g. OSPF).
  1194.    XR1, XR2, and XR3 exchange routing information among themselves such
  1195.    that they know that the best routes to networks N1 and N2 are via
  1196.    XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By
  1197.    setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for
  1198.    N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for
  1199.    routing to occur without additional hops through XR1. Without the
  1200.    Next Hop (for example, if RIP-1 were used) it would be necessary for
  1201.    XR2 and XR3 to also participate in the RIP-2 protocol to eliminate
  1202.    extra hops.
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229. Malkin                      Expires: 22Apr97                   [Page 22]
  1230.  
  1231. Internet Draft               RIP Version 2                  October 1996
  1232.  
  1233.  
  1234. References
  1235.  
  1236.    [1] Hedrick, C., Routing Information Protocol, Request For Comments
  1237.        (RFC) 1058, Rutgers University, June 1988.
  1238.  
  1239.    [2] Malkin, G., RIP Version 2 - Carrying Additional Information,
  1240.        Request for Comments (RFC) 1723, Xylogics, Inc., July 1994.
  1241.  
  1242.    [3] Malkin, G., and F. Baker, RIP Version 2 MIB Extension, Request
  1243.        For Comments (RFC) 1389, Xylogics, Inc., Advanced Computer
  1244.        Communications, January 1993.
  1245.  
  1246.    [4] Bellman, R. E., "Dynamic Programming", Princeton University
  1247.        Press, Princeton, N.J., 1957.
  1248.  
  1249.    [5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks",
  1250.        Prentice-Hall, Englewood Cliffs, N.J., 1987.
  1251.  
  1252.    [6] Braden, R., and Postel, J., "Requirements for Internet Gateways",
  1253.        USC/Information Sciences Institute, RFC-1009, June 1987.
  1254.  
  1255.    [7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M.,
  1256.        "Pup: An Internetwork Architecture", IEEE Transactions on
  1257.        Communications, April 1980.
  1258.  
  1259.    [8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
  1260.        Princeton University Press, Princeton, N.J., 1962.
  1261.  
  1262.    [9] Xerox Corp., "Internet Transport Protocols", Xerox System
  1263.        Integration Standard XSIS 028112, December 1981.
  1264.  
  1265.    [10] Baker, F., Atkinson, R., "RIP-II MD5 Authentication", draft-
  1266.        ietf-ripv2-md5-04.txt, September 1996.
  1267.  
  1268. Author's Address
  1269.  
  1270.    Gary Scott Malkin
  1271.    Bay Networks
  1272.    53 Third Avenue
  1273.    Burlington, MA 01803
  1274.  
  1275.    Phone:  (617) 272-8140
  1276.    EMail:  gmalkin@baynetworks.com
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285. Malkin                      Expires: 22Apr97                   [Page 23]
  1286.