Re: [MMUSIC] ICE candidate pairing and NAT64

[Ari Keränen <[e-mail]>]

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 <[e-mail]> wrote:
>>
>>> On Jun 23, 2015, at 9:21 PM, 🔓Dan Wing <[e-mail]> wrote:
>>>
>>> On 23-Jun-2015 12:28 pm, Jonathan Lennox <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>