IETF Logo Mail Archive

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

Philip Homburg <pch-dnsop-7@u-1.phicoh.com> Wed, 15 April 2026 07:06 UTC

Return-Path: <pch-b55F8B228@u-1.phicoh.com>
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 D508FDC8DF91; Wed, 15 Apr 2026 00:06:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776236812; bh=wXOSIUoJJH4zO1N02+wzgNB4Z3mlFMTYye4GrFEdT2k=; h=To:Cc:Subject:From:References:In-reply-to:Date; b=pVj/F/8JlNmQj3fj0If4g9EE3/fATkNbdZgA7dccg46VnppMFoUwVnmW6cremEM+C ZgUMIWgsmKlRo/cKoyBBL2rqeXCXKCC+dwE/Cvm1sJSV9pTFKWbqRz45KFjQc8v1CX VzdCg+aqbENRLnCFIYZEML+ILq+vvbD7bY/LUox4=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 5TPLhJxF8RzU; Wed, 15 Apr 2026 00:06:52 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [IPv6:2a10:3781:2413:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-ECDSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 1B281DC8DD39; Wed, 15 Apr 2026 00:04:28 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305) (Smail #158) id m1wCuIR-0000Q7C; Wed, 15 Apr 2026 09:04:23 +0200
Message-Id: <m1wCuIR-0000Q7C@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-7@u-1.phicoh.com>
Sender: pch-b55F8B228@u-1.phicoh.com
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> <m1wB6jW-0000VYC@stereo.hq.phicoh.net> <25022.1775841874@obiwan.sandelman.ca> <m1wBGFD-0000PhC@stereo.hq.phicoh.net> <5539.1775850116@obiwan.sandelman.ca> <m1wCHUo-0000QZC@stereo.hq.phicoh.net> <5A969A5C-EE2A-4581-AAC3-20A1423D0D43@consulintel.es> <m1wCi0t-0000Q7C@stereo.hq.phicoh.net> <BEC52137-2556-45A7-9859-695086C1E9D7@fugue.com>
In-reply-to: Your message of "Tue, 14 Apr 2026 20:31:55 +0200 ." <BEC52137-2556-45A7-9859-695086C1E9D7@fugue.com>
Date: Wed, 15 Apr 2026 09:04:23 +0200
Message-ID-Hash: LKIO3YFJ6WEQNHCRA5VS4LBXHHQTMA55
X-Message-ID-Hash: LKIO3YFJ6WEQNHCRA5VS4LBXHHQTMA55
X-MailFrom: pch-b55F8B228@u-1.phicoh.com
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: Ted Lemon <mellon@fugue.com>, IPv6 Operations <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [v6ops] Re: Re: 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/hpcWC75kaEtk01kf5uSO_iCj8qY>
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>

> But my point is, your printer that's downloading firmware probably
> isn't doing DNSSEC validation, although it should, and it's probably
> not using DoH to bypass the local resolver either.

That is true. So at first glance it seems simple, recommend that 'complex'
hosts provide CLAT and leave relying on DNS64 to simple hosts the printer.
(Though I suspect that in these modern times printers are a lot more complex
than something that just sometimes download new firmware).

Assume a complex host with CLAT and an application that is written for
dual stack. The nice thing about CLAT is that the application doesn't have
to care. It sees IPv6 native and IPv4 behind NAT.

The application tries to connect to a server that happens to be IPv4-only.
As usualy for dual-stack applications, the application's stub resolver issues
A and AAAA queries. The application will get an answer to both queries.
A records with the IPv4 addresses of the server and AAAA with IPv6 addresses
that are synthesized by DNS64.

Thie first questions is what the effect of this will be on happy eyeballs or
the other way around, what the effect of HE will be on NAT64? If HE
connects to IPv6 and IPv4 sort of in parallel then the NAY64 part may get
more flows than without DNS64.

The goal of NAT64 is to provide access to the IPv4 internet with all of its
complexity. So we can assume an application that uses STUN.

A simple dual-stack application may do STUN for IPv4 and assume that IPv6 is
not behind NAT. For this reason the application may strictly prefer IPv6
addresses. In this case, the application will receive an IPv6 address,
however the address is behind the NAT64 part. How does an application deal
with that? Do we have specs? 

One easy way out is that applications allways prefer IPv4. I'm sure that
will make a lot of people unhappy. This will also generate additional load
on the NAT64 part for servers that have IPv6 support.

The best solution in this case is to get rid of DNS64.

v2.43.4 | Report a Bug | By Email | System Status