Hi Mark, Thank you for voicing a clear opinion on this. I hope other people who have strong opinion on this matter will speak up. Thanks.
XiPeng -----Original Message----- From: v6ops <v6ops-boun...@ietf.org> On Behalf Of Mark Andrews Sent: Thursday, July 6, 2023 3:10 AM To: Tim Wicinski <tjw.i...@gmail.com> Cc: dnsop <dnsop@ietf.org>; list <v6...@ietf.org> Subject: Re: [v6ops] [DNSOP] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01 I’ll repeat that it is a bad idea to make this an RFC. I’m saying this despite adding this to named. It is perpetuating DNS64 which does not work with DNSSEC. It sends the wrong signal that DNS64 is a good protocol to deploy when we know that it breaks lots of things. The better solution would be to improve the automatic installation of 464XLAT (RFC6877) support in nodes. There is already a RA PREF64 option (RFC8781) to signal that NAT64 is available on the network and that works for all applications on the node, not just the nameserver. Similarly for DS-Lite. Linux has https://github.com/toreanderson/clatd FreeBSD has 464XLAT support built in since FreeBSD 11.3 While CLAT is not everywhere there yet it is definitely on the way. https://blog.apnic.net/2022/11/21/deploying-ipv6-mostly-access-networks/ I really don’t know why we are just not saying if you want to run a DNS64 server behind a IPv6 only link install CLAT support if it is not already available. > On 6 Jul 2023, at 01:12, Tim Wicinski <tjw.i...@gmail.com> wrote: > > Momoka > > Thanks for making DNSOP aware of this. We encourage anyone with comments on > the document adoption to reach out. > > Everything I've heard and read on this work (wearing no hats) is that this is > good work and should be adopted. > > thanks > tim > > > > On Tue, Jul 4, 2023 at 5:15 AM Momoka Yamamoto <momoka....@gmail.com> wrote: > Dear dnsop wg > cc:v6ops wg > > My name is Momoka, the author of the draft-momoka-v6ops-ipv6-only-resolver. > This draft, which has already been introduced to the V6OPS Working Group, > aims to address a pertinent operational issue: facilitating the transport of > query packets from an IPv6-only iterative resolver to an IPv4-only > authoritative DNS server. > > In light of some suggestions in V6OPS and considering the overlapping > interests, I am introducing this draft to the DNSOP Working Group. Its core > proposition lies in the mechanics of transporting query packets rather than > the alteration of the DNS protocol behavior, but the operational context > undoubtedly makes this draft relevant to both groups. > > Here are links to the draft and the ongoing discussions in V6OPS: > > 1. Draft: > https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver > / 2. V6OPS Thread: > https://mailarchive.ietf.org/arch/msg/v6ops/uNrPNbeUtA_D0xzqLfq5dNQ85O > Y/ > > > Currently, there is an adoption call in V6OPS for this draft set to end on > July 10, 2023. Your opinion, input, and suggestions will be highly valued as > we explore and progress this topic. I look forward to fruitful and > enlightening discussions. > > Best regards, > > Momoka Yamamoto > momoka....@gmail.com > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
