Port 67: BOOTP/DHCP — The Protocol That Gives You a Name

Every device on every network begins the same way: as a stranger.

When your phone connects to WiFi, when your laptop wakes from sleep, when a smart thermostat powers on for the first time, it faces an existential problem. It has a physical address burned into its hardware, but it does not know who it is on this network. It does not know where to send packets. It does not know how to find anything by name. It is a machine with a voice but no identity.

Port 67 is where that machine goes to get one.

What Port 67 Does

Port 67 is the listening port for DHCP (Dynamic Host Configuration Protocol) servers and its predecessor, BOOTP (Bootstrap Protocol). When a device needs network configuration, it broadcasts a request from port 68 to port 67. The server listening on port 67 responds with everything the device needs to become a functioning member of the network:

• An IP address: Your identity on this network
• A subnet mask: The boundaries of your local neighborhood
• A default gateway: The door to the rest of the Internet
• DNS server addresses: How to translate names into numbers

This exchange happens in four messages, remembered by the acronym DORA: Discover, Offer, Request, Acknowledge.¹ In seconds, a device goes from anonymous to addressed, from lost to located.

The DORA Handshake

The elegance of DHCP lies in its simplicity.

Discover: The client broadcasts to 255.255.255.255 (everyone) from source IP 0.0.0.0 (nobody). It is saying: "I exist. I need an address. Can anyone help?"

Offer: One or more DHCP servers respond with an offer: "I can give you 192.168.1.47 for the next 24 hours. Here is your subnet mask, your gateway, your DNS servers."

Request: The client broadcasts again, this time accepting a specific offer: "Thank you, server at 192.168.1.1. I accept your offer of 192.168.1.47." Other servers withdraw their offers and return their addresses to the pool.

Acknowledge: The chosen server confirms: "192.168.1.47 is yours. Welcome to the network."²

The entire conversation happens over UDP, connectionless and fast. The client does not need an IP address to participate because it is using broadcasts. The server does not need to know the client exists beforehand. Two strangers meet, exchange credentials, and part ways, each knowing what they need to know.

The History: From Diskless Machines to Ubiquity

In the early 1980s, Sun Microsystems was building workstations with a problem. The original Sun workstation was designed to be diskless, relying on centralized file servers over Ethernet.³ These machines could not store their own configuration. Every time they powered on, they needed to discover their IP address from somewhere.

The solution at the time was RARP (Reverse Address Resolution Protocol), defined in RFC 903 in 1984.⁴ RARP let a machine ask: "I know my hardware address. What is my IP address?" But RARP had a fatal flaw: it operated at the link layer, below IP. It could not cross routers. Every subnet needed its own RARP server. It could not provide gateway addresses or DNS servers. It was a band-aid on a growing wound.

In September 1985, two engineers published RFC 951: the Bootstrap Protocol.⁵

Bill Croft was at Stanford University, where he had built networking infrastructure including the Stanford Ethernet AppleTalk Gateway.⁶ John Gilmore was the fifth employee at Sun Microsystems, where he had worked on TCP/IP implementations for the diskless workstations that needed this protocol.⁷

What they designed was elegant: BOOTP would run over UDP/IP, which meant it could be relayed across routers. A single BOOTP server could serve an entire enterprise. It provided not just IP addresses but boot filenames, allowing diskless machines to download their operating systems from a TFTP server. It solved RARP's problems in one clean specification.

The co-author is worth pausing on. John Gilmore left Sun in 1986 with enough stock to become a millionaire when the company went public.⁸ He went on to co-found the Electronic Frontier Foundation in 1990 and helped launch the cypherpunks mailing list in 1992.⁹ He created the alt.* hierarchy in Usenet. He sponsored the EFF's Deep Crack DES cracker that demonstrated the weakness of 56-bit encryption. His most famous quote: "The net treats censorship as damage and routes around it."¹⁰

BOOTP was his first major contribution to the infrastructure of the Internet. It was a protocol about identity and belonging, written by someone who would spend the rest of his career thinking about identity, privacy, and freedom online.

