Re: the race to the bottom problem

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Fri, 06 November 2020 14:41 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
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 487E03A11DE for <ipv6@ietfa.amsl.com>; Fri, 6 Nov 2020 06:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 XoIVvM6aOoJ1 for <ipv6@ietfa.amsl.com>; Fri, 6 Nov 2020 06:41:36 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0AB3A11DD for <ipv6@ietf.org>; Fri, 6 Nov 2020 06:41:34 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kb2vf-0000L2C; Fri, 6 Nov 2020 15:41:27 +0100
Message-Id: <m1kb2vf-0000L2C@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: the race to the bottom problem
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
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> <CABNhwV3wG_VsFk2FRgXL=_6K9=RwAwAX=0dBNVr5PPReLhEySw@mail.gmail.com>
In-reply-to: Your message of "Fri, 6 Nov 2020 09:27:32 -0500 ." <CABNhwV3wG_VsFk2FRgXL=_6K9=RwAwAX=0dBNVr5PPReLhEySw@mail.gmail.com>
Date: Fri, 06 Nov 2020 15:41:26 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ijSPSaE6UPqUSFdQlt96w11tyL0>
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: Fri, 06 Nov 2020 14:41:37 -0000

>    A RIPE BCOP may help as well
>    for mobile operators.  This is all a theoretical fear that
>    operators will race to the bottom, but until we remove the 64
>    bit boundary, we dont know for sure either way.  My thoughts
>    are that large operators such as Verizon as I can influence the
>    stance Verizon takes on allocation guidelines, that they will
>    not change and will remain at /64.  Verizon as a major stakeholder
>    can influence other operators as well on the stance. The complexity
>    of management vlsm is allocation for operators is not worth the
>    saving and what is the real savings.  Most operators have massive
>    IPv6 assignments they got decades ago so they never have to go
>    back to the well again for more.

If mobile providers such as Verizon care about standards, and can influence
other operators then maybe they can comply with a 9 year old RFC (RFC 6177):

"Although a /64 can (in theory) address an almost unlimited
"number of devices, sites should be given sufficient address
"space to be able to lay out subnets as appropriate, and not be
"forced to use address conservation techniques such as using
"bridging.  Whether or not bridging is an appropriate choice is
"an end site matter.

RFC 7278 uses a weird type of bridging to get around the lack of address 
space. This is something that affects just about all phones because almost
without exception phones can be used as wifi base station to connect other
devices over the mobile link.