rfc887.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

           |     2     | 'C'   'R'   'A'   'S'   'H'   '-' |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           | 'D'   'U'   'M'   'P'    0  |                  
           +-----+-----+-----+-----+-----+                  

    to its local network (note that the file name component is
    explicitly terminated by a null so as not to exclude future
    further specialization of the crash dump protocol).

     - Host C (which supports this specialization of the TFTP
       protocol) receives the request and returns the reply

               <I-Provide> <Flags>=none <Message-ID>=54321
             <Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}


Accetta                                                        [Page 11]

RFC 887                                                    December 1983
Resource Location Protocol

       encoded as the 21 octet message


            +-----+-----+-----+-----+-----+-----+-----+-----+
            |  4  |  0  |   54321   |  17 |  15 |     69    |
            +-----+-----+-----+-----+-----+-----+-----+-----+
            |     2     | 'C'   'R'   'A'   'S'   'H'   '-' |
            +-----+-----+-----+-----+-----+-----+-----+-----+
            | 'D'   'U'   'M'   'P'    0  |                  
            +-----+-----+-----+-----+-----+                  

       to host H which may then proceed to send its crash dump to
       host C and reload.

     - Host D (which provides TFTP service but not the crash dump
       specialization), however, might receive the request and
       determine that it provides no support for the resource
       (since the resource name contains components following the
       UDP port number which it does not understand).  It would
       therefore return no reply to host H. 

 3. Finally, suppose host M wishes to locate some domain name
    translation server (either UDP or TCP based) anywhere on the
    Internet.  Furthermore, suppose that host M is on a IP network
    which does not provide broadcast address capabilities and that
    host R is a "known" resource location server for that network.

    First, since host M prefers to find a domain name server on its
    own locally connected network if possible, it sends the request

              <Does-Anyone-Provide?> <Flags>=<Local-Only>
                  <Message-ID>=12321 <Resource-List>=
                {[TCP, <DOMAIN-NAME-SERVER-PORT>] {M},
                 [UDP, <DOMAIN-NAME-SERVER-PORT>] {M}}

    encoded as the 22 octet message

        +-----+-----+-----+-----+                              
        |  3  | 128 |   12321   |                              
        +-----+-----+-----+-----+-----+-----+-----+-----+-----+
        |  6  |  2  |     53    |  1  |           M           |
        +-----+-----+-----+-----+-----+-----+-----+-----+-----+
        |  17 |  2  |     53    |  1  |           M           |
        +-----+-----+-----+-----+-----+-----+-----+-----+-----+

    to host R. 

    Host R receives the request and consults its tables for any
    hosts known to support either variety of domain name service.
    It finds entries indicating that both hosts S and T provide UDP


Accetta                                                        [Page 12]

RFC 887                                                    December 1983
Resource Location Protocol

    based domain name service but that neither host is on the same
    IP network as host H. It must then send the negative
    confirmation reply

            <They-Provide> <Flags>=none <Message-ID>=12321
                          <Resource-List>={}

    encoded as the 4 octet message

                       +-----+-----+-----+-----+
                       |  5  |  0  |   12321   |
                       +-----+-----+-----+-----+

    back to host M. 

    Host M, receiving this reply, might now abandon any hope of
    finding a server on its own network, reformat its request to
    permit any host address, and resend

        <Does-Anyone-Provide?> <Flags>=none <Message-ID>=12322
                           <Resource-List>=
                {[TCP, <DOMAIN-NAME-SERVER-PORT>] {M},
                 [UDP, <DOMAIN-NAME-SERVER-PORT>] {M}}

    encoded as the 22 octet message

        +-----+-----+-----+-----+                              
        |  3  |  0  |   12322   |                              
        +-----+-----+-----+-----+-----+-----+-----+-----+-----+
        |  6  |  2  |     53    |  1  |           M           |
        +-----+-----+-----+-----+-----+-----+-----+-----+-----+
        |  17 |  2  |     53    |  1  |           M           |
        +-----+-----+-----+-----+-----+-----+-----+-----+-----+

    again to host R. 

    Host R receives this new request and is no longer constrained
    to return only local addresses.  However, since only space for
    a single qualifying IP address was provided in each request
    resource specifier, it may not immediately return both
    addresses.  Instead, it is forced to return only the first
    address and replies

            <They-Provide> <Flags>=none <Message-ID>=12322
        <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>] {S}}

    encoded as the 13 octet message





Accetta                                                        [Page 13]

