Re: [MMUSIC] ICE candidate address selection update draft

On Aug 4, 2012, at 10:09 AM, Jonathan Lennox <jonathan@vidyo.com>
 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.
> 
> That said, if there were a well-defined algorithm to prioritize sensible checks over absurd ones, that'd be fine.
> 
+1 

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.

.-.
Pål-Erik

> I'm afraid I don't understand v6 addressing well enough to make concrete text suggestions based on this principle, though.
> 
> --
> Jonathan Lennox
> jonathan@vidyo.com
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic