As per Relevance of the word resource, we have this rfc below:
Network Working Group P.
Request for Comments: 1048 McGill
February 1988
BOOTP Vendor Information
Status of this
This memo proposes an addition to the Bootstrap Protocol (BOOTP).
Comments and suggestions for improvements are sought.
of this memo is unlimited
As workstations and personal computers proliferate on the Internet
the administrative complexity of maintaining a network is
by an order of magnitude. The assignment of local network
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,
to automate their assignment
The basic Bootstrap Protocol [RFC-951] dealt with the issue
assigning an internet address to a client, as well as a few
resources. The protocol included provisions for vendor-
resource information
This memo defines a (potentially) vendor-independent
of this resource information
Overview of
While the Reverse Address Resolution (RARP) Protocol [RFC-903] may
used to assign an IP address to a local network hardware address,
provides only part of the functionality needed. Though this
can be used in conjunction with other supplemental protocols (
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
booting host to configure itself dynamically, and more significantly
without user supervision. It provides a means to assign a host
IP address, a file from which to download a boot program from
server, that server's address, and (if present) the address of
Internet gateway
Prindeville [Page 1]
RFC 1048 BOOTP Extensions February 1988
One obvious advantage of this procedure is the centralized
of network addresses, which eliminates the need for per-host
configuration files. In an environment with several hundred hosts
maintaining local configuration information and operating
versions specific to each host might otherwise become chaotic.
categorizing hosts into classes and maintaining
information and boot programs for each class, the complexity of
chore may be reduced in magnitude
BOOTP Vendor Information
The full description of the BOOTP request/reply packet format may
found in [RFC-951]. The rest of this document will concern
with the last field of the packet, a 64 octet area reserved
vendor information, to be used in a hitherto unspecified fashion.
generalized use of this area for giving information useful to a
class of machines, operating systems, and configurations follows.
situations where a single BOOTP server is to be used
heterogeneous clients in a single site, a generic class of data
be used
Vendor Information "Magic Cookie
As suggested in [RFC-951], the first four bytes of this field
been assigned to the magic cookie, which identifies the mode
which the succeeding data is to be interpreted. The value of
magic cookie is the 4 octet dotted decimal 99.130.83.99 (
hexadecimal number 63.82.53.63) in network byte order
Format of Individual
The vendor information field has been implemented as a
format, with extendable tagged sub-fields. These sub-fields
length tagged (with exceptions; see below), allowing clients
implementing certain types to correctly skip fields they
interpret. Lengths are exclusive of the tag and length octets
all multi-byte quantities are in network byte-order
Fixed Length
The fixed length data are comprised of two formats. Those
have no data consist of a single tag octet and are
of one-octet length, while those that contain data consist
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
Prindeville [Page 2]
RFC 1048 BOOTP Extensions February 1988
required by the target machine (i.e., 32-bit quantities
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
on subnetting [RFC-950]. For convenience, this field
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
from Coordinated Universal Time (UTC); signed 32-
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
The variable length data has a single format; it consists
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
883].
Log Server Field (Tag: 7, Data: N address bytes
Specifies the IP addresses of N/4 MIT-LCS UDP log
[LOGGING].
Prindeville [Page 3]
RFC 1048 BOOTP Extensions February 1988
Cookie/Quote Server Field (Tag: 8, Data: N address bytes
Specifies the IP addresses of N/4 Quote of the Day
[RFC-865].
LPR Server Field (Tag: 9, Data: N address bytes
Specifies the IP addresses of N/4 Berkeley 4BSD
servers [LPD].
Impress Server Field (Tag: 10, Data: N address bytes
Specifies the IP addresses of N/4 Impress network
servers [IMAGEN].
RLP Server Field (Tag: 11, Data: N address bytes
Specifies the IP addresses of N/4 Resource Location
(RLP) servers [RFC-887].
Hostname (Tag: 12, Data: N bytes of hostname
Specifies the name of the client. The name may or may
domain qualified: this is a site-specific issue
Reserved Fields (Tag: 128-254, Data: N bytes of
content
Specifies additional site-specific information, to
interpreted on an implementation-specific basis.
should follow all data with the preceding generic tags 0-
127).
Additional generic data fields may be registered by contacting
Joyce K.
USC - Information Sciences
4676 Admiralty
Marina del Rey, California 90292-6695
or by E-mail as: JKREYNOLDS@ISI.
(nic handle JKR1).
Implementation specific use of undefined generic types (those in
range 12-127) may conflict with other implementations,
registration is required
Prindeville [Page 4]
RFC 1048 BOOTP Extensions February 1988
When selecting information to put into the vendor specific area,
should be taken to not exceed the 64 byte length restriction
Nonessential information (such as host name and quote of the
server) may be excluded, which may later be located with a
appropriate service protocol, such as RLP or the WKS resource-type
the domain name system. Indeed, even RLP servers may be
using a broadcast request to locate a local RLP server
Comparison to Alternative
Extending BOOTP to provide more configuration information than
minimum required by boot PROMs may not be necessary. Rather
having each module in a host (e.g., the time module, the
spooler, the domain name resolver) broadcast to the BOOTP server
obtain the addresses of required servers, it would be better for
of them to multicast directly to the particular server group
interest, possibly using "expanding ring" multicasts
The multicast approach has the following advantages over the
approach
- It eliminates dependency on a third party (the BOOTP server)
may be temporarily unavailable or whose database may be incorrect
incomplete. Multicasting directly to the desired services
locate those servers that are currently available, and only those
- It reduces the administrative chore of keeping the (
replicated) BOOTP database up-to-date and consistent. This
especially important in an environment with a growing number
services and an evolving population of servers
- In some cases, it reduces the amount of packet traffic and/or
delay required to get the desired information. For example,
current time can be obtained by a single multicast to a time
group which evokes replies from those time servers that
currently up. The BOOTP approach would require a broadcast to
BOOTP server, a reply from the BOOTP server, one or more unicasts
time servers (perhaps waiting for long timeouts if the
chosen server(s) are down), and finally a reply from a server
One apparent advantage of the proposed BOOTP extensions is that
provide a uniform way to locate servers. However, the
approach could also be implemented in a consistent way
multiple services. The V System naming protocol is a good example
this; character string pathnames are used to name any number
resources (i.e., not just files) and a standard subroutine
looks after multicasting to locate the resources, caching
discovered locations, and detecting stale cache data
Prindeville [Page 5]
RFC 1048 BOOTP Extensions February 1988
Another apparent advantage of the BOOTP approach is that it allows
administrator to easily control which hosts use which servers.
multicast approach favors more distributed control over
allocation, where each server decides which hosts it will serve
using whatever level of authentication is appropriate for
particular service. For example, time servers usually don't care
they serve (i.e., administrative control via the BOOTP database
unnecessary), whereas file servers usually require
authentication (i.e., administrative control via the BOOTP
is insufficient).
The main drawback of the multicast approach, of course, is that
multicasting is not widely implemented, and there is a need to
existing services which do not understand IP multicasts
The BOOTP approach may be most efficient in the case that all
information needed by the client host is returned by a single
reply and each program module simply reads the information it
from a local table filled in by the BOOTP reply
I would like to thank the following persons for their
comments and insights into this memo: Drew Perkins, of
Mellon University, Bill Croft, of Stanford University, and co-
of BOOTP, and Steve Deering, also of Stanford University,
contributing the "Comparison to Alternative Approaches" section
[RFC-951] Croft, B., and J. Gilmore, "Bootstrap Protocol",
Information Center, SRI International, Menlo Park
California, September 1985.
[RFC-903] Finlayson, R., T. Mann, J. Mogul, and M. Theimer, "
Reverse Address Resolution Protocol", Network
Center, SRI International, Menlo Park, California,
1984.
[RFC-887] Accetta, M., "Resource Location Protocol",
Information Center, SRI International, Menlo Park
California, December 1983.
[RFC-883] Mockapetris, P., "Domain Name - Implementation
Specification", Network Information Center,
International, Menlo Park, California, November 1983.
[RFC-950] Mogul, J., "Internet Standard Subnetting Procedure",
Prindeville [Page 6]
RFC 1048 BOOTP Extensions February 1988
Network Information Center, SRI International,
Park, California, August 1985.
[RFC-868] Postel, J., "Time Protocol", Network Information Center
SRI International, Menlo Park, California, May 1983.
[IEN-116] Postel, J., "Internet Name Server", Network
Center, SRI International, Menlo Park, California,
1979.
[LOGGING] Clark, D., Logging and Status Protocol",
Institute of Technology Laboratory for Computer Science
Cambridge, Massachusetts, 1981.
[RFC-865] Postel, J., "Quote of the Day Protocol",
Information Center, SRI International, Menlo Park
California, May 1983.
[LPD] Campbell, R., "4.2BSD Line Printer Spooler Manual",
Programmer's Manual, Vol II, University of California
Berkeley, Computer Science Division, July 1983.
[IMAGEN] "Image Server XT Programmer's Guide", Imagen Corporation
Santa Clara, California, August 1986.
Prindeville [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
