rfc1476.txt

RFC 的详细文档！

Network Working Group                                        R. Ullmann
Request for Comments: 1476                 Process Software Corporation
                                                              June 1993


                  RAP: Internet Route Access Protocol

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

Abstract

   This RFC describes an open distance vector routing protocol for use
   at all levels of the internet, from isolated LANs to the major
   routers of an international commercial network provider.

Table of Contents

   1.       Introduction  . . . . . . . . . . . . . . . . . . . 2
   1.1       Link-State and Distance-Vector . . . . . . . . . . 3
   1.2       Terminology  . . . . . . . . . . . . . . . . . . . 3
   1.3       Philosophy . . . . . . . . . . . . . . . . . . . . 3
   2.       RAP Protocol  . . . . . . . . . . . . . . . . . . . 4
   2.1       Command Header Format  . . . . . . . . . . . . . . 4
   2.1.1     Length field . . . . . . . . . . . . . . . . . . . 4
   2.1.2     RAP version  . . . . . . . . . . . . . . . . . . . 5
   2.2       RAP Commands . . . . . . . . . . . . . . . . . . . 5
   2.2.1     No operation . . . . . . . . . . . . . . . . . . . 5
   2.2.2     Poll . . . . . . . . . . . . . . . . . . . . . . . 6
   2.2.3     Error  . . . . . . . . . . . . . . . . . . . . . . 7
   2.2.4     Add Route  . . . . . . . . . . . . . . . . . . . . 8
   2.2.5     Purge Route  . . . . . . . . . . . . . . . . . . . 9
   3.       Attributes of Routes  . . . . . . . . . . . . . . . 9
   3.1       Metric and Option Format . . . . . . . . . . . . .10
   3.1.1     Option Class . . . . . . . . . . . . . . . . . .  10
   3.1.2     Type . . . . . . . . . . . . . . . . . . . . . .  10
   3.1.3     Format . . . . . . . . . . . . . . . . . . . . .  11
   3.2       Metrics and Options  . . . . . . . . . . . . . .  11
   3.2.1     Distance . . . . . . . . . . . . . . . . . . . .  12
   3.2.2     Delay  . . . . . . . . . . . . . . . . . . . . .  12
   3.2.3     MTU  . . . . . . . . . . . . . . . . . . . . . .  12
   3.2.4     Bandwidth  . . . . . . . . . . . . . . . . . . .  12



Ullmann                                                         [Page 1]

RFC 1476                          RAP                          June 1993


   3.2.5     Origin . . . . . . . . . . . . . . . . . . . . .  12
   3.2.6     Target . . . . . . . . . . . . . . . . . . . . .  13
   3.2.7     Packet Cost  . . . . . . . . . . . . . . . . . .  13
   3.2.8     Time Cost  . . . . . . . . . . . . . . . . . . .  13
   3.2.9     Source Restriction . . . . . . . . . . . . . . .  14
   3.2.10    Destination Restriction  . . . . . . . . . . . .  14
   3.2.11    Trace  . . . . . . . . . . . . . . . . . . . . .  14
   3.2.12    AUP  . . . . . . . . . . . . . . . . . . . . . .  15
   3.2.13    Public . . . . . . . . . . . . . . . . . . . . .  15
   4.       Procedure   . . . . . . . . . . . . . . . . . . .  15
   4.1       Receiver filtering . . . . . . . . . . . . . . .  16
   4.2       Update of metrics and options  . . . . . . . . .  16
   4.3       Aggregation  . . . . . . . . . . . . . . . . . .  17
   4.4       Active route selection . . . . . . . . . . . . .  17
   4.5       Transmitter filtering  . . . . . . . . . . . . .  17
   4.6       Last resort loop prevention  . . . . . . . . . .  18
   5.       Conclusion  . . . . . . . . . . . . . . . . . . .  18
   6.       Appendix: Real Number Representation  . . . . . .  19
   7.       References  . . . . . . . . . . . . . . . . . . .  20
   8.       Security Considerations . . . . . . . . . . . . .  20
   9.       Author's Address  . . . . . . . . . . . . . . . .  20

1.  Introduction

   RAP is a general protocol for distributing routing information at all
   levels of the Internet, from private LANs to the widest-flung
   international carrier networks.  It does not distinguish between
   "interior" and "exterior" routing (except as restricted by specific
   policy), and therefore is not as restricted nor complex as those
   protocols that have strict level and area definitions in their
   models.

   The protocol encourages the widest possible dissemination of topology
   information, aggregating it only when limits of thrust, bandwidth, or
   administrative policy require it.  Thus RAP permits aggressive use of
   resources to optimize routes where desired, without the restrictions
   inherent in the simplifications of other models.

   While RAP uses IPv7 [RFC1475] addressing internally, it is run over
   both IPv4 and IPv7 networks, and shares routing information between
   them.  A IPv4 router will only be able to activate and propagate
   routes that are defined within the local Administrative Domain (AD),
   loading the version 4 subset of the address into the local IP
   forwarding database.







