Re: [v6ops] IPREF as a transitioning tool

Martin Huněk <martin.hunek@tul.cz> Fri, 10 November 2023 15:31 UTC

Return-Path: <martin.hunek@tul.cz>
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 3D638C16F419 for <v6ops@ietfa.amsl.com>; Fri, 10 Nov 2023 07:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (2048-bit key) header.d=tul.cz
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 Pa6QdZDcCRW8 for <v6ops@ietfa.amsl.com>; Fri, 10 Nov 2023 07:31:25 -0800 (PST)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A033C16F3EF for <v6ops@ietf.org>; Fri, 10 Nov 2023 07:31:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.adm.tul.cz (unknown [IPv6:2001:67c:370:128:e5e2:2942:e535:3e94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 23B091803AD64; Fri, 10 Nov 2023 16:31:18 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 bubo.tul.cz 23B091803AD64
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tul.cz; s=tul2021; t=1699630278; bh=SnJ8/D5yz9Ucun2psXl69VeT5NjGYxFpULOELg0XSvI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CqVVS9yJ1Ub6TaouBRwAOI+HB+lZ5GptlX4eGbqSgy0EbJ3ITPRV91ivwcRN08wri TJMQ7nHDkmsqPSfG/zUz1H4TIzN/X/29QkhU6aiX1CfwnDAN26rG44FUqf/o5wkYUi dHTTB+9M6BOg9ZyUFONmqkRImnvZo7uKx03Nk0HO7aYbbKk/IcFXtZPdcZ723E2NFx MEoCO05jT69RW8Z8frl/OAzZAy+WrlL8kp105yqVIKFIA7+jxswNXpxcOl9DjzpiaE nJLC8Ih8iT7+ukfUPyGnBbZ7ehvsQWHy7Li0ChubFY8KCvBCxhsjpI92VretRqFsgW Vpqa0YNXw5Qsg==
From: Martin Huněk <martin.hunek@tul.cz>
To: Mark Andrews <marka@isc.org>, waldemar <waldemar@wdmsys.com>
Cc: v6ops@ietf.org
Date: Fri, 10 Nov 2023 16:31:11 +0100
Message-ID: <1964267.2dr1X8vxzf@asclepius.adm.tul.cz>
Organization: Technická univerzita v Liberci
In-Reply-To: <442536ba-f736-5106-615c-7fcc0b8dc2a1@wdmsys.com>
References: <90f07ffa-1f44-8fa6-a6eb-b35c14fcf655@wdmsys.com> <33892F6F-A2AF-4BAA-BB33-1ED99F9FD674@isc.org> <442536ba-f736-5106-615c-7fcc0b8dc2a1@wdmsys.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2717531.J6c7kFTM0d"; micalg="sha384"; protocol="application/pkcs7-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/aFSDgMJoH9IJenlNws005bR0KKM>
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: Fri, 10 Nov 2023 15:31:30 -0000

Hi,

If it is required in every network in the whole Internet, then it is a blocker, isn't it?

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.

> >
> > 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.

Regards,
Martin
> 
> >
> >> On 10 Nov 2023, at 14:13, waldemar <waldemar@wdmsys.com> wrote:
> >>
> >>
> >> On 11/9/23 17:12, Martin Huněk wrote:
> >>> Hi,
> >>>
> >>> I'm missing these parts:
> >>> - How this technology would interact with the networks that would not use IPREF.
> >> It wouldn't. Gateways are needed on both ends. You should think of GWs as a software upgrade on the edge routers, although stand alone gateways make sense in certain configurations, too.
> >>> - How the GWs would know when to switch to the IPv6 on the Internet.
> >> They wouldn't. The servers would advertise addresses with IPv6 context addresses. GWs don't choose, the endpoints do.
> >>> - What about DNSSEC?
> >> This was discussed (offline). No issue here. Unlike NAT64, IPREF actually places the exact returned addresses in the packets. It does encode them for local hosts, which are unmodified, but GWs decode them back to their original values when sending out of the network. Also, there is a proposal for a new RR which would simplify things for DNSSEC.
> > But you have the DNS synthesising A records.  This does not work with DNSSEC.
> No, I don't.  DNS returns what is configured. It does not do any address 
> processing. And, it does work with DNSSEC. The paragraph below indicates 
> that because hosts are unmodified, thus don't understand IPREF 
> addresses, the resolver must encode them. The gateways then restore them 
> when the packets reach them. There is no synthesis, just dealing with 
> unmodified hosts.
> >
> > 3.2. Local Network Resolvers
> >
> > Local network resolvers must recognize IPREF addresses returned by DNS queries.
> > They must also be capable of encoding them into native IP addresses in consultation
> > with IPREF gateways. This is shown in Figure 4 as a line connecting local DNS resolver
> > with IPREF gateway GWA. Encoding is needed because local hosts do not understand IPREF
> > addresses. Instead, local hosts use encoded equivalents which are then replaced with
> > the actual IPREF addresses by the gateways. There may be a need to standardize on how
> > resolvers communicate with gateways.
> >
> >
> >>> - What benefits does it bring to the network that already did the transition?
> >> They would be able to communicate with those that did not, or with some more exotic or experimental networks like SCION. IPREF also allows peer networking. Dealing with references might be viewed as easier than dealing with IP addresses.
> >>> 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.
> >> A lot is still less than all.  Dual stacks prevent taking down IPv4 Internet. The hope that somehow everyone switches  to IPv6 and we can take down IPv4 is a mirage.  These existing technologies perpetuate IPv4. They will never be able to eliminate IPv4 Internet.
> >>> 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.
> >> As mentioned above, DNS replies are not modified. DNSSEC is fine.
> > You are mistaken. Section 3.2 requires NODATA being turned into records.  This does not work with DNSSEC.
> >>> 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.
> >> The opposite is true. It is the existing transition technologies that give operators tools to not implement pure IPv6. IPREF transitions only to pure 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.
> >> Dual stacks is a huge problem. They re-enforce IPv4. These technologies you mention will never be able to do away with IPv4 Internet.
> >>>> (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.
> >> IPREF will eliminate NAT, NAT6, and CGNAT, albeit not the first thing that will happen. ISPs running dual stacks?? Yeah, exactly. We need to do away with it. IPREF is 100% customer premise technology, ISPs don't need to do anything, just provide pure IPv6 Internet.
> > And how is this different to ISPs providing IPv6 only connections like they do today with ISP NAT64 (which fills the role of the missing IPPREF gateway at the other end). You can publish AAAA records in the DNS which are mapped to internal IPv4 addresses through a NAT64 on the CPE.
> Those gateways are not needed thus freeing ISPs from maintaining 
> unnecessary services.
> >
> >>>> 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.
> >> Yes, it is in a vulnerable stage for the moment. There is no way to convince doubters without advancing it by building a GW and demonstrating results. But what else is new?
> >>> Regards,
> >>> Martin
> >>>> _______________________________________________
> >>>> v6ops mailing list
> >>>> v6ops@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/v6ops
> >>>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> v6ops@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
>