Re: the race to the bottom problem

Nick Hilliard <nick@foobar.org> Sun, 08 November 2020 16:36 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 48C893A0D47 for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 08:36:01 -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 LoTHxr3BZsc3 for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 08:35:59 -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 E56793A0D43 for <ipv6@ietf.org>; Sun, 8 Nov 2020 08:35:58 -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 0A8GZtqW070722 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2020 16:35:55 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: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: IPv6 List <ipv6@ietf.org>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <9A9CE8E7-3552-4FD8-A50E-1BDCA2CB813F@employees.org> <CABNhwV0LxM7EuKo2wNtVacjewsVqdhrmSiVBmB_EL-mqJYdU3A@mail.gmail.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>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <0c5df976-6c19-8763-adc7-8bf08a0aa1ba@foobar.org>
Date: Sun, 08 Nov 2020 16:35:53 +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: <b7c7f31c-825d-2a8e-4857-3526639649c4@joelhalpern.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/FprdcpgyfoSR3hLt7MtZe4dbmZA>
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 16:36:01 -0000

Joel M. Halpern wrote on 08/11/2020 00:00:
> I am not sure what data you are looking for Nick.

honestly, I'm not sure that any useful data even exists which suggests 
that right now, this entire "race to the bottom" discussion is an 
echo-chamber affair.  As Barbara points out (correctly, imo), the entire 
discussion is based on FUD and it's about time that this working group 
acknowledged this.

> History does tell us that ISPs give out very long prefixes even when 
> they do not need to.

Addressing scarcity has been an issue since before we had functional or 
widespread access services.  Also, provisioning mechanisms in the early 
days of access services were bereft of functionality, which meant that 
doing anything other than a single ipv4 statically-assigned /32 was 
troublesome and non-scalable.

There's never been a period where commodity ipv4 access products were 
available and where ipv4 addresses weren't a scarce resource, and 
scarcity has been the primary driver of addressing assignment policies 
since commodification of internet access services.  So this line of 
argument is not valid because there isn't a scarcity of ipv6 addressing 
resources.

Nick