On 16 February 2017 at 12:02, James Hogarth <james.hogarth@xxxxxxxxx> wrote:
> On 16 February 2017 at 11:46, James Hogarth <james.hogarth@xxxxxxxxx> wrote:
>> On 16 February 2017 at 11:35, Alice Wonder <alice@xxxxxxxxxxxxxx> wrote:
>>> On 02/16/2017 03:28 AM, James Hogarth wrote:
>>>>
>>>> On 16 February 2017 at 10:42, Alice Wonder <alice@xxxxxxxxxxxxxx> wrote:
>>>>>
>>>>> On 02/16/2017 02:32 AM, James Hogarth wrote:
>>>>>>
>>>>>>
>>>>>> On 16 February 2017 at 10:17, Alice Wonder <alice@xxxxxxxxxxxxxx> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 02/16/2017 02:03 AM, James Hogarth wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 16 February 2017 at 09:09, Alice Wonder <alice@xxxxxxxxxxxxxx>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@xxxxxxxxxxxxxx>,
>>>>>>>>>> Alice Wonder <alice@xxxxxxxxxxxxxx> 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@xxxxxxxxxx
>>>> 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@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
