Re: 64share v2

otroan@employees.org Tue, 10 November 2020 11:15 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 121493A047D for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 03:15:20 -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 3EZ2AuhBD8qn for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 03:15:19 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.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 31F9E3A0475 for <ipv6@ietf.org>; Tue, 10 Nov 2020 03:15:19 -0800 (PST)
Received: from astfgl.hanazo.no (201.51-175-101.customer.lyse.net [51.175.101.201]) (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 097E94E11B1C; Tue, 10 Nov 2020 11:15:15 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 7839043B0E13; Tue, 10 Nov 2020 12:15:12 +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: 64share v2
From: otroan@employees.org
In-Reply-To: <CAKD1Yr3Xr2t8yN40kmq6S+gSMPMDkm6cVXaVM+doW-xPo_BTrQ@mail.gmail.com>
Date: Tue, 10 Nov 2020 12:15:12 +0100
Cc: Ca By <cb.list6@gmail.com>, Erik Kline <ek@loon.com>, Mikael Abrahamsson <swmike@swm.pp.se>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <55A3AF63-83FF-4D1B-8B18-AD2E7C35E441@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> <CAKD1Yr3Xr2t8yN40kmq6S+gSMPMDkm6cVXaVM+doW-xPo_BTrQ@mail.gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/v8GobIc2MuWg2zWDzcm0_7f_8R8>
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 11:15:20 -0000

> > 3GPP networks do have this property. The PIO lifetime in the RA is set to infinite and the actual lifetime is the link lifetime. By and large that seems to work in practice :-) 
> 
> It works fine for the directly connected node. 
> Now please put a large network behind this link and tell me how that goes...
> 
> What problems do you see with this that aren't already addressed by existing RFC7278 implementations?

RFC7278 says:
"The LAN link RA configuration must be tightly
    coupled with the 3GPP link state.  If the 3GPP link goes down or
    changes the IPv6 prefix, that state should be reflected in the LAN
    link IPv6 configuration. "


In an arbitrary topology, i.e. with multiple routers and hosts.
Why do you do think this will work?

If the the RFC7278++ deploymenent model is one of ephemeral addressing, is the expectation that any time the cellular link flaps, the user should do the equivalent of a logical power reset of all devices? That would of course also assume those prefixes were not hard-coded in configuration files, DNS etc.

It is of course possible to provide long-lived prefixes also with this hack^H^H^H^Hmechanism. But that didn't seem like what Cameron was proposing.

Cheers,
Ole