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
