Re: IPv6 Stable Private Addresses RFC 7217

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 02 Jul 2014 00:48:01 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <439239e90356efcd45e8bcd989747e96%mail.marples.name@localhost>

  | BSD kernels will only add a link-local address on UP if none present.
  | Linux kernels will add one regardless, but actually use the 1st one 
  | assigned (from my testing anyway).

That's weird - do you mean that every time the interface goes down/up
(on a linux system) it generates a new LL addr?  Or just that there is one
particular LL addr (probably EUI64 based as a guess) that they believe an
interface just must have, and if that one isn't there, they add it, even if
there's another perfectly good one already existing that they actually use?
Either way looks wrong to me (but the first of those much more wrong than
the second).   (That is, the BSD (KAME) way is correct I think.)

  | As this is a kernel operation, it's quite possible for another userland 
  | application which UPs the interface to do this before dhcpcd does it.

Of course, is that some kind of problem?

  | Because if this, I added a toggle to NetBSD sysctl to stop the kernel 
  | from doing this - other BSD and Linux have the same toggle.

I have no problem with the sysctl (is it per interface, or system wide?
or perhaps the ideal solution - both - a system wide default, with per
interface overrides) which (I am assuming) prevents the kernel assigning
a LL addr when the interface comes up) - but I don't understand your use
model.

In fact, I'd normally expect the interface to be up, and a LL addr assigned,
before dhcpcd can possibly start (at least, before it can start doing anything
dhcp related).   The LL addr is needed to send an RS to obtain the RA that
indicates whether DHCP should be used or not after all.   But I assume for this
the part of dhcpcd that counts is the part that receives and processes RA's,
and I assume sends the RS ?   (The general network management role for which
the name dhcpcd is something of an anachronism).

Does it really matter if the LL is already assigned by some other process,
and if there is some other process that needs to use the network (perhaps
part of system booting, loading the kernel / modules (and dhcpcd itself...)
shouldn't it be able to configure the net as it needs it, and then simply
have it left that way?   If dhcpcd wants to take over monitoring RA's and
managing prefix changes after, that's OK, it does not need to be involved in
the initial address assignment (either LL or global) for that to happen,
does it?

Further, I cannot see how the sysctl really helps - rather than being used
by dhcpcd it should be something dhcpcd obeys when set by the network
manager, to prevent v6 usage on an interface (or on the whole system).
(There should be a similar one for v4 incidentally.)   After all, any
application that knows it needs an addr assigned, can trivially easily
alter the sysctl value if that's what it needs to make things work.

kre