John, that's simply not an option on networks that only support IPv6 (most especially 6lowpan). We really don't want to have to put an IPv4 stack in a constrained device. So this solution isn't going to work. In practice, these devices will generally just rely on a resolver that probably /does/ have IPv4 access, but a solution that assumes that all endpoints have IPv4 stacks is not a good solution.
On Fri, Jul 7, 2023 at 2:08 PM John Levine <jo...@taugh.com> wrote: > It appears that Vasilenko Eduard <vasilenko.edu...@huawei.com> said: > >-=-=-=-=-=- > >1. 464XLAT is indeed an alternative, but a bad one: it means that the > client should have a local IPv4 subnet. > >The DNS resolver should prepare the packet in IPv4 format, then fetch it > to the CLAT engine where it would be translated to IPv6. > > I'm with Mark here. If you want to talk to IPv4 devices, it makes a > lot more sense for your local router or device to give you an RFC1918 > network which then lets you use the real far end IPv4 addresses and > signed DNS records, than to require every bit of addresss management > and DNSSEC code to do special hacks to try and peer through the other side > of the NAT. > > R's, > John > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
