Multicast Networking: Why Use 224 as Multicast Address in Many Protocols?

I've kept digging around the internet....and I think I've answered my own question.
Now I need to go back to the application/device owners/developers and see what we can do or further lock these devices down to their own VLAN.

Please leave comments or answers with any further advice.

RFC 4541 2.1.2:

1. Packets with a destination IP address outside 224.0.0.X which are not IGMP should be forwarded according to group-based port membership tables and must also be forwarded on router ports.

   This is the main IGMP snooping functionality for the data path. One approach that an implementation could take would be to maintain separate membership and multicast router tables in software and then "merge" these tables into a forwarding cache.

2. Packets with a destination IP (DIP) address in the 224.0.0.X range which are not IGMP must be forwarded on all ports.

   This recommendation is based on the fact that many host systems do not send Join IP multicast addresses in this range before sending or listening to IP multicast packets. Furthermore, since the 224.0.0.X address range is defined as link-local (not to be routed), it seems unnecessary to keep the state for each address in this range. Additionally, some routers operate in the 224.0.0.X address range without issuing IGMP Joins, and these applications would break if the switch were to prune them due to not having seen a Join Group message from the router.

Damon, I'm afraid there is something wrong with your specific implementation. I, personally, can't think of an instance where a router doesn't respond to an icmp request on any of it's interfaces. Others, please chime in if that's inaccurate.

At any rate, I mocked it up in GNS3 to make sure there weren't any funky software bugs.

Basic configurations were set up on the interfaces with each router having it's router number as the lo0 interface address (i.e. R1 - 1.1.1.1). For verification, here's the rip routing table.

R1#show ip route rip
     2.0.0.0/32 is subnetted, 1 subnets
R       2.2.2.2 [120/1] via 10.1.1.2, 00:00:07, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
R       3.3.3.3 [120/1] via 10.3.3.3, 00:00:26, FastEthernet0/1
     10.0.0.0/24 is subnetted, 3 subnets
R       10.2.2.0 [120/1] via 10.3.3.3, 00:00:26, FastEthernet0/1
                 [120/1] via 10.1.1.2, 00:00:07, FastEthernet0/0
R1#

When pinging the multicast address of 224.0.0.9, 3 replys came back; R2 sent a reply, R3 sent a reply, and R1 replied to itself because it is also listening for that address.

R1#debug ip icmp
ICMP packet debugging is on
R1#ping 224.0.0.9 source lo0 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.9, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1

*Mar  1 00:15:41.163: ICMP: echo reply sent, src 1.1.1.1, dst 1.1.1.1
*Mar  1 00:15:41.163: ICMP: echo reply rcvd, src 1.1.1.1, dst 1.1.1.1   <--- R1 Response
*Mar  1 00:15:41.179: ICMP: echo reply rcvd, src 10.1.1.2, dst 1.1.1.1  <--- R2 Response
*Mar  1 00:15:41.179: ICMP: echo reply rcvd, src 10.3.3.3, dst 1.1.1.1  <--- R3 Response
Reply to request 0 from 1.1.1.1, 8 ms
Reply to request 0 from 10.3.3.3, 24 ms
Reply to request 0 from 10.1.1.2, 20 ms
R1#

Pinging a multicast address will generate a response from participants listening to that address.