> On 9 Oct 2022, at 04:58, Momoka Yamamoto <momoka....@gmail.com> wrote: > > > re: Mark Andrews 's comments > > this is yet another example of why DNS64 should be made historic. > > This is requesting even more support to work around problems introduced by > > DN64, a poorly thought out, supposedly short term hack. > > We did not write this draft thinking DNS64 has a problem.
I didn’t think you did but it highlights the problems with DNS64. DNS64 does not work with address literals. > We thought that IPv6-only iterative resolvers not existing because of > IPv4-only authoritative servers is a problem, and wanted a way to solve it > from the resolver side and not only from the network side (e.g. using > 464XLAT). Why do you think that promoting this niche fix is better that promoting that OS’s support 464XLAT, DS-Lite at the OS level? The later fixes the issues for every application on the node. We have well specified signalling for when a node to bring up 464XLAT, MAP-E, MAP-T, DS-Lite. We should be encouraging nodes to do just that when the signalling is present. We should be encouraging CPE router vendors to support copying the signalling from the ISP side to the internal side similar to how they do with DNS recursive server signalling by default except when configured not to. If a node can’t attach to an IPv6-only network and use the transition mechanism offered without applications have to know anything about it then it is deficient. DNS servers are an application in this context. The IETF should be trying to winnow down the number of transition mechanisms that vendors need to support. Less is actually more here and unfortunately we have not done a good job of pushing back on excessive choice. Mark > On Fri, Oct 7, 2022 at 2:47 PM Mark Andrews <ma...@isc.org> wrote: > While we (ISC) have been working on this for years > <https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/2166>, this is > yet another example of why DNS64 should be made historic. This > is requesting even more support to work around problems introduced by DN64, a > poorly thought out, supposedly short term hack. > > It is NOT needed with 464XLAT, DS-Lite and other transition technologies > where the IP stack maps > from IPv4 to IPv6 or the CPE maps from IPv4 to IPv6. > > Additionally this is an indication the BCP91 is now out of date. Best > current practice has been > to operate dual stack servers for many years now. > > Mark > > > On 7 Oct 2022, at 16:12, Momoka Yamamoto <momoka....@gmail.com> wrote: > > > > Hello, > > > > I have submitted an informational draft that describes resolvers performing > > IPv4 to IPv6 translation to send queries to IPv4-only authoritative servers. > > We thought it would be beneficial to document that we can operate a > > resolver with only an IPv6 address if we utilize the NAT64. > > Despite that it is stated in BCP91 [RFC3901], "every recursive name server > > SHOULD be either IPv4-only or dual stack." > > > > Since this is more related to IPv6/IPv4 translation I have submitted the > > draft to the v6ops wg, > > but because this is DNS related I would very much appreciate it if I could > > have comments from the dnsop list as well. > > > > Momoka. Y > > > > ---------- Forwarded message --------- > > From: <internet-dra...@ietf.org> > > Date: Thu, Oct 6, 2022 at 2:17 AM > > Subject: New Version Notification for > > draft-momoka-v6ops-ipv6-only-resolver-00.txt > > To: Momoka Yamamoto <momoka....@gmail.com>, Toyota Yasunobu > > <yasn...@sfc.wide.ad.jp> > > > > > > > > A new version of I-D, draft-momoka-v6ops-ipv6-only-resolver-00.txt > > has been successfully submitted by Momoka Yamamoto and posted to the > > IETF repository. > > > > Name: draft-momoka-v6ops-ipv6-only-resolver > > Revision: 00 > > Title: IPv6 only iterative resolver utilising NAT64 > > Document date: 2022-10-05 > > Group: Individual Submission > > Pages: 9 > > URL: > > https://www.ietf.org/archive/id/draft-momoka-v6ops-ipv6-only-resolver-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/ > > Html: > > https://www.ietf.org/archive/id/draft-momoka-v6ops-ipv6-only-resolver-00.html > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-momoka-v6ops-ipv6-only-resolver > > > > > > Abstract: > > By performing IPv4 to IPv6 translation, IPv6-only iterative resolvers > > can operate in an IPv6-only environment. When a specific DNS zone is > > only served by an IPv4-only authoritative server, the iterative > > resolver will translate the IPv4 address to IPv6 to access the > > authoritative server's IPv4 address via NAT64. This mechanism allows > > IPv6-only iterative resolvers to initiate communications to IPv4-only > > authoritative servers. > > > > > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
