Port 847: DHCP Failover — The protocol that works without a standard

Port 847 carries DHCP Failover protocol traffic—communication between DHCP servers that synchronize their lease databases to provide redundancy. When your primary DHCP server fails, the secondary takes over without dropping connections. Port 847 makes that handoff possible.

Here's what makes this port unusual: it has an official IANA assignment to a protocol that was never formally standardized. The DHCP Failover specification lived as an Internet-Draft for years, went through twelve revisions, and then expired in 2003 without ever becoming an RFC¹. Yet DHCP servers implemented it anyway, and port 847 has been carrying this traffic ever since.

What DHCP Failover Does

DHCP servers hand out IP addresses to devices joining a network. But what happens when the DHCP server goes down? Every new device gets stuck. No address, no network access.

DHCP Failover solves this by running two servers that stay synchronized. When the primary server hands out an IP address with a 24-hour lease, it immediately tells its partner on port 847. Both servers now know that 192.168.1.100 belongs to your laptop until tomorrow at 3pm.

If the primary server crashes, the secondary already knows the entire state of the network. It takes over seamlessly. No device loses its address. No connections drop.

How the Protocol Works

DHCP Failover uses TCP—not UDP like DHCP itself—because reliability matters here. The two servers maintain a persistent TCP connection on port 847, exchanging several types of messages²:

Binding updates — "I just gave 192.168.1.50 to device AA:BB:CC:DD:EE:FF with a lease until 4:15pm"

Pool balance messages — "I'm running low on available addresses in my pool, you should handle more of the new requests"

State synchronization — "I'm entering communications-interrupted state because I haven't heard from you in 60 seconds"

The protocol supports two modes. In load balancing mode, both servers actively respond to DHCP requests, splitting the workload. In hot standby mode, one server handles everything while the partner waits silently, ready to take over instantly if needed.

The Ports: 647 and 847

Here's where it gets confusing. The DHCP Failover draft specification originally called for port 647, which IANA officially assigned to "dhcp-failover"³. Port 847 received the IANA assignment "dhcp-failover" as well, intended as the peer port.

In practice, implementations vary. Some use port 647 on both sides. Some use 647 for the primary server and 847 for the secondary. The distinction matters for firewall rules: you need to allow whichever ports your specific DHCP implementation uses.

The Protocol That Never Standardized

The DHCP Failover Protocol draft went through twelve versions between 1998 and 2003⁴. It described the message formats, the state machines, the security considerations. Implementers built it into ISC DHCP, Microsoft DHCP Server, and other major implementations.

Then the draft expired. The working group moved on. The specification was never published as an RFC.

This is genuinely unusual. Normally protocols get standardized before they see widespread deployment, or they remain proprietary vendor extensions. DHCP Failover occupied a strange middle ground—detailed enough that different vendors could interoperate, public enough that everyone could implement it, but never formally blessed as a standard.

Why did it never become an RFC? The draft had known issues. The state machine was complex. Security was bolted on rather than built in. There were concerns about split-brain scenarios where both servers think they're primary.

But by then, it was already deployed. Networks depended on it. The imperfect protocol that actually existed beat the perfect protocol that might someday be written.

Modern Usage

DHCP Failover on port 847 remains common in enterprise networks. Windows Server DHCP implements its own variant (documented in [MS-DHCPF], Microsoft's protocol extension documentation). ISC DHCP supports failover based on the draft specification. Cisco, Infoblox, and other network vendors provide implementations.

For IPv6, a new effort began: draft-ietf-dhc-dhcpv6-failover-protocol attempted to learn from IPv4's experience and create a cleaner specification⁵. That draft also expired without becoming an RFC.

Security Considerations

The original DHCP Failover draft included support for TLS and TSIG for authenticating the connection between failover partners. In practice, many deployments skip authentication entirely, assuming the two servers sit on a trusted management network.

This is risky. An attacker who can inject packets on port 847 can corrupt the entire DHCP lease database, causing address conflicts across the network. If you're running DHCP Failover, ensure the connection between partners runs over a network segment that untrusted devices cannot access.

Checking Port 847

To see if port 847 is active on your system:

# On Linux/macOS
sudo lsof -i :847
sudo netstat -tulpn | grep :847

# On Windows
netstat -ano | findstr :847

If you see a listening service, check your DHCP server configuration to confirm it's part of a failover pair.

Related Ports

• Port 67 — DHCP server receives client requests here
• Port 68 — DHCP clients receive server responses here
• Port 647 — Also assigned to dhcp-failover, used by some implementations
• Port 546/547 — DHCPv6 (IPv6 equivalent of DHCP)

Why This Matters

Port 847 represents something important about how the Internet actually evolves. Sometimes messy, working solutions get deployed before clean, standardized ones arrive. Sometimes the standardized solution never arrives at all.

The protocol running on port 847 isn't perfect. It was never officially blessed. But it works. It's kept networks running for more than two decades. Every IP address your company's laptops received while the primary DHCP server was being patched—port 847 made that possible.

The Internet is full of these pragmatic compromises. Standards that never standardized. Specifications that lived as drafts forever. Protocols that work well enough that no one bothered to fix them properly.

Port 847 is one of them. And your network probably depends on it.