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
On Mon, 2021-01-18 at 12:30 -0700, Ariadne Conill wrote:
> 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
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
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.
> 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?
> 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.
> 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 ;)
Personally not convinced (yet?) that we really need dhcpcd in alpine-base.
Greetings,
Sören
Hello,
On Tue, 19 Jan 2021, Sören 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
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.
>> 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
delegation, only dhcpcd and dhclient do. udhcpc6 also does not support
specifying a DUID, but we could probably add that functionality easily
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
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.
>> 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
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
Ariadne Conill <ariadne@dereferenced.org> wrote:
> Hello,
Hi,
> 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.
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 > delegation, only dhcpcd and dhclient do. udhcpc6 also does not support > specifying a DUID, but we could probably add that functionality easily > 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 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.
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 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 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 > 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.
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
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
On Tue, 19 Jan 2021 15:19:22 -0500
Nathan Angelacos <nangel@alpinelinux.org> wrote:
> 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.)
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