On 26/06/2024 17:01, Tommy Jensen wrote:
One use case could be 8781 is harder for apps above the networking stack to read, which applies to NAT64+DNS64 in the absence of 464XLAT and apps that are IPv6 aware trying to reach IPv4 only destinations. I might be tossing a match into fuel here, but to answer your question, I think we need to first answer "what is our recommended story for IPv6-aware apps communicating with IPv4-only peers when the OS gives it no IPv4 address or CLAT?"
That is true, although your question implies that applications themselves are going to be embedding their own CLAT.
The possibility was raised on v6ops recently of putting CLAT-type functionality into libc, which in principle should be simple to do. That would indeed require a way for it to obtain the received PREF64 value(s). I would imagine that some networking daemon would write those values to a file, which is read by libc whenever it wants to map an IPv4 socket to an IPv6 one. That seems to me entirely an internal matter between the OS and libc, just as, say, determining which NTP servers to use based on DHCP responses.
Furthermore: increasingly applications are performing their own DNS resolution, using DNS configurations which are not those set up by the local network administrator (e.g. DoH to third-party service). Those will comprehensively defeat DNS64 as a prefix detection mechanism.
I was trying not to cloud the issue in my previous remark, but I might as well add additional fuel to the fire now: should DNS64 itself be deprecated? Once you have 464XLAT then you don't need it at all, and you don't need to pretend to applications that IPv4-only servers have IPv6 addresses.
Regards, Brian. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
