Date: Tue, 19 Jan 2021 07:19:31 -0700 (MST)
From: Ariadne Conill <ariadne@dereferenced.org>
To: =?ISO-8859-15?Q?S=F6ren_Tempel?= <soeren@soeren-tempel.net>
cc: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Proposed system change: Use dhcpcd as default DHCP client
In-Reply-To: <1ZT7J29AS5AJH.2CQHETQ00K814@8pit.net>
Message-ID: <66a3aa3-f55b-cdcd-d033-d6505985ccef@dereferenced.org>
References: <eb865f14-75ae-491b-179c-f6dc9f5df49@dereferenced.org> <1ZT7J29AS5AJH.2CQHETQ00K814@8pit.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="0-1840738407-1611065932=:23530"
Content-ID: <67fa2bcd-9dd6-d092-319d-5f1d0365229@dereferenced.org>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1840738407-1611065932=:23530
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-ID: <bb1e1913-6c93-45b1-f8ad-89bb9da5220@dereferenced.org>

Hello,

On Tue, 19 Jan 2021, S=F6ren Tempel wrote:

> Ariadne Conill <ariadne@dereferenced.org> wrote:
>> Hello,
>
> Hi,
>
> Thanks for bringing this up, I think IPv6 support in Alpine is generally
> a very important issue.
>
>> By focusing on the dhcpcd client as our preferred DHCP client, we can
>> support dual-stack IPv4+IPv6 autoconfiguration out of the box.  This is
>> helpful for CPE and home router deployments, where an ISP provides DHCP
>> for IPv4 and DHCPv6-PD for prefix delegation, which is the most common
>> form of dual-stack deployment at the consumer ISP level.
>
> From my subjective experience I don't agree with this statement, at
> least where I am living ISP-provided CPEs employ SLAAC for IPv6
> autoconfiguration. I've been using uhcp for the last > 5 years and
> never had to configure a DHCPv6 client for IPv6 connectivity.

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 =

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.

>> At present, users must install dhcpcd or ISC dhclient in order to support
>> this configuration -- while this is not a huge burden for the user, the
>> future is trending towards network deployments which do not have IPv4
>> service at all[0], which makes integrating a high quality DHCPv6 client
>> into our base system a strategic priority.
>
> If you are forced to use DHCPv6 instead of SLAAC: Doesn't our busybox
> package already provide udhcpc6, why would it be necessary to install
> dhcpcd or ISC dhclient in this scenario?

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.

>> By using dhcpcd by default, Alpine will support IPv4-only networks, IPv4
>> and IPv6 dual-stack networks and IPv6-only networks in all possible
>> auto-configuration scenarios.
>
> Alpine already supports these scenarios as long as SLAAC is used.

Yes, but as mentioned above, we have received reports from users who have=20
IPv6 service which does not provide SLAAC.  Our current situation is=20
suboptimal for those users, who wind up inventing their own hacks with=20
pre-up and post-down statements in /e/n/i.

>> Finally, dhcpcd has the best security maintenance record of the DHCP
>> clients we presently support: BusyBox udhcpc, ISC dhclient and dhcpcd.
>
> Source on this? What do you mean by "security maintenance record"? I
> would expect the dhcpcd codebase to more complex than the udhcpc
> implementation, i.e. would expect it to have more security critical bugs
> (it also has more features after all). After all, apart from security
> simplicity also used to be an Alpine design goal ;)

In general, udhcpc[6] has a good security record too, but it has a design=20
that has historically been difficult to work with in scenarios where you=20
need both DHCP and DHCPv6 (e.g. for DHCPv6-PD or DUID as a customer=20
identifier).  In this case, I am mostly comparing to ISC dhclient, which=20
as anybody should know at this point, has a generally abysmal security=20
record.

Regarding simplicity: a problem is that having two DHCP processes for DHCP =

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 same =

process is a simpler design.

With that said, splitting DHCP and DHCPv6 into separate executors is=20
potentially a more flexible design and that does warrant examination, too. =

In /e/n/i that would look something like:

iface ipv4-only
     use dhcp

iface dual-stack
     use dhcp
     use dhcpv6
     dhcpv6-duid aa:bb:cc:dd:ee:ff:11:22:33:44:55:66
     dhcpv6-pd yes

iface ipv6-only
     use dhcpv6
     dhcpv6-pd no

Admittedly, this looks very nice and gives the end user even more control=20
over the configuration.  But it does mean that we need to add the missing=20
features to udhcpc6, and it also means we need to come up with a good=20
answer to ensure that udhcpc and udhcpc6 do not fight with each other (at=20
least this a known issue with dhclient, I need to lab it with udhcp/udhcp6 =

still).

If consensus favors that direction, then the logical path forward would be =

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'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.

Ariadne
--0-1840738407-1611065932=:23530--