Re: [MMUSIC] ICE candidate address selection update draft

[Ari Keranen <[e-mail]>]

On 8/4/12 10:09 AM, Jonathan Lennox wrote:
>
> 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.

You have a good point. My main concern is that when you have a long list 
of different kind of IPv6 addresses for each interface (global, 
link-local, ULA, some temporary addresses, etc.), you will end up with a 
huge checklist of host-host candidates (which have the highest 
priority). If you have broken v6 connectivity, it's gonna take ages 
before you move to v4 candidates that work.

That being said, perhaps we should keep matching ULAs to globals but 
just give that combination a lower priority than other host-host 
candidate pairs. Link-locals we should still match only to link-locals 
(right?).

> That said, if there were a well-defined algorithm to prioritize
> sensible checks over absurd ones, that'd be fine.

This is the tricky part. Right now the candidates use same priority 
regardless of the other candidate's type. What we'd like to say is "for 
ULA candidate with ULA pair you need priority X and with other types 
priority Y". Then another question is what's the sensible trade-off 
between complexity of prioritization and making these corner cases work..

> I'm afraid I don't understand v6 addressing well enough to make
> concrete text suggestions based on this principle, though.

I can try to craft something for the next revision. All suggestions are 
welcome of course.


Cheers,
Ari