Re: v6-in-v4 configured tunneling over v4 multicast (vs 6over4)

[Pekka Savola <pekkas@netcore.fi>]

On Sun, 9 May 2004, Stig Venaas wrote:
> On Sat, May 08, 2004 at 09:21:55AM +0300, Pekka Savola wrote:
> [...]
> > If you want to create point-to-multipoint tunnels over v4 multicast
> > infrastructure, wouldn't the obvious solution be simply using
> > configured tunneling?  That is, you configure the tunnel destination
> > v4 address to be a multicast address (this requires zero code
> > changes), and the decapsulators configure their "local end" to be the
> > multicast address (requires code change in the tunnel setup tool to
> > permanently join the specified multicast address)?
> > 
> > This would seem to act like a "statically mapped", simplified
> > alternative to 6over4 which would only require an
> > implementation-specific addition to join the multicast group.
> 
> Are you saying that all hosts that are to share a virtual link, will
> use the same tunnel? So that all communications between all these
> hosts will be sent to one single multicast group that they all join?

No.  Sorry -- I should have been clearer on the context of the idea.

The strongest argument for 6over4 is in scenarios where you implement
v4 multicast for specific applications, and you'd implement v6
multicast for the same apps if you could (but if support is not being
provided by the vendors..).  The argument against configured tunneling
is that it requires quite a large load on the servers if the number of
participants per group grow larger than about 5-10 (due to requiring
unicast packet per receiver, instead of about one multicast packet).

So, I was thinking that these "multicast tunnels" might be able to 
complement either (non-multicast) native IPv6 or tunneled (configured 
tunnel, ISATAP whatever -- anything except 6over4) IPv6.

In other words, such "multicast tunnels" would be only used for very
specific applications, one tunnel per (group of) applications, as a 
means to leverage existing v4 multicast infrastructure to obtain the 
benefit of no multicast->unicast conversion/duplication in the 
network.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings