Re: [v6ops] IPREF as a transitioning tool

Martin Huněk <> Sat, 11 November 2023 00:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 898DFC1B0339 for <>; Fri, 10 Nov 2023 16:48:58 -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 6Ft5_naZOHTz for <>; Fri, 10 Nov 2023 16:48:54 -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 EC36AC1B032E for <>; Fri, 10 Nov 2023 16:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from [IPV6:2001:718:1c01:72:2e27:d7ff:fe2e:c477] (unknown [IPv6:2001:718:1c01:72:2e27:d7ff:fe2e:c477]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4F0EC18050A1A; Sat, 11 Nov 2023 01:48:47 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 4F0EC18050A1A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=tul2021; t=1699663727; bh=TuRzGvbvHlLnuQHlRI8bN0u9eI3adCiXuSNpKDz70K8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vb8AVOmJNwwVYZXOq6nXUHg/dV7rYnGQJXtVQ6EpxD1NHKr65pubqbbY2hIRVNm3M tex+nnknn2jMU0MtwYrUzIJwOVXeZfZuM8yzaxm9aHWX62OuS5B7WJD/EaAQa/1jmJ A/nZPFn0eEuMJUflVVNrfqpRrVoCQpwTtQWaRSsf94k3j0DkIiDh7QNbsZ2m/0QVHh uvbIIyU1Nt7js4Kcx6hspoTS6QDSvC7zGDLpLmglSD7LvhJ57REiO6Z3ySr0Uxjoia pmO5GtSzSUNuhu8dmPyhpGu1rbttMuFvaI/3lB7i7hfnXWJtzMt2ApvTWmqwCs4jxq t6g4k15L2Mg7Q==
Message-ID: <>
Date: Sat, 11 Nov 2023 01:48:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: cs-CZ
To: waldemar <>
References: <> <> <> <> <>
From: Martin Huněk <>
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000600020509080007020106"
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: Sat, 11 Nov 2023 00:48:58 -0000

On 10. 11. 23 19:06, waldemar wrote:
> On 11/10/23 07:31, Martin Huněk wrote:
>> Hi,
>> If it is required in every network in the whole Internet, then it is a blocker, isn't it?
> No, not really, We're requiring every network to transition and it is not a blocker.
We are not requiring them to do anything. Operators are forced to do that by their own reasons (shortage of IPv4 space, local regulations, customer requests). They do have a motivation. What would be the motivation for the IPREF? I see none.
>> Especially if it has to be in CPE, as many don't have any software support, and changes in HW take years to do.
>> Dne pátek 10. listopadu 2023 9:30:12 CET, waldemar napsal(a):
>>> On 11/9/23 22:12, Mark Andrews wrote:
>>>> There is nothing new in this proposal other than adding an unnecessary new DNS record.
>>>> Many moons ago the IETF/IRTF was presented with a DNS server that talked to a NAT64 to
>>>> establish A to AAAA mappings on demand to allow IPv4 machines to connect to IPv6 machines.
>>>> See section 3.2 of your proposal.  It worked but clearly had scaling limitations as it needed
>>>> a large IPv4 block to service a small IPv4 client base.  Putting one in every home CPE router
>>>> would probably work but is it really necessary when 99.99% of clients already support dual
>>>> stack.
>>> ...scaling issues.  Yes, exactly. IPREF does not have scaling issues.
>> If you put it in the CPE, you had to have the dual-stack all the way from the Internet to the CPE. Then you have got a dual-stack network. You are depending on both protocols until everyone transitions. If you do that, why should latecomers transition at all? Also, if everyone had to have dual-stack anyway, why use IPREF at all? Be aware that having GW on CPE means NAT/CGNAT on the operator's edge as it is now - if you do not have enough IPv4 public addresses to NAT on the GW. That can also be an issue.
> There is no dual stacks with IPREF. It works differently than traditional tools. I guess, we really have to build it, then it would be easier to show it. I have a working model but model is not as convincing as a bona fide gateway (which could be a software upgrade on existing routers).  For now, maybe a detailed walkthrough would help. I'm guessing you already read it in the draft?? In that case, let's leave it at that with me saying dual stacks are not required.
>>>> We already have the ability for IPv6 to connect to IPv6 to IPv4 using NAT64.  This can be run
>>>> with initiating traffic coming from both directions at the same time.  IPv6 on the public side
>>>> to IPv4 on the private side with static mapping and AAAA records in the DNS as well as the more
>>>> common use of dynamic mappings when running IPv6 only on the private side.  This has been done
>>>> for many years now.
>>> ...thereby reinforcing IPv4. You will never do away with IPv4 Internet
>>> this way.
>>> For as long as IPv4 Internet exists, the transition to IPv6 will never
>>> be completed.  Are you concerned at all that this may happen? Has there
>>> ever been a doubt in your mind that IPv4 might survive?  Is the fight
>>> over transition tools worth risking IPv6? IPREF transitions only to pure
>>> IPv6, it uses only pure IPv6 Internet. It removes IPv4 addresses.
>> IPREF doesn't do that either - you need the dual-stack connectivity for the GW. BTW, if you use SIIT-DC, you don't have to have IPv4 inside your content-providing network. If you use NAT64, you also do not have IPv4 in your network. In both cases, traffic going through the translator is only the one for that it is needed, not all the traffic.
> I guess, this is related to the comment above. Dual stacks are not needed. If you haven't read the draft, or read it quickly, there is a detailed walkthrough describing how packets travel over the different address spaces. At no point there is a need for dual stacks (gateways have them of course, but that's not what we're talking about here).

I'm talking about the WAN side of the IPREF GW! If you want to put it inside of the CPE, you absolutely need the dual-stack all the way between the Internet and the CPE/GW. Surprise, this means the whole ISP infrastructure had to be dual-stack. Now, as an ISP, if I have a dual-stack all the way to the CPE, why do I need IPREF then? I don't. I do provide dual-stack connectivity already, so I do not care if the customer is running legacy IPv4-only devices or did not configure IPv6 for some reason. Long story short, it is useless inside the CPE.

I have read the draft. Look at your figure in the section 4. What is the Network A? What is the Internet in it? If Network A is a home network, GWA is CPE, then the Internet includes the provider's network. Try to draw the same figure for yourself for the case where there are three networks (two dual-stack on WAN, one IPv4-only WAN - the IPv6 latecomer). Now, as long as there is an IPv6 latecomer connected, you cannot disable IPv4 on the WAN interface of the GWs. So you are not removing dual-stack; you are preserving together with the IPv4 Internet. It doesn't work; it cannot be placed into the CPE, and it makes no sense to do that. Draw it on the paper. You will see. If you don't see it, draw there also ISP devices between Network A and the Internet. Then, it must be apparent.