Re: Bug#632915: ifupdown: DHCPv6 support
Colin Watson <cjwatson@ubuntu.com> 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 <bjorn@mork.no> writes:
>> > Colin Watson <cjwatson@ubuntu.com> 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
Reply to: