Thank you for your feedback Mark, Having the OS's support is great in the way that all applications on the OS can use IPv4. However, we thought that in theory (but maybe not currently) an iterative resolver is the only application that actually needs IPv4 to operate. You may have concerns for DNS64 (because of DNSSEC?) but we feel that it is the best solution, and with DNS64/NAT64 all applications that use domain names can connect to IPv4 hosts with IPv6.
We wrote this draft specifying an iterative resolver because DNS is special. An iterative server is the only application that needs IPv4 support (please inform me if I'm wrong. my understanding of other applications needing IPv4 is that they just haven't added IPv6 support yet). Any other application can use DNS64/NAT64 and send IPv6 packets to IPv4 hosts. Unlike applications where both the server and client can be tweaked, DNS is internet global and cannot be changed by self-help. The current state of iterative resolvers needing support for IPv4 protocol, is a major barrier to the future migration to IPv6. If an iterative resolver is the only software that truly needs IPv4 support, forcing the OS to support the new protocol when only one piece of DNS software can do it may slow down the progress of the IPv6 migration roadmap. Momoka On Mon, Oct 10, 2022 at 10:24 AM Mark Andrews <ma...@isc.org> wrote: > > > > 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 > > -- > 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
