rfc1931.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 620 行 · 第 1/2 页

             ferent network segment than expected; users will be able to
             remedy the problem by connecting the system to the correct
             network segment.

        DRARPERR_FAILURE (5)
             For some reason, no address could be returned.  No defined
             status code known to the server explained the reason.

   More opcodes for the Address Resolution Protocol (ARP) family could
   be defined in the future, so unrecognized opcodes (and error codes)
   should be ignored rather than treated as errors.

2.3  Protocol Exchanges

   This section describes typical protocol exchanges using RARP and
   Dynamic RARP, and common fault modes of each exchange.

2.3.1.  RARP Address Lookup

   To determine a previously published ("persistent") protocol address
   for itself or another system, a system may issue a REVARP_REQUEST
   packet.  If a REVARP_REPLY packet arrives in response, then the
   target protocol address listed there should be used.




Brownell                     Informational                      [Page 6]

RFC 1931                      Dynamic RARP                    April 1996


   If no REVARP_REPLY response packet arrives within some time interval,
   a number of errors may have occurred.  The simplest one is that the
   request or reply packet may never have arrived:  most RARP client
   implementations retransmit requests to partially account for this
   error.  There is no clear point at which to stop retransmitting a
   request, so many implementations apply an exponential backoff to the
   retransmit interval, to reduce what is typically broadcast traffic.

   Otherwise there are many different errors which all have the same
   failure mode, including: the system might not have a published
   protocol address; it might be on the wrong network segment, so its
   published address is invalid; the RARP servers which can supply the
   published address may be unavailable; it might even be on a network
   without any RARP servers at all.

2.3.2  Dynamic RARP Address Lookup

   Dynamic RARP may be used to determine previously published protocol
   addresses by clients who issue DRARP_REQUEST packets.  If the client
   has a published protocol address on the network segment on which the
   DRARP_REQUEST packet was issued, it is returned in a REVARP_REPLY
   packet.

   If the client has a published protocol address only on some other
   network segment, then two basic responses are possible.  In the case
   where dynamic address reallocation is enabled, a temporary protocol
   address may be allocated and returned in a DRARP_REPLY packet.
   Otherwise if dynamic address reallocation is disabled, a DRARP_ERROR
   packet is returned with the status DRARPERR_MOVED.  Detection of host
   movement can be provided only with link level addresses that are
   unique over the catenet, such as are provided with IEEE 802 48 bit
   addresses.  Without such uniqueness guarantees, this case looks like
   a request for a new address as described in the next section.

2.3.3  Dynamic RARP Address Allocation

   Dynamic RARP clients who issue DRARP_REQUEST packets may acquire
   newly allocated protocol addresses.  If the client has no published
   protocol address, there are three responses:

   (a)  When dynamic address allocation is enabled, a temporary protocol
        address is allocated and returned in a DRARP_REPLY packet.

   (b)  Errors or delays in the allocation process (with dynamic address
        allocation enabled) are reported in DRARP_ERROR packets with
        error codes such as DRARPERR_SERVERDOWN, DRARPERR_NOADDRESSES,
        DRARPERR_MOVED, or even DRARPERR_FAILURE.




Brownell                     Informational                      [Page 7]

RFC 1931                      Dynamic RARP                    April 1996


   (c)  When dynamic address allocation is disabled (or "restricted"), a
        DRARP_ERROR packet with status DRARPERR_RESTRICTED is returned.

        DRARP_REQUESTS are normally retransmitted until an address is
        returned, using backoff-style algorithms to minimize needless
        network traffic.  When DRARP_ERROR responses are received, they
        should be reported to the user.  For example, knowing that the
        server is busy could indicate it's time for a cup of Java, but
        if the network is restricted then it might be time to contact a
        network administrator for help instead.

2.3.4  Discovering Other DRARP Servers

        The existence of a DRARP server can be discovered by the fact
        that it puts its addressing information in all DRARP_REPLY
        packets that it sends.  DRARP servers can listen for such
        packets, as well as announcing themselves by sending such a
        packet to themselves.

        It can be important to discover other DRARP servers.  Users make
        mistakes, and can inappropriately set up DRARP servers that do
        not coordinate their address allocation with that done by the
        other DRARP servers on their network segment.  That causes
        significant administrative problems, which can all but be
        eliminated by DRARP servers which politely announce themselves,
        and when they detect an apparently spurious server, report this
        fact before entering a "restricted" mode to avoid creating any
        problems themselves.

        As no further server-to-server protocol is defined here, some
        out-of-band mechanism, such as communication through the address
        authority, must be used to help determine which servers are in
        fact spurious.

2.4  Network Setup Concerns

        Some internetwork environments connect multiple network segments
        using link level bridges or routers.  In such environments, a
        given broadcast accessible "local" area network will have two
        problems worth noting.

        First, it will extend over several cable segments, and be
        subject to partitioning faults.  Assigning one DRARP server to
        each segment (perhaps on systems acting as routers or bridges,
        to serve multiple segments) can reduce the cost of such faults.
        Assigning more than one such server can help reduce the cost of
        failure to any single network segment; these cooperate in the
        assignment of addresses through the address authority.



