Re: the race to the bottom problem

otroan@employees.org Tue, 10 November 2020 09:49 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 0F0A43A0E5D for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 01:49:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BJ9hQHHkCVDj for <ipv6@ietfa.amsl.com>; Tue, 10 Nov 2020 01:49: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 980E63A0E57 for <ipv6@ietf.org>; Tue, 10 Nov 2020 01:49:44 -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 77F714E11B1C; Tue, 10 Nov 2020 09:49:43 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 5544C43AE2DA; Tue, 10 Nov 2020 10:49:41 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: the race to the bottom problem
From: otroan@employees.org
In-Reply-To: <CAD6AjGSpoaxDTmZDE8aG30ReZj4JrY7evDr8xJ_MxuzmGjnh0A@mail.gmail.com>
Date: Tue, 10 Nov 2020 10:49:41 +0100
Cc: 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CC4F27A-9E4E-440D-A36F-63F327A42635@employees.org>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <9e787ed0-a221-e413-e030-ac2553dffc8e@gmail.com> <a21c9447-730b-e2c0-81f6-46deda57f507@gmail.com> <f4635fa9-45ca-f7ec-40a2-41764e1ca74f@si6networks.com> <905bcc26-a223-53d0-6675-c35579b9a8be@gmail.com> <AAE75F7F-F8DF-4B7F-9C50-3D6C91544997@ciena.com> <2b59b2de-3597-8d35-374d-75e9b10d4d83@gmail.com> <CAO42Z2zUvDE2ZSCnZa_525Hj7OthhEoDGZcd0D9xxZVW3D8aeg@mail.gmail.com> <CAKD1Yr1yiXR43mL45KbsZkKY7_YVhWFzW82LL6qed6mVPBjxaw@mail.gmail.com> <E87C175C-C06D-485E-B790-6BC3DB48F101@gmail.com> <3daa3475-68f8-88e0-9fc4-77a58c074fbf@foobar.org> <CAO42Z2zictx_PykbVUqfvODhQwztw47apAnOPjkncRSdqJBLPQ@mail.gmail.com> <e197fdca-2dc6-340b-bd4f-03b89ecc15e9@foobar.org> <b7c7f31c-825d-2a8e-4857-3526639649c4@joelhalpern.com> <CAD6AjGTwPMbW1=SBCsSj15CA5BJY30JFsJoTpAgFYqDJrbUwYA@mail.gmail.com> <CAO42Z2yduTRL8cAxGKmmFocxQpKdkxcThhepTyprmWtV6MS_+g@mail.gmail.com> <CAD6AjGRL=Fb+ef1F5YDiKTG5KAFiWVRn-5vY06o4AEpmoKD-Mw@mail.gmail.com> <97d7ab73-501e-3d0e-6db9-a5cbc2588fa7@joelhalpern.com> <CAD6AjGTSmh-FePbGZU76CVU+Bcei0_S937LyWGtEiAHqASi0yQ@mail.gmail.com> <8A37B0BE-9F56-495B-8F3D-8E959603A434@employees.org> <CAD6AjGSpoaxDTmZDE8aG30ReZj4JrY7evDr8xJ_MxuzmGjnh0A@mail.gmail.com>
To: Ca By <cb.list6@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vc0zs8GNaRFrpn0q8-ETp0mPZZo>
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 09:49:46 -0000

> > RA prefix information can be set to any number between 0 and 128 
> > 
> > But, 3gpp enshrined it to be 64
> > 
> > https://tools.ietf.org/html/rfc6459#section-5.2
> > 
> > Let’s change and and make it so the UE to slice up a prefix into multiple downstream /64s
> 
> I suspect you find the RA mechanism which assigns prefixes to a link simpler to use because that configuration information is tied to the lifetime of that particular link.
> That premise does not hold when you are delegating address space to a network behind that link.
> 
> If you were taking that approach, it would imply ephemeral addressing and flash renumbering.
> 
> Yes, that is the case of the deployment today. I am simply looking to give < 64 instead of = 64, that is an improvement that is achievable 

If your "yes" was to "ephemeral addressing"...
Not saying we shouldn't do it. But that has massive ramifications for all applications.

It moves IP mobility to the transport or application layer. And would require something like MP-TCP or a new session layer.

I'm also unsure if the network configuration protocols HNCP and ND would work.
You would essentially get renumbered any time the cellular connection to the network flap, right? ;-)

Best regards,
Ole