Re: [v6ops] IPREF as a transitioning tool

waldemar <waldemar@wdmsys.com> Fri, 10 November 2023 11:40 UTC

Return-Path: <waldemar@wdmsys.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 26DB8C15C2BA for <v6ops@ietfa.amsl.com>; Fri, 10 Nov 2023 03:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.199
X-Spam-Level:
X-Spam-Status: No, score=-7.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wdmsys.com header.b="Ba3F5uQQ"; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b="Wx9vph1S"
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 FHrPH9mCWIsQ for <v6ops@ietfa.amsl.com>; Fri, 10 Nov 2023 03:40:25 -0800 (PST)
Received: from cat.pear.relay.mailchannels.net (cat.pear.relay.mailchannels.net [23.83.216.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0CDC1522AF for <v6ops@ietf.org>; Fri, 10 Nov 2023 03:39:57 -0800 (PST)
X-Sender-Id: _forwarded-from|217.96.228.89
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D545B101A30 for <v6ops@ietf.org>; Fri, 10 Nov 2023 11:39:56 +0000 (UTC)
Received: from outbound1a.ore.mailhop.org (unknown [127.0.0.6]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id C2BD3101A17 for <v6ops@ietf.org>; Fri, 10 Nov 2023 11:39:55 +0000 (UTC)
ARC-Seal: i=2; s=arc-2022; d=mailchannels.net; t=1699616395; a=rsa-sha256; cv=pass; b=7Mbt9az1EPw1GvCFeWHFPK2GlwWI/b3Gzt3i4V+2LV972S7zkCa2kPf/2KCfBDG6D83APN GbmZPfe0VFWdt+o8X70MSjFyIezMEC2GHAEIkyEagey/lKx3tAj6toSKQxbQBCdy3oenmK 8/r1oYzjbrB5JwnvYOVve7SWmIObt2XfJjnyCSgeB7F4RBqSzyAKeaVDVIvxN/HDSAjDLq MHg9HavdWbm0hh+T+RgmOiK1NyzxUMUZwEg/mHou0Ie1lbYrr8YBXUGRrfdDAsu5IpBskz CQqVYPj/kdyGIYv40yfyAlEdJ80ViY5YQiRVsGEAuTb2dro44xGYBhjbNfdStA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1699616395; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0R/DyoVBPfx+vz6Y109faVQf+znK4LoLIeomhU3Igis=; b=fSu4yyoAzvn2o9sC0w4adE5yZ8MTJKyTHbq9M5e/a/AH1IU70UyEaYyT5GWgyPYFz6/mgh oHAy+Qcy408I37uswYHkPV/orvwm61FkNcRt3XqyqSAhaJuyrCrMf6q9QrJe24GbXwY/n7 usaAEYuHGBswqao3ZmaJgML5DalgaXqi2NdyKPKk3MFuRVG0hz1fbs9eV7felYw/+6MEG2 AmGwFbS7QPnpI1yOX/gMjUB1cRSbri2On3we8uhKhuYnv1nTGzYx1TyLix2nqrhdloryDg 2oPrcYMIA21nCmvw19NjRmrgRt1IGEw1VR5SriR1utRCr5QYfI7UNZJGIcvJ1g==
ARC-Authentication-Results: i=2; rspamd-6c48c794c6-84zhg; arc=pass ("outbound.mailhop.org:s=arc-outbound20181012:i=1"); auth=pass smtp.auth=duocircle smtp.mailfrom=waldemar@wdmsys.com
X-Sender-Id: _forwarded-from|217.96.228.89
X-MC-Relay: Forwarding
X-MailChannels-SenderId: _forwarded-from|217.96.228.89
X-MailChannels-Auth-Id: duocircle
X-Tasty-Desert: 581f07d568dad88d_1699616395985_3846985443
X-MC-Loop-Signature: 1699616395984:39857221
X-MC-Ingress-Time: 1699616395984
Received: from outbound1a.ore.mailhop.org (outbound1a.ore.mailhop.org [54.213.22.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.112.201.10 (trex/6.9.2); Fri, 10 Nov 2023 11:39:55 +0000
ARC-Seal: i=1; a=rsa-sha256; t=1699616395; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Rg14i+VDUaAzW8uxm7kyKlVrGnINXcYbhCWPomVM3iM4axwgbE3fkL7YGvn9Vnymceb5XC9DoRelQ 132JPpFIT6INeDZgechUQ1R+T4+T7JuSoZV2j1dseqUCYnpfSC0DRb3LIfxS++3n0CPyYlh/g8mI1u AVR2sa5s3/mqH9+d8HYfIjph0ksKcyGOckMMuDGlhTHyaeIqAfVeaYkqS8hOzk7v3coc+Jk5np4S3D pzd6P6EM+Cied7yzj6qvElm5MXmq/KDEr0eeaiUtTlXyceSRbnSB5ra7J6UyKPN5g+2cS8Ik184JR1 AHxVhFpQvY03TV2FEdTxiqmlgLbRYGQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:from:references:cc:to: subject:mime-version:date:message-id:dkim-signature:dkim-signature:from; bh=0R/DyoVBPfx+vz6Y109faVQf+znK4LoLIeomhU3Igis=; b=aSESjjmna5vBhkiqkInG0Q67K1Gje4T6VX3FRus7oQONv8a3ZrNte8bkFgOahHn+bfigJ2wdhbTPu Qw3Oww7M+OhrauicPMea4B8szzPVrAdO9pYR0ARpNvj2TXEBBFU1IP1ciP9DLdRWfreaemGJbWpor8 B2O3qZLjxDF0jMpdhVknTu1gh3upisPvIFlTaOcJLg6rS4EhnuCryG6CamYFJrnCYnt41hFlXYayLy 5ImhjFvwf0v4aHHfawRn5yYkqujFw7GMckra0suc07dGO4DTVSoWoVv7l2heD8YkBSNUR+M9R/Bkxd KxNbFN8OPsgaUpcIfgzLmulfK0riOVw==
ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=wdmsys.com smtp.remote-ip=168.235.72.19; dmarc=none header.from=wdmsys.com; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wdmsys.com; s=duo-1675405977089-29a98ead; h=content-transfer-encoding:content-type:in-reply-to:from:references:cc:to: subject:mime-version:date:message-id:from; bh=0R/DyoVBPfx+vz6Y109faVQf+znK4LoLIeomhU3Igis=; b=Ba3F5uQQYO8B+0EIvRd+kA2rC9tPj8DRX6ipt1qAMqnekgHz/WvFf/bnDCVAaCI0Q3rg0sDqhKVkw QLeVAMCQo+vUnM4oIgKA4gXX9/clDVxLWLkBPgyDzeSgJl4pJKoN/6rfLauR3HEMCo3tvLbn+z8JED Ww5WqAph5p8PV3j4=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:from:references:cc:to: subject:mime-version:date:message-id:from; bh=0R/DyoVBPfx+vz6Y109faVQf+znK4LoLIeomhU3Igis=; b=Wx9vph1STMAjxJs1NZ8GE3z/LvIVLlx86bSF/ZUfxFHqdH9W6R/H0vacFzo5M/z7fpWVJ6s13rmxe D4RdSgzh04wCxN6LCbhCjUkjc9ZYzVxLk+BGQCpcaedtCknCjszFH6CFPcHOuT+nbU4qzqPNH1ah1J UJ/n0otv/908BVURA/sCMMtMTJuuI6VMzM94mUJYkytITJ8dQfyCNnMxpYoJpncepK2mQuT7jJNl7d atnCP+Leez3C656uNRYPthKMAI2cCuQ4CTnvzQnWoKiiY9iQIAMKL96H4Q0t1OKypv5il0YrnRJopi 9+7nrn5n8pEBV/EipTp/Wr05Ty5jOjw==
X-Originating-IP: 168.235.72.19
X-MHO-RoutePath: d2FsZGVtYXI=
X-MHO-User: da529650-7fbd-11ee-8626-d1581f149e9f
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from cmail.wdmsys.com (168-235-72-19.cloud.ramnode.com [168.235.72.19]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id da529650-7fbd-11ee-8626-d1581f149e9f; Fri, 10 Nov 2023 11:39:53 +0000 (UTC)
Received: from 217.96.228.89.ipv4.supernova.orange.pl ([217.96.228.89] helo=[192.168.1.13]) by cmail.wdmsys.com with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <waldemar@wdmsys.com>) id 1r1PrY-000e1X-1Q; Fri, 10 Nov 2023 11:39:48 +0000
Message-ID: <9587b3ef-464e-b053-7994-c09609eded8b@wdmsys.com>
Date: Fri, 10 Nov 2023 03:39:44 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
Content-Language: en-US
To: Mark Andrews <marka@isc.org>
Cc: Martin Huněk <martin.hunek@tul.cz>, v6ops@ietf.org
References: <90f07ffa-1f44-8fa6-a6eb-b35c14fcf655@wdmsys.com> <11220775.0j3nEXixpK@asclepius.adm.tul.cz> <df800110-7ee4-23d8-e11f-c6e1e32e8edc@wdmsys.com> <33892F6F-A2AF-4BAA-BB33-1ED99F9FD674@isc.org> <442536ba-f736-5106-615c-7fcc0b8dc2a1@wdmsys.com> <5BACA7CB-F37B-4AE8-A33A-9F29F93A46DD@isc.org>
From: waldemar <waldemar@wdmsys.com>
In-Reply-To: <5BACA7CB-F37B-4AE8-A33A-9F29F93A46DD@isc.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/dHAj4S-Oogb5ULw7IuhCAPGFgTE>
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 11:40:30 -0000

As a general note. I don't take these emails as criticism necessarily. I 
take it as points to consider, looking for issues, and the likes. I 
built a model which I tested which makes me very comfortable with many 
issues raised here and in other emails. But the model does not cover 
everything, it is useful to know where others see possible issues.

On 11/10/23 02:20, Mark Andrews wrote:
>
>> On 10 Nov 2023, at 19:30, waldemar <waldemar@wdmsys.com> wrote:
>>
>>
>> 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.
> It has the same scaling issues.  The mechanism in IPREF is exactly the same.  Gateway/NAT64 picks
> an IPv4 address to talk to the IPREF/IPv6 address using a to be defined protocol.

The mechanism is different. IPREF relies on underlying network 
protocols, thus it is as scalable as those network protocols. There is 
no protocol to define. The use of references is deliberate. It is a 
subtle point but very important: IPREF does not define any new address 
spaces, or meta-spaces. Instead, it always refers to existing addresses 
and uses existing network protocols for forwarding. When a destination 
is beyond reach of a local network protocol (because of NAT or cross 
protocol), the packet ends up at a gateway. The gateway runs dual stacks 
and moves the packet over to the other address space where it 
reinterprets the IPREF address, which are pointers to existing 
addresses, and hands it down to the network protocol employed at that 
address space. It repeats until a network protocol at this new address 
space recognizes the address pointed to by IPREF address as its own. It 
then delivers the packet locally.

This is described in detail in the draft:

https://datatracker.ietf.org/doc/draft-augustyn-intarea-ipref/

and also in a markdown doc:

https://github.com/ipref/ietf/blob/main/how-ipref-works-in-detail.md

>
>>> 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.
> No.  Sites with IPv4 only devices install NAT64 with a modified DNS server which to talk to the IPv6 internet
> and publish AAAA records for those devices.  This is no different to you wanting them to install a IPREF
> gateway and publish AA records.
It is different because it allows to remove IPv4 Internet early.
>
>
>>>> 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.
> So the host asks the recursive server for A records.  The recursive server lookups up IPREF address.
> It talks to the IPREF gateway that returns a IPv4 address.  The resolver returns the A record for
> that address.  That does not work with DNSSEC as the resolver cannot generate a valid RRSIG.

I don't know DNSSEC that well. I rely on an opinion of a person that 
does. He says, IPREF is fine. Looks like this may need further 
discussion, hopefully we'll get far enough for it to take place. The 
person i talked to mentioned that new RR, such as AA, would simplify 
things for DNSSEC. I'll let you evaluate if it makes any difference. I 
will add that the returned address actually does appear on the network, 
unlike DNS64. I certainly don't want to use DNS64 precedent to ram 
another non-compliant solution through. I am hoping DNSSEC recognizes 
that when dealing with cross protocol communication, some sort of 
transformation is unavoidable at some point. In case of IPREF, there is 
an additional, unappealing option of making hosts IPREF aware. I don't 
want to go that path. (Maybe later, way later).  A somewhat less bad 
option is to make *hosts* use modified resolvers. That would make DNSSEC 
happy but I would think there must be some way to aggregate it for local 
networks. Does DNSSEC attempt to protect against rogue actors on 
internal networks? Anyway, this discussion should probably be moved to 
DNSSEC when time comes.

[snip]
>>> 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.
> Which they can’t disable until *every* site is running IPREF or are willing to leave behind legacy servers/clients.

I would think they would not want to disable them anyway. But let's 
leave that discussion for later.

The idea is to take IPv4 Internet down at the earliest. So yes, this 
will result in leaving some procrastinators behind. With IPv6 Internet 
serving them well, and their IPv4 servers and clients still functioning, 
we'll call it a deal. After all, they can do whatever they want, so more 
power to them.

>