Subject: Re: [MMUSIC] ICE candidate pairing and NAT64

From: Ari Keränen <[email-masked]>
Date: Wed, 22 Jul 2015 15:09:05 +0200

Hi,

I agree that candidates from NAT64 setups would be useful. But I wonder 
what's the best way to discover them without adding too much complexity. 
In particular I'd prefer single mechanism that works across all (/many) 
cases.

If there is also DNS64 in use, discovering IPv4 STUN/TURN server via 
that would result in NAT64 translated server reflexive addresses. This 
seems to be fine according to the STUN RFC [1] and STUN bis [2].

In that case prefix discovery would not be needed. Or if it is used in 
parallel, one should probably check that the same prefix is not 
discovered twice? And how about the 464XLAT case?

I think these should be prioritized like IPv4 server reflexive candidates.

And at least so far seems to go to the category of "simple fixes" and 
hence good for ICEbis.

Cheers,
Ari

[1] https://tools.ietf.org/html/rfc5389#section-7.3.3
[2] https://tools.ietf.org/html/draft-ietf-tram-stunbis-04#section-6.3.3

On 24/06/15 17:57, 🔓Dan Wing wrote:
>
> On 24-Jun-2015 08:35 am, Jonathan Lennox <[email-masked]> wrote:
>>
>>> On Jun 23, 2015, at 9:21 PM, 🔓Dan Wing <[email-masked]> wrote:
>>>
>>> On 23-Jun-2015 12:28 pm, Jonathan Lennox <[email-masked]> wrote:
>>>>
>>>> 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?
>>>
>>> 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.
>>
>> 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).
>
> 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?
>>
>>>> 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.)
>>>
>>> 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?
>>
>> 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.)
>
> 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
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 22 Jul 2015 15:58:16 +0200

On 22-Jul-2015 03:09 pm, Ari Keränen <[email-masked]> wrote:
> 
> Hi,
> 
> I agree that candidates from NAT64 setups would be useful. But I wonder what's the best way to discover them without adding too much complexity. In particular I'd prefer single mechanism that works across all (/many) cases.
> 
> If there is also DNS64 in use, discovering IPv4 STUN/TURN server via that would result in NAT64 translated server reflexive addresses. This seems to be fine according to the STUN RFC [1] and STUN bis [2].

Yes, that should work with NAT64.

> In that case prefix discovery would not be needed.

Well, prefix discovery can still be useful, because the NAT64 might not be BEHAVE-friendly (specifically I am referring to address-dependent mapping, where the local ICE client has to send packets towards the remote ICE peer).  Maybe there aren't any NAT64s with address-dependent mapping behavior, but I worry there is a vendor or two that implemented such a thing.  I wonder if RIPE Atlas probes could do such testing of NAT64s they are behind?

> Or if it is used in parallel, one should probably check that the same prefix is not discovered twice?

Yeah, that's another check that should be written down.

> And how about the 464XLAT case?

I don't know, because I don't know if the ICE client would be aware of 464xlat; the IPv4 interface could look very 'real'.  And if 

> And at least so far seems to go to the category of "simple fixes" and hence good for ICEbis.

-d

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 22 Jul 2015 15:14:11 +0000

> On Jul 22, 2015, at 3:58 PM, 🔓Dan Wing <[email-masked]> wrote:
> 
> 

It’s not just address-dependent mapping on the NAT64 that’s an issue — address-dependent filtering is enough for the prefix discovery to be necessary.

> I don't know, because I don't know if the ICE client would be aware of 464xlat; the IPv4 interface could look very 'real'.  And if 

Presumably you could check whether the server-reflexive IP address for a v4 also appears on some v6 candidate — if they are, the v4 is very likely to be 464xlat. That’s a heuristic, though, with both false positives and false negatives.

>> I think these should be prioritized like IPv4 server reflexive candidates.

This is an interesting case in that the prefix-mapped remote candidates are entirely “synthetic”, i.e. the remote endpoint doesn’t necessarily even know the local side is using them, and has no way to assign priorities to them.   I’m also uncertain whether inserting these this has any effects on pacing.

>>> 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 synt…

(Just noticed this in the thread history.)

It’s not clear to me whether the implementations that don’t expose split horizon send out DNS requests to all interfaces (and thus combine them), or just to one preferred one and return its answer.  In the former case you’d get redundant ICE candidates, but in the latter you’d have no way of doing prefix discovery for the non-preferred interfaces at all.  As I understand the classic libresolv, it has the latter behavior; but I don’t known what modern OSes do.