Mailing List Archive

On 2016-04-22 13:39, Mikael Abrahamsson wrote:
>
> Hi,
>
> I have a pretty standard Ubuntu 14.04 machine I just upgraded to 16.04,
> which means I get a "4.4.0-21-generic" kernel.
>
> I guess I'm using straight up network manager, because my
> /etc/network/interfaces doesn't mention anything about eth0 or wlan0,
> only lo.
>
> In the GUI, it came default with "privacy extensions disabled".
>
> I used to administrate this device using its EUI64 based SLAAC address,
> which was stable across reboots. Now with 16.04, I get two addresses,
> none of them stable across reboots.
>
> Anyone know what the thought is behind this? I want to continue using
> SLAAC and I'm fine with privacy extension addresses over time, but I
> want a single stable address across reboots.

Isn't it awesome that Ubuntu wants dynamic addresses on servers? :)

They have been told about that problem by many people already,
unfortunately, they claim to know better...


But, check your 'sysctl -a | net.ipv6.conf' you might find some knobs
there. Next to that, check systemd settings as that thing wants to take
over the kernel and thus ignores those settings and comes up with it's
own...

Greets,
Jeroen

On Fri, 22 Apr 2016, Jeroen Massar wrote:

> Isn't it awesome that Ubuntu wants dynamic addresses on servers? :)

Well, this wasn't a server, this is installed as a desktop.

> They have been told about that problem by many people already,
> unfortunately, they claim to know better...

Who are "they"?

> But, check your 'sysctl -a | net.ipv6.conf' you might find some knobs
> there. Next to that, check systemd settings as that thing wants to take
> over the kernel and thus ignores those settings and comes up with it's
> own...

It's strangem it looks like they still have the kernel to process RAs?
Doesn't it seem like the kernel now has support for the kind of stable
non-EUI64 based addresses from https://tools.ietf.org/html/rfc7217 ?

http://unix.stackexchange.com/questions/251401/cannot-read-key-net-ipv6-conf-all-stable-secret-in-sysctl
seems to indicate that the error message below is because the secret isn't
set? So potentially if I set the secret I'll get the same address every
time? Let's try...

$ sudo sysctl -a | grep net.ipv6.conf | grep -i eth0
sysctl: reading key "net.ipv6.conf.all.stable_secret"
sysctl: reading key "net.ipv6.conf.default.stable_secret"
sysctl: reading key "net.ipv6.conf.eth0.stable_secret"
net.ipv6.conf.eth0.accept_dad = 1
net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.eth0.accept_ra_defrtr = 0
net.ipv6.conf.eth0.accept_ra_from_local = 0
net.ipv6.conf.eth0.accept_ra_min_hop_limit = 1
net.ipv6.conf.eth0.accept_ra_mtu = 1
net.ipv6.conf.eth0.accept_ra_pinfo = 0
net.ipv6.conf.eth0.accept_ra_rt_info_max_plen = 0
net.ipv6.conf.eth0.accept_ra_rtr_pref = 0
net.ipv6.conf.eth0.accept_redirects = 1
net.ipv6.conf.eth0.accept_source_route = 0
net.ipv6.conf.eth0.autoconf = 1
net.ipv6.conf.eth0.dad_transmits = 1
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.eth0.force_mld_version = 0
net.ipv6.conf.eth0.force_tllao = 0
net.ipv6.conf.eth0.forwarding = 0
net.ipv6.conf.eth0.hop_limit = 64
net.ipv6.conf.eth0.ignore_routes_with_linkdown = 0
net.ipv6.conf.eth0.max_addresses = 16
net.ipv6.conf.eth0.max_desync_factor = 600
net.ipv6.conf.eth0.mc_forwarding = 0
net.ipv6.conf.eth0.mldv1_unsolicited_report_interval = 10000
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
sysctl: reading key "net.ipv6.conf.wlan0.stable_secret"
net.ipv6.conf.eth0.mldv2_unsolicited_report_interval = 1000
net.ipv6.conf.eth0.mtu = 1500
net.ipv6.conf.eth0.ndisc_notify = 0
net.ipv6.conf.eth0.proxy_ndp = 0
net.ipv6.conf.eth0.regen_max_retry = 3
net.ipv6.conf.eth0.router_probe_interval = 60
net.ipv6.conf.eth0.router_solicitation_delay = 1
net.ipv6.conf.eth0.router_solicitation_interval = 4
net.ipv6.conf.eth0.router_solicitations = 3
net.ipv6.conf.eth0.suppress_frag_ndisc = 1
net.ipv6.conf.eth0.temp_prefered_lft = 86400
net.ipv6.conf.eth0.temp_valid_lft = 604800
net.ipv6.conf.eth0.use_oif_addrs_only = 0
net.ipv6.conf.eth0.use_tempaddr = 2


--
Mikael Abrahamsson email: swmike@swm.pp.se

