[MMUSIC] RE : IPv6 transition and ICE (Multicast use case)

<mohamed.boucadair@orange-ftgroup.com> Wed, 21 April 2010 17:59 UTC

Return-Path: <mohamed.boucadair@orange-ftgroup.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3FD3A6AC1 for <mmusic@core3.amsl.com>; Wed, 21 Apr 2010 10:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.504
X-Spam-Level:
X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MA1-piH6KOf for <mmusic@core3.amsl.com>; Wed, 21 Apr 2010 10:59:44 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 992853A6B89 for <mmusic@ietf.org>; Wed, 21 Apr 2010 10:54:33 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 92E141B9806; Wed, 21 Apr 2010 19:54:22 +0200 (CEST)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 708F9158099; Wed, 21 Apr 2010 19:54:22 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 21 Apr 2010 19:54:21 +0200
From: mohamed.boucadair@orange-ftgroup.com
To: Dan Wing <dwing@cisco.com>, 'Gonzalo Camarillo' <Gonzalo.Camarillo@ericsson.com>, 'Hadriel Kaplan' <HKaplan@acmepacket.com>
Date: Wed, 21 Apr 2010 19:54:21 +0200
Thread-Topic: RE : [MMUSIC] IPv6 transition and ICE (Multicast use case)
Thread-Index: AQHK4XusZLv7XpPX2k6XJVuGmM9lRg==
Message-ID: <3218_1271872462_4BCF3BCE_3218_64752_1_94C682931C08B048B7A8645303FDC9F30F0107DA75@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.4.21.171514
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] RE : IPv6 transition and ICE (Multicast use case)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2010 17:59:44 -0000

Dear all,

Another use case for ALTC is described in: http://tools.ietf.org/html/draft-venaas-behave-v4v6mc-framework-01

"
 The line of interest here is "c=IN IP4 224.2.17.12/127".  It is legal
   to use a domain name, this line would then become e.g. "c=IN IP4
   mcast.example.com/127".  The problem here is that the application is
   told to use IPv4.  It will expect the name to resolve to an IPv4
   address, and may ignore any IPv6 replies.  One could argue that it
   would be incorrect to use IPv6, since IPv4 is specified.  For DNS to
   solve our problem, we would need a new IP neutral SDP syntax, and
   applications would need to be updated to support it.

   An alternative to rewriting addresses in the network is to make the
   applications aware of the translation and mappings in use.  One
   approach could be for the source to create say SDP that includes both
   the original and the translated addresses.  This may require use of
   techniques like CCAP [I-D.boucadair-mmusic-ccap] for specifying both
   IPv4 and IPv6 multicast addresses, allowing the receiver to choose
   which one to use.  The other alternative would be for the receiving
   application to be aware of the translation and the mapping in use.
   This means that the receiving application can receive the original
   SDP, but then apply the mapping to those addresses..
"

As for the previously mentioned use cases (previous emails), this scenario does not require connectivity checks (at least for scalability issues at the source level).

Cheers,
Med

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************