Bug 626514 - ISC dhcp does not support ppp and ipv6 as in`dhclient -6 -P` [NEEDINFO]
ISC dhcp does not support ppp and ipv6 as in`dhclient -6 -P`
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
rawhide
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-23 13:45 EDT by udo
Modified: 2016-08-21 01:53 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
udovdh: needinfo? (jpopelka)


Attachments (Terms of Use)
handle PD etc (2.94 KB, patch)
2010-09-04 08:17 EDT, udo
no flags Details | Diff
handle PD etc (3.79 KB, patch)
2010-09-04 09:25 EDT, udo
no flags Details | Diff
handle PD (2.15 KB, patch)
2010-09-05 03:36 EDT, udo
no flags Details | Diff
handle PD and radvd (3.61 KB, patch)
2010-09-09 12:50 EDT, udo
no flags Details | Diff
handle PD and radvd (6.07 KB, patch)
2010-09-13 10:14 EDT, udo
no flags Details | Diff
diff beteen lpf.c from 4.2.3-8 to 4.2.3-9 (10.80 KB, patch)
2012-07-04 12:16 EDT, udo
no flags Details | Diff
example program from getifaddrs(3) man page (1.91 KB, text/plain)
2012-07-18 11:04 EDT, Jiri Popelka
no flags Details
Sample configuration for dhclient.conf (185 bytes, text/plain)
2012-08-05 05:40 EDT, Hrvoje
no flags Details
dhclient wrapper script (2.17 KB, text/plain)
2012-08-05 05:41 EDT, Hrvoje
no flags Details
dhclient autoconfiguration script (4.03 KB, text/plain)
2012-08-05 05:42 EDT, Hrvoje
no flags Details
pppd infterface down script (823 bytes, text/plain)
2012-08-05 05:42 EDT, Hrvoje
no flags Details
pppd interface up script (1.18 KB, text/plain)
2012-08-05 05:43 EDT, Hrvoje
no flags Details
Add ip6_prefix_setup function to dhclient-script (2.85 KB, patch)
2013-04-26 09:18 EDT, David Beveridge
no flags Details | Diff
My patched Script file (27.81 KB, text/plain)
2013-04-26 09:23 EDT, David Beveridge
no flags Details
My patched Script file #2 (28.07 KB, application/octet-stream)
2013-04-26 23:26 EDT, David Beveridge
no flags Details
ip6_prefix_setup v4 (6.28 KB, patch)
2013-04-30 06:32 EDT, David Beveridge
no flags Details | Diff
patched dhclient-script file with ip6_prefix_setup v4 (30.75 KB, text/plain)
2013-04-30 06:33 EDT, David Beveridge
no flags Details
ip6_prefix_setup v5 (7.39 KB, patch)
2013-05-04 02:11 EDT, David Beveridge
no flags Details | Diff
patched dhclient-script file with ip6_prefix_setup v5 (31.56 KB, text/plain)
2013-05-04 02:15 EDT, David Beveridge
no flags Details
dhclient script - should be in /usr/local/sbin (29.78 KB, text/plain)
2013-11-04 12:37 EST, Hrvoje
no flags Details
ipup script for IPv6 - should be in /etc/ppp (1.11 KB, application/x-shellscript)
2013-11-04 12:37 EST, Hrvoje
no flags Details
ipdown script - should be in /etc/ppp (1.45 KB, application/x-shellscript)
2013-11-04 12:38 EST, Hrvoje
no flags Details
dhclient script with changes for norestart ... (29.70 KB, application/x-shellscript)
2013-11-08 16:42 EST, Hrvoje
no flags Details
Slightly changed ipv6-up.local script (1.38 KB, text/plain)
2014-06-02 04:41 EDT, Hrvoje
no flags Details
Latest version of ipv6-down.local script (1.63 KB, text/plain)
2014-06-02 04:43 EDT, Hrvoje
no flags Details
Latest version of dhclient-script - souorce is one from F20 (30.61 KB, text/plain)
2014-06-02 04:44 EDT, Hrvoje
no flags Details

  None (edit)
