[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. ********************************
- [MMUSIC] RE : IPv6 transition and ICE (Multicast … mohamed.boucadair