rfc1058.txt

283个中文RFC文档

triggered updates happens, it would be possible to prove that
counting to infinity will never happen. Bad routes would always be
removed immediately, and so no routing loops could form.

Unfortunately, things are not so nice. While the triggered updates
are being sent, regular updates may be happening at the same time.
Gateways that haven't received the triggered update yet will still be
sending out information based on the route that no longer exists. It
is possible that after the triggered update has gone through a
gateway, it might receive a normal update from one of these gateways
that hasn't yet gotten the word. This could reestablish an orphaned
remnant of the faulty route. If triggered updates happen quickly
enough, this is very unlikely. However, counting to infinity is
still possible.

3. Specifications for the protocol

RIP is intended to allow hosts and gateways to exchange information
for computing routes through an IP-based network. RIP is a distance
vector protocol. Thus, it has the general features described in
section 2. RIP may be implemented by both hosts and gateways. As in
most IP documentation, the term "host" will be used here to cover
either. RIP is used to convey information about routes to
"destinations", which may be individual hosts, networks, or a special
destination used to convey a default route.

Any host that uses RIP is assumed to have interfaces to one or more
networks. These are referred to as its "directly-connected
networks". The protocol relies on access to certain information
about each of these networks. The most important is its metric or
"cost". The metric of a network is an integer between 1 and 15
inclusive. It is set in some manner not specified in this protocol.
Most existing implementations always use a metric of 1. New
implementations should allow the system administrator to set the cost
of each network. In addition to the cost, each network will have an
IP network number and a subnet mask associated with it. These are to
be set by the system administrator in a manner not specified in this
protocol.

Note that the rules specified in section 3.2 assume that there is a
single subnet mask applying to each IP network, and that only the
subnet masks for directly-connected networks are known. There may be
systems that use different subnet masks for different subnets within
a single network. There may also be instances where it is desirable
for a system to know the subnets masks of distant networks. However,
such situations will require modifications of the rules which govern
the spread of subnet information. Such modifications raise issues of
interoperability, and thus must be viewed as modifying the protocol.

Each host that implements RIP is assumed to have a routing table.
This table has one entry for every destination that is reachable
through the system described by RIP. Each entry contains at least
the following information:

- The IP address of the destination.

- A metric, which represents the total cost of getting a
datagram from the host to that destination. This metric is
the sum of the costs associated with the networks that
would be traversed in getting to the destination.

- The IP address of the next gateway along the path to the
destination. If the destination is on one of the
directly-connected networks, this item is not needed.

- A flag to indicate that information about the route has
changed recently. This will be referred to as the "route
change flag."

- Various timers associated with the route. See section 3.3
for more details on them.

The entries for the directly-connected networks are set up by the
host, using information gathered by means not specified in this

protocol. The metric for a directly-connected network is set to the
cost of that network. In existing RIP implementations, 1 is always
used for the cost. In that case, the RIP metric reduces to a simple
hop-count. More complex metrics may be used when it is desirable to
show preference for some networks over others, for example because of
differences in bandwidth or reliability.

Implementors may also choose to allow the system administrator to
enter additional routes. These would most likely be routes to hosts
or networks outside the scope of the routing system.

Entries for destinations other these initial ones are added and
updated by the algorithms described in the following sections.

In order for the protocol to provide complete information on routing,
every gateway in the system must participate in it. Hosts that are
not gateways need not participate, but many implementations make
provisions for them to listen to routing information in order to
allow them to maintain their routing tables.

3.1. Message formats

RIP is a UDP-based protocol. Each host that uses RIP has a routing
process that sends and receives datagrams on UDP port number 520.
All communications directed at another host's RIP processor are sent
to port 520. All routing update messages are sent from port 520.
Unsolicited routing update messages have both the source and
destination port equal to 520. Those sent in response to a request
are sent to the port from which the request came. Specific queries
and debugging requests may be sent from ports other than 520, but
they are directed to port 520 on the target machine.

There are provisions in the protocol to allow "silent" RIP processes.
A silent process is one that normally does not send out any messages.
However, it listens to messages sent by others. A silent RIP might
be used by hosts that do not act as gateways, but wish to listen to
routing updates in order to monitor local gateways and to keep their
internal routing tables up to date. (See [5] for a discussion of
various ways that hosts can keep track of network topology.) A
gateway that has lost contact with all but one of its networks might
choose to become silent, since it is effectively no longer a gateway.

