doc: Add RFC documents

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]
+