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

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Sep 2007 11:26:30 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: Prashant Jhingran <[email-masked]>
Date: Wed, 12 Sep 2007 18:10:12 +0530

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:[email-masked]] 
Sent: Wednesday, September 12, 2007 2:57 PM
To: [email-masked]
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

---

From: Prashant Jhingran <[email-masked]>
Date: Wed, 12 Sep 2007 18:10:12 +0530

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Wednesday, September 12, 2007 2:57 PM
To: [email-masked]
Subject: [MBONED] Multicast and IPv4-IPv6 co-existence

Stig

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 12 Sep 2007 10:46:33 -0400

> Sent: Wednesday, September 12, 2007 5:27 AM
> To: [email-masked]

As always, if you think the problem is solved with unicast, wait until
you try multicast.

I see in the near future the need for routers to do custom translation
of ASM from IPv4 to IPv6 or vice versa. I won't pretend that my needs
will be universal, though. But for such cases, it would be nice to have
a scheme where an IPv4 multicast address format that can be mapped
directly to IPv6 multicast, analogous to what is possible with unicast
RFC 4291 Section 2.5.5.2.

Maybe there are so many possible variations that we should start with
baby steps.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 12 Sep 2007 10:46:33 -0400

Bert

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Sep 2007 11:45:53 +0100

> and IPv6, or you need some kind of translation.

As someone on a site with (usually :) good IPv4 and IPv6 multicast
connectivity, we simply receive content from whichever protocol the
source uses.

In terms of our usage, we prefer to source IPv6 multicast for various
reasons (e.g. we can generate our own unique addresses easily, the
scoping is much cleaner, and Embedded RP makes small-scale multicast
communities easy to set up).   We would have no need to translate
content to IPv4 multicast internally.
 
> sure everyone can receive.

I think your (now old!) idea of having a gateway is good, and could
provide extra content in some scenarios.   It would be nice if the WG
chose to adopt it, if only as an informational document.  

But in general the 'nice' thing about IPv6 multicast is that in principle
it's easier for end users to set up multicast communities, on the assumption
their networks support Embedded RP.   One might argue it's better to
promote deployment of that (as has happened quite widely in academic
networks) rather than gateway/tunnelling methods.

I'm reminded of the recent discussion of IPv4 SSM and NAT... it's just so
much simpler in theory to use global IPv4 or IPv6... so we should be
sure there's a real need before potentially adding complexity.

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Sep 2007 11:45:53 +0100

-- 
Tim

---

From: John Zwiebel <[email-masked]>
Date: Thu, 13 Sep 2007 09:21:37 -0700

> sure there's a real need before potentially adding complexity.

I want to whole-heartedly agree.

What we have is the failure of applications to take advantage
of IGMPv3 so the network becomes overly complex and 'just doesn't work'
as well as it should.

Users want a 'short-term, quick-fix' and now 'short-term' is
approaching 10 years.

---

From: John Zwiebel <[email-masked]>
Date: Thu, 13 Sep 2007 09:21:37 -0700