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

Philipp Tiesel <phils@in-panik.de> Wed, 29 April 2026 12:06 UTC

Return-Path: <phils@in-panik.de>
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 46C06E59A78B for <dnsop@mail2.ietf.org>; Wed, 29 Apr 2026 05:06:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1777464383; bh=84WG/D3X+ZqBx32D6UMNqZF3GlXGpuAQRwUvfNnitPI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=ic7unhXITC1jnzD6sesIWRqrvxmFrmNPg6kmGQRMSTAbQCzHfNEPNQ0n+9Cu8Ytbf 2+3cCa06pek+fgv/q5pD+tB7fsddix4z9xKGVm/DMz7OGEO3mRvLaZfGBDoO9DDuvw aS+Xz+cGlWDUPXn9HEClokxSaLkWz6jwuoh+BrbE=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.495
X-Spam-Level:
X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001] autolearn=no 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 SpROUxWlJ1xV for <dnsop@mail2.ietf.org>; Wed, 29 Apr 2026 05:06:22 -0700 (PDT)
Received: from einhorn-mail-out.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (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 D914EE59A77D for <dnsop@ietf.org>; Wed, 29 Apr 2026 05:06:21 -0700 (PDT)
X-Envelope-From: phils@in-panik.de
Received: from x-berg.in-berlin.de ([IPv6:2a0a:4580:1018:0:5054:ff:feb2:aa6a]) by einhorn.in-berlin.de with ESMTPS id 63TC6DDv402930 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 29 Apr 2026 14:06:13 +0200
Received: from x-berg.in-berlin.de ([217.197.86.42] helo=smtpclient.apple) by x-berg.in-berlin.de with esmtp (Exim 4.94.2) (envelope-from <phils@in-panik.de>) id 1wI3gC-0002yV-Gq; Wed, 29 Apr 2026 14:06:12 +0200
From: Philipp Tiesel <phils@in-panik.de>
Message-Id: <D524EBF9-7845-413A-B3E9-3346647A4C93@in-panik.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1DB1D0EE-C903-4E63-ADC4-6977A1304519"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Date: Wed, 29 Apr 2026 14:06:02 +0200
In-Reply-To: <8FD551CE-3845-4747-874D-3654A2B5DF9B@consulintel.es>
To: "jordi.palet@consulintel.es" <jordi.palet=40consulintel.es@dmarc.ietf.org>
References: <PATP264MB67651000762E5D35C00D6EA888582@PATP264MB6765.FRAP264.PROD.OUTLOOK.COM> <PATP264MB6765DF96FD91CD7DA986159E882B2@PATP264MB6765.FRAP264.PROD.OUTLOOK.COM> <8FD551CE-3845-4747-874D-3654A2B5DF9B@consulintel.es>
X-Mailer: Apple Mail (2.3864.600.51.1.1)
Message-ID-Hash: NEPMIY3SWNDPLNEYHZGHORV3663CK7ZD
X-Message-ID-Hash: NEPMIY3SWNDPLNEYHZGHORV3663CK7ZD
X-MailFrom: phils@in-panik.de
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>, dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: (Concluded) 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/U8UqoLgd9M22xVUA8KYkQfy-KEw>
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>

Hi Jordi,

We might take that chance to include a proper description of local synthesis into the -bis
As it is mostly the same algorithm ad DNS64 without the undesired side effects. 
That way, we get a proper reference for Happy Eyeballs instead writing “similar to bump in the stack”.

Happy to contribute text if there is something to merge it into.

AVE!
   Philipp

> On 24. Apr 2026, at 12:44, jordi.palet@consulintel.es <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:
> 
> Hi Med,
> 
> We are already working in an update of the -bis that we have prepared, having in mind the recent discussions.
> 
> Regards,
> Jordi
> 
> @jordipalet
> 
> 
>> El 24 abr 2026, a las 12:26, mohamed.boucadair@orange.com escribió:
>> 
>> Hi all,
>>  
>> Thank you all for the constructive comments and feedback.
>>  
>> There is no consensus to proceed with an administrative status change. There are some contentious points and other aspects that are better addressed/clarified by having a bis document. If the original authors or any other volunteers are interested in that work, note that this is not covered by V6OPS charter and that work is to be brought to DNSOP like any other DNS-related individual contribution.
>>  
>> Cheers,
>> Med
>>  
>> De : mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>>
>> Envoyé : jeudi 9 avril 2026 18:19
>> À : IPv6 Operations <v6ops@ietf.org <mailto:v6ops@ietf.org>>; dnsop <dnsop@ietf.org <mailto:dnsop@ietf.org>>; Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>
>> Objet : [v6ops] Moving DNS64 (RFC6147) to Internet Standard
>>  
>> Hi DNSOP/V6OPS, 
>>  
>> V6OPS is in the process of progressing several widely deployed IPv6-related features into Internet Standard (e.g., [1]). There is an ongoing WGLC for NAT64 (RFC6146) to move it to IS. Although there is no strong dependency between NAT64 and DNS64 (RFC6147), DNS64 is usually deployed in networks that host NAT64.
>>  
>> Brian raised a question about the plan for RFC 6147 [2]. Given that DNS64 is also widely implemented and deployed and that there is only one minor erratum that does not impact interop [3], I think that we can proceed with a status change for RFC6147 and progress NAT64/DNS64 as a set this round as well.
>>  
>> Please share you thoughts on this plan by 23/04/2026.
>>  
>> Cheers,
>> Med
>>  
>> [1] https://mailarchive.ietf.org/arch/msg/v6ops/x1UNhtW1qkMpBh_27a1G_4JctHU/
>>  
>> [2] https://mailarchive.ietf.org/arch/msg/v6ops/G35ha3lL_tK2hSWVATiTnPXLaKc/
>>  
>> [3] https://www.rfc-editor.org/errata/eid2975
>>  
>> ____________________________________________________________________________________________________________
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>  
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>> ____________________________________________________________________________________________________________
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>> _______________________________________________
>> DNSOP mailing list -- dnsop@ietf.org <mailto:dnsop@ietf.org>
>> To unsubscribe send an email to dnsop-leave@ietf.org <mailto:dnsop-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.
> 
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org