Re: Disabling temporary addresses by default?

Bob Hinden <bob.hinden@gmail.com> Tue, 28 January 2020 21:36 UTC

Return-Path: <bob.hinden@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 CFDAB1200A3 for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 13:36:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 LVodasguXCrT for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 13:35:59 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 2E54012001B for <ipv6@ietf.org>; Tue, 28 Jan 2020 13:35:59 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id b6so17852639wrq.0 for <ipv6@ietf.org>; Tue, 28 Jan 2020 13:35:59 -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=Uoyy8FSYfbdtioliK5Y8H3elb8ISA2aaBGvbIaS18aU=; b=TlARAqKzr9zfTw5k9+YWX1cKVAeFRcaPzbrrZkSbIkoCC3Uqu7QmhRB1E+Z4/pUfIX Mc05PreweMEdWMwUuOV8Nd3AjEOaoMNzNbIHRY1+g9r7YYmCJGxJveQNaUy0tSlI5LxE tzuvikw4NV5o3V3si897BjqP82fFoo853cVQvi81dcTfnUw2qNt84f9h1WFMCRH5sCT0 rbxoJavOXrX69h2Kqld44pGF++1eccXPGUwNmQNtHRChxRlAXhbby7t+3AS0JnN/D8ul gf+I3jHTidOaY9Gz3vq6OGOOvXeq8UAPFSilqAb/Qd113mR8SzgoN8BS+Mk1cpG5gb9x Dw3g==
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=Uoyy8FSYfbdtioliK5Y8H3elb8ISA2aaBGvbIaS18aU=; b=XkqyG7oJCv014xEMwaHl9IZFdiniYpiJGkSI5CSlZNhF88FUH5zcVQb60D8HJod51z N66c3AmWifGosbf0UqgSX3NGpdVX1DvU+IhLKaokYw4Ugf4kEhJSjjkDWObTL+lVGjGN QK6Fe7Ns8U+hmJMKHaKyU5UOm4xLGuX///uSYIthWq0RaQ6cdw3J69Bk2Inz1vAm+xAI TksbiSxdWnIa2QwFXNvCaKfIVyMmaeUoB5NgDAvBIZHMOhRzl2OysYHSHTByksizq3pZ P01AIq/PtPPCx1gplCFGDhvnSygrAwS/byDu09AkPvYgT6O4stOd93ESbVZnGoHGpzvY 4sqw==
X-Gm-Message-State: APjAAAXUViMEo563TnyNbhJ0y3RHOugKhiSgi0ps1FMvfDrxmGvh8th3 eIxu9UHZO9YSSEf3JFO3Ktk=
X-Google-Smtp-Source: APXvYqy1dMl2SrCm5KqnpuOTLwG2WOdcCzuM6knbAndGn7if2OGwbWiLUobyxHUcSKGsEtDj1ZSwhA==
X-Received: by 2002:a5d:62d0:: with SMTP id o16mr30690933wrv.197.1580247357401; Tue, 28 Jan 2020 13:35:57 -0800 (PST)
Received: from ?IPv6:2601:647:5a00:ef0b:1057:8694:1a3:8609? ([2601:647:5a00:ef0b:1057:8694:1a3:8609]) by smtp.gmail.com with ESMTPSA id b16sm4561098wmj.39.2020.01.28.13.35.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jan 2020 13:35:56 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <1F1CE807-5466-42B3-AA37-8C916EAB545C@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E6B52610-0E96-4159-AF9F-DD2DDFD4D163"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: Disabling temporary addresses by default?
Date: Tue, 28 Jan 2020 13:35:52 -0800
In-Reply-To: <CAKD1Yr11_SSUkCBuQ3-h+eRg0LPZQdhe+h7f0YZy9TiyRWj6mw@mail.gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Ole Trøan <otroan@employees.org>, IPv6 List <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.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1Qms9Xei4TEDjLYvbZzwA2kQYC8>
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 21:36:02 -0000


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

I agree.

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

If the concern with privacy addresses is that a node might have a large number of these addresses, then this seems reasonable to me.

Bob