rfc1058.txt

283个中文RFC文档

128.6. It has a subnet mask of 255.255.255.0. Thus 128.6.0.0 is a
network number, 128.6.4.0 is a subnet number, and 128.6.4.1 is a host
address. However, if the host does not know the subnet mask,
evaluation of an address may be ambiguous. If there is a non-zero
host part, there is no clear way to determine whether the address
represents a subnet number or a host address. As a subnet number
would be useless without the subnet mask, addresses are assumed to
represent hosts in this situation. In order to avoid this sort of
ambiguity, hosts must not send subnet routes to hosts that cannot be
expected to know the appropriate subnet mask. Normally hosts only
know the subnet masks for directly-connected networks. Therefore,
unless special provisions have been made, routes to a subnet must not
be sent outside the network of which the subnet is a part.

This filtering is carried out by the gateways at the "border" of the
subnetted network. These are gateways that connect that network with
some other network. Within the subnetted network, each subnet is

treated as an individual network. Routing entries for each subnet
are circulated by RIP. However, border gateways send only a single
entry for the network as a whole to hosts in other networks. This
means that a border gateway will send different information to
different neighbors. For neighbors connected to the subnetted
network, it generates a list of all subnets to which it is directly
connected, using the subnet number. For neighbors connected to other
networks, it makes a single entry for the network as a whole, showing
the metric associated with that network. (This metric would normally
be the smallest metric for the subnets to which the gateway is
attached.)

Similarly, border gateways must not mention host routes for hosts
within one of the directly-connected networks in messages to other
networks. Those routes will be subsumed by the single entry for the
network as a whole. We do not specify what to do with host routes
for "distant" hosts (i.e., hosts not part of one of the directly-
connected networks). Generally, these routes indicate some host that
is reachable via a route that does not support other hosts on the
network of which the host is a part.

The special address 0.0.0.0 is used to describe a default route. A
default route is used when it is not convenient to list every
possible network in the RIP updates, and when one or more closely-
connected gateways in the system are prepared to handle traffic to
the networks that are not listed explicitly. These gateways should
create RIP entries for the address 0.0.0.0, just as if it were a
network to which they are connected. The decision as to how gateways
create entries for 0.0.0.0 is left to the implementor. Most
commonly, the system administrator will be provided with a way to
specify which gateways should create entries for 0.0.0.0. However,
other mechanisms are possible. For example, an implementor might
decide that any gateway that speaks EGP should be declared to be a
default gateway. It may be useful to allow the network administrator
to choose the metric to be used in these entries. If there is more
than one default gateway, this will make it possible to express a
preference for one over the other. The entries for 0.0.0.0 are
handled by RIP in exactly the same manner as if there were an actual
network with this address. However, the entry is used to route any
datagram whose destination address does not match any other network
in the table. Implementations are not required to support this
convention. However, it is strongly recommended. Implementations
that do not support 0.0.0.0 must ignore entries with this address.
In such cases, they must not pass the entry on in their own RIP
updates. System administrators should take care to make sure that
routes to 0.0.0.0 do not propagate further than is intended.
Generally, each autonomous system has its own preferred default
gateway. Thus, routes involving 0.0.0.0 should generally not leave

the boundary of an autonomous system. The mechanisms for enforcing
this are not specified in this document.

3.3. Timers

This section describes all events that are triggered by timers.

Every 30 seconds, the output process is instructed to generate a
complete response to every neighboring gateway. When there are many
gateways on a single network, there is a tendency for them to
synchronize with each other such that they all issue updates at the
same time. This can happen whenever the 30 second timer is affected
by the processing load on the system. It is undesirable for the
update messages to become synchronized, since it can lead to
unnecessary collisions on broadcast networks. Thus, implementations
are required to take one of two precautions.

- The 30-second updates are triggered by a clock whose rate
is not affected by system load or the time required to
service the previous update timer.

- The 30-second timer is offset by addition of a small random
time each time it is set.

There are two timers associated with each route, a "timeout" and a
"garbage-collection time". Upon expiration of the timeout, the route
is no longer valid. However, it is retained in the table for a short
time, so that neighbors can be notified that the route has been
dropped. Upon expiration of the garbage-collection timer, the route
is finally removed from the tables.

The timeout is initialized when a route is established, and any time
an update message is received for the route. If 180 seconds elapse
from the last time the timeout was initialized, the route is
considered to have expired, and the deletion process which we are
about to describe is started for it.

Deletions can occur for one of two reasons: (1) the timeout expires,
or (2) the metric is set to 16 because of an update received from the
current gateway. (See section 3.4.2 for a discussion processing
updates from other gateways.) In either case, the following events
happen:

- The garbage-collection timer is set for 120 seconds.

- The metric for the route is set to 16 (infinity). This
causes the route to be removed from service.

- A flag is set noting that this entry has been changed, and
the output process is signalled to trigger a response.