On 2016-04-22 14:37, Mikael Abrahamsson wrote:
> On Fri, 22 Apr 2016, Jeroen Massar wrote:
>
>> Isn't it awesome that Ubuntu wants dynamic addresses on servers? :)
>
> Well, this wasn't a server, this is installed as a desktop.

Then you should expect all kinds of magic...

>> They have been told about that problem by many people already,
>> unfortunately, they claim to know better...
>
> Who are "they"?

The people who decide what does and what does not go into Ubuntu:

https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756

Oh, indeed, toggling the sysctl back will lose your default route, thus
you can't just put it in an extra sysctl statement that runs after it.

Putting an empty file into /etc/sysctl.d/10-ipv6-privacy.conf solves
this partially though.

[..]
> $ sudo sysctl -a | grep net.ipv6.conf | grep -i eth0
[..]
> net.ipv6.conf.eth0.use_tempaddr = 2

Recognize what that knob does?

It has to do with the above mentioned file.

Still, all of that can be ignored by systemd, network-manager and other
such things running on a host.

Greets,
Jeroen

Mikael Abrahamsson <swmike@swm.pp.se> writes:
> On Fri, 22 Apr 2016, Jeroen Massar wrote:
>
>> But, check your 'sysctl -a | net.ipv6.conf' you might find some knobs
>> there. Next to that, check systemd settings as that thing wants to take
>> over the kernel and thus ignores those settings and comes up with it's
>> own...
>
> It's strangem it looks like they still have the kernel to process RAs?
> Doesn't it seem like the kernel now has support for the kind of stable
> non-EUI64 based addresses from https://tools.ietf.org/html/rfc7217 ?
>
> http://unix.stackexchange.com/questions/251401/cannot-read-key-net-ipv6-conf-all-stable-secret-in-sysctl
> seems to indicate that the error message below is because the secret
> isn't set? So potentially if I set the secret I'll get the same
> address every time? Let's try...

That's correct.... if they use the kernel. I don't know what they do.
You can check the kernel config with something like

$ ip -d link show dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 0c:8b:fd:08:09:71 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64

"addrgenmode" will tell you how the kernel creates IPv6 addresses for
that interface. "eui64" is the traditional default for ethernet
interfaces, but userspace applications taking over address configuration
will typically set it to "none".

Unfortunately you'll probably need a newer "iproute" tool to show
anything else. But recent kernels also support the rfc7217 mode you
refer to above, and a variant of that using an autogenerated secret.
The latter does of course not make much sense for most use cases. It
was created for devices which has no appropriate EUI64 method, like
headerless tunnels.



Bjørn

* Mikael Abrahamsson

> I have a pretty standard Ubuntu 14.04 machine I just upgraded to 16.04,
> which means I get a "4.4.0-21-generic" kernel.
>
> I guess I'm using straight up network manager, because my
> /etc/network/interfaces doesn't mention anything about eth0 or wlan0, only
> lo.
>
> In the GUI, it came default with "privacy extensions disabled".

Ubuntu (at least previous versions) hard-codes privacy extensions to be
on and preferred, overriding any user configuration to the contrary in
NM or /etc/network/interfaces. You need to
delete /etc/sysctl.d/10-ipv6-privacy.conf for your NM/interfaces
setting to take effect.

https://bugs.launchpad.net/bugs/1497166

> I used to administrate this device using its EUI64 based SLAAC
> address, which was stable across reboots. Now with 16.04, I get two
> addresses, none of them stable across reboots.
>
> Anyone know what the thought is behind this? I want to continue using
> SLAAC and I'm fine with privacy extension addresses over time, but I
> want a single stable address across reboots.

Are you 100% sure one of the addresses isn't stable? NM-1.2 defaults to
using RFC7217 IID instead of EUI-64, and I believe Ubuntu 16.04 ships
with a NM-1.2 or (or a release candidate).

https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-the-ipv6-internet/

(This is orthogonal from the use of RFC4941 privacy addresses, btw.)

However RFC7217 IIDs are supposed to be stable across reboots, and on
my Fedora 23 system, they are. If they aren't with you, maybe something
goes wrong with storing the stable secret key? On my system, it's
stored in /var/lib/NetworkManager/secret_key, for what it's worth.

What does "nmcli con show <yourconnamehere> | grep ipv6" say?

Tore

Forgot to mention one very useful command if you are after
short and easy-to-remember addresses with dynamic prefixes:

$ ip token help
Usage: ip token [ list | set | get ] [ TOKEN ] [ dev DEV ]

See ip-token(8). Still don't have any idea how network-manager or
systemd-networkd relates to this, unfortunately.

