All things related to multicast

[Bill Owens <>]

We're just starting to think about the next generation of network gear for 
NYSERNet, and trying to keep an open mind about it. As a specific example 
we'll be looking at several Layer 2/3 equipment vendors, and expect they'll 
have differing levels of support for some of the features that we take for 
granted in the R&E world, but that aren't widely used in the larger Internet.

If past experience is a guide, number one on this list will be multicast 
routing, particularly interdomain IPv6 multicast routing. The NYSERNet 
network has supported IPv6 multicast for years now; it even worked, the last 
time I checked ;) Sadly, running a test is the only way to know, since nobody 
has ever made use of IPv6 multicast for anything other than a demo. Looking 
at global adoption, a check of our routing table tells the sad story:

R&E IPv4 prefixes: 14394 unicast / 3483 multicast (24%)
R&E IPv6 prefixes: 1660 unicast / 139 multicast (8%)

I'd make the argument that inertia accounts for the majority of the IPv4 
multicast adoption. Someone at a campus wanted to use a multicast-enabled 
app, or see a particular streamed event, and the campus and regional enabled 
multicast routing in support of them. Naturally they never turned it off 
again, even if the interest was for just that one event. Certainly it isn't 
being used very heavily now; I just checked our egress routers and here's 
what showed up:

Active IP Multicast Sources - sending >= 1 kbps

Group: 224.2.127.254, (sap.mcast.net)
 <various sources sending rather more quickly than they should>

Group: 228.7.7.3, (?)
 <several members of a Eucalyptus cluster>

Group: 227.255.255.254, (?)
 <two machines at louisville.edu, apparently SMART boards running 
SynchronEyes software and with the TTLs set higher than default>

Group: 224.1.1.1, (?)
   Source: 134.207.12.65 (pike.cmf.nrl.navy.mil)
 <couldn't figure out what this one was up to>

So out of the four we have SAP, which is certainly legitimate if somewhat 
less than useful most of the time, two applications that wanted to use local 
multicast but were written by morons who couldn't be bothered to learn how 
multicast addresses are supposed to be used, and one mystery contestant. 
Nothing that would make me want to enable multicast, frankly.

It seems clear that the larger networking world has bypassed native multicast 
in favor of various kinds of streaming and application-layer multicast (or 
multicast-like) transmission. There appear to be many reasons why this 
happened, not least the inability of the standards community to find a stable 
and scalable answer for wide-area any-source multicast. 

I'm not about to suggest that we drop support for wide-area IPv4 multicast. 
There are legitimate uses still being made of it, even though there aren't 
any in evidence on our network this Monday morning. I'm really beginning to 
wonder whether IPv6 multicast has a future, though. It seems to me that we're 
now seeing the other side of the adoption curve for wide-area multicast in 
general, and as a result we aren't going to have even the low volume of 
interesting applications for IPv6 multicast that drove the original adoption 
for IPv4. 

I won't even go so far as to suggest that we 'early adopters' turn off 
interdomain IPv6 multicast, although nobody would notice. But if anyone is 
actively using interdomain IPv4 multicast, they really should get to work 
moving their application over to IPv6 before the tiny number of networks who 
support it decide that it's just another source of complication, bugs and 
potential security holes, and dump it.

Bill.