Re: IPv6 Stable Private Addresses RFC 7217

[Roy Marples <roy%marples.name@localhost>]

On 02/07/2014 5:22, Robert Elz wrote:
> 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.)

See here: 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/net/ipv6/addrconf.c?id=refs/tags/v3.15.3#n2731
There is no checking if there is already a suitable LL address.

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

Per interface with a global default.

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

You missed the part where dhcpcd adds it's own LL address which is 
private
but stable, unlike the hardware derived address the kernel adds.
The kernel has no notation of how to do this, and frankly, nor should it 
unless
you're happy with feeding it a private key loaded at boot time.
I would infact argue that too much IPv6 happens in the kernel.

Please read RFC 7217 and understand it's goals before commenting further 
as you
seem to have ignored it.

And you are mistaken slightly, RA is not a pre-requisite for DHCPv6.
DHCPv6 has no routing knowledge in the normal use case RA is required, 
but when
requesting a prefix delegation you don't need a RA to start DHCPv6.

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

It matters because the kernel hardware address only assignment is not 
desired
as stated above and dhcpcd cannot control the boot order so a sysctl is 
infact
needed by the operator to say "turn this off, I know what I'm doing."
dhcpcd will work correctly either way.

Thanks

Roy