Re: [MMUSIC] ICE candidate pairing and NAT64

Ari Keränen <> Wed, 22 July 2015 13:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8C8601B336C for <>; Wed, 22 Jul 2015 06:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rY_PViuwSXZl for <>; Wed, 22 Jul 2015 06:09:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DAA431A1A97 for <>; Wed, 22 Jul 2015 06:09:10 -0700 (PDT)
X-AuditID: c1b4fb3a-f79356d000006281-22-55af95f40138
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D2.DF.25217.4F59FA55; Wed, 22 Jul 2015 15:09:08 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server id; Wed, 22 Jul 2015 15:09:07 +0200
Received: from (localhost []) by (Postfix) with ESMTP id 0AE6760640; Wed, 22 Jul 2015 16:09:20 +0300 (EEST)
Received: from As-MacBook-Air.local (localhost []) by (Postfix) with ESMTP id 9555C605A2; Wed, 22 Jul 2015 16:09:18 +0300 (EEST)
To: 🔓Dan Wing <>, Jonathan Lennox <>
References: <> <> <> <>
From: Ari Keränen <>
Message-ID: <>
Date: Wed, 22 Jul 2015 15:09:05 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje6XqetDDZ6tVLO4eO0hk8X+xeeZ LaYuf8ziwOwx5fdGVo8lS34yebQ9u8MewBzFZZOSmpNZllqkb5fAlbHz1kfGgluqFYfnPGBt YPwp18XIySEhYCKx4uBaFghbTOLCvfVsXYxcHEICRxklpv2+xw7hbGOUuHDmDDOEs45R4kP3 UShnBaPEsd/NzCD9wgKmEp0NP9lAbBGBKIkvXT1QRVcZJX6fO8kIkmAWkJGYcbaRCcRmE7CV +N2+B8zmFdCWmLDiJ9ghLAKqEr1rJoLViwqkSSy+3MACUSMocXLmEzCbE6h3393/zBAzLSRm zj8PNV9eonnrbGaIh9Qkrp7bBGYLAc28+u8V4wRGkVlIRs1C0j4LSfsCRuZVjKLFqcXFuelG RnqpRZnJxcX5eXp5qSWbGIExcXDLb6sdjAefOx5iFOBgVOLhVfi5LlSINbGsuDL3EKM0B4uS OO+MzXmhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjNQ5p2NDr4s4c8mnv4juP+D7mGmVWT b/pt5nD8aX/00wObTtkVSjXePA0u8z3nWE603v/+mqXbg0PPHKuuy0/0mcCwLuKAQu5u3uSt s80OLYsyeN+Wd2Tbw7/MN18bShZ23xRckfI9c430jZ1z4pzf8/2yDUmPvVa8YifP6asacTvS 86YWnvRSYinOSDTUYi4qTgQARP4JX2oCAAA=
Archived-At: <>
Cc: mmusic <>
Subject: Re: [MMUSIC] ICE candidate pairing and NAT64
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jul 2015 13:09:28 -0000


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) 

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.



On 24/06/15 17:57, 🔓Dan Wing wrote:
> On 24-Jun-2015 08:35 am, Jonathan Lennox <> wrote:
>>> On Jun 23, 2015, at 9:21 PM, 🔓Dan Wing <> wrote:
>>> On 23-Jun-2015 12:28 pm, Jonathan Lennox <> 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, 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