Hi folks, Here is the summary of adoption call opinion for draft-momoka-v6ops-ipv6-only-resolver-01, and the planned action:
* Against (the number in front of each name is the order the opinion was expressed) * 1. Nick Hillard: more appropriate to have the draft go through one of the dns working groups, as this is an application (i.e. resolver) level issue, rather a network layer issue. * 11. v6ops has no mandate to change protocol behavior. * 4. Mark Andrew: No, it is primarily focused on the internals of the DNS resolver. Your audience is DNS resolver vendors. * 10. Philip Homburg a recursive resolver behind NAT64 should use 464xlat and should not try to implement address translation directly * For * 2. Gabor LENCSE: the draft solves an operational issue: how an IPv6-only iterative resolver can get information from an IPv4-only authoritative DNS server. * 3. Momoka Yamamoto: The draft's focus is primarily on the mechanics of transporting query packets to the authoritative server via IPv6 packets, placing it firmly within the realm of packet transfer issues as opposed to protocol issues. This leads me to the conclusion that it does indeed pertain to the scope of v6ops. * 12: 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. * 13: 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. * 6. It really feels like a perspective thing (v6ops vs dnsop), either way I support it because I have seen the problems it solves. * 8. Tim Wicinski: Everything I've heard and read on this work (wearing no hats) is that this is good work and should be adopted. * 9. Eduard Vasilenko: adopt Momoka's draft at least somewhere (I am not sure v6ops or dnsop). * 14. Kazunori Fujiwara: I support its adoption * 15. David Farmer: Based on these proposed changes and clarifications, I support adoption. * 16. Paolo Volpato: I am favor of adopting this draft. * Conditional * 5. Alejandro Acosta: How much time do I consider the server single stack?, vendor specific?, should the draft address some suggestion in this matter?. * 7. Mohamed Boucadair (Med): The proposal in the document is straightforward as it is simply about the case where DNS is an application that is served by a NAT64. That’s said, I would suggest to avoid re-specifying the behavior but point to existing RFCs out there (RFC6052, RFC6724, etc.). The proposal does not induce DNS interoperability issues as it touches only the transport of DNS messages, not the queries themselves. I’m not against adopting it, but not sure there is a value in publishing this as an RFC though. What would interesting is to check if, given the procedure described in the draft, BCP 91 can be updated 19 years after its publication. In summary, Momoka’s draft proposed that an IPv6-only iterative resolver behaves as RFC6502 defined when sending packets to IPv4-only authoritative DNS server via NAT64. It solves an existing problem in IPv6-only deployments and there are sufficient interest in the v6ops WG. Momoka also provided response to the other objections related to DNSSEC and 464XLAT. To me, there is only one remaining question: * Should the adding of RFC6502 behavior to the IPv6-only iterative resolver be considered as a change to the iterative resolver’s behavior? Some may argue that taking the RFC6502 behavior is just a packet transport change not a DNS protocol change so this draft belongs to v6ops, but others may argue that a packet transport change is still a change to the DNS server so this draft should move to DNSop. If this draft will one day go to IESG LC, some IESG members may ask the same question. Our AD Warren has asked the chairs to prepare answers/evidences before going to the IESG. This is why I wrote this summary and asked this question now. I invite the DNSop chairs to answer this question (and if they also think that this draft is in the grey area, to state their preference of v6ops or dnsop). I also invite our AD Warren to provide further guidance, if any. Depending on dnsop chairs’ answer/preference, either the draft will move to dnsop WG, or v6ops will adopt the updated version from Momoka. Thank you. XiPeng 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