= phenomenon =

A bug has been filed, and extensively documented and discussed.

A solution has been found and tested, with results documented as well.

Yet this bug has not moved to closure, in nearly 4 years.

See: https://bugzilla.redhat.com/show_bug.cgi?id=560361

= background analysis =

In many bridged environments (Wifi-to-Ethernet, Ethernet-to-DOCSIS, Ethernet-to-DSL [PPPoE]) the bridge might mangle the DHCP client's MAC address, replacing it with its own.

The workaround is to always use a client-id derived from the hw type and the hw address, as per RFC-3315 Section 9.4:

{{{
9.4. DUID Based on Link-layer Address [DUID-LL]

This type of DUID consists of two octets containing the DUID type 3,
a two octet network hardware type code, followed by the link-layer
address of any one network interface that is permanently connected to
the client or server device. For example, a host that has a network
interface implemented in a chip that is unlikely to be removed and
used elsewhere could use a DUID-LL. The hardware type MUST be a
valid hardware type assigned by the IANA, as described in RFC 826
[14]. The hardware type is stored in network byte order. The
link-layer address is stored in canonical form, as described in RFC
2464 [2]. The following diagram illustrates the format of a DUID-LL:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               3               |    hardware type (16 bits)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.             link-layer address (variable length)              .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The choice of network interface can be completely arbitrary, as long
as that interface provides a unique link-layer address and is
permanently attached to the device on which the DUID-LL is being
generated. The same DUID-LL SHOULD be used in configuring all
network interfaces connected to the device, regardless of which
interface's link-layer address was used to generate the DUID.

DUID-LL is recommended for devices that have a permanently-connected
network interface with a link-layer address, and do not have
nonvolatile, writable stable storage. DUID-LL MUST NOT be used by
DHCP clients or servers that cannot tell whether or not a network
interface is permanently attached to the device on which the DHCP
client is running.
}}}

= implementation recommendation =

As per the bug, recommending that the file /etc/dhcp/dhclient.conf be added to the RPM payload and that it include the contents:

{{{

required in environments where a bridge might be clobbering the forwarded

packet's MAC address (common in Wifi, Docsis, or ADSL bridging scenarios)

send dhcp-client-identifier = hardware;
}}}