RFC 887                                                    December 1983
Resource Location Protocol

           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  5  |  0  |   12322   |  17 |  2  |     53    |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  1  |           S           |                  
           +-----+-----+-----+-----+-----+                  

    to Host M. 

    Host M receives the reply and (being the suspicious sort)
    decides to confirm it with host S. It then sends

           <Do-You-Provide?> <Flags>=none <Message-ID>=12323
          <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>]}

    encoded as the 8 octet message

           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  1  |  0  |   12323   |  17 |  2  |     53    |
           +-----+-----+-----+-----+-----+-----+-----+-----+

    to host S and receives back from host S the reply

              <I-Provide> <Flags>=none <Message-ID>=12323
                          <Resource-List>={}

    encoded as the 4 octet message

                       +-----+-----+-----+-----+
                       |  4  |  0  |   12323   |
                       +-----+-----+-----+-----+

    denying any support for UDP based domain name service.

    In desperation host M again queries host R, this time excluding
    host S from consideration, and sends the request

        <Does-Anyone-Provide?> <Flags>=none <Message-ID>=12324
                           <Resource-List>=
                {[TCP, <DOMAIN-NAME-SERVER-PORT>] {S},
                 [UDP, <DOMAIN-NAME-SERVER-PORT>] {S}}

    encoded as the 22 octet message

        +-----+-----+-----+-----+                              
        |  3  |  0  |   12324   |                              
        +-----+-----+-----+-----+-----+-----+-----+-----+-----+
        |  6  |  2  |     53    |  1  |           S           |
        +-----+-----+-----+-----+-----+-----+-----+-----+-----+
        |  17 |  2  |     53    |  1  |           S           |
        +-----+-----+-----+-----+-----+-----+-----+-----+-----+


Accetta                                                        [Page 14]

RFC 887                                                    December 1983
Resource Location Protocol

    and this time receives the reply


            <They-Provide> <Flags>=none <Message-ID>=12324
        <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>] {T}}

    encoded as the 13 octet message

           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  5  |  0  |   12324   | 17  |  2  |     53    |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  1  |           T           |                  
           +-----+-----+-----+-----+-----+                  

    from host R which of course host M again insists on confirming
    by sending the request

           <Do-You-Provide?> <Flags>=none <Message-ID>=12325
                           <Resource-List>=
                  {[UDP, <DOMAIN-NAME-SERVER-PORT>]}

    encoded as the 8 octet message

           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  1  |  0  |   12325   |  17 |  2  |     53    |
           +-----+-----+-----+-----+-----+-----+-----+-----+

    to host T and finally receives confirmation from host T with
    the reply

              <I-Provide> <Flags>=none <Message-ID>=12325
          <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>]}

    encoded as the 8 octet message

           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  4  |  0  |   12325   |  17 |  2  |     53    |
           +-----+-----+-----+-----+-----+-----+-----+-----+

    that it indeed provides domain name translation service at UDP
    port 53.

A. Assigned Numbers

The "well-known" UDP port number for the Resource Location Protocol is
39 (47 octal).






Accetta                                                        [Page 15]

RFC 887                                                    December 1983
Resource Location Protocol

                               REFERENCES

[1]   Postel, J.
      User Datagram Protocol.
      RFC 768, USC/Information Sciences Institute, August, 1980.

[2]   Postel, J.
      File Transfer Protocol.
      RFC 765, USC/Information Sciences Institute, June, 1980.

[3]   Postel, J.
      Internet Protocol - DARPA Internet Program Protocol Specification.
      RFC 791, USC/Information Sciences Institute, September, 1981.

[4]   Postel, J.
      Transmission Control Protocol- DARPA Internet Program Protocol
         Specification.
      RFC 793, USC/Information Sciences Institute, September, 1981.

[5]   Postel, J.
      Internet Control Message Protocol - DARPA Internet Program
         Protocol Specification.
      RFC 792, USC/Information Sciences Institute, September, 1981.

[6]   Reynolds, J., and J. Postel.
      Assigned Numbers.
      RFC 870, USC/Information Sciences Institute, October, 1983.

[7]   Gurwitz, R., and R. Hinden.
      IP - Local Area Network Addressing Issues.
      IEN 212, Bolt Beranek and Newman, September, 1982.

[8]   Sollins, K.
      The TFTP Protocol (revision 2).
      RFC 783, MIT/Laboratory for Computer Science, June, 1981.

















Accetta                                                        [Page 16]