summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1723.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1723.txt')
-rw-r--r--doc/rfc/rfc1723.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc1723.txt b/doc/rfc/rfc1723.txt
new file mode 100644
index 0000000..2b8fb74
--- /dev/null
+++ b/doc/rfc/rfc1723.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group G. Malkin
+Request for Comments: 1723 Xylogics, Inc.
+Obsoletes: 1388 November 1994
+Updates: 1058
+Category: Standards Track
+
+
+ RIP Version 2
+ Carrying Additional Information
+
+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
+
+ This document specifies an extension of the Routing Information
+ Protocol (RIP), as defined in [1,2], to expand the amount of useful
+ information carried in RIP messages and to add a measure of security.
+ This memo obsoletes RFC 1388, which specifies an update to the
+ "Routing Information Protocol" STD 34, RFC 1058.
+
+ The RIP-2 protocol analysis is documented in RFC 1721 [4].
+
+ The RIP-2 applicability statement is document in RFC 1722 [5].
+
+ The RIP-2 MIB description is defined in RFC 1724 [3]. This memo
+ obsoletes RFC 1389.
+
+Acknowledgements
+
+ I would like to thank the IETF ripv2 Working Group for their help in
+ improving the RIP-2 protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin [Page 1]
+
+RFC 1723 RIP Version 2 November 1994
+
+
+Table of Contents
+
+ 1. Justification . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.5 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 6
+ 4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . . 7
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
+ Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
+
+1. Justification
+
+ With the advent of OSPF and IS-IS, there are those who believe that
+ RIP is obsolete. While it is true that the newer IGP routing
+ protocols are far superior to RIP, RIP does have some advantages.
+ Primarily, in a small network, RIP has very little overhead in terms
+ of bandwidth used and configuration and management time. RIP is also
+ very easy to implement, especially in relation to the newer IGPs.
+
+ Additionally, there are many, many more RIP implementations in the
+ field than OSPF and IS-IS combined. It is likely to remain that way
+ for some years yet.
+
+ Given that RIP will be useful in many environments for some period of
+ time, it is reasonable to increase RIP's usefulness. This is
+ especially true since the gain is far greater than the expense of the
+ change.
+
+2. Current RIP
+
+ The current RIP message contains the minimal amount of information
+ necessary for routers to route messages through a network. It also
+ contains a large amount of unused space, owing to its origins.
+
+ The current RIP protocol does not consider autonomous systems and
+ IGP/EGP interactions, subnetting, and authentication since
+ implementations of these postdate RIP. The lack of subnet masks is a
+
+
+
+Malkin [Page 2]
+
+RFC 1723 RIP Version 2 November 1994
+
+
+ particularly serious problem for routers since they need a subnet
+ mask to know how to determine a route. If a RIP route is a network
+ route (all non-network bits 0), the subnet mask equals the network
+ mask. However, if some of the non-network bits are set, the router
+ cannot determine the subnet mask. Worse still, the router cannot
+ determine if the RIP route is a subnet route or a host route.
+ Currently, some routers simply choose the subnet mask of the
+ interface over which the route was learned and determine the route
+ type from that.
+
+3. Protocol Extensions
+
+ This document does not change the RIP protocol per se. Rather, it
+ provides extensions to the message format which allows routers to
+ share important additional information.
+
+ The first four octets of a RIP message contain the RIP header. The
+ remainder of the message is composed of 1 - 25 route entries (20
+ octets each). The new RIP message format is:
+
+ 0 1 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Command (1) | Version (1) | unused |
+ +---------------+---------------+-------------------------------+
+ | Address Family Identifier (2) | Route Tag (2) |
+ +-------------------------------+-------------------------------+
+ | IP Address (4) |
+ +---------------------------------------------------------------+
+ | Subnet Mask (4) |
+ +---------------------------------------------------------------+
+ | Next Hop (4) |
+ +---------------------------------------------------------------+
+ | Metric (4) |
+ +---------------------------------------------------------------+
+
+ The Command, Address Family Identifier (AFI), IP Address, and Metric
+ all have the meanings defined in RFC 1058. The Version field will
+ specify version number 2 for RIP messages which use authentication or
+ carry information in any of the newly defined fields. The contents
+ of the unused field (two octets) shall be ignored.
+
+ All fields are coded in IP network byte order (big-endian).
+
+
+
+
+
+
+
+
+Malkin [Page 3]
+
+RFC 1723 RIP Version 2 November 1994
+
+
+3.1 Authentication
+
+ Since authentication is a per message function, and since there is
+ only one 2-octet field available in the message header, and since any
+ reasonable authentication scheme will require more than two octets,
+ the authentication scheme for RIP version 2 will use the space of an
+ entire RIP entry. If the Address Family Identifier of the first (and
+ only the first) entry in the message is 0xFFFF, then the remainder of
+ the entry contains the authentication. This means that there can be,
+ at most, 24 RIP entries in the remainder of the message. If
+ authentication is not in use, then no entries in the message should
+ have an Address Family Identifier of 0xFFFF. A RIP message which
+ contains an authentication entry would begin with the following
+ format:
+
+ 0 1 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Command (1) | Version (1) | unused |
+ +---------------+---------------+-------------------------------+
+ | 0xFFFF | Authentication Type (2) |
+ +-------------------------------+-------------------------------+
+ ~ Authentication (16) ~
+ +---------------------------------------------------------------+
+
+ Currently, the only Authentication Type is simple password and it is
+ type 2. The remaining 16 octets contain the plain text password. If
+ the password is under 16 octets, it must be left-justified and padded
+ to the right with nulls (0x00).
+
+3.2 Route Tag
+
+ The Route Tag (RT) field is an attribute assigned to a route which
+ must be preserved and readvertised with a route. The intended use of
+ the Route Tag is to provide a method of separating "internal" RIP
+ routes (routes for networks within the RIP routing domain) from
+ "external" RIP routes, which may have been imported from an EGP or
+ another IGP.
+
+ Routers supporting protocols other than RIP should be configurable to
+ allow the Route Tag to be configured for routes imported from
+ different sources. For example, routes imported from EGP or BGP
+ should be able to have their Route Tag either set to an arbitrary
+ value, or at least to the number of the Autonomous System from which
+ the routes were learned.
+
+ Other uses of the Route Tag are valid, as long as all routers in the
+ RIP domain use it consistently. This allows for the possibility of a
+
+
+
+Malkin [Page 4]
+
+RFC 1723 RIP Version 2 November 1994
+
+
+ BGP-RIP protocol interactions document, which would describe methods
+ for synchronizing routing in a transit network.
+
+3.3 Subnet mask
+
+ The Subnet Mask field contains the subnet mask which is applied to
+ the IP address to yield the non-host portion of the address. If this
+ field is zero, then no subnet mask has been included for this entry.
+
+ On an interface where a RIP-1 router may hear and operate on the
+ information in a RIP-2 routing entry the following rules apply:
+
+ 1) information internal to one network must never be advertised into
+ another network,
+
+ 2) information about a more specific subnet may not be advertised
+ where RIP-1 routers would consider it a host route, and
+
+ 3) supernet routes (routes with a netmask less specific than the
+ "natural" network mask) must not be advertised where they could be
+ misinterpreted by RIP-1 routers.
+
+3.4 Next Hop
+
+ 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 1994
+
+
+Appendix 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 1994
+
+
+Author's Address
+
+ Gary Scott Malkin
+ Xylogics, Inc.
+ 53 Third Avenue
+ Burlington, MA 01803
+
+ Phone: (617) 272-8140
+ EMail: gmalkin@Xylogics.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin [Page 9]
+