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. Plea 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 uful
information carried in RIP messages and to add a measure of curity. 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]
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 tho 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 ud 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 uful in many environments for some period of time, it is reasonable to increa RIP’s ufulness. This is
especially true since the gain is far greater than the expen 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 unud space, owing to its origins.
The current RIP protocol does not consider autonomous systems and
IGP/EGP interactions, subnetting, and authentication since
implementations of the postdate RIP. The lack of subnet masks is a Malkin [Page 2]
particularly rious 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 t, the router
cannot determine the subnet mask. Wor still, the router cannot
determine if the RIP route is a subnet route or a host route.
Currently, some routers simply choo 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 . 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 compod 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) | unud |
+---------------+---------------+-------------------------------+
| Address Family Identifier (2) | Route Tag (2) |
+-------------------------------+-------------------------------+
| IP Address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
take英语
+---------------------------------------------------------------+
| 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 u authentication or carry information in any of the newly defined fields. The contents
of the unud field (two octets) shall be ignored.
All fields are coded in IP network byte order (big-endian).
Malkin [Page 3]
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 u 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 u, 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) | unud |
+---------------+---------------+-------------------------------+
| 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 prerved and readvertid with a route. The intended u of the Route Tag is to provide a method of parating "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 t to an arbitrary
value, or at least to the number of the Autonomous System from which the routes were learned.
Other us of the Route Tag are valid, as long as all routers in the RIP domain u it consistently.
This allows for the possibility of a Malkin [Page 4]
河北招生考试院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 advertid into another network,
2) information about a more specific subnet may not be advertid
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 advertid 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 advertiment. An address specified as a
next hop must, per force, be directly reachable on the logical subnet over which the advertiment is made.
The purpo of the Next Hop field is to eliminate packets being
routed through extra hops in the system. It is particularly uful
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 tho hosts which are not
listening to RIP-2 messages, an IP multicast address will be ud for periodic broadcasts. The IP multicast address is 224.0.0.9. Note
that IGMP is not needed since the are inter-router messages which
are not forwarded.
Malkin [Page 5]
In order to maintain backwards compatibility, the u of the
multicast address will be configurable, as described in ction 4.1. If multicasting is ud, it should be ud 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 Respon. If the router is configured to nd 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 becau 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 u of multicasting would
prevent RIP-1 systems from receiving RIP-2 updates (which may be a
desired feature in some cas). This switch should be configurable
on a per-interface basis.
The switch has four ttings: RIP-1, in which only RIP-1 messages are nt; RIP-1 compatibility, in which RIP-2 messages are broadcast;
RIP-2, in which RIP-2 messages are multicast; and "none", which
disables the nding 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 ud 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]
