Re: 64share v2

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Tue, 10 November 2020 22:23 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
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 2356E3A113B for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 14:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 BfakTiJIdaly for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 14:23:35 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D21E3A1139 for <ipv6@ietf.org>; Tue, 10 Nov 2020 14:23:33 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kcc2t-0000KnC; Tue, 10 Nov 2020 23:23:23 +0100
Message-Id: <m1kcc2t-0000KnC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: 64share v2
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <CAD6AjGR-NE_sJ_jp7nAT6OvNkcdE9qoWuGEiiVW7r9YtsQvbbw@mail.gmail.com> <CAKD1Yr0G8PjzE+pULte_AaOi=RHMLyto-YUQerGjQ=iOYnz+iA@mail.gmail.com> <0986B112-2159-4045-87F9-876B58F1D896@employees.org> <CAKD1Yr0h9=7p+n=qnH1o1EHqtPrsaYebgvHciOJpP3=iXgNgKQ@mail.gmail.com> <0C739112-D8EA-42C3-BEFD-88C014D5BCD0@employees.org> <62bc0e56-85b8-42ea-c46b-4f2205dc435f@joelhalpern.com> <28C2E56B-1443-480A-B3D1-82E0F8CC0EC7@employees.org> <aabd41ad-1770-f2ac-77d6-62bfff1992c0@joelhalpern.com> <CC7C2B94-5A05-4682-8367-9072CC201C49@employees.org> <80ed3a3b-6e2c-188f-4c1e-c2ededfbbe0d@joelhalpern.com> <0188AC41-60B0-4BC6-810D-DC59CF9E4FB3@employees.org> <1931a638-64ed-f40e-07a3-67cf1eafb941@joelhalpern.com> <376D6BB0-87E2-42E5-9BC4-F3A2F04FA005@employees.org> <CAD6AjGSr-TPcGo7f9EGgoAahYLQTL68CUSq58LGMgD0=6GmRRg@mail.gmail.com> <8DC674FB-9F90-4C41-A323-62BD62934A12@employees.org>
In-reply-to: Your message of "Tue, 10 Nov 2020 19:04:53 +0100 ." <8DC674FB-9F90-4C41-A323-62BD62934A12@employees.org>
Date: Tue, 10 Nov 2020 23:23:22 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8RhitTBguVsQ_oj8oDarbOK1CiY>
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, 10 Nov 2020 22:23:37 -0000

>how networks are supposed to work with ephemeral addressing.

This is a good question, but it seems to be one that we need to solve.

If I start with your proposal to only have point-to-point ethernet links,
then I still want devices that behave like the current ethernet switches
we have everywhere.

So, I need to be able to connect such a device anywhere in the network and it
should work. The device should automatically find out which are upstream
and downstream links, obtain a /64 for each downstream link.

When another switch shows up on a downstream link it should be able to provide
the downstream switch with enough /64s.

I should be able to disconnect cables and reconnect them else where in the 
network.

I.e. it is nice to have static prefixes and long lease times. However the
reality is that links come and go. 

DHCPv4 created the model that you get a lease and nothing will change until
the lease expires. DHCPv6 introduced ways to inform clients of changes, but
I don't think it has seen much use. RAs constantly update hosts, but as we
have seen in the renum drafts we need to explictly invalidate old stuff. 

So we need to figure out how to invalidate stuff, in particular, if a link goes
down, how to invalidate what we learned from that link.