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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[Dropping netdev, as this is inappropriate]

On Sat, Jan 07, 2017 at 03:16:06PM +0000, peter green wrote:

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

Did you complain to you provider for providing broken configuration?

Sorry, but we can't workaround every broken configuration out there.
You are however free to educate people.

Regards,
Bastian

--
I'm a soldier, not a diplomat. I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/01/17 07:34, Henri Wahl wrote:

Hi Peter,

maybe our DHCPv6 server dhcpy6d helps you out - it allows to give
clients random addresses as they were pricacy extended. Have a look at https://dhcpy6d.ifw-dresden.de.

I am a guy who understands networks, I can figure out local workarounds to my problems.

The problem is that when someone plugs an out of the box Debian system (and likely many other Linux distributions too) into a Sky broadband router (one of the largest ISPs in the UK) they will end up with TCP connections that drop once an hour for no
obvious reason.

This is going to lead to frustrated users, some won't know what to blame and will just think their connection and/or OS is shit. Some will realize it's IPv6 related but won't figure out the details beyond that and will disable IPv6 in disgust.

I don't know about you but as someone who cares about the future of the Internet the last thing I want to see is users disabling IPv6 in disgust.

Sky certainly deserve some of the blame for setting such short timeouts in their RAs, but Linux also deserves some of the blame for an implementation of privacy extensions that does not seem to update the lifetimes of those addresses, even when they are
in active use by applications.

Regards
Henri

On 07.01.2017 16:16, peter green wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)