dhcpcd-discuss

On Wed, Feb 3, 2016 at 8:01 AM, Roy Marples <roy@xxxxxxxxxxxx> wrote:

> On 03/02/2016 13:41, Nicholas Williams wrote:
> > So, is this a related problem? :
> >
> > I noticed that each time I start dhcpcd for eth2, it always says this
> > (and it's always the same address ending in d416, which is to be
> > expected with autoconf):
> >
> > eth2: adding address 2600:1004:b15b:f338:a00:27ff:fe21:d416/64
> >
> > However, it actually adds TWO global addresses to the interface, not
> > just that one ending in d416, and the second address is always
> > different. Okay, no biggie ... this still isn't the problem.
>
> I snipped the rest of the post which details dhcpcd not actually dealing
> with any other addresses.
> So if it's not dhcpcd, then what is?
>
> The most likely answer is that you have the kernel handling IPv6
> temporary addresses. You can see this using the `ip a` command instead
> of ifconfig. Of course on a BSD system you would use ifconfig still ;)
>
> Arch has a good wiki on this.
> https://wiki.archlinux.org/index.php/IPv6#Privacy_extensions


Ahah! Indeed, all of those addresses are temporary:

    inet6 2600:1004:b15b:f338:99:d0c4:e774:888f/64 scope global temporary
dynamic
       valid_lft 603710sec preferred_lft 84710sec
    inet6 2600:1004:b15b:f338:5940:6213:627c:84a7/64 scope global temporary
dynamic
       valid_lft 603593sec preferred_lft 84593sec
    inet6 2600:1004:b15b:f338:3c48:2061:7d2c:6704/64 scope global temporary
dynamic
       valid_lft 603576sec preferred_lft 84576sec
    inet6 2600:1004:b15b:f338:84ce:c34b:f8ff:b137/64 scope global temporary
dynamic
       valid_lft 603571sec preferred_lft 84571sec
    inet6 2600:1004:b15b:f338:418f:2787:73c8:3485/64 scope global temporary
dynamic
       valid_lft 603564sec preferred_lft 84564sec
    inet6 2600:1004:b15b:f338:9942:2bce:84dd:405c/64 scope global temporary
dynamic
       valid_lft 603545sec preferred_lft 84545sec

So, it would seem this is outside the control of dhcpcd and up to the
kernel. Good to know. If I have this same problem on VyOS (probably won't
due to how finely it's configured), I'll just need to tweak some things to
remove those addresses or use "slaac private."

I tried "slaac private" on this same machine, and the result was perfect. I
got an address that didn't end in d416, the kernel extensions (presumably
seeing that the address didn't match the MAC address) didn't assign a
temporary address, and calling --release fully de-configured the interface
as expected.

Thanks for the help!

Nick