Date: Sun, 29 Jul 2018 19:03:53 +0100
From: Roy Marples <roy%marples.name@localhost>
Message-ID: <1718c621-40fe-cc05-5ec9-ee5f646dee4c%marples.name@localhost>
| > NetBSD 7 would have ignored the DHCP part, as there was no DHCPv6
| > client there
|
| That's not true.
I phrased what I said badly. From earlier messages it is clear that the
NetBSD 7 host in question (when it was running NetBSD 7) was using
dhclient and rtsol (and kernel IPv6 addr autoconf). On that particular
netbsd-7 host there was no DCHCPv6 client, ...
| NetBSD 7 shipped with dhcpcd-6.4.3 which did have a functional DHCPv6
| client.
OK, but it was not the default, and few sites used it.
| While I wont rule out this problem could be a dhcpcd issue, currently nothing
| points to that being the case.
Agreed, but right now nothing points to anything being the cause.
Clearly something odd is happening, and I suspect that there might
be some clue in some information that is not yet available.
| So one of the changes in dhcpcd-7 was the default location of some
| files, including the secret file which generates the SLAAC stable
| private address. If you didn't change the location
Since dhcpcd was not being used previously there would have been no
old files to worry about, it would all be new. And the address will have
changed, as now one of the randomly generated private addresses is
clearly being used, whereas previously it was most likely an EUI-64
based one.
| You can add `nodhcp6` to dhcpcd.conf to disable DHCP6 entirely.
| This should ignore both the RA O and M flags and probably any static
| DHCP6 setup you might have installed as well, unless a following dhcp6
| option re-enables it.
Does that also affect the SLAAC stable address generation (autoconf'd
addr on the advertised prefix) ? If it doesn't, that would be worth trying.