Re: Bug#632915: ifupdown: DHCPv6 support

Colin Watson <[email protected]> writes:

> Please remember to CC the bug report on replies.  I wouldn't object to
> being CCed as well.

OK. 

> On Thu, Jul 07, 2011 at 10:39:44AM +0200, Bjørn Mork wrote:
>> Bjørn Mork <[email protected]> writes:
>> > Colin Watson <[email protected]> writes:
>> >> I was initially going to support wide-dhcpv6-client as well as
>> >> isc-dhcp-client, but it was rather harder to integrate into ifupdown,
>> >> since doing stateful DHCPv6 there requires writing out custom
>> >> configuration files rather than just passing the right command line
>> >> options.  isc-dhcp-client is Priority: important, so this ought to be
>> >> good enough for most people.
>> >
>> > Nope, sorry.  isc-dhcp-client  has no support for ppp interfaces, which
>> > makes it useless for lots of people.  See e.g. xs4all's IPv6 access
>> > service.
>
> OK.  Thanks for that feedback.  (That said, I don't think this needs to
> block deployment of DHCPv6 support in ifupdown; wide-dhcpv6-client
> support seems to fall in the category of things that can be added later
> without compatibility problems, and adding isc-dhcp-client support does
> not make things any worse for wide-dhcpv6-client users.)  Do you know if
> anyone is working on PPP support in isc-dhcp-client?  I can't find a bug
> report for it.

I know of patches posted and discussed:
https://lists.isc.org/pipermail/dhcp-users/2010-April/011253.html

Don't know the status, but the issue is certainly known upstream.

See also this old thread on the ipv6-ops list:
http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002771.html
where Shane Kerr from ISC gave some insight into the problem.  I believe
that discussion may have  continued on the ISC DHCP list, but I didn't
have time to followup.  Unfortunately.  I should really be more careful
before starting such discussions as this one...



> It is, incidentally, unfortunate that dhcp6c does not wait for a lease
> before daemonising.  dhclient's behaviour is distinctly superior here
> from the point of view of integrating it into the boot process.

I'm not at all convinced by this.  I believe you are thing far too much
traditional IPv4 auto-configuration here.  I don't think DHCPv6 failure
ever should prevent an interface from coming up.  Which makes the state
of DHCPv6 completely irrelevant to ifupdown.

>  With
> dhcp6c, you have the choice between running it in the foreground and
> having to mess about with process supervision, and running it as a
> daemon and carrying on with other work before the interface is actually
> up.  Neither is very appealing.
>
>> And to provide a solution instead: Yes, wide-dhcpv6-client will require
>> a config file.  But the version packaged in Debian does not need require
>> a *custom written* one. It has support for "profiles", and you can get
>> away with a static config like this (note: no interface specific info
>> here):
>> 
>> profile default
>> {
>>   send ia-na 0;
>> };
>> 
>> 
>> and a command line like this:
>> 
>> dhcp6c -P default $IFACE
>
> It appears that it would still need to be custom-written, as at the
> moment the dhcp6c.conf shipped in the Debian package does not contain
> such a profile.  I would rather avoid ifupdown having to write out a
> profile fragment.

I assume adding a reasonaly default template won't to the Debian package
won't be a problem, but you could also include one with ifupdown and
just point dhcp6c there for any ifupdown managed interface:

 dhcp6c -c /usr/share/ifupdown/dhcp6c.conf -P default $IFACE

> In the stateless code, I also have to trust that nobody has modified the
> 'default' profile to be stateful, otherwise things will go wrong.
>
> Do you think it would be appropriate to append this to the stock
> dhcp6c.conf?  The duplicate 'profile stateless' is to avoid ambiguity in
> case somebody has modified 'profile default'.
>
>   profile stateless
>   {
>     information-only;
>   
>     request domain-name-servers;
>     request domain-name;
>   
>     script "/etc/wide-dhcpv6/dhcp6c-script";
>   };
>   
>   profile stateful
>   {
>     send ia-na 0;
>     
>     request domain-name-servers;
>     request domain-name;
>     
>     script "/etc/wide-dhcpv6/dhcp6c-script";
>   }
>   
>   id-assoc na 0 {
>   };

Looks sane to me, but I believe the Debian wide-dhcpv6 maintainer is
much much more qualified to comment.  After all, I'm mostly focused on
making this work  on a single access network.  Which is kind-of narrow...

> There are other packaging issues that need to be addressed before we
> could add wide-dhcpv6-client support to ifupdown (CCing the maintainer).
>
> wide-dhcpv6-client installs into /usr, making it unsuitable for
> infrastructural use on a system with a separate /usr.  That will
> presumably need to be changed.  Unfortunately, ifupdown's execable()
> function takes an absolute path, so there would be a compatibility
> problem if we added support to ifupdown first.  We should probably fix
> execable() to do a full $PATH search for non-absolute paths.
>
> It is not clear to me how to handle multiple interfaces.
> wide-dhcpv6-client ships an /etc/wide-dhcpv6/dhcp6c-ifupdown script
> which uses dhcp6ctl to talk to a running dhcp6c client.  I see no way to
> run two clients at once and still use dhcp6ctl: dhcp6c doesn't document
> a way to change the port it listens on, and in any case having to
> configure this from ifupdown would be tedious. 

I don't think a non-standard port would work in any case.  The servers
will expect the default port.

> wide-dhcpv6-client ships
> an init script, and may already be configured to run as a daemon on many
> systems.  You can only pass the profile to dhcp6c, not dhcp6ctl, so if
> you need to run stateless DHCPv6 on one interface and stateful DHCPv6 on
> another then it looks like you need to run multiple dhcp6c processes at
> once.  Is this supported? 

This is a very good point.  No, I don't think that is currently
supported and that's probably a showstopper for any useful ifupdown
integration using the "profile" extension.

Currently you would need to write a custom configuration file naming all
interfaces and run a single dhcp6c instance using this configuration if
you are going to support multiple interfaces with different configu rations.


> If so, what is the supported way to stop one
> of multiple existing dhcp6c processes, bearing in mind that 'dhcp6ctl
> stop' won't work for the reason just given?  We'll need to do that on
> ifdown.
>
> In general, I think somebody who knows WIDE well needs to figure out how
> it could be nicely integrated into ifupdown.
> /etc/wide-dhcpv6/dhcp6c-ifupdown is a reasonable stopgap, but it doesn't
> seem to fit well with configuring stateless/stateful DHCPv6 in
> /etc/network/interfaces the way I propose, which is the neatest fit I
> can think of to the /etc/network/interfaces model.

I appreciate this fruitful discussion. Sorry about the long RTT due to
vacation... 


Bjørn