Re: 64share v2

"Joel M. Halpern" <> Tue, 10 November 2020 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B8513A0D93 for <>; Tue, 10 Nov 2020 09:41:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4FKfkzXTRcjg for <>; Tue, 10 Nov 2020 09:41:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E11E3A0D8E for <>; Tue, 10 Nov 2020 09:41:27 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CVwCB6JH8z1nvFK; Tue, 10 Nov 2020 09:41:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1605030086; bh=JviPUzMsH/QF0htYeUj1Djvi6VPcMBF/6FfoSIYTbdM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jBOmbhbI65zS1sz9vKhTl3jM1R/f2XTjfkYLIUF9O99A/imzLLh1J4xth5JEW0ROG cwc1ZSI9YVxUIleq3v02Q+nQLbMZGwJ3WHCsog+ntwUwhu2mEvsaSeqEVjyPxic+m0 NPEiflEFbYDE8sSJomgDNcojnT999nirX8nFNMnU=
X-Quarantine-ID: <Uk7qkTZc3uTD>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4CVwCB1DHWz1nsT7; Tue, 10 Nov 2020 09:41:25 -0800 (PST)
Subject: Re: 64share v2
Cc: 6man WG <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Tue, 10 Nov 2020 12:41:25 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 17:41:28 -0000

Ole, that problem statement is not how I understand Cameron's 
description to this list.

On 11/10/2020 11:53 AM, wrote:
>>  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.
> We already have a protocol so no need for a new one.
> Cheers,
> Ole