Re: [v6ops] Geoff/queue-closed: 56%

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 17 April 2024 14:00 UTC

Return-Path: <vasilenko.eduard@huawei.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 9DF5BC14F6B0 for <v6ops@ietfa.amsl.com>; Wed, 17 Apr 2024 07:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1nTLpg0TxBm for <v6ops@ietfa.amsl.com>; Wed, 17 Apr 2024 07:00:09 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C401C14F6AC for <v6ops@ietf.org>; Wed, 17 Apr 2024 07:00:09 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VKMtj4YdVz6JBHb; Wed, 17 Apr 2024 21:58:05 +0800 (CST)
Received: from mscpeml100004.china.huawei.com (unknown [7.188.51.133]) by mail.maildlp.com (Postfix) with ESMTPS id 9ACF5140A46; Wed, 17 Apr 2024 22:00:05 +0800 (CST)
Received: from mscpeml500004.china.huawei.com (7.188.26.250) by mscpeml100004.china.huawei.com (7.188.51.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Wed, 17 Apr 2024 17:00:05 +0300
Received: from mscpeml500004.china.huawei.com ([7.188.26.250]) by mscpeml500004.china.huawei.com ([7.188.26.250]) with mapi id 15.02.1258.028; Wed, 17 Apr 2024 17:00:05 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Brian Candler <brian@nsrc.org>, Gert Doering <gert@space.net>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org>
Thread-Topic: [v6ops] Geoff/queue-closed: 56%
Thread-Index: AQHaen8WwAKufaKOBU605MUG7Z2bFbE/6bOAgCxOw4CAAAs+gIAABCqAgAAsqQCAADQx0A==
Date: Wed, 17 Apr 2024 14:00:04 +0000
Message-ID: <ddce8dbb377e485990a202396c29bf98@huawei.com>
References: <ZfplwNJGdpl05bZO@faui48e.informatik.uni-erlangen.de> <EF78559D-7879-4C0D-A47B-08AB279FD40B@isc.org> <5a4d382100604730bd31c45ba196d62a@huawei.com> <41e6d96d-dd6d-4982-9160-92bffb5eafad@nsrc.org> <Zh-trcwsxAwHgkus@Space.Net> <a98a82dd-dd47-4c21-ad08-ec717e13a847@nsrc.org>
In-Reply-To: <a98a82dd-dd47-4c21-ad08-ec717e13a847@nsrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.199.56.41]
Content-Type: multipart/alternative; boundary="_000_ddce8dbb377e485990a202396c29bf98huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bOCJE_QX0zBVHC1jB9Bo2JVgj94>
Subject: Re: [v6ops] Geoff/queue-closed: 56%
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 17 Apr 2024 14:00:13 -0000

Many networks (many ISPs and the majority of Enterprises) have NAT44 anyway.
If they would migrate to IPv6 then they just need to upgrade NAT44 to NAT64 (with a loss of about 30% of NAT performance).
Hence, it is possible to disable IPv4.

I believe that IPv6 migration would not happen in Enterprises for a long list of different reasons.
Sorry, DualStack is not on the list of blocking problems.
Of course, IPv6-mostly or IPv6-only is better. But there are much bigger problems.
Eduard
From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian Candler
Sent: Wednesday, April 17, 2024 16:48
To: Gert Doering <gert@space.net>
Cc: v6ops@ietf.org; Toerless Eckert <tte@cs.fau.de>; Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org>
Subject: Re: [v6ops] Geoff/queue-closed: 56%

On 17/04/2024 12:08, Gert Doering wrote:

On Wed, Apr 17, 2024 at 11:53:35AM +0100, Brian Candler wrote:

Also, everyone should be clear that there is currently no such thing as

"migrate to IPv6". You either add IPv6 to your IPv4 stack, or you stay with

IPv4. You can't remove the IPv4 part without cutting yourself off from most

of the Internet.

This is not a message the IETF should be spreading, because then the logical

