Re: [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01

The DNS people think that the network people should fix the network code 
so existing DNS resolvers work.  While the network people think the DNS 
people should fix the DNS resolvers to work with existing network code. 
Pick your poison.

By the way, it's not resolvers that need IPv4 literals.  It's any 
application that connects to IPv4 addresses that are either built into the 
code or found through a config or lookup, often not the DNS.  I can't tell 
you how common that is, but it's not as rare as you mght hope.  I also 
couldn't tell you the relative difficulty of writing shims and putting 
them around connect to an IPv4 address or around DNSSEC validation.

R's,
John

On Sun, 9 Jul 2023, Momoka Yamamoto 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
>

Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly