Re: [rtcweb] Dual stack RTCweb

"Olle E. Johansson" <oej@edvina.net> Tue, 16 August 2011 08:42 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 38C4021F8B25 for <rtcweb@ietfa.amsl.com>; Tue, 16 Aug 2011 01:42:42 -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 5gQUpZ6+2lmj for <rtcweb@ietfa.amsl.com>; Tue, 16 Aug 2011 01:42:41 -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 9226A21F8B16 for <rtcweb@ietf.org>; Tue, 16 Aug 2011 01:42:40 -0700 (PDT)
Received: from [127.0.0.1] (localhost [IPv6:::1]) by ns.webway.se (Postfix) with ESMTP id 9E6482842A; Tue, 16 Aug 2011 10:43:27 +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: <4E4A2B14.4090609@alvestrand.no>
Date: Tue, 16 Aug 2011 10:43:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <ECD4088D-58AF-40CE-B45C-3B9CE72629DF@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>
To: Harald Alvestrand <harald@alvestrand.no>
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 08:42:42 -0000

16 aug 2011 kl. 10:32 skrev Harald Alvestrand:

> On 08/15/11 17:14, Olle E. Johansson wrote:
>> 15 aug 2011 kl. 11:24 skrev Bernard Aboba:
>> 
>>> 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.
>>> 
>>> 
>> 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?
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.
>> 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?
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