Re: [MMUSIC] ICE candidate address selection update draft

Jonathan Lennox <> Sat, 04 August 2012 08:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10F8621F8777 for <>; Sat, 4 Aug 2012 01:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1EH2LDmy1xXM for <>; Sat, 4 Aug 2012 01:09:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4633A21F8773 for <>; Sat, 4 Aug 2012 01:09:48 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 78E62A686C1; Sat, 4 Aug 2012 03:48:21 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB012.mail.lan (unknown []) by (Postfix) with ESMTP id 11C68A684C4; Sat, 4 Aug 2012 03:48:21 -0400 (EDT)
Received: from BE235.mail.lan ([]) by HUB012.mail.lan ([]) with mapi; Sat, 4 Aug 2012 04:09:31 -0400
From: Jonathan Lennox <>
To: Ari Keranen <>
Date: Sat, 04 Aug 2012 04:09:55 -0400
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Thread-Index: Ac1yGHbg+j0mH/CkTgGo7qxjihndOA==
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
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: Sat, 04 Aug 2012 08:09:49 -0000

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'm afraid I don't understand v6 addressing well enough to make concrete text suggestions based on this principle, though.

Jonathan Lennox