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

[Bernard Aboba <[e-mail]>]

Agreed.

On Fri, Oct 27, 2017 at 8:36 AM, Peter Thatcher <[e-mail]>
wrote:

> Seems like we've reached the conclusion that the reference to dual stack
> is sufficient and we don't need to make any changes to the draft.
>
> On Wed, Oct 4, 2017 at 2:55 PM Bernard Aboba <[e-mail]>
> wrote:
>
>> 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
>>>
>>>
>>
>>
>>