Re: Disabling temporary addresses by default?

Fred Baker <fredbaker.ietf@gmail.com> Tue, 28 January 2020 17:44 UTC

Return-Path: <fredbaker.ietf@gmail.com>
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 EB7491200E6 for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 09:44:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.336
X-Spam-Level: *
X-Spam-Status: No, score=1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Cq41Z2kXD440 for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 09:44:42 -0800 (PST)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79D71200B7 for <ipv6@ietf.org>; Tue, 28 Jan 2020 09:44:41 -0800 (PST)
Received: by mail-pj1-x102b.google.com with SMTP id a6so1353523pjh.2 for <ipv6@ietf.org>; Tue, 28 Jan 2020 09:44:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=W3NfFqHm2FZWiJTKeZMiu6eJQCvj0py0uHnZivXYzE4=; b=Yq4ISklT8dgitOxW6l3EZ1EORyfsz9OglDp+0IkZ8weIPT7Tsle2tToQNzUIy6FnVe aLqUqhnvNVA+xs++kCMao01AuJB6+m4KSh5EAC9dToE64/BuOo3SdaoZEz0PgIHWbQni DMx9IHAygZQp/ycm+hrWlO3WaUbmyUk5QSs+QkuZkdGPzjhEu9MOqH1u236z9uW+LMSJ 7iKzH/AabOYLOCXquhoXt1xgyO2TzQWpnBxPA6su8WNuGdi+b5aTRtzjhiqLpzQy7L04 nGOx7UFdUK31mX0uMUHnnEstUYBG3Bi58pEWfyLIggAmDXxIf0IbwyQyIwFYub+uLOzP hEug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=W3NfFqHm2FZWiJTKeZMiu6eJQCvj0py0uHnZivXYzE4=; b=UAoOALpxmBWxPBQ+P7yAnKHFj+6zew6GbEj63TkwF8mWv2rKmAEqANtRce4Y52QQp9 5IbbTUoILLDgVZyjBQOjwVJArTnroV+5noy/zp9sH3Q3ASHi2bcld92nBJNbQIPvuR2r uw8FsxLT0Yptc+tCP5Nc8Or0ZAsTPOTVf1aRcwsYwpsUNfK98lRdlv9rbwmjOvxuuWzM W7+i6pmUG2RkBoDHBMkQU3z3tI63IH8uEnz9lIYSb7ys04ZVTWeH9FDgedJzY2RlPkGp 7Y1bYiRa7p/J8hyBlSiE9Mrc307RdgZlcZVPEDl0kfLArzVBU/ddFrw6ILaIrtJ90Y5d vQ6Q==
X-Gm-Message-State: APjAAAV374xo1t4HOrmOnyowMNQE4Mvxg8WVYG4NwxyoW6VEiddsRIEr QLJgb3m2Hqr1EdYDmBff1pI=
X-Google-Smtp-Source: APXvYqzD1AfH+rLceJ5dJjiuXR/WGS0vo5NM4HDxKJQH1gXsOT/jnsptXNwm1PXYJuAgOsaNy4SkwQ==
X-Received: by 2002:a17:90a:17c2:: with SMTP id q60mr5734303pja.111.1580233481225; Tue, 28 Jan 2020 09:44:41 -0800 (PST)
Received: from [172.20.3.120] (rrcs-74-87-33-234.west.biz.rr.com. [74.87.33.234]) by smtp.gmail.com with ESMTPSA id x11sm14007328pfd.168.2020.01.28.09.44.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jan 2020 09:44:40 -0800 (PST)
From: Fred Baker <fredbaker.ietf@gmail.com>
Message-Id: <BC310B79-A05D-4889-9CE9-E62823335E9B@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E7FE1D69-E995-44F0-AF4A-21AFCA75EAD5"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: Disabling temporary addresses by default?
Date: Tue, 28 Jan 2020 09:44:39 -0800
In-Reply-To: <CAKD1Yr11_SSUkCBuQ3-h+eRg0LPZQdhe+h7f0YZy9TiyRWj6mw@mail.gmail.com>
Cc: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <DE7B0688-230F-4A5C-8E24-9EAED9FD9FEB@puck.nether.net> <AFEBAD7D-DF24-4924-8B9A-60DF22BA1953@consulintel.es> <c42affce-fbd3-23ec-c9ff-4f05cdf38630@si6networks.com> <41173152-A8E8-4241-9DE7-376AA7AFB813@consulintel.es> <c4166907-b6c9-a4ef-fd59-cf539bbe0405@si6networks.com> <43D76C96-C16B-4BEB-B9B8-C68D53BCE63F@fugue.com> <fb5b8377-892d-2777-ef9b-4f9ddefa6c93@si6networks.com> <CAKD1Yr034_tu7ZoJ1FCfDYhNSN6igm-ZQyR4u3U+UDMr=huGOw@mail.gmail.com> <1af0b06d-f9d7-5ea1-27f3-b417eb9148fa@si6networks.com> <7606A049-318D-4526-917D-F2A801BF7050@cisco.com> <CAKD1Yr1d9kORFdoOJr22J_UDJ9hLPr6AQLyWuh7=bAQKa+aXGw@mail.gmail.com> <MN2PR11MB356588FC3E8A6410B725D159D80A0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAKD1Yr35meRGh_POo_2jrHA_oazO1xUOG5G_rx43xNLFYHQsMQ@mail.gmail.com> <MN2PR11MB356526F01CAE1CADEF8E4472D80A0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAKD1Yr0-rmyzz3y1d+pCpA0+tGuhSdjojaJovXUzVuyx6UdeLA@mail.gmail.com> <98179a48-8d86-4673-6c82-fc0022988862@foobar.org> <F84FEFAF-1F78-47D4-B3E0-981DCFD0CB58@employees.org> <CAKD1Yr11_SSUkCBuQ3-h+eRg0LPZQdhe+h7f0YZy9TiyRWj6mw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KJb0QQlPv9uNkjuihC5HJX00ElA>
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: Tue, 28 Jan 2020 17:44:43 -0000

