rfc951.txt

DHCP服务器源码

RFC 951                                                   September 1985
Bootstrap Protocol


      'gateway'; this means 'boot the named program configured for my
      machine'.  Finally the field can be a fully directory qualified
      path name.

      The 'vend' field can be filled in by the client with
      vendor-specific strings or structures.  For example the machine
      hardware type or serial number may be placed here.  However the
      operation of the BOOTP server should not DEPEND on this
      information existing.

      If the 'vend' field is used, it is recommended that a 4 byte
      'magic number' be the first item within 'vend'.  This lets a
      server determine what kind of information it is seeing in this
      field.  Numbers can be assigned by the usual 'magic number'
      process --you pick one and it's magic.  A different magic number
      could be used for bootreply's than bootrequest's to allow the
      client to take special action with the reply information.

      [UDP checksum.]

   7.2. Client Retransmission Strategy

      If no reply is received for a certain length of time, the client
      should retransmit the request.  The time interval must be chosen
      carefully so as not to flood the network.  Consider the case of a
      cable containing 100 machines that are just coming up after a
      power failure.  Simply retransmitting the request every four
      seconds will inundate the net.

      As a possible strategy, you might consider backing off
      exponentially, similar to the way ethernet backs off on a
      collision.  So for example if the first packet is at time 0:00,
      the second would be at :04, then :08, then :16, then :32, then
      :64.  You should also randomize each time; this would be done
      similar to the ethernet specification by starting with a mask and
      'and'ing that with with a random number to get the first backoff.
      On each succeeding backoff, the mask is increased in length by one
      bit.  This doubles the average delay on each backoff.

      After the 'average' backoff reaches about 60 seconds, it should be
      increased no further, but still randomized.

      Before each retransmission, the client should update the 'secs'
      field. [UDP checksum.]





Croft & Gilmore                                                 [Page 7]



RFC 951                                                   September 1985
Bootstrap Protocol


   7.3. Server Receives BOOTREQUEST

      [UDP checksum.]  If the UDP destination port does not match the
      'BOOTP server' port, discard the packet.

      If the server name field (sname) is null (no particular server
      specified), or sname is specified and matches our name or
      nickname, then continue with packet processing.

      If the sname field is specified, but does not match 'us', then
      there are several options:

         1. You may choose to simply discard this packet.

         2. If a name lookup on sname shows it to be on this same cable,
         discard the packet.

         3. If sname is on a different net, you may choose to forward
         the packet to that address.  If so, check the 'giaddr' (gateway
         address) field.  If 'giaddr' is zero, fill it in with my
         address or the address of a gateway that can be used to get to
         that net.  Then forward the packet.

      If the client IP address (ciaddr) is zero, then the client does
      not know its own IP address.  Attempt to lookup the client
      hardware address (chaddr, hlen, htype) in our database.  If no
      match is found, discard the packet.  Otherwise we now have an IP
      address for this client; fill it into the 'yiaddr' (your IP
      address) field.

      We now check the boot file name field (file).  The field will be
      null if the client is not interested in filenames, or wants the
      default bootfile.  If the field is non-null, it is used as a
      lookup key in a database, along with the client's IP address.  If
      there is a default file or generic file (possibly indexed by the
      client address) or a fully-specified path name that matches, then
      replace the 'file' field with the fully-specified path name of the
      selected boot file.  If the field is non-null and no match was
      found, then the client is asking for a file we dont have; discard
      the packet, perhaps some other BOOTP server will have it.

      The 'vend' vendor-specific data field should now be checked and if
      a recognized type of data is provided, client-specific actions
      should be taken, and a response placed in the 'vend' data field of
      the reply packet.  For example, a workstation client could provide




Croft & Gilmore                                                 [Page 8]



