The immediate next hop IP address to which packets to the destination   specified by this route entry should be forwarded.  Specifying a   value of 0.0.0.0 in this field indicates that routing should be via   the originator of the RIP advertisement.  An address specified as a   next hop must, per force, be directly reachable on the logical subnet   over which the advertisement is made.   The purpose of the Next Hop field is to eliminate packets being   routed through extra hops in the system.  It is particularly useful   when RIP is not being run on all of the routers on a network.  A   simple example is given in Appendix A.  Note that Next Hop is an   "advisory" field.  That is, if the provided information is ignored, a   possibly sub-optimal, but absolutely valid, route may be taken.  If   the received Next Hop is not directly reachable, it should be treated   as 0.0.0.0.3.5 Multicasting   In order to reduce unnecessary load on those hosts which are not   listening to RIP-2 messages, 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.Malkin                                                          [Page 5]RFC 1723                     RIP Version 2                 November 1994   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.3.6 Queries   If a RIP-2 router receives a RIP-1 Request, it should respond with a   RIP-1 Response.  If the router is configured to send only RIP-2   messages, it should not respond to a RIP-1 Request.4. Compatibility   RFC 1058 showed considerable forethought in its specification of the   handling of version numbers.  It specifies that RIP messages of   version 0 are to be discarded, that RIP messages of version 1 are to   be discarded if any Must Be Zero (MBZ) field is non-zero, and that   RIP messages 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).  This switch should be configurable   on a per-interface basis.   The switch has four settings: RIP-1, in which only RIP-1 messages are   sent; RIP-1 compatibility, in which RIP-2 messages are broadcast;   RIP-2, in which RIP-2 messages are multicast; and "none", which   disables the sending of RIP messages.  The recommended default for   this switch is RIP-1 compatibility.   For completeness, routers should also implement a receive control   switch which would determine whether to accept, RIP-1 only, RIP-2   only, both, or none.  It should also be configurable on a per-   interface basis.4.2 Authentication   The following algorithm should be used to authenticate a RIP message.   If the router is not configured to authenticate RIP-2 messages, then   RIP-1 and unauthenticated RIP-2 messages will be accepted;Malkin                                                          [Page 6]RFC 1723                     RIP Version 2                 November 1994   authenticated RIP-2 messages shall be discarded.  If the router is   configured to authenticate RIP-2 messages, then RIP-1 messages and   RIP-2 messages which pass authentication testing shall be accepted;   unauthenticated and failed authentication RIP-2 messages shall be   discarded.  For maximum security, RIP-1 messages should be ignored   when authentication is in use (see section 4.1).   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 messages.  If desired, this may be done using   multicasting, as described in sections 3.5 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 octet and   reuse the high three octets, but this would break any implementations   which treat the metric as a 4-octet entity.4.4 Addressless Links   As in RIP-1, addressless links will not be supported by RIP-2.5. Security Considerations   The basic RIP protocol is not a secure protocol.  To bring RIP-2 in   line with more modern routing protocols, an extensible authentication   mechanism has been incorporated into the protocol enhancements.  This   mechanism is described in sections 3.1 and 4.2.Malkin                                                          [Page 7]RFC 1723                     RIP Version 2                 November 1994Appendix A   This is a simple example of the use of the next hop field in a rip   entry.      -----   -----   -----           -----   -----   -----      |IR1|   |IR2|   |IR3|           |XR1|   |XR2|   |XR3|      --+--   --+--   --+--           --+--   --+--   --+--        |       |       |               |       |       |      --+-------+-------+---------------+-------+-------+--        <-------------RIP-2------------->   Assume that IR1, IR2, and IR3 are all "internal" routers which are   under one administration (e.g. a campus) which has elected to use   RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under   separate administration (e.g. a regional network, of which the campus   is a member) and are using some other routing protocol (e.g. OSPF).   XR1, XR2, and XR3 exchange routing information among themselves such   that they know that the best routes to networks N1 and N2 are via   XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By   setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for   N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for   routing to occur without additional hops through XR1. Without the   Next Hop (for example, if RIP-1 were used) it would be necessary for   XR2 and XR3 to also participate in the RIP-2 protocol to eliminate   extra hops.References   [1] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058,       Rutgers University, June 1988.   [2] Malkin, G., "RIP Version 2 - Carrying Additional Information",       RFC 1388, Xylogics, Inc., January 1993.   [3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC       1724, Xylogics, Inc., Cisco Systems, November 1994.   [4] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721,       Xylogics, Inc., November 1994.   [5] Malkin, G., "RIP Version 2 Protocol Applicability Statement", RFC       1722, Xylogics, Inc., November 1994.Malkin                                                          [Page 8]RFC 1723                     RIP Version 2                 November 1994Author's Address   Gary Scott Malkin   Xylogics, Inc.   53 Third Avenue   Burlington, MA 01803   Phone:  (617) 272-8140   EMail:  gmalkin@Xylogics.COMMalkin                                                          [Page 9]