DHCPv6 client in base

[Ben Woods]

On Sat, 12 Oct 2019 at 3:42 am, Hiroki Sato <hrs at allbsd.org> wrote:

> I do not have a strong objection on dhcpcd (I am using it on some of
>  my FreeBSD boxes actually) but let me explain the reason why I chose
>  wide-dhcp as the candidate.  That is because it is a small,
>  functional DHCPv6-only implementation.  I am planning to rewrite it
>  to add the missing bits and adjust it for a tighter integration with
>  kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum.  I
>  feel dhcpcd (or others) is too big for that purpose.



One of the main attractions of dhcpcd is that it has been actively
maintained for many years, and is already integrated into NetBSD and
DragonFlyBSD, ensuring it will continue to be maintained. Whilst they don’t
get offered often, Roy appears quite open to accepting code contributions
upstream.

On NetBSD and DragonFlyBSD, Roy has also submitted changes to the kernel to
introduce tighter integration with dhcpcd.

Since receiving feedback from yourself and brooks, Roy has already begun
the work to implement privilege separation in dhcpcd.

Whilst Roy doesn’t currently plan on working on capsicum support, I believe
adding capsicum support will be easier once privilege separation is
completed. I believe Roy would be very open to receiving these
contributions upstream (with appropriate ifdefs for operating systems which
don’t support capsicum).

IMHO, the directions of further developments of IPv6 functionality on
>  FreeBSD, NetBSD (dhcpcd), OpenBSD (slaacd + others), and DragonFly
>  BSD (dhcpcd) have already been diverged.  For RFC 7217 I already have
>  an in-kernel implementation (not committed yet), and I am also
>  working on SeND (RFC 3971, not directly related to DHCPv6 though).
>  My goal is to integrate these small implementations into the base
>  system and make them possible to work together.  So for DHCPv6, I
>  think an implementation of only DHCPv6 is the best.
>
>  If people want a more feature-rich implementation or the same one on
>  other systems, they can still use dhcpcd or ISC's dhclient even after
>  the import.
>
>  Of course this assumes that wide-dhcp works to some degree.  If it
>  does not, importing it to the base system does not make sense.  I
>  have used it in various scenarios for a long time such as RA + O flag
>  on native IPv6 over Ethernet, DHCPv6-PD over PPPoE/L2TP, and others
>  which are complex enough, and understand what works and what is
>  missing (poor DUID format support, for example).  The popular way to
>  use DHCPv6 is IA_PD, and wide-dhcp works well with it.
>
>  So I have a question.  What is missing feature in wide-dhcp which you
>  are concerned about?  I know some, but it has most of the basic
>  functionality of DHCPv6 and I think it is enough as a minimal
>  implementation for the base system.  My primary reason is that it is
>  just for DHCPv6 as mentioned earlier and I believe it is maintainable
>  in the base system.  I would like to know other people's opinion if
>  there is something critical.
>
> -- Hiroki
>
Whilst I don’t have anything against wide-dhcp, I personally prefer
integrated IPv4/IPv6 tools. ping vs ping6 for example would be better
integrated in my opinion.

The “feature” that I believe is missing from wide-dhcp is active
maintenance. I believe that dhcpcd has the right license, adoption
elsewhere, and active maintenance to make it successful for FreeBSD in the
long run.

Importing dhcpcd to the contrib/ tree means the maintenance to update it
regularly is greatly simplified (simply import the newer upstream version
and test). Anyone can submit any improvements / fixes upstream to Roy.

I do agree that we should minimise excess code in FreeBSD also, but I
believe that once dhcpcd has been proven to work, we could look at removing
dhclient and rtsold. Agree with your comment that before this occurs, we
should check what features / security improvements / tighter integration
have been added along the way, and ensure they make their way into dhcpcd.

If dhcpcd was imported, I believe this would come with a phased approach:
- import dhcpcd, but leave dhclient and rtsold as default
- add kernel support for tighter dhcpcd integration
- switch defaults to dhcpcd, but leave dhclient and rtsold as available
- remove dhclient and rtsold

Regards,
Ben
-- 

--
From: Benjamin Woods
woodsb02 at gmail.com