Description of problem: ISC dhcp does not support ppp and ipv6 as in`dhclient -6 -P` Version-Release number of selected component (if applicable): 4.1.1 and up How reproducible: Install dhcp. Have ppp connection to ipv6 capable isp. Run dhclient -6 -P -d -v ppp0 See error appear. Steps to Reproduce: 1. Install dhcp. 2. Have ppp connection to isp. 3. dhclient -6 -P -d -v ppp0 Actual results: Unsupported device type 512 for "ppp0" Expected results: Prefix Delegation to us. Additional info: https://lists.isc.org/pipermail/dhcp-users/attachments/20100426/9deb431f/attachment.bin has a patch that makes ppp interfaces acceptable. Finally we can use Prefix Delegation over PPP which is THE method for ISPs to give their clients their ipv6 numbers. Please do not say 'upstream'; please do either patch or *really* apply some methods upstream so that ISC fixes the ppp situation.
Hello Udo, I saw your question on dhcp-users mailing list https://lists.isc.org/pipermail/dhcp-users/2010-August/011843.html I'll look at it.
Jiri, the patch for ppp compatibility is referenced in the bug report. For receiving PD on pp0 but assigning an ipv6 number on eth0 dhclient-script needs a change or a separate script for this situation could be created (!) as well as specific ipv6 NetworkManager / initscripts hooks.
I would second that request. Right now I have to use ISC dhcp for ipv4 and a non-rpm built wide_dhcp client for ipv6. Messy. The only thing required is that ISC dhcp would support PPP interfaces. It's not so much an ipv6 issue, other than that we need PPP support to do ipv6 prefix delegation requests. It may be uncommon to use DHCP over PPP, as normally everything on a PPP connection is negotiated using IPCP. But our ISP uses IPCP only to issue a link-local IPv6 address and nameservers, and requires DHCP to request the prefix, which then needs to be assigned to an ethernet interface using a custom dhclient-script. Supposedly, this is the way ISP's are rolling out native IPv6: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/
We can also update radvd: config_radvd() { cat <<EOF interface $IFACE { AdvSendAdvert on; AdvHomeAgentFlag off; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; AdvLinkMTU 1460; prefix $new_ip6_prefix_radvd { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; AdvPreferredLifetime 20; AdvValidLifetime 30; }; RDNSS $new_dhcp6_name_servers { }; }; EOF kill -HUP `cat /var/run/radvd/radvd.pid` } And new_ip6_prefix_radvd=${new_ip6_address}/${new_ip6_prefixlen} config_radvd() at the necessary places... (yes we can provide a patch later on) I stripped the original (redhat) dhclient-script to just the ipv6 functionality and added the radvd hooks as documented here. I hardcoded eth0 as the interface to apply the ipv6 number to. I just need to understand the resolv.conf magic going on as I don't need the script to destroy stuff that is already in there (I run named locally). Also where would I start this dhclient? Just by faking that ppp0 needs a dhcp6 chat? (so ifup ppp0 does the job?)
Also an issue: Currently PREINIT6 in the dhclient-script removes all ipv6 numbers, even the ones configured statically in ifcfg-eth0. This issue is similar to the resolv.conf problem as it removes locally configured stuff that /is/ needed. (local caching named and/or local LAN setup)
When using PD dhclient does not give us an ip, just the prefix. We need to handle this case in dhclient-script and supply an interface with an ipv6 number...
(In reply to comment #6) > We need to handle this case in dhclient-script and supply an interface with an > ipv6 number... Any suggestions (patch) are welcomed. I'm afraid I don't have any spare time at the moment.
I added the code below just before the main case $reason block: if [ -z "${new_ip6_address}" ] && [ ! -z "${new_ip6_prefix}" ]; then my_mac_addr=`ip link show $IFACE|awk '/ether/{print $2};'` my_scope=`echo $new_ip6_prefix|sed -e 's/\/.*//'`"/"$PREFIXLEN new_ip6_address=`ipv6calc --action prefixmac2ipv6 --in prefix+mac --out ipv6addr $my_scope $my_mac_addr` new_ip6_prefixlen=$PREFIXLEN old_ip6_prefixlen=$PREFIXLEN if [ ${new_ip6_prefix} = ${old_ip6_prefix} ]; then old_ip6_address=$new_ip6_address fi fi This handles the PD situation that I see and fills in teh empty variables so that dhclient-script kan work. $IFACE and $PREFIXLEN are the hardcoded local values for interface (eth0, different from the interface that is used to obtain the PD) and prefix length (64, not supplied by dhclient/dhcp server). This is work in progress. Maybe we can juggle around with $interface based on $IFACE and the PD case being true (see the code block above).
Maybe like this: if [ -z "${new_ip6_address}" ] && [ ! -z "${new_ip6_prefix}" ]; then my_mac_addr=`ip link show $IFACE|awk '/ether/{print $2};'` my_scope=`echo $new_ip6_prefix|sed -e 's/\/.*//'`"/"$PREFIXLEN new_ip6_address=`ipv6calc --action prefixmac2ipv6 --in prefix+mac --out ipv6addr $my_scope $my_mac_addr` new_ip6_prefixlen=$PREFIXLEN old_ip6_prefixlen=$PREFIXLEN if [ ${new_ip6_prefix} = ${old_ip6_prefix} ]; then old_ip6_address=$new_ip6_address fi interface=$IFACE fi
Add thing this code a bit higher up, right after the spot where /etc/sysconfig/networking/network is sourced, appears to work better. At the end of PREINIT6 I added some code from ifup-ipv6 to restore some locally configured ipv6 numbers: # Setup IPv6 address on specified interface if [ -n "$IPV6ADDR" ]; then ipv6_add_addr_on_device $DEVICE $IPV6ADDR fi # Setup additional IPv6 addresses from list, if given if [ -n "$IPV6ADDR_SECONDARIES" ]; then for ipv6addr in $IPV6ADDR_SECONDARIES; do ipv6_add_addr_on_device $DEVICE $ipv6addr done fi
Created attachment 443055 [details] handle PD etc This Work in Progress patches adds some handling for Prefix Delegation and tries to fix the locally configured ipv6 numbers in the PREINIT6 phase.
Created attachment 443060 [details] handle PD etc Work in progress, tries to handle PD case
It might be more elegant to move the radvd stuff to the client side configuration scripts we have. Fedora distributes an example for ntp. I made one for radvd: #!/bin/bash make_conf_radvd() { new_ip6_prefix_radvd=`echo $new_ip6_address|awk -F: '{ print $1":"$2":"$3":"$4"::" }'`"/"${new_ip6_prefixlen} cat <<EOF > /etc/radvd.conf interface $IFACE { AdvSendAdvert on; AdvHomeAgentFlag off; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; AdvLinkMTU 1460; prefix $new_ip6_prefix_radvd { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; AdvPreferredLifetime 20; AdvValidLifetime 30; }; RDNSS $new_dhcp6_name_servers { }; }; EOF kill -HUP `cat /var/run/radvd/radvd.pid` } radvd_config(){ case "${reason}" in BOUND6) if [ -f /var/run/radvd/radvd.pid ]; then make_conf_radvd fi ;; RENEW6|REBIND6) if [ -n "${new_ip6_prefixlen}" ] && [ -n "${new_ip6_address}" ] && [ ! "${new_ip6_address}" = "${old_ip6_address}" ] || [ ! "${new_dhcp6_name_servers}" = "${old_dhcp6_name_servers}" ] || [ ! "${new_dhcp6_domain_search}" = "${old_dhcp6_domain_search}" ]; then if [ -f /var/run/radvd/radvd.pid ]; then make_conf_radvd fi fi ;; esac } The general idea is that if the ip6 number changes, or the ip6 dns changes or the search domain we make a fresh radvd.conf and kill -HUP radvd. Put radvd.sh in dhclient.d/ and make it executable. Still work in progress. Also see the fresh patch for dhclient-script to go with these changes.
Created attachment 443128 [details] handle PD
Small tweak in dhclient-script to handle REBIND6 while the ipv6 number has vanished due to e.g. a reboot. This makes the existing logic work again for this case, i.e.: an ipv6 number will be bound to the interface. # Handle Prefix Delegation case if [ -z "${new_ip6_address}" ] && [ ! -z "${new_ip6_prefix}" ]; then my_mac_addr=`ip link show $IFACE|awk '/ether/{print $2};'` my_scope=`echo ${new_ip6_prefix}|sed -e 's/\/.*//'`"/"$PREFIXLEN new_ip6_address=`ipv6calc --action prefixmac2ipv6 --in prefix+mac --out ipv6addr ${my_scope} ${my_mac_addr}|sed -e 's/\/.*//'` new_ip6_prefixlen=$PREFIXLEN old_ip6_prefixlen=$PREFIXLEN if [ x${new_ip6_prefix} = x${old_ip6_prefix} ]; then old_ip6_address=${new_ip6_address} fi interface=$IFACE fi New: # Handle Prefix Delegation case if [ -z "${new_ip6_address}" ] && [ ! -z "${new_ip6_prefix}" ]; then my_mac_addr=`ip link show $IFACE|awk '/ether/{print $2};'` my_scope=`echo ${new_ip6_prefix}|sed -e 's/\/.*//'`"/"$PREFIXLEN new_ip6_address=`ipv6calc --action prefixmac2ipv6 --in prefix+mac --out ipv6addr ${my_scope} ${my_mac_addr}|sed -e 's/\/.*//'` new_ip6_prefixlen=$PREFIXLEN old_ip6_prefixlen=$PREFIXLEN if [ x${new_ip6_prefix} = x${old_ip6_prefix} ]; then if [ ! ${reason}="REBIND6" ]; then old_ip6_address=${new_ip6_address} fi fi interface=$IFACE fi Any comments?
Hmm. The above 'fix' introduces a RTNETLINK answers: File exists messages each next time dhclient does a REBIND6 while it is running. So how could we do this only on the first REBIND6 after a restart? (no ipv6 number on the interface, dhclient.leases file present and we get the same prefix as last time) Any ideas?
Created attachment 446301 [details] handle PD and radvd
The patch I just added is still work in progress. It contains changes to /sbin/dhclient-script but also creates /etc/dhcp/dhclient.d/radvd.sh. Over here (xs4all.nl as isp with dual stack ppp connection) stuff works reasonably well.
Yup, REBIND6 issue remains: when ipv6 number is already on the interface and suddenly dhclient does a REBIND6 (instead of RENEW6) we see a 'RTNETLINK answers: File exists' message. Could we fix this elegantly? (or just redirect to /dev/zero ?)
Perhaps in add_ipv6_addr_with_DAD() we can place allreadypresent=$(ip -6 -o addr show dev ${interface} \ | grep ${new_ip6_address}/${new_ip6_prefixlen}) if [ -z "${alleadypresent} " ]; then { ..... fi around the existing code there? With such a construct we could handle a situation where the dhcp server stops responding for a while: Sep 12 00:45:26 epia dhclient[30491]: PRC: Renewing lease on ppp0. Sep 12 00:45:26 epia dhclient[30491]: XMT: Renew on ppp0, interval 10780ms. Sep 12 00:45:26 epia dhclient[30491]: RCV: Reply message on ppp0 from fe80::90:1a00:1a1:88e6. Sep 12 00:45:26 epia dhclient[30491]: message status code Success. Sep 12 01:45:26 epia dhclient[30491]: PRC: Renewing lease on ppp0. Sep 12 01:45:26 epia dhclient[30491]: XMT: Renew on ppp0, interval 9420ms. Sep 12 01:45:26 epia dhclient[30491]: RCV: Reply message on ppp0 from fe80::90:1a00:1a1:88e6. Sep 12 01:45:26 epia dhclient[30491]: message status code Success. Sep 12 02:45:26 epia dhclient[30491]: PRC: Renewing lease on ppp0. Sep 12 02:45:26 epia dhclient[30491]: XMT: Renew on ppp0, interval 10430ms. Sep 12 02:45:36 epia dhclient[30491]: XMT: Renew on ppp0, interval 20100ms. Sep 12 02:45:56 epia dhclient[30491]: XMT: Renew on ppp0, interval 41050ms. Sep 12 02:46:37 epia dhclient[30491]: XMT: Renew on ppp0, interval 84390ms. Sep 12 02:48:02 epia dhclient[30491]: XMT: Renew on ppp0, interval 172520ms. Sep 12 02:50:54 epia dhclient[30491]: XMT: Renew on ppp0, interval 344560ms. Sep 12 02:56:39 epia dhclient[30491]: XMT: Renew on ppp0, interval 649620ms. Sep 12 03:07:29 epia dhclient[30491]: XMT: Renew on ppp0, interval 477110ms. Sep 12 03:15:26 epia dhclient[30491]: PRC: Rebinding lease on ppp0. Sep 12 03:15:26 epia dhclient[30491]: XMT: Rebind on ppp0, interval 10750ms. Sep 12 03:15:26 epia dhclient[30491]: RCV: Reply message on ppp0 from fe80::90:1a00:1a1:88e6. Sep 12 03:15:26 epia dhclient[30491]: message status code Success. At Sep 12 03:15:26 we see a *rebind*, not a *renew*. The ipv6 number was still there and thus we saw a 'RTNETLINK answers: File exists' message.
Created attachment 446939 [details] handle PD and radvd This patch has a workaround for the 'RTNETLINK answers: File exists' message.
Has any additional progress been made by anyone on this issue. Having just started to work with a local ISP with their v6 rollout, I need to get this working as well. I have downloaded Fedora 14 but it doesn't seem to address the issue so I am guessing udo's work hasn't made it into the mainstream yet.
Glen, I saw your question od dhcp-users list. No, I haven't yet enough time to concentrate on this request, but I'm raising the priority on my TODO list now :-)
As a first step I applied the Patrik's patch from https://lists.isc.org/mailman/htdig/dhcp-users/2010-April/011253.html Builds are here: http://koji.fedoraproject.org/koji/buildinfo?buildID=204333 I don't have such hardware here so I hope you can test that it works as advertised.
Thanks. Patrik's patch basically works, especially once all files are in place. (DUID..?) So maybe we need a minor manual update. Next would be to change the scripts a little bit so we can use the 'new' functionality. Please see the attachments that I posted here to build on. (they work for me but perhaps stuff can be optimized)
Fedora patched dhcp (dhclient) appears to work OK with my proof of concept ipv6 Prefix Delegation scripting patch. When will Fedora support ipv6 Prefix Delegation? Fedora 17, 18?
Also: this prefix delegation patch just enables pppd support, but how and where would dhclient start in the ipv6 case? Please explain so I could try to rig stuff up that way. Depending on the state of the ipv6 pd connection I do not always see the ipv6 global link number be (re)assigned to the local interface after e.e.a a restart of dhclient or reboot of the box. How would I circumvent that in an elegant way? Have dhclient say `goodbye` in a nice way? And/or force the previous number onto my eth0 on restart?
Jul 2 18:47:49 epia dhclient[7832]: Bound to *:546 Jul 2 18:47:49 epia dhclient[7832]: Failed to get HW address for ppp0 Jul 2 18:47:49 epia dhclient[7832]: Jul 2 18:47:49 epia dhclient[7832]: This version of ISC DHCP is based on the release available Jul 2 18:47:49 epia dhclient[7832]: on ftp.isc.org. Features have been added and other changes Jul 2 18:47:49 epia dhclient[7832]: have been made to the base software release in order to make Jul 2 18:47:49 epia dhclient[7832]: it work better with this distribution. Jul 2 18:47:49 epia dhclient[7832]: Jul 2 18:47:49 epia dhclient[7832]: Please report for this software via the Red Hat Bugzilla site: Jul 2 18:47:49 epia dhclient[7832]: http://bugzilla.redhat.com Jul 2 18:47:49 epia dhclient[7832]: Jul 2 18:47:49 epia dhclient[7832]: exiting. Fedora 17 dhclient..
How to fix this? Now ipv6 PD is totall down here.
# rpm -Uvh --force /root/rpmbuild/RPMS/i386/dhclient-4.2.0-16.P2.fc17.i386.rpm # dhclient -6 -P ppp0 # And stuff works again. So what changed?
(In reply to comment #31) > # rpm -Uvh --force /root/rpmbuild/RPMS/i386/dhclient-4.2.0-16.P2.fc17.i386.rpm > # dhclient -6 -P ppp0 > > And stuff works again. > So what changed? Since 4.2.0-16 ? Lot of things :-) Seriously, there seem to be two updates that could have caused this 'Failed to get HW address for ppp0' problem. 1) Support for IPoIB (IP over InfiniBand) was added in 4.2.2-7 2) usage of getifaddrs() instead of ioctl to scan for interfaces was added in 4.2.3-20.P2 and improved in 4.2.3-23.P2 So I need you to (build &) install & test these versions to see where the problem occured. Hmmm, I've just noted that the patch for DHCPv6 over PPP was added in 4.2.0-18.P1 so I'm not sure how 4.2.0-16.P2 could work at all.
Maybe I added the ppp patch myself, I'll try some inbetween versions.
4.2.3-8.P2 works....
4.2.4-0.4-rc1: Failed to get HW address for ppp0
BTW: What about adding to ifup-eth: if [[ "${DHCPV6PD}" = [Yy1]* ]] && [ -x /sbin/dhclient ]; then generate_lease_file_name 6 /sbin/dhclient -6 -P ${DHCPV6PD_OPTIONS} -lf ${LEASEFILE} -pf /var/run/dhclient6-${DEVICE}.pid ${DEVICE} fi Near the DHCPV6C case? That would be a nice hook to start ipv6 PD?
(In reply to comment #32) > 2) usage of getifaddrs() instead of ioctl to scan for interfaces was added > in 4.2.3-20.P2 and improved in 4.2.3-23.P2 I removed the getifaddrs.patch and built dhcp-4.2.4-2.1.fc17 http://koji.fedoraproject.org/koji/taskinfo?taskID=4218262 Could you (is anybody else seeing this problem ?) confirm that dhcp-4.2.4-2.1.fc17 is OK while dhcp-4.2.4-2.fc17 (currently in stable) fails ?
i686/i386 please?
Building i686 myself.
I sent wrong link, sorry http://koji.fedoraproject.org/koji/taskinfo?taskID=4218261
Own build: Failed to get HW address for ppp0 lpf.c: + if (sll == NULL) { + freeifaddrs(ifaddrs); + log_fatal("Failed to get HW address for %s\n", name); (and what follows) That is the culprit.
Same deal for koji build.
So the getifaddrs.patch is not the problem. Udo, I need you (I don't have the HW) to do a binary search between 4.2.3-8.P2 (comment #34) and 4.2.4-0.4-rc1 (comment #35) and let me know which exact version introduced the problem.
Jiri, exactly what do you want me to do? Binary diff? gdb? Currently I am looking into the 'case' statement in 4.2.4.
No :-) We know that 4.2.3-8.P2 is OK and 4.2.4-0.4-rc1 KO. "binary search" [1] means that you take [2] some version between (ideally in the middle) them, lets say dhcp-4.2.3-17.P2, try it and if its OK, then select another from dhcp-4.2.3-17.P2 - 4.2.4-0.4-rc1 interval, otherwise (if it fails) from 4.2.3-8.P2 - dhcp-4.2.3-17.P2 interval. Until you find which version breaks it. [1] http://en.wikipedia.org/wiki/Binary_search_algorithm [2] https://koji.fedoraproject.org/koji/packageinfo?packageID=305
Working down all versions either segfaulted or didn't work with the HW address error. I came until dhclient-4.2.3-16.P2. dhclient-4.2.3-14.P2.fc17.i686.rpm needs rebuilding because of shared library issue.
Down to 4.2.3-9 they all fail with the HW address error. We can see the difference in lpf.c between 4.2.3-8 and 4.2.3-9 in get_hw_addr.
Created attachment 596257 [details] diff beteen lpf.c from 4.2.3-8 to 4.2.3-9
You must be looking (for the version numbers) somewhere else than me. The diff is the support for IPoIB added in 4.2.2-7 (as I already noted in comment #32) http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=commitdiff;h=bd3a57b466f51c1f214a42296cd8c14295c612af No code was changed between 4.2.3-8 and 4.2.3-9 http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=commitdiff;h=8b9d5e1b3b93506e1aae0f93183714562d28c312
I used dhcp-4.2.3-8.P2.fc16.src.rpm and dhcp-4.2.3-9.P1.fc17.src.rpm
(In reply to comment #50) > I used dhcp-4.2.3-8.P2.fc16.src.rpm and dhcp-4.2.3-9.P1.fc17.src.rpm ^ ^
Yes, so? Same basic version numbers. Distro version doesn't say much. Only very minor versions differ yet it appears that the differences are much much bigger than the numbers should imply?!
At https://koji.fedoraproject.org/koji/packageinfo?packageID=305 4.2.3.-8 is the latest Fedora 16 version. So what path of testing do you suggest? Try the lowest version for F17?
4.2.3-8.P1.fc17 does have the wrong code in lpf.c. This displays how nice the 'different' versions for each distro version are. This makes searching a lot of work, that's why we have version numbers and a version history so we can assume: same version is same code, independent of fcxyz ending.
Furthermore I see no lower version fc17 releases. So what can I do?
Jiri, The cause: * Mon Sep 19 2011 Jiri Popelka <jpopelka> - 12:4.2.2-7 - Support for IPoIB (IP over InfiniBand) interfaces (#660681) This bug has a patch which is the culprit: dhcp-4.10p1-lpf-ib.patch If the Fedora 16 version had the same patches we'd have known 9 months ago that this problem existed. So now we must patch around the ppp problem with this patch. Do you have any suggestions? This very bug is more true than ever.
When I take dhcp-4.2.4-2.1.fc17.src.rpm and build it, but with patches 33, 34, 35 and 40 disabled the resulting dhclient works as desired for Prefix Delegation.
(In reply to comment #56) > If the Fedora 16 version had the same patches we'd have known 9 months ago > that this problem existed. And PPP in F16 would be broken now too. Well, that's how I do things, i.e fix bugs in all afected versions and add new features (like this IPoIB) to unreleased/testing/rawhide version only. > So now we must patch around the ppp problem with this patch. > Do you have any suggestions? No, unless you can do some C debugging. I'll look at the problem but the thing is that all the (IPoIB, PPP) patches are from 3rd person and I don't have the PPP HW.
A new feature clearly broke a working functionality. So either we remove the new feature as I did in comment 57, or we patch around the issue. The new IB code does not see ppp0 as a valid interface. So me must catch that case and provide the struct that the new code needs. Then stuff should work again.
Created attachment 598914 [details] example program from getifaddrs(3) man page udo, could you build and run this program: gcc -Wall getifaddrs.c && ./a.out Also show me the 'ip a' output.
# gcc -Wall bla.c && ./a.out lo address family: 17 (AF_PACKET) eth1 address family: 17 (AF_PACKET) eth0 address family: 17 (AF_PACKET) lo address family: 2 (AF_INET) address: <127.0.0.1> eth1 address family: 2 (AF_INET) address: <10.0.0.150> eth0 address family: 2 (AF_INET) address: <192.168.10.98> ppp0 address family: 2 (AF_INET) address: <80.101.128.228> lo address family: 10 (AF_INET6) address: <::1> eth1 address family: 10 (AF_INET6) address: <fe80::240:63ff:fee6:200%eth1> eth0 address family: 10 (AF_INET6) address: <2001:980:3480:0:240:63ff:fee6:201> eth0 address family: 10 (AF_INET6) address: <fd00:c0a8:a01:1::1> eth0 address family: 10 (AF_INET6) address: <fe80::240:63ff:fe26:201%eth0> ppp0 address family: 10 (AF_INET6) address: <fe80::240:63ff:fe26:200%ppp0> # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:40:63:f6:02:00 brd ff:ff:ff:ff:ff:ff inet 10.0.0.150/24 brd 10.0.0.255 scope global eth1 inet6 fe80::240:63ff:fee6:200/64 scope link valid_lft forever preferred_lft forever 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:40:63:f6:02:01 brd ff:ff:ff:ff:ff:ff inet 192.168.10.98/24 brd 192.168.10.255 scope global eth0 inet6 2001:980:3481:0:240:63ff:fee6:201/64 scope global valid_lft forever preferred_lft forever inet6 fd00:c0a8:a00:1::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::240:63ff:fee6:201/64 scope link valid_lft forever preferred_lft forever 8: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc cbq state UNKNOWN qlen 3 link/ppp inet 80.101.128.228 peer 194.109.15.213/32 scope global ppp0 inet6 fe80::240:63ff:fee6:200/10 scope link valid_lft forever preferred_lft forever (similar to that at least)
From getifaddrs(3): " The addresses returned on Linux will usually be the IPv4 and IPv6 addresses assigned to the interface, but also one AF_PACKET address per interface containing lower-level details about the interface and its physical layer." but it's not true for PPP interface where the getifaddrs() doesn't return any AF_PACKET address so we are unable to discover that it's a PPP interface. I'll try to find out whether this is a bug in getifaddrs(), not yet implemented or designed so.
Meanwhile I added the fall-back method (using ioctl(SIOCGIFHWADDR)) when getting of HW address with getifaddrs() fails. Try https://koji.fedoraproject.org/koji/taskinfo?taskID=4251246
Jiri, stuff looks good for the fall-back method i686 rpms: Jul 19 14:44:17 epia dhclient[29305]: XMT: Renew on ppp0, interval 9770ms. Jul 19 14:44:17 epia dhclient[29305]: RCV: Reply message on ppp0 from fe80::90:1a00:1a1:88e6. Jul 19 14:44:17 epia dhclient[29305]: message status code Success. Jul 19 15:11:08 epia dhclient[22773]: /var/lib/dhclient/dhclient6.leases line 17: semicolon expected. Jul 19 15:11:08 epia dhclient[22773]: option Jul 19 15:11:08 epia dhclient[22773]: ^ Jul 19 15:11:08 epia dhclient[22773]: /var/lib/dhclient/dhclient6.leases line 35: semicolon expected. Jul 19 15:11:08 epia dhclient[22773]: option Jul 19 15:11:08 epia dhclient[22773]: ^ Jul 19 15:11:08 epia dhclient[22773]: /var/lib/dhclient/dhclient6.leases line 53: semicolon expected. Jul 19 15:11:08 epia dhclient[22773]: option Jul 19 15:11:08 epia dhclient[22773]: ^ Jul 19 15:11:08 epia dhclient[22773]: /var/lib/dhclient/dhclient6.leases line 71: semicolon expected. Jul 19 15:11:08 epia dhclient[22773]: option Jul 19 15:11:08 epia dhclient[22773]: ^ Jul 19 15:11:08 epia dhclient[22773]: Bound to *:546 Jul 19 15:11:08 epia dhclient[22773]: xid: warning: no netdev with useable HWADDR found for seed's uniqueness enforcement Jul 19 15:11:08 epia dhclient[22773]: xid: rand init seed (0xf8c86566) built using gethostid Jul 19 15:11:08 epia dhclient[22773]: XMT: Rebind on ppp0, interval 1030ms. Jul 19 15:11:08 epia dhclient[22773]: RCV: Reply message on ppp0 from fe80::90:1a00:1a1:88e6. Jul 19 15:11:08 epia dhclient[22773]: message status code Success. (15:11 and on)
So far the 4.2.4-5 dhclient works OK. Thanks! Will this version be released to F17? I could not find a src rpm yet to see the changes you made...
Sure dhcp-4.2.4-6.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dhcp-4.2.4-6.fc17 I'll leave this bug open, see comment #25.
Hi. I had same problem as udo, but i decided to solve it somehow. I'm also trying to use ppp from isp, and use local interface for PD. System is Fedora 17, x64. Basically, here we have more than one bug/problem: 1. dhclient a) unable to generate DUID (fixed? - i still get errors - 4.2.4-9.P1.fc17.x86_64) If dhclient* lease file is empty, dhclient tries to generate DUID, and it just fails. Once DUID is generated (by hand), is just complains about unable to get HWADDR, but it continues, and completes successfully. b) dies on deleted interfaces When pppd goes down, it first brings down interface (ppp0), and then tries to call scripts. If you put dhclient in those scripts, dhclient is executed on nonexistent interface. So, again, it just dies, killing (when invoked with -r or -x) any dhclient instance, and without invoking any of defined scripts. 2. pppd a) sometimes, on bringing down ppp, dies _before_ invoking scripts It's game of luck. Or, better, how fast your system is. It seems that pppd invokes scripts, but dies before they actually start, so OS kills everything (fork/exec calls does not complete). 3. radvd a) sometimes it does not send "prefix deferred" message Same situation as pppd - if radvd is configured with DeprecatePrefix directive, it should send RA out. But, sometimes, this does not happen. In logs, there is only "interrupted system call", so i'm guessing that it just dies to fast. RESOLUTION So, how to make it work. Preferred way would be: 1a) This is BUG. When ppp0 is up, pppd assigns LL addresses, so this should be enough to generate DUID. Logic in dhclient should be corrected to use them. 1b) Also BUG. When invoked with -r or -x, _even_ on deleted interfaces, dhclient _should_, if instructed by special new option, call scripts. It is up to script writer to check whether interface actually exists, or not. 2a) Also BUG. I'm guessing that pppd should be enhanced to, before dieing, check whether scripts are running, or, to wait some time (can be configurable) before dieing. I'm suspecting that pppoe (which calls pppd) just kills to fast. :-) 3a) Probably bug, but not sure. And now, quick&dirty fixes. :-) For 1a and 1b i did wrote wrapper script, which uses few extra parameters, and prepare environment for dhclient itself. Script is dhclient-ppp.sh. Also, i did wrote example ipv6-up/down scripts, also attached (ipv6-up.local and ipv6-down.local). To go around 2a, i did put in ipv6-up script to detect still running dhclient, and kills it, so we do not end up with more PD active. For 3a, for now, no easy solution. It does happen very rarely. As bonus, i'm providing additional script, called by dhclient, which will setup rarpd and dhcpd6 (radvd-script.sh). Scripts in them have few explanations, so im' guessing this should be enough. Also, they are work-in-progress, so there is a lot of places for improvement. Happy ipv6-ing! H.
Created attachment 602341 [details] Sample configuration for dhclient.conf
Created attachment 602342 [details] dhclient wrapper script
Created attachment 602343 [details] dhclient autoconfiguration script
Created attachment 602344 [details] pppd infterface down script
Created attachment 602345 [details] pppd interface up script
Jiri, Can you please update us on the status of things, Hrvoje's observations and our input? What is the Fedora roadmap for ipv6? In my opinion Fedora does NOT support ipv6 at an acceptable level. This bug tries to address at least on of the issues. Please let us know the status and how/where we can help.
I am having the same issue with prefix delegation. As Udo said, what is the status of this, and where is this going in the future. It is quite important for fedora to support this.
I'm trying to use Comcast's DHCPD-PD with fedora-18 and the lack of PD support is effecting me too. One observation: radvd has a magic configuration address "::/64" that can be used to tell radvd to get the actual prefix from the interface itself. There is no need to mash the user's radvd.conf file in order to get the PD's prefix read in. radvd.conf: interface p13p1 # internal net { AdvSendAdvert on; prefix ::/64 { }; };
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
see https://bugzilla.redhat.com/show_bug.cgi?id=956147 Review Request: wide-dhcpv6 - DHCPv6 Prefix Delegation client that works on PPP
dhclient *does* work over PPP. I am running it at this time. The issue with dhclient is that the network-scripts do NOT for a ppp interface support starting dhclient with prefix delegation. This is the main usability issue with dhclient.
Could you please specify which version of dhclient supports prefix delegation over PPP? I have tried the version from Fedora 18 which did not support PD (even when started manually, without support from network-scripts), exactly like udo described when creating this bug.
Hm. I did not say that dhclient does not work (in general), or that it does not support PD. Issues with dhclient are mainly with how does it work over ppp0 (ppp tunnel). In short, ppp0 is special interface, and it seems that dhclient is _unable_ to generate proper duid. Please see my previous post. I can confirm that in my version (also mentioned before) PD _works_. Please, read again through my mail. :-) H.
dhclient-4.2.5-7.fc18.x86_64 dhclient -d -v -6 -P ppp0 Gives me a prefix. My issues are: * Cannot be started or flagged to start from the ifcfg script for ppp (IE DHCPV6_PD=yes ) * Does not detect when link goes away / comes back to restart the delegation process (IE the link drops and returns on a new router, you need to wait 3600 seconds for the refresh)
This is what happens to me with dhclient-4.2.5-7.fc18.x86_64: # dhclient -d -v -6 -P ppp0 Internet Systems Consortium DHCP Client 4.2.5 Copyright 2004-2013 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Bound to *:546 Listening on Socket/ppp0 Sending on Socket/ppp0 xid: warning: no netdev with useable HWADDR found for seed's uniqueness enforcement xid: rand init seed (0x5179297b) built using gethostid Cannot form default DUID from interface ppp0. PRC: Soliciting for leases (INIT). XMT: Forming Solicit, 0 ms elapsed. Failure assembling a DUID. This version of ISC DHCP is based on the release available on ftp.isc.org. Features have been added and other changes have been made to the base software release in order to make it work better with this distribution. Please report for this software via the Red Hat Bugzilla site: http://bugzilla.redhat.com exiting.
(In reply to comment #82) > This is what happens to me with dhclient-4.2.5-7.fc18.x86_64: > # dhclient -d -v -6 -P ppp0 > xid: warning: no netdev with useable HWADDR found for seed's uniqueness > Cannot form default DUID from interface ppp0. > Failure assembling a DUID. I got around this based on some ideas I got from attachment 602342 [details] (comment 69) Unfortunately the DUID generated by Hrvoje's script was giving Invalid DUID on my DHCP Server at the other end of the PPP link, so I wrote a new one [root@localhost dhcp]# cat dhclient.sh #!/bin/sh myhwaddr=`ip add | grep link/ether | cut -f 6 -d \ | tail -n 1 | sed s/:/\\\\\\\\x/g` echo "default-duid \"\\x00\\x03\\x00\\x01\\x$myhwaddr\";" > /var/lib/dhclient/dhclient6.leases dhclient -P -d ppp0 I can see the dhcp server handing out a prefix, but I can't see dhclient doing anything with it. IMHO, it should be assigning /64's to each ethernet adapter specified in the config that is meant to get a prefix. However I can find nowhere this can be configured and no script that knows how to add an address to any interface other than the one on which the solicit is run on. So whilst dhclient might be able to get a prefix from a PPP link, it doesn't do anything with it. Please show me I am wrong.
In my crude patches I hardcoded the interface where the /64 has to go. So yes, it depends on the scripting what dhclient will do. I really can't believe wh proper ipv6 support is taking so long as all other nonense is taking priority. Did my ISP make the wrong choice by using PD? Is ipv6 not shiny enough? Please see the patches and improve on them!
I think this guy might be on the right track http://www.phildev.net/phil/blog/?p=308
The reason why dhclient is not doing anything with provided prefix is that - it is not it's job. This is job of /sbin/dhclient-script script. This script is "by default" called by dhclient. Inside you will notice one big "case", with dhcp states - and it misses handling of PD ones. This is why i did provide "new" one ... Yes, it's quite supprising that nor RedHat nor Centos nor Fedora do see this as _important_ thing. And, silly thing is - it is already done in OpenWRT scripts! So, some copy/pasting should make dhclient-script good enough to start. What's odd is that other Linux distros also "lag" behind. I do not know one major distribution that does this in the "proper" way. Anyhow, use provided scripts/configs, and make it work. Publish your work. Maybe someone will _finally_ put it in some distro. Maybe.
The main problem with ISC's dhclient is that it doesnt' allow you to do "-P -N" as far as I can tell. One cant' get both a normal ipv6 address and a prefix. Comcast (one of the biggerr ISP's that offer native IPv6 requires one to accept a single ipv6 address on the internet-facing interface and accept a pd on the inside interface. Current dhclient mangles the above case badly, as if it only had one storage site and both the ia and pd were clobbering each other.
That's bug #836702 I think.
Hm, interesting. This somewhat clashes with what i am expiriencing: # dhclient.old -6 -d -v -N -P -cf /tmp/dhclient.conf -lf /tmp/mm.l -pf /tmp/mm.p eth1 Internet Systems Consortium DHCP Client 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Bound to *:546 Listening on Socket/eth1 Sending on Socket/eth1 PRC: Soliciting for leases (INIT). XMT: Forming Solicit, 0 ms elapsed. XMT: X-- IA_NA 27:6d:96:3f XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: X-- IA_PD 27:6d:96:3f XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: Solicit on eth1, interval 1070ms. RCV: Advertise message on eth1 from fe80::6cb8:2dff:fe8f:b1cd. RCV: X-- IA_NA 27:6d:96:3f RCV: | X-- starts 1366917388 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAADDR 2a00:c30:f001:1ff::c RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- IA_PD 27:6d:96:3f RCV: | X-- starts 1366917388 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2a00:c30:f001:1d0::/60 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- Server ID: 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36 RCV: Advertisement recorded. PRC: Selecting best advertised lease. PRC: Considering best lease. PRC: X-- Initial candidate 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36 (s: 304, p: 0). XMT: Forming Request, 0 ms elapsed. XMT: X-- IA_NA 27:6d:96:3f XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAADDR 2a00:c30:f001:1ff::c XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_NA appended. XMT: X-- IA_PD 27:6d:96:3f XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAPREFIX 2a00:c30:f001:1d0::/60 XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_PD appended. XMT: Request on eth1, interval 1040ms. RCV: Reply message on eth1 from fe80::6cb8:2dff:fe8f:b1cd. RCV: X-- IA_NA 27:6d:96:3f RCV: | X-- starts 1366917389 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAADDR 2a00:c30:f001:1ff::c RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- IA_PD 27:6d:96:3f RCV: | X-- starts 1366917389 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2a00:c30:f001:1d0::/60 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- Server ID: 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36 PRC: Bound to lease 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36. PRC: Renewal event scheduled in 90 seconds, to run for 45 seconds. PRC: Depreference scheduled in 112 seconds. PRC: Expiration scheduled in 180 seconds. Also, multiple "-P" works ... # dhclient.old -6 -d -v -N -P -P -P -cf /tmp/dhclient.conf -lf /tmp/mm.l -pf /tmp/mm.p eth1 Internet Systems Consortium DHCP Client 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Bound to *:546 Listening on Socket/eth1 Sending on Socket/eth1 PRC: Soliciting for leases (INIT). XMT: Forming Solicit, 0 ms elapsed. XMT: X-- IA_NA 27:6d:96:3f XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: X-- IA_PD 27:6d:96:3f XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: X-- IA_PD 27:6d:96:40 XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: X-- IA_PD 27:6d:96:41 XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: Solicit on eth1, interval 1010ms. RCV: Advertise message on eth1 from fe80::6cb8:2dff:fe8f:b1cd. RCV: X-- IA_NA 27:6d:96:3f RCV: | X-- starts 1366917439 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAADDR 2a00:c30:f001:1ff::b RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- IA_PD 27:6d:96:3f RCV: | X-- starts 1366917439 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2a00:c30:f001:1c0::/60 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- IA_PD 27:6d:96:40 RCV: | X-- starts 1366917439 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2a00:c30:f001:1c0::/60 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- IA_PD 27:6d:96:41 RCV: | X-- starts 1366917439 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2a00:c30:f001:1c0::/60 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- Server ID: 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36 RCV: Advertisement recorded. PRC: Selecting best advertised lease. PRC: Considering best lease. PRC: X-- Initial candidate 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36 (s: 604, p: 0). XMT: Forming Request, 0 ms elapsed. XMT: X-- IA_NA 27:6d:96:3f XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAADDR 2a00:c30:f001:1ff::b XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_NA appended. XMT: X-- IA_PD 27:6d:96:3f XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAPREFIX 2a00:c30:f001:1c0::/60 XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_PD appended. XMT: X-- IA_PD 27:6d:96:40 XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAPREFIX 2a00:c30:f001:1c0::/60 XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_PD appended. XMT: X-- IA_PD 27:6d:96:41 XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAPREFIX 2a00:c30:f001:1c0::/60 XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_PD appended. XMT: Request on eth1, interval 910ms. RCV: Reply message on eth1 from fe80::6cb8:2dff:fe8f:b1cd. RCV: X-- IA_NA 27:6d:96:3f RCV: | X-- starts 1366917440 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAADDR 2a00:c30:f001:1ff::b RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- IA_PD 27:6d:96:3f RCV: | X-- starts 1366917440 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2a00:c30:f001:1c0::/60 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- IA_PD 27:6d:96:40 RCV: | X-- starts 1366917440 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2a00:c30:f001:180::/60 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- IA_PD 27:6d:96:41 RCV: | X-- starts 1366917440 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2a00:c30:f001:1a0::/60 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- Server ID: 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36 PRC: Bound to lease 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36. PRC: Renewal event scheduled in 90 seconds, to run for 45 seconds. PRC: Depreference scheduled in 112 seconds. PRC: Expiration scheduled in 180 seconds. So, like i said before - problem with prefixes lies in dhclient-script. (note, this is centos dhcp - version is different) I did test this with latest isc, and it works.
Interesting. Here is what I see with a stock dhclient in Fedora 18. I note you have a dhclient.conf file. Perhaps that is the difference. Can you please post it? Here is what I see when I run it with a test script that simply prints its env. + /sbin/dhclient -6 -d -v -N -P -lf /var/lib/dhclient/dhclient6-pd-p32p1.leases -pf /var/run/dhclient6-pd-p32p1.pid -sf /usr/sbin/dhclient-test-script p32p1 Internet Systems Consortium DHCP Client 4.2.5 Copyright 2004-2013 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ **** /usr/sbin/dhclient-test-script start 2013-04-25 13:17:59.019544501-07:00 **** interface=p32p1 reason=PREINIT6 PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin pid=31833 PWD=/home/wolfgang/src/prefix-delegation SHLVL=1 _=/bin/env **** /usr/sbin/dhclient-test-script end 2013-04-25 13:17:59.021262247-07:00 **** Bound to *:546 Listening on Socket/p32p1 Sending on Socket/p32p1 PRC: Confirming active lease (INIT-REBOOT). XMT: Forming Rebind, 0 ms elapsed. XMT: X-- IA_PD cd:21:75:13 XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAPREFIX 2601:9:a40:4a::/64 XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_PD appended. XMT: Rebind on p32p1, interval 1030ms. RCV: Reply message on p32p1 from fe80::201:5cff:fe32:7741. RCV: X-- IA_PD cd:21:75:13 RCV: | X-- starts 1366921079 RCV: | X-- t1 - renew +171892 RCV: | X-- t2 - rebind +275028 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2601:9:a40:4a::/64 RCV: | | | X-- Preferred lifetime 343785. RCV: | | | X-- Max lifetime 343785. RCV: X-- Server ID: 00:01:00:01:15:d6:c3:51:84:2b:2b:fe:4b:ec PRC: Bound to lease 00:01:00:01:15:d6:c3:51:84:2b:2b:fe:4b:ec. **** /usr/sbin/dhclient-test-script start 2013-04-25 13:17:59.346767004-07:00 **** old_renew=172230 old_dhcp6_server_id=0:1:0:1:15:d6:c3:51:84:2b:2b:fe:4b:ec old_max_life=344461 old_starts=1366920402 interface=p32p1 new_life_starts=1366921079 new_max_life=343785 new_starts=1366921079 reason=REBIND6 new_dhcp6_client_id=0:1:0:1:18:f9:ed:e9:0:a:cd:21:75:13 new_preferred_life=343785 new_ip6_prefix=2601:9:a40:4a::/64 old_ip6_prefix=2601:9:a40:4a::/64 new_iaid=cd:21:75:13 requested_dhcp6_domain_search=1 old_iaid=cd:21:75:13 new_rebind=275028 PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin old_preferred_life=344461 pid=31833 requested_dhcp6_name_servers=1 new_dhcp6_server_id=0:1:0:1:15:d6:c3:51:84:2b:2b:fe:4b:ec PWD=/home/wolfgang/src/prefix-delegation old_rebind=275568 new_renew=171892 new_dhcp6_name_servers=2001:558:feed::1 2001:558:feed::2 SHLVL=1 old_dhcp6_client_id=0:1:0:1:18:f9:ed:e9:0:a:cd:21:75:13 old_life_starts=1366920402 old_dhcp6_name_servers=2001:558:feed::1 2001:558:feed::2 _=/bin/env **** /usr/sbin/dhclient-test-script end 2013-04-25 13:17:59.351389770-07:00 **** PRC: Renewal event scheduled in 171892 seconds, to run for 103136 seconds. PRC: Depreference scheduled in 343785 seconds. PRC: Expiration scheduled in 343785 seconds.
Hm, odd. Can you try to recreate lease file and try again? I'm suspecting that there is something in your relase file that confuses dhclient. Anyhow, this is my run: ]# dhclient.old -6 -d -v -N -P -cf /tmp/dhclient.conf -lf /tmp/mm.l -pf /tmp/mm.p eth1 Internet Systems Consortium DHCP Client 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ ****************************** interface=eth1 reason=PREINIT6 pid=31309 PWD=/usr/local/sbin SHLVL=1 _=/bin/env ****************************** Bound to *:546 Listening on Socket/eth1 Sending on Socket/eth1 PRC: Soliciting for leases (INIT). XMT: Forming Solicit, 0 ms elapsed. XMT: X-- IA_NA 27:6d:96:3f XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: X-- IA_PD 27:6d:96:3f XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: Solicit on eth1, interval 1090ms. RCV: Advertise message on eth1 from fe80::6cb8:2dff:fe8f:b1cd. RCV: X-- IA_NA 27:6d:96:3f RCV: | X-- starts 1366922901 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAADDR 2a00:c30:f001:1ff::5 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- IA_PD 27:6d:96:3f RCV: | X-- starts 1366922901 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2a00:c30:f001:1e0::/60 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- Server ID: 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36 RCV: Advertisement recorded. PRC: Selecting best advertised lease. PRC: Considering best lease. PRC: X-- Initial candidate 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36 (s: 304, p: 0). XMT: Forming Request, 0 ms elapsed. XMT: X-- IA_NA 27:6d:96:3f XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAADDR 2a00:c30:f001:1ff::5 XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_NA appended. XMT: X-- IA_PD 27:6d:96:3f XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAPREFIX 2a00:c30:f001:1e0::/60 XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_PD appended. XMT: Request on eth1, interval 1010ms. RCV: Reply message on eth1 from fe80::6cb8:2dff:fe8f:b1cd. RCV: X-- IA_NA 27:6d:96:3f RCV: | X-- starts 1366922902 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAADDR 2a00:c30:f001:1ff::5 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- IA_PD 27:6d:96:3f RCV: | X-- starts 1366922902 RCV: | X-- t1 - renew +0 RCV: | X-- t2 - rebind +0 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2a00:c30:f001:1e0::/60 RCV: | | | X-- Preferred lifetime 112. RCV: | | | X-- Max lifetime 180. RCV: X-- Server ID: 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36 PRC: Bound to lease 00:01:00:01:19:04:75:e9:08:00:27:b2:98:36. ****************************** new_ip6_address=2a00:c30:f001:1ff::5 interface=eth1 new_life_starts=1366922902 new_max_life=180 new_starts=1366922902 reason=BOUND6 new_dhcp6_client_id=0:1:0:1:19:c:53:15:8:0:27:6d:96:3f new_preferred_life=112 new_iaid=27:6d:96:3f new_rebind=0 pid=31309 new_dhcp6_server_id=0:1:0:1:19:4:75:e9:8:0:27:b2:98:36 PWD=/usr/local/sbin new_renew=0 new_dhcp6_name_servers=2a00:c30:fffd:1::105 SHLVL=1 new_ip6_prefixlen=64 _=/bin/env ****************************** ****************************** interface=eth1 new_life_starts=1366922902 new_max_life=180 new_starts=1366922902 reason=BOUND6 new_dhcp6_client_id=0:1:0:1:19:c:53:15:8:0:27:6d:96:3f new_preferred_life=112 new_ip6_prefix=2a00:c30:f001:1e0::/60 new_iaid=27:6d:96:3f new_rebind=0 pid=31309 new_dhcp6_server_id=0:1:0:1:19:4:75:e9:8:0:27:b2:98:36 PWD=/usr/local/sbin new_renew=0 new_dhcp6_name_servers=2a00:c30:fffd:1::105 SHLVL=1 _=/bin/env ****************************** PRC: Renewal event scheduled in 90 seconds, to run for 45 seconds. PRC: Depreference scheduled in 112 seconds. PRC: Expiration scheduled in 180 seconds. My conf file is: -------------------------------- # interface "eth1" { script "/tmp/ja.sh"; } -------------------------------- Please note _two_ bound events - one for IA_NA, other for IA_PD.
ok, the problem is in how the code handles a lease file. If there is a lease file with only pd leases in it, dhclient never asks for the na. Removing the file causes it to stutter a bit and then things look normal. (Why do I see 3 "Forming Solicit" blocks??? (Yes, I noticed the two bound events. Nice!) + /sbin/dhclient -6 -d -v -N -P -lf /tmp/dhclient6-pd-p32p1.leases -pf /var/run/dhclient6-pd-p32p1.pid -sf /usr/sbin/dhclient-test-script p32p1 Internet Systems Consortium DHCP Client 4.2.5 Copyright 2004-2013 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ **** /usr/sbin/dhclient-test-script start 2013-04-25 13:56:37.194081122-07:00 **** interface=p32p1 reason=PREINIT6 PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin pid=32490 PWD=/home/wolfgang/src/prefix-delegation SHLVL=1 _=/bin/env **** /usr/sbin/dhclient-test-script end 2013-04-25 13:56:37.197140276-07:00 **** Bound to *:546 Listening on Socket/p32p1 Sending on Socket/p32p1 PRC: Soliciting for leases (INIT). XMT: Forming Solicit, 0 ms elapsed. XMT: X-- IA_NA cd:21:75:13 XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: X-- IA_PD cd:21:75:13 XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: Solicit on p32p1, interval 1050ms. XMT: Forming Solicit, 1050 ms elapsed. XMT: X-- IA_NA cd:21:75:13 XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: X-- IA_PD cd:21:75:13 XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: Solicit on p32p1, interval 2200ms. XMT: Forming Solicit, 3250 ms elapsed. XMT: X-- IA_NA cd:21:75:13 XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: X-- IA_PD cd:21:75:13 XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: Solicit on p32p1, interval 4550ms. RCV: Advertise message on p32p1 from fe80::201:5cff:fe32:7741. RCV: X-- Preference 0. RCV: X-- IA_NA cd:21:75:13 RCV: | X-- starts 1366923400 RCV: | X-- t1 - renew +172800 RCV: | X-- t2 - rebind +276480 RCV: | X-- [Options] RCV: | | X-- IAADDR 2001:558:6045:22:84f1:fd58:aee5:d053 RCV: | | | X-- Preferred lifetime 345600. RCV: | | | X-- Max lifetime 345600. RCV: X-- IA_PD cd:21:75:13 RCV: | X-- starts 1366923400 RCV: | X-- t1 - renew +172800 RCV: | X-- t2 - rebind +276480 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2601:9:a40:67::/64 RCV: | | | X-- Preferred lifetime 345600. RCV: | | | X-- Max lifetime 345600. RCV: X-- Server ID: 00:01:00:01:15:d6:c3:51:84:2b:2b:fe:4b:ec RCV: Advertisement immediately selected. PRC: Selecting best advertised lease. PRC: Considering best lease. PRC: X-- Initial candidate 00:01:00:01:15:d6:c3:51:84:2b:2b:fe:4b:ec (s: 304, p: 0). XMT: Forming Request, 0 ms elapsed. XMT: X-- IA_NA cd:21:75:13 XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAADDR 2001:558:6045:22:84f1:fd58:aee5:d053 XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_NA appended. XMT: X-- IA_PD cd:21:75:13 XMT: | X-- Requested renew +3600 XMT: | X-- Requested rebind +5400 XMT: | | X-- IAPREFIX 2601:9:a40:67::/64 XMT: | | | X-- Preferred lifetime +7200 XMT: | | | X-- Max lifetime +7500 XMT: V IA_PD appended. XMT: Request on p32p1, interval 1010ms. RCV: Advertise message on p32p1 from fe80::201:5cff:fe32:7741. Packet received, but nothing done with it. RCV: Reply message on p32p1 from fe80::201:5cff:fe32:7741. RCV: X-- IA_NA cd:21:75:13 RCV: | X-- starts 1366923401 RCV: | X-- t1 - renew +172800 RCV: | X-- t2 - rebind +276480 RCV: | X-- [Options] RCV: | | X-- IAADDR 2001:558:6045:22:84f1:fd58:aee5:d053 RCV: | | | X-- Preferred lifetime 345600. RCV: | | | X-- Max lifetime 345600. RCV: X-- IA_PD cd:21:75:13 RCV: | X-- starts 1366923401 RCV: | X-- t1 - renew +172800 RCV: | X-- t2 - rebind +276480 RCV: | X-- [Options] RCV: | | X-- IAPREFIX 2601:9:a40:67::/64 RCV: | | | X-- Preferred lifetime 345600. RCV: | | | X-- Max lifetime 345600. RCV: X-- Server ID: 00:01:00:01:15:d6:c3:51:84:2b:2b:fe:4b:ec PRC: Bound to lease 00:01:00:01:15:d6:c3:51:84:2b:2b:fe:4b:ec. **** /usr/sbin/dhclient-test-script start 2013-04-25 13:56:41.037194234-07:00 **** new_ip6_address=2001:558:6045:22:84f1:fd58:aee5:d053 interface=p32p1 new_life_starts=1366923401 new_max_life=345600 new_starts=1366923401 reason=BOUND6 new_dhcp6_client_id=0:1:0:1:19:c:55:5:0:a:cd:21:75:13 new_preferred_life=345600 new_iaid=cd:21:75:13 requested_dhcp6_domain_search=1 new_rebind=276480 PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin pid=32490 requested_dhcp6_name_servers=1 new_dhcp6_server_id=0:1:0:1:15:d6:c3:51:84:2b:2b:fe:4b:ec PWD=/home/wolfgang/src/prefix-delegation new_renew=172800 new_dhcp6_name_servers=2001:558:feed::1 2001:558:feed::2 SHLVL=1 new_ip6_prefixlen=64 _=/bin/env **** /usr/sbin/dhclient-test-script end 2013-04-25 13:56:41.041855717-07:00 **** **** /usr/sbin/dhclient-test-script start 2013-04-25 13:56:41.050500196-07:00 **** interface=p32p1 new_life_starts=1366923401 new_max_life=345600 new_starts=1366923401 reason=BOUND6 new_dhcp6_client_id=0:1:0:1:19:c:55:5:0:a:cd:21:75:13 new_preferred_life=345600 new_ip6_prefix=2601:9:a40:67::/64 new_iaid=cd:21:75:13 requested_dhcp6_domain_search=1 new_rebind=276480 PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin pid=32490 requested_dhcp6_name_servers=1 new_dhcp6_server_id=0:1:0:1:15:d6:c3:51:84:2b:2b:fe:4b:ec PWD=/home/wolfgang/src/prefix-delegation new_renew=172800 new_dhcp6_name_servers=2001:558:feed::1 2001:558:feed::2 SHLVL=1 _=/bin/env **** /usr/sbin/dhclient-test-script end 2013-04-25 13:56:41.055892337-07:00 **** PRC: Renewal event scheduled in 172800 seconds, to run for 103680 seconds. PRC: Depreference scheduled in 345600 seconds. PRC: Expiration scheduled in 345600 seconds.
(In reply to comment #87) > The main problem with ISC's dhclient is that it doesnt' allow you to do "-P > -N" as far as I can tell. One cant' get both a normal ipv6 address and a > prefix. Comcast (one of the biggerr ISP's that offer native IPv6 requires > one to accept a single ipv6 address on the internet-facing interface and > accept a pd on the inside interface. Current dhclient mangles the above > case badly, as if it only had one storage site and both the ia and pd were > clobbering each other. This would be so that customers could pick either mechanism. I don't see why you would need to support both at once.
(In reply to comment #93) > This would be so that customers could pick either mechanism. > I don't see why you would need to support both at once. Perhaps I needed to word that more succinctly: Comcast requires you to use both -N and -P.
(In reply to comment #94) > (In reply to comment #93) > > This would be so that customers could pick either mechanism. > > I don't see why you would need to support both at once. > > Perhaps I needed to word that more succinctly: Comcast requires you to use > both -N and -P. I think I know why, (I was thinking about ADSL and PPP). I see your dhcp request goes out an ethernet interface. I'm therefore assuming perhaps you are on a Cable Modem. http://www.nanog.org/meetings/nanog46/presentations/Tuesday/Brzozowski_introDHCP_N46.pdf says.. "Stateful DHCPv6 is required by DOCSIS for IPv6"
On the other hand, my provider provides Ipv6 for wan interface through RA (slaac), and LAN prefix via DHCPv6 IA_PD. So, i think that all posibilites should be supported. Just using -P, or jusing -N and -P.
My ISP provides IPv6 for WAN interface through RA (slaac) and LAN prefix via DHCPv6 IA_PD, too. Before I was able to run DHCPv6 client with PD, I could even take the /64 block from the WAN interface and successfully use it on the LAN interface instead. WAN interface was running fine with the IPv6 link-local address only. This is just a hack which might not work with all ISPs, though.
Created attachment 740389 [details] Add ip6_prefix_setup function to dhclient-script This patch adds a function to the script which can assign IP addresses to interfaces which are mentioned in the /etc/sysconfig/network file with a statement like DHCP6_PD="eth1 eth2 eth3" I will post the full script separately for convenience.
Created attachment 740393 [details] My patched Script file add the interfaces to your /etc/sysconfig/network eg DHCP6_PD="eth0 eth1" Only include the interfaces to be assigned an address not the interface running dhclient PS: this is only a half job, because the remaining unused prefixes should be set-up on those interfaces in a pool to be advertised via DHCPv6 PD Server downstream for other machines to pickup.
(In reply to comment #99) > Created attachment 740393 [details] Nice! Thanks. One thing missing from the radvd is munging the address for the recursive dns server (RDNSS stanza). The old address might need to be sed-ed out and replaced with the new one.
(In reply to comment #99) It should also add a blackhole route for the whole pd allocation attached to either the external interface that supplied the pd or on the "lo" loopback. The reason is that any unmapped pd space can have udp or icmp sprayed at it and the host would then route he packet upstream. The upstream would route it back. This would continue till the ttl expired, which would be the better part of 256 hops. The attacker gets a 256:1 amplification that way. On my machine I explicitly do a "ip -6 route add unreachable 2001:xxxx::/48" from an entry added by hand to /etc/sysconfig/network-scripts/route6-lo. It would be good to automate this from dhclient-scripts whenever a new pd is received.
(In reply to comment #100) > One thing missing from the radvd is munging the address for the recursive > dns server (RDNSS stanza). I don't think that DNS Servers, Domain Names etc are part of the DHCP6_PD request. unless -P -N works, see bug #836702 Here is my recommended radvd.conf interface eth0 { AdvSendAdvert on; MinRtrAdvInterval 30; MaxRtrAdvInterval 100; RDNSS fec0:0:0:1::1; prefix ::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; }; Repeat for each interface. Bind fec0:0:0:1::1 onto you site local DNS or use a well known upstream DNS Server, such as 2001:4860:4860::8888 or get one from your ISP.
(In reply to comment #101) > (In reply to comment #99) > > On my machine I explicitly do a "ip -6 route add unreachable 2001:xxxx::/48" > from an entry added by hand to /etc/sysconfig/network-scripts/route6-lo. > It would be good to automate this from dhclient-scripts whenever a new pd is > received. I like this idea.
(In reply to comment #102) > RDNSS fec0:0:0:1::1; ... > I don't think that DNS Servers, Domain Names etc are part of the DHCP6_PD request. unless -P -N works, see bug #836702 The case I'm thinking of is a user running their own recursive dns in order to get advanced services like ipv6 and dnssec and making that dns available on $prefix::1 to the local nets. When the prefix changes the line needs changing unless they use site-local or ULA. ULA might be the way to go for isp's that provide very volatile addresses. Or I suppose I could just fix radvd to understand to add the prefix to the host portion like it already does for the "prefix" stanza.
(In reply to comment #100) > (In reply to comment #99) > > Created attachment 740393 [details] > > Nice! Thanks. > Found a few bugs in this. Will post a new one after some more testing.
(In reply to comment #104) > The case I'm thinking of is a user running their own recursive dns in order > to get advanced services like ipv6 and dnssec and making that dns available > on $prefix::1 to the local nets. When the prefix changes the line needs > changing unless they use site-local or ULA. ULA might be the way to go for > isp's that provide very volatile addresses. > Wouldn't it be easier to use a site local address that never changes. At least local DNS would still work when your Internet link goes down.
Anyone know much about dhcpd for IPv6. Say I've been allocated a prefix of 2001:db8:beef:aa00::/56 I have two inside adapters eth0 and eth1 so I've allocated eth0 2001:db8:beef:aa00:5054:ff:fe0a:b80b/64 eth1 2001:db8:beef:aa01:5054:ff:feea:b5e8/64 Can I do something like this in my dhcpd server to allocate prefixes downstream? /etc/dhcp/dhcp6.conf authoritative; prefix6 2001:db8:beef:aa02:: 2001:db8:beef:aaff:: /56 subnet6 2001:db8:beef:aa00::/64 { range6 2001:db8:beef:aa00::0 2001:db8:beef:aa00::ffff/64 } subnet6 2001:db8:beef:aa01::/64 { range6 2001:db8:beef:aa01::0 2001:db8:beef:aa01::ffff/64 } My point is that I want the prefix delegation pool I have left to be available to all subnets, in case one is a lot more greedy than the others, otherwise I have to carve up the available prefix space and divide it amongst the downstream interfaces (in shell script!!). I'm thinking I'll also need to modify a script somewhere to add routes for the downstream prefixes to route them to the client that requested them.
Site local is deprecated in IPv6. Please do not use it. My ISP provides a static /56 prefix, so I can statically assign the ip of eth0, meaning all my local services correctly work even if the link is down. The only change is that ipv6 internet stops working for me. David: That is not allocating the prefix is a strict sense, that is allocating a pool of ip's from that prefix. allocating the prefix would imply you have another box one hop down connected to eth0 and eth1 that each run dhclient -P and then use that. Also, dhcp6d won't work without radvd. radvd should look like: interface eth0 { #IMPORTANT #THIS MUST BE THE FIRST OPTION ELSE IT WON'T WORK!!!! AdvSendAdvert on; AdvManagedFlag on; prefix 2001:db8:beef::/64 { AdvAutonomous off; }; }; This will *only* use dhcp6 for addressing if the client supports it, and falls back to autoconf if the client does not.
(In reply to comment #108) > Site local is deprecated in IPv6. Please do not use it. Yes, my bad. I need to think of something else. > My ISP provides a static /56 prefix, so I can statically assign the ip of > eth0, meaning all my local services correctly work even if the link is down. > The only change is that ipv6 internet stops working for me. Then I guess you won't need to use DHCPv6_PD at all. > David: That is not allocating the prefix is a strict sense, that is > allocating a pool of ip's from that prefix. allocating the prefix would > imply you have another box one hop down connected to eth0 and eth1 that each > run dhclient -P and then use that. > Sorry if I wasn't clear enough but that is exactly what I mean. When configuring a default script for fedora that will also be used by RHEL, I should be trying to cover all possibilities. I'm sure there will be cases where boxes are connecting via an intermediate rather than directly to the ISP. So your ISP gives you a /56 which is enough for 256 /64's If you primary box has 4 interfaces they could each have 64 x /64s to redelegate further on downstream. If the ISP only gives you a /60 then you only have 16 x 64. What if there is 3 internal interfaces or 7. This would be difficult to subnet in bash script. > Also, dhcp6d won't work without radvd. radvd should look like: > > interface eth0 > { > #IMPORTANT > #THIS MUST BE THE FIRST OPTION ELSE IT WON'T WORK!!!! > AdvSendAdvert on; > AdvManagedFlag on; > prefix 2001:db8:beef::/64 Have you tried using ::/64 here, radvd will read the prefix from the interface. That way we don't have to reconfigure radvd all the time. You need radvd version more recent that the one that comes with el6. The one that comes with a recent fedora will be fine. I have backported this to el6 and it's available here http://repo.bevhost.com/centos/6/x86_64/radvd-1.8.5-2.el6.x86_64.rpm http://repo.bevhost.com/centos/6/i386/radvd-1.8.5-2.el6.i386.rpm
Created attachment 740670 [details] My patched Script file #2 A few bug fixes.
(In reply to comment #107) > Anyone know much about dhcpd for IPv6. > > Say I've been allocated a prefix of 2001:db8:beef:aa00::/56 > I have two inside adapters eth0 and eth1 > I think this will do it authoritative; #Almost the entire block for downstream prefix redelegation subnet6 2001:db8:beef:aa00::/56 { prefix6 2001:db8:beef:aa02:: 2001:db8:beef:aaff:: /64 } #stateful config for eth0 subnet6 2001:db8:beef:aa00::/64 { range6 2001:db8:beef:aa00::0 2001:db8:beef:aa00::ffff/64 } #stateful config for eth1 subnet6 2001:db8:beef:aa01::/64 { range6 2001:db8:beef:aa01::0 2001:db8:beef:aa01::ffff/64 } When I run it I get a warning. Does any one know if this is a problem... Warning: subnet 2001:db8:beef:1::/32 overlaps subnet 2001:db8:beef::/32
(In reply to comment #102) > (In reply to comment #100) > > One thing missing from the radvd is munging the address for the recursive > > dns server (RDNSS stanza). > > I don't think that DNS Servers, Domain Names etc are part of the DHCP6_PD > request. unless -P -N works, see bug #836702 > > Here is my recommended radvd.conf > > interface eth0 > { > AdvSendAdvert on; > MinRtrAdvInterval 30; > MaxRtrAdvInterval 100; > RDNSS fec0:0:0:1::1; > prefix ::/64 > { > AdvOnLink on; > AdvAutonomous on; > AdvRouterAddr off; > }; > > }; I would also add DeprecatePrefix on; in "prefix ::/64" section. Reason behind this is that, you could have situation where you ISP gives you prefix for a specified time, and also, changes it every time. So, when time expires, radvd will get restarted, but clients will still have old addresses (from old prefix). Adding "DeprecatePrefix" will force radvd to send out RA message with livetime "0", and this should force clients to release old addresses, and aquire new ones. I did test this with Linux F18 and Windows 7, and it seems to work. It would be also nice to add "DecrementLifetimes" option, but then you would need to somehow indicate to radvd what is prefix livetime. > > Repeat for each interface. Bind fec0:0:0:1::1 onto you site local DNS or > use a well known upstream DNS Server, such as 2001:4860:4860::8888 or get > one from your ISP. I would also suggest to put in RDNSS that points to local interface. Just in case. In the end, this config file will be in /etc/radvd.conf and script will only restart radvd, correct? So, everyone can put inside what he/she/it likes, important part is only "prefix ::/64".
Created attachment 741830 [details] ip6_prefix_setup v4 This is my last release of this function containing new features. If bugs are found then I will fix, but otherwise this is it.
Created attachment 741831 [details] patched dhclient-script file with ip6_prefix_setup v4 This is my last release of this function containing new features. If bugs are found then I will fix, but otherwise this is it.
If you are using SELINUX enforcing mode please execute this before using the new script files. semanage fcontext -a -t dhcp_etc_t "/etc/dhcp/(.*)\.conf" semanage fcontext -a -t net_conf_t "/etc/dhcp/prefix_delegation.conf" To use the above scripts you must specify the interfaces that are to receive a delegated prefix in /etc/sysconfig/network like so:- DHCP6_PD="eth1 eth2 br0" If you want those interfaces to also bring up a DHCPv6 Server to allocate what is left of the prefix we were delegated to downstream users then you should also add DHCLIENT_CONTROLS_DHCPD=yes
When the DHCLIENT runs it creates a /etc/dhcp/prefix_delegation.conf which contains the prefixes for running a DHCPv6 Server on this inside to downstream PC's and networks. For Prefix Delegation part of this I gave serious consideration to adding static routes when a prefix was delegated downstream. On first look it would appear that this is any easy way to get downstream routing working and in really simple cases this may be right. However as complexity of the downstream network increases this becomes problematic. eg - All downstream traffic between prefixes would need to be routed via the DHCP server. - Extra work would need to be done on DHCP6 relays where they existed. - Removal of routes for old prefixes could be tricky - and it's not possible anyway because the "on commit" functions in the DHCP server do not trigger for IPv6 events and do not contain prefix data. So the long and the short of it is... run a routing protocol.
Line 681 has the dhcp server in debug mode remove "-d"
(In reply to comment #111) > (In reply to comment #107) > > Anyone know much about dhcpd for IPv6. > When I run it I get a warning. > Does any one know if this is a problem... > Warning: subnet 2001:db8:beef:1::/32 overlaps subnet 2001:db8:beef::/32 Further testing has revealed that this is indeed a problem. I will need to release a new version of the script in due course. This problem only affects redelegation of the prefix downstream.
Created attachment 743452 [details] ip6_prefix_setup v5 tested dhcpd server hands out delegated prefix for redelegation downstream
Created attachment 743453 [details] patched dhclient-script file with ip6_prefix_setup v5 The original configuration files for the redelegation of unused prefix had overlapping subnets and this is not the correct way to do it. So this script fixes that issue.
After trying to run the above script with SE Linux enabled and audit2allow produces the following. #============= dhcpc_t ============== allow dhcpc_t dhcpd_exec_t:file { read getattr open execute execute_no_trans }; allow dhcpc_t dhcpd_port_t:udp_socket name_bind; #!!!! The source type 'dhcpc_t' can write to a 'dir' of the following types: # dhcp_state_t, dhcpc_state_t, var_run_t, dhcpc_var_run_t, net_conf_t, virt_var_run_t, dhcpc_tmp_t, tmp_t, etc_t, root_t allow dhcpc_t dhcpd_state_t:dir { write remove_name search add_name }; #!!!! The source type 'dhcpc_t' can write to a 'file' of the following types: # dhcpc_state_t, dhcpc_var_run_t, net_conf_t, virt_var_run_t, dhcpc_tmp_t, root_t allow dhcpc_t dhcpd_state_t:file { rename read create write getattr link unlink open append }; allow dhcpc_t plymouth_exec_t:file { read getattr open execute execute_no_trans }; allow dhcpc_t radvd_initrc_exec_t:file getattr; allow dhcpc_t radvd_t:process signal; allow dhcpc_t radvd_var_run_t:dir search; allow dhcpc_t radvd_var_run_t:file { read getattr open }; allow dhcpc_t self:capability kill; allow dhcpc_t self:rawip_socket { create setopt };
see https://bugzilla.redhat.com/show_bug.cgi?id=967529 PPPoE does not attempt DHCPv6 Prefix Delegation
Futurefeature? The info at http://fedoraproject.org/wiki/IPv6Guide is a bit misleading: none of the scripts that do the networking actually support prefix delegation. ipv6 is by now a proven technology so it is hard to understand why /also/ this bug is moving forward so slowly even after providing a PoC scripting patch. How can we increase priority?
Hi. It seems that there is still no significant progress. Looking at latest Fedora, it seems that dnsmasq will be main dhcp/ra daemon? I did write few scripts that reconfigure dnsmasq to do PD (prefix delegation), but, i guess, they still require some polishing. If anyone is interested to get them, please levae note here, and i'll post small how-to with scripts. Regards, H.
Please post your dnsmasq work!
Hi. OK, so here it is. :-) I did test this on x86 hardware, which have USB disk - and this means that disk access speed can be erratic, and it does influence how scripts behave. I guess it more closely represent MMC based device ... There are two major issues: 1. adsl-stop script Script first kills pppd and then pppoe-connect. In turn, pppoe-connect kills pppd again, in case it is still up. Because disk can be slow, pppd takes a lot of time to start event scripts (ip-up, ip-down and so on), so adsl-start kills pppoe-connect, which kills pppd _before_ ip*-down scripts are completed/started. To go around this, i just added "sleep 0.5" between killing of pppd and pppoe-connect. It fixes this issues in 99% of cases. 2. resolv.conf update Since script execution depends on disk speed, it can happen that ifup scripts complete _before_ dhclient scripts (or vice verse). This results that resolv.conf ends up as a mess ... Or just wrong. Unfortunatelly, looking at network-functions script, and how it updates resolv.conf - there is no locking mechanism, which should prevent simultaneusly changing resolv.conf. Again, i did use simple "sleep" in dhclient script, which ensures that it's changes in resolv.conf are last ones. There is also one more problem here - resolv.conf is always overwriten. If you assume that one DNS values are provided with PPP, and some others via ipv6 dhcp, you end up with only IPv6 settings, which is (maybe) not what you wont to have. For this purpouse i introduced "DNS_KEEP" directive, which just add to existing resolv.conf. 3. dhcpv6 Two thing here. First, is you use PPP to get all parameters for IPv6, and delegated prefix, you need to know to which interface to apply it. So there is new option "DHCPV6C_LANDEVICE". In the end, there is "DHCPV6C_KEEPOLDIP". This is just a helper (call it a hack). It's purouse it to prevent dhclient-script from "killing" IPv6 address from PPP interface. Also, additional note. My provider uses slaac for IA_NA assigment, and DHCPv6 for IA_PD. So, this is the reason why this is somewhat ... complicated. :-) dhclient-script file is modified standard dhclient-script (F19 release). I did put it in /usr/loca/sbin. ipv6-up.local and ipv6-down.local local are from /etc/ppp, and are used to bootstrap everything. NOTE: scripts will generate dnsmasq conf file in /etc/dnsmasq.d. This maybe also should be put to more appropriate place .. NOTE2: i did setup NTP device on my gateway, so script assme that and set appropriate dhcp(v6) options. Examples! My LAN device is em1, p1p1 is WAN device, but i need to use vlan 100, so actually vlan100 interface is used as WAN. /etc/sysconfig/network-scripts/ifcfg-em1 PEERROUTES="yes" IPV6INIT="yes" UUID="x" IPV4_FAILURE_FATAL="no" HWADDR="x:x..." BOOTPROTO="static" IPV6_AUTOCONF="no" IPV6_FAILURE_FATAL="no" IPV6_PEERROUTES="yes" TYPE="Ethernet" ONBOOT="yes" DEVICE="em1" IPADDR="192.168.x.x" NETMASK="255.255.255.0" DNS_KEEP="yes" DHCPV6C="no" MTU="9000" /etc/sysconfig/network-scripts/ifcfg-ppp0 USERCTL=no BOOTPROTO=dialup NAME=DSLppp0 DEVICE=ppp0 TYPE=xDSL ONBOOT=no PIDFILE=/var/run/pppoe-adsl.pid PING=. PPPOE_TIMEOUT=80 LCP_FAILURE=3 LCP_INTERVAL=5 CLAMPMSS=1412 CONNECT_POLL=6 CONNECT_TIMEOUT=60 DEFROUTE=yes SYNCHRONOUS=no ETH=vlan100 PROVIDER=DSLppp0 USER=x@x PEERDNS=yes DEMAND=no UUID="x" IPV6INIT="yes" IPV6_AUTOCONF="yes" #PPPD_EXTRA="unit 0 ipv6 ," PPPD_EXTRA="ipv6 ," LINUX_PLUGIN="/usr/lib64/pppd/2.4.5/rp-pppoe.so" DHCPV6C="yes" DHCPV6C_LANDEVICE="em1" DHCPV6C_KEEPOLDIP="yes" My lan config (in /etc/dnsmasq.d/bla.conf) is: server=/x.168.192.in-addr.arpa/ local=/localdom/ interface=em1 dhcp-range=set:x1,192.168.x.100,192.168.x.200,255.255.255.0,24h dhcp-option=tag:x1,option:mtu,9000 dhcp-option=tag:x1,option:ntp-server,192.168.x.1 So, this is it. Feel free to ask for explanations ... H.
Created attachment 819281 [details] dhclient script - should be in /usr/local/sbin
Created attachment 819282 [details] ipup script for IPv6 - should be in /etc/ppp
Created attachment 819283 [details] ipdown script - should be in /etc/ppp
Thanks your posting your work and pointing out that dnsmasq has much more IPv6 capability that I was aware of. It appears to me as if this set up is in fact using dnsmasq for router advertisement rather than as a prefix delegation client, which is in fact still being done by isc dhclient in the ppp ipv6-up script. Not that there is anything wrong with that, but I am just stating what I see. Looks to me like dhclient script is then binding an IPv6 Address onto the LANDEVICE interface and then creating a config file for dnsmasq with that range statically configured. It then restarts dnsmasq. I think a better approach would be to configure dnsmasq to use it's own internal constructor so that it doesn't need to be restarted each time ppp goes up and down. eg: for slaac... --dhcp-range=::,constructor:eth0 I haven't had a chance to test any of this yet, so when I do I'll let you know.
Hi. (In reply to David Beveridge from comment #130) > Thanks your posting your work and pointing out that dnsmasq has much more > IPv6 capability that I was aware of. NP. > > It appears to me as if this set up is in fact using dnsmasq for router > advertisement rather than as a prefix delegation client, which is in fact > still being done by isc dhclient in the ppp ipv6-up script. Not that there > is anything wrong with that, but I am just stating what I see. And you are correct. ISC dhclient is used for fetching IA_PD. dnsmasq is used for DNS/DHCP/DHCPv6/RA only on LAN sde > > Looks to me like dhclient script is then binding an IPv6 Address onto the > LANDEVICE interface and then creating a config file for dnsmasq with that > range statically configured. It then restarts dnsmasq. Correct. > > I think a better approach would be to configure dnsmasq to use it's own > internal constructor so that it doesn't need to be restarted each time ppp > goes up and down. > eg: for slaac... > --dhcp-range=::,constructor:eth0 I did play with constructor part, but it does not work for "deprecated" situation. Let me explain. Let's assume that you already have IA_PD, and everything works. Then, ppp session-timeout expires. This will force ppp down, and delegated prefix is no longer valid, and you need to remove it. dnsmasq can do that, but you need to specify another line in dnsmasq conf, with "deprecated" directive. And, because you did remove IPv6 address from interface, you can not use constructor directive ... So to be consistent, i did not use it in either case. I guess it would be ok to use it for delegation, and specify range for deprecated case. > > I haven't had a chance to test any of this yet, so when I do I'll let you > know. OK, please do. Regards, H.
(In reply to Hrvoje from comment #131) > > > > I think a better approach would be to configure dnsmasq to use it's own > > internal constructor so that it doesn't need to be restarted each time ppp > > goes up and down. > > eg: for slaac... > > --dhcp-range=::,constructor:eth0 > > I did play with constructor part, but it does not work for "deprecated" > situation. Let me explain. > > Let's assume that you already have IA_PD, and everything works. Then, ppp > session-timeout expires. This will force ppp down, and delegated prefix is > no longer valid, and you need to remove it. dnsmasq can do that, but you > need to specify another line in dnsmasq conf, with "deprecated" directive. > And, because you did remove IPv6 address from interface, you can not use > constructor directive ... > > So to be consistent, i did not use it in either case. I guess it would be ok > to use it for delegation, and specify range for deprecated case. > Did you notice this from the version 2.67 dnsmasq CHANGELOG... When the address which triggered the construction of an advertised IPv6 prefix disappears, continue to advertise the prefix for up to 2 hours, with the preferred lifetime set to zero. This satisfies RFC 6204 4.3 L-13 and makes things work better if a prefix disappears without being deprecated first. Thanks to Uwe Schindler for persuasively arguing for this.
Hm ... No i did not. :-) Unfortunatelly, F19 latest dnsmasq is: # rpm -qa | grep dnsmasq dnsmasq-2.66-10.fc19.x86_64 # This means that i would need to compile it ... This somewhat complicates ... I'll try to test it ... H.
I grabbed this one http://dl.fedoraproject.org/pub/fedora/linux/releases/test/20-Alpha/Fedora/source/SRPMS/d/dnsmasq-2.67-0.6.test7.fc20.src.rpm It recompiled no problems for me (I needed to install some deps eg: dbus-devel) Let me know if you need help. Or you can grab the i386 one I made from http://repo.bevhost.com/fedora/dnsmasq-2.67-0.6.test7.fc19.i386.rpm
Also 2.67 stable version is already available in koji and in updates-tesing of F20. http://koji.fedoraproject.org/koji/buildinfo?buildID=475124
(In reply to Tomas Hozza from comment #135) > Also 2.67 stable version is already available in koji and in updates-testing > of F20. > > http://koji.fedoraproject.org/koji/buildinfo?buildID=475124 and i386 compiled for f19 here http://repo.bevhost.com/fedora/dnsmasq-2.67-1.fc19.i386.rpm Thanks Tomas
Hi. So, because u use x86_64, i did need to recompile. No errors, good. :-) And indeed, now there is no basically no need to restart dnsmasq! I did modify script to accomodate for this, and also, added "options" directory - which is reloaded with HUP. So, in dnsmasq.d i did put: dhcp-range=set:ipv6doma,::1,constructor:em1,ra-stateless,ra-names,64,24h dhcp-optsfile=/etc/dnsmasq.opts and created /etc/dnsmasq.opts. In this directory, scripts create IPv6 depended extra options, and reloads them by sending HUP to dnsmasq. It seems that this works as advertised. Now, only problem is that dnsmasq advertise those old prefixes for two hours ... And if you have a lot of ppp restarts, this can result in bit RA's with a lot of unused data. Maybe it would be good to extend dnsmasq and add option with which i could specify that only one prefix should be "depreciated". Another note is that, if gatway server crashes, clients will never get "depreciated" RA's, because dnsmasq did restart. Is solved by adding "depereciated" directive, so if dnsmasq restarts, you can catch this. Regards, H.
Created attachment 821802 [details] dhclient script with changes for norestart ...
Hi. So - no comments? :-) Then i guess that this seems good enough. I'm running this script for a week now, and it seems stable ... Still, comments would be appreciated. Regards, H.
Hi again. I did switch to F20, and again adjusted scripts. I did also try to simplfy them ... Basic steps how to make this work would be: - enable ipv4 and ipv6 forwarding - copy ipv6-up.local and ipv6-down.local to their place - place dhclient-script to /usr/local/sbin - create /etc/dnsmasq.opts dir (needed for adjusting dhcp options) - configure dnsmasq with "construct" directive - configure ppp0 ifcfg script - success. :-) Dnsmasq should have: dhcp-range=set:ipv6doma,::,constructor:<YOUR LAN IF NAME>,ra-stateless,ra-names,64,24h dhcp-optsfile=/etc/dnsmasq.opts additional things in ifcfg-ppp0: IPV6INIT="yes" IPV6_AUTOCONF="yes" PPPD_EXTRA="ipv6 ," # only if it works for you LINUX_PLUGIN="/usr/lib64/pppd/2.4.5/rp-pppoe.so" DHCPV6C="yes" DHCPV6C_LANDEVICE="<YOUR LAN IF NAME>" DHCPV6C_KEEPOLDIP="yes" dhclient-script is adjusted (and ipv6-*) so that it relies fully on dnsmasq to send proper RA's. Also, because dnsmasq reqcts only to IPv6 which have valid time "forever", this is changed in scripts. Regards, H.
Created attachment 901378 [details] Slightly changed ipv6-up.local script
Created attachment 901379 [details] Latest version of ipv6-down.local script
Created attachment 901380 [details] Latest version of dhclient-script - souorce is one from F20
What does dnsmasq do here? We have a prefix and we have autoconfiguration. Does the dhclient-script now properly and reliably handle assign/deassign/reassign of a prefix? Does it integrate well with the existing networking scripts?
Hi. (In reply to udo from comment #144) > What does dnsmasq do here? It provides DHCPv6 and radvd functionality, on LAN side. Basically, it replaces isc dhcpv6 server and radvd server. > We have a prefix and we have autoconfiguration. OK. > > Does the dhclient-script now properly and reliably handle > assign/deassign/reassign of a prefix? Well ... It does work ... For most cases ... I would not say 100% ... But it's close enough ...? :-) > Does it integrate well with the existing networking scripts? I would say yes, but there is still room for improvment - scripts need cleanup, and maybe some optimizations ... But main point here was to demonstrate proof of concept, and that it works. Regards, H.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Hi. I did test scripts that use dnsmasq, and they work on F21 without change. Regards, H.
Ok, so at the risk of stirring the pot.... This problem is also present in EL7. I'm wondering if anything has progressed in the nearly 2 years since the last comment? Is this still around in ISC DHCP 4.3.4? I also wonder if this is still present in the latest Fedora?
You may be able to use this package instead https://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/wide-dhcpv6.html
I've actually been using dibbler-client [1] - which seems to be quite handy (also in epel). I have found that the renew doesn't seem to behave somehow - which means at Lease Time / 2 the PD expires and my IPv6 range disappears. Restarting it via a stop / start of the client causes all connected TCP session on that ipv6 range to get terminated. I did try with wide-dhcpv6 - but didn't seem to have much success. 1: http://klub.com.pl/dhcpv6/
I'm still using my scripts ... :-) H.
I might as well add this to the record. My workaround for this issue right now is to add the following to a new file /sbin/ifup-local. This file runs when any interface comes up. I also have /sbin/ifdown-local which runs when any interface goes down. $ cat /sbin/ifup-local #!/bin/bash case "$1" in ppp0) LEASEFILE=/var/lib/dhclient/dhclient6.leases INTERFACE=ppp0 myhwaddr=`ip add | grep link/ether | cut -f 6 -d \ | tail -n 1 | sed s/:/\\\\\\\\x/g` echo "default-duid \"\\x00\\x03\\x00\\x01\\x$myhwaddr\";" > $LEASEFILE dhclient -v -P -lf $LEASEFILE $INTERFACE ;; *) ;; esac exit 0 $ cat /sbin/ifdown-local #!/bin/bash logger "ifdown-local: $1" case "$1" in ppp0) PIDFILE=/var/run/dhclient6.pid if [ -f $PIDFILE ]; then PID=`cat $PIDFILE` kill -9 $PID fi ;; *) esac exit 0
Can the method in Comment 152 work around the hardware address issue?
So urrmmm... nearly 5 months since the last comment, and well, I don't have enough fingers to count the months since this was first reported.... Its a little embarrassing that this is still unresolved. Do we have any progress / plan for action? or just wait until EL7 goes EOL?
(In reply to Steven Haigh from comment #154) > Do we have any progress / plan for action? No. If somebody here is willing to make this work in Fedora, feel free to request commit access for Fedora devel at https://admin.fedoraproject.org/pkgdb/package/rpms/dhcp/ and ping me by email. > or just wait until EL7 goes EOL? This ticket is for Fedora, the change would not go into EL7.
For the record, there is a 'duplicate' bug against RHEL 7 as well: https://bugzilla.redhat.com/show_bug.cgi?id=1329210
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
As this has been reassigned, any love to try and get this fixed?
Things are working quite nicely these days. I did not update dhclient-script to what is distributed. I do have a similar kinda thing to https://bugzilla.redhat.com/show_bug.cgi?id=626514#c152 in /sbin/adsl-start which is run when ppp0 is coming up. When ppp0 is up we start dhclient after the config is reset.
I still use my workaround as well - however not having to do this manually and fix the root cause is the best outcome. Right now, we're just patching it with a band-aid.
In fact, I should mention - I now integrate at the NetworkManager dispatcher level. I created /etc/NetworkManager/dispatcher.d/50-ppp-pd with the following: #!/bin/bash INTERFACE=$1 # The interface which is brought up or down STATUS=$2 # The new state of the interface case "$INTERFACE" in ppp0) if [ "$STATUS" = "up" ]; then LEASEFILE=/var/lib/dhclient/dhclient6.leases myhwaddr=`ip add | grep link/ether | cut -f 6 -d \ | tail -n 1 | sed s/:/\\\\\\\\x/g` echo "default-duid \"\\x00\\x03\\x00\\x01\\x$myhwaddr\";" > $LEASEFILE dhclient -6 -P -v -nw -lf $LEASEFILE -pf /var/run/dhclient6.pid $INTERFACE fi if [ "$STATUS" = "down" ]; then dhclient -x -pf /var/run/dhclient6.pid || true fi ;; esac exit 0
(In reply to Steven Haigh from comment #161) > In fact, I should mention - I now integrate at the NetworkManager dispatcher > level. Why not to use dhclient hooks instead?
(In reply to Pavel Zhukov from comment #162) > (In reply to Steven Haigh from comment #161) > > In fact, I should mention - I now integrate at the NetworkManager dispatcher > > level. > Why not to use dhclient hooks instead? Not sure what you mean? By default, dhclient doesn't run on PPPoE connections - hence the dispatcher script to run it.
(In reply to Steven Haigh from comment #163) > (In reply to Pavel Zhukov from comment #162) > > (In reply to Steven Haigh from comment #161) > > > In fact, I should mention - I now integrate at the NetworkManager dispatcher > > > level. > > Why not to use dhclient hooks instead? > > Not sure what you mean? > > By default, dhclient doesn't run on PPPoE connections - hence the dispatcher > script to run it. Sorry for not being clear. I meant to move part with duid calculation into dhclient pre-enter hook as it's very dhclient specific and use dispatcher for dhclient execution only.
Ah - my thoughts were purely to keep it all in one spot for the sake of being tidy. From what I understand, doing a PD over ethernet doesn't require these hacks - as they use the MAC address of the interface. Of course, a PPP connection doesn't have a MAC - hence the required hacks. Ideally, half of this could be fixed in dhclient directly - leaving only the start / stop logic for the dispatcher.
(In reply to Hrvoje from comment #67) > > 1a) This is BUG. When ppp0 is up, pppd assigns LL addresses, so this should > be enough to generate DUID. Logic in dhclient should be corrected to use > them. Unfortunately it's not enough according to RFC [1] link local in terms of ipv6 addresses is not the same as DUID LL in terms of mentioned RFC "DUID-LL MUST NOT be used by DHCP clients or servers that cannot tell whether or not a network interface is permanently attached to the device on which the DHCP client is running." So looks like the only option for now is to specify uuid manualy (generate it from existing device with proper address assigned by IANA as RFC says). Original problem (unsupported device type) is fixed long time ago so I'm closing this messy bug for now. Please open separate bugreports for another problems to make sure the problem will have proper attention. I spent more than 1 hour to go through the bug history (including radvd and rp-pppoe issues in different versions of CentOS/Fedora) and current situation is not helping to resolve the issue(s) at all. It fine to have tracking bug like "IPv6 PD in Fedora" with blocking bugs (feel free to create one or I'll do it soon or later) but not OK to put all issues in one place like this. [1] https://tools.ietf.org/html/rfc3315#section-9.4 (In reply to Steven Haigh from comment #165) > Ah - my thoughts were purely to keep it all in one spot for the sake of > being tidy. > > From what I understand, doing a PD over ethernet doesn't require these hacks > - as they use the MAC address of the interface. Of course, a PPP connection > doesn't have a MAC - hence the required hacks. > Right. dhclient uses duid ll(t) so hardware address of the interfaces must be used. . From other side MAC of any arbitrary chosen interface can be used for duid generation but it's hard to determinate which device is permanently connected to the "server" and which is not (wireless interfaces, USB, veth etc etc).
Bug for DUID issue: https://bugzilla.redhat.com/show_bug.cgi?id=1555387
Do we have a working Prefix-Delegation model for Fedora and as a result for RHEL? I'd like to see us have something which is supported in RHEL and developed upstream and not a custom script. Do we have anyone working on this who I could connect with to test things out?