Dear WGs, After following the cross-WGs discussion, I am favor of adopting this draft. It focuses on a specific case (that may be generalized in future works), but I think that it provides a good description of the issue and a valid operational approach.
BR Paolo From: v6ops <v6ops-boun...@ietf.org> On Behalf Of Momoka Yamamoto Sent: Sunday, July 9, 2023 11:48 AM To: list <v6...@ietf.org>; dnsop <dnsop@ietf.org> Subject: Re: [v6ops] [DNSOP] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01 Dear All, Thank you for your constructive feedback and the rich discussion that has followed the sharing of the draft. I've taken the time to digest all your comments. Concerning the DNS64 breaking DNSSEC issue: As Philip rightfully pointed out, the inclusion of DNS64 in this draft has indeed been misleading, and I will amend it by removing references to DNS64. DNSSEC is an important topic but this proposal doesn't directly interact with DNS64, hence the DNSSEC issues associated with DNS64 are out of its scope. Regarding the specificity of DNS resolvers when RFC7051 exists, there is a diverse range of opinions on this topic on list, some arguing the necessity of such documentation and others deeming it redundant. Some considerations I think are important include: * A resolver is one of the few applications that have a genuine requirement to use an IPv4 literal. * The inability of an iterative resolver to utilize RFC7050 for Pref64 discovery may be worth highlighting. * While 464XLAT has demonstrated its effectiveness in home networks supporting various apps and devices, the situation is different for DNS servers with more uniform tasks. In these cases, executing the translation within the resolver software could be more efficient. The process of the iterative resolver creating an IPv4 socket, which is then translated to an IPv6 packet by the CLAT, is inefficient as it adds an unnecessary layer of packet translation. * However, considering instances like Thread and other applications such as browsers, which already implement the synthesizing function, a draft dedicated to iterative resolvers may seem repetitive. Concerning the appropriate Working Group for this draft: While there is ongoing debate about whether this draft should be adopted or not, I did not find any strong opinions stating that this draft should be conducted at DNSOP. Furthermore, as Med proposed, BCP 91 could be updated, 19 years post-publication, to include these solutions for IPv6-only networks. For a more comprehensive and balanced draft, future steps will include removing references to DNS64 and incorporating both the 464XLAT and Pref64 solutions. For those unable to transition to 464XLAT promptly, having the resolver execute the translation will act as an essential bridge. This, however, does not preclude the consideration of 464XLAT as a potential future strategy. This approach aims to provide well-rounded guidance, assisting in better decision-making. I look forward to further discussions and appreciate your feedback on these matters. Best Regards, Momoka Y
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
