RIP Version 2 Protocol Applicability Statement
RFC 1722

Document Type RFC - Internet Standard (November 1994; No errata)
Also known as STD 57
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1722 (Internet Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          G. Malkin
Request for Comments: 1722                                Xylogics, Inc.
Category: Standards Track                                  November 1994

             RIP Version 2 Protocol Applicability Statement

Status of this Memo

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

Abstract

   As required by Routing Protocol Criteria (RFC 1264), this report
   defines the applicability of the RIP-2 protocol within the Internet.
   This report is a prerequisite to advancing RIP-2 on the standards
   track.

1.  Protocol Documents

   The RIP-2 protocol analysis is documented in RFC 1721 [1].

   The RIP-2 protocol description is defined in RFC 1723 [2].  This memo
   obsoletes RFC 1388, which specifies an update to the "Routing
   Information Protocol" RFC 1058 (STD 34).

   The RIP-2 MIB description is defined in RFC 1724 [3].  This memo will
   obsolete RFC 1389.

2.  Introduction

   This report describes how RIP-2 may be useful within the Internet.
   In essence, the environments in which RIP-2 is the IGP of choice is a
   superset of the environments in which RIP-1, as defined in RFC 1058
   [1], has traditionally been used.  It is important to remember that
   RIP-2 is an extension to RIP-1; RIP-2 is not a new protocol.  Thus,
   the operational aspects of distance-vector routing protocols, and
   RIP-1 in particular, within an autonomous system are well understood.

   It should be noted that RIP-2 is not intended to be a substitute for
   OSPF in large autonomous systems; the restrictions on AS diameter and
   complexity which applied to RIP-1 also apply to RIP-2.  Rather, RIP-2
   allows the smaller, simpler, distance-vector protocol to be used in
   environments which require authentication or the use of variable

Malkin                                                          [Page 1]
RFC 1722                  RIP-2 Applicability              November 1994

   length subnet masks, but are not of a size or complexity which
   require the use of the larger, more complex, link-state protocol.

   The remainder of this report describes how each of the extensions to
   RIP-1 may be used to increase the overall usefullness of RIP-2.

3.  Extension Applicability

3.1 Subnet Masks

   The original impetus behind the creation of RIP-2 was the desire to
   include subnet masks in the routing information exchanged by RIP.
   This was needed because subnetting was not defined when RIP was first
   created.  As long as the subnet mask was fixed for a network, and
   well known by all the nodes on that network, a heuristic could be
   used to determine if a route was a subnet route or a host route.
   With the advent of variable length subnetting, CIDR, and
   supernetting, it was no longer possible for a heuristic to reasonably
   distinguish between network, subnet, and host routes.

   By using the 32-bit field immediately following the IP address in a
   RIP routing entry, it became possible to positively identify a
   route's type.  In fact, one could go so far as to say that the
   inclusion of the subnet mask effictively creates a 64-bit address
   which eliminates the network, subnet, host distinction.

   Therefore, the inclusion of subnet masks in RIP-2 allows it to be
   used in an AS which requires precise knowledge of the subnet mask for
   a given route, but does not otherwise require OSPF.

3.2. Next Hop

   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.
   Consider the following example topology:

      -----   -----         -----   -----
      |IR1|   |IR2|         |XR1|   |XR2|
      --+--   --+--         --+--   --+--
        |       |             |       |
      --+-------+-------------+-------+--
        |--------RIP-2--------|

   The Internal Routers (IR1 and IR2) are only running RIP-2.  The
   External Routers (XR1 and XR2) are both running BGP, for example;
   however, only XR1 is running BGP and RIP-2.  Since XR2 is not running
   RIP-2, the IRs will not know of its existance and will never use it

Malkin                                                          [Page 2]
RFC 1722                  RIP-2 Applicability              November 1994

   as a next hop, even if it is a better next hop than XR1.  Of course,
   XR1 knows this and can indicate, via the Next Hop field, that XR2 is
   the better next hop for some routes.

   Another use for Next Hop has also been found.  Consider the following
   example topology:

           -----
           |COR|
           -----
Show full document text