Re: Grrrr ... dhcpd6
On 10/01/2012 11:44 AM, Jiri Popelka wrote: On 09/27/2012 10:22 PM, Gene Czarcinski wrote: also request fqdn.fqdn; also request fqdn.hostname; also request fqdn.domainname; These are DHCPv4 options which DHCPv6 client doesn't know. That is not clear. The dhcp-options man-page could be interpreted either way. also request dhcp6.hostname; also request dhcp6.domainname; I can't find such options in dhcp-options(5). I was grasping at straws. also request dhcp6.domain-search; This is requested by default as well as dhcp6.name-servers. See request statement in dhclient.conf(5) also request dhcp6.client-id; dhcp6.client-id is provided by client so I see no reason to request it from server. also request dhcp6.server-id; I'd say that dhcpv6 server sends this by default, by it's only a guess. This last requests are provided by dnsmasq so I thought it would be good to ask for them. And then there is (draft) RFC4704 where it says "Servers SHOULD send the complete fully qualified domain name in Client FQDN options." But, then it is "just" a draft RFC so maybe it is OK to ignore this. I did not want to assume that what they were suppose to send to the client would be sent. Regardless, the "current" patch had to "extra" stuff removed. And it does work ... integration is "in process." Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
On 10/01/2012 12:47 PM, Jiri Popelka wrote: On 10/01/2012 06:33 PM, Gene Czarcinski wrote: One of the problems I see is that, while there are a couple of viable dchp servers out there, where the ISC server is suppose to be the industrial strength one, dhclient seems to be the only client for the linux/*bsd/Unix systems. I wonder if there is interest in reviving the defunct dhcpv6c effort? If you mean https://fedorahosted.org/dhcpv6/ then no. It was also one-guy effort and David Cantrell stopped the development immediately after ISC dhcp-4.1.0 was released. Yes, there is dribbler but that seems like a one-guy effort and I do not see much support for it ... yes, dnsmasq is another one-guy effort but it also is popluar and has other people fixing things and submitting patches. I have no experience with Dibbler, but I believe it's a good implementation because Tomasz Mrugalski is very active on dhcwg at ietf.org Right now I believe we just grin and bear it with dhclient. Maybe ISC gets their act together, and mabe it does not. Maybe dribbler starts getting use and interest ... after all, dnsmasq seems to have gotten a lot of interest. Time will tell. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
On 10/01/2012 06:33 PM, Gene Czarcinski wrote: One of the problems I see is that, while there are a couple of viable dchp servers out there, where the ISC server is suppose to be the industrial strength one, dhclient seems to be the only client for the linux/*bsd/Unix systems. I wonder if there is interest in reviving the defunct dhcpv6c effort? If you mean https://fedorahosted.org/dhcpv6/ then no. It was also one-guy effort and David Cantrell stopped the development immediately after ISC dhcp-4.1.0 was released. Yes, there is dribbler but that seems like a one-guy effort and I do not see much support for it ... yes, dnsmasq is another one-guy effort but it also is popluar and has other people fixing things and submitting patches. I have no experience with Dibbler, but I believe it's a good implementation because Tomasz Mrugalski is very active on dhcwg at ietf.org ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
On 09/27/2012 10:22 PM, Gene Czarcinski wrote: also request fqdn.fqdn; also request fqdn.hostname; also request fqdn.domainname; These are DHCPv4 options which DHCPv6 client doesn't know. also request dhcp6.hostname; also request dhcp6.domainname; I can't find such options in dhcp-options(5). also request dhcp6.domain-search; This is requested by default as well as dhcp6.name-servers. See request statement in dhclient.conf(5) also request dhcp6.client-id; dhcp6.client-id is provided by client so I see no reason to request it from server. also request dhcp6.server-id; I'd say that dhcpv6 server sends this by default, by it's only a guess. -- Jiri ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
On Fri, 2012-09-28 at 06:54 -0400, Gene Czarcinski wrote:
> On 09/27/2012 04:22 PM, Gene Czarcinski wrote:
> > OK, anyone have any experience sending commands, requests etc. via
> > dhclient?
> >
> > I have my patch fixed up so that it works from a conf file rather than
> > "-F" on the commandline since that is a "Red Hat ism".
> >
> > I am asking for some stuff and I get little back from dhcpd6 [that is
> > using radvd, named, dhcpd, and dhcpd6 to provide services]. On the
> > other hand, I get pretty much what I asked for from dnsmasq [radvd and
> > dnsmasq provide the services]. In fact, I based what I put in by what
> > dnsmasq was delivering without bein asked.
> >
> > Anyway, here is nm-dhclient6-eth0.conf
> >
> > # Created by NetworkManager
> >
> > send fqdn.fqdn "f17user28";
> > send fqdn.encoded on;
> > send fqdn.no-client-update on;
> > send fqdn.server-update on;
> > also request fqdn.fqdn;
> > also request fqdn.hostname;
> > also request fqdn.domainname;
> > also require dhcp6.name-servers;
> > also request dhcp6.fqdn;
> > also request dhcp6.hostname;
> > also request dhcp6.domainname;
> > also request dhcp6.domain-search;
> > also request dhcp6.client-id;
> > also request dhcp6.server-id;
> > ---
> >
> > And here is dhclient6--eth0.lease
> > -
> > lease6 {
> > interface "eth0";
> > ia-na 00:e6:01:85 {
> > starts 1348776391;
> > renew 0;
> > rebind 0;
> > iaaddr fd00:dead:beef:28::2fe {
> > starts 1348776391;
> > preferred-life 7200;
> > max-life 21600;
> > }
> > }
> > option dhcp6.client-id 0:1:0:1:17:f7:6e:46:52:54:0:e6:1:85;
> > option dhcp6.server-id 0:1:0:1:17:f7:6d:f9:52:54:0:15:48:2;
> > option dhcp6.name-servers fd00:dead:beef:28::91;
> > option dhcp6.domain-search "vtest.";
> > }
> > -
> >
> > Any insight would be appreciated. The patch is "almost there" but I
> > would really like to understand this.
> >
> > BTW, on the client side stuff is working in that I get dhcpd6
> > addresses and dns update with a RA route. This is both for
> > radvd/dnsmasq and radvd/named/dhcpd/dhcpd6 configurations. Yup, that
> > auto stuff really works nicely.
> A little more information. I re-ran my test but this time I had
> wireshark running on the server.
>
> The requests for fqdn.fqdn, fqdn.hostname, fqdn.domainname, dhcp6.fqdn,
> dhcp6.hostname, and dhcp6.domainname were not sent from the dhclient to
> the server. Whether dhcpd6 could/would supply the info is not known
> since dhclient never asked. At this point I am going to just drop those
> requests. The dynamic dns update is done and the address is supplied. I
> do not feel up to digging into dhclient code to see what is screwed up
> there.
>
> At least stuff works.
Ok, so at least the client is sending the DDNS stuff to the server. At
this point we'll take what we can get :)
Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
> From: "Bjørn Mork" > Pavel Simerda writes: > > > - Original Message - > >> From: "Bjørn Mork" > >> To: "Gene Czarcinski" > >> Cc: networkmanager-list@gnome.org > >> Sent: Friday, September 28, 2012 10:46:31 AM > >> Subject: Re: G ... dhcpd6 > >> > >> Gene Czarcinski 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. This is not a matter of agreement, see below. > It doesn't support the > currently most popular ISP configuration: DHCPv6-PD over PPP. NetworkManager currently only supports IPv6 hosts, not routers. Until we start implementing any sort of IPv6 routing, DHCP-PD is out of question. > >> 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. I hope you are talking about ISC upstream, specifically. > >> 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... Citation needed. > That is an odd DHCP legacy restriction, and not the way the DHCPv6 > protocol was designed. Same as above. > >> 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. NetworkManager currently doesn't support any IPv6 routing usecases. Your concerns are actually ahead of what we are trying to solve, which is good. Please, if you are really interested about this, write down your solutions and put (or link) them here: https://bugzilla.gnome.org/show_bug.cgi?id=593815 Than way they don't get lost before someone actually gets to implementing this. I'd be happy if you could find time to do that. > But I can understand if you define those features as out of scope for a host > implementation. Exactly. > That's OK as long as everybody is aware of these limitations. I'm writing from the current NetworkManager perspective. > >> 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?
Re: Grrrr ... dhcpd6
Pavel Simerda writes: > - Original Message - >> From: "Bjørn Mork" >> To: "Gene Czarcinski" >> Cc: networkmanager-list@gnome.org >> Sent: Friday, September 28, 2012 10:46:31 AM >> Subject: Re: G ... dhcpd6 >> >> Gene Czarcinski 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
Re: Grrrr ... dhcpd6
> From: "Gene Czarcinski" > On 09/28/2012 08:15 AM, Pavel Simerda wrote: > > 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. > Give dnsmasq a look. AFAIK dnsmasq is out of question here as it only provides the server side. > It seems that not only NetworkManager using it as a caching name server And we might be abandoning it, switching to unbound, but that's a completely different topic. For NetworkManager, the choice of caching/validating nameserver is orthogonal to the choice of DHCP client anyway. > but libvirt is using if not dependent on it. Granted, it is nothing I would > like trying to scale to "industrial size" networks, but it sure configures > and works well. We're using it as a local caching nameserver because it's simple to set up. We're using it as a caching nameserver and DNS server for IPv4 method=shared for the same reason. > in another message, there is sudden activity on the dnsmasq discussion > mailinglist to get its RA support to work better ... maybe even suplant > the need for radvd We're not using radvd with NetworkManager at all as we currently don't support IPv6 connection sharing and we actually don't know yet how to do that. Ask Dan Winship about this. > to configure routes when dhcp supplies the address and dynamic dns. This choice would be made when (if) we add support for IPv6 connection sharing. But unfortunately for us and for this feature to be added, this won't work as easily as it does for IPv4. > You might want to consider adding it to the suite of tests you use. For my > testing, > I am using both named/dhcpd/dhcpd6 and dnsmasq (both > requiring radvd). Actually, the reationale for creating my tests was to *have a working IPv6 network with all sorts of dynamic configurations of host addresses*. To fullfill this I don't need anything of this sort unless I want to test your dynamic DNS stuff. And as you are testing it already, I'll kindly ask you to publish your tests. If you would like to participate on a broader range of interoperability tests, I'll be only happy. With Dan Williams, we are still looking for a reasonable way to do integration testing using virtualization. And I'm also working on a way to do complex non-integration tests for NetworkManager that would not require virtualization nor root account. These could complement each other. Cheers, Pavel > > Gene > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
On 09/28/2012 08:15 AM, Pavel Simerda wrote: 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. Give dnsmasq a look. It seems that not only NetworkManager using it as a caching name server but libvirt is using if not dependent on it. Granted, it is nothing I would like trying to scale to "industrial size" networks, but it sure configures and works well. As Dan pointed out in another message, there is sudden activity on the dnsmasq discussion mailinglist to get its RA support to work better ... maybe even suplant the need for radvd to configure routes when dhcp supplies the address and dynamic dns. You might want to consider adding it to the suite of tests you use. For my testing, I am using both named/dhcpd/dhcpd6 and dnsmasq (both requiring radvd). Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
- Original Message - > From: "Bjørn Mork" > To: "Gene Czarcinski" > Cc: networkmanager-list@gnome.org > Sent: Friday, September 28, 2012 10:46:31 AM > Subject: Re: G ... dhcpd6 > > Gene Czarcinski 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. > 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. > 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. > 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. > 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. > 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. Cheers, Pavel > > > Bjørn > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
On 09/27/2012 04:22 PM, Gene Czarcinski wrote:
OK, anyone have any experience sending commands, requests etc. via
dhclient?
I have my patch fixed up so that it works from a conf file rather than
"-F" on the commandline since that is a "Red Hat ism".
I am asking for some stuff and I get little back from dhcpd6 [that is
using radvd, named, dhcpd, and dhcpd6 to provide services]. On the
other hand, I get pretty much what I asked for from dnsmasq [radvd and
dnsmasq provide the services]. In fact, I based what I put in by what
dnsmasq was delivering without bein asked.
Anyway, here is nm-dhclient6-eth0.conf
# Created by NetworkManager
send fqdn.fqdn "f17user28";
send fqdn.encoded on;
send fqdn.no-client-update on;
send fqdn.server-update on;
also request fqdn.fqdn;
also request fqdn.hostname;
also request fqdn.domainname;
also require dhcp6.name-servers;
also request dhcp6.fqdn;
also request dhcp6.hostname;
also request dhcp6.domainname;
also request dhcp6.domain-search;
also request dhcp6.client-id;
also request dhcp6.server-id;
---
And here is dhclient6--eth0.lease
-
lease6 {
interface "eth0";
ia-na 00:e6:01:85 {
starts 1348776391;
renew 0;
rebind 0;
iaaddr fd00:dead:beef:28::2fe {
starts 1348776391;
preferred-life 7200;
max-life 21600;
}
}
option dhcp6.client-id 0:1:0:1:17:f7:6e:46:52:54:0:e6:1:85;
option dhcp6.server-id 0:1:0:1:17:f7:6d:f9:52:54:0:15:48:2;
option dhcp6.name-servers fd00:dead:beef:28::91;
option dhcp6.domain-search "vtest.";
}
-
Any insight would be appreciated. The patch is "almost there" but I
would really like to understand this.
BTW, on the client side stuff is working in that I get dhcpd6
addresses and dns update with a RA route. This is both for
radvd/dnsmasq and radvd/named/dhcpd/dhcpd6 configurations. Yup, that
auto stuff really works nicely.
A little more information. I re-ran my test but this time I had
wireshark running on the server.
The requests for fqdn.fqdn, fqdn.hostname, fqdn.domainname, dhcp6.fqdn,
dhcp6.hostname, and dhcp6.domainname were not sent from the dhclient to
the server. Whether dhcpd6 could/would supply the info is not known
since dhclient never asked. At this point I am going to just drop those
requests. The dynamic dns update is done and the address is supplied. I
do not feel up to digging into dhclient code to see what is screwed up
there.
At least stuff works.
Gene
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
* Bjørn Mork > 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. But I wonder if they are prepared to take over as > upstream? If not, then I suggest that NM development look for other > options, or the DHCPv6 support will be unmaintainable on any non Redhat > distribution. FWIW I've had great success using Dibbler (http://klub.com.pl/dhcpv6/) whever I've been playing around with and debugging DHCPv6. It seems to be actively maintained too. No idea about code quality and maintainability, but as a user I prefer it to ISC's client. -- Tore Anderson ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
Gene Czarcinski 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. 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 Being able to configure an IA_NA address on an ethernet interface is just not enough. Look further and plan for the other features you *must* support. 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. 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. But I wonder if they are prepared to take over as upstream? If not, then I suggest that NM development look for other options, or the DHCPv6 support will be unmaintainable on any non Redhat distribution. Bjørn ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Grrrr ... dhcpd6
OK, anyone have any experience sending commands, requests etc. via dhclient?
I have my patch fixed up so that it works from a conf file rather than
"-F" on the commandline since that is a "Red Hat ism".
I am asking for some stuff and I get little back from dhcpd6 [that is
using radvd, named, dhcpd, and dhcpd6 to provide services]. On the
other hand, I get pretty much what I asked for from dnsmasq [radvd and
dnsmasq provide the services]. In fact, I based what I put in by what
dnsmasq was delivering without bein asked.
Anyway, here is nm-dhclient6-eth0.conf
# Created by NetworkManager
send fqdn.fqdn "f17user28";
send fqdn.encoded on;
send fqdn.no-client-update on;
send fqdn.server-update on;
also request fqdn.fqdn;
also request fqdn.hostname;
also request fqdn.domainname;
also require dhcp6.name-servers;
also request dhcp6.fqdn;
also request dhcp6.hostname;
also request dhcp6.domainname;
also request dhcp6.domain-search;
also request dhcp6.client-id;
also request dhcp6.server-id;
---
And here is dhclient6--eth0.lease
-
lease6 {
interface "eth0";
ia-na 00:e6:01:85 {
starts 1348776391;
renew 0;
rebind 0;
iaaddr fd00:dead:beef:28::2fe {
starts 1348776391;
preferred-life 7200;
max-life 21600;
}
}
option dhcp6.client-id 0:1:0:1:17:f7:6e:46:52:54:0:e6:1:85;
option dhcp6.server-id 0:1:0:1:17:f7:6d:f9:52:54:0:15:48:2;
option dhcp6.name-servers fd00:dead:beef:28::91;
option dhcp6.domain-search "vtest.";
}
-
Any insight would be appreciated. The patch is "almost there" but I
would really like to understand this.
BTW, on the client side stuff is working in that I get dhcpd6 addresses
and dns update with a RA route. This is both for radvd/dnsmasq and
radvd/named/dhcpd/dhcpd6 configurations. Yup, that auto stuff really
works nicely.
Gene
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
