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
- 64share v2 Ca By
- Re: 64share v2 Lorenzo Colitti
- Re: 64share v2 Mikael Abrahamsson
- Re: 64share v2 otroan
- Re: 64share v2 Mark Smith
- Re: 64share v2 Lorenzo Colitti
- Re: 64share v2 otroan
- Re: 64share v2 Lorenzo Colitti
- Re: 64share v2 otroan
- Re: 64share v2 Mikael Abrahamsson
- Re: 64share v2 otroan
- Re: 64share v2 Mikael Abrahamsson
- Re: 64share v2 Ca By
- Re: 64share v2 Joel M. Halpern
- Re: 64share v2 Ca By
- Re: 64share v2 Alexandre Petrescu
- Re: 64share v2 otroan
- Re: 64share v2 Joel M. Halpern
- Re: 64share v2 Ca By
- Re: 64share v2 Alexandre Petrescu
- Re: 64share v2 otroan
- Re: 64share v2 Joel M. Halpern
- Re: 64share v2 Alexandre Petrescu
- Re: 64share v2 Bob Hinden
- Re: 64share v2 otroan
- Re: 64share v2 Joel M. Halpern
- Re: 64share v2 otroan
- Re: 64share v2 Ca By
- Re: 64share v2 Joel M. Halpern
- Re: 64share v2 Joel Halpern
- Re: 64share v2 Alexandre Petrescu
- Re: 64share v2 otroan
- Re: 64share v2 Ca By
- Re: [SUSPECTED SPAM] 64share v2 otroan
- Re: [SUSPECTED SPAM] 64share v2 Ca By
- Re: 64share v2 Brian E Carpenter
- Re: 64share v2 Joel M. Halpern
- Re: 64share v2 Ca By
- Re: 64share v2 Philip Homburg
- Re: 64share v2 Brian E Carpenter
- Re: 64share v2 Ca By
- Re: 64share v2 Brian E Carpenter
- Re: 64share v2 Erik Kline
- Re: 64share v2 otroan
- Re: 64share v2 Lorenzo Colitti
- Re: 64share v2 Lorenzo Colitti
- Re: 64share v2 otroan
- Re: 64share v2 Alexandre Petrescu
- Re: 64share v2 Alexandre Petrescu
- Re: 64share v2 Philip Homburg
- Re: 64share v2 Mikael Abrahamsson
- Ephemeral addressing [was Re: 64share v2] otroan
- Re: 64share v2 otroan
- Re: 64share v2 Philip Homburg
- Re: 64share v2 Mikael Abrahamsson
- Re: 64share v2 Mikael Abrahamsson
- Re: 64share v2 Lorenzo Colitti
- Re: 64share v2 otroan
- RE: Ephemeral addressing [was Re: 64share v2] Vasilenko Eduard
- Re: 64share v2 Mikael Abrahamsson
- Re: Ephemeral addressing [was Re: 64share v2] Philip Homburg
- Re: 64share v2 Philip Homburg
- Re: 64share v2 Philip Homburg
- Re: 64share v2 Mikael Abrahamsson
- Re: 64share v2 Philip Homburg
- Re: Ephemeral addressing [was Re: 64share v2] otroan
- Re: 64share v2 Lorenzo Colitti
- Re: 64share v2 otroan
- Re: Ephemeral addressing [was Re: 64share v2] Lorenzo Colitti
- RE: 64share v2 Vasilenko Eduard
- Re: Ephemeral addressing [was Re: 64share v2] Philip Homburg
- Re: 64share v2 Philip Homburg
- Re: 64share v2 Alexandre Petrescu
- Re: 64share v2 Alexandre Petrescu
- Re: Ephemeral addressing [was Re: 64share v2] otroan
- Re: 64share v2 Brian E Carpenter
- Re: Ephemeral addressing [was Re: 64share v2] Brian E Carpenter
- Re: 64share v2 神明達哉
- Re: 64share v2 Brian E Carpenter
- Re: 64share v2 Lorenzo Colitti
- Re: 64share v2 Brian E Carpenter
- Re: 64share v2 Gyan Mishra
- Re: 64share v2 Alexandre Petrescu
- Re: 64share v2 Alexandre Petrescu
- Re: Ephemeral addressing [was Re: 64share v2] Philip Homburg
- Re: Ephemeral addressing [was Re: 64share v2] otroan
- Re: Ephemeral addressing [was Re: 64share v2] Philip Homburg
- Re: Ephemeral addressing [was Re: 64share v2] otroan
- Re: Ephemeral addressing [was Re: 64share v2] Philip Homburg
- Re: Ephemeral addressing [was Re: 64share v2] Fernando Gont
- Re: Ephemeral addressing [was Re: 64share v2] Fernando Gont
- Re: Ephemeral addressing [was Re: 64share v2] Fernando Gont
- Re: Ephemeral addressing [was Re: 64share v2] Fernando Gont
- Re: 64share v2 Brian E Carpenter
- Re: 64share v2 Alexandre Petrescu
- Re: 64share v2 Alexandre Petrescu