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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
