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

[Pekka Savola <pekkas@netcore.fi>]

I'll reply here to both you and Fred.

To Fred: yes, precisely; this mode would only allow one sender per
tunnel.  I don't see that as a big problem, as most multicast apps
(videoconferencing and similar being the exception, but those only
have a limited number of participants, so unicast duplication should
not be a problem) are intrinsically more or less single-source.

On Tue, 11 May 2004, Erik Nordmark wrote:
> > Not necessarily -- sorry for failing to say that explicitly in the
> > first place (you guys couldn't read my mind yet?!?! :).  See the note
> > I wrote to Stig for clarification.
> 
> I didn't understand that note.

OK, let me try to describe it with an example.
 
> > 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.
> 
> For those "specific applications" (whatever that means) you'd end up with 
> having everything that enters the tunnel interface on the sender being sent
> to the "tunnel endpoint", which you stated is an IPv4 multicast address.

Let's take an example.  An enterprise is has a multicast application
with IPv4, for example, video broadcast of CEO talking every morning
:-), delivering stock prices to the brokers' terminals, or whatever.
(Videoconferencing is out of scope.)  Those are mainly one-to-many 
multicast.

Now, that enterprise would wish to do the same with v6, but their v6 
routers don't support multicast (or they don't have many v6 routers in 
the first place).

The enterprise assigns the admin-scoped multicast address 239.1.1.1 
for stockticks, or 239.1.1.2 for CEO's morning address.

The host sending this feed would configure the multicast tunnel like:

src_v4: 192.168.1.1 (the IP address)
dst_v4: 239.1.1.1

(No IPv6 addresses would be needed on the tunnel, except the 
traditional link-locals.)

The receivers would configure a tunnel like:

src_v4: 192.168.1.1
dst_v4: 239.1.1.1

(This would require an addition to configured tunnel set-up to join 
the multicast address 239.1.1.1.)

The v6 packets would be sent with:

src_v6: 2001:db8:1:2::1 (the IPv6 address of the sender)
dst_v6: ff05::1234 (whatever admin-scoped v6 multicast address)

To recap, this would require the following:
 1) one tunnel per multicast application (unless you wish to dump 
    everything in one v4 group, deliver it to everyone, and let their 
    multicast subsystem filter it out.)
 2) only for one-to-many multicast apps
 3) v4 multicast infrastructure

On the other hand, the benefits are:
 1) no unicast->multicast packet duplication at the tunnel servers, 
    etc -- uses v4 multicast techniques
 2) no new protocols needed, i.e., if deploying/implementing 6over4 is 
    not seen feasible, this could provide a means to achieve some 
    benefits of 6over4 for v4 multicast application.

> If you are thinking about only using the multicast to discovery a unicast
> address of the tunnel endpoint on a per IPv6 nexthop basis,
> then I think you are recreating something isomorphic to 6over4.

No, that wasn't the intent -- and yes, that would be like 6over4.

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