dhcpcd-discuss

On 2018/09/24 19:14, Roy Marples wrote:
> On 24/09/2018 16:39, Klemens Nanni wrote:
> > On Mon, Sep 24, 2018 at 02:20:30PM +0100, Roy Marples wrote:
> > > It's not currently that granular.
> > > See a recent discussion on this here:
> > > https://roy.marples.name/archives/dhcpcd-discuss/0001932.html
> > Thanks for the pointer.
> > 
> > > I also find it rather odd that you even need to run dhcpcd for DNS as the
> > > slaacd man page states it supports RFC 8106 which is all about DNS in the RA
> > > and nothing else.
> > While slaacd parses RDNSS and DNSSL, it does not touch /etc/resolv.conf to avoid
> > inteference with dhclient as of now.
> 
> Then it's man page should at least be updated to reflect this.

Perhaps something more is needed but the manual doesn't usually list what
something _doesn't_ do - currently it's "slaacd derives IPv6 addresses and
default routes from received router advertisements and installs them in
the kernel" so I don't see anything suggesting that it handles resolv.conf.

I think I may propose something like 'It also stores information about
DNS resolvers and domain search list for retrieval with slaacctl(8)'
though I don't know if it will be accepted.

> And maybe prod OpenBSD into solving it - a solution to this would be to
> implement resolvconf. NetBSD and FreeBSD use openresolv for this
> (disclaimer, I maintain it alongside dhcpcd so there is some bias).
> https://roy.marples.name/projects/openresolv
> 
> CCing Stuart as he might know who to prod for this.

This problem has been discussed internally a bit but we don't have
anything usable. It would need to take input from dhclient [either
resolv.conf or a lease file], umb(4) [USB MBIM mobile broadband devices,
which are handled in-kernel and have their own mechanism to fetch ns
addresses], slaac, and maybe others [vpn etc]. Most of these do not have
a way to write a resolv.conf file at all - and for some like umb(4),
doing so would be quite a stretch.

I think the general direction we were looking at was some kind of route
socket message to send a DNS server advertisement and some kind of
daemon to select from these and update resolv.conf. This is the sort of
thing that usually gets whiteboarded at hackathons and I haven't been
to all that many recently so am probably a bit behind what's happening
there.

> > > Is there a compelling reason why you need to run both? Either dhcpcd or
> > > slaacd should be fine.
> > Because slaacd comes with base, is enabled by default and runs with privilege
> > separation.
> > 
> > dhcpcd running as root should only do what's necessary.

I don't understand why someone would run both for two parts of the same
thing (i.e. handling router advertisements on the same interface).
If you're going to trust dhcpcd to parse rdnss fields and write files,
why not let it configure addresses too.

> There was also a discussion about doing priv-sep in dhcpcd here:
> https://roy.marples.name/archives/dhcpcd-discuss/0002137.html
> 
> But it come to nothing as no-one said if my idea was good or bad. One
> commentor offered to at least do a small related patch, but that didn't
> materialise, thus it has stalled as I personally have little interest in the
> feature.

My last attempt at implementing privsep (porting the privsep code from
OpenBSD's old version of BIND to a newer one) didn't exactly go well
so I don't feel too qualified to comment on whether an approach is good
or not ;)

> Anyway, my OpenBSD vm is currently down so I can't test the attached diff,
> but it should fix your problem. Please test it and let me know.
> 
> Roy

> diff --git a/src/if-bsd.c b/src/if-bsd.c
> index cdd959a6..c1a6be86 100644
> --- a/src/if-bsd.c
> +++ b/src/if-bsd.c
> @@ -1393,8 +1393,20 @@ set_ifxflags(int s, const struct interface *ifp)
>  	/*
>  	 * If not doing autoconf, don't disable the kernel from doing it.
>  	 * If we need to, we should have another option actively disable it.
> +	 *
> +	 * OpenBSD moved from kernel based SLAAC to userland via slaacd(8).
> +	 * It has a similar featureset to dhcpcd such as stable private
> +	 * addresses, but lacks the ability to handle DNS inside the RA
> +	 * which is a serious shortfall in this day and age.

(fwiw, the kernel-based one didn't support rdnss either..)

> +	 * Appease their user base by working alongside slaacd(8) if
> +	 * dhcpcd is instructed not to do auto configuration of addresses.
>  	 */
> -	if (ifp->options->options & DHCPCD_IPV6RS)
> +#if defined(ND6_IFF_ACCEPT_RTADV)
> +#define	BSD_AUTOCONF	DHCPCD_IPV6RS
> +#else
> +#define	BSD_AUTOCONF	DHCPCD_IPV6RA_AUTOCONF
> +#endif
> +	if (ifp->options->options & BSD_AUTOCONF)
>  		flags &= ~IFXF_AUTOCONF6;
>  	if (ifr.ifr_flags == flags)
>  		return 0;

What option would you suggest for "allow dhcpcd to do DHCPv6-PD and leave
RA handling entirely to the OS"? I'm currently using noipv6rs for that
which works with the current code, but is broken with that diff. I'm
happy to change my config (which is also in the port's "pkg-readme") if
there's something better.