> On 9 Dec 2016, at 23:43, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > Yoav Nir <ynir.i...@gmail.com> wrote: >> To get this working, the DNS64 should be on the remote tunnel endpoint >> or behind it. And this will require that it has an IPv6 address and >> knows to do the NAT64 translation in cooperation with the tunnel >> endpoint. I guess this vendor’s IPsec implementation doesn’t do all >> that. Neither does my employer’s. > > So, I think that you are saying that if the client does DNS through the > tunnel, then the HQ's DNS servers have to do DNS64 synthesis? I guess people > need to do DNS through the tunnel because of needing to resolv internal > addresses. It's the whole MIF/split-horizon DNS problem, and I think it's > all a bad IPv4-specific idea, and we should be trying to kill it.
That was what I said, but then I realized Tommy is right. It doesn’t really matter that the ISP / Wifi / whatever is providing me with only IPv6 access. Most IPsec clients have their own virtual interface (with IKEv2’s CFG, Cisco’s IKEv1 extension or (gasp!) L2TP) so that has no issue being dual-stack or even IPv4-only. The IPv4 packets never make it onto the access network - they get encapsulated in ESP/IPv6, or TLS/TCP/IPv6. So with IPsec you can get IPv4 connectivity even when the access network doesn’t give it to you. And you don’t need any DNS games to do it. Yoav _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4