Description udo 2010-08-23 13:45:38 EDT
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.
Comment 1 Jiri Popelka 2010-08-24 12:55:10 EDT
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.
Comment 2 udo 2010-08-24 13:32:18 EDT
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.
Comment 3 Pim Zandbergen 2010-08-26 05:37:35 EDT
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/
Comment 4 udo 2010-08-26 09:23:46 EDT
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?)
Comment 5 udo 2010-09-02 12:29:26 EDT
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)
Comment 6 udo 2010-09-03 08:59:39 EDT
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...
Comment 7 Jiri Popelka 2010-09-03 10:32:19 EDT
(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.
Comment 8 udo 2010-09-03 11:30:37 EDT
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).
Comment 9 udo 2010-09-03 11:38:28 EDT
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
Comment 10 udo 2010-09-04 04:02:56 EDT
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
Comment 11 udo 2010-09-04 08:17:56 EDT
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.
Comment 12 udo 2010-09-04 09:25:17 EDT
Created attachment 443060 [details]
handle PD etc

Work in progress, tries to handle PD case
Comment 13 udo 2010-09-05 03:35:26 EDT
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.
Comment 14 udo 2010-09-05 03:36:13 EDT
Created attachment 443128 [details]
handle PD
Comment 15 udo 2010-09-07 09:36:14 EDT
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?
Comment 16 udo 2010-09-07 10:42:06 EDT
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?
Comment 17 udo 2010-09-09 12:50:58 EDT
Created attachment 446301 [details]
handle PD and radvd
Comment 18 udo 2010-09-09 12:52:43 EDT
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.
Comment 19 udo 2010-09-12 03:42:39 EDT
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 ?)
Comment 20 udo 2010-09-12 06:29:05 EDT
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.
Comment 21 udo 2010-09-13 10:14:25 EDT
Created attachment 446939 [details]
handle PD and radvd

