rfc1058.txt

中、英文RFC文档大全打包下载完全版 .

      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.



Hedrick                                                        [Page 19]

RFC 1058              Routing Information Protocol             June 1988


   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



Hedrick                                                        [Page 20]

RFC 1058              Routing Information Protocol             June 1988


   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
   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



Hedrick                                                        [Page 21]

RFC 1058              Routing Information Protocol             June 1988


   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



Hedrick                                                        [Page 22]

RFC 1058              Routing Information Protocol             June 1988


   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 h