[CentOS] IPv6 broken on Linode

Alice Wonder alice at domblogger.net
Thu Feb 16 12:52:45 UTC 2017


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.hogarth at gmail.com>
>> wrote:
>>> On 16 February 2017 at 11:46, James Hogarth <james.hogarth at gmail.com>
>>> wrote:
>>>> On 16 February 2017 at 11:35, Alice Wonder <alice at domblogger.net>
>>>> wrote:
>>>>> On 02/16/2017 03:28 AM, James Hogarth wrote:
>>>>>>
>>>>>> On 16 February 2017 at 10:42, Alice Wonder <alice at domblogger.net>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 02/16/2017 02:32 AM, James Hogarth wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 16 February 2017 at 10:17, Alice Wonder
>>>>>>>> <alice at domblogger.net> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 02/16/2017 02:03 AM, James Hogarth wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 16 February 2017 at 09:09, Alice Wonder <alice at domblogger.net>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In article
>>>>>>>>>>>> <4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e at domblogger.net>,
>>>>>>>>>>>> Alice Wonder <alice at domblogger.net> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://forum.linode.com/viewtopic.php?f=19&t=14570&p=72785
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can not figure out what I need to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Apparently according to linode support, the VM is trying to
>>>>>>>>>>>>> grab an
>>>>>>>>>>>>> IPv6
>>>>>>>>>>>>> address with some privacy stuff enabled by default causing
>>>>>>>>>>>>> it to
>>>>>>>>>>>>> not
>>>>>>>>>>>>> grab the IPv6 address that is assigned to me.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Does the accepted answer at the following link give you any
>>>>>>>>>>>> useful
>>>>>>>>>>>> hints?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when-using-ipv6
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers
>>>>>>>>>>>> Tony
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> hardware
>>>>>>>>>>> address
>>>>>>>>>>> is
>>>>>>>>>>> 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
>>>>>>>>>> (journalctl
>>>>>>>>>> -u NetworkManager) from the time period of attempting to get an
>>>>>>>>>> address ...
>>>>>>>>>>
>>>>>>>>>> also the nmcli conn sh <connection_name> information for the
>>>>>>>>>> interface
>>>>>>>>>> along with your ifcfg- files
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ifcfg-lo is the only one that exists on any of the servers -
>>>>>>>>> including
>>>>>>>>> the
>>>>>>>>> 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 178.79.185.217  netmask 255.255.255.0  broadcast
>>>>>>>>> 178.79.185.255
>>>>>>>>>         inet6 fe80::a8ad:d312:4ef4:7272  prefixlen 64  scopeid
>>>>>>>>> 0x20<link>
>>>>>>>>>         inet6 2a01:7e00::825f:e564:ad53:72fc  prefixlen 64
>>>>>>>>> scopeid
>>>>>>>>> 0x0<global>
>>>>>>>>>         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
>>>>>>>>> IPv6
>>>>>>>>> address
>>>>>>>>> is suppose to be. But that's not the address it is grabbing,
>>>>>>>>> despite
>>>>>>>>> the
>>>>>>>>> fact that net.ipv6.conf.all.use_tempaddr = 0 is set.
>>>>>>>>>
>>>>>>>>> I'm seriously wondering if the real issue is a mis-configured dhcp
>>>>>>>>> server
>>>>>>>>> in
>>>>>>>>> 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
>>>>>>>>> hardware
>>>>>>>>> issue, and I suspect now all the hardware address privacy stuff
>>>>>>>>> being
>>>>>>>>> the
>>>>>>>>> issue is barking up the wrong tree because all the reading I
>>>>>>>>> have done
>>>>>>>>> seems
>>>>>>>>> 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
>>>>>>>>> fetching
>>>>>>>>> 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;
>>>>>>> enabled;
>>>>>>> vendor preset: enabled)
>>>>>>>    Active: active (running) since Thu 2017-02-16 08:19:34 UTC; 2h
>>>>>>> 19min
>>>>>>> ago
>>>>>>>
>>>>>>> * more stuff *
>>>>>>>
>>>>>>> nmcli
>>>>>>> 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
>>>>>>>         inet4 178.79.185.217/24
>>>>>>>         route4 178.79.187.246/32
>>>>>>>         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 :
>>>>>>>
>>>>>>> https://librelamp.com/sysctl.txt
>>>>>>>
>>>>>>> It looks from that like it should not be hiding the real MAC
>>>>>>> address.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> do nmcli conn show "Wired connection 1"
>>>>>>
>>>>>> the entries of interest are:
>>>>>>
>>>>>> ipv6.ip6-privacy
>>>>>> ipv6.addr-gen-mode
>>>>>>
>>>>>> man nm-settings to get what they mean
>>>>>> _______________________________________________
>>>>>> CentOS mailing list
>>>>>> CentOS at centos.org
>>>>>> https://lists.centos.org/mailman/listinfo/centos
>>>>>>
>>>>>
>>>>> 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
>>>> cryptographically
>>>> 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 ...
>>>
>>> https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-the-ipv6-internet/
>>>
>>>
>>> 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:
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/7.2_Release_Notes/index.html
>>>
>>>
>>> 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 ...
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/7.3_Release_Notes/index.html
>>>
>>>
>>> "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
>>> visible.
>>>
>>> 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
>> introduction:
>>
>> https://lists.fedoraproject.org/pipermail/devel/2015-November/216754.html
>>
>> 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
>> CentOS at centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
>
> I suspect this is it. However -
>
> cat /etc/sysconfig/network-scripts/ifcfg-eth0
> IPV6_ADDR_GEN_MODE=eui64
>
> 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.




More information about the CentOS mailing list