Re: the race to the bottom problem

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 09 November 2020 10:21 UTC

Return-Path: <swmike@swm.pp.se>
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 1255C3A0E05 for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 02:21:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 LqszroC0X5ZP for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 02:21:18 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C255F3A010A for <ipv6@ietf.org>; Mon, 9 Nov 2020 02:21:18 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0CACDB4; Mon, 9 Nov 2020 11:21:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1604917276; bh=qPF1SNX1HdkpnUwPDQGTJdviHNZILnGHixjEzsvH8v0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=tWIB7dGFXK/y0HOFASXm+oNKbICIx61R0CM+TGzNDxOjsn2/Y6fSkMS3SRH8OeIOk qq3xNibV2JaEiHBucEZZ+jsQevqkC2vMSNzdSa+3EwTCmwrOp6FnVvwkCyjcO/YMJe Gs3jNAbPgMwNiTP6k5z1iKNAYhycRCd/UEW//xRg=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0A092B3; Mon, 9 Nov 2020 11:21:16 +0100 (CET)
Date: Mon, 09 Nov 2020 11:21:16 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
cc: 6man WG <ipv6@ietf.org>
Subject: Re: the race to the bottom problem
In-Reply-To: <CAKD1Yr1yiXR43mL45KbsZkKY7_YVhWFzW82LL6qed6mVPBjxaw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2011091112170.15604@uplift.swm.pp.se>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com> <CABNhwV1zoZpZNjb54rEys4+49H3vpebZW2g9JbO1_58eR+WnQg@mail.gmail.com> <CABNhwV3L7kz=cWu8s3X=djVf4MCwewzbEgx09TWaKzCULCjYUQ@mail.gmail.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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TNVf8z2VVbcAPSaxO588w_-ZBvA>
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: Mon, 09 Nov 2020 10:21:21 -0000

On Sat, 7 Nov 2020, Lorenzo Colitti wrote:

> The logical consequence is that we end up at /128. This is particularly
> risky because any operator with lots of experience with IPv4 will find "one
> /128 per host" obvious, expected and natural. One device has one IP
> address, right? And once get to that point, we'll need to bring back NAT in
> order to extend further. That would pretty much make the entire transition
> to IPv6 pointless. We might as well have stayed with IPv4.
>
> Personally I think that once there's more industry experience and IPv6 is
> widely deployed in all network types (say, once we reach 80% of the
> internet, and many networks are IPv6-only), we might be able to safely move
> the bottom, once. But it's much too early for that.

I still fully agree with this. To this day, I run into people who want to 
via DHCPv6 assign a single address to each host. They do not care that 
this host might be running docker containers, VMs or whatever, that might 
benefit from having a GUA. To them it's "obvious" way to do, because 
that's how it's "always" been done.

They've already completed the race to the bottom, and indeed that's a 
/128.

We see all this /64 deployment because ISPs are saying "why more, there is 
just a single LAN?" and then /64 PD is the natural result of that thought 
process. This is the *only* thing stopping them from assigning smaller 
subnets. I'm sure there are plenty who started out with /120 and then 
discovered that didn't work, did some research and discovered "oh, I need 
/64" and then that was that.

I do agree we should try to solve this problem so that my machine can get 
for instance a /112 assigned to it in one go, basically "prefix 
registration" so the upstream router can assign a large subnet to a host 
and install a route for that. Still, that doesn't solve the nested doll 
problem with router->router->router->machine->VM->docker etc that we want 
to support.

I don't know how to solve this, but letting go of the /64 limit makes me 
very Fearful, Uncertain and Doubtful about the future.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se