DHCP leases and MAC addresses

Two different identifiers, one column

Every DHCPv4 message carries a field called chaddr, plus hardware type and length fields. On an Ethernet client request it normally contains the interface's link-layer address, but it is client-supplied, may be randomized or spoofed, and may represent a non-Ethernet hardware type.

A client may also send option 61, the client identifier. A conforming server normally uses it to identify the client when it is present and falls back to chaddr otherwise. Which values are retained or displayed is server-specific, and the column heading rarely tells you which one you are looking at.

That distinction explains most lease-table weirdness: one machine holding two leases because its firmware and its operating system identify themselves differently, a reservation that never applies because it was written against the MAC while the client is identified by something else, and two devices that appear to share an address because they share a client identifier.

The client identifier is not a MAC, but it may contain one

A legacy RFC 2132 client identifier is a type byte followed by a value. Type 01 is the ARP hardware type for Ethernet and is commonly followed by a six-byte Ethernet address. That common form is why the field is so often mistaken for a MAC. Cisco IOS can display those bytes in dotted hexadecimal:

0100.1b21.3c4d.5e

That is seven bytes, not six: 01 is the hardware type and the remaining 00:1b:21:3c:4d:5e is the address. Because Cisco groups the output in fours, the type byte shares a group with the first address byte, and reading the first four digits as the start of a MAC shifts every byte after it. The tell is the trailing group of two digits, which no real MAC address in this notation has.

Type 00 introduces an opaque identifier, while other hardware types may introduce other link-layer address formats. RFC 4361 uses type 255 followed by an interface association identifier and a DUID, so there may be no MAC in the identifier at all. When option 61 and chaddr disagree, use option 61 to understand the lease identity and the observed link-layer address to identify the interface used for that exchange. Neither is authenticated.

A long client identifier with no embedded MAC

This example is based on a Cisco DHCP binding, with the client-specific values replaced. Cisco wraps the identifier across three lines:

ff12.3456.7800.0200.
00ab.11a1.b2c3.d4e5.
f607.18

Joining the lines gives 19 bytes. The leading ff identifies an RFC 4361 client ID; the next four bytes are the IAID. The remaining bytes form a DUID:

ff                       RFC 4361 client ID
12 34 56 78              IAID
00 02                    DUID-EN
00 00 ab 11              Enterprise number 43793
a1 b2 c3 d4 e5 f6 07 18  Opaque identifier

The DUID type is 2 (DUID-EN), and enterprise number 43793 belongs to systemd. This matches the format systemd generates using a hash of its machine ID, although a client can override the identifier. The enterprise number identifies the identifier’s namespace, not the network-card manufacturer.

See systemd’s DUID generation documentation for the enterprise-number format.

In the original case, an ARP lookup for the same IP address in the same VRF supplied the MAC. Here, the illustrative replacement is 001b.213c.4d5e (00:1b:21:3c:4d:5e). This identifier has no MAC field, and there is no reversible formula to recover that MAC from its opaque value or the IAID. The ARP entry supplies the association; decoding the client ID alone cannot.

This does not mean every long identifier is opaque. Some encode readable text containing a MAC; DUID-LL and DUID-LLT contain link-layer address fields. The identifier’s format determines what can be recovered.

The formats you will actually paste

These illustrative excerpts use the same address to compare formats. Columns, date formatting, and optional fields vary by release and configuration.

ISC dhcpd, dhcpd.leases ISC DHCPISC stands for Internet Systems Consortium, the organization behind this older DHCP server. Its server program, dhcpd, stores leases in a text file called dhcpd.leases. More about ISC DHCP (opens in a new tab)

lease 10.0.0.51 {
  starts 3 2026/08/19 10:12:04;
  ends 3 2026/08/19 22:12:04;
  cltt 3 2026/08/19 10:12:04;
  binding state active;
  hardware ethernet 00:1b:21:3c:4d:5e;
  uid "\001\000\033!<M^";
  client-hostname "server";
}

hardware ethernet is the MAC. The uid is option 61 written here as a quoted string with octal escapes for non-printable bytes, and it starts with \001, the same type byte as above, followed by the same six address bytes. ISC can also write this field as colon-separated hexadecimal, depending on its lease-id-format setting. The leading digit in these date fields is the day of the week, and this default format uses UTC. With db-time-format local, ISC instead writes an epoch value followed by a local-time comment.

ISC dhcpd, log lines ISC DHCPISC stands for Internet Systems Consortium, the organization behind this older DHCP server. Its server program, dhcpd, stores leases in dhcpd.leases and also writes log messages like those below. More about ISC DHCP (opens in a new tab)

DHCPDISCOVER from 00:1b:21:3c:4d:5e via eth0
DHCPOFFER on 10.0.0.51 to 00:1b:21:3c:4d:5e (server) via eth0
DHCPREQUEST for 10.0.0.51 from 00:1b:21:3c:4d:5e (server) via eth0
DHCPACK on 10.0.0.51 to 00:1b:21:3c:4d:5e (server) via eth0

The name in parentheses is the client-supplied hostname. It is useful context, but it is unauthenticated and may be missing, stale, or spoofed. The server chooses the log notation; the client does not send punctuation as part of its hardware address.

dnsmasq

1787177524 00:1b:21:3c:4d:5e 10.0.0.51 server 01:00:1b:21:3c:4d:5e

For this IPv4 lease, five fields and no header: expiry as a Unix timestamp, MAC, IP, hostname, client identifier. A missing hostname or client identifier is written as an asterisk; zero expiry denotes an infinite lease. The last field is the type byte and the address again, this time colon-separated, which is why a naive parser reports seven-byte addresses from dnsmasq files.

