Re: [v6ops] Why enterprises aren't adopting IPv6 (Re: Implementation Status of PREF64)

Owen DeLong <owen@delong.com> Thu, 30 September 2021 17:40 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E683A0E15 for <v6ops@ietfa.amsl.com>; Thu, 30 Sep 2021 10:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com
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 rmpekDivjRBt for <v6ops@ietfa.amsl.com>; Thu, 30 Sep 2021 10:40:16 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6883A0E00 for <v6ops@ietf.org>; Thu, 30 Sep 2021 10:40:16 -0700 (PDT)
Received: from smtpclient.apple ([IPv6:2620:0:930:0:d12c:2b24:7049:d8a]) (authenticated bits=0) by owen.delong.com (8.16.1/8.15.2) with ESMTPSA id 18UHe9hT3537656 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Sep 2021 10:40:09 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 18UHe9hT3537656
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1633023609; bh=Ob1WJ9uuTRAQP+1kMzlhOQEYpPdPO6bvot25T0hyEYc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Gba9wU1sS0E1AK8RFDyRPEUxYfK1m+VEsOEn+cPQf0NXIQvQgQ0EPy5eFjA1hlaDp IrNpZSIJVnDSnpqY9NQna25seuDJwnLbYFXjOPrB/GdQZLwsq/nR45WnqlVQnMnQMZ +brSnMTLZdwH1I0s9YeF25Itix772By5o5+xXAZM=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4AF3C29B-4642-4173-A027-0AAAEE65C869@employees.org>
Date: Thu, 30 Sep 2021 10:40:08 -0700
Cc: Gert Doering <gert@space.net>, Jen Linkova <furry@google.com>, V6 Ops List <v6ops@ietf.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Owen DeLong <owen=40delong.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB9060DC-EBB1-4F02-BD70-C0BF6302CE12@delong.com>
References: <CAO42Z2wdoSdJDOB2Zo0=ZK0ecOARRsdg2nbHZGSDOhryPbLfDw@mail.gmail.com> <F2BD0A42-E9AD-45DD-999A-638E73BE1177@delong.com> <CAKD1Yr2K3Gd3JD=NJFOoH6GYgs-8ACxRQB9-sKJ7cbF4_hxsow@mail.gmail.com> <0B533C71-5DB0-410D-A5A3-7E8FD559F214@delong.com> <CAKD1Yr3NoYfNT7+OVJoCCdgdif6AHHw29tNCPttS=-NuRZKv3w@mail.gmail.com> <DM6PR02MB692426B0EEDDC2C4D78D8EC0C3A89@DM6PR02MB6924.namprd02.prod.outlook.com> <CAKD1Yr25dtinLBeJpAuJ17NfLg7-ewM9QPvnXNuEJ8wiBQV9ig@mail.gmail.com> <CAO42Z2zqf=F6OTDK2e8cMYXdPgMZ=SgFJcn7BTKYGgcYsLT2iw@mail.gmail.com> <894BCFE9-0811-4AE6-9941-6183292E4431@delong.com> <7E8C5F52-596F-4CAB-89EB-B0D5BAF5F612@employees.org> <YVXvgS6GDX97sHOW@Space.Net> <4AF3C29B-4642-4173-A027-0AAAEE65C869@employees.org>
To: otroan@employees.org
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 30 Sep 2021 10:40:09 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/lCwpZXwTaHI0PzpUCQxgXsesveU>
Subject: Re: [v6ops] Why enterprises aren't adopting IPv6 (Re: Implementation Status of PREF64)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2021 17:40:21 -0000


> On Sep 30, 2021, at 10:21 , otroan@employees.org wrote:
> 
> Gert,
> 
>>> typically they only use a 1/65535th of an IPv4 address ((one TCP port) although they share it at L7).
>>> it would certainly be possible to improve on that.
>> 
>> Is that our goal?
> 
> No, but our goal failed. So let's take stock.

I disagree. I think there is a subtle but important difference between “our goal failed” and “our goal hasn’t succeeded yet”.

While I agree we should take stock and consider alternatives to accelerate the deployment of IPv6, I do not
think that declaring failure and giving up on IPv6 transition is the right answer.

>> Make CGNAT44 solutions scale to amazeballs level, to avoid deploying IPv6?
> 
> The eyeball networks aren't depending on CGNAT44, they use public IPv4 addresses.

That’s only really true in North America and Europe and can’t be sustained much longer even there.

Much of Asia (especially India and China) are using varieties of CGN and NAT444, NAT4444, etc.

Much of Africa, despite their RIR still having a free pool is also deploying CGN rather than public
addresses, in part due to absurd policies that are based on the premise that protecting the free pool
somehow increases the viable longevity of IPv4 while actually hampering deployment progress in
general.

> My point was that the utilisation of those IPv4 addresses could be improved by orders of magnitude, simply by using more ports than just 443.

My point is that making it possible for consumers to use protocols beyond TCP, UDP, and ICMP
would be a good thing.


>>> last time I tried going IPv6 only, that was completely unworkable.
>>> (while doing IPv4 only is perfectly fine.)
>> 
>> IPv6-only without a NAT64 gateway is not workable today.
> 
> Indeed. And if you depend on a NAT64 gateway your application has the same set of issues as if it was behind a NAT44.

There are a couple of additional failure modes (e.g. Skype behind NAT44 has NAT traversal, last I looked, Skype
behind NAT64 was more of a complete failure).

>> IPv4-only is not workable either - if you need/want to access resources
>> that sit behind a DS-Lite ISP connection which has unhindered IPv6, and
>> CGNAT'ed IPv4...
> 
> The DS-lite part isn't relevant here, but yes, if there is an IPv6 only service, you can only reach that from the IPv4 only host if you go through a NAT46.
> Are you aware of any services like that today?

Yes, but not in the sense you are meaning:

(114) ~ % host jimtest.delong.com                                                                                                                                2021/09/30 10:35:06
jimtest.delong.com has IPv6 address 2620:0:930::dead:beef:cafe

No A record. Web server is alive on port 80 there.

>>> that's what we have been saying for 25 years.
>>> perhaps time to accept reality. ;-)
>> 
>> So what would that be?  "Sell more NAT boxes, give up on IPv6"?
>> 
>> There's certainly more money to be made, in helping panicking customers
>> sort out their NAT444 mess "we are losing millions every hour!"...
> 
> That's not my expertise, but my impression isn't that there is lot of money in selling more NAT boxes.
> Nor is anyone panicking either.

Well… yes and no. When CGN goes wrong, it often goes horribly wrong and there is a fair amount of
panic in those instances. Not to mention the call center costs and the cost in terms of customer good
will and trust, brand reputation, SLA credits, etc.

> The reality is unfortunately that NAT has benefits. Which would also be required in IPv6.

I remain unconvinced of this. Please explicate.

> And if significant deployments still would require NAT with IPv6... the gains over IPv4 are questionable.
> (For example the trend of Enterprises to tunnel their traffic to the cloud for "services". Marketing name: SASE.)

True, but I don’t accept the premise. You’re going to have to provide more than a simple allegation that
a) NAT has benefits
and
b) NAT would be the only way to achieve those benefits in IPv6

> End to end is certainly dead.

Why? Again, I remain unconvinced of this.

> So as much as I'd like the purety of the IPv6 architecture, we're not going to do networking like it's 1990 again any time soon.

Seems a lot of people would like it, so what, exactly, is preventing it?

Owen