All things related to multicast

[Caren Litvanyi <>]

In the past when this was discussed, the user-education mountain
was just too high.  It was thought we would do too much damage
to multicast, meaning, it would work even less than it already
does for end-users.  They'd pick an address in the wrong range,
then just give up when it didn't work.  It sounds like a good
idea, but, today there is a fair amount of legitimate traffic there.
I think the filtering would be helpful, just not sure about how
to get the user education to happen.  Most freely available docs
out there don't do much to encourage end-users to pick their
group address wisely.
Thanks,
Caren


On Tue, 20 Nov 2007, Matthew Davy wrote:

> I'm going to jump back on my soapbox about filtering the IANA Reserved 
> multicast group addresses (ie 225/8-231/8 and 234/8-238/8) at all 
> inter-domain borders.
>
> Today we had another round of MSDP instability caused by a single host 
> scanning the entire 224/4 address space.   The vast majority of this address 
> space is IANA Reserved address space that should not be routed inter-domain 
> any more than unicast IANA Reserved addresses.  Also, 232/8 is set aside for 
> SSM and 239/8 is "private" address space so you should never see MSDP SAs for 
> groups in these blocks either.   That leaves just 224/8 and 233/8 to be used 
> for inter-domain ASM.  Therefore these are the only address blocks that are 
> legitimate group addresses for MSDP SAs.
>
> If you are responsible for multicast on a campus, statewide or regional 
> network, I encourage you to update your MSDP SA filters to only permit SAs 
> with group addresses in the 224/8 and 233/8 address ranges.   I think this 
> filter should also be implemented on the Internet2 backbone.
>
> You may ask why we don't just go do this, if this is obviously the right 
> thing to do ?   Well, I just looked and it appears there are a few dozen 
> group addresses in these IANA Reserved ranges that are in active use.   I'm 
> basing this on the fact that there are 2 or more active sources from 
> different organizations for these groups.   As you might expect, the groups 
> are typically along the lines of 226.1.2.3 and 225.3.4.5.    So by 
> implementing this, we will likely break some applications, but I think the 
> long-term benefits to the stability of multicast would be significant.
>
> - Matt
>
> Matt Davy
> Chief Network Architect, Indiana University
>
>  / 812.855.7728

------------
Caren Litvanyi, network engineer
Global Research NOC at Indiana University

o:812-961-3790  c:250-896-4369