We do have a new obstacle to overcome: https://packages.debian.org/search?keywords=dhcpcd
Neither Squeeze (the old-old, unsupported version of Debian VyOS currently runs on) nor Wheezy (the next-old, still-supported version) have a version of dhcpcd that supports DHCPv6 Prefix Delegation prefix length hints. Jessie (the next-next, current version) has 6.0.5, which supports PD, but that version is still 3 years old, and //many// DHCPv6 bugs have been fixed since then. The current version, 6.9.x, isn't present until Debian-next. So we're going to have to package a newer version of DHCPv6 for use in Wheezy or Jessie (whichever we're planning on upgrading to). Nick On Wed, Jan 27, 2016 at 4:33 PM, Daniel Corbe <dco...@hammerfiber.com> wrote: > 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
