IETF Logo Mail Archive

Re: [rtcweb] Dual stack RTCweb

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 16 August 2011 11:22 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 F0BE221F89BA for <rtcweb@ietfa.amsl.com>; Tue, 16 Aug 2011 04:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 Qo6oQQZ85pQg for <rtcweb@ietfa.amsl.com>; Tue, 16 Aug 2011 04:22:17 -0700 (PDT)
Received: from blu0-omc4-s17.blu0.hotmail.com (blu0-omc4-s17.blu0.hotmail.com [65.55.111.156]) by ietfa.amsl.com (Postfix) with ESMTP id 8F89521F8A1A for <rtcweb@ietf.org>; Tue, 16 Aug 2011 04:22:16 -0700 (PDT)
Received: from BLU152-W41 ([65.55.111.136]) by blu0-omc4-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Aug 2011 04:23:04 -0700
Message-ID: <BLU152-W41B019AE5F8F004884506D93290@phx.gbl>
Content-Type: multipart/alternative; boundary="_49e4d2a8-da50-4852-8018-0f35d790c44f_"
X-Originating-IP: [65.34.177.21]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: oej@edvina.net, harald@alvestrand.no
Date: Tue, 16 Aug 2011 04:23:04 -0700
Importance: Normal
In-Reply-To: <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>, <ECD4088D-58AF-40CE-B45C-3B9CE72629DF@edvina.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Aug 2011 11:23:04.0546 (UTC) FILETIME=[DDAB6C20:01CC5C06]
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 11:22:18 -0000

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.   

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

v2.23.0 | Report a Bug | By Email