Re: [rtcweb] ICE for dual stacks (new topic)
"Olle E. Johansson" <oej@edvina.net> Wed, 28 September 2011 19:14 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 DACDF1F0CC2 for <rtcweb@ietfa.amsl.com>; Wed, 28 Sep 2011 12:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.233
X-Spam-Level:
X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=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 eAeoIpr51gVP for <rtcweb@ietfa.amsl.com>; Wed, 28 Sep 2011 12:14:10 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id F25481F0C62 for <rtcweb@ietf.org>; Wed, 28 Sep 2011 12:14:09 -0700 (PDT)
Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 95BE0754BCE5; Wed, 28 Sep 2011 19:16:57 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7A0E1CFF-6B02-4A40-AE63-C085F99148CD"
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <4E830E89.3050400@alvestrand.no>
Date: Wed, 28 Sep 2011 21:17:24 +0200
Message-Id: <3E66F9FC-C37B-41E5-ACF4-E1CDEB6E4DC6@edvina.net>
References: <4E830E89.3050400@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1244.3)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] ICE for dual stacks (new topic)
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: Wed, 28 Sep 2011 19:14:11 -0000
28 sep 2011 kl. 14:09 skrev Harald Alvestrand: >> Added an explicit statement that ICE is required for both NAT and >> consent-to-receive. I would like to bring IPv4/IPv6 transition to the table in the ICE discussion. Quoting http://tools.ietf.org/html/rfc6157 - abot SIP IPv6 transition: ------------ When following the ICE procedures, in addition to local addresses, user agents may need to obtain addresses from relays; for example, an IPv6 user agent would obtain an IPv4 address from a relay. The relay would forward the traffic received on this IPv4 address to the user agent using IPv6. Such user agents MAY use any mechanism to obtain addresses in relays, but, following the recommendations in ICE, it is RECOMMENDED that user agents support STUN relay usage [6] [8] for this purpose. IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses using the ICE procedures to generate all their offers. This way, both IPv4-only and IPv6-only answerers will be able to generate a mutually acceptable answer that establishes a session (having used ICE to gather both IPv4 and IPv6 addresses in the offer reduces the session establishment time because all answerers will find the offer valid.) ----- Now, I know this has been discussed widely and there are some drafts that discusses this. Dan Wing writes in http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 To achieve a similar function on the media plane, SIP endpoints are expected to use connectivity checks [RFC5245] to ensure there is IPv6 (or IPv4) connectivity. ICE has an advantage over the technique currently used by web browser, in that ICE does not wait for a user- noticeable timeout before trying other addresses. However, ICE is considered overkill for the problem of migrating to IPv6 because of the overhead of timers, interaction with existing media state machines, and CPU impact of SHA1 on large devices processing many sessions and on small devices. My question is of course what the opinion is about this in regards to our work in rtcweb? /O
- Re: [rtcweb] New version of -overview posted Colin Perkins
- [rtcweb] New version of -overview posted Harald Alvestrand
- Re: [rtcweb] ICE for dual stacks (new topic) Olle E. Johansson
- Re: [rtcweb] ICE for dual stacks (new topic) Roman Shpount
- Re: [rtcweb] New version of -overview posted Harald Alvestrand