DHCPv6 client in base

[Bjoern A. Zeeb]

On 14 Oct 2019, at 23:04, Ben Woods wrote:

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

I have a totally different opinion on this.  I prefer to have a tool 
that does one job. K.I.S.S.

In addition I consider IPv4 dead.  Let it die.  Stop thinking IPv4.  
Don’t screw the users over on the way out of the protocol by making 
changes to how things worked for a decade or two or three in the last 
minute.  Never change a running system.

If you want to touch IPv4 along, I am out on the IPv6 change.

Further I really, very soon, want to get rid of more IPv4 code for a lot 
of systems I am building as less code less attack surface.  We started 
compiling INET out in 2011 in addition to INET6.  I have a way more 
eager hobby project at the moment which does remove IPv4 entirely from 
the tree.  I do that by splattering more #ifdef code around all IPv4 
code I can find and then remove it. (two step needed to be able to 
merge-track FreeBSD still).  I can tell you even just doing that for 
libc is a pain.  If it takes us another 6-8 years until the rest of the 
world gets there, I’ll be happy (very much like it took the world to 
get to the IPv6-only discussions we have everywhere actively these 
days).



> The “feature” that I believe is missing from wide-dhcp is active
> maintenance.

I am not sure but I’d assume that’s a lot also to the fact of its 
current state as to where it is living.  If it were in head with a bit 
of infrastructure and not as a “import from upstream” project I 
think some people might “commit to it” a lot more.


> 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

- Make sure all the security concerns are rooted out.
- Update documentation, handbook, samples, ..   and educate our users.

> - add kernel support for tighter dhcpcd integration
> - switch defaults to dhcpcd, but leave dhclient and rtsold as 
> available
> - remove dhclient and rtsold

If you really want a proper smooth transition you probably need at least 
one major release overlap and that’s half a decade of maintaining two 
software sets.

/bz