summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1497.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1497.txt')
-rw-r--r--doc/rfc/rfc1497.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1497.txt b/doc/rfc/rfc1497.txt
new file mode 100644
index 0000000..16749c2
--- /dev/null
+++ b/doc/rfc/rfc1497.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group J. Reynolds
+Request for Comments: 1497 ISI
+Obsoletes: 1395, 1084, 1048 August 1993
+Updates: 951
+
+
+ BOOTP Vendor Information Extensions
+
+Status of this Memo
+
+ This memo is a status report on the vendor information extensions
+ used in the Bootstrap Protocol (BOOTP). 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 18 for Extension Path.
+
+ 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.
+
+
+
+
+
+
+Reynolds [Page 1]
+
+RFC 1497 BOOTP Extensions August 1993
+
+
+ Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol that allows a
+ booting host to configure itself dynamically, and more significantly,
+ 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.
+
+
+
+
+
+
+
+Reynolds [Page 2]
+
+RFC 1497 BOOTP Extensions August 1993
+
+
+ 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
+ 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].
+
+
+
+Reynolds [Page 3]
+
+RFC 1497 BOOTP Extensions August 1993
+
+
+ Domain Name Server Field (Tag: 6, Data: N address bytes)
+
+ Specifies the IP addresses of N/4 domain name servers RFC-
+ 1034].
+
+ 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.
+
+ Merit Dump File (Tag: 14, Data: N bytes of filename)
+
+ Name of a file to dump core of this client to.
+
+
+
+
+
+
+
+Reynolds [Page 4]
+
+RFC 1497 BOOTP Extensions August 1993
+
+
+ Domain Name (Tag: 15, Data: N bytes of domain name)
+
+ Specifies the domain name of the client for Domain Name
+ Server (DNS) resolution [RFC-1034].
+
+ Swap Server (Tag: 16, Data: 4 address bytes)
+
+ An IP address to hold the IP address of a swap server.
+
+ Root Path (Tag: 17, Data: N bytes of path name)
+
+ A string to specify a pathname to mount as a root disk.
+
+ Extensions Path (Tag: 18, Data: N bytes of path name)
+
+ A string to specify a file, retrievable via TFTP, which
+ contains information which can be interpreted in the same
+ way as the 64-octet vendor-extension field within the BOOTP
+ response, with the following exceptions:
+
+ - the length of the file is unconstrained;
+ - all references to Tag 18 (i.e., instances of the
+ BOOTP Extensions Path field) within the file are
+ ignored.
+
+ 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).
+
+Extensions
+
+ Additional generic data fields may be registered by contacting:
+
+ Internet Assigned Numbers Authority (IANA)
+ Information Sciences Institute
+ University of Southern California
+ 4676 Admiralty Way
+ Marina del Rey, California 90292-6695
+
+ or by email as: iana@isi.edu
+
+ Implementation specific use of undefined generic types (those in the
+ range 19-127) may conflict with other implementations, and
+ registration is required.
+
+
+
+Reynolds [Page 5]
+
+RFC 1497 BOOTP Extensions August 1993
+
+
+ When selecting information to put into the vendor specific area, care
+ should be taken to not exceed the 64 byte length restriction.
+ Nonessential information (such as host name and quote of the day
+ server) may be excluded, which may later be located with a more
+ appropriate service protocol, such as RLP or the WKS resource-type of
+ the domain name system. Indeed, even RLP servers may be discovered
+ using a broadcast request to locate a local RLP server.
+
+Comparison to Alternative Approaches
+
+ Extending BOOTP to provide more configuration information than the
+ minimum required by boot PROMs may not be necessary. Rather than
+ having each module in a host (e.g., the time module, the print
+ spooler, the domain name resolver) broadcast to the BOOTP server to
+ obtain the addresses of required servers, it would be better for each
+ of them to multicast directly to the particular server group of
+ interest, possibly using "expanding ring" multicasts.
+
+ The multicast approach has the following advantages over the BOOTP
+ approach:
+
+ - It eliminates dependency on a third party (the BOOTP server) that
+ may be temporarily unavailable or whose database may be incorrect or
+ incomplete. Multicasting directly to the desired services will
+ locate those servers that are currently available, and only those.
+
+ - It reduces the administrative chore of keeping the (probably
+ replicated) BOOTP database up-to-date and consistent. This is
+ especially important in an environment with a growing number of
+ services and an evolving population of servers.
+
+ - In some cases, it reduces the amount of packet traffic and/or the
+ delay required to get the desired information. For example, the
+ current time can be obtained by a single multicast to a time server
+ group which evokes replies from those time servers that are
+ currently up. The BOOTP approach would require a broadcast to the
+ BOOTP server, a reply from the BOOTP server, one or more unicasts to
+ time servers (perhaps waiting for long timeouts if the initially
+ chosen server(s) are down), and finally a reply from a server.
+
+ One apparent advantage of the proposed BOOTP extensions is that they
+ provide a uniform way to locate servers. However, the multicast
+ approach could also be implemented in a consistent way across
+ multiple services. The V System naming protocol is a good example of
+ this; character string pathnames are used to name any number of
+ resources (i.e., not just files) and a standard subroutine library
+ looks after multicasting to locate the resources, caching the
+ discovered locations, and detecting stale cache data.
+
+
+
+Reynolds [Page 6]
+
+RFC 1497 BOOTP Extensions August 1993
+
+
+ Another apparent advantage of the BOOTP approach is that it allows an
+ administrator to easily control which hosts use which servers. The
+ multicast approach favors more distributed control over resource
+ allocation, where each server decides which hosts it will serve,
+ using whatever level of authentication is appropriate for the
+ particular service. For example, time servers usually don't care who
+ they serve (i.e., administrative control via the BOOTP database is
+ unnecessary), whereas file servers usually require strong
+ authentication (i.e., administrative control via the BOOTP database
+ is insufficient).
+
+ The main drawback of the multicast approach, of course, is that IP
+ multicasting is not widely implemented, and there is a need to locate
+ existing services which do not understand IP multicasts.
+
+ The BOOTP approach may be most efficient in the case that all the
+ information needed by the client host is returned by a single BOOTP
+ reply and each program module simply reads the information it needs
+ from a local table filled in by the BOOTP reply.
+
+Acknowledgments
+
+ The following people provided helpful comments on the first edition
+ of this memo: Drew Perkins, of Carnagie Mellon University, Bill
+ Croft, of Stanford University, and co-author of BOOTP, and Steve
+ Deering, also of Stanford University, for contributing the
+ "Comparison to Alternative Approaches" section.
+
+References
+
+ [RFC-951] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)",
+ RFC 951, Stanford and SUN Microsystems, September 1985.
+
+ [RFC-903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
+ Reverse Address Resolution Protocol", STD 38, RFC 903,
+ Stanford, June 1984.
+
+ [RFC-887] Accetta, M., "Resource Location Protocol", RFC 887, CMU,
+ December 1983.
+
+ [RFC-1034] Mockapetris, P., "Domain Names - Concepts and
+ Facilities", STD 13, RFC 1034, USC/Information Sciences
+ Institute, November 1987.
+
+ [RFC-950] Mogul, J., and J. Postel, "Internet Standard Subnetting
+ Procedure", STD 5, RFC 950, USC/Information Sciences
+ Institute, August 1985.
+
+
+
+
+Reynolds [Page 7]
+
+RFC 1497 BOOTP Extensions August 1993
+
+
+ [RFC-868] Postel, J., "Time Protocol", STD 26, RFC 868,
+ USC/Information Sciences Institute, May 1983.
+
+ [IEN-116] Postel, J., "Internet Name Server", USC/Information
+ Sciences Institute, August 1979.
+
+ [LOGGING] Clark, D., "Logging and Status Protocol", Massachusetts
+ Institute of Technology Laboratory for Computer Science,
+ Cambridge, Massachusetts, 1981.
+
+ [RFC-865] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865,
+ USC/Information Sciences Institute, May 1983.
+
+ [LPD] Campbell, R., "4.2BSD Line Printer Spooler Manual", UNIX
+ Programmer's Manual, Vol II, University of California at
+ Berkeley, Computer Science Division, July 1983.
+
+ [IMAGEN] "Image Server XT Programmer's Guide", Imagen Corporation,
+ Santa Clara, California, August 1986.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address:
+
+ Joyce K. Reynolds
+ Information Sciences Institute
+ University of Southern California
+ 4676 Admiralty Way
+ Marina del Rey, CA 90292
+
+ Phone: (310) 822-1511
+
+ EMail: jkrey@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reynolds [Page 8]
+ \ No newline at end of file