I would simply turn off non-link-local multicast (on most routers it's not even on...) and return class D and class E addresses to the allocatable pool.
If this leads to a bonus upgrade of router equipment across the Internet - well, that's one way to ensure other protocols (e.g. IPv6) are available for use. Lloyd Wood http://sat-net.com/L.Wood __________ From: [email protected] [[email protected]] On Behalf Of [email protected] [[email protected]] Sent: 06 May 2010 10:02 To: [email protected]; [email protected] Subject: Re: [rrg] RG futures [..] 3) Multicast addresses More than ten years ago I sent an email to Scott Bradner comparing the multicast addresses with the compartments in trains: both are relicts due to the past, there, because the first train would draw a few coaches, here because LANs have/need multicast addresses. Approx. a billion of addresses could be made available for unicast (as to relax the Ipv4 address depletion problem) by means of 1 Multicast-Protocol Type combined with the sender’s unicast address as to replace the multicast address. In case the counter argument were “this undermines all the deployed multicast solutions” then I would add “good so” (see next). 4) Multicast forwarding I heavily question ALL existing multicast solutions. I am also wondering why multicast doesn’t play any role at all in the RRG-discussion. My proposed solution would be “cascade tree forwarding”, enabling state-less multicast to approx. 99,9 % of the involved routers. It is the combination of all these holy cows which blocks the view to a brighter routing technology, where there is no discrepancy between intra- and inter-domain routing, nor between CES and CEE, and where better technological tools would be given to the hands of the next generation of students. Heiner _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
