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.