However, this should not be done if there is any chance that
neighboring gateways might depend upon its messages to detect that
the failed network has come back into operation. (The 4BSD routed
program uses routing packets to monitor the operation of point-to-
point links.)

The packet format is shown in Figure 1.

Format of datagrams containing network information. Field sizes
are given in octets. Unless otherwise specified, fields contain
binary integers, in normal Internet order with the most-significant
octet first. Each tick mark represents one bit.

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) | must be zero (2) |
+---------------+---------------+-------------------------------+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
.
.
.
The portion of the datagram from address family identifier through
metric may appear up to 25 times. IP address is the usual 4-octet
Internet address, in network order.

Figure 1. Packet format

Every datagram contains a command, a version number, and possible
arguments. This document describes version 1 of the protocol.
Details of processing the version number are described in section
3.4. The command field is used to specify the purpose of this
datagram. Here is a summary of the commands implemented in version
1:

1 - request A request for the responding system to send all or
part of its routing table.

2 - response A message containing all or part of the sender's
routing table. This message may be sent in response
to a request or poll, or it may be an update message
generated by the sender.

3 - traceon Obsolete. Messages containing this command are to be
ignored.

4 - traceoff Obsolete. Messages containing this command are to be
ignored.

5 - reserved This value is used by Sun Microsystems for its own
purposes. If new commands are added in any
succeeding version, they should begin with 6.
Messages containing this command may safely be
ignored by implementations that do not choose to
respond to it.

For request and response, the rest of the datagram contains a list of
destinations, with information about each. Each entry in this list
contains a destination network or host, and the metric for it. The
packet format is intended to allow RIP to carry routing information
for several different protocols. Thus, each entry has an address
family identifier to indicate what type of address is specified in
that entry. This document only describes routing for Internet
networks. The address family identifier for IP is 2. None of the
RIP implementations available to the author implement any other type
of address. However, to allow for future development,
implementations are required to skip entries that specify address
families that are not supported by the implementation. (The size of
these entries will be the same as the size of an entry specifying an
IP address.) Processing of the message continues normally after any
unsupported entries are skipped. The IP address is the usual
Internet address, stored as 4 octets in network order. The metric
field must contain a value between 1 and 15 inclusive, specifying the
current metric for the destination, or the value 16, which indicates
that the destination is not reachable. Each route sent by a gateway
supercedes any previous route to the same destination from the same
gateway.

The maximum datagram size is 512 octets. This includes only the
portions of the datagram described above. It does not count the IP
or UDP headers. The commands that involve network information allow
information to be split across several datagrams. No special
provisions are needed for continuations, since correct results will
occur if the datagrams are processed individually.

3.2. Addressing considerations

As indicated in section 2, distance vector routing can be used to
describe routes to individual hosts or to networks. The RIP protocol
allows either of these possibilities. The destinations appearing in
request and response messages can be networks, hosts, or a special
code used to indicate a default address. In general, the kinds of
routes actually used will depend upon the routing strategy used for
the particular network. Many networks are set up so that routing

information for individual hosts is not needed. If every host on a
given network or subnet is accessible through the same gateways, then
there is no reason to mention individual hosts in the routing tables.
However, networks that include point to point lines sometimes require
gateways to keep track of routes to certain hosts. Whether this
feature is required depends upon the addressing and routing approach
used in the system. Thus, some implementations may choose not to
support host routes. If host routes are not supported, they are to
be dropped when they are received in response messages. (See section
3.4.2.)

The RIP packet formats do not distinguish among various types of
address. Fields that are labeled "address" can contain any of the
following:

host address
subnet number
network number
0, indicating a default route

Entities that use RIP are assumed to use the most specific
information available when routing a datagram. That is, when routing
a datagram, its destination address must first be checked against the
list of host addresses. Then it must be checked to see whether it
matches any known subnet or network number. Finally, if none of
these match, the default route is used.

When a host evaluates information that it receives via RIP, its
interpretation of an address depends upon whether it knows the subnet
mask that applies to the net. If so, then it is possible to
determine the meaning of the address. For example, consider net