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

[Mészáros Mihály <[e-mail]>]

So you mean the application should take care about it and detect it,
and after candidate gathering set the "type priority" to 0 in case they
detect  "unreliable connectivity"?
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]
> <mailto:[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]
>     <mailto:[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 <tel:%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]
>>         <mailto:[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] <mailto:[e-mail]>
>>             https://www.ietf.org/mailman/listinfo/ice
>>             <https://www.ietf.org/mailman/listinfo/ice>
>>
>
>
>     _______________________________________________
>     Ice mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ice
>     <https://www.ietf.org/mailman/listinfo/ice>
>
>