68
Summary
- // if you see it open
- LAN threat model: rogue/spoofing DHCP server enabling MitM via malicious gateway/DNS; DHCP starvation (address-pool-exhaustion DoS); and client-side code execution via crafted DHCP option values. Notable CVEs: CVE-2011-0997 (ISC dhclient 3.0.x-4.2.x RCE via shell metacharacters in a server-supplied hostname passed to dhclient-script; CVSS 7.5 HIGH; patched in 4.2.1-P1 / 3.1-ESV-R1) and CVE-2018-1111 'DynoRoot' (Red Hat/Fedora NetworkManager DHCP client command injection via crafted option 114; root RCE). Mitigations: DHCP snooping, dynamic ARP inspection, ACLs limiting 67/68 to trusted uplink ports, monitoring for multiple simultaneous DHCP server responses.
- // analyst note
- An open/active port 68 is a normal LAN client artifact, not an internet service. Treat the surface as local: watch for rogue DHCP responders and unpatched client stacks rather than external exposure.
About port 68/tcp.
Port 68/tcp is registered with IANA as bootpc with the description "Bootstrap Protocol Client," assignee Bill Croft, and a blank reference field — it is dual-registered on both TCP and UDP (lines 160–161 of the IANA service-names-port-numbers registry). In practice essentially all real bootpc traffic is UDP, not TCP: the TCP assignment exists for completeness but has no documented real-world use. On UDP, port 68 is the client-side port of the BOOTP/DHCP pair — a host seeking IP configuration binds to 68 to receive the server's replies (Offer, Acknowledgement, NAK) during the DORA handshake, while the server listens on the companion port 67. DHCP is a broadcast-based, link-local protocol; its messages do not cross a router without a relay agent (an IP helper per RFC 1542), so port 68 is rarely seen on internet-facing interfaces and produces almost no external scan results. For an analyst the threat model is local: a responsive or active port 68 belongs to the LAN attack surface, where rogue/spoofing DHCP servers can win the race against the legitimate server to hand out a malicious gateway or DNS (MitM), and DHCP starvation can exhaust the address pool (DoS). The most consequential historic vulnerabilities are client-side: CVE-2011-0997 (ISC dhclient 3.0.x–4.2.x, remote code execution via shell metacharacters in a server-supplied hostname passed to dhclient-script; patched in 4.2.1-P1 / 3.1-ESV-R1) and CVE-2018-1111 ("DynoRoot," Red Hat/Fedora NetworkManager DHCP client command injection via a crafted option 114, root RCE). The IANA reference field is blank — the DHCP RFCs (RFC 2131, RFC 1542) reference the port by convention rather than via a formal port-number assignment RFC, so no RFC is recorded here. Standard mitigations are DHCP snooping on managed switches, dynamic ARP inspection, ACLs restricting 67/68 to trusted uplink ports, and alerting on multiple simultaneous DHCP server responses.
- IANA assignment
bootpc— "Bootstrap Protocol Client"; reference (blank — no RFC cited in IANA registry); assignee Bill Croft; dual-registered 68/tcp + 68/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (lines 160–161)- Range class
- well-known (0–1023)
- Related ports
- 67/udp (bootps — DHCP/BOOTP server side); the BOOTP/DHCP pair
Primary use
DHCP/BOOTP client-side receive port; the client binds to 68 to receive server replies (Offer/Ack/NAK) during the DORA handshake while the server listens on 67
Common software
ISC DHCP client (dhclient), Windows DHCP client service, NetworkManager, systemd-networkd, udhcpc (BusyBox/embedded), Cisco IOS / Junos DHCP client
Security implications
LAN threat model — rogue/spoofing DHCP server (MitM via malicious gateway/DNS), DHCP starvation (pool-exhaustion DoS), and client-side RCE via crafted option values. Key CVEs: CVE-2011-0997 (ISC dhclient RCE, CVSS 7.5 HIGH); CVE-2018-1111 "DynoRoot" (NetworkManager DHCP client command injection, root RCE)
- TCP vs UDP
- all real bootpc/DHCP traffic is UDP; TCP/68 is registered but has no documented real-world use [Likely] — IANA registry (assignment) + howtonetwork.com (UDP-only operative transport)
- Scope
- broadcast-based, link-local protocol; does not cross routers without a relay agent (IP helper, RFC 1542); rarely internet-exposed and near-empty in external scans [Confirmed] — howtonetwork.com, manageengine DHCP port KB
- Mitigations
- DHCP snooping, dynamic ARP inspection, ACLs limiting 67/68 to trusted uplink ports, monitoring for multiple simultaneous DHCP server responses [Confirmed] — pentestpad.com, manageengine DHCP port KB
- Analyst note
- An open/active port 68 is a normal LAN client artifact, not an internet service. Treat the surface as local: watch for rogue DHCP responders and unpatched client stacks rather than external exposure.
About port 68/udp.
Port 68/udp is the client-side port for DHCP and BOOTP — the port on which a host listens for the server's replies during address assignment. DHCP deliberately uses two fixed ports rather than ephemeral ones: the server listens on 67 and the client on 68, a design inherited from BOOTP so that broadcast replies can be delivered deterministically to a client that does not yet have an IP address. In the four-step DORA exchange, the client sources its Discover and Request from port 68 (initially from 0.0.0.0, since it has no address) and the server's Offer and Ack are delivered to port 68; on routed networks a relay agent mediates between the client's broadcast domain and the server. The protocol lineage is BOOTP (RFC 951, 1985) and DHCP (RFC 1531 → RFC 2131, 1997, with options in RFC 2132); the DHCPv6 client uses the separate port 546. From a security standpoint, port 68 is the client side of the same unauthenticated exchange, so the relevant exposures are largely those a client inherits — a rogue DHCP server on the segment can feed it a malicious gateway or DNS for man-in-the-middle, and the defenses are network-side controls such as DHCP snooping, port security, and IP Source Guard rather than anything the client port itself enforces. The IANA registry leaves the 68 Reference field blank (the entry is attributed to Bill Croft), so the protocol RFCs are linked separately rather than presented as the registry citation. For an analyst, traffic to or from 68/udp is normal client behavior; it is meaningful mainly as the counterpart to server port 67, and the investigative focus for DHCP abuse belongs on the server side and on switch-level snooping.
- IANA assignment
bootpc— "Bootstrap Protocol Client"; reference (blank — no RFC cited in IANA registry); assignee/contact Bill Croft; governing protocols RFC 951 (BOOTP) + RFC 2131 (DHCP), not the IANA-cited reference [IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry- Range class
- well-known (0–1023)
- Prevalence
- nmap-services open-frequency 0.140118 (present on essentially every DHCP client) [Well-established] — nmap-services file
- Related ports
- 67 (bootps, DHCP server); 546 (DHCPv6 client) / 547 (DHCPv6 server)
Primary use
DHCP/BOOTP client — receives server Offer/Ack during the DORA exchange
Other/unofficial uses
none notable beyond DHCP/BOOTP [n/a]
Security implications
client side of an unauthenticated exchange; exposed to rogue-DHCP MITM (attacker gateway/DNS); defenses are network-side (DHCP snooping, port security, IP Source Guard)
Typically seen on
essentially every DHCP client device (workstations, phones, IoT, servers obtaining leases)
- Analyst note
- Traffic to/from 68/udp is normal client behavior; interpret it as the counterpart to server port 67. Focus DHCP-abuse triage on the server side and switch-level DHCP snooping.
Service assignments.
| Name | Protocol | Description | Open frequency |
|---|---|---|---|
| dhcpc | UDP | DHCP/Bootstrap Protocol Client | 14.01% |
| dhcpc | TCP | bootpc | 0.01% |
Service assignments from the IANA Service Name and Transport Protocol Port Number Registry, with open-frequency data from nmap-services.