Based on these proposed changes and clarifications, I support adoption. On Sun, Jul 9, 2023 at 04:49 Momoka Yamamoto <momoka....@gmail.com> wrote:
> 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 > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- =============================================== David Farmer Email:far...@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
