Re: [MMUSIC] ICE candidate address selection update draft

"Pal Martinsen (palmarti)" <> Mon, 06 August 2012 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 487E621F85FF for <>; Mon, 6 Aug 2012 01:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s1CNJRtN5LHG for <>; Mon, 6 Aug 2012 01:02:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3278021F8600 for <>; Mon, 6 Aug 2012 01:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3041; q=dns/txt; s=iport; t=1344240169; x=1345449769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rUItiANTpj3K1aABdPnGrFhUX9ddHXxMRLmAb1nyypo=; b=c1HPl1dtHnZhWc7eVtK+JGXpPKM6cPeF8ZMyvgCNgeiSwOE4vPIXph0z soepvHHaOGu9H5qqW9MfXk5C91egCihCl4LMwbKGi3IQ4+gBzL9yMJkEn 0S9dHUb4i3gZ+NR28DBOpXUpBM34zupbjgyd2THQRLxwRUl5Ve4fgGp1X s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EACx5H1CtJV2d/2dsb2JhbABFuT6BB4IgAQEBAwEBAQEPAVsLBQsCAQgYLicLJQIEDgUih2UGC5s7n0gEi0qGJGADiBiNMY4mgWaCXw
X-IronPort-AV: E=Sophos;i="4.77,717,1336348800"; d="scan'208";a="108706468"
Received: from ([]) by with ESMTP; 06 Aug 2012 08:02:48 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q7682msS011281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 08:02:48 GMT
Received: from ([]) by ([]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 03:02:48 -0500
From: "Pal Martinsen (palmarti)" <>
To: Jonathan Lennox <>
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Date: Mon, 06 Aug 2012 08:02:48 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--39.101600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Aug 2012 08:02:50 -0000

On Aug 4, 2012, at 10:09 AM, Jonathan Lennox <>

> On Aug 3, 2012, at 12:27 PM, Ari Keranen wrote:
>> On 8/3/12 12:03 PM, Simon Perreault wrote:
>>> Le 2012-08-03 11:58, Ari Keranen a écrit :
>>>> Yes, you should not get ULAs from the STUN server as long as the STUN
>>>> server is properly located (on the Internet, outside of the organization
>>>> perimeter and on the other side of any NATs). And the peer reflexive
>>>> candidate (which would be global address) can be then matched with
>>>> peer's globals.
>>> But reflexive candidates don't always work. I know I said NPTv6, but we
>>> shouldn't prevent ICE from working behind evil NAT66. And an ICE client
>>> may not be able to reach a STUN server so you can't rely on having
>>> reflexive candidates. So you should still try to match ULAs with globals.
>> OK, this is quite a corner case, but I'm afraid you're right. However, 
>> if you have a global address on the interface (i.e., you're not behind 
>> an evil NAT66), matching ULAs with globals doesn't make sense. So, I'd 
>> suggest text along the lines of:
>>   o  Candidate addresses from Unique Local Addresses (ULAs) SHOULD NOT
>>      be combined with any other candidates except other ULA candidates.
>>      However, if an interface does not have any global addresses, the
>>      ULA SHOULD be used.
>> (changed MUST to SHOULD and added the second sentence)
> Remembering that the two ICE endpoints need to agree on which candidates match, does this mean that I need to know whether my peer's ULA and my peer's global address are on its same interface?
> As a more general comment, one of the virtues of ICE is that by matching everything to everything, you're guaranteed to find a route, if one's possible, no matter how stupid or evil your network architects have been.  I don't think we want to break that property for IPv6, except in cases where it's absolutely impossible (e.g., due to host behavior) for a route to work.  If there's any circumstance where a network admin being "helpful" could make a connectivity check on a candidate pair succeed, I think we want to try that pair.  Even if the IETF says that the network MUST NOT be configured so as to make such a route work.
> That said, if there were a well-defined algorithm to prioritize sensible checks over absurd ones, that'd be fine.

I think you make a very good point here. Just make sure we don´t encourage bad/evil network configurations. Those configurations should finish their connectivity checks last.


> I'm afraid I don't understand v6 addressing well enough to make concrete text suggestions based on this principle, though.
> --
> Jonathan Lennox
> _______________________________________________
> mmusic mailing list