Re: 64share v2 Tue, 10 November 2020 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 688283A0DDB for <>; Tue, 10 Nov 2020 10:04:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qwpQn0_xvKdR for <>; Tue, 10 Nov 2020 10:04:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FA603A0DB5 for <>; Tue, 10 Nov 2020 10:04:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9E3A54E11AE5; Tue, 10 Nov 2020 18:04:55 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3E8E343BB6FB; Tue, 10 Nov 2020 19:04:53 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: 64share v2
In-Reply-To: <>
Date: Tue, 10 Nov 2020 19:04:53 +0100
Cc: 6man WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Ca By <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Nov 2020 18:04:57 -0000


> > From what the operators have said, using the existing infrastructure for RA/SLAAC is important.  They have not needed DHCPv6.  So they want to be able to offer this using the tools they have deployed.  That seems reasonable to me.  Creating a new protocol for this would seem even worse.
> Then you must have missed the point I made earlier.
> What operators find attractive about the RA hack is a deployment model where the user's delegated prefix is taken out of a dynamic pool local to the box.
> That deployment model results in ephemeral addresses. Which might work in an environment with tethering today (a client-only stub network, where user is expected to press refresh often). But it is not obvious how scaling that hack to multiple links/routers is possible. Without a massive cost to the rest of the ecosystem.
> Ole,
> Your understanding is correct.


> I believe this thread saw several reports that prefixes in the home are commonly ephemeral, sometimes on purpose, so this is not new .  It is also consistent to my user experience with multiple large USA broadband providers.  Reports from around the world confirm similar, see draft-ietf-v6ops-slaac-renum-05.  Do you believe there is a new risk here that is not yet commonly seen ?

The slaac-renum documents describe only a small subset of the problems that ephemeral addressing causes.

> If you would like to provide some brief cautionary text for the I-D, I would be happy to include it, so that implementers are not under any false impressions.  Perhaps reference to draft-ietf-v6ops-slaac-renum-05   would be sufficient.  That said, like many I-Ds, this one has trade-offs.  

It isn't as much an implementation problem (implementation of this is easy) it's the operational problems caused by this (operations in the end-user networks).

Is it not irresponsible to specify a mechanism that we know will cause massive pain for host stacks, applications etc, if we were to properly fix the problem properly, or a miserably functioning network for the end-users if we didn't.

Feel free to tell me I'm wrong, and how networks are supposed to work with ephemeral addressing.

Best regards,