Chapter 4 - Multicasting and the Internet Group Management Protocol


SummaryIP multicasting allows IP datagrams to be sent to explicit hosts on multiple networks simultaneously. This is different from traditional broadcasting in that not all hosts have to process the data, and hosts on remote networks can also receive the datagrams. The Internet Group Management Protocol provides a mechanism for IP devices to register with multicast routers, indicating the multicast groups they are interested in participating in.
Protocol ID2
Relevant STDs2 (http://www.iana.org/);
3 (includes RFCs 1122 and 1123);
5 (includes RFCs 791, 792, 919, 922, 950 and 1112)
Relevant RFCs1112 (IP Multicasting and IGMPv1);
1122 (Host Network Requirements);
1469 (Token Ring Multicasting);
2236 (IMGP v2)
Related RFCs1075 (Distance Vector Multicast Routing Protocol);
1256 (Router Discovery);
1584 (Multicast Extensions to OSPF);
2365 (Administratively Scoped IP Multicast);
2588 (IP Multicast and Firewalls)

When a system needs to communicate with other hosts on the local network, it typically does so either by broadcasting a packet to every host on the local network or by sending unicast datagrams to a specific destination.

Another alternative that can be used is multicasting, a technique that lets a system send data to a group address. Any hosts that are monitoring that group address will receive the data, while every other device on the network will simply ignore it.

This model is particularly useful for applications that require a host to send data to multiple destinations simultaneously, but would be hindered by the limitations found with broadcasts.

For example, applications such as streaming audio require that a host be able to send data to multiple hosts simultaneously. While it may seem that general-purpose broadcasting can be used for these types of applications, it is not necessarily the most efficient model to use. For one thing, broadcasts are meant for every host on the local network. As such, they will not reach hosts that are on remote networks (most routers filter out broadcast traffic). But if a host on a remote network needed to receive that data, then the broadcast traffic would have to be re-broadcast to the remote network, getting sent to every host on that remote network, regardless of whether or not they wanted the traffic.

Furthermore, with broadcast traffic, every device on the local network has to monitor all of the packets and then decide if the data is needed by any local applications. If the data wasn't useful, then it still had to be processed before this fact was discovered. With bandwidth-intensive applications like network multimedia, this traffic results in every system on the network spending a large amount of computing resources examining and then discarding unwanted messages. But by using multicasts instead of broadcasts, hosts can choose which network streams they want to monitor, and higher-layer protocols will only have to process the packets they are specifically interested in. Hosts that do not want any data from a particular multicast group will not have to process anything extra.

In short, multicasts allow for broadcast-like activity, while providing explicit support for remote hosts and networks on a selective basis. This is a particularly important service with bandwidth-intensive applications like network multimedia, but also is useful for any application that requires a host be able to communicate with multiple systems simultaneously.

For example, the Router Discovery protocol (defined in RFC 1256) makes extensive use of multicasting to allow devices to automatically locate the routers on a network, and there is a draft proposal that proposes to imbue DNS clients with the ability to locate DNS servers automatically using this same model. There are even proposals for using multicast transfers with TFTP to send data to multiple hosts simultaneously, and for replicating Usenet newsfeeds to multiple servers with a single stream (instead of many large unicast transfers).

Multicasts are useful for all of these applications, allowing data to be sent to multiple systems simultaneously, rather than sending it on a point-to-point basis to each of them discreetly. In fact, anything that can benefit from a single feed to multiple, distributed destinations can benefit from IP multicasts.

The IP Multicasting and IGMP Specifications

IP multicasting is documented in RFC 1112, which is included in STD 5 (the IP standard). As such, IP multicasting is a part of STD 5, and is therefore considered to be an Internet Standard protocol. All hosts are required to implement multicasting into their IP stacks if they are to be compliant with Internet standards.

In addition to the IP multicasting services, RFC 1112 also defined IGMPv1, a follow-up to IGMPv0 (originally published in RFC 998). IGMPv2 was introduced in RFC 2236 as an update to IGMPv1, and has gained a substantial number of implementations. Some IGMP implementations only support IGMPv1 while others support IGMPv2 and v1.*

Of the differences between IGMPv1 and v2, the most notable addition in IGMPv2 was the addition of the Leave Report message, which allows a host to inform the network that it is no longer interested in receiving IP datagrams for a specific multicast group. This feature is required for networks that use data-link services that do not support multicasting directly (such as PPP). This chapter focuses on IGMPv2 primarily, and only mentions IGMPv1 when there is a significant difference.

RFC 2236 states that the Protocol ID for IGMP is 2. When a system receives an IP datagram that is marked as containing Protocol 2, it should pass the contents of the datagram to IGMP for further processing. However, note that IGMP is not a transport protocol and is not used for the delivery of multicast data. Rather, IGMP is a control protocol like ICMP, useful for informing devices of network events and changes.

It is also important to note that although all hosts are required to implement IP multicasting, they are not required to implement IGMP. If they do not implement IGMP, however, then they cannot tell local multicast routers that they wish to receive multicast packets. Although a host can send any data it wants to a multicast group IP address, hosts can only receive multicast data reliably if they implement IGMP. Most of the multicast-aware systems in use today implement IGMP, as well as the basic support for multicast services.

The default Time-to-Live value for IP datagrams sent to a multicast address is 1 hop , unless the sending application explicitly specifies a larger value. Also, it should be noted that IGMP messages are only meant to be received and processed by devices on the local network, and as such the Time-to-Live value for IP datagrams that contain IGMP messages should always be 1 hop . Although multicast data can be sent across router lines, IGMP messages should never be forwarded.

* IGMP stands for Internet Group Management Protocol.

An Introduction to IP Multicasting

In essence, IP multicasting is a function of the IP address in use by a particular multicast group. If a user wants to send an audio presentation to a variety of distributed hosts simultaneously, then that user would send the data to an IP address that was associated with a particular multicast group. Any hosts that were listening for traffic destined for that IP address would then receive the data and process it accordingly, while other hosts would simply ignore it.

The application protocol used for such a feed could be a RealAudio stream sent as a bunch of UDP messages over IP. These messages would not look any different from the same data being sent to a single destination system or to the local broadcast address. The only difference between the multicast datagrams and their unicast or broadcast equivalents would be the destination IP address in use with those datagrams: the unicasts would point to a specific destination system, the broadcasts would point to all hosts on the local network, and the multicasts would point to a group address.

In the IP world, multicast group addresses are known as Class D addresses and include all of the IP addresses in the range of 224.0.0.0 through 239.255.255.255. Each of the individual addresses in this range refer to specific multicast groups, many of which are associated with a specific application or service.

There are a number of predefined, reserved addresses that are registered with the Internet Assigned Numbers Authority (IANA). For example, all of the addresses in the range of 224.0.0.0 through 224.0.0.255 are reserved for use with routing protocols and other low-level, infrastructure-related services. Some of the more common registered addresses are shown in Table 4-1. For a detailed listing of all of the multicast groups that are currently registered, refer to the IANA's online registry (accessible on the Web at http://www.isi.edu/in-notes/iana/assignments/multicast-addresses).

Table 4-1. Some Common Multicast Group Addresses
Multicast AddressDescription
224.0.0.1All local multicast hosts (including routers). Never forwarded.
224.0.0.2All local multicast routers. Never forwarded.
224.0.0.4DVMRP routers. Never forwarded.
224.0.1.1Network Time Protocol.
224.4.1.24Microsoft's Windows Internet Name Service locator service.

Besides the reserved addresses that are managed by the IANA, there are also unreserved addresses that can be used by any application for any purpose, although conflicts may occur with other users who are also using those multicast addresses. Any group address that is frequently used is encouraged to register with the IANA.

Any host can send data to a multicast group address simply by providing the multicast group address in the destination field of the IP datagram. Any hosts that are listening for traffic sent to that group address will pick up the data.

If an application wishes to participate in a local multicast group as a listener, all it has to do is inform the local system's IP stack and network adapter of the group address to be monitored. If this step is not performed, then the system will likely ignore traffic going to the multicast group addresses of the applications in use. By registering with the local interface, any data sent to the multicast address in use by the application will get picked up and monitored by the local system and then get delivered to the local application for processing. The following section, Local Multicasting , describes this process in detail.

If an application wishes to participate in a distributed multicast group across a router, then the application must still perform the local registration tasks described above, but it must also register its desire to receive traffic for that group address with any local multicast routers. This step is required before multicast routers will forward any remote multicast datagrams for that group address onto the local network. Distributed Multicasting later in this chapter describes multicasting over multiple networks in detail, while Managing Group Memberships , also later, describes the registration process.

Local Multicasting

Remember that IP datagrams (and IP addresses) are used only to represent a consistent view between IP-enabled devices, and that when two devices on the same local network want to communicate with each other they will use the topology-specific protocols and addresses defined for the local network medium to actually exchange data. For example, two hosts on the same local Ethernet segment will use Ethernet framing and addressing mechanisms when they want to exchange IP data, with the IP packets being passed in the Ethernet frames. Meanwhile, hosts on Token Ring networks will use the protocols and addressing mechanisms specified in the Token Ring standards when they want to exchange data.

These same rules apply with multicast traffic, which must also use the low-level protocols and addressing rules defined for whatever medium is in use with the local network. When multicast IP packets are being passed around the network, they are really being sent in a form that uses the multicasting services that are provided by the underlying network topology.

Most shared-medium networks provide three distinct types of addressing:

Unicast
Unicast data is sent from one device to another, using an explicit destination address. Devices on the network must monitor the network traffic, looking for any frames that are marked for their local hardware address. With Ethernet, this is a 48-bit address typically written in hexadecimal notation as something like c0:14:3d:22:1e:04.

Broadcast
Broadcast data is sent from one device to every other device on the local network, using a broadcast address specific to the network topology. Devices on the network must monitor the network traffic and read any frame that is marked for the broadcast address. With Ethernet, the 48-bit broadcast address is all on, typically being written in hexadecimal notation as ff:ff:ff:ff:ff:ff.

Multicast
Multicast data is sent from one device to a specific multicast group address. Devices on the network choose which multicast groups they want to participate in, and then monitor the network traffic, looking for any frames that are destined for one of those multicast groups (ignoring any other frames that are going to any other multicast group addresses). Ethernet offers a variety of multicast group addresses, ranging from 01:00:5e:00:00:00 to 01:00:5e:7f:ff:ff.

In order for IP multicast traffic to be sent to multiple hosts simultaneously, the IP multicast addresses must be mapped to the multicast addresses in use by the local network, and the local IP stack must inform the local network adapter of the multicast groups that the adapter should be listening for. Unless the hardware is listening for traffic sent to the hardware-specific multicast addresses, the IP software (and thus UDP and the application-layer protocols) will never get the IP packets.

Some conversion is usually required in the process of mapping multicast IP addresses to multicast hardware addresses. For example, the range of available Ethernet multicast addresses only provides 23 of the 48 available bits for defining specific multicast group addresses, although IP uses 26 bits from the 32-bit Class D address block to identify specific multicast groups. Therefore, to map IP multicast addresses onto Ethernet multicast addresses, the last 23 bits from the IP multicast address are mapped onto the 23 bits available for the Ethernet multicast address.

For example, Figure 4-1 shows a multicast packet bound for 224.0.0.1 being sent to the Ethernet group address of 01:00:5e:00:00:01. The last 23 bits of the IP address (0000000 00000000 00000001) have simply been copied to the Ethernet group address block of 01:00:5e:00:00:00.

This mapping results in some overlap, with some multicast groups sharing a single Ethernet multicast address. In this case, the IP software on the destination

0141-01.gif
Figure 4-1.
Mapping Ethernet addresses to Class D IP addresses

systems must perform some filtering, discarding any IP packets that are destined for a multicast group address (as specified in the IP header) that the device does not want. For example, if the network adapter is monitoring for Ethernet-specific multicast addresses that fall within the duplicate range, then the IP software in use on the listening host must also examine the destination IP address shown in the IP datagram before handing the data to the specified transport protocol for subsequent processing.

Although this presents a challenge for users on Ethernet networks, some topologies have even greater degrees of overlap, and require much greater levels of filtering. For example, Token Ring networks have a limited number of group addresses available to them, so all Token Ring multicasts must share the same group address of c0:00:00:04:00:00.

Some networks don't provide any form of group address at all, and are strictly limited to unicast and broadcast frames. On those networks, the topology-specific broadcast address must be used for all multicast data, requiring that hosts filter through all broadcast packets. Note that some point-to-point networks don't even have broadcast addresses. Instead, they have only send and receive wires. On those networks, multicast routers must use topology-specific unicast frames to deliver data to the destination systems.

owl.gif Some switches offer an intelligent multicast filtering mechanism, whereby they can interpret an IP multicast request and apply a filter on the switch port for that device, effectively limiting the multicast traffic sent to the device according to the multicast IP addresses that the device has sent out.

Regardless of these issues, the important thing to remember is that IP multicasts use the addressing and delivery mechanisms offered by the underlying network topology, just as every other type of IP packet does. Some network topologies provide better mapping services than others, but almost all of the widely used LAN topologies allow for multicasts using some form of explicit group addressing.

When an application on a host wishes to begin receiving multicast packets, it must inform the local network adapter that it should begin accepting network packets for the specific multicast group (if that service is available, as it is on Ethernet). If a host is directly attached to multiple networks, it may register with any of the network interfaces explicitly, or it may register with all supported interfaces simultaneously. Applications have to explicitly state which networks they want to monitor. Typically, hosts with multiple interfaces will have a default multicast interface that they use for reading and writing multicast traffic.

Sometimes this registration occurs at the same time as the network-wide IGMP registration process, and sometimes it occurs just before the IGMP registration process, as a precondition of the IGMP registration request. This is an implementation-specific issue. The important thing to remember is that registering with the network adapter(s) on the local system and registering with the local multicast routers (via IGMP messages) are two separate and distinct acts.

Distributed Multicasting

One of the big differences between IP multicasts and IP broadcasts is that multicast datagrams can be sent to remote networks, while broadcasts are normally restricted to the local network. By being able to forward multicast feeds across network boundaries, multicast routers can get multicast datagrams to hosts around the world, allowing the hosts to participate in global multicasting groups, with multicast datagrams going to every network that has a host that is participating in that particular multicast group.

This process is achieved by using multicasting routers that are particularly aware of multicast traffic and the routing issues associated with that type of traffic. This model involves a couple of theories that are somewhat different from traditional routing.

For one thing, the local multicast router must be listening for multicast packets. The router has to actively monitor the network for IP traffic that has a destination address of 224.0.0.1 through 239.255.255.255, and then forward that data on to any other multicast-enabled network segments that are attached to the router (or any tunnels to remote multicast networks that may be configured). Traditional routers do not monitor the network looking for packets that need to be forwarded, but instead wait for data that needs to be sent to the router (for forwarding) explicitly.

Also, since the destination address is a multicast address and not a unicast address, the multicast router has to forward any multicast data that it sees to every other network segment attached to the multicast router. In addition, since not every network is multicast-enabled (i.e., does not have a multicast router on it), many networks are bridged together using multicast tunnels, whereby multicast traffic is sent as unicast datagrams to another multicast router at the far end of the tunnel. Regardless of how the networks are connected, the model is the same: multicast routers send multicast data to the other multicast-enabled networks that they know of, and any multicast routers on those networks will pick up the frames and forward the data to any other multicast-enabled networks that they are attached to.

This allows hosts on remote networks to receive locally generated multicast data, and vice versa. And since any additional multicast routers on those networks will see and forward any multicast data that comes onto their network, they will also forward the data on to any other multicast-enabled network segments that they are attached to. This allows the data to be propagated across the entire Internet.

For example, Figure 4-2 shows an IP packet being sent from Ferret to the multicast address of 224.1.2.3. If any remote hosts (such as Fungi) want to monitor that group address, then Sasquatch has to monitor the network on its behalf, pick up any matching data, and then explicitly forward the packets out to the other segments (where they would eventually be received by Fungi).

There are some special considerations with this model that must be followed in order for everything to work smoothly. Otherwise, simply propagating multicasts across the different networks could result in them becoming saturated with unwanted data.

Limited forwarding

The primary rule that multicast routers follow is that they will only forward multicast traffic to the networks that have expressed an interest in that specific type of data. For example, Figure 4-2 shows two subnets. When Ferret sends a multicast datagram to the 224.1.2.3 group address, Sasquatch has to forward the datagram to the 192.168.20.0 network in order for Fungi to receive it. However, Sasquatch will only do this if Fungi has explicitly stated that it was interested in data for the 224. 1.2.3 multicast group.

0144-01.gif
Figure 4-2.
Routing in a multicast environment

This statement of interest is achieved by using IGMP messages, which are sent by the hosts when they first come onto the network, and which are also sent in response to IGMP queries issued by local multicast routers. There are lots of rules and conditions that are involved with this scenario which are discussed in more detail in Managing Group Memberships later in this chapter. However, the basis of the protocol is that hosts announce which multicast groups they want to listen to, and routers use this information to determine which networks they will forward data to. In essence, a multicast router will only forward multicast data to a network if there is an active listener for that group address on that network.

In addition, multicast routers must also forward any group registration information they have to all other multicast routers that they know about. This procedure ensures that other routers know to send multicast data to their networks. Otherwise, upstream routers would not send any data for that multicast group address down to the local network. Note that this process is handled by different multicast routing protocols in different ways, but that they all do the same basic thing: informing other networks of the groups that this particular network wants to receive traffic for.

Time-to-Live considerations.

Blindly forwarding multicast data around the Internet could cause significant utilization problems. For this reason, another important aspect of wide-area multicasting is the Time-to-Live value of the multicast IP datagram. As was discussed in Chapter 2, The Internet Protocol, the IP datagram's Time-to-Live header field dictates the maximum number of hops that a datagram can take before it must be discarded. Since all multicast datagrams are sent using IP, this field is also used with multicast datagrams, and is also used by multicast routers to keep traffic from propagating across too many multicast routers.

Multicast group addresses in the range of 224.0.0.0 through 224.0.0.255 are reserved for administrative use only, and as such are restricted to the local network. Any data sent to those addresses must have a Time-to-Live setting of 1 in order to keep those messages from being forwarded across multicast routers. RFC 2236 goes so far as to state that even if the Time-to-Live is not set to 1 on those datagrams, they still should not be forwarded.

For example, the all-hosts group address of 224.0.0.1 refers to all of the multicast-aware devices on the local network. Whenever a multicast router wants to locate the active multicast groups in use on the local network, it will send an IGMP query to the 224.0.0.1 group address. In addition, the multicast router must set the Time-to-Live value of that query to 1, preventing any other multicast routers on the local network from forwarding the query to any other networks they may be attached to.

In addition to these considerations, it is also important to note that ICMP errors must not be generated in response to IGMP or multicast datagrams, as that could result in many ICMP messages getting sent for every multicast or IGMP packet. Therefore, if a multicast router sees an IGMP message with the Time-to-Live value set to 1 (normally meaning that the datagram is about to expire and cannot be forwarded), then the ICMP software on that router must not return an ICMP Time Exceeded error message. Instead, the datagram should just be discarded silently. For more information on ICMP, refer to Chapter 5, The Internet Control Message Protocol.

Managing Group Memberships

Although any host can send traffic to a multicast group, applications that want to participate in a distributed multicast group as listeners must inform the local multicast routers of the groups that they want to listen for. This is done using IGMP messages that state the multicast group address that the host wants to participate in.

In addition, multicast routers also use IGMP messages to query the local network for hosts that have active memberships in multicast groups that are being routed to the local network. This is basically the entire function of IGMP: routers asking for hosts that are listening for multicast traffic, and hosts telling routers which groups they are listening for.

All IGMP messages have certain requirements. First of all, they must all have the Time-to-Live value of the IP datagram set to 1 hop , thereby preventing them from being forwarded by any routers. In addition, RFC 2236 states that all IGMP messages should set the IP datagram to use the IP Router Alert Option, as discussed in Router Alert in Chapter 2.

Membership reports

The process of registering with a router is very straightforward. Whenever an application that needs to participate in a specific multicast group is started, an IGMP Membership Report is sent by the host to the multicast address in use by the application. RFC 2236 states that multicast hosts should resend the first Membership Report within a few moments, in case the first one was lost or damaged.

For example, servers running the multicast-enabled Simple Network Time Protocol (SNTP) can use the multicast group address of 224.0.1.1 to automatically pass time-synchronization data across the network to SNTP-enabled clients. Whenever an SNTP system is started, it will immediately send a couple of IGMP Membership Reports to the 224.0.1.1 multicast address, as illustrated in Figure 4-3. Any multicast routers on the local network will see this report, and use this information when building their multicast-forwarding maps.

0146-01.gif
Figure 4-3.
An SNTP-enabled system announcing its presence to the network

Membership Reports are also sent in response to IGMP Membership Queries, which are periodically sent by multicast routers on the local network in order to determine which multicast groups still have active memberships. Whenever a query is received, at least one host from each multicast group on the local network must respond with a Membership Report. This procedure is described in more detail in Membership queries later in this chapter.

Note that Membership Reports are never generated for the all-hosts group address of 224.0.0.1. Although every multicast-enabled host should listen for traffic on that multicast address, no host should ever report its membership in that group.

Leave reports

Another announcement mechanism that is commonly seen with many multicast applications is the Leave Report, used to announce that a particular host is no longer interested in receiving multicast traffic for a particular group. The idea behind this report is that it can be used to inform a local multicast router that the host is going away, and that the router can stop forwarding multicast data for the specified group address to this network.

There are some special considerations with this type of report. For one thing, the router has to verify that the host that is leaving the multicast group is indeed the last user of the specified group address, otherwise any other hosts on the local network that still wanted to receive traffic for that group wouldn't get it any more. This is achieved through the use of a group-specific query message (as we'll discuss in the next section, Membership queries ). If no hosts respond to the group-specific query, the router can stop forwarding traffic for that group's multicast address immediately, thereby reducing the local bandwidth consumption.

