Port 68: BOOTPC — The Listening Ear of Every New Device

Every device that joins a network starts in the same state: alive but anonymous. It has a physical address burned into its hardware, but no IP address, no subnet mask, no gateway, no DNS server. It knows nothing about where it is or how to reach anything beyond itself.

Port 68 is where that changes.

When your laptop connects to WiFi, when your phone joins a network, when a smart thermostat powers on for the first time, each sends a broadcast into the void: "I exist. Who am I?" That question goes out on port 67. The answer comes back on port 68. And in that moment, a piece of hardware becomes a citizen of the network.

What Port 68 Does

Port 68 is the client side of the Bootstrap Protocol (BOOTP) and its successor, the Dynamic Host Configuration Protocol (DHCP). While servers listen on port 67, clients listen on port 68.¹

This is unusual. Most client applications use ephemeral ports, random high numbers assigned by the operating system. But DHCP clients can't do that. They don't have an IP address yet. They can't receive unicast traffic. The only way to reach them is to broadcast to a well-known port that every device listens on before it has an identity.²

So port 68 exists as a universal listening post. Every device on every network, in the moment before it knows who it is, waits here for the answer.

The DORA Dance

DHCP works through a four-step exchange known as DORA: Discover, Offer, Request, Acknowledge.³

Discover: The client broadcasts from 0.0.0.0:68 to 255.255.255.255:67. "I exist. I need an address. Is anyone out there?"

Offer: A DHCP server responds with an available IP address, subnet mask, default gateway, and DNS servers. This arrives on port 68.

Request: The client broadcasts again, accepting the offer. If multiple servers responded, this tells them which offer was accepted.

Acknowledge: The server confirms. The client now has an identity.

The entire exchange happens over UDP. No TCP handshake, no connection state. Just broadcasts and responses in the dark, until the lights come on and the client knows where it is.

The Problem Before BOOTP

In the early 1980s, diskless workstations were the future. Sun Microsystems built its business on them, workstations that had processors and memory but no local storage, booting entirely from the network.⁴ The economics made sense: centralized storage was cheaper to manage than disks on every desk.

But diskless machines faced a bootstrap problem. To boot from the network, a machine needed to know its IP address. To get its IP address, it needed to ask a server. To ask a server, it needed to send IP packets. But it couldn't send IP packets without an IP address.

The first solution was RARP, the Reverse Address Resolution Protocol.⁵ It let a machine broadcast its MAC address and receive its IP address in response. Simple and elegant, but fatally limited.

RARP operated at Layer 2, the link layer. It couldn't cross routers. Every subnet needed its own RARP server. It couldn't provide anything beyond an IP address, no subnet mask, no gateway, no boot file location. And implementing it required kernel modifications on the server, because RARP wasn't IP-based.⁶

Birth of the Bootstrap Protocol

In 1985, Bill Croft at Stanford University and John Gilmore at Sun Microsystems wrote RFC 951, defining the Bootstrap Protocol.⁷

Gilmore was Sun's fifth employee. He'd been there since 1982, writing network code for the systems that would define an era of computing.⁸ Croft had built early campus networks at Purdue before joining the project.

Their insight was simple but transformative: make the bootstrap protocol IP-based. Use UDP. This meant BOOTP packets could cross routers with the help of relay agents. One centralized server could serve an entire organization, not just a single subnet. And the protocol could carry more than just an IP address: boot file names, server addresses, vendor-specific options.⁹

As Gilmore later recalled: "We got the BOOTP protocol working in prototype. Bill understood the RFC submission process, and we got it published as an experimental RFC. Sun didn't care."¹⁰

They didn't realize they were building infrastructure that would outlive Sun Microsystems itself.

From BOOTP to DHCP

BOOTP had one significant limitation: addresses were statically assigned. An administrator had to configure the server with a mapping from each MAC address to its IP address. Add a new machine, update the server. Move a machine, update the server. It didn't scale to networks where devices came and went.

In 1993, Ralph Droms at Bucknell University published RFC 1531, the first DHCP specification.¹¹ DHCP extended BOOTP with a crucial concept: leases. Instead of permanent assignments, addresses were borrowed for a period of time and returned when no longer needed.

This transformed network administration. Connect a laptop to a network, get an address automatically. Disconnect, the address goes back to the pool. No administrator intervention required. The protocol could handle a coffee shop where a hundred different devices might connect in a single day, each needing an address for an hour.

RFC 2131, published in March 1997, refined the protocol into the form still used today.¹² It added the DHCPINFORM message and clarified interoperability with BOOTP, ensuring the old and new could coexist.

DHCP kept BOOTP's port assignments. Port 67 for servers, port 68 for clients. The infrastructure didn't need to change. DHCP was an evolution, not a revolution.

Security: The Fundamental Vulnerability

DHCP has no authentication. None. A client broadcasts "I need an address," and it trusts whatever answer comes first.¹³

This creates two categories of attack:

DHCP Starvation: An attacker floods the DHCP server with requests using spoofed MAC addresses, exhausting the address pool. Legitimate clients can't get addresses. The network becomes unusable.¹⁴

Rogue DHCP Server: An attacker sets up their own DHCP server on the network. When a client asks for an address, the rogue server answers first. It hands out addresses, but it also tells clients to use the attacker's machine as their default gateway and DNS server. All traffic now routes through the attacker. Man-in-the-middle, achieved.¹⁵

These attacks are often combined. First, starve the legitimate server. Then, become the only server that answers.

The defense is DHCP snooping, a switch-level security feature that tracks which ports are allowed to send DHCP server responses.¹⁶ Only designated ports can offer addresses. Everything else gets dropped. But DHCP snooping requires managed switches and deliberate configuration. Many networks don't have it.

The fundamental problem is that DHCP was designed in an era when everyone on the network was trusted. That era ended long ago.

The Modern Landscape

DHCP remains ubiquitous. Every home router runs a DHCP server. Every corporate network relies on it. Every time you connect to WiFi, your device listens on port 68 for the response that lets it participate.

For IPv6, the protocol has been reimagined as DHCPv6, using different ports: 546 for clients, 547 for servers.¹⁷ But IPv6 also introduced SLAAC, Stateless Address Autoconfiguration, which lets devices generate their own addresses without any server at all. The two approaches coexist, each suitable for different scenarios.

Port 68 on UDP carries less traffic than it used to. Addresses lease for hours or days, not minutes. Once a device has an address, it keeps it until the lease expires. The constant chatter of early networks has settled into a quieter rhythm.

But every new connection still starts the same way. Every device still asks the same question. And port 68 still listens for the answer.

The Gilmore Connection

John Gilmore left Sun in 1985 with stock that made him wealthy when the company went public the following year.¹⁸ He used that freedom to pursue causes he cared about.

In 1990, he co-founded the Electronic Frontier Foundation, dedicated to defending civil liberties in the digital world.¹⁹ In 1992, he co-founded the Cypherpunks mailing list, where cryptographers and activists discussed technologies for privacy and anonymity.

His most famous quote: "The Net interprets censorship as damage and routes around it."²⁰

There's something fitting about this. The same engineer who helped devices discover their identity on networks spent his life helping humans preserve theirs. Port 68 carries that lineage, infrastructure built by someone who understood that networks are ultimately about enabling connection between people, not just machines.

Related Ports