Ullmann                                                         [Page 2]

RFC 1476                          RAP                          June 1993


1.1  Link-State and Distance-Vector

   Of the two major classes of routing algorithm, link-state and
   distance vector, only distance vector seems to scale from the local
   network (where RIP is existence-proof of its validity) to large scale
   inter-domain policy routing, where the number of links and policies
   exceeds the ability of each router to map the entire network.

   In between, we have OSPF, an open link state (specifically, using
   shortest-path-first analysis of the graph, hence the acronym)
   protocol, with extensive development in intra-area routing.

   Since distance vector has proven useful at both ends of the range, it
   seems reasonable to apply it to the entire range of scales, creating
   a protocol that works automatically on small groups of LANs, but can
   apply fairly arbitrary policy in the largest networks.

   This helps model the real world, where networks are not clearly
   divided into hierarchical domains with identifiable "border" routers,
   but have many links across organizational structure and over back
   fences.

1.2  Terminology

   The RAP protocol propagates routes in the opposite direction to the
   travel of datagrams using the routes.  To avoid confusion explaining
   the routing protocol, several terms are distinguished:

   source          where datagrams come from, the source of the
                   datagrams

   destination     where datagrams go to, the destination of the
                   datagrams

   origin          where routing information originates, the router
                   initially inserting route information into the
                   RAP domain

   target          where routing information goes, the target uses the
                   information to send datagrams

1.3  Philosophy

   Protocols should become simpler as they evolve.







Ullmann                                                         [Page 3]

RFC 1476                          RAP                          June 1993


2.  RAP Protocol

   The RAP protocol operates on TCP port 38, with peers opening a
   symmetric TCP connection between the RAP ports on each system.  Thus
   only one RAP connection exists between any pair of peers.

   RAP is also used on UDP port 38, as a peer discovery method.  Hosts
   (i.e., non-routing systems) may listen to RAP datagrams on this port
   to discover local gateways.  This is in addition to, or in lieu of,
   an Internet Standard gateway discovery protocol, which does not exist
   at this writing.

   The peers then use RAP commands to send each other all routes
   available though the sending peer.  This occurs as a full-duplex
   (i.e., simultaneous) exchange of information, with no acknowledgement
   of individual commands.

   Once the initial exchange has been completed, the peers send only
   updates to routes, new routes, and purge commands to delete routes
   previously offered.

   When the connection is broken, each system purges all routes that had
   been offered by the peer.

2.1  Command Header Format

   Each RAP command starts with a header.  The header contains a length
   field to identify the start of the next packet in the TCP stream, a
   version number, and the code for the command.  On UDP, the length
   field does not appear:  each UDP datagram must contain exactly one
   RAP command and not contain data or padding after the end of the
   command.

     0                   1                   2                   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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        length                                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        RAP version            |       command code            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1  Length field

   The length is a 32 bit unsigned number specifying the offset in bytes
   from the first byte of the length field of this command packet to the
   start of the length field of the next.  The minimum value is 8.
   There is no specific limit to the length of a command packet;
   implementations MUST be able to at least count and skip over a packet



Ullmann                                                         [Page 4]

RFC 1476                          RAP                          June 1993


   that is too large and then MAY send an error indication.

   Each version of the protocol will profile what size should be
   considered the limit for senders, and what (larger) size should be
   considered by receivers to mean that the connection is insane:
   either unsynchronized or worse.

   For version 1 of the protocol, senders MUST NOT send command packets
   greater than 16384 bytes.  Receivers SHOULD consider packets that
   appear to be greater than 162144 bytes in length to be an indication
   of an unrecoverable error.

   Note that these limits probably will not be approached in normal
   operation of version 1 of the protocol; receivers may reasonably
   decline to use routes described by 16K bytes of metrics and policy.
   But even the most memory-restricted implementation MUST be able to
   skip such a command packet.

2.1.2  RAP version

   The version field is a 16 bit unsigned number.  It identifies the
   version of RAP used for that command.  Note that commands with
   different versions may be mixed on the same connection, although the
   usual procedure will be to do the serious protocol (exchanging route
   updates) only at the highest version common to both ends of the
   connection.

   Each side starts the connection by sending a poll command, using the
   highest version supported and continues by using the highest version
   received in any command from the remote.  The response to the poll
   will either be a no-operation packet at that version or an error
   packet at the highest version supported by the remote.

   This document describes version 1 of the RAP protocol.

2.2  RAP Commands

   There five simple RAP commands, described in the following sections.

2.2.1  No operation

   The no operation command serves to reset the poll timer (see next
   section) of the receiver, or (as a side effect) to tell the receiver
   that a particular version is supported.  It never contains option
   specific data and its length is always 8.

   The no operation command is also used in a UDP broadcast to inform
   other systems that the sender is running RAP actively on the network