Furthermore, Leave Reports were introduced in the IGMPv2 specification, and were not a part of the IGMPv1 specification. As such, they will only be used on systems that use IGMPv2, and will be ignored by systems that are using IGMPv1.

It is important to note that Leave Reports are not sent to the multicast address of the group being left as are Membership Reports, but instead are sent to the all-routers group address of 224.0.0.2, which is similar to the all-hosts address, except that it is only monitored by multicast routers.

Figure 4-4 shows the NTP client from Figure 4-3 announcing that it is leaving the network. In the example network shown, only Sasquatch should receive the Leave Report, since it is the only monitored by multicast router on the network.

Devices that do not understand Leave Report messages should silently discard them, as they should all other unknown message types.

0148-01.gif
Figure 4-4.
An SNTP-enabled system announcing its departure from the network

Membership queries

Another commonly seen IGMP message is the Membership Query. Queries are sent by multicast routers in order to verify that each of the multicast groups that are currently being forwarded still have listening members on the local network (by default, the interval between queries is 125 seconds). If no hosts respond to a Membership Query, then the router can stop forwarding multicast datagrams for any of the multicast groups that no longer have any active listeners on that network.

Typically, only one multicast router issues these queries. Any other multicast routers on the network then takes a passive role, watching for Membership Reports, but not sending any queries. The query router is elected by having the lowest-numbered IP address. If that router stops issuing queries, then the multicast router with the next-higher IP address will become the query router.

