In iptables in Fedora Core 4, the fourth chain is RH-Firewall-1-INPUT, which is referenced by the FORWARD and INPUT chains, and lists this rule:
* * * * *
target prot opt source destination
. . . . .
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:5353
* * * * *
I wondered about the purpose of 224.0.0.251:5353. If this was a Microsoft system, I'd suspect it of nefariously communicating something from my machine to some website out there without asking me, but I'd doubt open Linux communities would do that. Still, I wondered what 224.0.0.251 is doing there.
In researching that, 224.0.0.22 also came up.
Linux, maybe the kernel or something else that comes with Linux, knows about 224.0.0.251 and 224.0.0.22. During OS bootup with no networking, Linux sends out traffic to those two IPs (at least on my laptop) without a human requesting it. (To see the traffic on your box, set iptables to log outputs and review dmesg; you may turn that logging off after bootup.)
It seems to be about routing in some way, and not a destination of any kind. It could become a destination sometime in the future, because the right of IANA to reclaim it is present. (I haven't contacted the two people associated with Apple and Cisco named as having requested the addresses, whose requests for the addresses were over 7 years ago, and at any rate the reason for each address is now IANA's reason, regardless of what Apple or Cisco may have had in mind.)
In short, the address seems safe today. It does not appear that anyone will be able to set up a website with that as its address and collect anything from our Fedora machines that way.
The only real catch is if IANA reclaims the address from underuse, and that would be a risk for old Fedora distros, probably Apple software, and perhaps other programs still in use years later, maybe for use on what would then have become low-tech computers for specialized uses that link to the Internet. But IANA doesn't seem likely to pull the rug out from under any substantial number of users, so that may not be a big concern.
I took it out of my effective iptables setup, in the course of tightening my firewall, since I don't understand why it should be allowed, but I'm not sure about that.
Please correct me if I'm wrong. Please add if this is incomplete.
<http://forums.fedoraforum.org/showthread.php?t=174086>, as accessed today, is somewhat relevant.
Following are some quotations from IANA, Cisco, et al.:
* * * * *
The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is reserved for the use of routing protocols and other low-level topology discovery or maintenance protocols . . . . Multicast routers should not forward any multicast datagram with destination addresses in this range, regardless of its TTL.
Registry Name: IPv4 Multicast Addresses
Reference: [RFC3171]
. . . . .
224.0.0.0 - 224.0.0.255 (224.0.0/24) Local Network Control Block . . .
. . . . .
224.0.0.22 IGMP [Deering]
. . . . .
224.0.0.251 mDNS [Cheshire]
. . . . .
PEOPLE
------
. . . . .
[Cheshire] Stuart Cheshire, <cheshire&apple.com>, April 2000.
. . . . .
[Deering] Steve Deering, <deering&cisco.com>, October 1999."
* * * * *
-- <http://www.iana.org/assignments/multicast-addresses>, last updated 2007-11-28, as accessed Dec. 8, 2007 (brackets so in original; each ampersand in email addresses so in original, presumably representing "@").
* * * * *
[T]he IANA assigns addresses in the Local Network Control . . . block . . . based on the guidelines also supplied by the IETF in RFC 3171bis. These guidelines call for Expert Review, Internet Engineering Steering Group (IESG) approval, or a Standards Action process before the IANA assigns addresses in these spaces.
. . . .
The range of 224.0.0.0 through 224.0.0.251 is considered the Local Network Control Block--more commonly known as the Link-Local Block--and is used by network protocols on a local subnet segment. Packets with an address in this range are local in scope and always should be transmitted with a Time To Live (TTL) of 1 so that they can go no farther than the local subnet.
. . . . ["IGMP" and "MDNS" are] the network protcol function[s] to which . . . [they] [224.0.0.22 and 224.0.0.251, respectively] ha[ve] . . . been assigned . . . and ["[Deering]" and "[Cheshire]", respectively, are] the person[s] who requested the address[es] . . . .
. . . . .
. . . . [I]t may soon become necessary for the IANA to begin periodic reviews of these allocations and to reclaim some of these allocations that are no longer actively being used.
Layer 2 Flooding of Link-Local Multicast
IGMP Snooping normally is used by Layer 2 switches to constrain multicast traffic only to those ports that have hosts attached and that have signaled their desire to join the multicast group by sending IGMP Membership Reports. However, it is important to note that most Layer 2 switches flood all multicast traffic that falls within the MAC address range of 0x0100.5E00.00xx (which corresponds to Layer 3 addresses in the Link-Local block) to all ports on the switch even if IGMP Snooping is enabled. This is true for the current suite of Cisco switches. The reason that this Link-Local multicast traffic is always flooded is that IGMP Membership Reports normally are never sent for multicast traffic in the Link-Local block. . . . Therefore, if Layer 2 switches were to constrain (that is, not flood) Link-Local packets in the 224.0.0.0/24 (0x0100.5E00.00xx) range to only those ports where IGMP Membership reports [sic] were received, Link-Local protocols such as OSPF would break.
. . . . [The] multicast address ranges that should not be used if Layer 2 flooding is to be avoided . . . . [includes "224.0.0.0/24" (including 224.0.0.22 and 224.0.0.251)].
* * * * *
--
http://www.cisco.com/warp/public/cc/...t/ipmlt_wp.htm (posted 3-30-06 5:03:45p PST) as accessed 11-3-07 (Cisco sells products for Internet networking, such as for routing).
"Multicast Address Range": "224.0.0.0/24"
"MAC Address Range": "0x0100.5E00.00xx"
-- Per same source.
"Addresses in the Local Network Control block are used for protocol control traffic that is not forwarded off link." RFC 3171 (IANA Guidelines for IPv4 Multicast Address Assignments) (Best Current Practice), August 2001, section 3,
ftp://ftp.rfc-editor.org/in-notes/rfc3171.txt as accessed Nov. 6, 2007.
Port 5353 via UDP or TCP is for Multicast DNS, it is a registered port, and the relevant person is Stuart Cheshire, then at <MulticastDNS.org>. Port Numbers, <http://www.iana.org/assignments/port-numbers>, last updated 2007-12-03, accessed Dec. 4, 2007.
* * * * *
. . . . Version 3 of the Internet Group Management Protocol, IGMPv3 . . . . is the protocol used by IPv4 systems ["(hosts and routers)"] to report their IP multicast group memberships to neighboring multicast routers. . . .
. . . . .
IGMP is also used for other IP multicast management functions, using message types other than those used for group membership reporting. . . .
* * * * *
-- RFC 3376: Internet Group Management Protocol, Version 3 <ftp://ftp.rfc-editor.org/in-notes/rfc3376.txt>, October 2002, accessed Dec. 22, 2007 (saved as text).
* * * * *
There are three levels of conformance to this specification:
. . . . .
Level 2 [of 0, 1, and 2] allows a host to join and leave host groups, as well as send IP datagrams to host groups. It requires implementation of the Internet Group Management Protocol (IGMP) . . . .
* * * * *
-- Per same source, section 3 (main body, not appx.).
--
Nick
Linear Mode
