[DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147) to Internet Standard

"jordi.palet@consulintel.es" <jordi.palet@consulintel.es> Mon, 13 April 2026 13:39 UTC

Return-Path: <prvs=1563c5a74c=jordi.palet@consulintel.es>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8638ADB37C66; Mon, 13 Apr 2026 06:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776087587; bh=daAfJ/pKj51cnzplQtwTxVhYUFeBkBm8UV+agMh4glo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=FLFwtjRWJbOka7y+3g/0CTVA2Y1weRBVyMVOp531izi4a97rtYxwgFyTP9mZHCCxO 2x4xtHsY6YOWyjDOBwtZQAHTMnh6VZ1mvkx1RhLg5VAD9tpNFVxGdbOP8FAwTUy/l4 2636TOf1+Mh0WhM1pzCopeVd3OYNOFBTbfshhbDc=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=consulintel.es
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVJb9CVKHcOz; Mon, 13 Apr 2026 06:39:46 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7C8E1DB37BC4; Mon, 13 Apr 2026 06:39:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=consulintel.es; s=mailer; t=1776087564; x=1776692364; i=jordi.palet@consulintel.es; q=dns/txt; h=From:Message-Id: Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To: References; bh=BRpNH0jhLtkcY63soV9lnxmHt1VJRd8mZVsOaqoA4tE=; b=d JcEWu3mUqO1F/PCkhvHMfKnC7RXBFO9jYlYcwZLGgHyVBlRfSQOT1H7yULg/uosa t5zLrCg+/9MI0H5Yrod0EDLw/PoamH5mhZAjUl1KxoImam2VOzazQXwHf0nzXrPk V8p1dNYQtDj9lDpyLj8kn/coEI4/kHDCvhvR4EIFEM4fgwFhNoo+O9OhvChWWS6I 51/xE2hE1PBL87bC5BtEJbhH5w/q1Zh6OFGKVJXkoIvREqdOwx1LtKyRWe9tGW+i +HfIMGJ8foUfyl7jkY1cQpD7GKVAysZn0SxccS6uLUNSFTc8vyM3LP1q4hqGNa4l 4g8PqxGuAm372gU5VBCHA==
X-MDAV-Processed: mail.consulintel.es, Mon, 13 Apr 2026 15:39:24 +0200 (not processed: message from trusted source)
X-Spam-Processed: mail.consulintel.es, Mon, 13 Apr 2026 15:39:24 +0200
Received: from smtpclient.apple by mail.consulintel.es (10.10.10.5) (MDaemon PRO v25.5.0) with ESMTPSA id md5001002622665.msg; Mon, 13 Apr 2026 15:39:23 +0200
X-MDRemoteIP: 2001:470:1f09:495:39c0:8573:a909:1d84
X-MDArrival-Date: Mon, 13 Apr 2026 15:39:23 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1563c5a74c=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
From: "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>
Message-Id: <21065661-AF82-44B9-9F1B-95EC244EBDEA@consulintel.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9F436B6A-4574-4519-B0F0-EDA8A36B87B6"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\))
Date: Mon, 13 Apr 2026 15:39:11 +0200
In-Reply-To: <DB9PR07MB7771839D4A9F2D4380926DCCD6242@DB9PR07MB7771.eurprd07.prod.outlook.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
References: <m1wAunU-0000NEC@stereo.hq.phicoh.net> <2338256.t9SDvczpPo@localhost> <038ae9d1-34fc-4085-aa6d-76ef79287857@gmail.com> <PARP264MB6760A67BB8F2060962E8A64088592@PARP264MB6760.FRAP264.PROD.OUTLOOK.COM> <B93DB6C8-2974-4915-93DE-DFCB6B858AFA@consulintel.es> <21557.1775841053@obiwan.sandelman.ca> <DB9PR07MB7771839D4A9F2D4380926DCCD6242@DB9PR07MB7771.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3864.500.181)
X-MDCFSigsAdded: consulintel.es
Message-ID-Hash: I2NXJQHGDEQSWR6LGOOZRAD3VTQCOBPR
X-Message-ID-Hash: I2NXJQHGDEQSWR6LGOOZRAD3VTQCOBPR
X-MailFrom: prvs=1563c5a74c=jordi.palet@consulintel.es
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IPv6 Operations <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147) to Internet Standard
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OKwnpPFn0X0kUy61esy-9jvMHgI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

However, if implemented for self-synthesis (no need to change the protocol), usage will increase (at least while we still have IPv4-only services), and there is no any risk or harm.

Actually will be good if it becomes a MUST for draft-ietf-6man-rfc8504-bis.

In any case, my main point is still if people that implemented it in the network has actually got broken DNSSEC. I haven’t seen that.

Regards,
Jordi

@jordipalet


> El 13 abr 2026, a las 15:27, Tim Chown <Tim.Chown=40jisc.ac.uk@dmarc.ietf.org> escribió:
> 
> Hi,
> 
> I’m minded NOT to advance DNS64 to IS.  Pretty much exactly for the reason implied in Michael’s final paragraph below.
> 
> It is widely implemented, and there are multiple implementations, but at the same time there very much is​​ a health warning to be carried with it, and its use will (hopefully) decrease over time.  It served a purpose, but we’ve learnt and moved on.
> 
> We need that health warning to be clearly stated, noting that DNS64 serves a purpose (with caveats) particularly for devices that will never see a host-based shim supported, as Michael points out.
> 
> Tim
> 
> On 10/04/2026, 18:12, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:
> 
> 
> DNS64 should be advanced to IS, but it can include (IESG or author) notes
> that *hosts* should aim to move to PREF64/etc. as written extensively in
> RFC8683.
> 
> It's very useful for networks to be able to deploy DNS64 for hosts that are
> either older (or are dual-stack capable from 2003, but operating IPv6-only),
> or which want to have *no* IPv4, or whose local infrastructure becomes v6-only.
> (They really only need a CLAT if they have v4-literals. I've run lots of
> v6-only hosts for ~15 years, long before CLAT)
> They do DNS requests to a local recursive nameserver (whether Do53 or
> DoX), on which DNSSEC and AAAA-synthesis occurs.
> 
> There are *many* reasons to have such older hosts, and to *not* do major upgrades.
> For instance, because they support applications deployed to systems that are
> not, or never replaced: embedded systems for buildings, aircraft, ...
> Remember, "host" can be a VM, or a even just a container.
> 
> {Many decades ago, when a WGA at BNR, I found a "devops" guy with what was
> already a super ancient HP9000 series 300 workstation on/under his desk.
> Because that was the build system for one generation of DMS-10.  His
> email/cocos wouldn't work anymore.  He got an NCD X-terminal that afternoon,
> and this critical build system got moved to the data center room.  We
> considered if we should/could do that without cutting the power to it, as it
> also hadn't rebooted in ~6 months.  It was fine}
> 
> So while DNS64 should be deprecated for hosts going forward, it needs to be
> available as network infrastructure (in a trade-agreement compatible RFP'able
> way) for some time.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> **       My working hours and your working hours may be different.         **
> ** Please do not feel obligated to reply outside your normal working hours **
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list -- v6ops@ietf.org
> To unsubscribe send an email to v6ops-leave@ietf.org



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.