Hosts respond to Membership Queries with standard Membership Reports, and the multicast routers use this information to determine which multicast addresses should be forwarded to the local network. If no hosts respond for a multicast address that is already being forwarded, then the multicast router can assume that nobody wants that traffic anymore and can stop forwarding remote datagrams for that multicast address to this network.

Membership Queries are sent to the all-hosts address of 224.0.0.1. With IGMPv2, routers are also allowed to send group-specific queries to test for membership in a particular group, if this is needed for some reason. Regardless of the query type,

the hosts on the network will respond to the Multicast Query by sending their Membership Reports to the multicast addresses in use by their local applications, just like always. Multicast routers are required to listen for data on every multicast address, so they will see all of the responses.

Figure 4-5 shows an IGMP Membership Query being sent to the all-hosts group address of 224.0.0.1. The IGMP messages that are generated in response to the query would be simple Membership Reports—sent to the multicast addresses in use by the applications on those hosts—as shown back in Figure 4-3.

0149-01.gif
Figure 4-5.
An overview of the membership-sampling process

Keep in mind that the purpose of the Membership Query is to locate any hosts that are actively listening for a specific group, and is not intended to locate every host that may be listening. Since multicast routers only need to know that at least one host is listening for specific multicast addresses, they do not benefit from multiple hosts responding for a single multicast address.

