Re: [v6ops] IPREF as a transitioning tool

Martin Huněk <> Fri, 10 November 2023 01:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0FD7C0A8573 for <>; Thu, 9 Nov 2023 17:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Status: No, score=-2.108 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YH4RCqTa0ENY for <>; Thu, 9 Nov 2023 17:13:09 -0800 (PST)
Received: from ( [IPv6:2001:718:1c01:16::aa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A168C0A856E for <>; Thu, 9 Nov 2023 17:13:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from (unknown [IPv6:2001:718:1c01:11::1:15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 283AF180383C5 for <>; Fri, 10 Nov 2023 02:13:03 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 283AF180383C5
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=tul2021; t=1699578783; bh=6qrJ/xaa8XAI1TMxKs58u9bVT25tjr11w+fJhlz31UU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XdFbECmvBl3hIHB3O6bLlri9Ek60kATurED0c0JZKvGUHnihKVCRsnyYb/Yqi6JF8 EfctHgXhfMFKql/KY2SIO1xfaGMU2IzCF2F08s9Gak0nsySMvMsna5b/wyADUDEA4h bVPcmZj4/IU44du03LAgHsrOLDcKIEtUmfyc3iO23F1+/7g98dYg9SZGaftYG2lCvr RDA8cUKylkdrXsyACR23HiKjnYPdhK2dzf985gABsqgQa3IMlk0LlAt/WSvH06i4MJ lgcdece69b9YByx+SyEerocI6lMjdyNIxrPRg4ZGCQ1TfwrFc9FdjVUD9SHsSXQy5v pOs8uF7oeCcXg==
From: Martin Huněk <>
Date: Fri, 10 Nov 2023 02:12:56 +0100
Message-ID: <>
Organization: Technická univerzita v Liberci
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2352380.bO1fEbeGnv"; micalg="sha384"; protocol="application/pkcs7-signature"
Archived-At: <>
Subject: Re: [v6ops] IPREF as a transitioning tool
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Nov 2023 01:13:13 -0000


I'm missing these parts:
- How this technology would interact with the networks that would not use IPREF.
- How the GWs would know when to switch to the IPv6 on the Internet.
- What about DNSSEC?
- What benefits does it bring to the network that already did the transition?

A lot of us do not start with just IPv4 running. We run dual-stack or braver ones IPv6-mostly/only. The IPv4-only starting point would be around 15 years ago.

Modifying DNS replies on a local recursive resolver is not a good idea. This would break DNSSEC signatures, so IPREF would not work for DNSSEC-validating clients.

Rest see inline.

Dne středa 8. listopadu 2023 10:08:14 CET, waldemar napsal(a):
> I wanted to address one comment that I did not have time to during the 
> session yesterday.
> There was a gentleman who questioned the wisdom of introducing another 
> transition strategy. He said such a proposal would make sense 15 years 
> ago, he also said many could propose new strategies but refrain from 
> doing so. He ended by stating that there is no need for another 
> transition strategy.

I must agree with the thought of the above-mentioned gentleman. Maybe 15 years ago, this could be a viable solution even though we would probably have thought the IPv6 adoption would have been faster than it actually was. Anyway, now we have the proper tools to do the transition to IPv6-only even without IPREF. We can use, for example, SIIT-DC to shut down IPv4 internally without waiting for latecomers. The IPv4-only operator would not care about the reachability of IPv6-only services (together with any transitional mechanism) until there is something really important there. When so, it is not a good idea to give such an operator tool how to not implement native IPv6.
> I generally agree with the line of thought. Excessive proliferation of 
> methods is detrimental to the cause. I questioned myself whether to go 
> with the proposal or not. In the end I decided that IPREF is so 
> different and so distinct from anything currently available that it 
> should be presented. I already mentioned that it is based on a different 
> principle which will make it succeed where existing methods would fail. 
> There are other factors, even more significant:
> (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.
> (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.

With the "Enterprise" admin hat on, I like more tools; there is no dispute about that. However, I don't like the idea of placing some translator in the way of all my traffic and being forced to keep it there until the last latecomer finishes the transition. I run full dual-stack now. If I want to run IPREF, it would cost me additional money to do so - buy the translator. There is more risk that an additional device in the way, the translator, would fail. Higher latency. And because all would have to go through it, for me, it means up to 100 Gbps throughput. I'm not convinced if it is better than dual-stack or 464XLAT + SIIT-DC. Seams more like charity work for latecomers than an economically viable solution.
> (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.

Now, ISP admin hat on. I'm also doing dual-stack now. I would rather love to get rid of NAT/CGNAT. Putting all the traffic through yet another translator that I do not have now. And keep it for how long? I see the additional cost, not less. Also, there is an additional risk of implementing new transitional technology and to run it.
> I am just an individual, an inventor, I can do only so much. There are 
> different roles played by different entities. IPREF must be picked up by 
> others. By vendors to build commercial gateways, by architects and 
> operators to complete its specification. This project is in a very 
> vulnerable stage. It can be easily dismissed. Because of (a), (b), and 
> (c) above, it would be foolish to do so. You must allow that the project 
> might be picked up at some point, the gateways will be built, and in the 
> end the economy of the method will prevail. IPv6 cause is better served 
> embracing it than fighting it.

The whole reasoning is full of claims but very little data and very "heavy" (GWs in every network, modified DNS, etc.) without clear motivation for those who already made the transition.

> _______________________________________________
> v6ops mailing list