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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
