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

["[e-mail]" <[e-mail]>]

Hi Nick,

I guess you mean RFC9872. Re-reading the document, it is clear to me that the main point of the document is moving away from RFC7050, which I agree.

I already mention several times, that in my experience is not being used in 99,99% of the deployments, but I will love to hear from others experiences if I’m wrong. For example, mobile networks have their own 3GPP standards to configure the DNS servers.

Considering what I’ve mention already a few times in this thread, I don’t see actual *real* breach of DNSSEC so in that sense I think the sentence at RFC9872, is too strong and not realistic if compared with actual worldwide experience (unfortunately I missed that specific text during the discussion of RFC9872). Anyway, once more, I will like to hear from others real experience in production deployments where we can see reality on this.

Also, as I indicated already, RFC6147 “as a protocol” doesn’t have such disadvantages, it all depends on how you deploy it. Which is the same for *any other protocol*. Again, happy to hear otherwise.

And last, but not least, as said by several people, we could add implementation/deployment recommendations in RFC6147, such as self-synthesis, etc., yes, but that doesn’t change the protocol itself (not breaking backwards interoperability), so don’t prevent moving to IS.

Regards,
Jordi

@jordipalet


> El 10 abr 2026, a las 20:44, Nick Buraglio <[e-mail]> escribió:
> 
> One data point to consider here - RFC 8972 does state:
> 
> "Migrating away from DNS64-based discovery also reduces dependency on
> DNS64 in general, thereby eliminating DNSSEC and DNS64
> incompatibility concerns (Section 6.2 of [RFC6147])."
> 
> Given that we are actively recommending a newer mechanism to eventually replace DNS64, at least for prefix discovery, and recommending local synthesis, does that change the conversation of advancing RFC 6147? Should we be advancing a document that creates the underpinnings that we're trying to move away from? 
> 
> nb
> 
> 
> 
> 
> On Fri, Apr 10, 2026 at 1:09 PM Philip Homburg <[e-mail] <mailto:[e-mail]>> wrote:
>> >Since all the addresses are IPv6, the application might think it does not
>> >need to do TURN.  If the service is sane, then it has v4 and v6 addresses,
>> >and the DNS64 will not synthesize AAAA, and the application will fail to
>> >connect to the v4, and just use the v6.
>> >If the application communicates IP literals in-band (I think teams.* does
>> >this), and supplies v4 and v6, then the v4 just fail.
>> >*If* there is also a local CLAT, then the v4 "work", and the application us=
>> >es
>> >TURN to figure out what the outer IPv4 from the 464 is.
>> >
>> >The place where I think we get into trouble is when, as you suggest, a name
>> >is used to refer to the additional resource, there are no v6, and DNS64
>> >synthesis occurs, and TURN would have been needed.  In 2019 thru 2022-ish,
>> >many of us experienced exactly that with teams.*, where it did not do TURN
>> >properly, unless it was RFC1918.
>> 
>> I'm worried about host and application complexity. Most people writing
>> applications still live mostly in an IPv4 world. IPv6 is weird. DNS64
>> create an extra level of weirdness where IPv4 addresses are embedded in
>> IPv6 addresses. 
>> 
>> Hosts can provide CLAT which increases host complexity but significantly
>> reduces application complexity. However, with DNS64 all IPv4-only destination
>> suddenly have both IPv4 and IPv6 addresses. That may confuse hosts that
>> need NAT traversal. 
>> 
>> DSN64 assumes hosts without CLAT (or address synthesis) otherwise DNS64
>> could be restricted to just prefix discovery. Such an IPv6-only host
>> has the disadvatage that if the server is dual stack, then the host
>> can only communicate using the IPv6 addresses of te server. In this way
>> DNS64 promotes deployment of hosts that are more fragile than hosts
>> with CLAT.
>> 
>> None of this is fatal. I'm sure that over time hosts and applications
>> will figure it out. But for me it is sad if this becomes an Internet
>> Standard.
>> 
>> _______________________________________________
>> v6ops mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



**********************************************
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.