In message <[email protected]> Brian E Carpenter writes: > On 02/08/2012 06:58, Mikael Abrahamsson wrote: > > On Wed, 1 Aug 2012, Curtis Villamizar wrote: > > > >> 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 > > > > Am I interpreting you correctly in that you're saying that an IPv6 only > > device should have a built in resolver that does DNS64 in case of v6 > > only connectivity? > > > > I can see that this would work, but is that a generally accepted > > solution? On Android, this would mean that dnsmasq would need to gain > > DNS64 functionality (and also needs to be able to detect the NAT64 > > prefix somehow). > > That is one of the models discussed in BEHAVE, of course, and it deals > neatly with the DNSSEC conundrum for DNS64. But the normal model is > the one that Curtis doesn't like. NAT64/DNS64 plays better when > the client network is truly IPv6-only; with mixed hosts, you really need > to provision dual stack hosts with a normal DNS server, and the IPv6-only > hosts with a DNS64. > > Brian
Brian, What you suggest might be accomplished by having DHCP4 return a different nameserver than DHCP6. At the very least the same nameserver (same copy of bind or whatever on a DS machine) could respond differently if the private side query arrives via IPv4 than if it arrives via IPv6. Worst case is DS machines make use of NAT64 when they could have used IPv4. [aside: Bind has views, but I don't know if the view support would allow this. It seems like it would. It would be nice if this were doable today with no changes. ie: existance proof] Curtis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
