Yet another IPv6 Prefix Delegation question
scott-isc at shambarger.net
Thu Jul 5 22:06:58 UTC 2012
On 2012-07-04 12:23, Vladimir-M. Obelic wrote:
> How am I supposed to do that with just 'dhclient -P eth0' here?
> I'm aware only one interface can be used for PD for now, but how do I
> specify which downstream interface gets the prefix?
> I am able to get the prefix, but what is supposed to happen next?
I struggled with the same issue, and basically came to the conclusion
that dhclient will only allow you to process the prefix in your
dhclient-script (or in my case, dhclient-exit-hooks, called from my
dhclient-script on Fedora), and doesn't do anything with it internally.
So I had my script-hook assign an address from the prefix to the LAN
interface, and ping radvd to advertise it.
The real problem I ran into was when I wanted to get a public address
for the WAN at the same time (rfc3633 says the PD shouldn't be used on
the requesting interface). You _can_ run dhclient -P -N to re-enable
address assignment, but the mix does weird things in the state machine
since INIT-REBOOT becomes a REBIND6 when a prefix is requested...
leading to a address REBIND6 with old_ip == new_ip for the assigned
address, which dhclient-script seems to think is a noop.
I ended up patching dhc6.c to look for a specially named pseudo
interface (hard coded as "pd-handler"), and if it finds it, assigns any
delegated prefix queries to it; since the pseudo interface is an
independent state machine, that leaves the regular address query to work
as normal (which is actually how the RFC says it should work). Of
course there are issues with needing to set the client-identifier, since
dhclient doesn't follow rfc4361 and mix the IAID and DUID in creating
the automatic ones... but that's another matter.
I submitted the patch to dhcp-bugs, but haven't heard any comments on
it. I also submitted it downstream at
https://bugzilla.redhat.com/show_bug.cgi?id=836702 in case anyone wants
to check it out.
(also had to fix a bug with lease6 not saving the "name" attribute,
which was causing a restart to get quite confused...)
More information about the dhcp-users