BOOTP vendor information extensions
RFC 1048
|
Document |
Type |
|
RFC - Unknown
(February 1988; No errata)
|
|
Author |
|
Philip Prindeville
|
|
Last updated |
|
2018-08-22
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1048 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group P. Prindeville
Request for Comments: 1048 McGill University
February 1988
BOOTP Vendor Information Extensions
Status of this Memo
This memo proposes an addition to the Bootstrap Protocol (BOOTP).
Comments and suggestions for improvements are sought. Distribution
of this memo is unlimited.
Introduction
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-
883]), 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,
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.
Prindeville [Page 1]
RFC 1048 BOOTP Extensions February 1988
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
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
Prindeville [Page 2]
RFC 1048 BOOTP Extensions February 1988
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
Show full document text