Re: Disabling temporary addresses by default?

Richard Patterson <richard@helix.net.nz> Tue, 28 January 2020 15:14 UTC

Return-Path: <richard@helix.net.nz>
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 228FB120124 for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 07:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.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 9WrjSrLficEC for <ipv6@ietfa.amsl.com>; Tue, 28 Jan 2020 07:14:24 -0800 (PST)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 754C712012A for <ipv6@ietf.org>; Tue, 28 Jan 2020 07:14:24 -0800 (PST)
Received: by mail-il1-x12a.google.com with SMTP id t17so10878761ilm.13 for <ipv6@ietf.org>; Tue, 28 Jan 2020 07:14:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=brjlBreBdbL8LBW/WN6Jp0GCudShqmOyAr0gZhnuaJg=; b=RNPctLHnDrXLTjLTyLB+7bP68EZMBMBK2jW+sNMV0IOkwBD0NJRiPxEDjYq2r69N1b /PTNFtMIfKnZPuXjjS2u6eydHLg1TWEQRIFYbW1qI/RwYd09Huj1tCMUHnLjzc+uB/m9 J8yJmBDjsskTt4Tryg9vuXcmnKPaJoQSrPjZDSzi4llcTWCYzySurdpJUgJ+TNxvYbIa Ce1qVYXL431JyNbx77auVykAwrh9mg3PQViSe6fZNGuIvgS3+WluoCow7UWZ0ov9v7RO lIIUjylKqCga64U6RmXAHNkzxENIP2Ntb3R3YPvaJylNx0Buf9uamSMopgHX9T/XJSvr QgrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=brjlBreBdbL8LBW/WN6Jp0GCudShqmOyAr0gZhnuaJg=; b=fzbpeHLW3nq6DQrCg05coW2WGf/cXvu2YuBwbg1QpTQDacvO8A1YySWxqPx8PdoTdO ssebaS4Sx3Xrp/vg8fHl7kgCOuYwfO49Mj3lqlTfK4KEFULzlrkTe6EWBu3a5Xo3w5sR Gnsv6H7QvYLviQ2GxO8vvfAzlxJB2LLk0mmePfpejIvTAP/OJP3kdT02CwRC3bQlFRp+ v8s/+8sn3jnH6FMITLvWjy4YiiAF8C2apD/XVQ/2qTq4nl+OQ8XAezWhMKql9NxW3BQx 3XfWFIiyqFVhIsz0OjheMe26TzIz+6ZvVjyH6NEqOaWOfTRyNWZFHpVqoUwWdhMJxO+e J1iw==
X-Gm-Message-State: APjAAAUkl3LK3fuKaUukUokohznbX6jEIZ/gH3UNvC9Rby6JDP88IkfC gzSfdSmpG4PVQhswLRhVJCRIe8EUoNfOng==
X-Google-Smtp-Source: APXvYqzR01vZ0mTrwEGQV+szBs+5fcOPVjx3SNqFiYtsKv2vk92kyFoqeUVQMsR/W7w4l7ITQ3DftA==
X-Received: by 2002:a92:d5cf:: with SMTP id d15mr19820476ilq.306.1580224463628; Tue, 28 Jan 2020 07:14:23 -0800 (PST)
Received: from mail-il1-f178.google.com (mail-il1-f178.google.com. [209.85.166.178]) by smtp.gmail.com with ESMTPSA id y11sm631098ilm.22.2020.01.28.07.14.23 for <ipv6@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jan 2020 07:14:23 -0800 (PST)
Received: by mail-il1-f178.google.com with SMTP id i7so7737791ilr.7 for <ipv6@ietf.org>; Tue, 28 Jan 2020 07:14:23 -0800 (PST)
X-Received: by 2002:a92:ca82:: with SMTP id t2mr20515488ilo.242.1580224462750; Tue, 28 Jan 2020 07:14:22 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <CAKD1Yr11_SSUkCBuQ3-h+eRg0LPZQdhe+h7f0YZy9TiyRWj6mw@mail.gmail.com>
From: Richard Patterson <richard@helix.net.nz>
Date: Tue, 28 Jan 2020 15:14:11 +0000
X-Gmail-Original-Message-ID: <CAHL_VyBzcZPpEpzNmaebVr=U_mBqaquA1YbWTDGD808eoBxvHA@mail.gmail.com>
Message-ID: <CAHL_VyBzcZPpEpzNmaebVr=U_mBqaquA1YbWTDGD808eoBxvHA@mail.gmail.com>
Subject: Re: Disabling temporary addresses by default?
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Cc: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c496c2059d34ad13"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tHUJG6FfEGGtfJ5yUYuxlHPcDz8>
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 15:14:27 -0000

On Tue, 28 Jan 2020 at 14:59, Lorenzo Colitti <lorenzo=
40google.com@dmarc.ietf.org> wrote:

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

So simply recommending that Valid Lifetime is no more than 2x Preferred
Lifetime?