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.