IGMP

Introduction

Internet Group Management Protocol (IGMP) allows hosts on multiaccess networks to inform locally attached routers of their group membership information. Hosts share their group membership information by multicasting IGMP host membership reports. Multicast routers listen for these host membership reports, and then exchange this information with other multicast routers.

The group membership reporting protocol includes two types of messages: host membership query and host membership report. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. Protocol operation requires that a designated querier router be elected on each subnet and that it periodically multicast a host membership query to the all-hosts group.

Hosts respond to a query by generating host membership reports for each multicast group to which they belong. These reports are sent to the group being reported, which allows other active members on the subnet to cancel their reports. This behavior limits the number of reports generated to one for each active group on the subnet. This exchange allows the multicast routers to maintain a database of all active host groups on each of their attached subnets. A group is declared inactive (expired) when no report is received for several query intervals.

The IGMPv2 protocol adds a leave group message and uses an unused field in the IGMPv1 host membership query message to specify a maximal response time. The leave group message allows a host to report when its membership in a multicast group terminates. Then, the IGMP querier router can send a group-directed query with a very small maximal response time to probe for any remaining active group members. This accelerated leave extension can reduce the time required to expire a group and prune the multicast distribution tree from minutes, down to several seconds

The unicast traceroute program allows the tracing of a path from one device to another, using mechanisms that already exist in IP. Unfortunately, you cannot apply such mechanisms to IP multicast packets. The key mechanism for unicast traceroute is the ICMP TTL exceeded message that is specifically precluded as a response to multicast packets. The traceroute facility implemented within routed conforms to the traceroute facility for IP multicast draft specification.

GaiaClosed Check Point security operating system that combines the strengths of both SecurePlatform and IPSO operating systems. supports IGMPv1, IGMPv2 (runs by default), and IGMPv3.

IGMPv3

Gaia provides IGMP version 3 source filtering to support source-specific multicast (SSM), which enables the Gaia system to request traffic from specific sources via PIM join/prune messages without requiring the presence of a rendezvous point (RP). This enables the Gaia system to forward traffic from only those sources from which receivers requested traffic. IGMPv3 supports applications that explicitly signal sources, from which they want to receive traffic.

With IGMP version 3, receivers (hosts) identify their membership to a multicast group in the following two modes:

  • Include mode: Receivers announce membership to a group and provide a list of IP addresses (the include list) from which they want to receive traffic.

  • Exclude mode: Receivers announce membership to a host group and provide a list of IP addresses (the exclude list) from which they do not want to receive traffic. To receive traffic from all sources, a host sends an empty exclude list.

The multicast group address range 232/8 (232.0.0.0 to 232.255.255.255) is reserved for use by SSM protocols and applications. The DRs of senders do not send register packets to any RPs in the SSM group range.

When SSM is enabled, all other multicast groups are treated as in normal sparse-mode.

Configuring Local and Static IGMP Groups

You can facilitate multicast routing by creating IGMP local and static groups. You create these groups on a per-interface basis, and for each group you specify an address for a multicast group. Gaia then acts as a receiver for that multicast group and builds a routing tree to the source regardless of whether there are any hosts on the downstream LAN that want to receive traffic for that group. When hosts later join the multicast group, they start receiving traffic sooner because the routing tree is already built.

This feature is useful in any situation in which multicast receivers might not be permanently attached to the downstream LAN. For example, if you have laptop users who regularly detach from the LAN and reattach when they return to work and who also want to receive multicast traffic from a known source when their laptop is connected to the LAN, you can create a local or static group using the multicast address of the known source. Gaia then maintains the reverse path forwarding tree without waiting for requests from the laptops.

The differences between local and static groups are:

  • When you create a local group:

    • IGMP sends a membership report out of the appropriate interface.

    • If the system is running a parent multicast routing protocol, IGMP informs the parent protocol about the simulated local receiver.

  • When you create a static group:

    • IGMP does not send a membership report for the group. You might want to use static groups if you do not want other devices to receive IGMP membership reports from your Gaia system.

    • If the system is running a parent multicast routing protocol, IGMP informs the parent protocol about the simulated local receiver.