Re: Grrrr ... dhcpd6

[Bjørn Mork <bjorn mork no>]

Pavel Simerda <psimerda redhat com> writes:

> ----- Original Message -----
>> From: "Bjørn Mork" <bjorn mork no>
>> To: "Gene Czarcinski" <gene czarc net>
>> Cc: networkmanager-list gnome org
>> Sent: Friday, September 28, 2012 10:46:31 AM
>> Subject: Re: Grrrr ... dhcpd6
>> 
>> Gene Czarcinski <gene czarc net> writes:
>> 
>> > OK, anyone have any experience sending commands, requests etc. via
>> > dhclient?
>> 
>> Well, if you ask me (OK, you didn't, but I am answering anyway :-)
>> then
>> the IPv6 support in the ISC dhclient is far from mature enough to be
>> used for anything yet, and it moves at a pace which... I don't think
>> it
>> will ever become useful outside simple lab experiments.  The PD
>> support
>> is unconfigurable.  There is no support for PPP interfaces. Both of
>> these are show stoppers.  IMHO, you have *no* DHCPv6 support worth
>> mentioning without them.
>
> The basic DHCP usecases are covered by dhclient.

If you meant DHCPv6, then I do not agree.  It doesn't support the
currently most popular ISP configuration: DHCPv6-PD over PPP.


>> And this is not because these features are difficult to add.  There
>> have
>> been feature requests and patches circulating for years.  Here's one
>> example:
>> https://lists.isc.org/pipermail/dhcp-users/2010-April/011624.html
>
> Then the fist step might be to get the patchset into distributions if
> it's good enough to be added. It can be used for a while and then
> submitted again for inclusion. Poking jpopelka for that.

I wish you good luck with that.  Upstream is a black patch hole in my
experience.

>> Being able to configure an IA_NA address on an ethernet interface is
>> just not enough.
>
> It's one of the two most important features of DHCPv6, the other being
> conveying DNS information to hosts that also works.

Only if the host is connected by ethernet...  That is an odd DHCP legacy
restriction, and not the way the DHCPv6 protocol was designed.

>> Look further and plan for the other features you
>> *must* support. 
>
> Could you please specify which of the features are required in host
> implementations? Currently I only know about the options Gene is trying
> to use. But that looks to me too easy to be a good reason to abandon
> dhclient.

As I said, I'd like to see PPP support and configurable PD support.  At
the very least, I want to create rules for splitting a prefix over the
available host interfaces. But I can understand if you define those
features as out of scope for a host implementation.  That's OK as long
as everybody is aware of these limitations.

>> Using the ISC dhclient is a dead end.
>> 
>> I believe the ISC development model just does not work anymore.  It
>> belongs in another millennium.  Sorry.
>
> You *may* be right. But, unfortunately, I have been playing with DHCPv6
> implementations and there wasn't one that I would actually like. Except
> ISC DHCP which works for me but needs improvement.
>
>> Hmm, looking at https://bugzilla.redhat.com/show_bug.cgi?id=626514 it
>> seems that Redhat is using a heavily patched ISC dhclient, fixing
>> these shortcomings.
>
> And this can continue and distributions are free to include the patches.
>
>> But I wonder if they are prepared to take over as upstream?  If not,
>> then I suggest that NM development look for other
>> options,
>
> I would like to see one single option that matches or even exceeds the
> quality of ISC DHCP, which is not perfect, but still rather good. Look
> at the RH-patched version.

I did an exercise on this a few years ago, and I do agree that there is
no perfect candidate. Unfortunately I don't think the picture has
changed much since this thread:
http://www.gossamer-threads.com/lists/nsp/ipv6/20683

Shane Kerr from ISC had some promising answers back then, but time has
shown that they are unable to deliver.  The BIND10 project is moving the
right direction, but it is still not open enough to attract a large
number of developers.  So it moves very slowly.  And the DHCP code there
is not yet ready for anything, I believe.

>> or the DHCPv6 support will be unmaintainable on any non Redhat distribution.
>
> To summarize the possibilities:
>
> 1) Continue using ISC DHCP. Integrate the necessary patches upstream.
>
> 2) Use a fork of ISC DHCP that integrates the patches. Or maintain a
> cross-distro patchset.
>
> 3) Find/create a real DHCP client (even dhclient doesn't work as a DHCP client
> without NetworkManager's dhclient-script).
>
> I'm all for taking the best route. But... dhclient works pretty well for most
> common use cases. And we're not going to make default anything that breaks
> those.
>
> And if we're pushing such a big change, I would only ever go for a proper solution.
> The new DHCP client should work well for the current use cases and bring improvement
> to new use cases. And it should really work as a DHCP client and should *not*, at
> least with proper commandline option, try to be a network configuration daemon.
>
> The only goal of a DHCP client for the modern networking is to maintain the DHCP state
> and convey the DHCP configuration changes to the network configuration daemon. Again,
> dhclient does it, but only with NetworkManager's dhclient-script.

I am not sure if you are talking about DHCPv6 here or not.  Just to make
it clear: The ISC dhclient is the best open source DHCP client I know
of. I am not suggesting that it should be replaced.  But I believe ISC
has demonstrated quite well that reusing the IPv4 DHCP code does not
make a DHCPv6 client. So you may want to choose something else for
DHCPv6.

As Tore pointed out: Considering upstream maintenance, the only real
option at the moment is dibbler.


Bjørn