Date: Tue, 19 Jan 2021 19:54:19 +0100
To: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Proposed system change: Use dhcpcd as default DHCP client
From: =?UTF-8?Q?S=C3=B6ren?= Tempel <soeren@soeren-tempel.net>
References: <eb865f14-75ae-491b-179c-f6dc9f5df49@dereferenced.org>
 <1ZT7J29AS5AJH.2CQHETQ00K814@8pit.net>
 <66a3aa3-f55b-cdcd-d033-d6505985ccef@dereferenced.org>
In-Reply-To: <66a3aa3-f55b-cdcd-d033-d6505985ccef@dereferenced.org>
Message-Id: <2R13E13K99O5U.2AJR60YXHCP5M@8pit.net>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ariadne Conill <ariadne@dereferenced.org> wrote:
> Hello,

Hi,

> I agree that in most cases SLAAC is sufficient, but we have received a=20=

> handful of reports from Alpine upgraders in the ifupdown-ng tracker and=20=

> IRC that DHCPv6 is required for some kinds of deployments, notably at=20
> least one French ISP does not support SLAAC and instead uses DHCPv6 with =
a=20
> customer-specific DUID.  There is also the matter of DHCPv6-PD which is=20=

> used to delegate /64 prefixes to customers; this obviously has no SLAAC=20=

> equivalent and is commonly used by ISPs worldwide.

Ah, wasn't aware that this is an actual issue for people. I agree that
we should find some way to make it easier for people to use DHCPv6 if they
have to for some reason.

> As far as I know, udhcpc6 does not support DHCPv6-PD for prefix=20
> delegation, only dhcpcd and dhclient do.  udhcpc6 also does not support=20=

> specifying a DUID, but we could probably add that functionality easily=20=

> enough.

Yeah, I think these feature should be relatively easy to add and
upstream is probably interested in having them as well.

> Regarding simplicity: a problem is that having two DHCP processes for DHC=
P=20
> and DHCPv6 is problematic because they can (and do) conflict with each=20=

> other.  While it is possible to create a solution for that in ifupdown-ng=
=20
> that allows for both DHCP and DHCPv6 to co-exist without conflicts, it=20=

> seems like just having a single DHCP client which handles both in the sam=
e=20
> process is a simpler design.

Maybe we can workout a solution with busybox upstream for this issue? It
seems to me that there should be an easy way to use both udhcpc and
udhcpc6 if needed. Can't really comment on whether or not it makes sense
to implement this as separate ifupdown-ng executors as I am not
familiar with ifupdown-ng internals. The configuration syntax you
suggest looks plausible to me though.

> If consensus favors that direction, then the logical path forward would b=
e=20
> to implement support for DUIDs and DHCPv6-PD in udhcpc6.  But dhcpcd is=20=

> the less expensive path forward to solving this scenario properly (it=20
> already works there today, by default).

I think it's the more obvious path to solve this issue since we already
employ udhcpc by default and users are already familiar with it. dhcpcd
would probably also increase the base image size a bit. However, as you
point out, it's certainly more work to improve busybox udhcpc. Let's
wait and see what other people think about this :)

> I'm not very adamant about the solution being dhcpcd, but I want to solve=
=20
> this problem correctly, so that people stop inventing their own fragile=20=

> solutions for it.  Giving people a robust configuration tool was and=20
> remains the primary goal of ifupdown-ng.

I agree, we should definitely address this somehow. Maybe we could also
just make it easier to install and configure dhcpcd and advise people to
use it if they need DHCPv6 (instead of enabling it by default)? Though
that would of cause not work by default then.

Cheers,
S=C3=B6ren