So far we have discussed how multicast datagrams are transmitted, filtered, and received from a host’s perspective. When multicast datagrams are to be for- warded over a wide area network or within an enterprise across multiple sub- nets, we require that multicast routing be enabled by one or more multicast routers.
This complicates the situation considerably, because multicast routers require
ptg999 knowledge about which hosts are interested in what multicast groups, in order
to arrange for multicast traffic to be delivered appropriately. They also execute a special procedure called the Reverse Path Forwarding (RPF) check. This procedure performs a routing lookup on the source address of an arriving multicast data- gram. Only if the outgoing interface for routing matches the interface on which the datagram arrived is the datagram forwarded. The RPF check is important for avoiding multicast loops. Multicast routing is largely separate from conventional unicast routing provided by IP routers. However, some capabilities of multicast routing are required for the IPv6 ND protocol (see Chapter 8) to operate properly.
Two major protocols are used to allow multicast routers to learn the groups in which nearby hosts are interested: the Internet Group Management Protocol (IGMP) used by IPv4 and the Multicast Listener Discovery (MLD) protocol used by IPv6. Both are used by hosts and routers that support multicasting, and the protocols are very similar. These protocols let the multicast routers on a LAN (VLAN) know which hosts currently belong to which multicast groups. This information is required by the routers so that they know which multicast datagrams to forward on to which interfaces. In most cases, a multicast router only requires knowledge that at least one listening host is reachable by a particular interface, as link-layer multicast address- ing (assuming it is supported) permits the multicast router to send link-layer multi- cast frames that will be received by all interested listeners. This allows a multicast router to do its job without keeping track of every individual host on each interface that might be interested in multicast traffic for a particular group.
IGMP has evolved over time, and [RFC3376] defines version 3 (the most cur- rent one at the time of writing). MLD has evolved in parallel, and its current version (2) is defined in [RFC3810]. IGMPv3 and/or MLDv2 are required for sup- porting SSM. See [RFC4604] for more details on how these protocols are restricted when using only a single source per multicast group.
Version 1 of IGMP was the first commonly used version of IGMP. Version 2 added the ability to leave groups more quickly (also supported by MLDv1).
IGMPv3 and MLDv2 add the ability to select the sources of multicast traffic and are required for deployment of SSM. While IGMP is a separate protocol used with IPv4, MLD is really part of ICMPv6 (see Chapter 8).
Figure 9-6 indicates how IGMP (MLD) is used by an IPv4 (IPv6) multicast- enabled router. Such routers are interested in ascertaining which multicast groups are of interest on each of its attached interfaces. These routers require this infor- mation in order to avoid simply broadcasting all traffic out of every interface.
In Figure 9-6, we can see how IGMP (MLD) queries are sent by multicast rout- ers. These are sent to the All Hosts multicast address, 224.0.0.1 (IGMP), or the All Nodes link-scope multicast address, ff02::1 (MLD), and processed by every host implementing IP multicast (see the exception in Section 9.4.2 for “specific” que- ries). Membership report messages are sent by group members (hosts) in response to the queries but may also be sent in an unsolicited way from hosts that wish to inform multicast routers that their group membership(s) and/or interest in particular sources has changed. IGMPv3 reports are sent to the IGMPv3-capable
ptg999 Section 9.4 Internet Group Management Protocol and Multicast Listener Discovery Protocol 453
multicast router address 224.0.0.22. MLDv2 reports are sent to the correspond- ing MLDv2 Listeners IPv6 multicast address ff02::16. Note that multicast routers themselves may also act as members when they join multicast groups.
Note
In IGMPv1 and IGMPv2, after receiving a query, hosts do not respond immedi- ately but instead may wait a small random amount of time to see if any other host responds for the same group. If so, a host’s response is suppressed (not sent).
This is accomplished by having reports sent to the multicast address of the group in question. Appendix A of [RFC3376] indicates why this operation was removed in IGMPv3. In short, multicast routers may wish to track individual hosts’ subscrip- tions, suppression does not work well in bridged LANs using IGMP snooping (see Section 9.4.7), handling suppression complicates the protocol implementation, and IGMPv3 reports contain information on multiple groups, making successful suppression less likely. Note that both IGMPv3 and MLDv2 require backward compatibility with earlier versions of themselves and revert to using older-version protocol messages of older hosts or routers detected on the same subnet.
The encapsulations for IGMP and MLD are shown in Figure 9-7. Like ICMP, IGMP is considered part of the IP layer. Also like ICMP, IGMP messages are trans- mitted in IPv4 datagrams. Unlike other protocols that we have seen, IGMP uses a fixed TTL of 1, so packets are limited to the local subnetwork. IGMP packets also use the IPv4 Router Alert option and use the 6-bit value 0x30 in the DS Field
6ZLWFK$
6ZLWFK%
0XOWLFDVW 5RXWHU
:LGH$UHD1HWZRUN HJ,QWHUQHW
,*030/'4XHU\
,*030/'5HSRUW
Figure 9-6 Multicast routers send IGMP (MLD) requests to each attached subnet periodically to determine which groups and sources are of interest to the attached hosts. Hosts respond with reports indicating which groups and sources are of interest. Hosts may also send unsolicited reports if membership changes occur.
ptg999
,3Y+HDGHU ,*03
+HDGHU ,*03'DWD*URXS5HFRUGVRU6RXUFH/LVW
,3Y'DWDJUDP E\WHV
,3Y5RXWHU$OHUW2SWLRQ E\WHV5HSRUWV E\WHV4XHULHV
'HVWLQDWLRQ$OO+RVWV²*HQHUDO4XHULHV*URXS$GGUHVV6SHFLILF4XHULHV,*03YRU
$OO,*03YURXWHUV²5HSRUWV
77/ 3URWR '6)LHOG [
,3Y+HDGHU
,3Y'DWDJUDP
E\WHV YDULDEOH
+RS/LPLW 1H[W+HDGHU /LQN/RFDO6RXUFH$GGUHVVRU
,&03Y +HDGHU 1+
E\WHV
0/''DWD 6RXUFH/LVW
'HVWLQDWLRQII$OO+RVWV²*HQHUDOTXHULHV*URXS$GGUHVV6SHFLILF4XHULHVRUII$OO5RXWHUV²5HSRUWV 7\SH4XHU\Y5HSRUW +%+
2SWV
7/
9DO 1+
,*03
0/' 7\SH4XHU\Y5HSRUWY5HSRUWY5HSRUWYOHDYH
5RXWHU$OHUW2SWLRQ
3DG
Figure 9-7 IGMP is encapsulated as a separate protocol in IPv4. MLD is a type of ICMPv6 message.
to represent Internetwork Control (CS6, see Chapter 5). In IPv6, MLD is part of ICMPv6, but the functionality of MLD is nearly identical to that of IGMP, so we describe it here (we described its message formats briefly when describing ICMPv6 in Chapter 8). Its encapsulation makes use of an IPv6 Hop-by-Hop extension header to hold the Router Alert option. In many cases, the list of sources is empty.
IGMP and MLD define two sets of protocol processing rules: those performed by hosts that are group members and those performed by multicast routers. Gen- erally speaking, the job of the member hosts (which we will call “group members”) is to spontaneously report changes in interest in multicast groups and sources and to respond to periodic queries. Multicast routers send queries to ascertain whether any interest is present on an attached link for any groups, or for a specific multicast group and source. Routers also interact with wide area multicast proto- cols (such as PIM-SM and BIDIR-PIM) to bring the desired traffic to the interested hosts or prohibit traffic from flowing to uninterested hosts. For more details on these protocols, please see [RFC4601] and [RFC5015].
9.4.1 IGMP and MLD Processing by Group Members (“Group Member Part”) The group members’ portion of IGMP and MLD is designed to allow hosts to specify what groups they are interested in and whether traffic sent from particu- lar sources should be accepted or filtered out. This is accomplished by sending reports to one or more multicast routers (and participating hosts) attached to the
ptg999 Section 9.4 Internet Group Management Protocol and Multicast Listener Discovery Protocol 455
same subnet. Reports may be sent as a result of receiving a query, or spontane- ously (unsolicited) because of a local change in reception state (e.g., an application joins or leaves a group). IGMP reports take the form shown in Figure 9-8.
7\SH[
ELWV &KHFNVXPELWV
%DVLF ,*03 5HSRUW +HDGHU E\WHV 5HVHUYHG
ELWV
1XPEHURI*URXS5HFRUGV1 ELWV
*URXS5HFRUG>@
*URXS5HFRUG>@
*URXS5HFRUG>1@
5HVHUYHGELWV
Figure 9-8 The IGMPv3 membership report contains group records for N groups. Each group record indicates a multicast address and optional list of sources.
Report messages are fairly simple. They contain a vector of group records, each of which provides information about a particular multicast group, including the address of the subject group, and an optional list of sources used for establishing filters (see Figure 9-9).
Each group record contains a type, the address of the subject group, and a list of source addresses to either include or exclude. There is also support for includ- ing auxiliary data, but this feature is not used by IGMPv3. Table 9-1 reveals the sig- nificant flexibility that can be achieved using IGMPv3 report record types. MLD uses the same values. A list of sources is said to refer to include mode or exclude mode. In include mode, the sources in the list are the only sources from which traffic should be accepted. In exclude mode, the sources in the list are the ones to be filtered out (all others are allowed). Leaving a group can be expressed as using an include mode filter with no sources, and a simple join of a group (i.e., for any source) can be expressed as using the exclude mode filter with no sources. Note that when using SSM, types 0x02 and 0x04 are not used, as only a single source is assumed for any group.
ptg999 5HFRUG7\SH
ELWV
$X['DWD/HQ ELWV
1XPEHURI*URXS6RXUFHV1 ELWV
6RXUFH$GGUHVV>@
6RXUFH$GGUHVV>@
6RXUFH$GGUHVV>1@
,3Y0XOWLFDVW*URXS$GGUHVVELWV
$X[LOLDU\'DWD
Figure 9-9 An IGMPv3 group record includes a multicast address (group) and an optional list of sources. Groups of sources are either allowed as senders (include mode) or filtered out (exclude mode). Previous versions of IGMP reports did not include a list of sources.
T able 9-1 Type values for IGMP and MLD source lists indicate the filtering mode (include or exclude) and whether the source list has changed
Type Name and Meaning When Sent
0x01 MODE_IS_INCLUDE (IS_IN): traffic sent from any of the associated source addresses is not to be filtered.
In response to a query from a multicast router
0x02 MODE_IS_EXCLUDE (IS_EX): traffic sent from any of the associated source addresses should be filtered.
In response to a query from a multicast router
0x03 CHANGE_TO_INCLUDE_MODE (TO_IN): a change from exclude mode; traffic sent from any of the associated source addresses should now not be filtered.
In response to a local action changing the filter mode from exclude to include
0x04 CHANGE_TO_EXCLUDE_MODE (TO_EX): a change from include mode; traffic sent from any of the associated source addresses should now be filtered.
In response to a local action changing the filter mode from include to exclude
0x05 ALLOW_NEW_SOURCES (ALLOW): a change in source list; traffic sent from any of the associated source addresses should now not be filtered.
In response to a local action changing the source list to allow new sources
0x06 BLOCK_OLD_SOURCES (BLOCK): a change in source list; traffic sent from any of the associated source addresses should now be filtered.
In response to a local action changing the source list to disallow previously allowed sources
ptg999 Section 9.4 Internet Group Management Protocol and Multicast Listener Discovery Protocol 457
The first two message types (0x01, 0x02) are known as current-state records and are used to report the current filter state in response to a query. The next two (0x03, 0x04) are known as filter-mode-change records, which indicate a change from include to exclude mode or vice versa. The last two (0x05, 0x06) are known as source-list-change records and indicate a change to the sources being handled in either exclude or include mode. The last four types are also described more gener- ally as state-change records or state-change reports. These are sent as a result of some local state change such as a new application being started or stopped, or a running application changing its group/source interests. Note that IGMP and MLD que- ries/reports themselves are never filtered. MLD reports use a structure similar to IGMP reports but accommodate larger addresses and use an ICMPv6 type code of 143 (see Chapter 8).
When receiving a query, group members do not respond immediately. Instead, they set a random (bounded) timer to determine when to respond. During this delay interval, processes may alter their group/source interests. Any such modi- fications can be processed together before a timer expires to trigger the report. In this way, once the timer does expire, the status of multiple groups can more likely be merged into a single report, saving overhead.
The source address used for IGMP is the primary or preferred IPv4 address of the sending interface. For MLD, the source address is a link-local IPv6 address.
One complication arises when a host is booting and attempting to determine its own IPv6 address. During this time, it selects a potential IPv6 address to use and executes the duplicate address detection (DAD) procedure (see Chapter 6) to deter- mine if any other systems are already using this address. Because DAD involves multicast, some source address must be assigned to outgoing MLD messages. This is addressed by [RFC3590], which allows the unspecified address (::) to be used as the source IPv6 address for MLD traffic during configuration.
9.4.2 IGMP and MLD Processing by Multicast Routers (“Multicast Router Part”) In IGMP and MLD, the job of the multicast router is to determine, for each multi- cast group, interface, and source list, whether at least one group member is pres- ent to receive corresponding traffic. This is accomplished by sending queries and building state describing the existence of such members based on the reports they send. This state is soft state, meaning that it is cleared after a certain amount of time if not refreshed. To build this state, multicast routers send IGMPv3 queries of the form depicted in Figure 9-10.
The IGMP query message is very similar to the ICMPv6 MLD query we dis- cussed in Chapter 8. In this case, the group (multicast) address is 32 bits in length and the Max Resp Code field is 8 bits instead of 16. The Max Resp Code field encodes the maximum amount of time the receiver of the query should delay before send- ing a report, encoded in 100ms units for values below 128. For values above 127, the field is encoded as shown in Figure 9-11.
ptg999
This encoding provides for a possible range of (16)(8) = 128 to (31)(1024) = 31,744 (i.e., about 13s to 53 minutes). Using smaller values for the Max Resp Code field allows for tuning the leave latency (the elapsed time from when the last group member leaves to the time corresponding traffic ceases to be forwarded). Larger values of this field reduce the traffic load of the IGMP messages generated by members by increasing the likelihood of longer periods for reporting.
The remaining fields in a query include an Internet-style checksum across the whole message, the address of the subject group, a list of sources, and the S, QRV,
7\SH[
ELWV &KHFNVXPELWV
%DVLF ,*03 4XHU\
+HDGHU E\WHV 0D[5HVS&RGH
ELWV
1XPEHURI6RXUFHV1 ELWV ,3Y0XOWLFDVW*URXS$GGUHVVELWV 5HVY
ELWV
459
ELWV 44,&ELWV
6RXUFH$GGUHVV>@
6RXUFH$GGUHVV>@
6RXUFH$GGUHVV>@
6RXUFH$GGUHVV>1@
6
Figure 9-10 The IGMPv3 query includes the multicast group address and optional list of sources.
General queries use a group address of 0 and are sent to the All Hosts multicast address, 224.0.0.1. The QRV value encodes the maximum number of retransmissions the sender will use, and the QQIC field encodes the periodic query interval. Specific queries are used before terminating traffic flow for a group or source/group combination. In this case (and all cases with IGMPv2 or IGMPv1), the query is sent to the address of the subject group.
([SRQHQW ELWV
0DQWLVVDELWV
0D[5HVS7LPH PDQWLVVDH[SRQHQW
Figure 9-11 The Max Resp Code field encodes the maximum time to delay responses in 100ms units.
For values above 127, an exponential value can be used to accommodate larger values.
ptg999 Section 9.4 Internet Group Management Protocol and Multicast Listener Discovery Protocol 459
and QQIC fields we defined in Chapter 8 with MLD. In cases where the multicast router wishes to know about interest in all multicast groups, the Group Address field is set to 0 (such queries are called “general queries”). The S and QRV fields are used for fault tolerance and retransmission of reports and are discussed in Section 9.4.5. The QQIC field is the Querier’s Query Interval Code. This value is the query sending period, in units of seconds and encoded using the same method as the Max Resp Code field (i.e., a range from 0 to 31,744).
There are three variants of the query message that can be sent by a multicast router: general query, group-specific query, and group-and-source-specific query. The first form is used by the multicast router to update information regarding any multicast group, and for such queries the group list is empty. Group-specific que- ries are similar to general queries but are specific to the identified group. The last type is essentially a group-specific query with a set of sources included. The spe- cific queries are sent to the destination IP address of the subject group, as opposed to general queries that are sent to the All Systems multicast address (for IPv4) or the link-scope All Nodes multicast address for IPv6 (ff02::1).
The specific queries are sent in response to state-change reports in order to verify that it is appropriate for the router to take some action (e.g., to ensure that no interest remains in a particular group before constructing a filter). When receiv- ing either filter-mode-change records or source-list-change records, the multicast router arranges to add new traffic sources and may be able to filter out traffic from certain sources. In cases where the multicast router is prepared to begin filter- ing out traffic that was flowing previously, it uses the group-specific query and group-and-source-specific query first. If these queries elicit no reports, the router is free to begin filtering out the corresponding traffic. Because such changes can significantly affect the flow of multicast traffic, state-change reports and specific queries are retransmitted (see Section 9.4.5).
9.4.3 Examples
Figure 9-12 shows a packet trace containing a combination of IGMPv2, IGMPv3, MLDv1, and MLDv2 protocols, all working on the same subnet. The trace is 16 packets in length (the first 10 are shown in Figure 9-12) and begins with an MLD query from fe80::204:5aff:fe9f:9e80, the link-local IPv6 address of the querier.
Recall that MLD and MLDv2 use the same query format. This same system also acts as an IGMP querier using the IPv4 source address 10.0.0.1.
In Figure 9-12, the MLD query (packet 1) is sent by the querier using its link- local IPv6 address fe80::204:5aff:fe9f:9e80 to the multicast address ff02::1 (All Nodes). The MAC-layer addresses are 00:04:5a:9f:9e:80 and 33:33:00:00:00:01, respectively. Here we can see how an IPv6 link-local unicast address relates to the corresponding MAC address, and also how the All Nodes address is mapped to the MAC address using prefix 33:33, as we discussed earlier. The IPv6 Hop Limit field is set to 1, as MLD messages are applicable only to the local link. The IPv6 Payload Length field indicates 36 bytes, which includes 8 bytes holding the MLD