For this reason, hosts incorporate a random length timer that they use before responding to a Membership Query. If no other hosts have responded on behalf of the multicast groups in use on this host before the timer expires, then the host will issue a response. Any other hosts that have not yet responded for that group will then abort their own responses. However, it should be noted that this procedure is conducted on a per-group basis: if a host aborts a response for a group because some other host has already responded to the Membership Query, then it does not abort all of the pending responses; instead it will only abort responses for the groups that have already been responded to by the other hosts.

IGMP Messages

Before a host can receive and process multicast datagrams, it has to do two things: it must inform the local network interface card that it wishes to accept and process network frames for specific multicast groups, and it must inform any multicast routers on the local network that it wishes to receive the IP packets for those multicast groups as well.

How the application communicates with the local network interface card is a function of the specific IP implementation in use on the local system (the process is discussed earlier in this chapter in Local Multicasting ). However, the mechanisms used by IP to inform the multicast routers on the local network of its desire to participate in certain multicast groups is a function of the Internet Group Management Protocol (this process is discussed earlier in Managing Group Memberships ).

IGM Message Headers

IGMP messages consist of a predefined set of fields that indicate the type of message being passed and the multicast group that the message applies to. Each message type is used in specific scenarios and is indicated by a field in the header. Depending on the version of IGMP in use and the type of message being sent, an IGMP message will have four or five fields, with different fields being used for the different versions of IGMP.

