Re: [**EXTERNAL**] the race to the bottom problem

Simon Hobson <linux@thehobsons.co.uk> Sun, 08 November 2020 13:12 UTC

Return-Path: <linux@thehobsons.co.uk>
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 B50283A03F3; Sun, 8 Nov 2020 05:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 c_IhS2htyqEn; Sun, 8 Nov 2020 05:12:24 -0800 (PST)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCCC3A03EF; Sun, 8 Nov 2020 05:12:23 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from [192.168.137.104] (unknown [192.168.137.104]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 72CBC1BC66; Sun, 8 Nov 2020 13:12:18 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: [**EXTERNAL**] the race to the bottom problem
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <CABNhwV2oB6BCLqbqPRZLYOKUwSQ+ZQbyMddzKLSBc-p-eaaXBg@mail.gmail.com>
Date: Sun, 08 Nov 2020 13:12:15 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <3AC7204D-E231-42E8-BB7A-A1982A625FA5@thehobsons.co.uk>
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> <21BC970D-8708-4090-A984-02E6E1305B94@gmail.com> <25099A60-8685-4226-8328-AA87376B62D2@ciena.com> <c5402655-9bfd-dafd-ceef-25b1f9c36770@gmail.com> <CABNhwV2oB6BCLqbqPRZLYOKUwSQ+ZQbyMddzKLSBc-p-eaaXBg@mail.gmail.com>
To: 6man <ipv6@ietf.org>, "draft-mishra-6man-variable-slaac@ietf.org" <draft-mishra-6man-variable-slaac@ietf.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8AiY1drK6puxqK9jkk9UYpQ7Is8>
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 13:12:27 -0000

Gyan Mishra <hayabusagsm@gmail.com> wrote:

> > because I believe the race to the bottom can be addressed by other network elements (e.g. CE), not only clients.
> 
> But the consumer CE is very often supplied by the ISP, and it therefore does what the ISP wants. If that's different from what an RFC says, it's the ISP that wins.

Indeed, and we've seen all sorts of "interesting" ideas about how networking should work.

>    From my standpoint previous response about the race rob bottom feasibility, I agree we are at the bottom now, but we are only theorizing that their would be a new bottom with longer prefixes.  As I stated before IPV6 is not IPV4 and is not subject to address space exhaustion so as exhaustion is an impossibility there would never be a case where a new bottom would occur as ISPs do not have any fear of IPV6 address space exhaustion.

That is only true if we assume that the people building the IPv6 networks (and operating policies) have unlearned all they've learned from doing the same with IPv4. And there is evidence that they haven't ...


Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> wrote:

>> By observation,
>> folks are giving out /64s, when we would prefer they gave out /56
>> or even shorter.  
> 
> I'd say that a /56 is a clear example of the race to the bottom.
> 
> ISPs have been trying to give just a /128 to customers, just like IPv4.
> There is a common complaint that a 64-bit IID just wastes bits without 
> stating how those bits are more useful as part of the prefix.
> 
> And somehow the original 'give everybody a /48' got changed into '/56 is
> also fine' without clear operational reason. The only one I can think of
> is 6RD, but /56 shows up everywhere outside 6RD.
> 
> Why /56? because /48 has way too many subnets for a consumer. Again
> preserving bits that don't need to be preserved.
> 
> This tendency to use the longest possible prefix for a network or subnet
> is very strong.

I see a number of "human factors" at work in this.

Firstly, for some there is an opinion that anyone wanting more than one address [per device] must be wanting to do something "naughty" - whether that's getting up top mischief, or heaven forbid, host a service themselves on a residential connection. This latter reason is something I've come across in my (admittedly limited) experience in a small IT services company and dealing with a number of ISPs - some will actually cite this as a reason for not allowing a static IPv4 address unless you are paying more for a "business" connection (Talk Talk), or pay a stupidly high monthly fee for it (BT Internet).
The same mindset would translate into IPv6 as people wanting lots of address must be trying to hide something.

Something else I've come across in the past is "pay by devices". Granted it's mostly been in the mobile world where contracts explicitly prohibit sharing the connection with anything but the phone itself. But I vaguely recall some fixed services in the past having different tiers of pricing depending on how many devices you wanted to connect to it - again as a means of forcing businesses to pay more. Once you eliminate NAT (which effectively hides the number of devices without expensive traffic analysis), then you open the doors to "per per device" again - and what better method to restrict devices than to restrict the number of addresses ? Look forward to price tiers by subnet size.

The second factor, which I suspect is a very significant one, is that many people still think IPv6 is "IPv4 with a few more address bits". If your job is to build/manage IPv4 networks, and you are told "just add IPv6" without any extra budget, training, etc, then you are likely to just think in terms of "New IPv4 with more bits" and work from there.

You are not likely to have even heard of the privacy argument for large address allocations and address hopping - and if you have, then in many circles the ability to address hop would actually be seen as a bad thing. Don't forget that large parts of the world do not have the liberal views most of us in "the west" take for granted.

And I expect the majority of ISPs are still in the mindset that a customer network is your WAN connection plus "the ISP supplied router and exactly one network". I've dealt with ISPs that explicitly don't allow your to use your own router - and that included one (Vodafone) selling business DSL connections.


In summary, I too think having a fixed 64 bits doesn't make a lot of sense technically - I've seen enough to believe that there would in fact be a race to the bottom in some areas. And given that some places don't have the choice we take for granted in the UK, if you are unlucky enough to be in a "take or leave the /127 on offer" then that would indeed be a very bad thing.

I also think NAT was the spawn of the devil and put back widespread adoption of IPv6 by a decade at least - and diverted immeasurable developer (and support) resources away from fixing the underlying problem.

Simon