Skip to main content

2. Host Requirements for Source-Specific Multicast

This section defines the notion of an "SSM-aware" host and then goes on to describe the API requirements and the SFGMP protocol requirements of an SSM-aware host. It is important to note that SSM can be used by any host that supports source filtering APIs and whose operating system supports the appropriate SFGMP. The SFGMP modifications described in this section make SSM work better on an SSM-aware host, but they are not strict prerequisites for the use of SSM.

The 232/8 IPv4 address range is currently allocated for SSM by IANA [IANA-ALLOCATION]. In IPv6, the FF3x::/32 range (where 'x' is a valid IPv6 multicast scope value) is reserved for SSM semantics [RFC3306], although today SSM allocations are restricted to FF3x::/96. ([SSM] has a more thorough discussion of this topic.) A host that knows the SSM address range and is capable of applying SSM semantics to it is described as an "SSM-aware" host.

A host or router may be configured to apply SSM semantics to addresses other than those in the IANA-allocated range. The GMP module on a host or router SHOULD have a configuration option to set the SSM address range(s). If this configuration option exists, it MUST default to the IANA-allocated SSM range. The mechanism for setting this configuration option MUST at least allow for manual configuration. Protocol mechanisms to set this option may be defined in the future.

2.1. API Requirements​

If the host IP module of an SSM-aware host receives a non-source-specific request to receive multicast traffic sent to an SSM destination address, it SHOULD return an error to the application, as specified in [MSFAPI] (MODIFICATION). On a non-SSM-aware host, an application that uses the wrong API (e.g., "join(G)", "IPMulticastListen(G,EXCLUDE(S1))" for IGMPv3, or "IPv6MulticastListen(G,EXCLUDE(S2))" for MLDv2) to request delivery of packets sent to an SSM address will not receive the requested service, because an SSM-aware router (following the rules of this document) will refuse to process the request, and the application will receive no indication other than a failure to receive the requested traffic.

2.2. GMP Requirements​

This section defines the behavior of the SFGMP protocol module on an SSM-aware host, including two modifications to the protocols as described in [IGMPv3, MLDv2]. It also includes a number of clarifications of protocol operations. In doing so, it documents the behavior of an SSM-aware host with respect to sending and receiving the following GMP message types:

  • IGMPv1/v2 and MLDv1 Reports (2.2.1)
  • IGMPv3 and MLDv2 Reports (2.2.2)
  • IGMPv1 Queries, IGMPv2 and MLDv1 General Queries (2.2.3)
  • IGMPv2 Leave and MLDv1 Done (2.2.4)
  • IGMPv2 and MLDv1 Group Specific Query (2.2.5)
  • IGMPv3 and MLDv2 Group Specific Query (2.2.6)
  • IGMPv3 and MLDv2 Group-and-Source Specific Query (2.2.7)

2.2.1. IGMPv1/v2 and MLDv1 Reports​

An SSM-aware host operating according to [IGMPv3, MLDv2] could send an IGMPv1, IGMPv2, or MLDv1 report for an SSM address when it is operating in "older-version compatibility mode." This is an exceptional (error) condition, indicating that the router(s) cannot provide the SFGMP support needed for SSM, and an error is logged when the host enters compatibility mode for an SSM address, as described below. In this situation, it is likely that traffic sent to a channel (S,G) will not be delivered to a receiving host that has requested to receive channel (S,G).

[IGMPv3] and [MLDv2] specify that a host MAY allow an older-version report to suppress its own IGMPv3 or MLDv2 Membership Record. An SSM-aware host, however, MUST NOT allow its report to be suppressed in this situation (MODIFICATION). Suppressing reports in this scenario would provide an avenue for an attacker to deny SSM service to other hosts on the link.

2.2.2. IGMPv3 and MLDv2 Reports​

A host implementation may report more than one SSM channel in a single report either by including multiple sources within a group record or by including multiple group records.