Table 4-2 lists all of the fields in IGMPv1 messages, along with their size (in bits) and some usage notes. For more information on these fields, refer to the individual discussions throughout this section.

Table 4-2. The Fields in an IGMPv1 Message
FieldBitsDescription
Version4Indicates the version of IGMP in use (always 1).
Message Type4Indicates the message type (such as query or report ).

Table 4-2. The Fields in an IGMPv1 Message (continued)
FieldBitsDescription
Unused8This field is unused with IGMPv1 query messages, and must be filled with zeroes.
Checksum16Used to store a checksum of the IGMP message.
Multicast Group32The 32-bit IP address of the multicast group that this message is associated with.

Table 4-3 lists all of the fields in IGMPv2 messages, along with their size (in bits) and some usage notes. For more information on these fields, refer to the individual discussions throughout this section.

Table 4-3. The Fields in an IGMPv2 Message
FieldBitsDescription
Message Type8Indicates the message type (such as query or report ), and also uses some bits to indicate the version of the message.
Max Response Time8Indicates the longest period of time that a host should wait before responding to a query. This field is only used with IGMPv2 query messages, and is unused with IGMPv1 messages.
Checksum16Used to store a checksum of the IGMP message.
Multicast Group32The 32-bit IP address of the multicast group that this message is associated with.

Note that the size and use of the fields are such that IGMPv2 messages are almost identical to IGMPv1 messages. The only real differences between the two versions is that IGMPv2 messages have subsumed the Version field into the Message Type field, and that the IGMPv1 Unused field is now the IGMPv2 Maximum Response Time field.

The total length of a normal IGMP message is eight bytes. However, other IGMP messages may be longer, particularly with messages that are specifically used with multicast routing protocols and the like. If the Message Type is recognized as being one of the core messages, IGMPv2 implementation must ignore any additional data after the first eight bytes (although the checksum will be for the entire message, and not just the first eight bytes).

All IGMP messages are sent within IP datagrams directly. Each of these datagrams must have a protocol identifier of 2 and an IP Time-to-Live value of 1 hop . In addition, all IGMPv2 messages must use the Router Alert Option in the header of the IP datagram.

Figure 4-6 shows an IGMPv2 Membership Query message, which will be used to dissect the headers of the IGMP Message.

0152-01.gif
Figure 4-6.
A simple IGMP Message

The following sections discuss the header fields in detail.

Version

With IGMPv1 messages, indicates the version of IGMP in use. However, IGMPv2 subsumed this field into the Message Type field, although IGMPv2 messages still set these four bits to 1.

Size
Four bits.

Default Value
1

Defined In
RFCs 1112 and 2236.

Notes
With IGMPv2, this field has been subsumed into the Message Type field, although it is still used to report version information in some cases. In all cases, this field should report a version number of 1, allowing older multicast routers to process the data. If this field reported 2, then IGMPv1 multicast routers would ignore the messages.

Capture Sample
In the capture shown in Figure 4-7, the Version field (i.e., the most significant four bits of the Type field) is set to 1, although the Message Type field shows that this is an IGMPv2 message. All of the messages currently defined for IGMPv2 use 1 in the four-bit version field.

0153-01.gif
Figure 4-7.
The Version field

See Also
Message Type

Message Type

Specifies the specific type of message being sent (such as query or report ).

Size
Four bits.

Default Value
N/A

Defined In
RFCs 1112 and 2236.

Notes
Each IGMP message is identified by a four-bit numeric code that maps against a specific type of service. There are a variety of message types provided in IGMPv1 and IGMPv2. Table 4-4 lists the different message types, their codes, and descriptions for their use.

Table 4-4. IGMP Message Types and Their Meanings
CodeMessage TypeDescription
1Membership Queryused by IGMPv1 and IGMPv2 multicast routers to locate the multicast groups in use by hosts on the local network.
2v1 Membership ReportIdentifies this message as an IGMPv1 Membership Report
6v2 Membership ReportIdentifies this message as an IGMPv1 Membership Report
7v2 Leave ReportUsed by IGMPv2 hosts to announce that they are leaving a multicast group.

Although all of the IGMP messages that are described in RFC 1112 and RFC 2236 use 1 in the version field, each of them use different codes for the message types that are generated by the Membership Reports. For example, Figure 4-8 shows an IGMP Membership Query (identifiable by the Message Type being set to 1).
Unrecognized message types should be silently ignored.

Capture Sample
In the capture shown in Figure 4-8, the Message Type field is set to 1, indicating that this message is an IGMPv2 Membership Query.

0154-01.gif
Figure 4-8.
The Message Type field

See Also
Managing Group Memberships

IGMP Message Types
Version
Maximum Response Time
Multicast Group

Maximum Response Time.

Identifies the maximum amount of time that a host may wait before responding to an IGMPv2 Membership Query, in tenths of a second. This field is not used with IGMPv1 messages or IGMPv2 Membership Reports.

Size
Eight bits.

Default Value
0

Defined In
RFC 2236.

Notes
This field is almost always set to 0, either because it is unused with IGMPv2 Membership Reports and Leave Reports, or because it originated from an IGMPv1 system.

If the message is an IGMPv2 Membership Query, the value specified in this field is used to inform hosts on a network how much time (in tenths of a second) they have before they must respond. This is useful in situations where hosts are waiting for each other to respond (a process described earlier in Membership queries ). By providing a maximum response time value, hosts will be forced to choose a random value within the given amount of time.
If the message is an IGMPv1 Membership Query, this value should be set to 0. In that case, IGMPv2 hosts should interpret the 0 to be 100 (or 10 seconds ), and respond within that time frame. Membership Report messages should set this field to 0, since it has no meaning for those messages.
IGMPv1 hosts will ignore this value, if it's defined in a Membership Query.

Capture Sample
In the capture shown in Figure 4-9, the Maximum Response Time field is 100, which is equal to ten seconds.

See Also
Managing Group Memberships

Message Type
0156-01.gif
Figure 4-9.
The Maximum Response Time field

Checksum

Used to store a checksum of the IGMP message, allowing destination systems to validate the contents of the message and test for possible corruption.

