Hi all, Just a clarification for those that don’t follow v6ops.
I presented in v6ops a while ago a plan for all the NAT64-related documents (in total 6) to be moved to full-standard. Some of the require 2 steps as they were informational (now all them are already standards track). Of course, DNS64 is one of those documents. Consequently, last October, I’ve already prepared a new version of RFC6147 (-bis), starting from the XML available at the RFC Editor. This version that I’ve prepared is already including the implementation report, resolution of erratas, etc. However, decided to hold it until we advance in v6ops, which is progressing well. Initially I contacted the original authors using the datatracker email for the document, but later on discovered that those emails actually don’t work. So I will contact directly the original authors in case they want to take over the document or participate or whatever and suggest them to follow this discussion. Regarding the discussion my view is: 1) NAT64 in many situations requires DNS64, we like it or not. Even when is not required, it has advantages (see section 3.3.f connection optimization RFC8683). 2) It is a stable and mature protocol, widely implemented and deployed. 3) If the people deploys DNSSEC together with IPv6, DNS64 is not creating any trouble. It doesn’t make sense to me that DNSSEC is deployed without IPv6, right? 4) When DNSSEC is deployed without IPv6, in most of the cases no problems is created and what we probably want to encourage is to do DNS64 self-synthesis in the hosts if they are checking DNSSEC. See section 4.1 of RFC8683. 5) One of the issues of DNS64 is actually RFC7050, which was updated by RFC8880. In my experience RFC7050 is not widely deployed and instead there are now better ways to discover the NAT64 prefix, such as PREF64 (RFC8781) and PCP (RFC7225). Mobile networks have their own ways to configure the DNS (including DNS64). So probably a different discussion is if we should deprecate RFC7050, but I think it belongs to v6ops. So in summary, probably the key is advocate for both: self-synthesis and deployment of IPv6 when DNSSEC is deployed. I will continue following the discussion and see how the inputs can impact in my actual draft before formally submitting it. Regards, Jordi @jordipalet > El 10 abr 2026, a las 6:07, [email protected] escribió: > > Hi all, > > Brian clarified the point, but I'd like to remind the exact criteria required > by this process: > > The request for reclassification is sent to the IESG along with an > explanation of how the criteria have been met. The criteria are: > > (1) There are at least two independent interoperating implementations > with widespread deployment and successful operational experience. > > (2) There are no errata against the specification that would cause a > new implementation to fail to interoperate with deployed ones. > > (3) There are no unused features in the specification that greatly > increase implementation complexity. > > (4) If the technology required to implement the specification > requires patented or otherwise controlled technology, then the > set of implementations must demonstrate at least two independent, > separate and successful uses of the licensing process. > > Cheers, > Med > >> -----Message d'origine----- >> De : Brian E Carpenter <[email protected]> >> Envoyé : jeudi 9 avril 2026 22:21 >> À : Paul Vixie <[email protected]>; [email protected] >> Cc : IPv6 Operations <[email protected]>; Philip Homburg <pch-dnsop- >> [email protected]> >> Objet : [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147) to >> Internet Standard >> >> >> On 10-Apr-26 07:17, Paul Vixie wrote: >>> On Thursday, April 9, 2026 12:12:12 PM PDT Philip Homburg wrote: >>> >>>>> ... >>> >>>> >>> >>>> In my opinion we should strongly discourage deploying DNS64. >> So >>> moving >>> >>>> DNS64 to Internet Standard sends completely the wrong >> message. >> >> I'm very torn on that, because like it or not DNS64 is stable, >> well-defined, and widely implemented. (I'd also prefer to abolish >> the problem by abolishing the distinction between Proposed >> Standard and Internet Standard, but that's another story.) >> >>> >>> so, i agree, but: >>> >>>> DNS64 is incompatible with local DNSSEC validation. This >> combines >>> the > worst of both worlds: something doesn't work both because >> of >>> DNSSEC and > IPv6. >>>> >>>> New deployments of NAT64 should either use some kind of >> address >>> synthesis > in a library or deploy a CLAT. >> >> I don't think there's much disagreement with that. >> >>> we should not need new deployments of v6/v4 transition >> technology almost 20 years after june 6 2006, and it's time for >> the IETF to occupy that position. >> >> But we still do need co-existence for very practical reasons. >> That's why v6ops is developing the IPv6-mostly approach in draft- >> ietf-v6ops-6mops, which explicitly says: >> "Those concerns make DNS64 a suboptimal and undesirable solution >> long-term. >> To eliminate the needs for DNS64..." etc. >> >> So we might end up with DNS64 completely meeting the requirements >> for Internet Standard status and being operationally deprecated. >> Yes, it's a paradox. >> >> Brian >> >> _______________________________________________ >> DNSOP mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > ____________________________________________________________________________________________________________ > 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 -- [email protected] > To unsubscribe send an email to [email protected] ********************************************** 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 -- [email protected] To unsubscribe send an email to [email protected]
