On Aug 1, 2017, at 1:28 PM, Tim Chown <tjc@xxxxxxxxxxxxxxx> wrote:
Yes, she describes the issue nicely. What she doesn't mention is that there is a way to detect DNS64, so in principle a validating stub resolver can do DNS64 itself _post validation_. Of course, there are a lot of moving parts in this, particularly if you have multiple stub resolvers per host (e.g., a stub resolver in your browser and another one in your libc). But the point is that it is actually possible to have NAT64 and DNSSEC. And indeed, if you are able to detect the NAT64 prefix (RFC 7050), you can treat all IPv4 addresses as IPv6 addresses by prepending the NAT64 prefix in the stack, and you don't even need to do DNS64 in the resolver, so validation just works (RFC 6535). You can also do this by doing IPv4-to-v6 translation in the router, which is what Jordi is talking about when he mentions CLAT (RFC6877). The only reason I'm not on board with Jordi's proposal is that I think it's more interesting to see what stacks do when you don't give them _any_ IPv4 address. But in principle, with Jordi's solution, even IPv4 literals are handled correctly, and the interactions between DNS64 and VPNs go away as well. To me this seems like a pretty reasonable compromise position, although it's not the experiment I'd personally prefer to run. |