Re: [v6ops] IPREF as a transitioning tool

"owen@Delong.com" <owen@delong.com> Wed, 08 November 2023 21:46 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 AB759C151091 for <v6ops@ietfa.amsl.com>; Wed, 8 Nov 2023 13:46:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com
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 oSciBYF7SFfJ for <v6ops@ietfa.amsl.com>; Wed, 8 Nov 2023 13:45:56 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E954AC15C28B for <v6ops@ietf.org>; Wed, 8 Nov 2023 13:45:03 -0800 (PST)
Received: from smtpclient.apple (75-10-5-143.lightspeed.sntcca.sbcglobal.net [75.10.5.143]) (authenticated bits=0) by owen.delong.com (8.17.1/8.15.2) with ESMTPSA id 3A8Lj1Lj1191826 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Nov 2023 21:45:02 GMT
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 3A8Lj1Lj1191826
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1699479902; bh=hub/vVmshYgYHijMCZ1DES8oIn286WwGVfsW+Br7yi4=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ORtfVITWhY8qpNbd4QGLB8DLi39oIFZvaNbb++3/NZvYKdQKEq79FbTi/laMe6bym lk6f4RGxCj4Ql/SOdUiOhQGl0HpqMQegzTCvOx3nanBTlev6FjVZTZqKE+YEIBzKt7 EVpM8E0yBrmW3fpRHAYdjF3UuM+jtLsXEahXgHwU=
From: "owen@Delong.com" <owen@delong.com>
Message-Id: <97F41CE9-075D-4CAC-B78F-2FE9F2FF3B6D@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C6A4E983-2798-4954-862E-A9139BB02A0C"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Wed, 08 Nov 2023 13:44:51 -0800
In-Reply-To: <9067a45b-56ca-47d6-b011-9274c0b634b8@gmail.com>
Cc: v6ops@ietf.org
To: "Soni They/Them L." <fakedme+ipv6@gmail.com>
References: <90f07ffa-1f44-8fa6-a6eb-b35c14fcf655@wdmsys.com> <9DD47882-7147-4C39-B559-E363182438EA@delong.com> <9067a45b-56ca-47d6-b011-9274c0b634b8@gmail.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (owen.delong.com [192.159.10.2]); Wed, 08 Nov 2023 21:45:02 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/rP5IpHK5YtMOaqRRqL8IaN-KXYk>
Subject: Re: [v6ops] IPREF as a transitioning tool
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, 08 Nov 2023 21:46:00 -0000


> On Nov 8, 2023, at 12:27, Soni They/Them L. <fakedme+ipv6@gmail.com> wrote:
> 
> 
> 
> On 2023-11-08 16:48, owen@Delong.com <mailto:owen@Delong.com> wrote:
>> > (a) IPREF is 100% customer premise technology. As such, its use is totally dependent on the customers choice. There is nothing IETF can do to stop them. It is similar to NAT in this respect. NAT was widely despised, still is, by IPv6 enthusiast but it took over the world in spite of attempts to  block it.
>> 
>> NAT took over the world because we dithered around too long before providing working IPv6 and that was a tragic missed opportunity.
>> 
>> Sadly, we took so long that we now have a generation and a half of network engineers who don’t understand how peer to peer networking is supposed to work and regard address transparency as a security risk. Indeed, I’m constantly having to teach actual network and systems administrators that it is possible to do stateful inspection without mutilating the packet header and that it provides all the same security benefits as stateful inspection combined with header mutilation, with the added benefits of rational audit trails, easier troubleshooting, and transparent addressing.
> 
> Personally we like to think ephemeral IPv6 is the solution to this problem. It basically takes away address transparency in all the relevant places, with all of the drawbacks that comes with, except without header mangling (i.e. it's still peer to peer).

I’m slightly less concerned about EDID transparency than at least knowing which administrator I need to contact for an abuse problem and the ability for said administrator to match his logs to my logs, so yes, this is mostly a solution for environments where EDID transparency is considered a “bad thing”.

Certainly nowhere near as bad as thousands or tens of thousands of users behind a single IPv4 address.

>> I haven’t had a chance to look at IPREF in detail (and I guarantee if you keep that name, it’s going to crate wonderful confusion with iperf the beloved performance measurement tool), so I don’t know whether it’s a good or bad thing.
>> 
>> > (b) Related to (a), enterprises love the ability to control the process themselves, without anybody dictating what they should or should not do with their networks. In addition, the economic profile hugely favors IPREF. It is simply cheaper not to do dual stacks, not to do two step transition, not to have to upgrade what they don't want to upgrade, not to have to coordinate with peers. Less cost, less risk.
>> 
>> Enterprises claim to love that, but they also love cloud (at the moment) which is completely antithetical to that claim. Anything that gets us to IPv6-only sooner and/or cheaper does seem appealing. If IPREF does that, I’ll end up being a supporter.
> 
> *Anything*...? (Something something, "Proof of IPv4"/"Waste of IPv4" blockchain algorithms. :v)

Neither of those would particularly bother me at the moment, though I don’t see them providing enough value to actually achieve widespread adoption. I do know at least one person who wants to replace the RIRs (at least for IPv4) with what amounts to IPv4 NFTs. I’m not in favor of this approach and I suspect I’m not alone.

Anyway, I think you understand the intended meaning of my statement.

>> > (c) Related to (b) the economic profile of IPREF is hugely attractive to  ISPs as well. Why doing IPv4-as-a-service if it is not necessary, why burden pure IPv6 Internet with IPv4 services if they're not needed? How can IPv6 compete with IPv4 if it is required to provide extra functionality but which can be avoided? Less cost, less risk.
>> 
>> At some point, there are going to be IPv6-only services because there simply aren’t enough IPv4 addresses for services to continue to grow indefinitely. The only requirement for ISPs to continue to provide IPv4 as a service stems from content/services that are not available on IPv6.
> 
> We already have those, The White House Website archives are IPv6-only nowadays.

Yes, but I mean services a LOT of subscribers actually care about enough that ISPs not providing IPv6 would have trouble explaining to their users why they can’t get there…

Imagine if you couldn’t get to Amazon over IPv4… How would your typical eyeball ISP stay in business without solving that?

It’s not going to be Amazon, obviously, but some next-generation IPv4-was-too-expensive-for-our-startup service will eventually come along and become popular enough to drive the remaining eyeball providers to have to do IPv6. Sadly, the time that was needed most was a decade ago and it still hasn’t happened.


Owen