Size
Sixteen bits.

Default Value
N/A

Defined In
RFCs 1112 and 2236.

Notes
The checksum field provides a simple validation scheme for IGMP messages. When calculating the checksum, the sending system looks at the entire message (with the Checksum field set to 0) and performs a simple checksum operation. This procedure is reversed by all recipients before the contents of the message are processed.

Note that the checksum applies to the entire message, even if the message is more than eight bytes long (longer messages may be a result of future versions or external protocols). As long as the Message Type is recognized as an IGMP core message, then the segment should be accepted and only the first eight bytes should be processed. However, the checksum value will apply to the entire message, and it is not limited to the first eight bytes of the message.
Also note that the Multicast Group field provides some additional sanity checking, allowing the recipient to verify that the IP datagram's destination multicast address is the same as that used in the Multicast Group field.

Capture Sample
In the capture shown in Figure 4-10, the Checksum is shown as ee 9b .

0157-01.gif
Figure 4-10.
The Checksum field

See Also
Message Type

Multicast Group

Multicast Group

Specifies the multicast group address that this message applies to.

Size
Thirty-two bits.

Default Value
The destination multicast address specified in the IP header, or 0.0.0.0 .

Defined In
RFCs 1112 and 2236.

Notes
Membership Queries and reports are not always sent to the multicast group address to which they pertain. Sometimes they are sent to a different address. Therefore, the contents of this field will vary, depending upon the type of message being sent.

IGMPv1 and IGMPv2 general queries are sent to the all-hosts group address of 224.0.0.1, and the Multicast Group field is set to 0.0.0.0, indicating that the query is for all groups. Group-specific queries (which are normally sent in response to a Leave Report) are also sent to the all-hosts address,
although the Multicast Group field will be set to the IP address of the specific multicast group being queried.
Membership Reports sent by hosts on the network are sent to the IP address of the multicast group they are joining or reporting, and the Multicast Group field is set to the same multicast group address. This provides an additional validation service to the multicast routers and hosts on the network; if the destination address and the Multicast Group fields do not match, the datagram can be discarded as simply being erroneous.
Finally, IGMPv2 Leave Reports are sent to the all-routers group address of 224.0.0.2, while the Multicast Group field shows the IP address of the multicast group that is being left. This provides a mechanism for the Leave Report to specify which group is being abandoned (which will likely result in a group-specific query being generated).

Capture Sample
In the capture shown in Figure 4-11, the Multicast Group field being is shown as 0.0.0.0 , which is the all-groups multicast address used with IGMP Membership Queries.

0158-01.gif
Figure 4-11.
The Multicast Group field

See Also
Membership reports

Message Type
Checksum

IGMP Message Types

There are only four IGMP messages defined in RFC 2236, two of which were previously defined for IGMPv1. The message types are listed in Table 4-5.

Table 4 5. IGMP Message Types and Their Meanings
Message TypeDescription
Membership QueryUsed by IGMPv1 and IGMPv2 multicast routers to locate the multicast groups in use by hosts on the local network.
v1 Membership ReportIdentifies this message as an IGMPv1 Membership Report.
v2 Membership ReportIdentifies this message as an IGMPv2 Membership Report
v2 Leave ReportUsed by IGMPv2 hosts to announce that they are leaving a multicast group.

For detailed information about each of these message types, refer to the sections that follow.

Membership Query

Membership Query messages are sent by multicast routers whenever they want to verify that hosts are listening for remotely generated multicast traffic that is being forwarded to this network.

IGMP Message Type
The Message Type for Membership Query messages is 1.

Defined In
RFCs 1112 and 2236.

Status
Standard, Recommended.

Generated By
IGMPv1 or IGMPv2 multicast routers.

Notes
Both IGMPv1 and IGMPv2 multicast routers will issue Membership Query messages. The two messages are generally indistinguishable from each other, except that IGMPv2 queries will have data in the Maximum Response Time field.

Membership Queries can be for all groups or for specific groups. If the query is for all groups, then the Multicast Group field will contain 0.0.0.0. If the query is for a specific group, then the Multicast Group field will contain the IP address of the multicast group in question.
Whenever hosts see a Membership Query message, they must respond with a list of the multicast groups that they are actively monitoring, and they must do
so within the time-frame provided in the Maximum Response Time field. However, not all hosts will respond to these queries; if another host responds for a multicast group that this host is also participating in, then this host can abort the response for that group. Multicast routers only need one response in order to continue forwarding multicast traffic for any given group.

Capture Sample
The packet capture shown in Figure 4-12 shows a message type of 1, which indicates that this is a Membership Query. By looking at the Maximum Response Time field, we can tell that this is an IGMPv2 query, since IGMPv1 messages did not use this field.

0160-01.gif
Figure 4-12.
An IGMP Membership Query message

See Also
Managing Group Memberships

IGM Message Headers
IGMPv1 Membership Report
IGMPv2 Membership Report
Leave Report

IGMPv1 Membership Report

IGMPv1 Membership Reports are generated by hosts whenever they start monitoring a multicast address, or whenever they see a Membership Query. IGMPv1 Membership Reports can be generated by IGMPv1 and IGMPv2 hosts.

IGMP Message Type
The IGMP Message Type for IGMPv1 Membership Reports is 2.

Defined In
RFCs 1112 and 2236.

Status
Standard, Recommended.

Generated By
IGMPv1 or IGMPv2 hosts, and multicast routers who are also participating in multicast groups.

Notes
IGMPv1 Membership Reports are generated by IGMPv1 hosts when they first join a multicast group, and are sent in response to IGMPv1 Membership Queries by IGMPv1 and IGMPv2 hosts.

When an IGMPv1 host first joins a multicast group (such as when a multicast application is started on the host), it issues a couple of IGMPv1 Membership Reports, allowing for the possibility that the first one was lost or corrupted. After that, IGMPv1 Membership Reports are not sent unless a multicast router has issued an IGMPv1 Membership Query.
Typically, an IGMPv2 host will respond only to a Membership Query with an IGMPv2 Membership Report when it can tell for certain that an IGMPv2 multicast router is on the network. This is determined by examining the Maximum Response Time field in a Membership Query. If the field is not blank, then the sender is probably an IGMPv2 multicast router.
Not all hosts will respond to Membership Queries. If another host responds for a multicast group that this host is also participating in, then this host can abort the response for that group. Multicast routers only need one response in order to continue forwarding multicast traffic for any given group, so multiple responses only waste network bandwidth.
In some situations, the multicast router will also be a listening host. In those cases, the router will respond as a host to queries that it sees from other multicast routers. Multicast routers never respond to their own queries.

