Re: DHCPv6 DDNS registration with FQDN

2015-02-26 Thread Dan Williams 
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/ RR to prevents name squatting (examples
 https://technet.microsoft.com/en-us/library/dd759188.aspx?f=255MSPPError=-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.localAAIBcviuOsLCzN+gMgFRRnSu7vCDQgeQWo3TyWyt6hbOyCc=,
 11024,02/26/15,00:15:41,DNS IPV6 Update
 Successful,2001:470:1f0b:c9a:d0fe:3fdd:9808:be77,fedora.wghoch4.localAAIBcviuOsLCzN+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  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

Re: DHCPv6 DDNS registration with FQDN

2015-02-26 Thread Alexander Groß 
​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
https://tools.ietf.org/html/draft-ietf-dnsext-dhcid-rr-13 next to the
A/ RR to prevents name squatting (examples
https://technet.microsoft.com/en-us/library/dd759188.aspx?f=255MSPPError=-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:

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.localAAIBcviuOsLCzN+gMgFRRnSu7vCDQgeQWo3TyWyt6hbOyCc=,
11024,02/26/15,00:15:41,DNS IPV6 Update
Successful,2001:470:1f0b:c9a:d0fe:3fdd:9808:be77,fedora.wghoch4.localAAIBcviuOsLCzN+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  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.

I'll try forging my DUIDs to be the same and also try send dhcp6.client-id
something and report my findings.

Beste Grüße,

Alex
-- 
Alexander Groß
http://therightstuff.de/

On Wed, Feb 25, 2015 at 5:43 PM, Dan Williams d...@redhat.com wrote:

 On Wed, 2015-02-25 at 17:40 +0100, Alexander Groß wrote:
  On Wed, Feb 25, 2015 at 5:33 PM, Dan Williams d...@redhat.com wrote:
 
   Hmm, it seems to apply with 'git am  /path/to/mail.mbox' for me.  What
   version of NetworkManager are you using?  I'll generate a non-git patch
   for that version.
  
 
  I made a fresh clone and tried to apply if on the master branch.​ The
  version of NM is use on CentOS or Fedora shouldn't be relevant to that,
 but
  I have
 
  * NetworkManager-0.9.10.1-3.20150219git.fc21.x86_64 and
  * NetworkManager-0.9.9.1-29.git20140326.4dba720.el7_0.x86_64.
 
  I have to admit I don't have any mailbox setup on my boxes. I copied the
  patch from the nm-list web interface and made sure line endings are
 correct.

 Try the attached patch which I've done against 0.9.10; I believe it'll
 apply with just:

 cd NetworkManager/
 patch -p1  /path/to/patch

 Thanks!
 Dan


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list