[DNSOP] Re: [v6ops] Re: [EXTERNAL] New Version Not ification for draft-jens-7050-secure-channel-00.txt

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