A Group Record for a source-specific destination address may (under normal operation) be any of the following types:

  • MODE_IS_INCLUDE as part of a Current-State Record

  • ALLOW_NEW_SOURCES as part of a State-Change Record

  • BLOCK_OLD_SOURCES as part of a State-Change Record

A report may include both SSM destination addresses and non-source-specific, i.e., Any-Source Multicast (ASM) destination addresses, in the same message.

Additionally, a CHANGE_TO_INCLUDE_MODE record may be sent by a host in some cases, for instance, when the SSM address range is changed through configuration. A router should process such a record according to the normal SFGMP rules.

An SSM-aware host SHOULD NOT send any of the following record types for an SSM address.

  • MODE_IS_EXCLUDE as part of a Current-State Record

  • CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record

This is a MODIFICATION to [IGMPv3, MLDv2], imposing a restriction on its use for SSM destination addresses. The rationale is that EXCLUDE mode does not apply to SSM addresses, and an SSM-aware router will ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM range, as described below.

2.2.3. IGMPv1 Queries, IGMPv2 and MLDv1 General Queries​

If an IGMPv1 Query, or an IGMPv2 or MLDv1 General Query is received, the SFGMP protocol specifications require the host to revert to the older (IGMPv1, IGMPv2, or MLDv1) mode of operation on that interface. If this occurs, the host will stop reporting source-specific subscriptions on that interface and will start using IGMPv1, IGMPv2, or MLDv1 to report interest in all SSM destination addresses, unqualified by a source address. As a result, SSM semantics will no longer be applied to the multicast group address by the router.

A router compliant with this document would never generate an IGMPv1, IGMPv2, or MLDv1 query for an address in the SSM range; thus, this situation only occurs either if the router is not SSM-aware, or if the host and the router disagree about the SSM address range (for instance, if they have inconsistent manual configurations).

A host SHOULD log an error if it receives an IGMPv1, IGMPv2, or MLDv1 query for an SSM address (MODIFICATION).

In order to mitigate this problem, it must be administratively assured that all routers on a given shared-medium network are compliant with this document and are in agreement about the SSM address range.

2.2.4. IGMPv2 Leave and MLDv1 Done​

IGMP Leave and MLD Done messages are not processed by hosts. IGMPv2 Leave and MLDv1 Done messages should not be sent for an SSM address, unless the sending host has reverted to older-version compatibility mode, with all the caveats described above.

2.2.5. IGMPv2 and MLDv1 Group Specific Query​

If a host receives an IGMPv2 or MLDv1 Group Specific Query for an address in any configured source-specific range, it should process the query normally, as per [IGMPv3, MLDv2], even if the group queried is a source-specific destination address. The transmission of such a query likely indicates either that the sending router is not compliant with this document or that it is not configured with the same SSM address range(s) as the receiving host. A host SHOULD log an error in this case (MODIFICATION).

2.2.6. IGMPv3 and MLDv2 Group-Specific Query​

If an SSM-aware host receives an SFGMP Group-Specific Query for an SSM address, it must respond with a report if the group matches the source-specific destination address of any of its subscribed source-specific channels, as specified in [IGMPv3, MLDv2].

The rationale for this is that, although in the current SFGMP protocol specifications a router would have no reason to send one, the semantics of such a query are well-defined in this range and future implementations may have reason to send such a query. Be liberal in what you accept.

2.2.7. IGMPv3 and MLDv2 Group-and-Source-Specific Query​

An SFGMP router typically uses a Group-and-Source-Specific Query to query an SSM channel that a host has requested to leave via a BLOCK_OLD_SOURCES record. A host must respond to a Group-and-Source-Specific Query for which the group and source in the query match any channel for which the host has a subscription, as required by [IGMPv3, MLDv2]. The use of an SSM address does not change this behavior.

A host must be able to process a query with multiple sources listed per group, again as required by [IGMPv3, MLDv2]. The use of an SSM address does not modify the behavior of the SFGMPs in this regard.

Last updated on