GNOME Bugzilla – Bug 681764
dhcp: more than one IPv6 address via DHCPv6
Last modified: 2015-08-17 08:29:30 UTC
Hi developers, If I want to deliver more than one IPv6 address to DHCPv6 clients (a global one and an ULA for example) NetworkManager only uses one of them. The funny thing is that dhclient being used directly accepts several addresses, but dhclient used by NetworkManager ignores the others randomly. In an IPv6 world more addresses will be useful, so what do you thing about adding this (via dhclient yet existing) functionality? Best regards Henri Wahl
Hi, please test it with e.g. ISC DHCP server and post the server configuration so that we have a test case to work with. The reportedly working dhclient is from the same package so it shouldn't be too hard. Cheers, Pavel
Hi, I am not able to deliver 2 or more addresses with ISC dhcpd or dibbler-server - if anyone has a clue how to do this let me know. I am working on an own DHCPv6 server implementation which is capable of delivering several addresses and it works pretty well with Windows and Linux clients (dhclient and dibbler-client). While testing I found accidently that dhclient does but the dhclient-based NetworkManager doesn't take more than one address. If the server is ready to be released (soon I hope) it might be used for tests. Regards Henri
Thanks for all information. However, because there is currently no implementation and no testing configuration, and nobody will probably work on it any soon, I'm closing the bug. You can ammend it or open a new one when there is: 1) A common implementation of DHCPv6 server that serves multiple addresses 2) At least some implementation of DHCPv6 server, a reasonably written testcase and a patch for NetworkManager
Created attachment 227024 [details] Config file for dhcpy6d for delivery of 2 IPv6 addresses
Hi, meanwhile the mentioned DHCPv6 server is available at http://sourceforge.net/projects/dhcpy6d/. Run with the attached config file "dhcpy6d.py dhcpy6d-testcase-2-addresses.conf" (for some reason it has been detected as octet-stream by Bugzilla but is a plain text file) and it delivers 2 addresses to clients. Works well with Windows 7+ and dhclient coming with Fedora 17: p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fd00:db8:db8::800:27b2:8b8d prefixlen 64 scopeid 0x0<global> inet6 fe80::a00:27ff:feb2:8b8d prefixlen 64 scopeid 0x20<link> inet6 2001:db8::1513:9db3:2bf5:132c prefixlen 64 scopeid 0x0<global> ether 08:00:27:b2:8b:8d txqueuelen 1000 (Ethernet) RX packets 112 bytes 25577 (24.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 504 bytes 107050 (104.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 If NM takes care of IPv6 (set to automatic) the resulting ifconfig is this: p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fd00:db8:db8::800:27b2:8b8d prefixlen 64 scopeid 0x0<global> inet6 fe80::a00:27ff:feb2:8b8d prefixlen 64 scopeid 0x20<link> ether 08:00:27:b2:8b:8d txqueuelen 1000 (Ethernet) RX packets 126 bytes 27473 (26.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 539 bytes 112692 (110.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 One address is missing. As dhclient is capable of handling more than one address it should be no big change to add this functionality to NM too? Best regards Henri
Thanks for the new information. Reopening.
Ok, does either dhclient or dhcpcd support reporting both IP addresses? The NM code only handles one IP address passed back from dhclient. If somebody can get a dump of the environment that dhclient sends to its script we can figure out how to get the additional addresses into NM. To do that you can rename nm-dhcp-client.action (whcih is in /usr/libexec or /usr/lib/NetworkManager or /usr/lib depending on your distro) and replace it with a short script that does this: #!/bin/bash env > /tmp/dhcp-env /path/to/new/nm-dhcp-client.action $@
Following your instructions I get the following environment: new_ip6_address=fd02::800:273d:7a9a interface=p2p1 new_life_starts=1360621619 new_max_life=7200 new_starts=1360621619 reason=BOUND6 new_dhcp6_client_id=0:1:0:1:18:ac:28:1a:8:0:27:3d:7a:9a new_preferred_life=5400 new_iaid=27:3d:7a:9a requested_dhcp6_domain_search=1 new_rebind=4050 PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin pid=3541 requested_dhcp6_name_servers=1 new_dhcp6_server_id=0:1:0:1:51:19:6b:b6:8:0:27:ae:9c:9 PWD=/ new_dhcp6_domain_search=domain. new_renew=2700 SHLVL=1 new_ip6_prefixlen=64 _=/bin/env ifconfig shows: p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255 inet6 fe80::a00:27ff:fe3d:7a9a prefixlen 64 scopeid 0x20<link> pure dhclient -6 -d give this result: Bound to *:546 Listening on Socket/p2p1 Sending on Socket/p2p1 PRC: Confirming active lease (INIT-REBOOT). XMT: Forming Confirm, 0 ms elapsed. XMT: X-- IA_NA 27:3d:7a:9a XMT: | X-- Confirm Address fd01::800:273d:7a9a XMT: | X-- Confirm Address fd02::800:273d:7a9a XMT: V IA_NA appended. which leads to ifconfig: p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255 inet6 fe80::a00:27ff:fe3d:7a9a prefixlen 64 scopeid 0x20<link> inet6 fd01::800:273d:7a9a prefixlen 64 scopeid 0x0<global> inet6 fd02::800:273d:7a9a prefixlen 64 scopeid 0x0<global> Obviously the environment given from dhclient to NM only has one address. May this be triggered by the dhclient call from NM? Regards
Sorry, in the first ifconfig I did not past the line containing the single IPv6 address. It must be p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255 inet6 fe80::a00:27ff:fe3d:7a9a prefixlen 64 scopeid 0x20<link> inet6 fd02::800:273d:7a9a prefixlen 64 scopeid 0x0<global>
Fun. So what happens here is that the dhclient script is executed *multiple* times, once for each address bound in the lease. NM clearly doesn't handle that yet. Can you do one more test for me? Can you echo the environment out to individually named files? Maybe change the intercept bits to: #!/bin/bash env > /tmp/dhcp-env.$RANDOM /path/to/new/nm-dhcp-client.action $@ and then tar up the random ones, and also (very important) run "ls -al /tmp/dhcp-env.*" so I can see what the timestamps on those files are? What I'm trying to get at here is to figure out the sequence of calls to the dhclient script and how we need to track state over the multiple calls. Thanks!
Created attachment 235814 [details] dhcp-env files
You are right, there are several files now. I did a env > /tmp/dhcp-env.`date +%s`.$RANDOM which lead to [root@localhost ~]# ls -lt /tmp/dhcp-env.* -rw-r--r--. 1 root root 514 12. Feb 21:38 /tmp/dhcp-env.1360701483.13529 -rw-r--r--. 1 root root 514 12. Feb 21:38 /tmp/dhcp-env.1360701483.6673 -rw-r--r--. 1 root root 110 12. Feb 21:38 /tmp/dhcp-env.1360701482.28880 -rw-r--r--. 1 root root 109 12. Feb 21:38 /tmp/dhcp-env.1360701480.3653 env files are attached.
NM bugzilla reorganization. Sorry for the bug spam.
So that means each call will generate its own NMIP6Config instance and that nm-device will replace the original config with the new one. The question is, whether we can actually check that the multiple script runs belong to one dataset. If that can be done, it's not a problem to store the information with NMDHCPClient instance and reuse the already listed addresses for the generated NMIP6Config instance. Also, I'm curious whether the same applies for IPv4.
(In reply to comment #14) > So that means each call will generate its own NMIP6Config instance and that > nm-device will replace the original config with the new one. The question is, > whether we can actually check that the multiple script runs belong to one > dataset. Maybe we can key off "new_life_starts" or something like that? Here's the relevant environment dump, and the only difference is "new_ip6_address" between the two runs: -new_ip6_address=fd02::800:273d:7a9a +new_ip6_address=fd01::800:273d:7a9a interface=p2p1 new_life_starts=1360701482 new_max_life=7200 new_starts=1360701482 reason=BOUND6 new_dhcp6_client_id=0:1:0:1:18:ac:28:1a:8:0:27:3d:7a:9a new_preferred_life=5400 new_iaid=27:3d:7a:9a requested_dhcp6_domain_search=1 new_rebind=4050 PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin pid=2468 requested_dhcp6_name_servers=1 new_dhcp6_server_id=0:1:0:1:51:1a:a6:15:8:0:27:ae:9c:9 PWD=/ new_dhcp6_domain_search=domain. new_renew=2700 SHLVL=1 new_ip6_prefixlen=64 _=/bin/env so perhaps for any given run of dhclient, any additional BOUND/RENEW events that come in with the same lease start time should simply add the new address to the existing config, and not replace it. > If that can be done, it's not a problem to store the information with > NMDHCPClient instance and reuse the already listed addresses for the generated > NMIP6Config instance. Yeah, we'd need to store them all in the same IP6Config when they were all received. > Also, I'm curious whether the same applies for IPv4. Good question, but I've never heard of it on IPv4.
(In reply to comment #15) > (In reply to comment #14) > > whether we can actually check that the multiple script runs belong to one > > dataset. > > Maybe we can key off "new_life_starts" or something like that? Sounds good enough, you might want to combine it with the server id, just in case. > so perhaps for any given run of dhclient, any additional BOUND/RENEW events > that come in with the same lease start time should simply add the new address > to the existing config, and not replace it. Fair enough. > > If that can be done, it's not a problem to store the information with > > NMDHCPClient instance and reuse the already listed addresses for the generated > > NMIP6Config instance. > > Yeah, we'd need to store them all in the same IP6Config when they were all > received. Originally wanted a GArray for addresses, but caching the whole IP6Config sounds even better. > > Also, I'm curious whether the same applies for IPv4. > > Good question, but I've never heard of it on IPv4. OK.
Hi, are here any news regarding this issue? With slowly increasing IPv6 adoption it would be nice to have a Networkmanager that is 100% ready for DHCPv6 :-) Regards
No news from me, anyone is free to take the bug and work on it.
(random note) or possibly we should key off the same IAID, not quite sure.
Created attachment 308732 [details] [review] [PATCH] device: accept multiple addresses in a DHCPv6 lease
(In reply to Beniamino Galvani from comment #20) > Created attachment 308732 [details] [review] [review] > [PATCH] device: accept multiple addresses in a DHCPv6 lease LGTM
The patch looks good to me too.
Merged to master: 1d6e8e8da724 device: accept multiple addresses in a DHCPv6 lease