Re: [Ice] Should teredo type preference be relayed or host?

[Bernard Aboba <[e-mail]>]

We have found that Teredo candidates are rarely optimal, and often have
high failure rates on checks, so that the "unreliable  connectiv
ity" advice in the dual stack document applies well to them.

On Oct 3, 2017 9:08 PM, "Mészáros Mihály" <[e-mail]> wrote:

The application should make decision based on the gathered IP address, and
if it has prefix 2001::/32 then consider it as TEREDO address and so
"unreliable connectivity"?

Am I understand you correctly?
On 2017-10-03 18:09, Bernard Aboba wrote:

Peter said:

"It sounds like this is more similar to host candidates on a VPN network
interface.  Is that correct?"

[BA] There have been problems with Teredo relay routability, so the
following snippets from https://tools.ietf.org/html/
draft-ietf-ice-dualstack-fairness apply:

   Applications should take special care to deprioritize network
   interfaces known to provide unreliable connectivity when operating in
   a multihomed environment.  For example, certain tunnel services might
   provide unreliable connectivity.  Doing so will ensure a more fair
   distribution of the connectivity checks across available network
   interfaces on the device.  The simple guidelines presented here
   describe how to deprioritize interfaces known by the application to
   provide unreliable connectivity...

   Candidates with IP addresses from an unreliable interface should be
   ordered at the end of the checklist, i.e., not intermingled as the
   dual-stack candidates.


On Mon, Oct 2, 2017 at 10:05 PM, Peter Thatcher <[e-mail]>
wrote:

> Ah, I misunderstood TEREDO.  I thought you were saying that there was a
> server giving out candidates (in which case I thought it could just mark
> it's candidates as relay).
>
> It sounds like this is more similar to host candidates on a VPN network
> interface.  Is that correct?
>
> On Mon, Oct 2, 2017 at 9:57 PM Mészáros Mihály <[e-mail]> wrote:
>
>> Hi Peter et al.
>>
>>
>>
>> Why wouldn't TEREDO endpoints just say the candidates are relayed if they
>> think it's wise?
>>
>> I assume "TEREDO endpoint" in your terminology is the "Teredo client".
>> Teredo Client setups a new interface (Teredo Tunneling Pseudo-Interface)
>> on windows with an IPv6 address
>> It seems to be a host candidate, because it setups local
>> adapter/interface with IPv6 address.
>>
>> ICE will detect it as host candidate.
>> It seems host candidate, but it is tunneled and relayed, and so in my
>> opinion it should be treated as relayed.
>>
>> e.g.
>> Chrome: 57.0.2987.133
>>
>> sdpMid: audio, sdpMLineIndex: 0, candidate: candidate:3123958951 <%28312%29%20395-8951> 1 udp 212225510 2001::5ef5:79fd:2c57:21fb:3e1e:c8bb 54819 typ host generation 1 ufrag D02B network-id 1 network-cost 50
>>
>>
>>
>>
>> Why does this need to be in the ICE spec?
>>
>> TEREDO is an IPv6 smooth transition technology, that is a tunnel and
>> relay very similarly to TURN in many aspects,
>> but it is  treated as host candidate IMHO that is not optimal.
>>
>> ICE spec defines:
>>
>>    - host candidates
>>
>>    Host candidates are obtained by binding to ports on an IP address
>>    attached to an interface (physical or virtual, including VPN
>>    interfaces) on the host.
>>
>>    - type preferences.
>>
>> 4.1.2.2.  Guidelines for Choosing Type and Local Preferences
>>
>>    The RECOMMENDED values for type preferences are 126 for host
>>    candidates, 110 for peer reflexive candidates, 100 for server
>>    reflexive candidates, and 0 for relayed candidates.
>>
>>
>> The Spec recommends, type preference for host candidates, and TEREDO
>> according current spec definition is a "host candidate".
>> According these, Teredo as it is local host IPv6 address, it is a "host
>> candidate" with the highest type preference.
>> VS.
>> Relayed with type preference 0.
>>
>> IMHO spec should address this edge case where it seems to be host
>> candidate but it is more related to tunneled/relayed.
>>
>>
>> Thanks,
>> Misi
>>
>>
>> On 2017-10-03 00:49, Peter Thatcher wrote:
>>
>> Why wouldn't TEREDO endpoints just say the candidates are relayed if they
>> think it's wise?  Why does this need to be in the ICE spec?
>>
>> On Mon, Oct 2, 2017 at 3:44 PM Mészáros Mihály <[e-mail]> wrote:
>>
>>> Hi,
>>>
>>> Please correct me if I totally misunderstand the situation, but
>>>
>>> AFAIU Teredo is considered according ICE as a host candidate and
>>> according it, we have to use the host local type preference for it.
>>>
>>> (That seems to be logical because it is on the host interface.)
>>>
>>>
>>> IMHO that is not the right behavior, because TEREDO is doing also
>>> relaying,
>>> and should be not considered as host candidate type rather consider it
>>> as relayed type.
>>>
>>> I can configure a very close TURN relay in WebRTC UA, but in the other
>>> hand I can not set the TEREDO relay location,
>>> because it depends on the network provider BGP. (anycast BGP 2001::/32)
>>>
>>> Many endpoints is doing TEREDO.
>>> On Windows AFAIK TEREDO is enabled by default, and all such home users
>>> with ipv4 only + nat box has TEREDO IPv6 address configured.
>>>
>>> My experience was that my peers are located in Hungary and I set a very
>>> close Hungarian TURN server, surprisingly the media use TEREDO relay in
>>> UK.... :-(
>>>
>>> If TURN and TEREDO both do relaying, then I think TEREDO should also
>>> considered as relayed candidate..
>>>
>>> If I have very close nice low latency TURN service, that is close to the
>>> communication peers, than I don't want to prefer so much the TEREDO
>>> relay.
>>>
>>> Actually according to the actual ICE behavior, because Teredo considered
>>> as host address,
>>> ICE will definitely choose and use TEREDO relay, even if it will be also
>>> relayed like TURN, and may even adds more latency than the TURN.
>>>
>>>
>>> All in all, I think the new 5254-bis rfc should clarify this case, and
>>> because TEREDO is also relaying, so I propose to define in the text an
>>> exception for this case.
>>> Consider TEREDO candidate type preference even if it is discovered on
>>> the host interface, as relay and not as host.
>>>
>>> Please comment/correct my thoughts.
>>>
>>> Thanks,
>>>
>>> Misi
>>>
>>>
>>> _______________________________________________
>>> Ice mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ice
>>>
>>
>>
> _______________________________________________
> Ice mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ice
>
>