Well don’t put an IPv4 stack on the device. Use mapped addresses over IPV6 sockets and map those addresses to the PREF64 prefix in use in the stack. -- Mark Andrews
> On 8 Jul 2023, at 05:20, Ted Lemon <mel...@fugue.com> wrote: > > > 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
