On 02/16/2017 04:34 AM, Alice Wonder wrote:
On 02/16/2017 04:20 AM, James Hogarth wrote:
On 16 February 2017 at 12:02, James Hogarth <james.hoga...@gmail.com>
On 16 February 2017 at 11:46, James Hogarth <james.hoga...@gmail.com>
On 16 February 2017 at 11:35, Alice Wonder <al...@domblogger.net>
On 02/16/2017 03:28 AM, James Hogarth wrote:

On 16 February 2017 at 10:42, Alice Wonder <al...@domblogger.net>

On 02/16/2017 02:32 AM, James Hogarth wrote:

On 16 February 2017 at 10:17, Alice Wonder
<al...@domblogger.net> wrote:

On 02/16/2017 02:03 AM, James Hogarth wrote:

On 16 February 2017 at 09:09, Alice Wonder <al...@domblogger.net>

On 02/16/2017 12:54 AM, Tony Mountifield wrote:

In article
Alice Wonder <al...@domblogger.net> wrote:


I can not figure out what I need to do.

Apparently according to linode support, the VM is trying to
grab an
address with some privacy stuff enabled by default causing
it to
grab the IPv6 address that is assigned to me.

Does the accepted answer at the following link give you any



Not really - I tried

net.ipv6.conf.all.use_tempaddr = 0

and it still fails to grab the proper IPv6


Just in case, I did ask Linode support to verify that my
what it is suppose to be. Still waiting to hear on that.


it still is key=value  ... it uses the ifcfg- files (via the rh
plugin) and they are all key=value

It would be helpful if you could paste the journal output
-u NetworkManager) from the time period of attempting to get an
address ...

also the nmcli conn sh <connection_name> information for the
along with your ifcfg- files

ifcfg-lo is the only one that exists on any of the servers -
VMs that grab the correct IPv6 address.

from /sbin/ifconfig -a :

For a start stop using ifconfig ... it's broken at this point on
linux, especially on multi ip and ipv6 scenarios

Use `ip -6 addr sh` for ipv6 specfic stuff, or just ip addr sh
to see
all IP address stuff regardless of family

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 fe80::a8ad:d312:4ef4:7272  prefixlen 64  scopeid
        inet6 2a01:7e00::825f:e564:ad53:72fc  prefixlen 64
        ether f2:3c:91:18:8a:7e  txqueuelen 1000  (Ethernet)
        RX packets 9903  bytes 1088621 (1.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7786  bytes 1087223 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

That hardware address - the 18:8a:7e corresponds with what the
is suppose to be. But that's not the address it is grabbing,
fact that net.ipv6.conf.all.use_tempaddr = 0 is set.

I'm seriously wondering if the real issue is a mis-configured dhcp
their London facility because nothing makes sense.

journalctl -u NetworkManager

reports no journal entries found.

So are you not using NetworkManager then? there should be some
logs ...

I think the problem must be on their end.

It all was working fine until they migrated the VM because of a
issue, and I suspect now all the hardware address privacy stuff
issue is barking up the wrong tree because all the reading I
have done
to indicate that with

net.ipv6.conf.all.use_tempaddr = 0

that a fake temporary hardware address would not be sent to
their dhcp
server when obtaining the address, but the real one, that
should be
my assigned address.

Only if the kernel is doing SLAAC ... if other things (eg NM) are
handling it directly they may act differently ... but then from the
lack of logs is NM actually handling this?

Does systemctl status NetworkManager show it running and does nmcli
show anything?

systemctl status NetworkManager
‚óŹ NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service;
vendor preset: enabled)
   Active: active (running) since Thu 2017-02-16 08:19:34 UTC; 2h

* more stuff *

eth0: connected to Wired connection 1
        "Red Hat Virtio network device"
        ethernet (virtio_net), F2:3C:91:18:8A:7E, hw, mtu 1500
        ip4 default, ip6 default
        inet6 2a01:7e00::825f:e564:ad53:72fc/64
        inet6 fe80::a8ad:d312:4ef4:7272/64
        route6 2a01:7e00::/64

