RE: 64share v2

Vasilenko Eduard <> Wed, 11 November 2020 14:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4419F3A0DCF for <>; Wed, 11 Nov 2020 06:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SJ0Ug7-bXupH for <>; Wed, 11 Nov 2020 06:04:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 049833A0DBD for <>; Wed, 11 Nov 2020 06:04:28 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4CWRJT5lzWz67DyD for <>; Wed, 11 Nov 2020 22:02:49 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 11 Nov 2020 15:04:25 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 11 Nov 2020 17:04:24 +0300
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Wed, 11 Nov 2020 17:04:24 +0300
From: Vasilenko Eduard <>
To: Lorenzo Colitti <>, Philip Homburg <>
CC: IETF IPv6 Mailing List <>
Subject: RE: 64share v2
Thread-Topic: 64share v2
Thread-Index: AQHWt/xBtAKXBQsyPUyv1auh5NWcm6nCbJ0AgAABSoCAAGI27P//z1UAgAAEfICAAAm5gIAAPT+V///Sa4CAADY8cA==
Date: Wed, 11 Nov 2020 14:04:24 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_b5de09234cd1412dbbff20e386b5920bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Wed, 11 Nov 2020 14:04:30 -0000

Under some rate of address changes
The post would fail to deliver the majority of messages.
Independent from how fast somebody would change plates on streets and buildings.
Physical location should have stable ID.
All changes are better to move into Overlay.

Is it possible for everything in the world to have Unique ID that would be used for Underlay? No UID – no communication.
The real learning would happen in opposite direction: client would tell what is his UID.
UID movement inside one carrier (or the set of properly interconnected carriers) would not disrupt connectivity.
Underlay should be limited by size (carriers could choose the limit), because it would be difficult to aggregate UID.
The real internet would happen in Overlay. Here logical address could be assigned in normal direction: from carrier.
From: ipv6 [] On Behalf Of Lorenzo Colitti
Sent: 11 ноября 2020 г. 16:37
To: Philip Homburg <>
Cc: IETF IPv6 Mailing List <>
Subject: Re: 64share v2

On Wed, Nov 11, 2020 at 10:19 PM Philip Homburg <<>> wrote:
>Do we really need to solve this problem in order to solve the problem of
>how to distribute the information? Or rather - do we need to solve the
>problems together, in the same draft?

We have a problem with DHCPv6 PD relays and soft state getting
lost. We have quite a few drafts related to RAs and renumbering.

I don't think that can really happen here because the option we're defining is explicitly for a point-to-point link. It's very unlikely that point-to-point links won't have some sort of liveness detection already. You know if your point-to-point link is up, right?

Maybe we should first figure out how it should work, before we specify
bits on the wire.

If you're talking about what should happen *downstream* of the device that receives the option ("recipient"), then it seems to me that that problem is almost completely independent of how the recipient gets the prefix, and is basically entirely between the recipient and its downstream devices. I mean - sure, we can decide that the option should or should not contain a timer, and per the above, I think we can assume that there is a link-layer signal that the recipient can use to determine that the option is no longer valid. But... once we've done that, I think the recipient has all the information we can possibly convey to it. The recipient will definitely know if its prefix is no longer valid if the link goes down.

Obviously, we still have the problem that downstream devices don't know what happened. But I don't see how we can fix that as part of defining the option. The only things we can do when defining the option are a) add more information to the option (but I don't see what we could add to make this better), or b) to say that the devices implementing the option should behave in some way. I don't think it's reasonable to mandate that behaviour on the sender of the option, because the recipient already has all the information it needs. So yes, in theory we could say that the recipient of the option must have some way to notify its downstream devices when the option is no longer valid. But I don't think that mechanism should be specified in this draft.