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

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