* more stuff for other interfaces *


The output of

sysctl -a | grep net.ipv6 :


It looks from that like it should not be hiding the real MAC

do nmcli conn show "Wired connection 1"

the entries of interest are:


man nm-settings to get what they mean
CentOS mailing list

ipv6.ip6-privacy:                       -1 (unknown)
ipv6.addr-gen-mode:                     stable-privacy

Okay so from the man page:

The permitted values are:
"eui64", or
"stable-privacy". If
the property is set to
"eui64", the addresses
will be generated using
the interface tokens
derived from  hardware
address. This makes the
host part of the
address to stay
constant, making it
possible to track
host's presence when it
changes networks. The
address changes when
the interface hardware
is replaced. The value
of "stable-privacy"
enables use of
secure hash of a secret
host-specific key along
with the connection
identification and the
network address as
specified by RFC7217.
This makes it
impossible to use the
address track host's
presence, and makes the
address stable when the
network interface
hardware is replaced.

I'm not certain (would have to go get changelogs) but I suspect this
was a change at 7.3 with the rebase of NetworkManager

From what you say you want it sounds like you want eui64 - the one
based entire on the current MAC - whereas the present version is using
stable-privacy to avoid tracking.

Note that this is distinct and different to ip6-privacy which is
concerned about the automatic generation of temporary addresses to use
for outbound communication.

Okay a little more research as I'm curious when it changed from EUI64
by default ...


NM changed upstream to stable-privacy at 1.2 (the privacy extensions
for the external connections were added at 1.0.4)

RHEL 7.2 enabled privacy extensions by default:


But at that milestone we had NM 1.0.6

At the RHEL 7.3 release NM was rebased to 1.4.0

It was briefly referenced with this change in the 7.3 release notes
but honestly it's pretty opaque ...


"NetworkManager now supports new device types, improved stacking of
virtual devices, LLDP, stable privacy IPv6 addresses (RFC 7217),
detects duplicate IPv4 addresses, and controls a host name through
systemd-hostnamed. Additionally, the user can set a DHCP timeout
property and DNS priorities."

Of course unless you knew what RFC 7217 was you'd have no idea this
was the effect and there's no note that stable-privacy is the new
default behaviour ARGH

Disappointingly it's not listed in the "Networking" part of the
release notes ....

I think I'll raise the priority on my blog for the article I'm
intending on the NM rebase ... there are nice things in the rebase
like the arbitrary layering of teams, vlans and bridges but then
there's unexpected stuff like this as well which should be made more

So ... Alice if you want to configure the system with the older EUI64
behaviour then in your ifcfg file for that interface you need
IPV6_ADDR_GEN_MODE=eui64 and then restart  NetworkManager (or `nmcli
conn reload` rather than a full service restart or `nmcli conn mod
"Wired Connection 1" ipv6.addr-gen-mode eui64` to do it at the CLI
without editing files and needing a connection reload).

Oh and last message about this ...

This was the email to fedora-devel at the time of the NM 1.2


Systems that existed prior to the package didn't change their
configuration, it was only newly built systems that picked up the new
default - which might  explain what you saw depending on how they
handled the migration.

There's a good reason that stable-privacy was moved to for automatic
addressing, but for your setup you may want to set the older eui64 to
keep things consistent.
CentOS mailing list

I suspect this is it. However -

cat /etc/sysconfig/network-scripts/ifcfg-eth0

yet it still lists stable-privacy

But I think that is it, so I'll figure it out.

Thank you so much.

nmcli c modify "Wired connection 1" ipv6.addr-gen-mode eui64

That solved it.

Again, thank you so much.

Now I need to set that on all my other linodes, which I suspect are only working on IPv6 because they haven't been restarted in a long time.

CentOS mailing list

Reply via email to