Subject: [rtcweb] Transports questions on IPv6

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 14:56:49 +0000

>From the transports draft, S 3.4:

   In order to deal with situations where one party is on an IPv4
   network and the other party is on an IPv6 network, TURN extensions
   for IPv6 [RFC6156 <http://tools.ietf.org/html/rfc6156>] MUST be supported.

I think this needs clarification. Does this mean that we should
allocate v6 candidates from all v4 interfaces (for compat with v6-only
endpoints), as well as allocate v4 candidates from all v6 interfaces
(for compat with v4-only endpoints), and if so, which path (v6-to-TURN
or v6-from-TURN) should be prioritized?

Note also that these v4->v6 or v6->v4 allocations will be dependent on
the SSODA work being discussed in TRAM, since this is the only way to
allocate v4 and v6 TURN from a single host candidate.

Also worth noting:

With the current default settings, a single STUN and TURN server, and
assuming a dual-stack host with two network interfaces, a
PeerConnection with audio, video, and data will generate

5 (components) * 4 (local-udp+stun+turn+local-tcp) * 2 (interfaces) *
2 (IP protocols) = 80 candidates

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Mar 2014 15:21:01 +0000

Le 2014-03-05 14:56, Justin Uberti a écrit :
> I think this needs clarification. Does this mean that we should allocate v6 candidates from all v4 interfaces (for compat with v6-only endpoints), as well as allocate v4 candidates from all v6 interfaces (for compat with v4-only endpoints), and if so, which path (v6-to-TURN or v6-from-TURN) should be prioritized?

You must always allocate both v4 and v6 relayed candidates, irrespective
of what other candidates you have.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 15:26:41 +0000

On Wed, Mar 5, 2014 at 3:21 PM, Simon Perreault <[email-masked]
> wrote:

> > I think this needs clarification. Does this mean that we should allocate
> v6 candidates from all v4 interfaces (for compat with v6-only endpoints),
> as well as allocate v4 candidates from all v6 interfaces (for compat with
> v4-only endpoints), and if so, which path (v6-to-TURN or v6-from-TURN)
> should be prioritized?
>

I am fine with that - this needs to be added to the transports document
though.

Any thoughts on the prioritization question?

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Mar 2014 15:55:58 +0000

Since you asked for more...

Le 2014-03-05 14:56, Justin Uberti a écrit :
> which path (v6-to-TURN or v6-from-TURN) should be prioritized?

I'm sorry, I don't understand this question.

> Note also that these v4->v6 or v6->v4 allocations will be dependent on the SSODA work being discussed in TRAM, since this is the only way to allocate v4 and v6 TURN from a single host candidate.

I don't understand what you mean.

> Also worth noting:
> 
> With the current default settings, a single STUN and TURN server, and assuming a dual-stack host with two network interfaces, a PeerConnection with audio, video, and data will generate
> 
> 5 (components) * 4 (local-udp+stun+turn+local-tcp) * 2 (interfaces) * 2 (IP protocols) = 80 candidates

It's....... it's beautiful!

Simon

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 5 Mar 2014 21:58:33 +0530

(TURN) relayed candidates MUST NOT be prioritized as it is always possible to other high priority candidates succeed for the WebRTC session. Also, TURN candidates is not required to be allocated for all the session. Hope trickle ICE solve these problems as the allocation shall happen.

IMO, it is very much possible to implement in the WebRTC network (server/endpoint) without TURN server and with reduced WebRTC session setup time.

Thanks

Partha

From: rtcweb [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Wednesday, March 05, 2014 8:57 PM
To: Simon Perreault
Cc: [email-masked]
Subject: Re: [rtcweb] Transports questions on IPv6

On Wed, Mar 5, 2014 at 3:21 PM, Simon Perreault <[email-masked]> wrote:

I am fine with that - this needs to be added to the transports document though.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 18:16:00 +0000

On Wed, Mar 5, 2014 at 3:55 PM, Simon Perreault <[email-masked]

> I'm sorry, I don't understand this question.

Imagine I am a v6-only endpoint. Via IPv6, I allocate 2 ports on the TURN
server, v4 and v6. The remote client is v4-only, and via IPv4 it also
allocates v4 and v6 on its TURN server. So we need to relay to connect v4
and v6. Which path should be preferred?

a) Caller -- TURN/v6 --> TURN Server(Caller, v4 alloc) <-- v4 -- Callee
[ Caller candidate is relay, Callee candidate is host ]
b) Caller -- v6 --> TURN Server(Callee, v6 alloc) <-- TURN/v4 -- Callee
[ Caller candidate is host, Callee candidate is relay ]

I worked this through and I think ICE will choose (b), due to the (G>D?1:0)
tiebreaker, which seems right to me. So no action needed :)

> I don't understand what you mean.

I was assuming that WebRTC endpoints will need to do cross-family
allocations, to handle the case where they are talking to a v4-only or
v6-only endpoint and they are not v4- or v6- capable. If so, the transports
draft will need to reference the SSODA work once it becomes a WG item,
since I don't think WebRTC endpoints should create additional sockets to do
cross-family allocations (we have enough sockets already, as shown below).

> assuming a dual-stack host with two network interfaces, a PeerConnection
> with audio, video, and data will generate
> >
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Mar 2014 18:33:12 +0000

> tiebreaker, which seems right to me. So no action needed :)

Isn't it the case that you can assign different local priorities to
these to get the result that you need/want such that the tie breaker
is not necessary.  I would suggest that ICE would prefer the
v6-all-the-way option, but the happy eyeballs stuff might cause the
precedence to flip.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Mar 2014 18:34:55 +0000

> It's....... it's beautiful!

Indeed!  Now imagine pairing those.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Mar 2014 18:53:54 +0000

> Indeed!  Now imagine pairing those.

5 * ( 16 * 15 / 2 ) = 600 pairs

A marvel of engineering!

Simon

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Mar 2014 19:29:49 +0000

On Wed, Mar 5, 2014 at 6:53 PM, Simon Perreault <[email-masked]

> 5 * ( 16 * 15 / 2 ) = 600 pairs

At 20 ms paced checks, this is... 12 seconds.

(Fortunately many pairs don't make sense, e.g. v4->v6, udp->tcp, stun->*,
and can be omitted)