[CentOS] IPv6 broken on Linode
Alice Wonder
alice at domblogger.net
Thu Feb 16 12:34:18 UTC 2017
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.
More information about the CentOS
mailing list