Re: the race to the bottom problem

Nick Hilliard <nick@foobar.org> Sun, 08 November 2020 18:21 UTC

Return-Path: <nick@foobar.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 1E1A13A03AA for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 10:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 Fw_bi1KIpK09 for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 10:21:31 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2F33A0365 for <ipv6@ietf.org>; Sun, 8 Nov 2020 10:21:31 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.16.1/8.16.1) with ESMTPSA id 0A8ILOex084493 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2020 18:21:25 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
Subject: Re: the race to the bottom problem
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: IPv6 List <ipv6@ietf.org>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <CD9F9F09-2CBC-4A72-99C0-4A9A470357ED@employees.org> <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> <8ef560cf-e256-7590-6090-5291f0256d26@gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <9dd5af26-4093-b131-7300-c78b9258da2b@foobar.org>
Date: Sun, 08 Nov 2020 18:21:23 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.36
MIME-Version: 1.0
In-Reply-To: <8ef560cf-e256-7590-6090-5291f0256d26@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BUTMSVoo3eV6XHJ2TJul7WDGsUA>
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 18:21:34 -0000

Brian E Carpenter wrote on 08/11/2020 01:38:
> If that is true, why on Earth does 3GPP still ration each PDP context
> to one /64? That is for sure not the IETF's fault. We've told them
> and told them.

Sure, but different access technologies use different deployment models.

Unfortunately, any time this discussion happens on 6man or v6ops, 
generalisations are made about the entire ipv6 networking ecosystem 
based on speculation about perceived worst-case situations in specific 
networking models, often cellular / mobile.

There's more to ipv6 than service provider access models, and there's 
more to ipv6 service provider access models than just cellular.  We 
should not accept as a working group that discussion about /64 is 
consistently driven into the ditch because people consistently steer the 
discussion in the direction of some specific access technology models 
and then make unsubstantiated claims relating to those models.  6man 
needs to move past this.

Nick