On Thu, 2015-02-26 at 11:12 +0100, Alexander Groß wrote: > 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.
Excellent. I'll merge the patch then. > Windows DHCP has the option to protect DNS entries with a DHCID RR > <https://tools.ietf.org/html/draft-ietf-dnsext-dhcid-rr-13> next to the > A/AAAA RR to prevents name squatting (examples > <https://technet.microsoft.com/en-us/library/dd759188.aspx?f=255&MSPPError=-2147217396>). > 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: Yes, the interaction between DHCPv6 DUID and the IPv4 client ID is a bit more complicated than just treating the two separately as used to be the case. I don't think we can ignore existing client IDs since that would break stable IP addresses for many people, but we can start using the DUID to create the v4 ClientID for new leases, I think. That'll take a bit more work though. > 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 <https://tools.ietf.org/html/rfc3315#section-9> 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. Yes, it should, according to http://www.ietf.org/rfc/rfc4361.txt . I've filed https://bugzilla.gnome.org/show_bug.cgi?id=745243 to track the issue. Thanks for your help! Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
