Re: IPv6 broken on Linode

[Alice Wonder <alice@xxxxxxxxxxxxxx>]

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@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
>
> 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.

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos