RFC 1923 INFORMATIONAL ROUTING · PROTOCOLS

RIPv1 Historic: RIPv1 Applicability Statement for Historic Status

Why RIPv1 was declared historic for use on the global Internet.

On rfc-editor.org ↗
PUBLISHED
March 1996
AUTHORS
J. Halpern, S. Bradner
STREAM
IETF
RIPV1 INFINITY
16 hops
SUBNET MASKS IN RIPV1 PACKETS
Not carried
DOI
10.17487/RFC1923

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                         J. Halpern
Request for Comments: 1923                            Newbridge Networks
Category: Informational                                       S. Bradner
                                                      Harvard University
                                                              March 1996


           RIPv1 Applicability Statement for Historic Status

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   RIP Version 1 [RFC-1058] has been declared an historic document.
   This Applicability statement provides the supporting motivation for
   that declaration.  The primary reason, as described below, is the
   Classful nature of RIPv1.

1.0 Introduction

   RIP version 1 (RIPv1) (as defined by RFC 1058) was one of the first
   dynamic routing protocols used in the internet.  It was developed as
   a technique for passing around network reachability information for
   what we now consider relatively simple topologies.

   The Internet has changed significantly since RIPv1 was defined,
   particularly with the introduction and use of subnets and CIDR.

   While RIPv1 is widely used in private networks, it can no longer be
   considered applicable for use in the global Internet.

2.0 RIPv1 restrictions

   RIPv1 has a number of restrictions and behaviors which restrict its
   useability in the global Internet.

2.1 Classfulness

   Chief among these is that it is a classful routing protocol.  RIP
   packets do not carry prefix masks.  The prefix length is inferred
   from the address.  For non-local addresses, the prefix is always the
   "natural" (classful) length. (e.g., 24 bits for a "Class C" network
   address.)  For networks to which a local interface exists, if the
   interface is subnetted with some specific mask, then RIPv1 assumes
   that the mask used locally is the correct mask to apply for all
   subnets of that network.

   This has a number of effects.

   1) RIPv1 can not be used with variable length subnetting.  In the
      presence of variable length subnetting it will consistently
      misinterpret prefix lengths.

   2) RIPv1 is difficult to use with supernetting.  All CIDR supernets
      must be exploded and advertised to RIPv1 as individual "natural"
      classful advertisements.

   3) Even when the networks running RIPv1 are themselves only subnetted
      in fixed ways, if the remainder of the network has variable
      subnetting then one must carefully make sure that RIPv1 does not
      destroy the mask information when it passes through those subnets
      running RIPv1.  Put another way, co-existence with mutual
      information exchange between RIPv1 and more advanced routing
      protocols is problematic at best.  Note that this applies even when
      the other routing protocol is RIPv2.

   4) The Internet will soon be making use of addresses which appear to
      RIPv1 to be parts of Class A networks. Networks using RIPv1 may not
      be able to reach all sites assigned the subsections of a single A.

2.2 Simple Distance Vector

   RIPv1 is a simple distance vector protocol.  It has been enhanced
   with various techniques, including Split Horizon and Poison Reverse
   in order to enable it to perform better in somewhat complicated
   networks.

   However, being a simple distance vector protocol, it will run into
   difficulty. First and foremost, it will occasionally have to count to
   infinity in order to purge bad routes.  This delays the convergence
   of routing.  In order to keep this short, RIPv1 defines infinity as
   16 hops.  That means that networks with diameters larger than that
   can not use RIP.  Even getting close to that limit can cause
   confusion for some implementations.

3.0 Conclusion

   The recommendation of this Applicability statement is that if there
   is reason to run RIP in a network environment, one should use RIPv2
   (RFC 1723).

   RIPv1 itself should only be used in simple topologies, with simple
   reachability. It may be used by any site which uses fixed subnetting
   internally, and either uses a default route to deal with external
   traffic or is not connected to the global Internet or to other
   organizations.

   RIPv1 may also be used as a local advertising technology if the
   information to be used fits within its capabilities.

4.0 Security Considerations

   RIPv1 includes no security functions.  RIPv2 includes a mechanism for
   authenticating the sender of the routing information.  Sites which
   are worried about the vulnerability of their routing infrastructure
   and which feel they must run a RIP-like protocol should use RIPv2.

5.0 Authors' Addresses

   Joel M. Halpern
   Newbridge Networks Inc.
   593 Herndon Parkway Herndon,
   VA 22070-5241

   Phone: +1 703 708 5954
   EMail: jhalpern@newbridge.com


   Scott Bradner
   Harvard University
   1350 Mass Ave, Rm 813
   Cambridge MA 02138

   Phone: +1 617 495 3864
   EMail: sob@harvard.edu

ISO Plain Language

On this page
PROBLEMRIPv1's classful routing behavior could not handle subnet masks, variable-length subnetting, or supernetting reliably on the changing Internet.
MECHANISMThe memo explains that RIPv1 packets carry no prefix masks and that its distance-vector behavior is limited by a maximum of 16 hops.
WHY RIPV1 BECAME HISTORICThe applicability statement recommends RIPv2 when RIP is needed and limits RIPv1 to simple topologies where its capabilities suffice.

§1.0RIPv1's Changing Applicability

RIPv1 was an early dynamic routing protocol for sharing network reachability in relatively simple topologies. The RFC says the Internet changed with the introduction and use of subnets and CIDR, and RIPv1 could no longer be considered applicable for the global Internet.

RIPv1 was designed for simpler networks. Later use of subnets and CIDR exposed limits that made it unsuitable for global Internet routing.

§2.1Classful Addresses and Missing Masks

RIPv1 packets do not carry prefix masks. For non-local addresses, the prefix length is inferred from the address's natural classful length; for networks with a local interface, RIPv1 assumes the local mask applies to all subnets of that network.

As a result, the memo says RIPv1 cannot be used with variable-length subnetting and is difficult to use with supernetting. Exchanging routes with more advanced protocols can also be problematic because mask information may be lost.

RIPv1 does not send the mask that says how much of an address is the network prefix. It guesses from the address class, which causes problems when subnet sizes differ.

§2.2Distance-Vector Hop Limit

RIPv1 is a simple distance-vector protocol. It uses techniques such as Split Horizon and Poison Reverse, but can still need to count to infinity to remove bad routes, delaying convergence. The memo defines infinity as 16 hops, so networks with a diameter larger than that cannot use RIP.

RIPv1 can take time to remove a bad route. It also treats 16 hops as infinity, so it cannot serve networks larger than that limit.

§3.0Recommendation and Historic Status

The applicability statement says RIPv1 has been declared Historic. It recommends RIPv2 for networks that have reason to run RIP, while allowing RIPv1 in simple topologies with fixed subnetting, a default route for external traffic, or no connection to other organizations.

The memo notes that RIPv1 includes no security functions and recommends RIPv2 for sites concerned about routing security.

The RFC recommends RIPv2 when a network needs RIP. It says RIPv1 is limited to simple cases and has no security functions.

§5References