Re: Ubuntu 16.04

[WILSON Sam]

On 22 Apr 2016, at 14:37, Holger Zuleger  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




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.

Re: Ubuntu 16.04

[Holger Zuleger]

> 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




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Ubuntu 16.04

[Mikael Abrahamsson]

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


$ ip -d link show dev wlan0
3: wlan0:  mtu 1500 qdisc mq state UP mode 
DORMANT group default qlen 1000


$ ip -d link show dev eth0
2: eth0:  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 Abrahamssonemail: swm...@swm.pp.se

Re: Ubuntu 16.04

[Bjørn Mork]

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

Re: Ubuntu 16.04

[Tore Anderson]

* 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  | grep ipv6" say?

Tore

Re: Ubuntu 16.04

[Bjørn Mork]

Mikael Abrahamsson  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:  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

Re: Ubuntu 16.04

[Jeroen Massar]

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

Re: Ubuntu 16.04

[Mikael Abrahamsson]

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 = 1
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 Abrahamssonemail: swm...@swm.pp.se

Re: Ubuntu 16.04

[Jeroen Massar]

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

Ubuntu 16.04

[Mikael Abrahamsson]

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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se