-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 If there's a good reason to build it, and they do have source code in a convenient form (git would be perfect) we absolutely can build it. It would be nice if someone volunteered to maintain it of course. ;)
On 01/28/2016 06:03 AM, Nicholas Williams wrote: > 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:nicholas%2bv...@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 <mailto:nicholas%2bv...@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 <mailto:Vyos-developers@lists.tuxis.nl> > >>>> > https://lists.tuxis.nl/listinfo/vyos-developers > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Vyos-developers mailing list > >>>> > >>>> Vyos-developers@lists.tuxis.nl <mailto: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 <tel:313.278.4522%20x%20102> > >>> > >>> _______________________________________________ > >>> Vyos-developers mailing list > >>> Vyos-developers@lists.tuxis.nl <mailto: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 <tel:313.278.4522%20x%20102> > >> > > > > -- > > Seamus Caveney > > Senior Network Administrator > > Active Solutions Group > > 4 Park Lane Blvd Ste 170 – Dearborn, MI 48126 > > phone: 313.278.4522 x 102 <tel:313.278.4522%20x%20102> > > > > _______________________________________________ > > Vyos-developers mailing list > > Vyos-developers@lists.tuxis.nl <mailto: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 - -- #!/usr/bin/env perl @a=split(//, "daniil @ baturin . org" );# Daniil Baturin @b=split(//,q/Px%!+o0Q6lh*7dp$.@8#%|y{/);while($i<24){$_.= chr((ord(@b[$i])-ord(@a[$i])+62)%94+32);$i++};print"$_\n"# -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWqV2gAAoJEEcm35UR4K8f4sIP/iOWPBLpxaMkFjjupwDaWpQd xuSOFqFxsZrTadi2PNBkyv/1RlhIg6aLEx2TFGyAWlYyBt8dK13jCtC4sh13BhRy FkSqGHGWiu1NeULF9XfevNuBgZ4Or81HO5u2DGMVgixv8Bd4D+18993QDGufTGki u/NizGeww4jZDKp3NzbLKhs3kz7ULxgtXFJmkVN/f9QG5fP2qSSQvnnGcpOooSty BNSio3whpOgjKzAF40/8CroZr/QwCfCe7Bk3Vc5SjuokFSLEjGEpAj7UT0F1o8l7 GedHJyT7EY8ZrjuayveSv6QqN3Wm+8uMtN3wGWcnP2u6r+Ulx8XE0F7PyjHO3CJR OarJGsvAzYyvO8ZYYfdpoP85XLbUFZlwPwa97Y+rJcnSOJgc0L/k6qjDskPStxS8 9UGym0XEjiUVOwZIg7jc3NU6ruDiwTX3yHaqqRNZRDtlU/kE06rNqmH/7IihH+6B nZuGYaT6XqVYXDoSWHgsEaiPPSLYC2t076svaCty+FilmHKFJ3oOG+FIV9Z2gl4w KyS5Ol3IESIWHGz/g6v7Z05Po6qOVO0Ex2WbPInQNLVFZWLfPgzsBq+36x7hfwVV f4r/sjZigyo8GKmgNDNiTchaWbwuLApSc3RzR/BqWT0WGcUUPpv2ABZffZIbc2pd 4Nr3Blg4Gsn+T4D6+sya =XsNH -----END PGP SIGNATURE----- _______________________________________________ Vyos-developers mailing list Vyos-developers@lists.tuxis.nl https://lists.tuxis.nl/listinfo/vyos-developers