question follows "why bother with IPv6 at all, if I have to keep IP4 around".

That is ultimately why this so-called "migration" hasn't happened - and wishful thinking won't change that, nor keeping quiet about reality. If there's any message the IETF should be spreading, it's that they live on the same planet as the rest of us.

Dual-stack would be excellent as a migration tool: add v6 this month, remove v4 next month, job done.  But that's not what's being asked of users, and dual-stack as a "forever" proposition is absolutely terrible. Nobody should be surprised that it has been rejected for the last 25 years, and will continue to be rejected. Dabbling at the edges does not change this fundamental fact - such as saying "oh look, we measure lower RTT for IPv6 than IPv4, now you have a good reason to enable IPv6!". It isn't, and they won't.

We all wish there were more addresses, and this is most keenly felt at the access ISP side of things. In the UK, many new fibre operators are starting to put people behind CGNAT, which nobody wants.

As I see it, there are two general ways to approach this.

(1) You can try to get *all* the content providers in the world to enable IPv6.  This is the approach which has been tried and failed over >25 years.

IMO, this was always doomed to fail. For as long as any significant banks, shops, restaurants or government services are not reachable via IPv6, then an IPv6-only connection is useless. And it's no good if 50% are, or 80% are, or even 99% are.  As long as that 1% is still there, an IPv6-only connection does not let you reach the Internet, and users will complain that the Internet is broken.  And as said above: "why bother with IPv6 at all, if I have to keep IP4 around?"

If there is no incremental benefit to users, neither is there incremental benefit to content providers. From where I'm looking, many large organizations aren't making their content available on IPv6 (e.g. www.bbc.co.uk<http://www.bbc.co.uk> - who were technical leaders in broadcasting, back in the 20th century); neither are smaller ones, including technical publications like www.theregister.co.uk<http://www.theregister.co.uk>. Just two random examples.

Only they know the real reasons why they're not, but I believe it boils down to a negative business case: cost and time, with on-going running costs (dual-stack and happy-eyeballs makes network problems harder to diagnose), plus no return on investment, plus risks associated with user tracking, advertising and monetization, all set against higher priorities which *do* have a return on investment.

You can't tell people that their business case is wrong, or try to make up business cases for them. It's their money and their time, and they know themselves how best to allocate it. It's patronising to suggest otherwise, and they will rightly ignore you.

(Aside: it's also worth mentioning that there's no scarcity of IPv4 addresses at the content provider and CDN side. They've been sharing IP addresses been sites for years.)
So that's failed. What's the alternative?

(2) You can make it practical to deploy IPv6-only networks at the access edge - the places where people sit behind NAT44 today - and still reach IPv4-only content. In that case, single-stack IPv6 replaces single-stack IPv4, and NAT64 replaces NAT44, and *that* starts to become a proposition you can sell: you are choosing between technology A or technology B, not technology A or technology A+B.

This is an approach the IETF could spread, with the support of big orgs like Google who are doing it in their own networks.

However, building NAT64 needs clue on the side of the user (if they are building their own NAT64), or on the side of the ISP (if they are running a large scale NAT64 on behalf of their users), and it has similar operational overhead to CGN/NAT44, and needs the same external public IPv4 resources, so it is still an uphill struggle.  It's a clear win over dual-stack, but much less so over IPv4 single-stack.

With my wishing hat on: I would like to see one or more big companies step up to the mark and build a giant, *public* NAT64 or reverse proxy so that the whole IPv4 Internet is accessible to anyone with an IPv6-only address. The big CDNs like Google, Cloudflare, Akamai etc would be well placed to do that.  At that point, IPv6-only access ISPs and enterprise networks spring into life.  I would expect usage to ramp up as challenger ISPs start to make use of this service; at that point, websites will see more and more of their traffic coming from the CDN source v4 addresses, and will realise they can get *better* tracking of their users by enabling native IPv6, at which point usage will decline. Incremental benefits to all. I would love this to happen, but I'm not holding my breath.

Regards,

Brian.