rfc1084.txt

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

Network Working Group                                       J. Reynolds
Request for Comments: 1084                                          ISI
Obsoletes: 1048                                           December 1988


                  BOOTP Vendor Information Extensions


Status of this Memo

   This memo describes an addition to the Bootstrap Protocol (BOOTP).
   Comments and suggestions for improvements are sought.  Distribution
   of this memo is unlimited.

Introduction

   This RFC is a slight revision and extension of RFC-1048 by Philip
   Prindeville, who should be credited with the original work in this
   memo.  This memo will be updated as additional tags are are defined.
   This edition introduces Tag 13 for Boot File Size.

   As workstations and personal computers proliferate on the Internet,
   the administrative complexity of maintaining a network is increased
   by an order of magnitude.  The assignment of local network resources
   to each client represents one such difficulty.  In most environments,
   delegating such responsibility to the user is not plausible and,
   indeed, the solution is to define the resources in uniform terms, and
   to automate their assignment.

   The basic Bootstrap Protocol [RFC-951] dealt with the issue of
   assigning an internet address to a client, as well as a few other
   resources.  The protocol included provisions for vendor-defined
   resource information.

   This memo defines a (potentially) vendor-independent interpretation
   of this resource information.

Overview of BOOTP

   While the Reverse Address Resolution (RARP) Protocol [RFC-903] may be
   used to assign an IP address to a local network hardware address, it
   provides only part of the functionality needed.  Though this protocol
   can be used in conjunction with other supplemental protocols (the
   Resource Location Protocol [RFC-887], the Domain Name System [RFC-
   1034]), a more integrated solution may be desirable.

   Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol that allows a
   booting host to configure itself dynamically, and more significantly,



Reynolds                                                        [Page 1]

RFC 1084                    BOOTP Extensions               December 1988


   without user supervision.  It provides a means to assign a host its
   IP address, a file from which to download a boot program from some
   server, that server's address, and (if present) the address of an
   Internet gateway.

   One obvious advantage of this procedure is the centralized management
   of network addresses, which eliminates the need for per-host unique
   configuration files.  In an environment with several hundred hosts,
   maintaining local configuration information and operating system
   versions specific to each host might otherwise become chaotic.  By
   categorizing hosts into classes and maintaining configuration
   information and boot programs for each class, the complexity of this
   chore may be reduced in magnitude.

BOOTP Vendor Information Format

   The full description of the BOOTP request/reply packet format may be
   found in [RFC-951].  The rest of this document will concern itself
   with the last field of the packet, a 64 octet area reserved for
   vendor information, to be used in a hitherto unspecified fashion.  A
   generalized use of this area for giving information useful to a wide
   class of machines, operating systems, and configurations follows.  In
   situations where a single BOOTP server is to be used among
   heterogeneous clients in a single site, a generic class of data may
   be used.

   Vendor Information "Magic Cookie"

      As suggested in [RFC-951], the first four bytes of this field have
      been assigned to the magic cookie, which identifies the mode in
      which the succeeding data is to be interpreted.  The value of the
      magic cookie is the 4 octet dotted decimal 99.130.83.99 (or
      hexadecimal number 63.82.53.63) in network byte order.

   Format of Individual Fields

      The vendor information field has been implemented as a free
      format, with extendable tagged sub-fields.  These sub-fields are
      length tagged (with exceptions; see below), allowing clients not
      implementing certain types to correctly skip fields they cannot
      interpret.  Lengths are exclusive of the tag and length octets;
      all multi-byte quantities are in network byte-order.

      Fixed Length Data

         The fixed length data are comprised of two formats.  Those that
         have no data consist of a single tag octet and are implicitly
         of one-octet length, while those that contain data consist of



Reynolds                                                        [Page 2]

RFC 1084                    BOOTP Extensions               December 1988


         one tag octet, one length octet, and length octets of data.

         Pad Field (Tag: 0, Data: None)

            May be used to align subsequent fields to word boundaries
            required by the target machine (i.e., 32-bit quantities such
            as IP addresses on 32-bit boundaries).

         Subnet Mask Field (Tag: 1, Data: 4 subnet mask bytes)

            Specifies the net and local subnet mask as per the standard
            on subnetting [RFC-950].  For convenience, this field must
            precede the GATEWAY field (below), if present.

         Time Offset Field (Tag: 2, Data: 4 time offset bytes)

            Specifies the time offset of the local subnet in seconds
            from Coordinated Universal Time (UTC); signed 32-bit
            integer.

         End Field (Tag: 255, Data: None)

            Specifies end of usable data in the vendor information area.
            The rest of this field should be filled with PAD zero)
            octets.

      Variable Length Data

         The variable length data has a single format; it consists of
         one tag octet, one length octet, and length octets of data.

         Gateway Field (Tag: 3, Data: N address bytes)

            Specifies the IP addresses of N/4 gateways for this subnet.
            If one of many gateways is preferred, that should be first.

         Time Server Field (Tag: 4, Data: N address bytes)

            Specifies the IP addresses of N/4 time servers [RFC-868].

         IEN-116 Name Server Field (Tag: 5, Data: N address bytes)

            Specifies the IP addresses of N/4 name servers [IEN-116].

         Domain Name Server Field (Tag: 6, Data: N address bytes)

            Specifies the IP addresses of N/4 domain name servers RFC-
            1034].



Reynolds                                                        [Page 3]

RFC 1084                    BOOTP Extensions               December 1988


         Log Server Field (Tag: 7, Data: N address bytes)

            Specifies the IP addresses of N/4 MIT-LCS UDP log server
            [LOGGING].

         Cookie/Quote Server Field (Tag: 8, Data: N address bytes)

            Specifies the IP addresses of N/4 Quote of the Day servers
            [RFC-865].

         LPR Server Field (Tag: 9, Data: N address bytes)

            Specifies the IP addresses of N/4 Berkeley 4BSD printer
            servers [LPD].

         Impress Server Field (Tag: 10, Data: N address bytes)

            Specifies the IP addresses of N/4 Impress network image
            servers [IMAGEN].

         RLP Server Field (Tag: 11, Data: N address bytes)

            Specifies the IP addresses of N/4 Resource Location Protocol
            (RLP) servers [RFC-887].

         Hostname (Tag: 12, Data: N bytes of hostname)

            Specifies the name of the client. The name may or may not
            domain qualified: this is a site-specific issue.

         Boot File Size (Tag: 13, Data: 2)

            A two octet value (in network order) specifying the number
            of 512 octet blocks in the default boot file.  Informs BOOTP
            client how large the BOOTP file image is.

         Reserved Fields (Tag: 128-254, Data: N bytes of undefined
         content)

            Specifies additional site-specific information, to be
            interpreted on an implementation-specific basis.  This
            should follow all data with the preceding generic tags 0-
            127).








Reynolds                                                        [Page 4]