bad interaction between privacy extensions, prefix lifetimes and protocols that maintain long-term connections.

bad interaction between privacy extensions, prefix lifetimes and protocols that maintain long-term connections.

[peter green]

I just switched my main machine to a new one. After doing so I noticed my connections to IRC were dropping about once per hour.

The old machine had been running a mixed mess of Debian versions while the new machine is running Debian stretch. A critical difference between the old and new machines is that the old machine had privacy extensions disabled while the new machine had them enabled.

Disabling privacy extensions solved the issue but obviously reveals the MAC address of my new machine to the world which is undesirable.

My ISP (a major provider in the UK) router sets a relatively short valid_lft of about 1 hour. Presumably so any changes to the ISP-allocated address will be picked up quickly by clients.

For the main MAC-based address the valid_lft is always short but it is updated by new RAs so the address remains valid.

However privacy addresses inherit their valid_lft from the main MAC-based address and unlike the main address it is not updated causing the addresses to time out. I believe that the timeout of these privacy addresses is what is causing my repeated disconnections from IRC.

Re: bad interaction between privacy extensions, prefix lifetimes and protocols that maintain long-term connections.

[Matthew Hall]

On Sat, Jan 07, 2017 at 03:16:06PM +0000, peter green wrote:
> For the main MAC-based address the valid_lft is always short but it is 
> updated by new RAs so the address remains valid.
> 
> However privacy addresses inherit their valid_lft from the main MAC-based 
> address and unlike the main address it is not updated causing the addresses 
> to time out. I believe that the timeout of these privacy addresses is what 
> is causing my repeated disconnections from IRC.

Privacy addresses generally cause me nothing but absolute misery.

Despite the MAC address problem I usually end up disabling them just to be 
able to survive without losing my sanity due to issues like this one.

I have had all kinds of applications not work reliably because of them. 
Including Google Chrome / Chromium etc. IRC also seems like a likely victim, 
but I wouldn't have noticed because I use it from a system with a static 
address.

Perhaps a workaround would be using the MAC address override ability in the 
interfaces file pre-up script with "ip link set eth0 address 02:01:02:03:04:08".
Randomly generate one fake MAC per boot.

Matthew.

Re: bad interaction between privacy extensions, prefix lifetimes and protocols that maintain long-term connections.

[Bjørn Mork]

peter green <plugwash@p10link.net> writes:

> Disabling privacy extensions solved the issue but obviously reveals
> the MAC address of my new machine to the world which is undesirable.

I have no solution to the problem with privacy extensions, but just
wanted to let you know there is a third alternative for IPv6
autoconfigured addresses: stable-privacy

This will give you addresses which are just as stable as the eui64
addresses, but derived from a configurable secret instead of the
mac. The kernel part is documented in under 'stable_secret' in
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

If you use NetworkManager, then this is very easy to set up: Just set
'addr-gen-mode' to 'stable-privacy'.  See the docs in nm-settings(5).

Or if you use ifupdown and prefer to control it yourself, you can
e.g. save the secret (in IPv6 address format) in some file and write it
to /proc/sys/net/ipv6/conf/default/stable_secret on boot.  This will set
a common secret for all interfaces.  Note that the generated interface
ids still will be different, since the prefix is used as part of the
input to the generator.



Bjørn