Re: the race to the bottom problem

otroan@employees.org Sun, 08 November 2020 09:55 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 DCEE23A1128 for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 01:55:47 -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 1HJAsOHRGHWY for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 01:55:46 -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 532CC3A1125 for <ipv6@ietf.org>; Sun, 8 Nov 2020 01:55:46 -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 567524E11B19; Sun, 8 Nov 2020 09:55:45 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id B0F08438707C; Sun, 8 Nov 2020 10:55:42 +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: <CAD6AjGTSmh-FePbGZU76CVU+Bcei0_S937LyWGtEiAHqASi0yQ@mail.gmail.com>
Date: Sun, 08 Nov 2020 10:55:42 +0100
Cc: 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A37B0BE-9F56-495B-8F3D-8E959603A434@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>
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/xigPMy63b6Oaqq5Z9kApmabEbR4>
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: Sun, 08 Nov 2020 09:55:48 -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.

Simple and cheap on the operator side likely implies complex and costly on the end-user side.
That might not be a good tradeoff. There are many more end-user sites than operators.

Best regards,
Ole