RFC 1084

BOOTP vendor information extensions

📅 published December 1988, from ietf

RFC 1084: BOOTP Vendor Information Extensions 🎀

  • Working group: Network Working Group 🌸
  • RFC: 1084
  • Title: BOOTP Vendor Information Extensions
  • Author: J. Reynolds, ISI
  • Date: December 1988
  • Obsoletes: 1048 (the older version this one replaces) 💅

Status of this Memo ✨

okay so this memo is basically an addition to the Bootstrap Protocol (BOOTP) 🦋. They're literally begging for comments and suggestions for improvements, so if you have thoughts, speak up bestie 🫶. Distribution of this memo is unlimited too, so share away 🌈.

Introduction 💖

This RFC is a slight revision and extension of RFC-1048, and the original work belongs to Philip Prindeville, so give him the credit 👑. This memo will be updated as more tags get defined, and this edition introduces Tag 13 for Boot File Size 🍓.

As workstations and personal computers take over the Internet, the admin complexity of running a network goes up by an order of magnitude 😭. Assigning local network resources to each client is one of those headaches. In most environments, handing that job to the user is not plausible 💀, so the move is to define 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 even had provisions for vendor-defined resource information 💜.

This memo defines a (potentially) vendor-independent way to read that resource information 👑.

Overview of BOOTP 🌈

Okay so the Reverse Address Resolution (RARP) Protocol [RFC-903] can assign an IP address to a local network hardware address, but ngl it only covers part of what you need 🥲. You can pair it with other supplemental protocols like the Resource Location Protocol [RFC-887] and the Domain Name System [RFC-1034], but a more integrated solution may be desirable ✨.

BOOTP is a UDP/IP-based protocol that lets a booting host configure itself dynamically 🤯. Even better, it does this 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 the address of an Internet gateway (if present) 🚪.

The obvious perk is centralized management of network addresses, which means no more per-host unique configuration files 🗂️. With several hundred hosts, keeping local configuration info and operating system versions specific to each host could get totally chaotic 😵. Sorting hosts into classes and keeping configuration info and boot programs for each class means the complexity of that chore may be reduced in magnitude 📉.

BOOTP Vendor Information Format 🎀

The full scoop on the BOOTP request/reply packet format lives in [RFC-951] 📦. The rest of this doc is about the last field of the packet: a 64 octet area reserved for vendor information, which used to be totally unspecified 🫠. A generalized use of that area, for info useful to a wide range of machines, operating systems, and configurations, comes next ✨. If one BOOTP server has to serve heterogeneous clients at a single site, a generic class of data may be used 🧩.

Like [RFC-951] suggested, the first four bytes of this field are the magic cookie, which tells you how to read the data that follows 🔮. Its value 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 free format, with extendable tagged sub-fields 🧸. Most of those sub-fields are length tagged (there are exceptions, see below), so clients that don't implement certain types can still skip past the fields they can't interpret 🏃‍♀️. 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 🍦. Fields with no data are just a single tag octet, implicitly one octet long. Fields with data are one tag octet, one length octet, and then that many octets of data 🧾.

Pad Field (Tag: 0, Data: None)

PAD may be used to line up later fields on the word boundaries the target machine needs, like 32-bit quantities such as IP addresses sitting on 32-bit boundaries 📐.

Subnet Mask Field (Tag: 1, Data: 4 subnet mask bytes)

This one specifies the net and local subnet mask, following the subnetting standard in [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 one gives the time offset of the local subnet, in seconds from Coordinated Universal Time (UTC) ⏰. It's a signed 32-bit integer 🔢.

End Field (Tag: 255, Data: None)

This marks the end of the usable data in the vendor information area 🛑. The rest of this field should be filled with PAD (zero) octets 🫧.

to be continued... the variable length fields and extensions are up next 👀🎀

Comparison to Alternative Approaches 💅

Okay bestie, this section is the RFC basically asking "wait, do we even need all this?" 🤔 Extending BOOTP to hand out more config info than the bare minimum boot PROMs need may not be necessary. Instead of every module on a host (like the time module, the print spooler, or the domain name resolver) pinging the BOOTP server for server addresses, it would be better for each one to multicast straight to the server group it wants, maybe using "expanding ring" multicasts. 🦋

The multicast approach has the following advantages over the BOOTP approach:

  • No more depending on a third party (the BOOTP server) that might be temporarily unavailable, or whose database might be wrong or incomplete 🙃 Multicasting directly to the services you want finds the servers that are up right now, and only those. ✨
  • It takes way less admin drama to keep the (probably replicated) BOOTP database up-to-date and consistent 📋 This matters a LOT when you've got a growing number of services and a constantly changing crowd of servers. 😭
  • Sometimes it cuts down on packet traffic and/or the delay needed to get the info you want ⚡ For example, the current time can come from a single multicast to a time server group, which gets replies from whichever time servers are currently up. The BOOTP approach would need a broadcast to the BOOTP server, a reply from the BOOTP server, one or more unicasts to time servers (maybe waiting out long timeouts if the first picks are down), and finally a reply from a server. Main character energy it is not 💀

One apparent advantage of the proposed BOOTP extensions is that they give you a uniform way to locate servers. Cute, but the multicast approach could be done consistently across multiple services too 🌈 The V System naming protocol is a great example of this: character string pathnames name any number of resources (not just files), and a standard subroutine library handles the multicasting to locate them, caches the discovered locations, and detects stale cache data. Iconic. 👑

Another apparent advantage of the BOOTP approach is that it lets an administrator easily control which hosts use which servers 🎀 The multicast approach leans toward more distributed control over resource allocation, where each server decides which hosts it will serve, using whatever level of authentication fits that particular service. For example, time servers usually don't care who they serve (so administrative control via the BOOTP database is unnecessary), whereas file servers usually require strong authentication (so administrative control via the BOOTP database is insufficient). Different vibes, different needs. 🧚

The main drawback of the multicast approach, of course, is that IP multicasting is not widely implemented, and there's a need to locate existing services that don't understand IP multicasts 😬

The BOOTP approach may be most efficient when all the information the client host needs comes back in a single BOOTP reply, and each program module just reads what it needs from a local table filled in by that reply. Simple, clean, no drama 🍓

Acknowledgments 🫶

The following people gave 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. Thank you, queens. 👑💜

References 📚

  • [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-1034] Mockapetris, P., "Domain Names - Concepts and Facilities", Network Information Center, SRI International, Menlo Park, California, November 1987.
  • [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.

Author's Address 🌸

Joyce K. Reynolds
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Phone:  (213) 822-1511

EMail: JKREYNOLDS@ISI.EDU
📦 where this page comes from