Re: Market forces

Simon Hobson <linux@thehobsons.co.uk> Mon, 09 November 2020 12:49 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 A5DB43A1073 for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 04:49:20 -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 h3vsi8syunzk for <ipv6@ietfa.amsl.com>; Mon, 9 Nov 2020 04:49:19 -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 B6F873A105C for <ipv6@ietf.org>; Mon, 9 Nov 2020 04:49:18 -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 52BC11A073 for <ipv6@ietf.org>; Mon, 9 Nov 2020 12:49:14 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Market forces
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <77C70939-13F9-4B04-BEF1-F6894EA1C09C@fugue.com>
Date: Mon, 09 Nov 2020 12:49:13 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <1522C532-EAE5-42A1-9B66-08883A90D2D8@thehobsons.co.uk>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <3c1c3ab5-5726-b141-e7ed-618984bbbdb1@gmail.com> <CABNhwV1zoZpZNjb54rEys4+49H3vpebZW2g9JbO1_58eR+WnQg@mail.gmail.com> <CAKD1Yr0vvyQnTGRoSh4qa4He1gq5HXXRaKU3pVLtCtDUzcwL_w@mail.gmail.com> <CABNhwV13gggo9XfRvrR31bCUptZuAiosK5ebMmnzDdinKqmrBw@mail.gmail.com> <B7B3091C-92E0-482A-8D16-AD6DCFD1E714@isc.org> <CAD6AjGSCnG_fyorW2-tEqzzTfj897Knf55-0QV9DPcDKt45VOA@mail.gmail.com> <F323E4EB-5AAA-4C34-9EA2-06D4A0839308@thehobsons.co.uk> <77C70939-13F9-4B04-BEF1-F6894EA1C09C@fugue.com>
To: 6man <ipv6@ietf.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hhXd-Y1fRF36miKuLDUWGCz1jNw>
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 12:49:21 -0000

Ted Lemon <mellon@fugue.com> wrote:

> Simon, the thing you’re glossing over here, which I actually don’t hear anybody talking about, is that there has thus far been no market pressure that could punish ISPs that hand out /64s. What’s the bad outcome for the end user in practice? They can’t subnet their home network? Well, they don’t, do they? HNCP has a market penetration of 0% right now.
> 
> We can reasonably expect this to change in the next year or two. Several initiatives are underway at the moment that are likely to suffer from the absence of a narrower allocation: specifically CHIP and Thread, both of which rely on 802.15.4.6lowpan networks. It’s reasonable to expect that these technologies will start to be deployed in homes in significant numbers in the near future.
> 
> At present, when such technologies are deployed, they will be forced to rely on IPv4 for cloud service reachability for ISPs that don’t provide an allocation narrower than /64. Since these networks are v6-only, this will be done using NAT64. And this will work fine, except that the ISP is now stuck giving the customer an IPv4 address.
> 
> What is less scarce than an IPv4 address? Why, a /60 or a /56. These are 2^28 or 2^24 less scarce than IPv4 addresses, respectively.

I think all of us on this list know that - it would seem that many don't.

> So all this fuss about how to solve the problem of ISPs only giving out /64s is genuinely premature. Market forces will change their behavior. It’s just a matter of time.

I applaud your optimism !

Would these be the same market forces that give many of you in the US a choice of exactly one (the cable company covering your area) or zero (if you live anywhere the cable companies have decided isn't worthwhile) "high speed" internet provider ? I know we have our problems over here in the UK, but they do seem relatively minor compared to what I read about over there.

Besides, as long as "stuff works" and the general population don't understand "all this technical stuff", then customers aren't going to be complaining. Until some of the IOT vendors (taking your examples) start telling customers that "your network is broken, this stuff will stop working unless you fix it" then there never will be any pressure on the ISPs to change.



Mikael Abrahamsson <swmike=40swm.pp.se@dmarc.ietf.org> wrote:

> Other vendors also do not support this, one fairly popular brand is Ubiquiti that I see a lot of, which doesn't support sub-PD.

Unless they've fixed that, their access points also filter out IPv6 altogether (ibtables rule IIRC).


> Unfortunately I don't think normal users will notice the lack of /64 or larger within the home. Software vendors will have to work around this with IPv4 fallback just like you say, to ensure a good customer experience. They will invisibly to the user workaround the problem to hide this network deficiency. It'll cost everybody time and money without anyone really noticing.

Exactly. Lots of devs/support people/whatever will be forced to waste loads of effort working around this - just like they have done for years with NAT. And the end users will only see a problem when it doesn't work - but they won't be blaming their ISP because (unless the vendor takes the effort to educate them) they just won't know.


Simon