Re: Disabling temporary addresses by default?

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 30 January 2020 14:41 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE821200FE for <ipv6@ietfa.amsl.com>; Thu, 30 Jan 2020 06:41:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.435
X-Spam-Level: *
X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhf-ua6owMe7 for <ipv6@ietfa.amsl.com>; Thu, 30 Jan 2020 06:41:42 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BD21200FD for <ipv6@ietf.org>; Thu, 30 Jan 2020 06:41:41 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [206.108.166.28]) by relay.sandelman.ca (Postfix) with ESMTPS id 818501F45B for <ipv6@ietf.org>; Thu, 30 Jan 2020 14:41:40 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id A719C1A374D; Thu, 30 Jan 2020 09:33:05 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6man WG <ipv6@ietf.org>
Subject: Re: Disabling temporary addresses by default?
In-reply-to: <CAO42Z2zzmBGwrEthNP=S0yF+uiUP=88OKRhtXN8L+mtbdGO8rw@mail.gmail.com>
References: <CAKD1Yr11_SSUkCBuQ3-h+eRg0LPZQdhe+h7f0YZy9TiyRWj6mw@mail.gmail.com> <751D59E0-F60B-4FE1-840F-3FEAB82F618F@huitema.net> <c058863d-9e29-3ddb-a020-0ebadef26ad4@si6networks.com> <CABNhwV0KsKN7LQY2D-BJkCtvB40oZCT65EmOCr0oE56c9g7-aQ@mail.gmail.com> <CAO42Z2zzmBGwrEthNP=S0yF+uiUP=88OKRhtXN8L+mtbdGO8rw@mail.gmail.com>
Comments: In-reply-to Mark Smith <markzzzsmith@gmail.com> message dated "Wed, 29 Jan 2020 07:23:58 +1300."
X-Mailer: MH-E 8.6; nmh 1.7.1-RC3; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 30 Jan 2020 09:33:05 -0500
Message-ID: <26898.1580394785@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SVwHY-qTJt2dlBMfwYm_nMBwRHc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2020 14:41:44 -0000

Mark Smith <markzzzsmith@gmail.com> wrote:
    >> The main reason this topic comes has up is due to possible impact of
    >> usage of the temporary address when it gets deprecated with long lived
    >> session.
    >> 

    > Devices and their end-users that desire address privacy are unlikely to
    > have long lived connections.

    > Can you provide an example of a common long lived connection that would
    > occur with a laptop or smartphone? I can't think of one.

Maybe you could ask the question differently;

_Can you provide an example of a common long lived connection that would
 occur with an Android or Linux based wireless device?_

(Yes, I've just excluded Apple iOS, because AFAIK, there are no iOS based IoT
devices other than smartphones)

So, let me give you my list now:
1) Point of Sale tablet in store (iPad or Android)
2) (smart)TV for use in the living room
3) (smart)TV used as screen for security system
4) Laptop at home with SSH connection, or VPN to office. (Networks are fast
   enough/low-enough latency today to do X-windows over SSH across town)
5) Billions of IoT devices using MQTT.
6) NFS, SSHFS
7) All the HTTP/1.1 stuff using push notifications, for devices that don't
   leave the home: Smart Fridge, kids tablet, reading tablet, 

Do these devices benefit from the privacy that temporary addresses provide?
That's a different question.  Have most of these devices had to learn to
reconnect? Or to point it another way, have applications had to learn to make
up for a layer-3/4 which is was rendered unreliable by NAT44? yes. 
Is that well architected? No.

I would argue that we (Ubuntu,Android,etc.) have moved forward with temporary
addresses by default without enough work around the side.  Meanwhile, PLPTMU
is still not enabled by default, which I think is a significantly more
important thing.

    > Even back in the early 1990s, when fixed location desktops were the
    > main personal computing device, long lived client connections were
    > rare. If you wanted a reliable long lived connection for something, you
    > didn't use your desktop, you used the hosts/servers that were in
    > computer rooms protected by UPS.

I disagree.

In the 1990s my office desktop had long lived connections (logins, X-windows
sessions, even RDP sessions) that lived for weeks.  Between power
interruptions, or OS patches.  More the later actually, but this was the
1990s, so it wasn't automatic.

Yes, you are right, power failures are an annoyance, especially when it's 90
seconds every Sunday night at 5pm {I'm looking at you UQO.ca}, but a $80 UPS
solved that.

I stopped lugging a laptop around around in 2010, opting for a desktop system
(with many monitors and ergonomic keyboard) at each major location,
plus... well.. Internet.   I tried no-laptop (tablet only), but projecting
slides at IETF was one of the pain points, and I now have a capable laptop,
but it's not my, as you said, my primary location.  The desktop at the office
with UPS is.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [