Summary

  • RFC 1048 put the four-octet value 99.130.83.99 at the front of BOOTP's vendor field to select an interpretation grammar. Tagged, length-delimited subfields then let a receiver find known options and skip unknown ones inside a fixed 64-octet envelope.
  • The cookie authenticated nothing. A reply could be perfectly framed yet false, stale or unauthorized; later BOOTP guidance made that security limit explicit even as the same option format passed into DHCP.

In BOOTP's original problem, a machine begins with almost no local context. It may know its hardware address and how to execute a small bootstrap program, but not its IP address, the address of a useful server or the name of the file it should load. RFC 951, published in 1985, split the process into two phases: learn enough configuration and a bootfile location, then use another protocol to fetch the file.

The BOOTP packet reserved 64 octets for vend, a vendor-specific area. That was simultaneously generous and awkward. It offered room to return the subnet mask, a gateway, time servers or other facts a client might need before a general service was available. But “vendor-specific” meant that the same bytes could mean different things to different programs. RFC 951 recommended beginning used vendor data with a four-byte magic number so a client could recognize the kind of information that followed. Recognition existed; a common grammar did not yet.

RFC 1048, issued in February 1988, changed that boundary. It did not enlarge the packet. It made the existing space self-describing enough for heterogeneous clients to share. The design is small enough to miss: four bytes select the format, and the remaining bytes are divided into tagged subfields. Yet this modest grammar solved three separate problems—format identification, extension framing and bounded allocation—without pretending to solve source authority.

The cookie names a language, not a speaker

RFC 1048 sets the first four octets to decimal 99.130.83.99, or hexadecimal 63.82.53.63, in network byte order. The document's wording is exact: the magic cookie identifies the mode in which the succeeding data is to be interpreted.

That is a representation claim. Once a program sees the cookie, it can apply the RFC 1048 parsing rules instead of a private vendor layout. The bytes do not identify a manufacturer, authenticate a BOOTP server, prove that a relay preserved the packet or certify that the advertised router is legitimate. Anyone capable of sending the same four public octets can make the same syntactic claim.

BOOTP had other correlation fields. A transaction ID helped a client associate a response with an outstanding request; addresses and a hardware address helped deliver and recognize the exchange. Those mechanisms answer “which attempted exchange does this packet resemble?” They do not turn the magic cookie into a secret or the response into a signed statement.

This distinction later became operationally urgent. RFC 1542 described BOOTP as inherently insecure and warned that an unauthorized server could supply false IP, router and domain-name-server information. The danger does not arise because the grammar failed. It arises because parsing and authority are different controls. A false gateway can be encoded with impeccable tag and length fields.

Length made unfamiliar options survivable

After the cookie, an ordinary RFC 1048 option has a one-octet tag, a one-octet length and the stated number of value octets. The length excludes the tag and length themselves. Multi-octet quantities follow Internet network byte order.

This tiny convention gives an old client a disciplined response to novelty. If it recognizes a tag, it can check the length and interpret the value. If it does not recognize the tag, it can advance by the declared length and try the next subfield. The unknown item remains unknown, but it need not corrupt the framing of everything after it.

That is a powerful form of compatibility because it limits ignorance. A parser does not need a catalogue of every future option merely to reach an option it already understands. Nor does the sender need to negotiate an entirely new packet version each time a generic field is registered. Format evolution becomes incremental.

The guarantee is narrow, however. A length says where a value ends, not what the value means. A site-specific tag can be skipped safely by an outside implementation while remaining meaningful only under a local agreement. A known tag with a plausible length can still carry a mistaken address. A parser that advances correctly has demonstrated memory safety only if its implementation is sound; it has demonstrated no network truth.

RFC 1084 and RFC 1497 later revised the option catalogue while keeping this core arrangement. The persistence of the framing is historical evidence of a useful compatibility seam. It is not evidence that all deployments understood every option alike.

Pad and End are part of the grammar's control plane

Two tag values do not carry a length. Pad, tag 0, occupies one octet. It can align later material or consume unused space. End, tag 255, also occupies one octet and says that the option sequence is over; any remaining bytes are filled with zeroes.

These exceptions are not ordinary data with zero-length values. They control how the byte stream is traversed. Treating Pad as if another octet contained a length would shift the parser. Treating bytes after End as fresh options would convert padding into invented configuration. Interoperability depends as much on knowing when not to read a length as on knowing how to read one.

