Re: Ephemeral addressing [was Re: 64share v2]

otroan@employees.org Wed, 11 November 2020 13:35 UTC

Return-Path: <otroan@employees.org>
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 59F6C3A0869 for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 05:35:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDuLglG7pgBJ for <ipv6@ietfa.amsl.com>; Wed, 11 Nov 2020 05:35:44 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300B23A0D58 for <ipv6@ietf.org>; Wed, 11 Nov 2020 05:35:44 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:9724:43:9ead:7fe6:a65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 3A28A4E11A68; Wed, 11 Nov 2020 13:35:43 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 1ACD643CD0AB; Wed, 11 Nov 2020 14:35:40 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: Ephemeral addressing [was Re: 64share v2]
From: otroan@employees.org
In-Reply-To: <m1kcprv-0000GNC@stereo.hq.phicoh.net>
Date: Wed, 11 Nov 2020 14:35:39 +0100
Cc: 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F39272F7-EBCC-4551-BB42-4014DD437302@employees.org>
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> <CAD6AjGTYBs8YbHgCJJG84vgwXK4ZSCm65z6KXvZP9F+LdT_atg@mail.gmail.com> <038A830C-E024-42C6-917E-E6FF57829A1C@employees.org> <CAD6AjGTQVtJBJ3=aZBsF1WcdSK2k9b1hzeZXM6008w_2vpo6_w@mail.gmail.com> <948ACA2B-E45C-4289-A837-9F2536F20F8F@employees.org> <CAKD1Yr0tDTSH2F4=ZsdMJREy1k6equ9mZV0Au1bJPmKuzxeYVA@mail.gmail.com> <43C449AD-D116-4452-A4F2-79AE5A76539F@employees.org> <m1kcoXQ-0000G1C@stereo.hq.phicoh.net> <267D8461-47EC-443A-98DF-4FE990138B5A@employees.org> <m1kcprv-0000GNC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mzqvwjeGxIzCtqdUc0QHx1oRjlg>
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: Wed, 11 Nov 2020 13:35:45 -0000

Philip,

>> Let me rename this thread as this opens a much larger issue.  While
>> being able to rapidly reconfigure an end-user network using the
>> layer3 primitives in 6man, I don't think it's worth solving unless
>> also the upper layer problems are solved.  
>> - How do TCP connections
>> survive a renumbering event?
>> - How do applications get notified to
>> reconnect?
>> - Do all applications have to change as a result? Or
>> use a different transport layer?
>> - What happens with DNS configuration?
>> Are you assuming everyone has DNS-SD deployed and working?
>> - What
>> about other configuration? Static addresses for example?
>> 
>> Good luck I say...  Until then I suggest that we continue (to
>> pretend) that addresses must be long-lived.
> 
> My reality is that many addresses are short lived. Not because addresses
> on a single link change often, but because mobile devices regularly connect
> to new links.
> 
> Static addresses are similar to old unix systems where you have recompile
> the kernel and reboot for each new piece of hardware that gets added to a
> system. Modern systems were forced to evolve because users expect to 
> plug in USB devices, connect bluetooth devices, etc.
> 
> Does the world wait until the IETF solves renumbering? No. Just like the
> world switched to NAT long before the IETF recognized there was such a
> thing, most modern application deployments are essentially an overlay
> network.
> 
> Applications use https to connect to the cloud, session identifiers are 
> stored in cookies. Short sessions and short timeouts make renumber event
> transparent to the application.
> 
> Can TCP survive a renumber event? Yes, MPTCP should be able to that.
> 
> How do applications get notified. The IETF and the Open Group failed to 
> create APIs for that. So every OS creates its own ad-hoc mechanisms.
> 
> DNS support dynamic updates.
> 
> But what we do at the transport layer may not be relevant. So we can focus
> on making the network layer work. 
> 
> Or just stick to static prefixes.

Seems to me the world waited. At least the one I'm leaving in did. :-)
None of the systems I use handle renumbering. Barring a single application (mosh).
Most of the building blocks are there, but in 20 years of waiting few if any have put them together.
I doubt this is deployable in time to avoid users being forced to NAT on the edge, to protect themselves from instability in global addressing.

Are we going to restrict all future IPv6 end-user networks that are forced to depend on PA addressing to be client only?

Cheers,
Ole