rfc1388.txt

RFC 的详细文档！

   receives a RIP entry which contains a non-zero RT value must re-
   advertise that value.  Those routes which have no RT value must
   advertise an RT value of zero.

3.4 Subnet mask

   The Subnet Mask field contains the subnet mask which is applied to
   the IP address to yield the non-host portion of the address.  If this
   field is zero, then no subnet mask has been included for this entry.

   On an interface where a RIP-1 router may hear and operate on the
   information in a RIP-2 routing entry the following two rules apply:

   1) information internal to one network must never be advertised into
      another network, and

   2) information about a more specific subnet may not be advertised
      where RIP-1 routers would consider it a host route.

3.5 Next Hop

   The immediate next hop IP address to which packets to the destination
   specified by this route entry should be forwarded.  Specifying a
   value of 0.0.0.0 in this field indicates that routing should be via



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


   the originator of the RIP advertisement.  An address specified as a
   next hop must, per force, be directly reachable on the logical subnet
   over which the advertisement is made.

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

3.6 Multicasting

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

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

4. Compatibility

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

4.1 Compatibility Switch

   A compatibility switch is necessary for two reasons.  First, there
   are implementations of RIP-1 in the field which do not follow RFC
   1058 as described above.  Second, the use of multicasting would
   prevent RIP-1 systems from receiving RIP-2 updates (which may be a
   desired feature in some cases).

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



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


4.2 Authentication

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

4.3 Larger Infinity

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

4.4 Addressless Links

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

Appendix A

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

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

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



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


   necessary for XR2 and XR3 to also participate in the RIP-2 protocol
   to eliminate extra hops.

References

   [1] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
       University, June 1988.

   [2] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC
       1389, Xylogics, Inc., Advanced Computer Communications, January
       1993.

   [3] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1387,
       Xylogics, Inc., January 1993.

Security Considerations

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

Author's Address

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

   Phone:  [phone]
   EMail:  [e-mail]




















Malkin                                                          [Page 7]