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

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 12 May 2004, Erik Nordmark wrote:
> > 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.
> 
> I think you mean "single sender" since all multicast is "one-to-many".
> Are you explicitly excluding applications, such a streaming media,
> which have a unicast feedback channel? (for quality reports etc)

Sorry for the terminology mess.  I'm referring to the distinction of 
SSM vs ASM, where you either have "one-to-many" sessions or 
"many-to-many" sessions (from the perspective of the network and the 
receivers).  From the sender's point of view, it's always obviously 
one-to-many.

Unicast feedback channels are not excluded; I'd just assume that the
unicast v6 reachability is obtained using a different mechanism
(natively, using another configured tunnel, a tunnels server,
whatever).

> > 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).
> 
> Does "don't have many v6 routers" imply that there
> might not be unicast connectivity between all the nodes for which you want
> to establish single-sender multicast connectivity?

It's possible that native v6 would not be available to everyone, in 
which case some tunneling (separate from the multicast tunnels) would 
be used.

> > (No IPv6 addresses would be needed on the tunnel, except the 
> > traditional link-locals.)
> 
> I think that implies that it is impossible to have unicast feedback;
> there isn't a tunnel configured on the multicast receivers which can be
> used to send packets to the senders link-local IPv6 address, is there?

Connectivity is obtained separately, natively or through a different 
set of tunnels.  So there would be a feedback channel, but the 
feedback would go through a different route than the multicast feed.

> > 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.
> 
> But why not just run this application over IPv4 multicast?

Good question.  I suppose the idea is to transition the network to 
IPv6, and being able to do the same with v6.  I think the argument in 
the original scenario was that if there is no mechanism for v6, people 
could not transition their apps etc. to v6, or might delay the v6 
deployment for the lack of support.

If truth be told, and considering dual-stack deployments, this is not 
really convincing, because as it works with v4, and the only thing 
missing from v6 is the support in their equipment, a correct 
response could be continue using it w/ v4 and request implementing v6 
multicast support, or buy only products which support that.

But delaying v6 deployment due to this might not be a good idea 
either, which is why I thought a separate multicast tunnel could be an 
easy solution to this problem.

> I don't see what IPv6 multicast using only IPv6 link-local addresses
> (and perhaps not a unicast return channel) would provide
> over what IPv4 multicast can provide in this case.

You don't need to use IPv6 link-local addresses, you can use a wider
scope as well.  But a link-local would be the simplest, and unicast
return channel would be possible as well.

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