Subject: [rtcweb] Dual stack RTCweb

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 12 Aug 2011 16:39:05 +0200

Coming in late to the discussion, I can't find any traces of a discussion about dual stacks. Are the issues related with this supposed to be solved with ICE/STUN/Turn - if so, shouldn't this be documented?

If not, what do we do? Happy RTC-eyeballs?

/O

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 15 Aug 2011 08:42:45 +0200

> Coming in late to the discussion, I can't find any traces of a discussion about dual stacks. Are the issues related with this supposed to be solved with ICE/STUN/Turn - if so, shouldn't this be doc…
I think ICE/STUN is supposed to solve the issue of setting up a 
connection that is either IPv6 or IPv4. Bernard Aboba mentioned in 
Quebec that he had some experience in this area - Bernard, can you share?
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 15 Aug 2011 02:24:32 -0700

ICE is designed to handle dual stack operation.  It can even deal with NAT64, if correctly implemented. 

Since ICE tests pairs before using them, there is no "happy eyeballs" problem with ICE (e.g. if an IPv6 route doesn't exist, the test will fail). 

That said, IPv6/IPv4 priorities may need some adjustment in some situations (e.g. if the IPv6 routes are more circuitous than IPv4, it may not make sense to prefer IPv6 over IPv4).  

That is one of the reasons that I am not enthusiastic about treating the SDP JSON blob as "opaque" (e.g. not subject to adjustment). Doing so without the ability
to adjust IPv6/IPv4 priorities will result in poor performance in dual stack operation in some cases.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 15 Aug 2011 17:14:08 +0200

> to adjust IPv6/IPv4 priorities will result in poor performance in dual stack operation in some cases. 

Well, if we use SRV records, the receiving part may use SRV to indicate preference.

Now, if I have an IPv6 only client ICE won't help unless we force turn usage for IPv6 only clients so that they offer dual stack always (like the current recommendation for SIP).

/O

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 16 Aug 2011 10:32:20 +0200

> Well, if we use SRV records, the receiving part may use SRV to indicate preference.
I think the ICE procedure for connecting doesn't do any DNS lookups.
In which phase of the negotiation are you suggesting we look up SRV records?

Not having any opinion on the idea, just trying to figure out what we're 
talking about.
> Now, if I have an IPv6 only client ICE won't help unless we force turn usage for IPv6 only clients so that they offer dual stack always (like the current recommendation for SIP).
we can't force anything, but I do see IPv6-only clients as a powerful 
argument for offering dual-stack TURN servers.

I'm not 100% sure .... if client A is IPv6 only, and has a dual-stack 
TURN server, while client B is IPv4 only and does not have (or does not 
want to use) a TURN server .... will the connection complete in both 
directions?

It's easier to imagine that dual-stack TURN servers will be deployed 
usefully if only the service provider that wants to support the 
IPv6-only client will have to do anything.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 16 Aug 2011 10:43:27 +0200

> In which phase of the negotiation are you suggesting we look up SRV records?
Sorry, me confused. In SIP we have both a signalling and a media issue. SRV is of course a signalling issue.

> 
> Not having any opinion on the idea, just trying to figure out what we're talking about.
> we can't force anything, but I do see IPv6-only clients as a powerful argument for offering dual-stack TURN servers.
> 
> I'm not 100% sure .... if client A is IPv6 only, and has a dual-stack TURN server, while client B is IPv4 only and does not have (or does not want to use) a TURN server .... will the connection complete in both directions?
This is one of the not covered cases in SIP. Most documents assume that everyone has IPv4 and very few assume single-stack Ipv6, something I think we need to start thinking more about. 

> 
> It's easier to imagine that dual-stack TURN servers will be deployed usefully if only the service provider that wants to support the IPv6-only client will have to do anything.

Right. But regardless, we need to consider these scenarios in the media negotiation, SDP or no SDP.

/O

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Aug 2011 04:23:04 -0700

> > I think the ICE procedure for connecting doesn't do any DNS lookups.

[BA] Right.  The SRV RRs (and subsequent A/AAAA RRs) are used in signaling, not media and in any case, ICE is end-to-end.  

> > we can't force anything, but I do see IPv6-only clients as a powerful argument for offering dual-stack TURN servers.

[BA] Even an IPv6-only client could need ICE if there is a NAT64 on their network.   And yes, relay candidates from a dual-stack TURN server could end up being
selected.   Overall, the idea behind ICE is to be robust against network configurations, to the greatest degree possible.  So it's best not to say "we think IPv6 networks will generally be built in the following ways, so the following features of ICE are not needed".   

> > I'm not 100% sure .... if client A is IPv6 only, and has a dual-stack TURN server, while client B is IPv4 only and does not have (or does not want to use) a TURN server .... will the connection c…

[BA] There first question is if A and B can communicate via SIP.   There could be a dual-stack SIP proxy somewhere, or maybe a NAT64 on the network, so that IPv6-A and IPv4-B could signal each other. 

If there is a way for media to flow between IPv6-A and IPv4-B, then ICE should find it.  This could be via NAT64 (server reflexive candidate) or via a dual stack TURN server (relay candidate).  

> This is one of the not covered cases in SIP. Most documents assume that everyone has IPv4 and very few assume single-stack Ipv6, something I think we need to start thinking more about. 

[BA] The SIP (and ICE) standards do cover this.  However, operationally we are still in the early stages, and so implementations may function well until they hit a deployment they didn't expect.   

> > It's easier to imagine that dual-stack TURN servers will be deployed usefully if only the service provider that wants to support the IPv6-only client will have to do anything.

[BA] Some service providers may opt for NAT64 so an ICE implementation needs to handle this.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 16 Aug 2011 14:02:23 +0200

> [BA] The SIP (and ICE) standards do cover this.  However, operationally we are still in the early stages, and so implementations may function well until they hit a deployment they didn't expect.   
I would not say that the SIP standards do cover dual stack and single stack use cases fully.  But that's an off-topic discussion here, I guess. We just need to make sure that we keep these issues in this discussion for media negotiation and possible signalling specs.

> [BA] Some service providers may opt for NAT64 so an ICE implementation needs to handle this. 

Well, when talking about apps in web browsers, we are talking about a large number of situations compared with where we have  "pure" sip deployments today (which is mostly managed networks).

/O