RFC 1395

RFC 1395: BOOTP Vendor Information Extensions 🎀

Network Working Group 🌈 Request for Comments: 1395 Author: J. Reynolds, ISI 💅 Date: January 1993 🍓 Obsoletes: 1084, 1048 Updates: 951

Bestie, this one is all about the vendor information extensions for BOOTP, and J. Reynolds at ISI wrote it. It obsoletes RFC 1084 and 1048 and updates RFC 951, so it's giving major revision energy ✨

Status of this Memo ✨

Okay so this memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP) 🦋 Distribution of it is unlimited, so share it with everyone who needs it 💖

Introduction 🌸

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, and he absolutely deserves the credit for the original work 🫶 The memo is going to keep getting updated as more tags get defined. This edition adds Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server, and Tag 17 for Root Path 🎀

As workstations and personal computers take over the Internet, running a network gets way more admin-heavy, like by an order of magnitude 😭 Giving every client its own local network resources is one of the hard parts. In most environments, handing that job to the user just isn't realistic. The move is to define resources in uniform terms and automate how they get assigned 🧚

The basic Bootstrap Protocol [RFC-951] 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 way of reading that resource information ✨

Overview of BOOTP 🦋

Reverse Address Resolution (RARP) Protocol [RFC-903] can assign an IP address to a local network hardware address, but honestly 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 might be the move 💅

Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol. It 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. Iconic 🔥

The obvious win here is centralized management of network addresses, so you don't need per-host unique configuration files anymore 🌈 With several hundred hosts, keeping local configuration info and operating system versions specific to each host could get totally chaotic. If you sort hosts into classes and keep configuration info and boot programs for each class, the chore gets a lot smaller 🫶

BOOTP Vendor Information Format 💖

The full description of the BOOTP request/reply packet format may be found in [RFC-951] 📖 This part of the doc focuses on the last field of the packet, a 64 octet area reserved for vendor information, which has been waiting to be used in an unspecified way. A generalized use of this area, for info useful to a wide class of machines, operating systems, and configurations, comes next. When a single BOOTP server is serving heterogeneous clients at one 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 are assigned to the magic cookie. The magic cookie tells you the mode the succeeding data should be read in. 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 a free format with extendable tagged sub-fields. These sub-fields are length tagged (with exceptions, see below), so clients that don't implement certain types can skip the fields they can't interpret 🙌 Lengths are exclusive of the tag and length octets, and all multi-byte quantities are in network byte-order 💅

Fixed Length Data 🎀

Fixed length data comes in two formats. The ones with no data are just a single tag octet, implicitly one-octet length. The ones that contain data have one tag octet, one length octet, and length octets of data ✨

Pad Field (Tag: 0, Data: None) 🫧

This field MAY be used to align subsequent fields to the word boundaries the target machine needs. For example, 32-bit quantities like IP addresses sit on 32-bit boundaries 🧱

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

This specifies the net and local subnet mask, following 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 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) 🛑

This marks the end of usable data in the vendor information area. The rest of this field SHOULD be filled with PAD zero) octets. Main character energy, the end of the story 💜

Comparison to Alternative Approaches 🦋

okay bestie, the big question is whether we even NEED to cram more config info into BOOTP 🤔. Extending BOOTP to give more than the bare minimum that 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) broadcasting to the BOOTP server to find the servers it needs, it would be better for each one to multicast directly to the particular server group it cares about. It could even use "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 incorrect or incomplete. Multicasting straight to the services you want finds the servers that are up right now, and only those ✨
• Way less admin pain 😩 keeping the (probably replicated) BOOTP database up-to-date and consistent. This matters SO much when you've got a growing number of services and an evolving population of servers 🧹
• Sometimes it cuts down on packet traffic and/or delay 🚀. Like, getting the current time is just ONE multicast to a time server group, and the replies come from whichever time servers are up. With BOOTP you'd need a broadcast to the BOOTP server, a reply from the BOOTP server, one or more unicasts to time servers (maybe sitting through long timeouts if the first pick is down 😵), and finally a reply from a server. Main character energy it is not 💀

okay so one thing the BOOTP extensions have going for them is a uniform way to find servers 🫶. BUT multicast can be just as consistent across multiple services!! The V System naming protocol is the proof 🧚. Character string pathnames name any number of resources (not just files!), and a standard subroutine library handles the multicasting to find them, caches what it finds, and notices when the cache goes stale 💅.

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 the particular service. For example, time servers usually don't care who they serve (i.e., administrative control via the BOOTP database is unnecessary), whereas file servers usually require strong authentication (i.e., administrative control via the BOOTP database is insufficient) 🔐.

The big catch 😬 with multicast is that IP multicasting isn't widely implemented, and you still need to locate existing services that don't understand IP multicasts.

BOOTP might be the most efficient when a single BOOTP reply hands the client host ALL the info it needs 📦, and each program module just reads what it needs from a local table filled in by that reply 🍓.

---

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 💜.

References 📚

[RFC-951]   Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)",
            Stanford and SUN Microsystems, September 1985.

[RFC-903]   Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
            Reverse Address Resolution Protocol", 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. 🚨

Author's Address 💌

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