+1 on this. We can discuss whether a temporary address should have a limited lifetime or whether a given interface might have at most some number of temporary addresses at any given time, but to say that in the default (e.g., usual) case each system has zero seems like a bad idea.

> On Jan 28, 2020, at 6:59 AM, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:
> 
> Changing subject because many participants are likely to just ignore yet another "SLAAC vs DHCPv6" thread. :-)
> 
> On Tue, Jan 28, 2020 at 11:27 PM <otroan@employees.org> wrote:
> In the context of 4941bis last call, it might be prudent of us to revisit this change:
> 
> https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-05#section-8
> 6.  Temporary addresses are *not* disabled by default.
> 
> Saying that temporary addresses should be disabled by default (assuming hosts actually do that) seems like a terrible privacy problem. It means that by default, a host that doesn't change prefix will use the same IPv6 address to communicate with *everyone* on the internet until the end of time. That provides lots of opportunities for cross-site tracking, and the user can do very little to protect themselves because they don't have control over IP addressing like they do over higher-layer identifiers (e.g., users can clear cookies, or use different browser profiles or different browsers/apps for different sites).
> 
> I don't think 4191bis should advance if it says that privacy addresses are disabled by default. It would be a strong statement by the IETF that we don't care about privacy of IP addresses and would be a terrible signal to send.
> 
> Instead of disabling, why not change the default of the number of addresses maintained? For example, instead of maintaining 1 permanent + 1 valid + 7 deprecated, why not just default to maintaining 1 permanent + 1 valid + 1 deprecated. That means that applications would have to re-establish their connections once a day instead of once every 7 days. But if they use privacy addresses, they already need to re-establish connections after 7 days. And they can always use not to use privacy addresses via the appropriate socket option.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------