RFC 951                                                   September 1985
Bootstrap Protocol


      an authentication key and receive from the server a capability for
      remote file access, or a set of configuration options, which can
      be passed to the operating system that will shortly be booted in.

      Place my (server) IP address in the 'siaddr' field.  Set the 'op'
      field to BOOTREPLY.  The UDP destination port is set to 'BOOTP
      client'.  If the client address 'ciaddr' is nonzero, send the
      packet there; else if the gateway address 'giaddr' is nonzero, set
      the UDP destination port to 'BOOTP server' and send the packet to
      'giaddr'; else the client is on one of our cables but it doesnt
      know its own IP address yet --use a method described in the 'Egg'
      section above to send it to the client. If 'Egg' is used and we
      have multiple interfaces on this host, use the 'yiaddr' (your IP
      address) field to figure out which net (cable/interface) to send
      the packet to.  [UDP checksum.]

   7.4. Server/Gateway Receives BOOTREPLY

      [UDP checksum.]  If 'yiaddr' (your [the client's] IP address)
      refers to one of our cables, use one of the 'Egg' methods above to
      forward it to the client.  Be sure to send it to the 'BOOTP
      client' UDP destination port.

   7.5. Client Reception

      Don't forget to process ARP requests for my own IP address (if I
      know it).  [UDP checksum.]  The client should discard incoming
      packets that: are not IP/UDPs addressed to the boot port; are not
      BOOTREPLYs; do not match my IP address (if I know it) or my
      hardware address; do not match my transaction id.  Otherwise we
      have received a successful reply. 'yiaddr' will contain my IP
      address, if I didnt know it before.  'file' is the name of the
      file name to TFTP 'read request'.  The server address is in
      'siaddr'.  If 'giaddr' (gateway address) is nonzero, then the
      packets should be forwarded there first, in order to get to the
      server.

8. Booting Through Gateways

   This part of the protocol is optional and requires some additional
   code in cooperating gateways and servers, but it allows cross-gateway
   booting.  This is mainly useful when gateways are diskless machines.
   Gateways containing disks (e.g. a UNIX machine acting as a gateway),
   might as well run their own BOOTP/TFTP servers.

   Gateways listening to broadcast BOOTREQUESTs may decide to forward or
   rebroadcast these requests 'when appropriate'.  For example, the


Croft & Gilmore                                                 [Page 9]



RFC 951                                                   September 1985
Bootstrap Protocol


   gateway could have, as part of his configuration tables, a list of
   other networks or hosts to receive a copy of any broadcast
   BOOTREQUESTs.  Even though a 'hops' field exists, it is a poor idea
   to simply globally rebroadcast the requests, since broadcast loops
   will almost certainly occur.

   The forwarding could begin immediately, or wait until the 'secs'
   (seconds client has been trying) field passes a certain threshold.

   If a gateway does decide to forward the request, it should look at
   the 'giaddr' (gateway IP address) field.  If zero, it should plug its
   own IP address (on the receiving cable) into this field.  It may also
   use the 'hops' field to optionally control how far the packet is
   reforwarded. Hops should be incremented on each forwarding.  For
   example, if hops passes '3', the packet should probably be discarded.
   [UDP checksum.]

   Here we have recommended placing this special forwarding function in
   the gateways.  But that does not have to be the case.  As long as
   some 'BOOTP forwarding agent' exists on the net with the booting
   client, the agent can do the forwarding when appropriate.  Thus this
   service may or may not be co-located with the gateway.

   In the case of a forwarding agent not located in the gateway, the
   agent could save himself some work by plugging the broadcast address
   of the interface receiving the bootrequest into the 'giaddr' field.
   Thus the reply would get forwarded using normal gateways, not
   involving the forwarding agent.  Of course the disadvantage here is
   that you lose the ability to use the 'Egg' non-broadcast method of
   sending the reply, causing extra overhead for every host on the
   client cable.

9. Sample BOOTP Server Database

   As a suggestion, we show a sample text file database that the BOOTP
   server program might use.  The database has two sections, delimited
   by a line containing an percent in column 1.  The first section
   contains a 'default directory' and mappings from generic names to
   directory/pathnames.  The first generic name in this section is the
   'default file' you get when the bootrequest contains a null 'file'
   string.

   The second section maps hardware addresstype/address into an
   ipaddress. Optionally you can also overide the default generic name
   by supplying a ipaddress specific genericname.  A 'suffix' item is
   also an option; if supplied, any generic names specified by the
   client will be accessed by first appending 'suffix' to the 'pathname'


Croft & Gilmore                                                [Page 10]



RFC 951                                                   September 1985
Bootstrap Protocol


   appropriate to that generic name.  If that file is not found, then
   the plain 'pathname' will be tried.  This 'suffix' option allows a
   whole set of custom generics to be setup without a lot of effort.
   Below is shown the general format; fields are delimited by one or
   more spaces or tabs; trailing empty fields may be omitted; blank
   lines and lines beginning with '#' are ignored.

      # comment line

      homedirectory
      genericname1    pathname1
      genericname2    pathname2
      ...

      % end of generic names, start of address mappings

      hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
      hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
      ...

   Here is a specific example.  Note the 'hardwaretype' number is the
   same as that shown in the ARP section of the 'Assigned Numbers' RFC.
   The 'hardwaretype' and 'ipaddr' numbers are in decimal;
   'hardwareaddr' is in hex.

      # last updated by smith

      /usr/boot
      vmunix          vmunix
      tip             ethertip
      watch           /usr/diag/etherwatch
      gate            gate.

      % end of generic names, start of address mappings

      hamilton        1 02.60.8c.06.34.98     36.19.0.5
      burr            1 02.60.8c.34.11.78     36.44.0.12
      101-gateway     1 02.60.8c.23.ab.35     36.44.0.32      gate 101
      mjh-gateway     1 02.60.8c.12.32.bc     36.42.0.64      gate mjh
      welch-tipa      1 02.60.8c.22.65.32     36.47.0.14      tip
      welch-tipb      1 02.60.8c.12.15.c8     36.46.0.12      tip

   In the example above, if 'mjh-gateway' does a default boot, it will
   get the file '/usr/boot/gate.mjh'.





Croft & Gilmore                                                [Page 11]



RFC 951                                                   September 1985
Bootstrap Protocol


10. Acknowledgements

   Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP
   bootstraping [2] using RARP [1].

   We would also like to acknowledge the previous work and comments of
   Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer.

REFERENCES

   1.  Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer.  A
       Reverse Address Resolution Protocol.  RFC 903, NIC, June, 1984.

   2.  Ross Finlayson.  Bootstrap Loading using TFTP.  RFC 906, NIC,
       June, 1984.

   3.  Mark Lottor.  Simple File Transfer Protocol.  RFC 913, NIC,
       September, 1984.

   4.  Jeffrey Mogul.  Broadcasting Internet Packets.  RFC 919, NIC,
       October, 1984.

   5.  David Plummer.  An Ethernet Address Resolution Protocol.  RFC
       826, NIC, September, 1982.

   6.  Jon Postel.  File Transfer Protocol.  RFC 765, NIC, June, 1980.

   7.  Jon Postel.  User Datagram Protocol.  RFC 768, NIC, August, 1980.

   8.  Jon Postel.  Internet Protocol.  RFC 791, NIC, September, 1981.

   9.  K. R. Sollins, Noel Chiappa.  The TFTP Protocol.  RFC 783, NIC,
       June, 1981.
















Croft & Gilmore                                                [Page 12]