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