Subject: Proposed system change: Use dhcpcd as default DHCP client

From: Ariadne Conill <[email-masked]>
Date: Mon, 18 Jan 2021 12:30:40 -0700 (MST)

Hello,

I would like to propose we use dhcpcd as the DHCP client moving forward.

## Background

At present, Alpine uses udhcpc as the default DHCP client.

With the world transitioning toward IPv6, it makes sense to use a DHCP 
client which actively supports dual-stack configurations -- dhcpcd is the 
only client we package which does so cleanly.

## Benefits to Alpine

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.

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.

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.

Finally, dhcpcd has the best security maintenance record of the DHCP 
clients we presently support: BusyBox udhcpc, ISC dhclient and dhcpcd.

## Testing

Users can verify their setup continues to work by simply installing dhcpcd 
and testing.

## Contingency Plan

If dhcpcd has release-critical bugs, we can simply remove it from 
alpine-base, at which point BusyBox udhcpc will continue to be the default 
again.

## Timeline

I would like to add dhcpcd to alpine-base in February.

Ariadne

[0]: https://ipv4flagday.net

---

From: maxice8 <[email-masked]>
Date: Mon, 18 Jan 2021 18:55:34 -0300

> [0]: https://ipv4flagday.net

Hello

Sounds good.

Just need to update our dhcpcd as it is one MAJOR version (8.x.x-
>9.x.x) behind upstream, the biggest pain point is that it breaks
NetworkManager, or at least did when I tried to upgrade it.

Regards
Leo

---

From: Sören Tempel <[email-masked]>
Date: Tue, 19 Jan 2021 07:03:14 +0100

> Hello,

Hi,

Thanks for bringing this up, I think IPv6 support in Alpine is generally
a very important issue.

> 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.

> 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?

> auto-configuration scenarios.

Alpine already supports these scenarios as long as SLAAC is used.

> 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 ;)

Personally not convinced (yet?) that we really need dhcpcd in alpine-base.

Greetings,
Sören

---

From: Ariadne Conill <[email-masked]>
Date: Tue, 19 Jan 2021 07:19:31 -0700 (MST)

Hello,

> never had to configure a DHCPv6 client for IPv6 connectivity.

I agree that in most cases SLAAC is sufficient, but we have received a 
handful of reports from Alpine upgraders in the ifupdown-ng tracker and 
IRC that DHCPv6 is required for some kinds of deployments, notably at 
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 
used to delegate /64 prefixes to customers; this obviously has no SLAAC 
equivalent and is commonly used by ISPs worldwide.

> dhcpcd or ISC dhclient in this scenario?

As far as I know, udhcpc6 does not support DHCPv6-PD for prefix 
delegation, only dhcpcd and dhclient do.  udhcpc6 also does not support 
specifying a DUID, but we could probably add that functionality easily 
enough.

> Alpine already supports these scenarios as long as SLAAC is used.

Yes, but as mentioned above, we have received reports from users who have 
IPv6 service which does not provide SLAAC.  Our current situation is 
suboptimal for those users, who wind up inventing their own hacks with 
pre-up and post-down statements in /e/n/i.

> simplicity also used to be an Alpine design goal ;)

In general, udhcpc[6] has a good security record too, but it has a design 
that has historically been difficult to work with in scenarios where you 
need both DHCP and DHCPv6 (e.g. for DHCPv6-PD or DUID as a customer 
identifier).  In this case, I am mostly comparing to ISC dhclient, which 
as anybody should know at this point, has a generally abysmal security 
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 
other.  While it is possible to create a solution for that in ifupdown-ng 
that allows for both DHCP and DHCPv6 to co-exist without conflicts, it 
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 
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 
over the configuration.  But it does mean that we need to add the missing 
features to udhcpc6, and it also means we need to come up with a good 
answer to ensure that udhcpc and udhcpc6 do not fight with each other (at 
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 
the less expensive path forward to solving this scenario properly (it 
already works there today, by default).

I'm not very adamant about the solution being dhcpcd, but I want to solve 
this problem correctly, so that people stop inventing their own fragile 
solutions for it.  Giving people a robust configuration tool was and 
remains the primary goal of ifupdown-ng.

Ariadne

---

From: Sören Tempel <[email-masked]>
Date: Tue, 19 Jan 2021 19:54:19 +0100

Hi,

> 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.

> specifying a DUID, but we could probably add that functionality easily 

Yeah, I think these feature should be relatively easy to add and
upstream is probably interested in having them as well.

> 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.

> 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 :)

> 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ören

---

From: Nathan Angelacos <[email-masked]>
Date: Tue, 19 Jan 2021 15:19:22 -0500

On Tue, 2021-01-19 at 19:54 +0100, Sören Tempel wrote:
> 
> 
> 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.

Spectrum (old Charter) customer here from Southeast US. Spectrum (old
Time Warner) in Northeast US apparently had IPv6 working years ago, but
that was not the case across the ISP.

They finally deployed it here in the Southeast, and its DHCPv6.  dhcpcd
let me grab a /56 via DHCPv6-PD (completely undocumented) until a
couple of weeks ago, when they apparently decided they only hand out
/60's. <sarcasm> I guess there's a shortage of prefixes? </sarcasm>

My personal experience is yes, there are "Tier 1" ISPs in the USA who
still haven't figured out how they want to hand out prefixes, or /128's
for that matter.

> 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.

In my use case, I just install dhcpcd and move on.  It is bigger, but
it "just works".  

No objections to pushing the other features upstream, but if we want
something for the next release, I wonder if giving the user the option
is viable.  We already do that with the choice of ssh and ntp; do we
let the user choose?  (if you have IPv4, this is smaller; if you need
DHCPv6-PD, this is your choice, etc.)

Like you two, not adamant on the subject, just commenting on what's
needed to make it work here.

Cheers

---

From: Natanael Copa <[email-masked]>
Date: Tue, 19 Jan 2021 22:14:05 +0100

On Tue, 19 Jan 2021 15:19:22 -0500

> DHCPv6-PD, this is your choice, etc.)

I think it would be nice if we could support both. With the small
udhcpcd as the default. busybox ifupdown will use dhcpcd if its there
or fall back to if its not. Users who needs dhcpv6 could get get dhcpcd.

That way we can give a bare minimal for those who only needs a simple
networking setup. dhcpcd could be pulled in with network-extras meta
package.

My ISP does not seem to provide ipv6 yet, and I don't have much
experience with it. Might need some help with the setup scripts to
handle ipv6.

-nc