Kea, memfile CSV (schema varies by version) KeaKea is a newer DHCP server from the Internet Systems Consortium (ISC), built to replace ISC DHCP. It supports IPv4 and IPv6 and can store leases in CSV files or a database. More about Kea (opens in a new tab)

address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state
10.0.0.51,00:1b:21:3c:4d:5e,01:00:1b:21:3c:4d:5e,3600,1787177524,1,0,0,server,0

The first row names the fields, but use the actual header because Kea's schema varies by version. A lease can remain after expiry, and reclaimed leases may be retained until lease-file cleanup, so a row's presence is not proof of a current lease.

Windows Server

Client IP Address  Subnet Mask     Unique ID           Lease Expires          Type
10.0.0.51        - 255.255.255.0 - 00-1b-21-3c-4d-5e - 8/19/2026 10:12:04 PM -D

"Unique ID" is the identifier, not necessarily the hardware address, and the trailing letter is the lease type. Times are the server's local time, not UTC.

Cisco IOS

IP address       Client-ID/              Lease expiration        Type
                 Hardware address/
                 User name
10.0.0.51        0100.1b21.3c4d.5e       Aug 19 2026 10:12 PM    Automatic

The header wraps across three lines because the column can show the client identifier, hardware address, or user name used for the binding.

MikroTik RouterOS

 # ADDRESS      MAC-ADDRESS        HOST-NAME  SERVER  STATUS
 0 10.0.0.51    00:1B:21:3C:4D:5E  server     dhcp1   bound

DHCPv6 uses a DUID instead of chaddr

DHCPv6 dropped the hardware address field entirely. Clients normally identify themselves with a DUID, a DHCP Unique Identifier. Servers treat it as opaque, and a client normally keeps one DUID across interfaces and restarts, although privacy profiles and local configuration can rotate it. Whether you can get a MAC out of one depends on which kind it is:

Two consequences. A link-layer address recovered from a DUID names the interface used to create it, which may be a network card that was removed years ago, so it is a hint rather than an identity. A DUID is normally stable across interfaces, while IPv4 identifiers may be per-interface or change between boot stages. Where the DUID is useless, a first-hop relay can add the client's link-layer address as a separate option.

Why the address in a lease may not identify the device

Where the lease identifies a physical location, it is usually not the MAC that does it. Option 82 can carry relay-supplied circuit and remote identifiers whose encoding is implementation-specific; a circuit ID often identifies an access port. Treat it as stronger location evidence only when trusted infrastructure inserts it and rejects client-supplied values.

Timestamps, and what an expired lease means

Lease files keep expired records. ISC dhcpd appends lease changes and periodically rewrites the database; when declarations repeat, only the last one counts. dnsmasq normally stores a Unix expiry timestamp, but builds without a usable real-time clock store remaining lease duration instead. Kea stores an expiry timestamp, and Windows may retain records after their local-time expiry.

A lease record shows an assignment or configured binding, not proof that a device is online. Static reservations may exist before a client ever connects. A gateway's ARP cache shows recent IPv4 neighbor resolution but may be stale or incomplete. Combine it with active reachability checks and switch or access-point observations; the lease still supplies useful historical context such as the client-provided hostname.

What macs4days does with lease output

The parser recognizes MAC addresses in lease files and command output. Colon, hyphen, dotted and bare notations are all recognized, so a lease list, a log excerpt, and a show ip dhcp binding can go in together, from as many servers as you like.

The Cisco client identifier is handled as the special case it is: a seven-byte 0100.1b21.3c4d.5e is read as hardware type 01 plus the six address bytes, and yields 00:1b:21:3c:4d:5e. Identifiers with any other type byte, and longer identifiers that hold no address, are not decoded as this Cisco format. This is a text extractor, not a general option 61 or DUID decoder; inspect unfamiliar identifiers in the original output.

ISC log lines can supply the hostname in parentheses before via, plus the IP and interface. Recognized aligned headers can help with other tables, but a familiar label alone does not guarantee complete extraction. In the RouterOS excerpt above, the MAC and IP are recovered; HOST-NAME and STATUS are not.

One deliberate restraint is worth knowing about. A bare twelve-character token is only read as an address when it contains at least one letter, because a lease file is full of twelve-digit numbers that are timestamps, serial numbers, and identifiers. An all-digit token is accepted only when a table header says that column holds addresses. The same rule keeps timestamps in dnsmasq files from becoming devices, and a seven-group client identifier sitting beside a real address does not turn into a second, invented one.

The parser does not assemble raw ISC lease blocks or CSV rows into records. It detects the MAC in those sources, but the raw block's opening IP, lease times, and hostname do not attach to it, and dnsmasq or Kea CSV fields such as hostname and expiry are not mapped by position. The Cisco expiry date above leaves age empty. The Windows example yields only 10:12:04 in age, without its date or PM suffix; that is not a reliable lease-expiry value. If you have the choice, paste an ISC log line or a supported aligned CLI table. Rows with the same normalized MAC are merged, so combining servers or time periods does not preserve each lease as a separate record. Lines with no recognized MAC remain in the unparsed output.

Sources and further reading

The protocol rules are in RFC 2131 (DHCPv4), RFC 2132 (client identifiers), and RFC 4361 (DUID-based DHCPv4 identifiers). For DHCPv6 and relay information, see RFC 9915 (DHCPv6), RFC 6939 (client link-layer address option), and RFC 3046 (option 82).

Format references: ISC dhcpd lease-file manual, dnsmasq's lease-file explanation, Kea lease expiration, Cisco DHCP binding reference, and RouterOS DHCP server manual.

For related output, see Reading ARP tables and MAC address formats. For what a vendor match means, read OUI and IEEE registries.