RFC 1497

BOOTP Vendor Information Extensions

📅 published August 1993, from ietf

BOOTP Vendor Information Extensions 🎀 (Part 1 of 2)

  • Request for Comments: 1497, from the Network Working Group 🧚
  • Author: J. Reynolds, ISI 💅
  • Date: August 1993 📅
  • Status: a status report on the vendor information extensions used in BOOTP 📜
  • Obsoletes: RFC 1395, 1084, and 1048, so this one replaces all three 🔁
  • Updates: RFC 951 ⭐

Status of this Memo 📜

okay so this memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP). distribution is unlimited, so share it with everyone 💖

Introduction ✨

okay bestie, this RFC is a slight revision and extension of RFC-1048. the original work is credited to Philip Prindeville, who totally deserves the shoutout here 🙌

this memo will be updated as additional tags are defined 🏷️ and this edition introduces Tag 18 for Extension Path 🦋

as workstations and personal computers multiply all 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 the hardest parts. in most environments, handing that job to the user is not 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 provisions for vendor-defined resource information 🌸

so this memo defines a (potentially) vendor-independent way to interpret that resource information 💜

Overview of BOOTP 🔍

the Reverse Address Resolution Protocol (RARP) [RFC-903] can be used to assign an IP address to a local network hardware address, but it only covers part of what's needed 🙈 it can be used alongside other supplemental protocols, like the Resource Location Protocol [RFC-887] and the Domain Name System [RFC-1034], but a more integrated solution may be the move 🧩

Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol that lets a booting host configure itself dynamically. the even bigger deal is that it does this without 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 here is centralized management of network addresses, which means no more per-host unique configuration files 🎉 with several hundred hosts, keeping local configuration info and OS versions specific to each host could get totally chaotic 😵‍💫 so you sort hosts into classes and keep configuration info and boot programs for each class. the complexity of the chore may be reduced in magnitude 👑

BOOTP Vendor Information Format 🎀

the full description of the BOOTP request/reply packet format is in [RFC-951], so go check there for the whole picture 📖 this document is all about 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 info useful to a wide class of machines, operating systems, and configurations comes next. when a single BOOTP server is used among heterogeneous clients at one site, a generic class of data may be used 🌈

as suggested in [RFC-951], the first four bytes of this field have been assigned to the magic cookie. it identifies the mode in which the data that follows 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 is implemented as a free format, with extendable tagged sub-fields ✨ these sub-fields are length tagged (with exceptions; see below). that lets clients who don't implement certain types correctly skip the fields they can't interpret 🦋

heads up: lengths are exclusive of the tag and length octets, and all multi-byte quantities are in network byte-order 👀

Fixed Length Data 💖

the fixed length data comes in two formats 🎀 fields with no data are a single tag octet and are implicitly one-octet length. fields that do contain data are 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 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 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) ⏰ specifies 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) 🛑 specifies the end of usable data in the vendor information area. the rest of this field should be filled with PAD (zero) octets 🫧

part 2 is up next, with the variable length data, Extensions and the rest 🫶

Comparison to Alternative Approaches ✨

okay so bestie, extending BOOTP to hand out more config info than the minimum that boot PROMs need may not even be necessary 🙈 Instead of every module in a host (the time module, the print spooler, the domain name resolver) shouting into a broadcast at the BOOTP server to ask where the servers are, it would be way better for each one to multicast straight to the particular server group it cares about 🦋. Possibly using "expanding ring" multicasts too 💅

The multicast approach has these advantages over the BOOTP approach:

  • It kills the dependency on a third party (the BOOTP server) that may be temporarily unavailable, or whose database may be incorrect or incomplete 💀. Multicasting directly to the services you want finds the servers that are up right now, and only those. no ghosts 👻
  • It takes the admin chore of keeping the (probably replicated) BOOTP database up-to-date and consistent off your plate 🧚. This is especially important when you've got a growing number of services and an evolving crowd of servers 📈.
  • In some cases it cuts the amount of packet traffic and/or the delay needed to get the info you want ⚡. Like, the current time can be grabbed with a single multicast to a time server group, which summons replies from whichever time servers are currently up 🕰️. BOOTP 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 pick(s) are down 😩), and finally a reply from a server. not the vibe 💀

One apparent advantage of the proposed BOOTP extensions is that they provide a uniform way to locate servers ✨. However, the multicast approach could also be implemented in a consistent way across multiple services 💜. The V System naming protocol is a great example of this 👑: character string pathnames are used to name any number of resources (not just files), and a standard subroutine library looks after the multicasting to locate them, caches the discovered locations, and detects stale cache data 🧠.

Another apparent advantage of the BOOTP approach is that it lets an administrator easily control which hosts use which servers 🎀. The multicast approach favors more distributed control over resource allocation, where each server decides which hosts it will serve, using whatever level of authentication is appropriate for 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 😤).

The main drawback of the multicast approach, of course, is that IP multicasting is not widely implemented, and there is a need to locate existing services which do not understand IP multicasts 😭.

The BOOTP approach may be most efficient in the case that all the information needed by the client host comes back in a single BOOTP reply, and each program module simply reads the information it needs from a local table filled in by that reply 🍓.

Acknowledgments 🫶

The following people provided 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 💖 They're literally the reason that section exists ✨

ps. the original spells it "Carnagie" 🙈 typo and all, we keep receipts

References 📚

  • [RFC-951] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford and SUN Microsystems, September 1985.
  • [RFC-903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, Stanford, June 1984.
  • [RFC-887] Accetta, M., "Resource Location Protocol", RFC 887, CMU, December 1983.
  • [RFC-1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
  • [RFC-950] Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, USC/Information Sciences Institute, August 1985.
  • [RFC-868] Postel, J., "Time Protocol", STD 26, RFC 868, USC/Information Sciences Institute, May 1983.
  • [IEN-116] Postel, J., "Internet Name Server", USC/Information Sciences Institute, 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", STD 23, RFC 865, USC/Information Sciences Institute, 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.

Security Considerations 💀

Security issues are not discussed in this memo 😱

the memo literally says nothing about security. zero words. plan accordingly, bestie 🔒

Author's Address 🎀

Here's where to find the author, Joyce K. Reynolds 💌

Joyce K. Reynolds
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, CA 90292

Phone:  (310) 822-1511

EMail: jkrey@isi.edu
📦 where this page comes from