Re: [MMUSIC] ICE candidate pairing and NAT64

Jonathan Lennox <> Wed, 24 June 2015 15:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CE61C1AC39F for <>; Wed, 24 Jun 2015 08:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.797
X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bGku8RfNd9jL for <>; Wed, 24 Jun 2015 08:35:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC4CA1A92B7 for <>; Wed, 24 Jun 2015 08:35:39 -0700 (PDT)
Received: from pps.filterd ( []) by (8.14.7/8.14.7) with SMTP id t5OFZc1v008566; Wed, 24 Jun 2015 11:35:38 -0400
Received: from ([]) by with ESMTP id 1v0grte3j0-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Jun 2015 11:35:38 -0400
Received: from ([fe80::50:56ff:fe85:4f77]) by ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 24 Jun 2015 10:35:37 -0500
From: Jonathan Lennox <>
To: Dan Wing <>
Thread-Topic: [MMUSIC] ICE candidate pairing and NAT64
Thread-Index: AQHQrerP8Bq8S0QLeECkbf43H8WpDZ27MEeAgADuiwA=
Date: Wed, 24 Jun 2015 15:35:36 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-24_06:2015-06-23,2015-06-24,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506240255
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, 24 Jun 2015 15:35:46 -0000

> 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).  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.)