BOOTP Vendor Information Extensions
RFC 1497
Document | Type |
RFC - Draft Standard
(August 1993; No errata)
Obsoleted by RFC 1533
Updates RFC 951
|
|
---|---|---|---|
Author | Joyce Reynolds | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1497 (Draft Standard) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 boundariesShow full document text