Re: 64share v2

"Joel M. Halpern" <> Tue, 10 November 2020 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 261B93A0408 for <>; Tue, 10 Nov 2020 07:46:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 X3beuWyrZjiC for <>; Tue, 10 Nov 2020 07:46:25 -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 58EE43A03F8 for <>; Tue, 10 Nov 2020 07:46:25 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CVsfT1kVvz1ntn3; Tue, 10 Nov 2020 07:46:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1605023185; bh=zN+ddnSu/8Q4F5wMFOJQIvLrDzi1+pFWzEY4BHtC7FI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mszflRONQQEjfbfRYR9Toe1ubpQsLY/SUlGQXbHEX9LenDsqavobtf/KOa10HJpDY b97lOSgtZvusK6mUK9mCx4NpWJ5zl04qTqkL+Ky7kFh1Bq63Gx8kHzQPaccxsPOoFs ikxxe1QfefqzEZ2+R/IQCKz5vc+zpf9D4SpW5om0=
X-Quarantine-ID: <7_TY_vgeauTN>
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 4CVsfS571jz1ntZF; Tue, 10 Nov 2020 07:46:24 -0800 (PST)
Subject: Re: 64share v2
Cc: 6man WG <>
References: <> <> <> <> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Tue, 10 Nov 2020 10:46:24 -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 15:46:26 -0000

So we add a bit (as the earlier proposal did) to make clear that the 
intent in this case is to make the prefix available to the recipient. 
Over this pt-to-pt link.


On 11/10/2020 10:38 AM, wrote:
> Joel,
>> Ole, I do not understand what you are asking.
>> network A is allocating to rotuer B over a point-to-point link a prefix.  (The router might be a 3GPP UE.  It might be a fixed wireless RG. Doesn't matter.)
>> If there is a network behind B, the B can use that prefix for that network.  Obviously, if it is multi-hop network and we want to get multiple levels of allocation, then other tools are needed.  That was the homenet problem.
>> This approach does not claim to solve the whole homenet problem.  It solves a simple and common problem.
> In the 64share solution the prefix is assigned to the _link_ between then PE and the CE.
> The CE steals that prefix and assigns it to downstream interfaces.
> In PD the prefix is delegated (as in the authority of the prefix changes) to the CE.
> Do you understand the difference? And the implications of that difference?
> I.e. that prefix lifetime is limited to the lifetime of the connection.
> Again, we do not know how to operate networks with rapidly changing addresses.
> Cheers,
> Ole