Until the garbage-collection timer expires, the route is included in
all updates sent by this host, with a metric of 16 (infinity). When
the garbage-collection timer expires, the route is deleted from the
tables.

Should a new route to this network be established while the garbage-
collection timer is running, the new route will replace the one that
is about to be deleted. In this case the garbage-collection timer
must be cleared.

See section 3.5 for a discussion of a delay that is required in
carrying out triggered updates. Although implementation of that
delay will require a timer, it is more natural to discuss it in
section 3.5 than here.

3.4. Input processing

This section will describe the handling of datagrams received on UDP
port 520. Before processing the datagrams in detail, certain general
format checks must be made. These depend upon the version number
field in the datagram, as follows:

0 Datagrams whose version number is zero are to be ignored.
These are from a previous version of the protocol, whose
packet format was machine-specific.

1 Datagrams whose version number is one are to be processed
as described in the rest of this specification. All fields
that are described above as "must be zero" are to be checked.
If any such field contains a non-zero value, the entire
message is to be ignored.

>1 Datagrams whose version number are greater than one are
to be processed as described in the rest of this
specification. All fields that are described above as
"must be zero" are to be ignored. Future versions of the
protocol may put data into these fields. Version 1
implementations are to ignore this extra data and process
only the fields specified in this document.

After checking the version number and doing any other preliminary
checks, processing will depend upon the value in the command field.

3.4.1. Request

Request is used to ask for a response containing all or part of the
host's routing table. [Note that the term host is used for either
host or gateway, in most cases it would be unusual for a non-gateway
host to send RIP messages.] Normally, requests are sent as
broadcasts, from a UDP source port of 520. In this case, silent
processes do not respond to the request. Silent processes are by
definition processes for which we normally do not want to see routing
information. However, there may be situations involving gateway
monitoring where it is desired to look at the routing table even for
a silent process. In this case, the request should be sent from a
UDP port number other than 520. If a request comes from port 520,
silent processes do not respond. If the request comes from any other
port, processes must respond even if they are silent.

The request is processed entry by entry. If there are no entries, no
response is given. There is one special case. If there is exactly
one entry in the request, with an address family identifier of 0
(meaning unspecified), and a metric of infinity (i.e., 16 for current
implementations), this is a request to send the entire routing table.
In that case, a call is made to the output process to send the
routing table to the requesting port.

Except for this special case, processing is quite simple. Go down
the list of entries in the request one by one. For each entry, look
up the destination in the host's routing database. If there is a
route, put that route's metric in the metric field in the datagram.
If there isn't a route to the specified destination, put infinity
(i.e., 16) in the metric field in the datagram. Once all the entries
have been filled in, set the command to response and send the
datagram back to the port from which it came.

Note that there is a difference in handling depending upon whether
the request is for a specified set of destinations, or for a complete
routing table. If the request is for a complete host table, normal
output processing is done. This includes split horizon (see section
2.2.1) and subnet hiding (section 3.2), so that certain entries from
the routing table will not be shown. If the request is for specific
entries, they are looked up in the host table and the information is
returned. No split horizon processing is done, and subnets are
returned if requested. We anticipate that these requests are likely
to be used for different purposes. When a host first comes up, it
broadcasts requests on every connected network asking for a complete
routing table. In general, we assume that complete routing tables
are likely to be used to update another host's routing table. For
this reason, split horizon and all other filtering must be used.
Requests for specific networks are made only by diagnostic software,

and are not used for routing. In this case, the requester would want
to know the exact contents of the routing database, and would not
want any information hidden.

3.4.2. Response

Responses can be received for several different reasons:

response to a specific query
regular updates
triggered updates triggered by a metric change

Processing is the same no matter how responses were generated.

Because processing of a response may update the host's routing table,
the response must be checked carefully for validity. The response
must be ignored if it is not from port 520. The IP source address
should be checked to see whether the datagram is from a valid
neighbor. The source of the datagram must be on a directly-connected
network. It is also worth checking to see whether the response is
from one of the host's own addresses. Interfaces on broadcast
networks may receive copies of their own broadcasts immediately. If
a host processes its own output as new input, confusion is likely,
and such datagrams must be ignored (except as discussed in the next
paragraph).

Before actually processing a response, it may be useful to use its
presence as input to a process for keeping track of interface status.
As mentioned above, we time out a route when we haven't heard from
its gateway for a certain amount of time. This works fine for routes
that come from another gateway. It is also desirable to know when
one of our own directly-connected networks has failed. This document
does not specify any particular method for doing this, as such
methods depend upon the characteristics of the network and the
hardware interface to it. However, such methods often involve
listening for datagrams arriving on the interface. Arriving
datagrams can be used as an indication that the interface is working.
However, some caution must be used, as it is possible for interfaces
to fail in such a way that input datagrams are received, but output
datagrams are never sent successfully.

Now that the datagram