Subject: [MMUSIC] ICE candidate pairing and NAT64

From: Jonathan Lennox <[email-masked]>
Date: Tue, 23 Jun 2015 19:28:40 +0000

Apple’s recent announcement that all iOS apps are soon going to be required to support running behind NAT64 has led me to contemplate what this means for ICE.

Should ICE endpoints be required and/or recommended to support using RFC 7050 NAT64 prefix discovery to pair local IPv6 candidates which have a NAT64 gateway with remote IPv4 candidates?

What does this do to connectivity check pacing, or to the total number of connectivity checks?

And how many operating systems can support a userspace app doing an RFC 7050 DNS lookup on a per-interface basis?  (Even if you roll your own DNS resolver, you still need to be able to obtain per-interface DNS server configuration information to find the interface’s appropriate DNS64 server.)

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 23 Jun 2015 18:21:51 -0700

> Should ICE endpoints be required and/or recommended to support using RFC 7050 NAT64 prefix discovery to pair local IPv6 candidates which have a NAT64 gateway with remote IPv4 candidates?

Yes.

> What does this do to connectivity check pacing, or to the total number of connectivity checks?

It means an IPv6-only device with a NAT64 has same number of candidates as a dual-stack device.  I would pace and prioritize NAT64 addresses exactly same as IPv4 addresses would be paced and prioritized on a dual-stack host.

> And how many operating systems can support a userspace app doing an RFC 7050 DNS lookup on a per-interface basis?  (Even if you roll your own DNS resolver, you still need to be able to obtain per-i…

Dunno.  MIF was going to solve that.  I will note that dnsmasq appears capable of sending DNS requests out certain interfaces (see the --server option at http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html), so it must be relatively possible?

-d

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 24 Jun 2015 15:35:36 +0000

> On Jun 23, 2015, at 9:21 PM, 🔓Dan Wing <[email-masked]> wrote:
> 

The issue that occurred to me (having thought about this some more) is that if you’re on a 464XLAT network, I don’t think you want to have the application do its own RFC 7050 pairing — instead, you probably want to use the 464XLAT interface to pair with remote IPv4 candidates.

Unfortunately, I don’t see any easy way for an application to be able to tell the difference between being on a device with 464XLAT (which will appear as an IPv6 local address with NAT64 plus a private address space IPv4 address) vs. a device with NAT64 on one interface and IPv4 on another (e.g. cellular data plus wi-fi).  In the latter case, essentially what an ICE stack needs to do is application-layer 464XLAT for the NAT64 candidates, but doing it redundantly for the former case seems like a bad idea.  Any thoughts, other than deep knowledge of device configuration?

> Dunno.  MIF was going to solve that.  I will note that dnsmasq appears capable of sending DNS requests out certain interfaces (see the --server option at http://www.thekelleys.org.uk/dnsmasq/docs/d…

It’s not just a matter of which interface you use to send the request, but which interface’s configuration information you use to discover the DNS server.  (Consider a dual-SIM device which can connect to  two different carriers’ cellular data networks, both of which are using NAT64.)

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 24 Jun 2015 08:57:11 -0700

On 24-Jun-2015 08:35 am, Jonathan Lennox <[email-masked]> wrote:
> Unfortunately, I don’t see any easy way for an application to be able to tell the difference between being on a device with 464XLAT (which will appear as an IPv6 local address with NAT64 plus a private address space IPv4 address) vs. a device with NAT64 on one interface and IPv4 on another (e.g. cellular data plus wi-fi).  

I had remembered 464XLAT used a special IPv4 address for its CLAT, but reading RFC6877 now, I am mis-remembering (or it was deemed a bad idea and pulled from the eventual RFC).

> In the latter case, essentially what an ICE stack needs to do is application-layer 464XLAT for the NAT64 candidates, but doing it redundantly for the former case seems like a bad idea.  Any thoughts, other than deep knowledge of device configuration?
> 

Yes, good point.  I agree if all the DNS & DNS64 servers learned from each interface is munged together (like it is with the traditional /etc/resolv.conf), we can't be successful at building synthetic NAT64 addresses.  That's what MIF was going to fix.  I know Dmitry Anipko was making good progress at keeping the learned DNS server from each interface separate on Windows, mostly for split-horizon support [e.g., enterprise VPN] but per-interface DNS64 is exactly the same split-horizon problem.  The learned DNS servers, and the interface each DNS server was learned from, need to be available to the application.  On OSs where that isn't possible, I think worst case is some additional ICE candidates and additional ICE connectivity checks, which will fail?

-d