That's a fun question. I took this approach based on my operating assumption that 7050 is still useful to some folks (noting 7050 is also still in the CLAT recommendations draft Jen and I are writing). I wouldn't be opposed to writing a deprecation instead if consensus indicates 7050 is no longer needed.
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?" There may be other use cases for 7050 that 8781 can't meet, but I'll let others speak up if they want for those. I certainly have a PREFerence for 8781. Thanks, Tommy ________________________________ From: Brian Candler <br...@nsrc.org> Sent: Wednesday, June 26, 2024 12:21 AM To: Tommy Jensen <jensen.tho...@microsoft.com>; dnsop@ietf.org <dnsop@ietf.org> Cc: V6 Ops List <v6...@ietf.org> Subject: Re: [v6ops] Re: [EXTERNAL] New Version Notification for draft-jens-7050-secure-channel-00.txt On 26/06/2024 06:50, Tommy Jensen wrote: > I am seeking feedback on whether updating 7050 is the correct > approach, and more generally, if there's interest in taking up work in > the area of "revisiting how a stub resolver should secure its > communication with a DNS64 resolver". With the PREF64 mechanism (RFC8781) already seeing widespread adoption, are we at a point where we could simply deprecate RFC7050?
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
