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

From: Mészáros Mihály <[email-masked]>
Date: Tue, 3 Oct 2017 00:44:04 +0200

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

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 02 Oct 2017 22:49:10 +0000

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 <[email-masked]> wrote:

> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Mészáros Mihály <[email-masked]>
Date: Tue, 3 Oct 2017 06:57:27 +0200

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 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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     [email-masked] <mailto:[email-masked]>

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 03 Oct 2017 05:05:48 +0000

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 <[email-masked]> wrote:

> think it's wise?
> It seems to be a host candidate, because it setups local adapter/interface
> with IPv6 address.
>
> sdpMid: audio, sdpMLineIndex: 0, candidate: candidate:3123958951 <(312)%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
>
>
>
>
> TEREDO is an IPv6 smooth transition technology, that is a tunnel and relay
> very similarly to TURN in many aspects,
>    - host candidates
>    - type preferences.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Oct 2017 09:09:01 -0700

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.

---

From: Mészáros Mihály <[email-masked]>
Date: Wed, 4 Oct 2017 05:54:27 +0200

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

Yes, exactly, with some implementation differences.
TEREDO is autmatic..
e.g. To have a VPN the user need to setup VPN connection, but on windows
TEREDO is enabled by default.

On 2017-10-03 07:05, Peter Thatcher 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 <[email-masked]
>>     Why wouldn't TEREDO endpoints just say the candidates are relayed
>>     if they think it's wise?
>>
>     Teredo Client setups a new interface (Teredo Tunneling
>     Pseudo-Interface) on windows with an IPv6 address
>     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
>
>
>
>     TEREDO is an IPv6 smooth transition technology, that is a tunnel
>     and relay very similarly to TURN in many aspects,
>     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.
>>     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?
>>

---

From: Mészáros Mihály <[email-masked]>
Date: Wed, 4 Oct 2017 06:08:22 +0200

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?"
>
> On Mon, Oct 2, 2017 at 10:05 PM, Peter Thatcher <[email-masked]
> <mailto:[email-masked]>> 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).
>
>>         Why wouldn't TEREDO endpoints just say the candidates are
>>         relayed if they think it's wise?
>>
>         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
>
>         TEREDO is an IPv6 smooth transition technology, that is a
>         tunnel and relay very similarly to TURN in many aspects,
>         According these, Teredo as it is local host IPv6 address, it
>         is a "host candidate" with the highest type preference.
>         VS.
>         IMHO spec should address this edge case where it seems to be
>         host candidate but it is more related to tunneled/relayed.
>
>
>         Thanks,
>         Misi
>
>
>>         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?
>>
>>             <https://www.ietf.org/mailman/listinfo/ice>
>>
>
>
>     <https://www.ietf.org/mailman/listinfo/ice>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Oct 2017 14:55:50 -0700

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" <[email-masked]> 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"?

Peter said:

[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:

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

>> 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
>>
>>
>>
>>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 27 Oct 2017 15:36:51 +0000

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.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Oct 2017 10:25:09 -0700

Agreed.

On Fri, Oct 27, 2017 at 8:36 AM, Peter Thatcher <[email-masked]>
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.
>