The patch was applied successfully and I was able to build on Fedora 21 with these commands (if you have opinions about these, I'm happy to learn more about your build system - I'm still a Linux noob):
$ ./autogen.sh \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--with-nmtui
$ make
$ make install
The DHCP packets look good now and I got the occasional DDNS update to happen successfully. I write "occassional", because there's a new outstanding issue.
Windows DHCP has the option to protect DNS entries with a
DHCID RR next to the A/AAAA RR to prevents name squatting (
examples). It's not really Windows-specific, but from my 30 minute research there seems to be a problem with two dhclient instances (-4 and -6) requesting IPv4 and IPv6 addresses in short succession.
For illustration, let's say IPv4 is the first DHCP server transaction to finish. The DHCP server will request a DDNS update with a DHCID computed based on the DHCPv4 request. The DHCID RR is placed next to the A RR in DNS. The last string is the DHCID:
30,02/26/15,00:15:39,DNS Update Request,172.16.0.27,fedora.wghoch4.local,,,0,6,,AAIB9bp2uTdfLzJh0EvCVjZaAX8wFfhJnVtyWlwdswZmz6A=,
32,02/26/15,00:15:40,DNS Update Successful,172.16.0.27,fedora.wghoch4.local,,,0,6,,AAIB9bp2uTdfLzJh0EvCVjZaAX8wFfhJnVtyWlwdswZmz6A=,
When the DHCPv6 transaction finishes a couple of milliseconds later, the DHCPv6 server will request a DDNS update with a DHCID computed based on the DHCPv6 request, which is different:
11022,02/26/15,00:15:41,DNS IPV6 Update Request,2001:470:1f0b:c9a:d0fe:3fdd:9808:be77,fedora.wghoch4.local,,,,AAIBcviuOsLCzN+gMgFRRnSu7vCDQgeQWo3TyWyt6hbOyCc=,
11024,02/26/15,00:15:41,DNS IPV6 Update Successful,2001:470:1f0b:c9a:d0fe:3fdd:9808:be77,fedora.wghoch4.local,,,,AAIBcviuOsLCzN+gMgFRRnSu7vCDQgeQWo3TyWyt6hbOyCc=,
The DNS server will check the second DHCID against the one it already knows and reject the DDNS update (the log above says it was successful, but Windows logs generally suck ;-)
It's easy to confirm that the DHCID RR is actually the culprit. Just delete it from the DNS, re-request DHCPv6 and the AAAA RR shows up.
My dhclient man page has the following snippet:
-df duid-lease-file
Path to a secondary lease file. If the primary lease file doesn't contain a DUID this file will be searched. The
DUID read from the secondary will be written to the primary. This option can be used to allow an IPv4 instance of
the client to share a DUID with an IPv6 instance. After starting one of the instances the second can be started
with this option pointing to the lease file of the first instance. There is no default. If no file is specified
no search is made for a DUID should one not be found in the main lease file.
The
DUID is a main contributor to the DHCID. As both IPv4 and IPv6 addresses are requested by/for the same interface it seems NM should make sure to use the same DUID for its requests.
I'll try forging my DUIDs to be the same and also try "send dhcp6.client-id <something>" and report my findings.