This patch has a workaround for the 'RTNETLINK
answers: File exists' message.
Comment 22 Glen Eustace 2010-11-04 15:12:26 EDT
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.
Comment 23 Jiri Popelka 2010-11-04 15:20:43 EDT
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 :-)
Comment 24 Jiri Popelka 2010-11-09 11:31:02 EST
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.
Comment 25 udo 2010-11-09 11:39:33 EST
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)
Comment 27 udo 2011-11-06 08:04:47 EST
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?
Comment 28 udo 2012-03-25 07:16:37 EDT
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?
Comment 29 udo 2012-07-02 12:54:20 EDT
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..
Comment 30 udo 2012-07-02 13:11:39 EDT
How to fix this?
Now ipv6 PD is totall down here.
Comment 31 udo 2012-07-02 13:59:58 EDT
# 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?
Comment 32 Jiri Popelka 2012-07-03 07:54:53 EDT
(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.
Comment 33 udo 2012-07-03 09:01:24 EDT
Maybe I added the ppp patch myself, I'll try some inbetween versions.
Comment 34 udo 2012-07-03 09:11:46 EDT
4.2.3-8.P2 works....
Comment 35 udo 2012-07-03 09:35:26 EDT
4.2.4-0.4-rc1: Failed to get HW address for ppp0
Comment 36 udo 2012-07-03 11:01:44 EDT
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?
Comment 37 Jiri Popelka 2012-07-04 08:35:27 EDT
(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 ?
Comment 38 udo 2012-07-04 09:02:01 EDT
i686/i386 please?
Comment 39 udo 2012-07-04 09:07:03 EDT
Building i686 myself.
Comment 40 Jiri Popelka 2012-07-04 09:14:02 EDT
I sent wrong link, sorry
http://koji.fedoraproject.org/koji/taskinfo?taskID=4218261
Comment 41 udo 2012-07-04 09:27:04 EDT
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.
Comment 42 udo 2012-07-04 09:35:52 EDT
Same deal for koji build.
Comment 43 Jiri Popelka 2012-07-04 10:01:34 EDT
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.
Comment 44 udo 2012-07-04 10:09:52 EDT
Jiri, exactly what do you want me to do?
Binary diff?
gdb?

Currently I am looking into the 'case' statement in 4.2.4.
Comment 45 Jiri Popelka 2012-07-04 10:30:22 EDT
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
Comment 46 udo 2012-07-04 10:47:44 EDT
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.
Comment 47 udo 2012-07-04 11:41:22 EDT
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.
Comment 48 udo 2012-07-04 12:16:45 EDT
Created attachment 596257 [details]
diff beteen lpf.c from 4.2.3-8 to 4.2.3-9
Comment 49 Jiri Popelka 2012-07-04 12:35:58 EDT
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
Comment 50 udo 2012-07-04 12:40:35 EDT
I used dhcp-4.2.3-8.P2.fc16.src.rpm  and dhcp-4.2.3-9.P1.fc17.src.rpm
Comment 51 Jiri Popelka 2012-07-04 12:43:08 EDT
(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
                           ^                                 ^
Comment 52 udo 2012-07-04 12:45:15 EDT
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?!
Comment 53 udo 2012-07-05 09:14:32 EDT
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?
Comment 54 udo 2012-07-05 09:18:25 EDT
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.
Comment 55 udo 2012-07-05 23:08:00 EDT
Furthermore I see no lower version fc17 releases.
So what can I do?
Comment 56 udo 2012-07-06 01:00:17 EDT
Jiri,

The cause:

* Mon Sep 19 2011 Jiri Popelka <jpopelka@redhat.com> - 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.
Comment 57 udo 2012-07-06 10:16:44 EDT
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.
Comment 58 Jiri Popelka 2012-07-07 05:01:09 EDT
(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.
Comment 59 udo 2012-07-07 05:06:27 EDT
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.
Comment 60 Jiri Popelka 2012-07-18 11:04:09 EDT
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.
Comment 61 udo 2012-07-18 11:10:12 EDT
# 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)
Comment 62 Jiri Popelka 2012-07-18 15:21:55 EDT
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.
Comment 63 Jiri Popelka 2012-07-18 16:08:08 EDT
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
Comment 64 udo 2012-07-19 09:13:18 EDT
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)
Comment 65 udo 2012-07-22 11:40:02 EDT
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...
Comment 66 Jiri Popelka 2012-07-23 08:18:04 EDT
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.
Comment 67 Hrvoje 2012-08-05 05:12:31 EDT
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.
Comment 68 Hrvoje 2012-08-05 05:40:13 EDT
Created attachment 602341 [details]
Sample configuration for dhclient.conf
Comment 69 Hrvoje 2012-08-05 05:41:12 EDT
Created attachment 602342 [details]
dhclient wrapper script
Comment 70 Hrvoje 2012-08-05 05:42:05 EDT
Created attachment 602343 [details]
dhclient autoconfiguration script
Comment 71 Hrvoje 2012-08-05 05:42:54 EDT
Created attachment 602344 [details]
pppd infterface down script
Comment 72 Hrvoje 2012-08-05 05:43:28 EDT
Created attachment 602345 [details]
pppd interface up script
Comment 73 udo 2012-11-11 10:13:49 EST
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.
Comment 74 William Brown 2012-12-05 07:14:40 EST
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.
Comment 75 Wolfgang Rupprecht 2013-02-11 05:34:54 EST
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 {
	};
};
Comment 76 Fedora End Of Life 2013-04-03 15:53:30 EDT
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
Comment 77 David Beveridge 2013-04-24 18:56:30 EDT
see
https://bugzilla.redhat.com/show_bug.cgi?id=956147
Review Request: wide-dhcpv6 - DHCPv6 Prefix Delegation client that works on PPP
Comment 78 William Brown 2013-04-24 20:55:15 EDT
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.
Comment 79 Leoš Bitto 2013-04-25 04:19:15 EDT
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.
Comment 80 Hrvoje 2013-04-25 08:10:12 EDT
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.
Comment 81 William Brown 2013-04-25 09:00:53 EDT
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)
Comment 82 Leoš Bitto 2013-04-25 09:05:32 EDT
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.
Comment 83 David Beveridge 2013-04-25 10:11:05 EDT
(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.
Comment 84 udo 2013-04-25 10:14:55 EDT
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!
Comment 85 David Beveridge 2013-04-25 10:30:00 EDT
I think this guy might be on the right track
http://www.phildev.net/phil/blog/?p=308
Comment 86 Hrvoje 2013-04-25 11:31:13 EDT
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.
Comment 87 Wolfgang Rupprecht 2013-04-25 11:37:09 EDT
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.
Comment 88 Jiri Popelka 2013-04-25 11:51:33 EDT
That's bug #836702 I think.
Comment 89 Hrvoje 2013-04-25 15:19:42 EDT
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.
Comment 90 Wolfgang Rupprecht 2013-04-25 16:25:28 EDT
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.
Comment 91 Hrvoje 2013-04-25 16:50:51 EDT
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.
Comment 92 Wolfgang Rupprecht 2013-04-25 17:04:52 EDT
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.
Comment 93 David Beveridge 2013-04-25 18:44:44 EDT
(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.
Comment 94 Wolfgang Rupprecht 2013-04-25 19:06:52 EDT
(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.
Comment 95 David Beveridge 2013-04-25 19:46:05 EDT
(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"
Comment 96 Hrvoje 2013-04-26 05:54:01 EDT
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.
Comment 97 Leoš Bitto 2013-04-26 05:58:28 EDT
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.
Comment 98 David Beveridge 2013-04-26 09:18:49 EDT
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.
Comment 99 David Beveridge 2013-04-26 09:23:57 EDT
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.
Comment 100 Wolfgang Rupprecht 2013-04-26 15:40:34 EDT
(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.
Comment 101 Wolfgang Rupprecht 2013-04-26 17:57:33 EDT
(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.
Comment 102 David Beveridge 2013-04-26 18:18:49 EDT
(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.
Comment 103 David Beveridge 2013-04-26 18:22:10 EDT
(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.
Comment 104 Wolfgang Rupprecht 2013-04-26 18:42:56 EDT
(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.
Comment 105 David Beveridge 2013-04-26 19:31:12 EDT
(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.
Comment 106 David Beveridge 2013-04-26 19:34:26 EDT
(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.
Comment 107 David Beveridge 2013-04-26 19:52:05 EDT
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.
Comment 108 William Brown 2013-04-26 19:57:42 EDT
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.
Comment 109 David Beveridge 2013-04-26 23:08:34 EDT
(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
Comment 110 David Beveridge 2013-04-26 23:26:46 EDT
Created attachment 740670 [details]
My patched Script file #2

A few bug fixes.
Comment 111 David Beveridge 2013-04-27 05:51:22 EDT
(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
Comment 112 Hrvoje 2013-04-28 04:38:01 EDT
(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".
Comment 113 David Beveridge 2013-04-30 06:32:05 EDT
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.
Comment 114 David Beveridge 2013-04-30 06:33:31 EDT
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.
Comment 115 David Beveridge 2013-04-30 06:40:39 EDT
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
Comment 116 David Beveridge 2013-04-30 06:50:02 EDT
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.
Comment 117 David Beveridge 2013-04-30 07:57:00 EDT
Line 681 has the dhcp server in debug mode
remove "-d"
Comment 118 David Beveridge 2013-05-01 08:07:57 EDT
(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.
Comment 119 David Beveridge 2013-05-04 02:11:10 EDT
Created attachment 743452 [details]
ip6_prefix_setup v5

tested dhcpd server hands out delegated prefix for redelegation downstream
Comment 120 David Beveridge 2013-05-04 02:15:43 EDT
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.
Comment 121 David Beveridge 2013-05-04 02:17:00 EDT
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 };
Comment 122 David Beveridge 2013-05-27 07:32:26 EDT
see https://bugzilla.redhat.com/show_bug.cgi?id=967529
PPPoE does not attempt DHCPv6 Prefix Delegation
Comment 123 udo 2013-08-22 09:07:20 EDT
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?
Comment 124 Hrvoje 2013-11-02 16:13:10 EDT
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.
Comment 125 udo 2013-11-03 01:16:13 EST
Please post your dnsmasq work!
Comment 126 Hrvoje 2013-11-04 12:30:35 EST
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.
Comment 127 Hrvoje 2013-11-04 12:37:02 EST
Created attachment 819281 [details]
dhclient script - should be in /usr/local/sbin
Comment 128 Hrvoje 2013-11-04 12:37:56 EST
Created attachment 819282 [details]
ipup script for IPv6 - should be in /etc/ppp
Comment 129 Hrvoje 2013-11-04 12:38:39 EST
Created attachment 819283 [details]
ipdown script - should be in /etc/ppp
Comment 130 David Beveridge 2013-11-05 01:15:11 EST
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.
Comment 131 Hrvoje 2013-11-05 08:35:14 EST
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.
Comment 132 David Beveridge 2013-11-05 21:32:10 EST
(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.
Comment 133 Hrvoje 2013-11-06 04:30:17 EST
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.
Comment 134 David Beveridge 2013-11-06 06:09:53 EST
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
Comment 135 Tomas Hozza 2013-11-06 06:20:13 EST
Also 2.67 stable version is already available in koji and in updates-tesing of F20.

http://koji.fedoraproject.org/koji/buildinfo?buildID=475124
Comment 136 David Beveridge 2013-11-06 06:36:24 EST
(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
Comment 137 Hrvoje 2013-11-08 16:41:34 EST
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.
Comment 138 Hrvoje 2013-11-08 16:42:34 EST
Created attachment 821802 [details]
dhclient script with changes for norestart ...
Comment 139 Hrvoje 2013-11-17 06:08:57 EST
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.
Comment 140 Hrvoje 2014-06-02 04:38:32 EDT
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.
Comment 141 Hrvoje 2014-06-02 04:41:37 EDT
Created attachment 901378 [details]
Slightly changed ipv6-up.local script
Comment 142 Hrvoje 2014-06-02 04:43:11 EDT
Created attachment 901379 [details]
Latest version of ipv6-down.local script
Comment 143 Hrvoje 2014-06-02 04:44:57 EDT
Created attachment 901380 [details]
Latest version of dhclient-script - souorce is one from F20
Comment 144 udo 2014-06-03 10:11:56 EDT
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?
Comment 145 Hrvoje 2014-06-03 10:24:48 EDT
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.
Comment 146 Fedora End Of Life 2015-01-09 16:45:14 EST
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.
Comment 147 Hrvoje 2015-01-12 10:37:16 EST
Hi.

I did test scripts that use dnsmasq, and they work on F21 without change.

Regards,

H.
Comment 148 Steven Haigh 2016-04-21 09:33:39 EDT
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?
Comment 149 David Beveridge 2016-04-21 20:23:04 EDT
You may be able to use this package instead
https://dl.fedoraproject.org/pub/epel/7/x86_64/repoview/wide-dhcpv6.html
Comment 150 Steven Haigh 2016-04-21 21:57:13 EDT
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/
Comment 151 Hrvoje 2016-04-24 16:04:09 EDT
I'm still using my scripts ...  :-)

H.
Comment 152 Steven Haigh 2016-08-17 01:47:54 EDT
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
Comment 153 udo 2016-08-21 01:53:11 EDT
Can the method in Comment 152 work around the hardware address issue?

Note You need to log in before you can comment on or make changes to this bug.