RE: [MBONED] Multicast and IPv4-IPv6 co-existence

Prashant Jhingran <prashantj@huawei.com> Wed, 12 September 2007 12:41 UTC

Return-path: <mboned-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVRWs-0002U1-2I; Wed, 12 Sep 2007 08:41:14 -0400
Received: from mboned by megatron.ietf.org with local (Exim 4.43) id 1IVRWq-0002Qc-Te for mboned-confirm+ok@megatron.ietf.org; Wed, 12 Sep 2007 08:41:12 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVRWq-0002QU-DO for mboned@ietf.org; Wed, 12 Sep 2007 08:41:12 -0400
Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVRWo-00022g-RX for mboned@ietf.org; Wed, 12 Sep 2007 08:41:12 -0400
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JO900KTZ9VDW5@szxga04-in.huawei.com> for mboned@ietf.org; Wed, 12 Sep 2007 20:40:25 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JO900MTU9VCR8@szxga04-in.huawei.com> for mboned@ietf.org; Wed, 12 Sep 2007 20:40:25 +0800 (CST)
Received: from prashant7175 ([10.18.5.160]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JO9007MT9V70C@szxml04-in.huawei.com> for mboned@ietf.org; Wed, 12 Sep 2007 20:40:24 +0800 (CST)
Date: Wed, 12 Sep 2007 18:10:12 +0530
From: Prashant Jhingran <prashantj@huawei.com>
Subject: RE: [MBONED] Multicast and IPv4-IPv6 co-existence
In-reply-to: <46E7B0C6.6010801@uninett.no>
To: 'Stig Venaas' <stig.venaas@uninett.no>
Message-id: <000301c7f53a$10b3de00$a005120a@china.huawei.com>
Organization: Huawei Technologies
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Acf1H8fnj68yIgR6SS+EnY2rZLLNyAAFsssg
X-Spam-Score: 1.2 (+)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc: mboned@ietf.org
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: prashantj@huawei.com
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
Errors-To: mboned-bounces@ietf.org

As per the mail, solution for following scenarios may be
required:

- Multicast between IPv6 isolated domains connected via IPv4
backbone 
- Multicast between IPv6 only domains & IPv4 only domains
[draft-venaas-mboned-v4v6mcastgw-00.txt]
- Multicast between IPv4 isolated domains connected via IPv6
backbone  [draft-xu-softwire-4over6multicast-00]

Provided border routers are dual-stack in all the above
scenarios.

Various protocol standards exists for IPv6 multicast but
there exists none which facilitates a smooth integration of
IPv6 with the existing IPv4 networks!  

I also feel that the WG should address these scenarios
particularly the first two listed above.



-----Original Message-----
From: Stig Venaas [mailto:stig.venaas@uninett.no] 
Sent: Wednesday, September 12, 2007 2:57 PM
To: mboned@ietf.org
Subject: [MBONED] Multicast and IPv4-IPv6 co-existence

With the transition/migration to IPv6 we will probably for
decades have
nodes and networks that either can be IPv4-only, both IPv4
and IPv6, or
IPv6-only. And of course, combinations of those. Below are
some thoughts
regarding multicast and IPv4-IPv6 co-existence.

Looking at end nodes (multicast sources and receivers) the
principal
problem is that the source and all the receivers must use
the same IP
protocol. If you source multicast and some receivers are
IPv4-only and
some IPv6-only, you will need to either send the stream
twice, both IPv4
and IPv6, or you need some kind of translation.

Having the source send the content twice might be fine for
many single
source applications. It becomes more problematic if
receivers send
multicast RTCP reports that you want all the other receivers
to receive,
or if you have multi-party applications like conferencing.
One thing is
bandwidth, the other is that this is not possible if some of
the
participants are IPv4-only and some IPv6-only.

We can hope that in the short run all end-points can do IPv4
multicast
(IPv4-only or dual-stack), and that by the time we get many
IPv6-only
there will be few IPv4-only. I am far from sure this will be
the case,
but this would simplify things.

Assuming that all nodes participating in a multicast session
(all
sources and receivers) can speak the same IP protocol, one
can avoid
translation. However, while all the end-points might speak
the same,
there will probably be a need for encapsulation/tunneling
techniques to
make things work through networks that might only support
multicast for
one of the IP protocols. It might make sense to encapsulate
multicast
from one IP protocol into multicast in the other, however
one could
consider unicast encapsulation as well. There could also be
some other
interesting aspects, e.g. one might say have IPv6 islands
doing ASM
being connected by an IPv4 network using SSM.

There are also some application level issues. It is not
quite clear to
me how you for instance in SDP can signal that the same
content is
available both from an IPv4 and an IPv6 address and have the
application
somehow try one of them and if necessary fall back to the
other.

I would like to know whether people think it is worth
looking into
such issues. Are we likely to run into such problems in the
short term,
should we wait and see whether the need arises, or is it
just a waste
of time and not a real problem?

I kind of see some of these problems myself. But so far the
networks
and nodes I am exposed to are either IPv4-only or
dual-stack, so one
can always reach everyone using IPv4 multicast if one wants
to make
sure everyone can receive.

Stig


_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www1.ietf.org/mailman/listinfo/mboned




_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www1.ietf.org/mailman/listinfo/mboned