Trying to configure ipv4 and ipv6 addresses on hosts using one dhcp server fails.
David W. Hankins
dhankins at isc.org
Tue Aug 24 21:35:49 UTC 2010
On Tue, Aug 24, 2010 at 08:25:12PM +0200, Eddie Lania wrote:
> Maybe someone can help me with this?
The problem is that our TXT record (a simulacrum of the RFC based
DHCID) is computed using the DHCPv4 client identifier in DHCPv4's
case, and the DHCPv6 DUID in DHCPv6's case.
There is RFC 4361, which modified RFC 2131 to define that clients
provide a DHCPv6-identical IAID+DUID pair as their DHCPv4 client
identifier option contents. There is the minor inconvenience that
after these changes it may not be legal for a server to inspect them
depending upon RFC interpretation (non-normative text demanding the
field be considered "opaque" by servers, "not to be interpreted"), but
this is not the sort of thing to stop either experimentation or
This means that if the DHCPv4 client sent us a DUID as its
client-identifier, then we could experimentally use the DHCPv4-
supplied DUID as input to the TXT, and the DHCPv6 and DHCPv4 clients
would be seen by the algorithm as the same node.
The next trick is getting the DHCPv4 clients to send the same DHCPv6
DUID as their DHCPv6 counterpart, or at least sending a DUID at all.
So far I haven't seen evidence there are any clients that do this,
ours also doesn't currently.
So, welcome to the migration period.
In the interim, you can either use separate names for v4 and v6
(foo.example.com vs foo.v6.exmaple.com or similar), or you can
disable the conflict detection ("update-conflict-detection false;")
but this also means hosts can steal each others names.
David W. Hankins BIND 10 needs more DHCP voices.
Software Engineer There just aren't enough in our heads.
Internet Systems Consortium, Inc. http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the dhcp-users