rfc1388.txt

RFC 的详细文档！

Network Working Group                                          G. Malkin
Request for Comments: 1388                                Xylogics, Inc.
Updates: RFC 1058                                           January 1993


                             RIP Version 2
                    Carrying Additional Information

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   This document specifies an extension of the Routing Information
   Protocol (RIP), as defined in [1], 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].

Acknowledgements

   I would like to thank the following for their contributions to this
   document: Fred Baker, Noel Chiappa and Vince Fuller.  This memo is a
   product of the RIP-2 Working Group of the Internet Engineering Task
   Force (IETF).

Table of Contents

   1.  Justification . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 2
   3.1   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 3
   3.2   Routing Domain  . . . . . . . . . . . . . . . . . . . . . . . 4
   3.3   Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.4   Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.5   Next Hop  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.6   Multicasting  . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.1   Compatibility Switch  . . . . . . . . . . . . . . . . . . . . 5
   4.2   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 6
   4.3   Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 6
   4.4   Addressless Links . . . . . . . . . . . . . . . . . . . . . . 6
   Appendix A  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7



Malkin                                                          [Page 1]

RFC 1388                     RIP Version 2                  January 1993


   Security Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7

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.






Malkin                                                          [Page 2]

RFC 1388                     RIP Version 2                  January 1993


   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)                     ~
   +---------------------------------------------------------------+



Malkin                                                          [Page 3]

RFC 1388                     RIP Version 2                  January 1993


   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