summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1722.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1722.txt')
-rw-r--r--doc/rfc/rfc1722.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc1722.txt b/doc/rfc/rfc1722.txt
new file mode 100644
index 0000000..27fd197
--- /dev/null
+++ b/doc/rfc/rfc1722.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+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|
+ -----
+ / \
+ / \
+ ----- ----- -----
+ |RO1|-----|RO2|=====| R |
+ ----- ----- -----
+
+ The three links between the Central Office Router (COR) and the
+ Remote Office routers (RO1 and RO2) are all Dial-On-Demand (DOD)
+ links. The link between RO2 and R is a fixed link. Once all of the
+ routers have been initialized, the only routes they know about are
+ the configured static routes for the DOD links. Assume that
+ connections between COR and RO1, and COR and RO2 are established and
+ RIP information is passing between the routers. RO1 will ignore
+ COR's route to RO2 because it already has a better one; however, it
+ will learn to reach R via COR.
+
+ If we assume that RO1 and RO2 are only capable of establishing one
+ link at a time, then RO1 will not be able to reach RO2; however, RO1
+ will be able to reach R. Worse still, if we assume that traffic
+ stops and the DOD links drop due to inactivity, an attempt by RO1 to
+ reach R will trigger the dialing of two links (through COR). Of
+ course, once RO1 establishes a link to RO2, the problem corrects
+ itself because the new route to R is one hop shorter.
+
+ To correct this problem, the routers may use the Next Hop field to
+ indicate their next hop. Consider the following route advertisements
+ during the period described above (before the RO1/RO2 link has ever
+ been established):
+
+ Sender Recvr Route NextHop Metric
+ =======================================
+ RO2 COR R 0 1
+ ---------------------------------------
+ COR RO1 RO2 0 1
+ R RO2 2
+ ---------------------------------------
+
+
+
+
+
+Malkin [Page 3]
+
+RFC 1722 RIP-2 Applicability November 1994
+
+
+ When R01 receives the two routes from COR, it will ignore the route
+ for RO2, as mentioned above. However, since R is not in RO1's
+ routing table, it will add it using a next hop of RO2 (because RO2 is
+ directly connected, after a fashion). Note that COR does count
+ itself in R's metric; this is less than accurate, but entirely safe
+ and correctable (when the RO1/RO2 link comes up). Suppose, now, that
+ the RO1/RO2 link did not exist. RO1 would ignore the specification
+ of RO2 as the next hop to R and use COR, as it would if no Next Hop
+ had been specified.
+
+ Note that this is not a recursive algorithm; it only works to
+ eliminate a single extra hop from the path. There are methods by
+ which this mechanism might be extended to include larger
+ optimizations, but the potential to create routing loops has not been
+ sufficiently analyzed to specify them here.
+
+3.3 Authentication
+
+ The need for authentication in a routing protocol is obvious. It is
+ not usually important to conceal the information in the routing
+ messages, but it is essential to prevent the insertion of bogus
+ routing information into the routers. So, while the authentication
+ mechanism specified in RIP-2 is less than ideal, it does prevent
+ anyone who cannot directly access the network (i.e., someone who
+ cannot sniff the routing packets to determine the password) from
+ inserting bogus routing information.
+
+ However, the specification does allow for additional types of
+ authentication to be incorporated into the protocol. Unfortunately,
+ because of the original format of RIP packets, the amount of space
+ available for providing authentication information is only 16 octets.
+
+3.4 Multicasting
+
+ The RIP-2 protocol provides for the IP multicasting of periodic
+ advertisements. This feature was added to decrease the load on
+ systems which do not support RIP-2. It also provides a mechanism
+ whereby RIP-1 routers will never receive RIP-2 routes. This is a
+ feature when correct use of an advertised route depends on knowing
+ the precise subnet mask, which would be ignored by a RIP-1 router.
+
+4. Conclusion
+
+ Because the basic protocol is unchanged, RIP-2 is as correct a
+ routing protocol as RIP-1. The enhancements make RIP-2 useful in
+ environments which RIP-1 could not handle, but which do not
+ necessitate the use of OSPF by virtue of requirements which RIP-2
+ does not satisfy.
+
+
+
+Malkin [Page 4]
+
+RFC 1722 RIP-2 Applicability November 1994
+
+
+5. References
+
+ [1] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721,
+ Xylogics, Inc., November 1994.
+
+ [2] Malkin, G., "RIP Version 2 - Carrying Additional Information",
+ RFC 1723, Xylogics, Inc., November 1994.
+
+ [3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC
+ 1724, Xylogics, Inc., Cisco Systems, November 1994.
+
+6. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+7. Author's Address
+
+ Gary Scott Malkin
+ Xylogics, Inc.
+ 53 Third Avenue
+ Burlington, MA 01803
+
+ Phone: (617) 272-8140
+ EMail: gmalkin@Xylogics.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin [Page 5]
+