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. 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). 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 > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
