source/setup/provision does not support IPv6. The changes that need to be made are: 1) I would suggest a new option in the provision script to enable IPv6 provisioning. It could be called --enable-ipv6. 2) The provision.js script in source/scripting/libjs needs to obtain the first IPv6 for the host. At present it gets the IPv4 address in the function hostip(). This either needs to be changed to return the IPv6 address as well or a new function could be created, say hostip6() that returns the IPv6 address. 3) For IPv4 you can specify the address as a command line option called --host-ip. There needs to be an equivalent option for IPv6 or this options needs to be modified to detect and accept IPv6 address formats. 4) A new provsion.zone template needs to be created. I would suggest having another file for IPv6 called provision6.zone. It needs the following lines adding to those in the current provision.zone file. The variable ${HOSTIP6} must contain the IPv6 address: IN AAAA ${HOSTIP6} ${HOSTNAME} IN AAAA ${HOSTIP6} 5) The source/setup/provision script needs to be modified to use the provision6.zone file instead of the provision.zone file if the option --enable-ipv6 is used. An error should be generated if no IPv6 address can be found and this option is used. Let me know if you have any questions or need this testing. Regards, David
-ENOPATCH? :-) This sounds interesting, any chance you can code this up?
Yes! Thought you might ask. I'll fit it in on my holiday...
I didn't have time on my holiday to do this. Hopefully, I'll get some free time soon. Anyway, I have had further thoughts that I'd like to bounce off you. In Windows the DC adds the DNS resource records to the zone using DDNS. In theory, the zone can be hosted on any DNS server that supports DDNS. The snag with using BIND for the DNS server has always been its lack of support for the security mechanism used by Windows, that is GSS-TSIG. Wouldn't it be better to change the provisioning script so that it uses DDNS to update the zone data? Issues are: 1) What do you do if the DNS server does not support DDNS? 2) What if you want to use GSS-TSIG to secure the DDNS updates? (solution could be use to use development version of BIND that does include support for GSS-TSIG.) 3) Do you allow Samba4 to provision using BIND's TSIG? Should this be a new BUG?
Created attachment 3229 [details] Add provision support for IPv6 Thanks to David for all his research into enabling IPv6 in samba! Instead of explicitly enabling IPv6 using an --enable-ipv6 flag to provision, as suggested by David, the IPv6 address is probed within a try/catch if not specified as a command-line argument to provision. I have verified this patch works with the current S4 codebase with "make test" and testing basic client functionality under Windows XP both with and without the MS TCP/IP version 6 protocol installed.
Per my comments on IRC: I would like to see the existing zone file re-used, with a 'whole of line' sub, for the cases where we need to put in the additional address. This would avoid the two files falling out of sync. Otherwise, this looks really good Thanks!
Created attachment 3230 [details] Add provision support for IPv6 Per an IRC converation w/ Andrew Bartlet, the patch has been updated to use whole-line substitution from a single zone template file.
Created attachment 3231 [details] Add provision support for IPv6 Obvious naming change from Andrew Bartlet on IRC. *_WC_* is not a wildcard record, but instead a record at the base of $ORIGIN. Also pushed to my Git repository at git://git.id10ts.net/samba.git under the v4-0-ipv6 branch.
I believe comment 3 should be raised as its own bug. The DDNS and BIND TSIG issue has been addressed (although I did not think to test w/ IPv6). As my patch corrects the initial report of this bug, I would suggest filing the issues from comment 3 under a new bug, and closing this one. This will prevent the bug title from causing the bug from being scanned over.
Andrew, Thanks for this. I'll test it myself later this week. (In reply to comment #8) > I believe comment 3 should be raised as its own bug. I have raised a new bug for this - 5368. > The DDNS and BIND TSIG issue has been addressed (although I did not think to > test w/ IPv6). I will test this later this week too :-) David
Andrew, The good news is that the --host-ip and --host-ip6 options work find. The problem with the script is that it uses name resolution to determine the IP addresses. Since the purpose of the script is configure DNS name resolution this is a catch 22! Various things can go wrong, but the bottom line is that the provision script should not use getaddrinfo or any other name resolution mechanism to determine the IP addresses, rather the addresses should be obtained from the server's interfaces. The good news is that the configure script already does this. Here is the output on my system: checking for iface getifaddrs... lo AF=17 eth0 AF=17 lo IP=127.0.0.1 NETMASK=255.0.0.0 eth0 IP=192.168.108.53 NETMASK=255.255.255.0 lo IP=::1 NETMASK=ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff eth0 IP=3000::3 NETMASK=ffff:ffff:ffff:ffff:: eth0 IP=fe80::20c:29ff:fe50:7e26 NETMASK=ffff:ffff:ffff:ffff:: I was there when Tridge wrote this and I seem to think that the intention was that it would work on most platforms - I don't know if it does. Then, you need to check that loopback, link-local or other addresses that are not suitable for the zone file are not used. I hope this makes sense. And I hope I understood the script correctly! Let me know if you need any testing doing. David
Is there some progress on this?
Is there some update on this issue?
We should have some IPv6 support in provision (--host-ip6 option) but I don't know if it is enough. If there is some interest to enhance this please REOPEN this bug report - I mark it as FIXED for now.