Replacing just one component (dhclient) of ISC’s stack should be trivial. Especially considering dhcpcd does IPv4 DHCP just as well as it does IPv6 DHCP.
ISC can DHCP-server-it-up. > On Jan 27, 2016, at 4:57 PM, Seamus Caveney <sea...@activesolutionsmi.com> > wrote: > > Yep, I'm on the same page re: not replacing the server. > > I didn't look into whether the patch made it in. If what you're saying is > correct then DHCPCD is probably a better idea if we can retrofit it easily. > I'll look at whether we are using a separate process for dhcpd or not. > > On 1/27/2016 4:54 PM, Nicholas Williams wrote: >> To be clear, we're not talking about replacing the DHCP server. That would >> still be ISC. We're talking about replacing the DHCP client. >> >> I looked at the link you sent, and I read through all of the mailing list >> threads from November, December, and January surrounding the thread you sent >> me. Several different patches for PD prefix lengths have been proposed. As >> of today, at this time, none of them have been committed [1]. >> >> Given that none of them have been committed, I find it unlikely there will >> be a stable ISC DHCP release with PD prefix length within the next 6-9 >> months. After that, it would probably take another 3-6 months before we >> could integrate the new version into VyOS and get PD prefix length >> configuration written, and then probably another 3 months before that would >> land in a release. I'd prefer not to see this bare-RFC-minimum feature >> dragged out to 2017. I still support dropping ISC's DHCP client in support >> of DHCPCD. >> >> Also, FWIW, I've determined that the ISC server and client run as a separate >> service, so that should support our efforts. We can continue to run ISC as a >> DHCP server, and use DHCPCD as a client. >> >> [1] https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=shortlog >> >> On Wed, Jan 27, 2016 at 3:26 PM, Seamus Caveney >> <sea...@activesolutionsmi.com> wrote: >> It seems ISC added prefix len support just last December[1], if this patch >> is in a stable release perhaps we can just work towards updating our version >> of ISC DHCPD? Probably an easier solution than switching to an entirely >> different DHCP server. >> >> [1] https://marc.info/?l=dhcp-workers&m=144905666712005&w=2 >> >> >> On 1/27/2016 4:21 PM, Nicholas Williams wrote: >>> Excellent! >>> >>> Given that, and what appears to be that DHCPCD is much better supported and >>> maintained than WIDE, I say we go with DHCPCD. In order to know how best to >>> proceed, we still need to know: >>> >>> - Are we using ISC for just client, or also server? >>> - If we're using ISC for the DHCP server, does it run in a separate process >>> as the ISC client? >>> - If it runs in the same process, is it possible to turn off the ISC client? >>> >>> Nick >>> >>> >>> On Wed, Jan 27, 2016 at 3:17 PM, Seamus Caveney >>> <sea...@activesolutionsmi.com> wrote: >>> Yeah, their docs are rather poor. However I did find confirmation that it >>> supports customizing the prefix size[1]. >>> >>> The ia_pd instruction has the following options: >>> >>> ia_pd [iaid] [prefix] [prefix_len] >>> >>> So you can specify something like: >>> >>> ia_pd 1 :: 60 >>> >>> for a /60 prefix. >>> >>> [1] >>> https://dollarblogname.wordpress.com/2014/10/13/dynamic-prefix-delegation-can-be-easy/ >>> >>> >>> On 1/27/2016 4:09 PM, Nicholas Williams wrote: >>>> DHCPCD certainly looks like a great alternative to Wide. I'm very >>>> interested in it. However, my two concerns: >>>> >>>> - After about 15 minutes of looking around on their site, and Googling, I >>>> can't find documentation of how to use it. >>>> - After that same time, I also can't find any information confirming that >>>> DHCPCD's Prefix Delegation support includes the ability to request >>>> specific prefix sizes. ISC technical has Prefix Delegation—the problem is >>>> that you can't customize what size prefixes it requests, so you always get >>>> a /64. >>>> >>>> If you can point me to documentation about these two issues that you've >>>> been able to find, that would be great. >>>> >>>> N >>>> >>>> >>>> On Wed, Jan 27, 2016 at 2:34 PM, Daniel Corbe <dco...@hammerfiber.com> >>>> wrote: >>>> Why WIDE though? It’s crusty and old and full of bugs. >>>> >>>> There’s a more modern DHCP client implementation for Linux that’s neither >>>> WIDE nor ISC. >>>> >>>> http://roy.marples.name/projects/dhcpcd/index >>>> >>>> > On Jan 27, 2016, at 1:37 PM, Nicholas Williams >>>> > <nicholas+v...@nicholaswilliams.net> wrote: >>>> > >>>> > I spent some time this morning re-familiarizing myself with this topic >>>> > (I've set it down for the last year because I've been otherwise >>>> > occupied). I scoured the webz for any sign that ISC plans on fixing the >>>> > two core discrepancies in their DHCPv6-PD support: >>>> > >>>> > 1. Being able to change the values sent in the DHCPv6-PD request to >>>> > specify the requested prefix length desired. >>>> > 2. Being able to divy-up the ISP-delegated prefix and assign it to >>>> > internal interfaces. >>>> > >>>> > If ISC would just support #1 (a must for any legitimate DHCPv6 client), >>>> > we could hack around #2 with scripts. Unfortunately, one ear later, >>>> > there there is no sign that ISC has any intention of fixing this issue, >>>> > and I don't feel confident that patches would be welcome. I think they >>>> > don't want it fixed because they don't think it's a good feature. >>>> > >>>> > Given all this, I believe the best way forward is to integrate >>>> > Wide-DHCPv6 client into VyOS: >>>> > https://sourceforge.net/projects/wide-dhcpv6/ >>>> > >>>> > By all indications, Wide should largely be a drop-in replacement for ISC >>>> > for DHCPv6 requests. So, given that, here is my proposed roadmap: >>>> > >>>> > Step 1: Replace ISC with Wide for DHCPv6 client requests, but make no >>>> > other changes. Put out a beta version that many people can test. Ensure >>>> > everything still works the way it is working now. This help isolate any >>>> > problems caused by this migration from any problems that could be caused >>>> > by changing prefix delegation in VyOS. >>>> > >>>> > Step 2: Add necessary configuration options and scripting for requesting >>>> > prefix lengths and delegating them to internal interfaces. Put out a >>>> > beta version that many people can test. Ensure everything still works >>>> > the way it is working now. >>>> > >>>> > Step 3. Release >>>> > >>>> > What I don't fully understand is to what extent we're using ISC. Are we >>>> > using it as both a client and a server? Are we using a single process >>>> > for client and server, or separate processes? Are we using a single >>>> > process for DHCPv4 and DHCPv6, or separate processes? The answers to >>>> > those questions will help to determine how much work Step 1 involves. >>>> > Wide-DHCPv6 is only a client, and only for v6. So we'll have to keep >>>> > using ISC for v4 and serving (if we're using it for serving). >>>> > >>>> > Nick >>>> > >>>> > >>>> > On Wed, Jan 27, 2016 at 10:46 AM, Nicholas Williams >>>> > <nicholas+v...@nicholaswilliams.net> wrote: >>>> > > I see Bug ID 112 about adding a proper DHCPv6 PD support. I’d also >>>> > > like to see a proper CLAT implementation for VyOS for users who use >>>> > > service providers that are kind enough to provide a PLAT service to >>>> > > their customers. >>>> > > >>>> > > Is there any concerted effort going on right now to actually get this >>>> > > work done? IE is there someone I should talk to about contributing >>>> > > to the effort? >>>> > >>>> > Daniel, >>>> > >>>> > I'm not familiar with CLAT/PLAT, but I am mostly familiar with Prefix >>>> > Delegation and IA_PD. Because I'm a Comcast residential customer, I am >>>> > very motivated to get PD working with my VyOS installation. You'll see >>>> > I have been involved in discussions in Big ID 112 already. I am not >>>> > super familiar with the VyOS source code, but I am willing to help in >>>> > any way I can, including testing experimental images of VyOS with a >>>> > new DHCP client and debugging issues. I may even, once I become more >>>> > familiar with the changes happening, be able to suggest changes that >>>> > need to happen in the code to get this working. >>>> > >>>> > Nick >>>> > >>>> > _______________________________________________ >>>> > Vyos-developers mailing list >>>> > Vyos-developers@lists.tuxis.nl >>>> > https://lists.tuxis.nl/listinfo/vyos-developers >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Vyos-developers mailing list >>>> >>>> Vyos-developers@lists.tuxis.nl >>>> https://lists.tuxis.nl/listinfo/vyos-developers >>> >>> >>> -- >>> Seamus Caveney >>> Senior Network Administrator >>> Active Solutions Group >>> 4 Park Lane Blvd Ste 170 – Dearborn, MI 48126 >>> phone: >>> 313.278.4522 x 102 >>> >>> _______________________________________________ >>> Vyos-developers mailing list >>> Vyos-developers@lists.tuxis.nl >>> https://lists.tuxis.nl/listinfo/vyos-developers >>> >>> >> >> -- >> Seamus Caveney >> Senior Network Administrator >> Active Solutions Group >> 4 Park Lane Blvd Ste 170 – Dearborn, MI 48126 >> phone: >> 313.278.4522 x 102 >> > > -- > Seamus Caveney > Senior Network Administrator > Active Solutions Group > 4 Park Lane Blvd Ste 170 – Dearborn, MI 48126 > phone: 313.278.4522 x 102 > > _______________________________________________ > Vyos-developers mailing list > Vyos-developers@lists.tuxis.nl > https://lists.tuxis.nl/listinfo/vyos-developers _______________________________________________ Vyos-developers mailing list Vyos-developers@lists.tuxis.nl https://lists.tuxis.nl/listinfo/vyos-developers
