On Wed, 21 Apr 2010, Tom Limoncelli wrote: > Multicast in IPv4 and IPv6 are about equal. On the LAN they were > really well. The problem is how to route them on the WAN. The > multicast routing protocols are still evolving. It turns out to be > more complicated than one would expect.
Many people need to think about this problem a little bit to recognise how hard this is. Apologies to those for who this is trivial, but in my experiance a lot of sysadmins don't know much about how traffic is actually delivered from point to point. On the whole, routers process packets individually without keeping state on individual connections, they look at the destination address and then look at their routing table and send it to the next hop (there is the issue of how they maintain the routing table, and what to do if they have multiple routes to a destination, but simply put this is what they do). If the router is acting as a firewall it may keep state on individual connections, but most of the Internet routers do not do so. Among other things, this allows for routes to change in the middle of a session and nothing will care (you can even have packets for a single connection take different routes, so a router in the middle may not see the entire connection) With multicast traffic, the destination is going to one IP address and computers say they want to listen to a specific connection. On a local LAN you can just broadcast the traffic and it will work, but if there are many such streams going on you will quickly flood the network with traffic that isn't needed. So the computers need to tell the switches which multicast streams they are interested in seeing so that the switches can filter out all the other multicast streams. When you move to routing it gets even more complicated because you can no longer start with the 'send it everywhere and filter what's not needed' approach (as that would send packets through everyone's links), you need a way to tell a router 'I am interested in this multicast stream', and then that router needs to tell it's adjacent routers what it's interested in, etc until it finally reaches a router that knows about that particular multicast stream. If paths change between the points, the new routers involved need to know enough to send that multicast stream to the router. Maintaining this is hard, doing so in a way that can't cause overloads of the routers and links with traffic that they don't care about, or even with just the traffic of finding out if a particular multicast stream needs to be sent is even harder. Enabling multicast also opens up a vector for DOS, if someone can send you a packet saying that you should send multicast traffic their way, you then will start receiving that traffic, and sending it out another link. This eats up bandwidth on both links. If this traffic is actually used, good, but if the message was forged/incorrect you are using bandwith for nothing. I'm sure I've oversimplified this, but I think this should be a reasonable starting point for people to understand why this is hard. AFAIK IPv6 doesn't change much of anything to solve these problems. The currently common streaming process of using individual UDP connections is very wasteful for the equipment near the broadcast source as it needs to send the same data out to each destination individually, but it is very efficiant for the Internet as a whole as nothing needs to know that this is a broadcast, it's just processing packets as usual, and if you don't happen the be between the source and the destination there is no effect on you at all. Since the protocols include feedback from the destinations, if the destination disappears the dataflow will stop fairly quickly. Personally, I see multicast as something useful over a local network or limited (i.e. mostly private) WAN, but not something that can be used by everyone over the Internet as a whole without having so many problems that it will just collapse. David Lang _______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
