As I said in another message, that is in fact what we do. :) Op za 8 jul 2023 om 01:00 schreef Mark Andrews <ma...@isc.org>
> 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
