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

Fernando Gont <fgont@si6networks.com> Thu, 12 November 2020 16:07 UTC

Return-Path: <fgont@si6networks.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 2999E3A13E6 for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 08:07:24 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 keLffXzQeIgw for <ipv6@ietfa.amsl.com>; Thu, 12 Nov 2020 08:07:22 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955B23A13BE for <ipv6@ietf.org>; Thu, 12 Nov 2020 08:07:19 -0800 (PST)
Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A8572283B70; Thu, 12 Nov 2020 16:07:16 +0000 (UTC)
Subject: Re: Ephemeral addressing [was Re: 64share v2]
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Ole Troan <otroan@employees.org>
Cc: 6man WG <ipv6@ietf.org>
References: <CAD6AjGR-NE_sJ_jp7nAT6OvNkcdE9qoWuGEiiVW7r9YtsQvbbw@mail.gmail.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> <F39272F7-EBCC-4551-BB42-4014DD437302@employees.org> <CAKD1Yr3xe2MMFR+vy4_7HABEfVRMjGX+6W0CrsxzBNmnFgpz+w@mail.gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <57f29db7-2811-8c0f-28dd-4f5f43bf59cc@si6networks.com>
Date: Thu, 12 Nov 2020 13:06:37 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr3xe2MMFR+vy4_7HABEfVRMjGX+6W0CrsxzBNmnFgpz+w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6wD2ynmQ2NzJtfofPQemKt8w3Bk>
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: Thu, 12 Nov 2020 16:07:29 -0000

On 11/11/20 10:55, Lorenzo Colitti wrote:
> QUIC supports connection migration. See for example this draft:
> 
> https://tools.ietf.org/html/draft-tan-quic-connection-migration-00
> 
> In hindsight, the real reason mobility is hard is that TCP does not 
> provide its own session identifier and instead relies on the lower-level 
> identifiers (i.e., IP addresses) to identify its connections. 

Indeed, TCP checksuming the network attachment point (IP address) rules 
out mobility.

THe approach (mobile IP) of trying to make addresses (a 
location-dependent identifier) mobile (hence "location-independent") 
doesn't seem to be the best one.

And yes, given what we have, it would seem dealing with it at transport 
is what's feasible and deployable.

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492