Oops, slight clarification, we are using nat64 destination address and ipv6 source address. John was talking about using rfc1918 source addresses. That amounts to putting an ipv4 stack in the device.
Op za 8 jul 2023 om 07:56 schreef Ted Lemon <mel...@fugue.com> > 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