See Also
Managing Group Memberships

IGM Message Headers
Membership Query
IGMPv2 Membership Report

IGMPv2 Membership Report

IGMPv2 Membership Reports are generated by hosts whenever they start monitoring a multicast address, or whenever they see a Membership Query. IGMPv2 Membership Reports are generated only by IGMPv2 hosts.

IGMP Message Type
The IGMP Message Type for IGMPv2 Membership Reports is 6.

Defined In
RFC 2236.

Status
Proposed Standard, Elective.

Generated By
IGMPv2 hosts, and multicast routers who are also participating in multicast groups.

Notes
IGMPv2 Membership Reports are generated by IGMPv2 hosts when they first join a multicast group, and are sent in response to IGMPv2 Membership Queries.

When an IGMPv2 host first joins a multicast group (such as when a multicast application is started on the host), it issues a couple of IGMPv2 Membership Reports, allowing for the possibility that the first one was lost or corrupted. After that, IGMPv2 Membership Reports are not sent unless a multicast router has issued an IGMPv2 Membership Query.
Typically, an IGMPv2 host will only respond to a Membership Query with an IGMPv2 Membership Report when it can tell for certain that an IGMPv2 multicast router is on the network. This is determined by examining the Maximum Response Time field in a Membership Query. If the field is not blank, then the sender is probably an IGMPv2 multicast router.
Not all hosts will respond to Membership Queries. If another host responds for a multicast group that this host is also participating in, then this host can abort the response for that group. Multicast routers only need one response in order to continue forwarding multicast traffic for any given group, so multiple responses only waste network bandwidth.
In some situations, the multicast router will also be a listening host. In those cases, the router will respond as a host to queries that it sees from other multicast routers. Multicast routers never respond to their own queries.

Capture Sample
The packet capture shown in Figure 4-13 shows a message type of 6, which indicates that this is an IGMPv2 Membership Report. The Destination Address

field of the IP header shows that this message is for 224.0.1.1, which is the well-known multicast address associated with the Network Time Protocol.
0163-01.gif
Figure 4-13.
An IGMPv2-specific Membership Report message

See Also
Managing Group Memberships

IGM Message Headers
Membership Query
IGMPv1 Membership Report

Leave Report

Leave Report messages are generated by IGMPv2 hosts when they stop monitoring a multicast group address for data, and need to inform other devices on the network that they are no longer interested in receiving IP datagrams destined for that multicast group.

IGMP Message Type
The IGMP Message Type for Leave Reports is 7.

Defined In
RFC 2236.

Status
Proposed Standard, Elective.

Generated By
IGMPv2 hosts, and sometimes multicast routers.

Notes
Leave Reports are generated by IGMPv2 hosts when they stop monitoring a multicast group address for data, and need to inform other devices of the fact that this host is no longer interested in receiving IP datagrams destined for the specified multicast group address.

RFC 1112 (which defined IGMPv1) was written primarily for the use and benefit of hosts attached to Ethernet networks, which offered explicit support for multicast addresses at the data-link layer. In this model, hosts could choose to monitor IP multicast addresses—and also could choose to stop monitoring those groups—simply by informing the local network adapter of the Ethernet multicast address associated with the desired IP multicast group.
However, not all networks support this model. In particular, a PPP network that connects a remote user to a network over a dial-up connection offers no support for this type of model whatsoever. If a remote user wanted to monitor a multicast group, they had to send an IGMP Join Report message to the local network, which the dial-up server would have to intercept. At that point, the dial-up server could choose to redirect any multicast traffic for that group address to the remote user. This system has proven to be workable.
Unfortunately, prior to RFC 2236, there has been no way for the downstream device to inform the dial-up server that it wanted to stop getting traffic for that group address. Once a remote host subscribed to a group, there was no way for that host to unsubscribe. IGMPv2 fixed this problem by providing the Leave Report message, which provides just that functionality.
There are other situations where the Leave Report is desirable. For example, it helps to eliminate unnecessary traffic on networks that only have a few multicast listeners, by allowing those hosts to explicitly inform a local IGMP router whenever they are done monitoring a specific group. Although the IGMP router probably would have discovered this information during the next Membership Query cycle, the use of the Leave Report allows for immediate termination (although the router still has to verify the fact that no other hosts are listening for traffic to the specified group address).
Furthermore, in some situations, a multicast router will in fact be the listening host (such a device may be listening for group messages that are specific to a certain routing protocol that is in use by the router). In those cases, the router should also issue Leave Reports when it unsubscribes from those multicast groups.

Capture Sample
The packet capture shown in Figure 4-14 shows a message type of 7, which indicates that this is an IGMPv2 Leave Report. Although the Destination Address in the IP header does not tell us which group this message is for

(since it is going to the all-routers group address), we can tell from the Group Address field of the IGMP Message that this message is for the Network Time Protocol (224.0.1.1).
0165-01.gif
Figure 4-14.
An IGMPv2 Leave Report message

See Also
Managing Group Memberships

IGM Message Headers
IGMPv2 Membership Report

Multicasting and IGMP in Action

As far as IP is concerned, multicast datagrams are virtually indistinguishable from other forms of IP traffic. The only way to tell a multicast IP datagram apart from a unicast or broadcast IP datagram is the fact that the destination IP address of the IP datagram that is carrying the multicast data has a Class D address in the range of 224.0.0.0 through 239.255.255.255.

Simple Multicast Traffic.

Figure 4-15 shows a simple UDP datagram sent to the multicast address 233.1.1.1. There isn't anything else about this datagram that would indicate that it contains multicast data.

The application used to generate the packet shown in Figure 4-15 is a sample application called party.exe, available from Microsoft's public FTP server. Many such applications exist for a wide variety of platforms.

0166-01.gif
Figure 4-15.
A simple UDP datagram sent to a multicast address

Membership and Leave Reports

As was described in IGMP Message Types earlier in this chapter, the acts of joining and leaving multicast groups are pretty straightforward: hosts issue multiple join requests when they first start, and later issue a single leave request when they end. A good example of this process can be seen with Microsoft's Windows Internet Name Service (WINS) server, shipped with Windows NT Server 4.0. WINS is a NetBIOS-to-TCP/IP resolution service, capable of automatically locating other WINS servers using IP multicasts. Once these other servers are located, they can replicate name resolution information with each other. Figure 4-16 shows a WINS server being started and then being shut down.

Notice that the WINS server issues two Membership Reports back-to-back. This behavior is specified in RFC 2236, which states that hosts should issue at least two announcements whenever they are started, allowing for the possibility that the first

