Beruflich Dokumente
Kultur Dokumente
G. Malkin
Xylogics, Inc.
November 1994
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].
obsoletes RFC 1389.
This memo
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. Current RIP . . . . . .
3. Protocol Extensions . .
3.1
Authentication . . .
3.2
Route Tag . . . . . .
3.3
Subnet Mask . . . . .
3.4
Next Hop . . . . . .
3.5
Multicasting . . . .
3.6
Queries . . . . . . .
4. Compatibility . . . . .
4.1
Compatibility Switch
4.2
Authentication . . .
4.3
Larger Infinity . . .
4.4
Addressless Links . .
5. Security Considerations
Appendix A . . . . . . . .
References . . . . . . . .
Authors Address . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
3
4
4
5
5
5
6
6
6
6
7
7
7
8
8
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 RIPs 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
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
Malkin
[Page 5]
RFC 1723
RIP Version 2
November 1994
Malkin
[Page 6]
RIP Version 2
RFC 1723
November 1994
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]
RIP Version 2
RFC 1723
November 1994
Authors Address
Gary Scott Malkin
Xylogics, Inc.
53 Third Avenue
Burlington, MA 01803
Phone:
EMail:
Malkin
(617) 272-8140
gmalkin@Xylogics.COM
[Page 9]