Order can also carry a dependency. RFC 1048 says that if a subnet mask and a gateway both appear, the subnet mask must come first. A client needs the mask to decide which destinations and gateways are local. The options are not a bag whose order is always irrelevant; framing and sequence together express the usable record.

The general lesson is not that TLV formats automatically solve evolution. It is that a format must state its exceptions, termination rule, ordering dependencies and failure behavior. Otherwise the length field merely moves ambiguity from the packet boundary into the implementation.

Sixty-four octets turned extensibility into choice

The cookie consumes four of the field's 64 octets before any option appears. Every ordinary option then spends two octets on tag and length. An IPv4 address costs four more; a list costs multiples of that. RFC 1048 explicitly says the contents must not exceed the vendor field and recommends omitting nonessential data or discovering it through another service.

The limit shaped the protocol's politics. Generic tags were scarce shared identifiers, so broadly useful fields were to be registered rather than claimed informally. Tags 128 through 254 remained site-specific. That division allowed local experimentation, but it placed the burden of meaning on the participating site. Shared framing did not make a private option globally portable.

Registration reduced collisions in the common range. It did not decide which options a particular client should receive, whose database entry was accurate or which service deserved a place in the first 64 octets. Those remained operational choices. A boot server administrator controlled the local table; a client implementation controlled what it requested and acted upon; later discovery services could carry what did not fit.

The fixed field therefore produced a useful discipline and a real lock-in pressure. Compact early configuration encouraged implementations to converge on one common envelope. Once clients and servers depended on the tag numbers and parsing rules, changing the envelope became expensive. Later specifications could add catalogued meanings more easily than they could replace the grammar itself.

One efficient reply could still be wrong

RFC 1048 compares BOOTP's centrally administered information with discovery by multicast or other distributed methods. If a reply contains everything a client needs, the client can read a local table and proceed efficiently. But the document also notes that centrally maintained information can be incomplete or stale.

The distinction matters because central control is often mistaken for authentication. An administrator who can edit the BOOTP database has authority over what that database says. That does not automatically establish the identity of the eventual file server or the authenticity of a boot image. RFC 1048 says the BOOTP database is insufficient for strong file-server authentication; the service must solve that problem at its own level.

There are thus at least four records in a successful bootstrap. The packet is parseable under a named grammar. The reply correlates with a request. The configured value came from some server path. The later service transaction succeeds under its own security and application rules. Combining those records into “the cookie trusted the boot” erases every useful boundary.

RFC 1542's recommendation that clients include the cookie even when sending no options makes this separation especially clear. Such a request contains the four-byte cookie, an End tag and zero padding so the server knows which response format the client expects. It negotiates representation before content. It conveys no secret with which to trust the responder.

DHCP inherited the envelope, not an assurance

RFC 1533 defined DHCP options in the same BOOTP vendor-extension format: tag, length and value, with Pad and End as one-octet exceptions. It retained the BOOTP magic cookie, network byte order and the site-specific range. RFC 2132 later documented the mature DHCP option catalogue in that lineage.

This is a documented format succession, not a licence to read later DHCP practice back into every 1988 BOOTP network. The option catalogue grew; message use and operational environments changed; security remained a separate problem. RFC 1533 itself says security issues are not discussed there. A durable container can transport more semantics than its first authors enumerated, but it cannot silently acquire provenance guarantees.

The deeper historical achievement of RFC 1048 is therefore restraint. It standardized enough to let unlike machines agree on where an option begins, where it ends and how to move past one they cannot understand. It allocated a shared range and preserved a local one. It made a strict small envelope productive. And it left identity, freshness, authorization and service success outside the cookie's authority.

Sources and limits of evidence

RFC 951 supplies the original BOOTP exchange, the 64-octet vendor field and the recommendation for a magic number. RFC 1048 defines the generalized cookie and tagged format, the ordering and allocation rules, the fixed-field limit and its comparison of centralized data with other discovery. RFC 1084 and RFC 1497 record later BOOTP revisions. RFC 1533, RFC 1542 and RFC 2132 show the DHCP-format lineage and the explicit BOOTP security boundary.

These documents establish specifications and documented design transitions. They do not measure historic deployment share, identify a particular network's configuration, prove that every implementation handled unknown tags safely or show that any option value observed today came from an authorized server.