Routing Information Protocol
RFC 1058
|
Document |
Type |
|
RFC - Historic
(June 1988; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy stream
|
|
Formats |
|
plain text
html
pdf
htmlized (tools)
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1058 (Historic)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group C. Hedrick
Request for Comments: 1058 Rutgers University
June 1988
Routing Information Protocol
Status of this Memo
This RFC describes an existing protocol for exchanging routing
information among gateways and other hosts. It is intended to be
used as a basis for developing gateway software for use in the
Internet community. Distribution of this memo is unlimited.
Table of Contents
1. Introduction 2
1.1. Limitations of the protocol 4
1.2. Organization of this document 4
2. Distance Vector Algorithms 5
2.1. Dealing with changes in topology 11
2.2. Preventing instability 12
2.2.1. Split horizon 14
2.2.2. Triggered updates 15
3. Specifications for the protocol 16
3.1. Message formats 18
3.2. Addressing considerations 20
3.3. Timers 23
3.4. Input processing 24
3.4.1. Request 25
3.4.2. Response 26
3.5. Output Processing 28
3.6. Compatibility 31
4. Control functions 31
Overview
This memo is intended to do the following things:
- Document a protocol and algorithms that are currently in
wide use for routing, but which have never been formally
documented.
- Specify some improvements in the algorithms which will
improve stability of the routes in large networks. These
improvements do not introduce any incompatibility with
existing implementations. They are to be incorporated into
Hedrick [Page 1]
RFC 1058 Routing Information Protocol June 1988
all implementations of this protocol.
- Suggest some optional features to allow greater
configurability and control. These features were developed
specifically to solve problems that have shown up in actual
use by the NSFnet community. However, they should have more
general utility.
The Routing Information Protocol (RIP) described here is loosely
based on the program "routed", distributed with the 4.3 Berkeley
Software Distribution. However, there are several other
implementations of what is supposed to be the same protocol.
Unfortunately, these various implementations disagree in various
details. The specifications here represent a combination of features
taken from various implementations. We believe that a program
designed according to this document will interoperate with routed,
and with all other implementations of RIP of which we are aware.
Note that this description adopts a different view than most existing
implementations about when metrics should be incremented. By making
a corresponding change in the metric used for a local network, we
have retained compatibility with other existing implementations. See
section 3.6 for details on this issue.
1. Introduction
This memo describes one protocol in a series of routing protocols
based on the Bellman-Ford (or distance vector) algorithm. This
algorithm has been used for routing computations in computer networks
since the early days of the ARPANET. The particular packet formats
and protocol described here are based on the program "routed", which
is included with the Berkeley distribution of Unix. It has become a
de facto standard for exchange of routing information among gateways
and hosts. It is implemented for this purpose by most commercial
vendors of IP gateways. Note, however, that many of these vendors
have their own protocols which are used among their own gateways.
This protocol is most useful as an "interior gateway protocol". In a
nationwide network such as the current Internet, it is very unlikely
that a single routing protocol will used for the whole network.
Rather, the network will be organized as a collection of "autonomous
systems". An autonomous system will in general be administered by a
single entity, or at least will have some reasonable degree of
technical and administrative control. Each autonomous system will
Show full document text