DHCP: The Evolution

BOOTP had one limitation: addresses were statically assigned. An administrator had to configure a mapping between each hardware address and its IP address. As networks grew, this became unmanageable.

In October 1993, Ralph Droms of Bucknell University published RFC 1531: the Dynamic Host Configuration Protocol.¹¹ DHCP extended BOOTP with one critical addition: leases. Instead of permanent assignments, DHCP could lend addresses temporarily and reclaim them when no longer in use. A pool of 254 addresses could serve thousands of devices, as long as they were not all connected simultaneously.

DHCP went through three RFC iterations, all authored by Droms: RFC 1531 and 1541 in October 1993, and the current standard RFC 2131 in March 1997.¹² The protocol kept BOOTP's port numbers (67 for server, 68 for client) and maintained backward compatibility. A DHCP server can respond to BOOTP clients. The infrastructure was preserved while the capabilities expanded.

Today, virtually every consumer device, enterprise workstation, IoT sensor, and mobile phone uses DHCP. When you walk into a coffee shop and connect to WiFi, you are sending a DHCP Discover from port 68 to port 67. When your ISP assigns your home router a public IP address, DHCP. When a containerized microservice spins up in a cloud data center, DHCP.

The protocol that two engineers wrote to solve the diskless workstation problem in 1985 now configures billions of network connections every day.

Security: The Vulnerability of Trust

DHCP has a fundamental security weakness: it trusts everyone.

When your device broadcasts a DHCP Discover, it will accept an Offer from any server that responds. There is no authentication. There is no encryption. The protocol assumes that anyone answering on port 67 is legitimate.

This creates two primary attack vectors:

DHCP Starvation: An attacker floods the DHCP server with fake requests, each with a spoofed MAC address, exhausting the address pool. Legitimate devices cannot obtain addresses. The network becomes unusable.¹³

Rogue DHCP Server (DHCP Spoofing): After starving the legitimate server (or simply racing it), an attacker sets up their own DHCP server. When your device asks for configuration, the attacker responds with malicious settings: a gateway address pointing to the attacker's machine (enabling man-in-the-middle attacks), DNS servers that redirect your requests to fraudulent sites.¹⁴

These attacks are devastatingly simple to execute. Tools like Yersinia can launch DHCP starvation with a single command. Once an attacker controls DHCP responses, they control where your traffic goes.

Mitigations exist but require deliberate configuration:

• DHCP Snooping: Switches can be configured to only allow DHCP responses from trusted ports.¹⁵
• Port Security: Limiting MAC addresses per port prevents starvation attacks.
• 802.1X Authentication: Requiring authentication before network access prevents rogue devices.
• RFC 3118: Defines DHCP authentication options, though adoption remains limited.¹⁶

The honest truth: most networks run DHCP completely unauthenticated. Your laptop trusts whatever server answers first. On a public WiFi network, that trust may be misplaced.

Related Ports

Port 67 does not work alone:

The conversation between 67 and 68 is the Internet's most common introduction. Billions of times per day, a device sends "hello" to port 67 and receives "welcome" on port 68.

Why Port 67 Matters

There is something profound about a protocol that answers the question "Who am I?"

Every network identity you have ever held started with a broadcast to port 67. The IP address that defined your connection, the gateway that connected you to the wider Internet, the DNS servers that translated names into numbers, all of it was given to you by a server listening on this port.

Bill Croft and John Gilmore solved a practical problem: diskless workstations that could not remember their configuration. But what they built was more than a boot protocol. They built the introduction ritual of the networked world. The moment of becoming someone on a network instead of no one.

Port 67 does not carry email or web pages or video streams. It carries something more fundamental: the gift of belonging. Before you can do anything on a network, you must first become part of it. Port 67 is where that happens.

Every time you connect, there is a moment, too fast to notice, where your device broadcasts into the void: "I am here. I need a name." And from port 67, always, the answer comes back: "Welcome. This is who you are."