In message <[email protected]> Mikael Abrahamsson writes: > On Wed, 1 Aug 2012, Brian E Carpenter wrote: > > > That's true. My point was that the CPE resolver will have to be upgraded > > to support DNS64 for, and *only* for, IPv6-only hosts. How it knows > > which hosts are IPv6-only is another mystery. > > Indeed, I started a thread about this on v6ops the other day: > > <http://www.ietf.org/mail-archive/web/v6ops/current/msg13581.html> > > Seems there is no solution to this problem and I'm seem to be having > trouble getting traction there that this might actually be a real problem > that needs solving.
Same answer as one given on that thread. If a device can support IPv4, then use NAT4. If a device can only support IPv6, then the DNS64 belongs on the IPv6-only device. To that device all host return AAAA records, since the A records are translated into ipv4-in-ipv6 space. The CPE should be dual stack and be capable of both NAT4 and NAT64 translations to allow reachability into the IPv4 world. This is simple. As pointed out on the thread, a patch has already been submitted to android and some 3gpp phone already do DNS64. If the CPE doesn't do NAT64, the packet will wander along some route, most likely the default route, until it either hits a NAT64 or runs into a black hole. Propogating DNS64 translated address can cause severe problems and therefore should never leak outside the single IPv6 only host that needs it to get to IPv4 addresses. DNS64 and NAT64 already exist for BSD and Linux (bind and pf for BSD, bind and linuxnat64 for linux). Curtis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
