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.