home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1497.txt < prev    next >
Text File  |  1994-05-29  |  17KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       J. Reynolds
  8. Request for Comments: 1497                                          ISI
  9. Obsoletes: 1395, 1084, 1048                                 August 1993
  10. Updates: 951
  11.  
  12.  
  13.                   BOOTP Vendor Information Extensions
  14.  
  15. Status of this Memo
  16.  
  17.    This memo is a status report on the vendor information extensions
  18.    used in the Bootstrap Protocol (BOOTP).  Distribution of this memo is
  19.    unlimited.
  20.  
  21. Introduction
  22.  
  23.    This RFC is a slight revision and extension of RFC-1048 by Philip
  24.    Prindeville, who should be credited with the original work in this
  25.    memo.  This memo will be updated as additional tags are are defined.
  26.    This edition introduces Tag 18 for Extension Path.
  27.  
  28.    As workstations and personal computers proliferate on the Internet,
  29.    the administrative complexity of maintaining a network is increased
  30.    by an order of magnitude.  The assignment of local network resources
  31.    to each client represents one such difficulty.  In most environments,
  32.    delegating such responsibility to the user is not plausible and,
  33.    indeed, the solution is to define the resources in uniform terms, and
  34.    to automate their assignment.
  35.  
  36.    The basic Bootstrap Protocol [RFC-951] dealt with the issue of
  37.    assigning an internet address to a client, as well as a few other
  38.    resources.  The protocol included provisions for vendor-defined
  39.    resource information.
  40.  
  41.    This memo defines a (potentially) vendor-independent interpretation
  42.    of this resource information.
  43.  
  44. Overview of BOOTP
  45.  
  46.    While the Reverse Address Resolution (RARP) Protocol [RFC-903] may be
  47.    used to assign an IP address to a local network hardware address, it
  48.    provides only part of the functionality needed.  Though this protocol
  49.    can be used in conjunction with other supplemental protocols (the
  50.    Resource Location Protocol [RFC-887], the Domain Name System [RFC-
  51.    1034]), a more integrated solution may be desirable.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Reynolds                                                        [Page 1]
  59.  
  60. RFC 1497                    BOOTP Extensions                 August 1993
  61.  
  62.  
  63.    Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol that allows a
  64.    booting host to configure itself dynamically, and more significantly,
  65.    without user supervision.  It provides a means to assign a host its
  66.    IP address, a file from which to download a boot program from some
  67.    server, that server's address, and (if present) the address of an
  68.    Internet gateway.
  69.  
  70.    One obvious advantage of this procedure is the centralized management
  71.    of network addresses, which eliminates the need for per-host unique
  72.    configuration files.  In an environment with several hundred hosts,
  73.    maintaining local configuration information and operating system
  74.    versions specific to each host might otherwise become chaotic.  By
  75.    categorizing hosts into classes and maintaining configuration
  76.    information and boot programs for each class, the complexity of this
  77.    chore may be reduced in magnitude.
  78.  
  79. BOOTP Vendor Information Format
  80.  
  81.    The full description of the BOOTP request/reply packet format may be
  82.    found in [RFC-951].  The rest of this document will concern itself
  83.    with the last field of the packet, a 64 octet area reserved for
  84.    vendor information, to be used in a hitherto unspecified fashion.  A
  85.    generalized use of this area for giving information useful to a wide
  86.    class of machines, operating systems, and configurations follows.  In
  87.    situations where a single BOOTP server is to be used among
  88.    heterogeneous clients in a single site, a generic class of data may
  89.    be used.
  90.  
  91.    Vendor Information "Magic Cookie"
  92.  
  93.       As suggested in [RFC-951], the first four bytes of this field have
  94.       been assigned to the magic cookie, which identifies the mode in
  95.       which the succeeding data is to be interpreted.  The value of the
  96.       magic cookie is the 4 octet dotted decimal 99.130.83.99 (or
  97.       hexadecimal number 63.82.53.63) in network byte order.
  98.  
  99.    Format of Individual Fields
  100.  
  101.       The vendor information field has been implemented as a free
  102.       format, with extendable tagged sub-fields.  These sub-fields are
  103.       length tagged (with exceptions; see below), allowing clients not
  104.       implementing certain types to correctly skip fields they cannot
  105.       interpret.  Lengths are exclusive of the tag and length octets;
  106.       all multi-byte quantities are in network byte-order.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Reynolds                                                        [Page 2]
  115.  
  116. RFC 1497                    BOOTP Extensions                 August 1993
  117.  
  118.  
  119.       Fixed Length Data
  120.  
  121.          The fixed length data are comprised of two formats.  Those that
  122.          have no data consist of a single tag octet and are implicitly
  123.          of one-octet length, while those that contain data consist of
  124.          one tag octet, one length octet, and length octets of data.
  125.  
  126.          Pad Field (Tag: 0, Data: None)
  127.  
  128.             May be used to align subsequent fields to word boundaries
  129.             required by the target machine (i.e., 32-bit quantities such
  130.             as IP addresses on 32-bit boundaries).
  131.  
  132.          Subnet Mask Field (Tag: 1, Data: 4 subnet mask bytes)
  133.  
  134.             Specifies the net and local subnet mask as per the standard
  135.             on subnetting [RFC-950].  For convenience, this field must
  136.             precede the GATEWAY field (below), if present.
  137.  
  138.          Time Offset Field (Tag: 2, Data: 4 time offset bytes)
  139.  
  140.             Specifies the time offset of the local subnet in seconds
  141.             from Coordinated Universal Time (UTC); signed 32-bit
  142.             integer.
  143.  
  144.          End Field (Tag: 255, Data: None)
  145.  
  146.             Specifies end of usable data in the vendor information area.
  147.             The rest of this field should be filled with PAD zero)
  148.             octets.
  149.  
  150.       Variable Length Data
  151.  
  152.          The variable length data has a single format; it consists of
  153.          one tag octet, one length octet, and length octets of data.
  154.  
  155.          Gateway Field (Tag: 3, Data: N address bytes)
  156.  
  157.             Specifies the IP addresses of N/4 gateways for this subnet.
  158.             If one of many gateways is preferred, that should be first.
  159.  
  160.          Time Server Field (Tag: 4, Data: N address bytes)
  161.  
  162.             Specifies the IP addresses of N/4 time servers [RFC-868].
  163.  
  164.          IEN-116 Name Server Field (Tag: 5, Data: N address bytes)
  165.  
  166.             Specifies the IP addresses of N/4 name servers [IEN-116].
  167.  
  168.  
  169.  
  170. Reynolds                                                        [Page 3]
  171.  
  172. RFC 1497                    BOOTP Extensions                 August 1993
  173.  
  174.  
  175.          Domain Name Server Field (Tag: 6, Data: N address bytes)
  176.  
  177.             Specifies the IP addresses of N/4 domain name servers RFC-
  178.             1034].
  179.  
  180.          Log Server Field (Tag: 7, Data: N address bytes)
  181.  
  182.             Specifies the IP addresses of N/4 MIT-LCS UDP log server
  183.             [LOGGING].
  184.  
  185.          Cookie/Quote Server Field (Tag: 8, Data: N address bytes)
  186.  
  187.             Specifies the IP addresses of N/4 Quote of the Day servers
  188.             [RFC-865].
  189.  
  190.          LPR Server Field (Tag: 9, Data: N address bytes)
  191.  
  192.             Specifies the IP addresses of N/4 Berkeley 4BSD printer
  193.             servers [LPD].
  194.  
  195.          Impress Server Field (Tag: 10, Data: N address bytes)
  196.  
  197.             Specifies the IP addresses of N/4 Impress network image
  198.             servers [IMAGEN].
  199.  
  200.          RLP Server Field (Tag: 11, Data: N address bytes)
  201.  
  202.             Specifies the IP addresses of N/4 Resource Location Protocol
  203.             (RLP) servers [RFC-887].
  204.  
  205.          Hostname (Tag: 12, Data: N bytes of hostname)
  206.  
  207.             Specifies the name of the client. The name may or may not
  208.             domain qualified: this is a site-specific issue.
  209.  
  210.          Boot File Size (Tag: 13, Data: 2)
  211.  
  212.             A two octet value (in network order) specifying the number
  213.             of 512 octet blocks in the default boot file.  Informs BOOTP
  214.             client how large the BOOTP file image is.
  215.  
  216.          Merit Dump File (Tag: 14, Data: N bytes of filename)
  217.  
  218.             Name of a file to dump core of this client to.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Reynolds                                                        [Page 4]
  227.  
  228. RFC 1497                    BOOTP Extensions                 August 1993
  229.  
  230.  
  231.          Domain Name  (Tag: 15, Data: N bytes of domain name)
  232.  
  233.             Specifies the domain name of the client for Domain Name
  234.             Server (DNS) resolution [RFC-1034].
  235.  
  236.          Swap Server (Tag: 16, Data: 4 address bytes)
  237.  
  238.             An IP address to hold the IP address of a swap server.
  239.  
  240.          Root Path  (Tag: 17, Data: N bytes of path name)
  241.  
  242.             A string to specify a pathname to mount as a root disk.
  243.  
  244.          Extensions Path  (Tag: 18, Data: N bytes of path name)
  245.  
  246.             A string to specify a file, retrievable via TFTP, which
  247.             contains information which can be interpreted in the same
  248.             way as the 64-octet vendor-extension field within the BOOTP
  249.             response, with the following exceptions:
  250.  
  251.                    - the length of the file is unconstrained;
  252.                    - all references to Tag 18 (i.e., instances of the
  253.                      BOOTP Extensions Path field) within the file are
  254.                      ignored.
  255.  
  256.          Reserved Fields (Tag: 128-254, Data: N bytes of undefined
  257.          content)
  258.  
  259.             Specifies additional site-specific information, to be
  260.             interpreted on an implementation-specific basis.  This
  261.             should follow all data with the preceding generic tags 0-
  262.             127).
  263.  
  264. Extensions
  265.  
  266.    Additional generic data fields may be registered by contacting:
  267.  
  268.           Internet Assigned Numbers Authority (IANA)
  269.           Information Sciences Institute
  270.           University of Southern California
  271.           4676 Admiralty Way
  272.           Marina del Rey, California  90292-6695
  273.  
  274.           or by email as: iana@isi.edu
  275.  
  276.    Implementation specific use of undefined generic types (those in the
  277.    range 19-127) may conflict with other implementations, and
  278.    registration is required.
  279.  
  280.  
  281.  
  282. Reynolds                                                        [Page 5]
  283.  
  284. RFC 1497                    BOOTP Extensions                 August 1993
  285.  
  286.  
  287.    When selecting information to put into the vendor specific area, care
  288.    should be taken to not exceed the 64 byte length restriction.
  289.    Nonessential information (such as host name and quote of the day
  290.    server) may be excluded, which may later be located with a more
  291.    appropriate service protocol, such as RLP or the WKS resource-type of
  292.    the domain name system.  Indeed, even RLP servers may be discovered
  293.    using a broadcast request to locate a local RLP server.
  294.  
  295. Comparison to Alternative Approaches
  296.  
  297.    Extending BOOTP to provide more configuration information than the
  298.    minimum required by boot PROMs may not be necessary.  Rather than
  299.    having each module in a host (e.g., the time module, the print
  300.    spooler, the domain name resolver) broadcast to the BOOTP server to
  301.    obtain the addresses of required servers, it would be better for each
  302.    of them to multicast directly to the particular server group of
  303.    interest, possibly using "expanding ring" multicasts.
  304.  
  305.    The multicast approach has the following advantages over the BOOTP
  306.    approach:
  307.  
  308.     - It eliminates dependency on a third party (the BOOTP server) that
  309.     may be temporarily unavailable or whose database may be incorrect or
  310.     incomplete.  Multicasting directly to the desired services will
  311.     locate those servers that are currently available, and only those.
  312.  
  313.     - It reduces the administrative chore of keeping the (probably
  314.     replicated) BOOTP database up-to-date and consistent.  This is
  315.     especially important in an environment with a growing number of
  316.     services and an evolving population of servers.
  317.  
  318.     - In some cases, it reduces the amount of packet traffic and/or the
  319.     delay required to get the desired information.  For example, the
  320.     current time can be obtained by a single multicast to a time server
  321.     group which evokes replies from those time servers that are
  322.     currently up.  The BOOTP approach would require a broadcast to the
  323.     BOOTP server, a reply from the BOOTP server, one or more unicasts to
  324.     time servers (perhaps waiting for long timeouts if the initially
  325.     chosen server(s) are down), and finally a reply from a server.
  326.  
  327.    One apparent advantage of the proposed BOOTP extensions is that they
  328.    provide a uniform way to locate servers.  However, the multicast
  329.    approach could also be implemented in a consistent way across
  330.    multiple services.  The V System naming protocol is a good example of
  331.    this; character string pathnames are used to name any number of
  332.    resources (i.e., not just files) and a standard subroutine library
  333.    looks after multicasting to locate the resources, caching the
  334.    discovered locations, and detecting stale cache data.
  335.  
  336.  
  337.  
  338. Reynolds                                                        [Page 6]
  339.  
  340. RFC 1497                    BOOTP Extensions                 August 1993
  341.  
  342.  
  343.    Another apparent advantage of the BOOTP approach is that it allows an
  344.    administrator to easily control which hosts use which servers.  The
  345.    multicast approach favors more distributed control over resource
  346.    allocation, where each server decides which hosts it will serve,
  347.    using whatever level of authentication is appropriate for the
  348.    particular service.  For example, time servers usually don't care who
  349.    they serve (i.e., administrative control via the BOOTP database is
  350.    unnecessary), whereas file servers usually require strong
  351.    authentication (i.e., administrative control via the BOOTP database
  352.    is insufficient).
  353.  
  354.    The main drawback of the multicast approach, of course, is that IP
  355.    multicasting is not widely implemented, and there is a need to locate
  356.    existing services which do not understand IP multicasts.
  357.  
  358.    The BOOTP approach may be most efficient in the case that all the
  359.    information needed by the client host is returned by a single BOOTP
  360.    reply and each program module simply reads the information it needs
  361.    from a local table filled in by the BOOTP reply.
  362.  
  363. Acknowledgments
  364.  
  365.    The following people provided helpful comments on the first edition
  366.    of this memo: Drew Perkins, of Carnagie Mellon University, Bill
  367.    Croft, of Stanford University, and co-author of BOOTP, and Steve
  368.    Deering, also of Stanford University, for contributing the
  369.    "Comparison to Alternative Approaches" section.
  370.  
  371. References
  372.  
  373.    [RFC-951]   Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)",
  374.                RFC 951, Stanford and SUN Microsystems, September 1985.
  375.  
  376.    [RFC-903]   Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
  377.                Reverse Address Resolution Protocol", STD 38, RFC 903,
  378.                Stanford, June 1984.
  379.  
  380.    [RFC-887]   Accetta, M., "Resource Location Protocol", RFC 887, CMU,
  381.                December 1983.
  382.  
  383.    [RFC-1034]  Mockapetris, P., "Domain Names - Concepts and
  384.                Facilities", STD 13, RFC 1034, USC/Information Sciences
  385.                Institute, November 1987.
  386.  
  387.    [RFC-950]   Mogul, J., and J. Postel, "Internet Standard Subnetting
  388.                Procedure", STD 5, RFC 950, USC/Information Sciences
  389.                Institute, August 1985.
  390.  
  391.  
  392.  
  393.  
  394. Reynolds                                                        [Page 7]
  395.  
  396. RFC 1497                    BOOTP Extensions                 August 1993
  397.  
  398.  
  399.    [RFC-868]   Postel, J., "Time Protocol", STD 26, RFC 868,
  400.                USC/Information Sciences Institute, May 1983.
  401.  
  402.    [IEN-116]   Postel, J., "Internet Name Server", USC/Information
  403.                Sciences Institute, August 1979.
  404.  
  405.    [LOGGING]   Clark, D., "Logging and Status Protocol", Massachusetts
  406.                Institute of Technology Laboratory for Computer Science,
  407.                Cambridge, Massachusetts, 1981.
  408.  
  409.    [RFC-865]   Postel, J., "Quote of the Day Protocol", STD 23, RFC 865,
  410.                USC/Information Sciences Institute, May 1983.
  411.  
  412.    [LPD]       Campbell, R., "4.2BSD Line Printer Spooler Manual", UNIX
  413.                Programmer's Manual, Vol II,  University of California at
  414.                Berkeley, Computer Science Division, July 1983.
  415.  
  416.    [IMAGEN]    "Image Server XT Programmer's Guide", Imagen Corporation,
  417.                Santa Clara, California, August 1986.
  418.  
  419. Security Considerations
  420.  
  421.    Security issues are not discussed in this memo.
  422.  
  423. Author's Address:
  424.  
  425.    Joyce K. Reynolds
  426.    Information Sciences Institute
  427.    University of Southern California
  428.    4676 Admiralty Way
  429.    Marina del Rey, CA 90292
  430.  
  431.    Phone:  (310) 822-1511
  432.  
  433.    EMail: jkrey@isi.edu
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Reynolds                                                        [Page 8]
  451.  
  452.