dhcpcd-discuss

On 2018/01/29 15:26, Roy Marples wrote:
> On 29/01/2018 12:54, Stuart Henderson wrote:
> > Happy birthday :)
> 
> Thanks :)
> 
> > 
> > I had a report that dhcpcd >=7 was clearing the autoconf6 flag on an
> > interface even when dhcpcd wasn't managing rs itself on that interface.
> > I think this must have changed when the "own" handling was removed.
> > 
> > Does this look right or am I missing something?  Thanks!
> 
> You're the second person to query this since I made the change.
> Here's the email which triggered the change:
> https://roy.marples.name/archives/dhcpcd-discuss/0001880.html
> 
> I think the request is still valid, but equally yours is as well.
> The changeset in question is below, so it's really quite simple.
> However To satisfy all parties we may need an optional argument to it.
> 
> I think the current default is still correct - the user doesn't want IPv6/RS
> so clearing the kernel options that enable it is fine by default.
> 
> noipv6rs keep
> noipv6rs keepkernel
> noipv6rs leave
> keepipv6rs
> 
> Which of these sounds better, or can you suggest something else?

I see exactly where you're coming from, it's similar to the
reason why OpenBSD no longer (since 5.6) configures a link-local by
default. (the reasoning when it was changed is that users coming from
IPv4 don't expect the machine to respond to or send IP traffic unless
an action of some sort has been carried out to set an address, so the
sane default is for IPv6 to behave similarly). So in the case of
OpenBSD, if an interface has IFXF_AUTOCONF6, that was an active choice.

To me, arguments like "noipv6rs" and "noipv6" seem passive, I'd expect
them to request that dhcpcd doesn't handle those things itself but
I wouldn't expect them to cause it to make a change the admin has
already explicitly made.

It would seem more intuitive to me to have this behind a more
"active" sounding word, maybe "disableipv6". But I see why "noipv6" /
"noipv6rs" makes sense on other OS.