Re: [MMUSIC] ICE candidate address selection update draft

[Jonathan Lennox <[e-mail]>]

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
[e-mail]