Brownell                     Informational                      [Page 8]

RFC 1931                      Dynamic RARP                    April 1996


        Second, those networks are sometimes shared by organizations
        which don't cooperate much on the management of protocol
        addresses, or perhaps aren't even collocated.  A DRARP server
        might need help from link level bridges/routers in order to
        ensure that local clients are tied to local servers (rather
        than, for example, to servers across the country where they are
        prone to availability problems).  Or the server might need to
        run in "restricted" mode so that a network administrator
        manually assigns address and other resources to each system.

3.  The Address Authority

        While not part of the DRARP protocol, the Address Authority used
        by the DRARP servers on a network segment is critical to
        providing the address allocation functionality.  It manages the
        data needed to implement such service, which is required not
        just for dynamic address allocation tools.  This section is
        provided to record one set of requirements for such an
        authority, ignoring implementation isssues such as whether
        protocol support for replication or partitioning is needed.

3.1  Basic Requirements

        For each network segment under its control, an Address Authority
        maintains at least:

        -    persistent bindings between hardware and protocol addresses
             (for at least those hosts which are DRARP clients);

        -    temporary bindings between such addresses;

        -    protocol addresses available for temporary bindings;

   The Address Authority is also responsible for presenting and managing
   those bindings.  DRARP clients need it to support:

        -    creating temporary bindings initially,

        -    looking up bindings (the distinction between temporary and
             persistent bindings is not usually significant here),

        -    deleting temporary or persistent bindings on request,

        -    purging them automatically by noticing that a binding is
             now persistent or that the temporary address is available
             for reuse.





Brownell                     Informational                      [Page 9]

RFC 1931                      Dynamic RARP                    April 1996


   Those clients will frequently make concurrent requests, and should be
   required to pass some kind of authorization check before they create
   or change any bindings.  They may also need to know about other
   clients, in order to determine (for example) if a given DRARP server
   is spurious.

3.2  Multiple Authorities and Segments

   Note there is only a single address authority on a given network
   segment.  It may be desirable to partition that authority, though
   that complicates implementation and administration of the authority
   substantially.

   If detection of systems moving between network segments is to be
   provided, then the authorities for those two network segments must
   either be the same or (equivalently) must communicate with one
   another.  Also, as noted earlier, hardware addresses must be scoped
   widely enough that the two segments do not assign the same link level
   address to different hosts.

3.3  Quality of Service

   The records of temporary address bindings must be persistent for at
   least long enough to install a system and propagate its records
   through the site's administrative databases, even in the case of
   server or network faults.  A timeout mechanism could be used to
   ensure that the limited address space was not used up too quickly.
   The initial implementation found that an hour's worth of caching,
   before deleting temporary bindings, was sufficient.

   Experience has shown that many networks have addresses in use which
   are not listed in their name services (or other administrative
   databases).  On such networks, the Address Authority should have a
   way to learn when an address which it thinks is available for
   allocation is instead being actively used.  Probing the network for
   "the truth" before handing out what turns out to be a duplicate IP
   address is a worthwhile.  Both ARPing for the address and ICMP echo
   request have been used for this.

4.  Security Considerations

   Security concerns are not addressed in this memo.  They are
   recognized as significant, but they also interact with site-specific
   network administration policies.  Those policies need to be addressed
   at higher levels before ramifications at this level can be
   understood.





Brownell                     Informational                     [Page 10]

RFC 1931                      Dynamic RARP                    April 1996


5.  References

   [1]  Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
        RFC 826, MIT, November 1982.

   [2]  Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
        Address Resolution Protocol", STD 38, RFC 903, Stanford, June
        1984.

   [3]  Finlayson, R., "Bootstrap Loading using TFTP", RFC 906,
        Stanford, June 1984.

   [4]  Postel, J., "Multi-LAN Address Resolution", RFC 925,
        USC/Information Sciences Institute, October 1984.

   [5]  Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
        13, RFC 1034, USC/Information Sciences Institute, November 1987.

   [6]  Postel, J., and J. Reynolds, "A Standard for the Transmission of
        IP Datagrams over IEEE802 Networks", STD 43, RFC 1042,
        USC/Information Sciences Institute, February 1988.

   [7]  IEEE; "IEEE Standards for Local Area Networks:  Logical Link
        Control" (IEEE 802.2); IEEE, New York, NY; 1985.

   [8]  United States Patent No. 4,689,786; "Local Area Network with
        Self Assigned Address Method"; Issued August 25, 1987;
        Inventors:  Sidhu, et al.; Assignee:  Apple Computer, Inc.

   [9]  Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
        Bucknell University, October 1993.

   [10] Srinivasan, R., "RPC:  Remote Procedure Call Protocol
        Specification, Version 2", RFC 1831, Sun Microsystems, August
        1995.

Author's Address:

   David Brownell
   SunSoft, Inc
   2550 Garcia Way, MS 19-215
   Mountain View, CA  94043

   Phone:  [phone]
   EMail:  [e-mail]






Brownell                     Informational                     [Page 11]