Re: [rtcweb] Dual stack RTCweb

"Olle E. Johansson" <oej@edvina.net> Tue, 16 August 2011 12:01 UTC

Return-Path: <oej@edvina.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AFC21F8ABD for <rtcweb@ietfa.amsl.com>; Tue, 16 Aug 2011 05:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axxx85atGFCz for <rtcweb@ietfa.amsl.com>; Tue, 16 Aug 2011 05:01:39 -0700 (PDT)
Received: from ns.webway.se (edvina-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:d79::2]) by ietfa.amsl.com (Postfix) with ESMTP id B62F821F8A55 for <rtcweb@ietf.org>; Tue, 16 Aug 2011 05:01:38 -0700 (PDT)
Received: from [127.0.0.1] (localhost [IPv6:::1]) by ns.webway.se (Postfix) with ESMTP id ABFEC28429; Tue, 16 Aug 2011 14:02:23 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="iso-8859-1"
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <BLU152-W41B019AE5F8F004884506D93290@phx.gbl>
Date: Tue, 16 Aug 2011 14:02:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A891E7D-CDD3-42CE-9F93-9785756EEA4A@edvina.net>
References: <21A83EF5-206B-47CA-A055-C86E590EBEEF@edvina.net>, <4E48BFE5.9080504@alvestrand.no> <BLU152-W559E16682573CB4D4D269893260@phx.gbl> <3E59491C-459D-4D89-937D-5F38D4393D1C@edvina.net> <4E4A2B14.4090609@alvestrand.no>, <ECD4088D-58AF-40CE-B45C-3B9CE72629DF@edvina.net> <BLU152-W41B019AE5F8F004884506D93290@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
X-Mailer: Apple Mail (2.1244.3)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Dual stack RTCweb
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Aug 2011 12:01:40 -0000

16 aug 2011 kl. 13:23 skrev Bernard Aboba:

> Harald said: 
> 
> > > 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.  
> 
> Olle said:
> 
> > >> 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.
> 
> [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 complete in both directions?
> 
> [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.   
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.

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

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