0167-01.gif
Figure 4-16.
A Microsoft WINS server registering and then leaving a multicast group

announcement was lost or corrupted somehow. In the example shown in Figure 4-16, the Windows NT server sends the multicast Membership Report to a WINS-specific multicast address of 224.0.1.24, which is also the proper behavior according to RFC 2236.

After a while, the WINS server is terminated, so the Windows NT host issues an IGMPv2 Leave Report, starting that the host is no longer interested in that particular multicast traffic. Note that the Leave Report is sent to the all-routers multicast address of 224.0.0.2, and is not sent to the WINS-specific multicast address of 224.0.1.24 (only routers are interested in Leave Reports, so that's where they are sent). However, the Group ID of the Leave Report is still set to the 224.0.1.24 multicast group, identifying the group that the application is no longer interested in.

Unfortunately, not all multicast-aware applications follow all of these rules. For a detailed discussion of this problem, refer to Troubleshooting Multicasts and IGMP later in this chapter.

Membership Queries and Reports

If a network does not have a multicast router, then the multicast-enabled hosts on that network can only participate with other multicast-enabled hosts that are also on that network. In that kind of environment, users will never see a Membership Query, since those messages are only issued by multicast routers when they need to find out which hosts are actively listening for specific multicast group addresses.

However, if the hosts on the network wish to exchange multicast data with hosts on other networks (either internal to the organization or in far-away places), then multicast routers are required. In that scenario, there will be several Membership Queries issued by the router.

As described in Managing Group Memberships earlier in this chapter, at least one host will respond to each of these queries with a Membership Report. The type of report that is issued will depend on whether or not the hosts and routers are running IGMPv1 or IGMPv2. Most systems today are running IGMPv2.

The process of sending Membership Queries and Membership Reports is shown in Figure 4-17.

Notice that the first packet contains an IGMPv2 Membership Query, which is sent to the all-hosts address of 224.0.0.1. Every multicast-enabled host is required to monitor that group address, allowing them to see these queries. The last packet shown in Figure 4-17 contains an IGMPv2 membership response for the multicast group address of 224.0.1.1, which is the address associated with the Simple Network Time Protocol (SNTP).

Troubleshooting Multicasts and IGMP

Since IGMP is a very small and lightweight protocol, there aren't many things that can go wrong with it. The only real errors that are likely to occur are problems with programs that implement the specification poorly. For example, the party.exe application that is provided by Microsoft does not use the appropriate system calls for generating multicast traffic. As such, it does not cause a Membership Report to be sent when the program is started, and does not cause a Leave Report to be issued when it is stopped.

Another implementation problem can be seen with the SNTP client provided with RedHat Linux 5.2. Although this same client code executes properly on Solaris and Digital Unix systems, RedHat Linux 5.2 had some bugs in the multicasting code

0169-01.gif
Figure 4-17.
A simple exchange of Membership Query and Membership Report messages

that caused some malformed IGMP messages to be sent. Figure 4-18 shows this in detail.

The first mistake that is made is that the SNTP client does not issue multiple Membership Reports when it is started. Instead, only one Membership Report is issued, although RFC 2236 specifically states that applications should issue at least two separate Membership Reports whenever they join a multicast group.

The second mistake—and one that is much more problematic—is that the Leave Report issued by this implementation is completely malformed. Although the client does send the Leave Report to the all-routers multicast group (224.0.0.2), it also specifies that the group it wants to leave is 224.0.0.2, which is not correct. It should be advertising that it wants to leave the 224.0.1.1 group (the well-known

0170-01.gif
Figure 4-18.
A malformed IGMP Leave Report

multicast address for SNTP, the same group that it joined in the previous message). As it stands, this client is offering to leave the all-routers group of 224.0.0.2, rather than the NTP group.

This is the wrong behavior and will likely result in some problems eventually. For example, any multicast routers that are on the network (such as Sasquatch) will never find out that Greywolf wants to leave the NTP multicast group, and as such will continue forwarding NTP data to this network segment. Although that's okay here (we have many NTP clients), if Greywolf were on a remote network accessible via a dial-on-demand connection, we would likely see the link being brought up every so often just for the NTP traffic.

In addition, multicast datagrams are basically indistinguishable from IP datagrams, so one way to test for basic multicasting functionality is to use a program like ping to determine which hosts are currently listening for a specific group address.

For example, Figure 4-19 shows a single ICMP Echo Request Query Message being sent from Krill to the all-hosts multicast group address of 224.0.0.1. In response, Krill receives three different ICMP Echo Response Query Messages back, with the IP addresses of the responding systems shown in the ping output. Also notice that Krill's implementation of ping thinks that two of the responses are duplicates (which they are), although they were returned from different hosts.

Note that many TCP/IP stacks will not respond to ICMP Echo Request messages that are sent to multicast addresses, and that this method is not a sure-fire indicator of the active listeners on a network. For example, there are more than three multicast-aware hosts active on the local network, although Krill only got answers back from three hosts (one of which was itself) in the test shown in Figure 4-19.

0171-01.gif
Figure 4-19.
The output from a ping test to the multicast all-hosts address of 224.0.0.1

For a detailed discussion on ways to use ping, refer to Notes on ping in Chapter 5.

General problems with multicasting will also result from configuration problems with your multicast-enabled routers. Multicasting and IGMP both rely on the presence of a multicast router in order for the multicast datagrams to be forwarded across network boundaries. Although many IP routers offer multicast support, most of them do not have these protocols enabled by default. You may need to enable a multicast-specific routing protocol such as DVMRP (the Distance-Vector Multicast Routing Protocol), or you may need to acquire a new router if the one you currently have does not support either multicast routing or the version of IGMP in use by your hosts.

Also, if you are trying to interact with multicasting traffic from the Internet, then you will need to configure your firewalls to allow that type of traffic through. This is not a widely-supported option at the present time, and the only viable solution may involve the creation of multicast tunnels (using a multicast routing protocol), or the creation of a secure, encrypted virtual private network link. In both cases, you will need to find an external organization that can provide you with those services (although the chances are good that the external organizations are also suffering under security issues with multicast traffic). For more information on this subject, refer to RFC 2588, which covers the issues around IP multicasting and firewalls in great detail.




Internet Core Protocols. The Definitive Guide with Cdrom
Internet Core Protocols: The Definitive Guide: Help for Network Administrators
ISBN: 1565925726
EAN: 2147483647
Year: 1999
Pages: 17
Authors: Eric Hall

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net