Yes, this is a UI mess :(


Bjørn

On Fri, 22 Apr 2016, Bjørn Mork wrote:

> $ ip -d link show dev wlan0
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000

$ ip -d link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 90:fb:a6:8a:7d:de brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode none

I have another machine I upgraded that does still use EUI64. I will
compare settings and try to find out what the difference between them is.

--
Mikael Abrahamsson email: swmike@swm.pp.se

> Forgot to mention one very useful command if you are after
> short and easy-to-remember addresses with dynamic prefixes:
>
> $ ip token help
> Usage: ip token [ list | set | get ] [ TOKEN ] [ dev DEV ]
Great! This is something I was looking for years now.

Does anyone know why the output is in "inet" syntax?

# ip token set ::0:0:27:53 dev eth0
# ip token list
token ::0.39.0.83 dev eth0
token :: dev wlan0

$ ip -6 addr show | grep :53
inet6 2a00:0:1803::27:53/64 scope global dynamic

Ok, setting it to a larger value "restores" inet6 syntax:
# ip token set ::0:18:27:53 dev eth0
# ip token get dev eth0
token ::18:27:53 dev eth0

Holger

On 22 Apr 2016, at 14:37, Holger Zuleger <Holger.Zuleger@hznet.de> wrote:

>> Forgot to mention one very useful command if you are after
>> short and easy-to-remember addresses with dynamic prefixes:
>>
>> $ ip token help
>> Usage: ip token [ list | set | get ] [ TOKEN ] [ dev DEV ]
> Great! This is something I was looking for years now.
>
> Does anyone know why the output is in "inet" syntax?
>
> # ip token set ::0:0:27:53 dev eth0
> # ip token list
> token ::0.39.0.83 dev eth0
> token :: dev wlan0
>
> $ ip -6 addr show | grep :53
> inet6 2a00:0:1803::27:53/64 scope global dynamic
>
> Ok, setting it to a larger value "restores" inet6 syntax:
> # ip token set ::0:18:27:53 dev eth0
> # ip token get dev eth0
> token ::18:27:53 dev eth0


<https://tools.ietf.org/html/rfc4291#section-2.5.5>

Sam

--
Sam Wilson
Communications Infrastructure Section, IT Infrastructure
Information Services, The University of Edinburgh
Edinburgh, Scotland, UK


The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Hi again,

> Ubuntu (at least previous versions) hard-codes privacy extensions to be
> on and preferred, overriding any user configuration to the contrary in
> NM or /etc/network/interfaces.

For the record, this has actually been fixed in 16.04, probably as a
side-effect of changing to systemd. Now the sysctls get loaded before
the network is brought up, so if you explicitly configure "privext 0"
in /etc/network/interfaces or "ipv6.ip6-privacy 0" in nmcli con edit
<foo>, that device-specific setting does not get overwritten later on
in the boot process.

> > I used to administrate this device using its EUI64 based SLAAC
> > address, which was stable across reboots. Now with 16.04, I get two
> > addresses, none of them stable across reboots.
> >
> > Anyone know what the thought is behind this? I want to continue using
> > SLAAC and I'm fine with privacy extension addresses over time, but I
> > want a single stable address across reboots.
>
> Are you 100% sure one of the addresses isn't stable? NM-1.2 defaults to
> using RFC7217 IID instead of EUI-64, and I believe Ubuntu 16.04 ships
> with a NM-1.2 or (or a release candidate).

I was able to reproduce the issue. I'm guessing you're using a wired
ethernet with no explicitly saved connection profile? When NM
auto-creates an ephemeral connection profile, it gets an equally
ephemeral UUID. The RFC7217 implementation in NM derives the UUID from
the connection profile (amongst other things), which means the results
of the algorithm - the IID - isn't stable at all.

https://bugzilla.gnome.org/show_bug.cgi?id=765464

You can work around this by saving the connection profile, e.g.:

$ nmcli con edit 'Wired connection 1' # the name might be localised
nmcli> save

Alternatively, if you don't want RFC7212 addresses at all and prefer
the previous behaviour, you can do:

nmcli> set ipv6.addr-gen-mode eui64

Tore

On Sat, 23 Apr 2016, Tore Anderson wrote:

> I was able to reproduce the issue. I'm guessing you're using a wired
> ethernet with no explicitly saved connection profile? When NM
> auto-creates an ephemeral connection profile, it gets an equally
> ephemeral UUID. The RFC7217 implementation in NM derives the UUID from
> the connection profile (amongst other things), which means the results
> of the algorithm - the IID - isn't stable at all.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=765464
>
> You can work around this by saving the connection profile, e.g.:
>
> $ nmcli con edit 'Wired connection 1' # the name might be localised
> nmcli> save
>
> Alternatively, if you don't want RFC7212 addresses at all and prefer
> the previous behaviour, you can do:
>
> nmcli> set ipv6.addr-gen-mode eui64

This worked for me perfectly, and restored the old behavor so I get an
EUI64 address. Thanks!

--
Mikael Abrahamsson email: swmike@swm.pp.se