RFC 1048

BOOTP Vendor Information Extensions 💖

bestie, this is RFC 1048 🎀 from the Network Working Group, written by P. Prindeville at McGill University, dated February 1988. It's a proposal: the memo says it proposes an addition to BOOTP and is literally asking for comments and suggestions for improvements 🫶. Distribution is unlimited. The title block doesn't list anything it obsoletes or updates, so no drama there 💅.

Status of this Memo 📜

okay so this memo proposes an addition to the Bootstrap Protocol (BOOTP) 🦋. Share your feedback, because comments and suggestions for improvements are exactly what it's looking for. Distribution of this memo is unlimited, so pass it around 💜.

Introduction 🌸

okay so as workstations and personal computers keep multiplying across the Internet, running a network gets so much more complicated, like by an order of magnitude 😭. Assigning local network resources to every single client is the big headache. In most places, handing that job to the user isn't realistic, so the move is to define the resources in uniform terms and automate their assignment ✨.

The basic Bootstrap Protocol [RFC-951] already handled giving a client an internet address, plus a few other resources 🧚. It also had room for vendor-defined resource information 🎀.

This memo defines a (potentially) vendor-independent interpretation of that 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 only covers part of what's needed 🥺. It can be paired with other supplemental protocols, like the Resource Location Protocol [RFC-887] and the Domain Name System [RFC-883], but a more integrated solution may be desirable 👑.

Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol that lets a booting host configure itself dynamically, and more importantly, without any user supervision 🤖. It gives a host its IP address, a file to download a boot program from on some server, that server's address, and (if present) the address of an Internet gateway 🚪.

The big win is centralized management of network addresses, so you don't need per-host unique configuration files 🙌. With several hundred hosts, keeping local config info and OS versions for each one would get chaotic 💀. Instead, you sort hosts into classes and keep configuration info and boot programs for each class, which cuts the complexity of that chore by a lot 🍓.

BOOTP Vendor Information Format 🎀

The full BOOTP request/reply packet format lives in [RFC-951], so that's the place to check. This doc is about the last field of the packet: a 64 octet area reserved for vendor information, which was never really specified before 🧩. It's about to get a generalized use for info that's useful across a wide class of machines, operating systems, and configurations. If a single BOOTP server has to serve mixed clients at one site, a generic class of data MAY be used 💖.

Vendor Information "Magic Cookie" 🍪

As [RFC-951] suggested, the first four bytes of this field are assigned to the magic cookie, which tells you how to read the data that comes after it. 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 is a free format with extendable tagged sub-fields. Each sub-field is length tagged (with exceptions, see below), so clients can skip right over the types they don't implement 🙈. Lengths don't count the tag and length octets, and all multi-byte quantities are in network byte order 💅.

Fixed Length Data

Fixed length data comes in two flavors 🦋. Some fields have no data and are just one tag octet, which means they're implicitly one octet long. The others have one tag octet, one length octet, and then length octets of data.

Pad Field (Tag: 0, Data: None)

This is for lining up later fields on the word boundaries the target machine needs 🧱. It 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)

This specifies the net and local subnet mask according to 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)

This gives the time offset of the local subnet in seconds from Coordinated Universal Time (UTC), as a signed 32-bit integer ⏰.

End Field (Tag: 255, Data: None)

This marks the end of usable data in the vendor information area 🛑. The rest of this field SHOULD be filled with zero-valued PAD octets.

Variable Length Data

Variable length data has a single format: one tag octet, one length octet, and length octets of data 📦.

Gateway Field (Tag: 3, Data: N address bytes)

This 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)

This specifies the IP addresses of N/4 time servers [RFC-868] ⏰.

IEN-116 Name Server Field (Tag: 5, Data: N address bytes)

This specifies the IP addresses of N/4 name servers [IEN-116].

Domain Name Server Field (Tag: 6, Data: N address bytes)

This specifies the IP addresses of N/4 domain name servers [RFC-883] 🌐.

Log Server Field (Tag: 7, Data: N address bytes)

This specifies the IP addresses of N/4 MIT-LCS UDP log servers [LOGGING] 📝.

Cookie/Quote Server Field (Tag: 8, Data: N address bytes)

This specifies the IP addresses of N/4 Quote of the Day servers [RFC-865] 🍪.

LPR Server Field (Tag: 9, Data: N address bytes)

This specifies the IP addresses of N/4 Berkeley 4BSD printer servers [LPD] 🖨️.

Impress Server Field (Tag: 10, Data: N address bytes)

This specifies the IP addresses of N/4 Impress network image servers [IMAGEN] 🖼️.

RLP Server Field (Tag: 11, Data: N address bytes)

This specifies the IP addresses of N/4 Resource Location Protocol (RLP) servers [RFC-887] 🧭.

Hostname (Tag: 12, Data: N bytes of hostname)

This specifies the name of the client. The name MAY or MAY not be domain qualified, and that's a site-specific issue 🌈.

Reserved Fields (Tag: 128-254, Data: N bytes of undefined content)

This specifies additional site-specific information, to be interpreted on an implementation-specific basis 🔮. It SHOULD follow all data with the preceding generic tags 0-127.

Acknowledgments 🫶

Okay bestie, huge thank yous to the people who helped make this memo happen! 💖 Drew Perkins, of Carnagie Mellon University, gave really helpful comments and insights into this memo. Bill Croft, of Stanford University, is a co-author of BOOTP and gets a big hug from me 🤗. And Steve Deering, also of Stanford University, contributed the "Comparison to Alternative Approaches" section, which is literally iconic 👑.

References 📚

Here's the reading list, babe. Every single source is listed with all its details so you can go find them yourself 🔍✨

• [RFC-951] Croft, B., and J. Gilmore, "Bootstrap Protocol", Network Information Center, SRI International, Menlo Park, California, September 1985.
• [RFC-903] Finlayson, R., T. Mann, J. Mogul, and M. Theimer, "A Reverse Address Resolution Protocol", Network Information Center, SRI International, Menlo Park, California, June 1984.
• [RFC-887] Accetta, M., "Resource Location Protocol", Network Information Center, SRI International, Menlo Park, California, December 1983.
• [RFC-883] Mockapetris, P., "Domain Name - Implementation and Specification", Network Information Center, SRI International, Menlo Park, California, November 1983.
• [RFC-950] Mogul, J., "Internet Standard Subnetting Procedure", Network Information Center, SRI International, Menlo 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 Information Center, SRI International, Menlo Park, California, 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", Network Information Center, SRI International, Menlo Park, California, 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.

That's the whole thing, bestie! 🦋 You made it through BOOTP end to end 💅