home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1388.txt < prev    next >
Text File  |  1994-05-29  |  17KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          G. Malkin
  8. Request for Comments: 1388                                Xylogics, Inc.
  9. Updates: RFC 1058                                           January 1993
  10.  
  11.  
  12.                              RIP Version 2
  13.                     Carrying Additional Information
  14.  
  15. Status of this Memo
  16.  
  17.    This RFC specifies an IAB standards track protocol for the Internet
  18.    community, and requests discussion and suggestions for improvements.
  19.    Please refer to the current edition of the "IAB Official Protocol
  20.    Standards" for the standardization state and status of this protocol.
  21.    Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    This document specifies an extension of the Routing Information
  26.    Protocol (RIP), as defined in [1], to expand the amount of useful
  27.    information carried in RIP packets and to add a measure of security.
  28.    A companion document will define the SNMP MIB objects for RIP-2 [2].
  29.  
  30. Acknowledgements
  31.  
  32.    I would like to thank the following for their contributions to this
  33.    document: Fred Baker, Noel Chiappa and Vince Fuller.  This memo is a
  34.    product of the RIP-2 Working Group of the Internet Engineering Task
  35.    Force (IETF).
  36.  
  37. Table of Contents
  38.  
  39.    1.  Justification . . . . . . . . . . . . . . . . . . . . . . . . . 2
  40.    2.  Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 2
  41.    3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 2
  42.    3.1   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 3
  43.    3.2   Routing Domain  . . . . . . . . . . . . . . . . . . . . . . . 4
  44.    3.3   Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 4
  45.    3.4   Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 4
  46.    3.5   Next Hop  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
  47.    3.6   Multicasting  . . . . . . . . . . . . . . . . . . . . . . . . 5
  48.    4.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 5
  49.    4.1   Compatibility Switch  . . . . . . . . . . . . . . . . . . . . 5
  50.    4.2   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 6
  51.    4.3   Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 6
  52.    4.4   Addressless Links . . . . . . . . . . . . . . . . . . . . . . 6
  53.    Appendix A  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  54.    References  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  55.  
  56.  
  57.  
  58. Malkin                                                          [Page 1]
  59.  
  60. RFC 1388                     RIP Version 2                  January 1993
  61.  
  62.  
  63.    Security Considerations . . . . . . . . . . . . . . . . . . . . . . 7
  64.    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
  65.  
  66. 1. Justification
  67.  
  68.    With the advent of OSPF and IS-IS, there are those who believe that
  69.    RIP is obsolete.  While it is true that the newer IGP routing
  70.    protocols are far superior to RIP, RIP does have some advantages.
  71.    Primarily, in a small network, RIP has very little overhead in terms
  72.    of bandwidth used and configuration and management time.  RIP is also
  73.    very easy to implement, especially in relation to the newer IGPs.
  74.  
  75.    Additionally, there are many, many more RIP implementations in the
  76.    field than OSPF and IS-IS combined.  It is likely to remain that way
  77.    for some years yet.
  78.  
  79.    Given that RIP will be useful in many environments for some period of
  80.    time, it is reasonable to increase RIP's usefulness.  This is
  81.    especially true since the gain is far greater than the expense of the
  82.    change.
  83.  
  84. 2. Current RIP
  85.  
  86.    The current RIP packet contains the minimal amount of information
  87.    necessary for routers to route packets through a network.  It also
  88.    contains a large amount of unused space, owing to its origins.
  89.  
  90.    The current RIP protocol does not consider autonomous systems and
  91.    IGP/EGP interactions, subnetting, and authentication since
  92.    implementations of these postdate RIP.  The lack of subnet masks is a
  93.    particularly serious problem for routers since they need a subnet
  94.    mask to know how to determine a route.  If a RIP route is a network
  95.    route (all non-network bits 0), the subnet mask equals the network
  96.    mask.  However, if some of the non-network bits are set, the router
  97.    cannot determine the subnet mask.  Worse still, the router cannot
  98.    determine if the RIP route is a subnet route or a host route.
  99.    Currently, some routers simply choose the subnet mask of the
  100.    interface over which the route was learned and determine the route
  101.    type from that.
  102.  
  103. 3. Protocol Extensions
  104.  
  105.    This document does not change the RIP protocol per se.  Rather, it
  106.    provides extensions to the datagram format which allows routers to
  107.    share important additional information.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Malkin                                                          [Page 2]
  115.  
  116. RFC 1388                     RIP Version 2                  January 1993
  117.  
  118.  
  119.    The new RIP datagram format is:
  120.  
  121.     0                   1                   2                   3 3
  122.     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
  123.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  124.    | Command (1)   | Version (1)   |       Routing Domain (2)      |
  125.    +---------------+---------------+-------------------------------+
  126.    | Address Family Identifier (2) |       Route Tag (2)           |
  127.    +-------------------------------+-------------------------------+
  128.    |                         IP Address (4)                        |
  129.    +---------------------------------------------------------------+
  130.    |                         Subnet Mask (4)                       |
  131.    +---------------------------------------------------------------+
  132.    |                         Next Hop (4)                          |
  133.    +---------------------------------------------------------------+
  134.    |                         Metric (4)                            |
  135.    +---------------------------------------------------------------+
  136.  
  137.    The Command, Address Family Identifier (AFI), IP Address, and Metric
  138.    all have the meanings defined in RFC 1058.  The Version field will
  139.    specify version number 2 for RIP datagrams which use authentication
  140.    or carry information in any of the newly defined fields.
  141.  
  142.    All fields are coded in IP network byte order (big-endian).
  143.  
  144. 3.1 Authentication
  145.  
  146.    Since authentication is a per packet function, and since there is
  147.    only one 2-byte field available in the packet header, and since any
  148.    reasonable authentication scheme will require more than two bytes,
  149.    the authentication scheme for RIP version 2 will use the space of an
  150.    entire RIP entry.  If the Address Family Identifier of the first (and
  151.    only the first) entry in the packet is 0xFFFF, then the remainder of
  152.    the entry contains the authentication.  This means that there can be,
  153.    at most, 24 RIP entries in the remainder of the packet.  If
  154.    authentication is not in use, then no entries in the packet should
  155.    have an Address Family Identifier of 0xFFFF.  A RIP packet which
  156.    contains an authentication entry would have the following format:
  157.  
  158.     0                   1                   2                   3 3
  159.     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
  160.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  161.    | Command (1)   | Version (1)   |       Routing Domain (2)      |
  162.    +---------------+---------------+-------------------------------+
  163.    |             0xFFFF            |    Authentication Type (2)    |
  164.    +-------------------------------+-------------------------------+
  165.    ~                       Authentication (16)                     ~
  166.    +---------------------------------------------------------------+
  167.  
  168.  
  169.  
  170. Malkin                                                          [Page 3]
  171.  
  172. RFC 1388                     RIP Version 2                  January 1993
  173.  
  174.  
  175.    Currently, the only Authentication Type is simple password and it is
  176.    type 2.  The remaining 16 bytes contain the plain text password.  If
  177.    the password is under 16 bytes, it must be left-justified and padded
  178.    to the right with nulls (0x00).
  179.  
  180. 3.2 Routing Domain
  181.  
  182.    The Routing Domain (RD) number is the number of the routing process
  183.    to which this update belongs.  This field is used to associate the
  184.    routing update to a specific routing process on the receiving router.
  185.    The RD is needed to allow multiple, independent RIP "clouds" to co-
  186.    exist on the same physical wire.  This gives administrators the
  187.    ability to run multiple, possibly parallel, instances of RIP in order
  188.    to implement simple policy.  This means that a router operating
  189.    within one routing domain, or a set of routing domains, should ignore
  190.    RIP packets which belong to another routing domain.  RD 0 is the
  191.    default routing domain.
  192.  
  193. 3.3 Route Tag
  194.  
  195.    The Route Tag (RT) field exists as a support for EGPs.  The contents
  196.    and use of this field are outside the scope of this protocol.
  197.    However, it is expected that the field will be used to carry
  198.    Autonomous System numbers for EGP and BGP.  Any RIP system which
  199.    receives a RIP entry which contains a non-zero RT value must re-
  200.    advertise that value.  Those routes which have no RT value must
  201.    advertise an RT value of zero.
  202.  
  203. 3.4 Subnet mask
  204.  
  205.    The Subnet Mask field contains the subnet mask which is applied to
  206.    the IP address to yield the non-host portion of the address.  If this
  207.    field is zero, then no subnet mask has been included for this entry.
  208.  
  209.    On an interface where a RIP-1 router may hear and operate on the
  210.    information in a RIP-2 routing entry the following two rules apply:
  211.  
  212.    1) information internal to one network must never be advertised into
  213.       another network, and
  214.  
  215.    2) information about a more specific subnet may not be advertised
  216.       where RIP-1 routers would consider it a host route.
  217.  
  218. 3.5 Next Hop
  219.  
  220.    The immediate next hop IP address to which packets to the destination
  221.    specified by this route entry should be forwarded.  Specifying a
  222.    value of 0.0.0.0 in this field indicates that routing should be via
  223.  
  224.  
  225.  
  226. Malkin                                                          [Page 4]
  227.  
  228. RFC 1388                     RIP Version 2                  January 1993
  229.  
  230.  
  231.    the originator of the RIP advertisement.  An address specified as a
  232.    next hop must, per force, be directly reachable on the logical subnet
  233.    over which the advertisement is made.
  234.  
  235.    The purpose of the Next Hop field is to eliminate packets being
  236.    routed through extra hops in the system.  It is particularly useful
  237.    when RIP is not being run on all of the routers on a network.  A
  238.    simple example is given in Appendix A.  Note that Next Hop is an
  239.    "advisory" field.  That is, if the provided information is ignored, a
  240.    possibly sub-optimal, but absolutely valid, route may be taken.
  241.  
  242. 3.6 Multicasting
  243.  
  244.    In order to reduce unnecessary load on those hosts which are not
  245.    listening to RIP-2 packets, an IP multicast address will be used for
  246.    periodic broadcasts.  The IP multicast address is 224.0.0.9.  Note
  247.    that IGMP is not needed since these are inter-router messages which
  248.    are not forwarded.
  249.  
  250.    In order to maintain backwards compatibility, the use of the
  251.    multicast address will be configurable, as described in section 4.1.
  252.    If multicasting is used, it should be used on all interfaces which
  253.    support it.
  254.  
  255. 4. Compatibility
  256.  
  257.    RFC 1058 showed considerable forethought in its specification of the
  258.    handling of version numbers.  It specifies that RIP packets of
  259.    version 0 are to be discarded, that RIP packets of version 1 are to
  260.    be discarded if any Must Be Zero (MBZ) field is non-zero, and that
  261.    RIP packets of any version greater than 1 should not be discarded
  262.    simply because an MBZ field contains a value other than zero.  This
  263.    means that the new version of RIP is totally backwards compatible
  264.    with existing RIP implementations which adhere to this part of the
  265.    specification.
  266.  
  267. 4.1 Compatibility Switch
  268.  
  269.    A compatibility switch is necessary for two reasons.  First, there
  270.    are implementations of RIP-1 in the field which do not follow RFC
  271.    1058 as described above.  Second, the use of multicasting would
  272.    prevent RIP-1 systems from receiving RIP-2 updates (which may be a
  273.    desired feature in some cases).
  274.  
  275.    The switch has three settings: RIP-1, in which only RIP-1 packets are
  276.    sent; RIP-1 compatibility, in which RIP-2 packets are broadcast; and
  277.    RIP-2, in which RIP-2 packets are multicast.  The recommended default
  278.    for this switch is RIP-1 compatibility.
  279.  
  280.  
  281.  
  282. Malkin                                                          [Page 5]
  283.  
  284. RFC 1388                     RIP Version 2                  January 1993
  285.  
  286.  
  287. 4.2 Authentication
  288.  
  289.    Since an authentication entry is marked with an Address Family
  290.    Identifier of 0xFFFF, a RIP-1 system would ignore this entry since it
  291.    would belong to an address family other than IP.  It should be noted,
  292.    therefore, that use of authentication will not prevent RIP-1 systems
  293.    from seeing RIP-2 packets.  If desired, this may be done using
  294.    multicasting, as described in sections 3.6 and 4.1.
  295.  
  296. 4.3 Larger Infinity
  297.  
  298.    While on the subject of compatibility, there is one item which people
  299.    have requested: increasing infinity.  The primary reason that this
  300.    cannot be done is that it would violate backwards compatibility.  A
  301.    larger infinity would obviously confuse older versions of rip.  At
  302.    best, they would ignore the route as they would ignore a metric of
  303.    16.  There was also a proposal to make the Metric a single byte and
  304.    reuse the high three bytes, but this would break any implementations
  305.    which treat the metric as a long.
  306.  
  307. 4.4 Addressless Links
  308.  
  309.    As in RIP-1, addressless links will not be supported by RIP-2.
  310.  
  311. Appendix A
  312.  
  313.    This is a simple example of the use of the next hop field in a rip
  314.    entry.
  315.  
  316.       -----   -----   -----           -----   -----   -----
  317.       |IR1|   |IR2|   |IR3|           |XR1|   |XR2|   |XR3|
  318.       --+--   --+--   --+--           --+--   --+--   --+--
  319.         |       |       |               |       |       |
  320.       --+-------+-------+---------------+-------+-------+--
  321.         <-------------RIP-2------------->
  322.  
  323.    Assume that IR1, IR2, and IR3 are all "internal" routers which are
  324.    under one administration (e.g., a campus) which has elected to use
  325.    RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under
  326.    separate administration (e.g., a regional network, of which the
  327.    campus is a member) and are using some other routing protocol (e.g.,
  328.    OSPF).  XR1, XR2, and XR3 exchange routing information among
  329.    themselves such that they know that the best routes to networks N1
  330.    and N2 are via XR1, to N3, N4, and N5 are via XR2, and to N6 and N7
  331.    are via XR3. By setting the Next Hop field correctly (to XR2 for
  332.    N3/N4/N5, to XR3 for N6/N7), only XR1 need exchange RIP-2 routes with
  333.    IR1/IR2/IR3 for routing to occur without additional hops through XR1.
  334.    Without the Next Hop (for example, if RIP-1 were used) it would be
  335.  
  336.  
  337.  
  338. Malkin                                                          [Page 6]
  339.  
  340. RFC 1388                     RIP Version 2                  January 1993
  341.  
  342.  
  343.    necessary for XR2 and XR3 to also participate in the RIP-2 protocol
  344.    to eliminate extra hops.
  345.  
  346. References
  347.  
  348.    [1] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
  349.        University, June 1988.
  350.  
  351.    [2] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC
  352.        1389, Xylogics, Inc., Advanced Computer Communications, January
  353.        1993.
  354.  
  355.    [3] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1387,
  356.        Xylogics, Inc., January 1993.
  357.  
  358. Security Considerations
  359.  
  360.    The basic RIP protocol is not a secure protocol.  To bring RIP-2 in
  361.    line with more modern routing protocols, an extensible authentication
  362.    mechanism has been incorporated into the protocol enhancements.  This
  363.    mechanism is described in sections 3.1 and 4.2.
  364.  
  365. Author's Address
  366.  
  367.    Gary Scott Malkin
  368.    Xylogics, Inc.
  369.    53 Third Avenue
  370.    Burlington, MA 01803
  371.  
  372.    Phone:  (617) 272-8140
  373.    EMail:  gmalkin@Xylogics.COM
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Malkin                                                          [Page 7]
  395.  
  396.