[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4604

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               H. Holbrook
Expires Aug 16, 2004                                       Cisco Systems
                                                                 B. Cain
                                                        Storigen Systems
                                                             B. Haberman
                                                        Caspian Networks
                                                            Feb 16, 2004

          Using IGMPv3 and MLDv2 for Source-Specific Multicast

Status of this Memo

This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
document are to be interpreted as described in RFC 2119 [RFC 2119].

Holbrook/Cain/Haberman                                          [Page 1]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004


The Internet Group Management Protocol Version 3 (IGMPv3) and the
Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols
that allow a host to inform its neighboring routers of its desire to
receive IPv4 and IPv6 multicast transmissions, respectively.  Source-
Specific Multicast (SSM) is a form of multicast in which a receiver is
required to specify both the network-layer address of the source and the
multicast destination address in order to receive the multicast
transmission.  This document defines the notion of an "SSM-aware" router
and host, and clarifies and, in some cases, modifies the behavior of
IGMPv3 and MLDv2 on SSM-aware routers and hosts to accomodate source-
specific multicast.

1.  Introduction

The Internet Group Management Protocol (IGMP) [RFC1112,IGMPv2,IGMPv3],
allows an IPv4 host to communicate IP multicast group membership
information to its neighboring routers.  IGMP version 3 (IGMPv3)
[IGMPv3] provides the ability for a host to selectively request or
filter traffic from individual sources within a multicast group.

The Multicast Listener Discovery Protocol (MLD) [RFC2710, MLDv2] offers
similar functionality for IPv6 hosts.  MLD version 2 (MLDv2) provides
the analagous "source filtering" functionality of IGMPv3 for IPv6.

Due to the commonality of function, the term "Group Management Protocol"
or "GMP" will be used to refer to both IGMP and MLD.  The term "Source
Filtering GMP", or "SFGMP" will be used to refer jointly to the IGMPv3
and MLDv2 group management protocols.

The use of source-specific multicast is facilitated by small changes to
the SFGMP protocols on both hosts and routers.  [SSM] defines general
requirements that must be followed by systems that implement the SSM
service model; this document defines the concrete application of those
requirements to systems that implement IGMPv3 and MLDv2.  In doing so,
this document defines modifications to the host and router portions of
IGMPv3 and MLDv2 for use with SSM, and presents a number of
clarifications to their behavior when used with SSM addresses.

In order to emphasize the parts of this document that modify the
existing protocol specifications, as opposed to merely clarifying them,
the modifications are marked with the tag "MODIFICATION".

Holbrook/Cain/Haberman                                          [Page 2]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004

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 a properly configured router 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:

Holbrook/Cain/Haberman                                          [Page 3]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004

     - IGMPv1/v2 and MLDv1 Reports (2.2.1)
     - IGMPv3 and MLDv2 Reports (2.2.2)
     - IGMPv1/v2 and MLDv1 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) can not 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

[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, by including either 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.

Holbrook/Cain/Haberman                                          [Page 4]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004

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/IGMPv2 and MLDv1 Queries

If an IGMPv1, IGMPv2, or MLDv1 query is received, the SFGMP protocol
specifications require the host to revert to the older (IGMPv1, IGMPv2,
or MLDv1) mode of operation for that destination address.  If this
occurs, the host will stop reporting source-specific subscriptions for
that destination address and will start using IGMPv1, IGMPv2, or MLDv1
to report interest in the SSM destination address, 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 if either 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.

Holbrook/Cain/Haberman                                          [Page 5]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004

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 that the sending router is either 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

2.2.6.  IGMPv3 and MLDv1 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 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

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.

Holbrook/Cain/Haberman                                          [Page 6]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004

3.  Router Requirements for Source-Specific Multicast

Routers must be aware of the SSM address range in order to provide the
SSM service model.  A router that knows the SSM address range and is
capable of applying SSM semantics to it as described in this section is
described as an "SSM-aware" router.  An SSM-aware router MAY have a
configuration option to apply SSM semantics to addresses other than the
IANA-allocated range, but if such an option exists, it MUST default to
the IANA-allocated range.

This section documents the behavior of routers with respect to the
following types of SFGMP messages for source-specific destination

     - IGMPv3 and MLDv2 Reports (3.1)
     - IGMPv3 and MLDv2 General Query (3.2)
     - IGMPv3 and MLDv2 Group-Specific Query (3.3)
     - IGMPv3 and MLDv2 Group-and-Source Specific Query (3.4)
     - IGMPv1/v2 and MLDv1 Reports (3.5)
     - IGMPv1/v2 and MLDv1 Queries (3.6)
     - IGMPv2 Leave and MLDv1 Done (3.7)

3.1.  IGMPv3 and MLDv2 Reports

SFGMP Reports are used to report source-specific subscriptions in the
SSM address range.  A router SHOULD ignore a group record of either of
the following types if it refers to an SSM destination address:

        - MODE_IS_EXCLUDE Current-State Record

        - CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record

and a router MAY choose to log an error in this case.  It MUST process
any other group records within the same report.  These behaviors are
MODIFICATIONS to [IGMPv3,MLDv2] to prevent non-source-specific semantics
from being applied to SSM addresses, and to avoid reverting to older-
version compatibility mode.

A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record is processed per the
normal SFGMP rules; Section 2.2.2 describes a legitimate scenario when
this could occur.

3.2.  IGMPv3 and MLDv2 General Queries

An SSM router sends periodic SFGMP General Queries as per the IGMPv3 and
MLDv2 specifications.  No change in behavior is required for SSM.

Holbrook/Cain/Haberman                                          [Page 7]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004

3.3.  IGMPv3 and MLDv2 Group Specific Queries

SFGMP routers that support source-specific multicast may send group-
specific queries for addresses in the source-specific range.  This
specification does not explicitly prohibit such a message, although, at
the time of this writing, a router conformant to [IGMPv3,MLDv2] would
not send one.

3.4.  IGMPv3 and MLDv2 Group-and-Source Specific Queries

SFGMP Group-and-Source Specific Queries are used when a receiver has
indicated that it is no longer interested in receiving traffic from a
particular (S,G) pair to determine if there are any remaining directly-
attached hosts with interest in that (S,G) pair.  Group-and-Source
Specific Queries are used within the source-specific address range when
a router receives a BLOCK_OLD_SOURCES Record for one or more source-
specific groups.  These queries are sent normally, as per

3.5.  IGMPv1/v2 and MLDv1 Reports

An IGMPv1/v2 or MLDv1 report for an address in the source-specific range
could be sent by a non-SSM-aware host.  A router SHOULD ignore all such
reports and specifically SHOULD NOT use them to establish IP forwarding
state.  This is a MODIFICATION to [IGMPv3,MLDv2].  A router MAY log an
error if it receives such a report (also a MODIFICATION).

3.6.  IGMPv1/v2 and MLDv1 Queries

An SFGMP router that loses the querier election to a lower version
router must log an error, as specified by [IGMPv3,MLDv2].

3.7.  IGMPv2 Leave and MLDv1 Done

An IGMPv2 Leave or MLDv1 Done message may be sent by a non-SSM-aware
host.  A router SHOULD ignore all such messages in the source-specific
address range and MAY log an error (MODIFICATION).

4.  Security Considerations

The specific protocol modifications described in this document are not
known to create any security concerns that are not already present when
IGMPv3 or MLDv2 is used with ASM-style multicast.  The reader is

Holbrook/Cain/Haberman                                          [Page 8]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004

referred to [SSM] for an analysis of SSM-specific security issues.

It is important that a router not accept non-source-specific reception
requests for an SSM destination address.  The rules of [IGMPv3] and
[MLDv2] require a router, upon receiving such a membership report, to
revert to earlier version compatibility mode for the group in question.
If the router were to revert in this situation, it would prevent an
IGMPv3-capable host from receiving SSM service for that destination
address, thus creating a potential for an attacker to deny SSM service
to other hosts on the same link.

5.  Notes

[To be removed before going to the IESG.]

5.1.  Change history

Changes in the -06 version: Responses to last call comments received,
mostly from Pekka Savola, and some additional wordsmithing and editing.
Described the SSM-aware router, cleaned up and normalized the use of the
MODIFICATION tag.  Eliminated most uses of MAY/MUST/SHOULD in places
where there was no modification to the prior specs.  Updated the

Changes in the -05 version: Additional wordsmithing, editing,
eliminating redundancy.  Clean up the text describe SSM-awareness.  Call
out what is actually a protocol modification vs. what is a clarification
of existing protocol behavior. Clarify that an ssm-aware host may send
IGMPv1,2/MLDv1 reports when in compatibility mode.  Clean up the
abstract, add notion of SSM-aware to the abstract.  Add reference to

Changes in the -04 version: Updated to reflect ID-nits.  Rewrote
Abstract, added Security Considerations, IPR, and Copyright statements.
Clarified the notion of an "SSM-aware" host as being a host with an
address range configuration option.  Clarified that
CHANGE_TO_INCLUDE_MODE may be sent when the address range configuration
changes.  Eliminated the mention of the option to ignore older version
queriers -- this conflicts the IGMPv3 spec and creates a bunch of bad
scenarios for ASM.  Updated and split references to

Changes in the -03 version: There were two major changes in this
revision (-03): the inclusion of IPv6, and the removal of the explicit
text stating that a host MAY choose to ignore IGMPv1/v2 (MLDv1) queries
in the SSM address range.  The document was internally inconsistent on
this point (it said two different things in two different sections), and

Holbrook/Cain/Haberman                                          [Page 9]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004

the statement conflicted with the existing IGMPv3 specifications.  This
situation indicates a serious configuration error and if the querying
router has already reverted to IGMPv2 mode for a group, then a host can
not receive proper SSM service for that group in any case.  Hence the
authors decided that it was better to remove this statement.

5.2.  A note on EXCLUDE mode

The IGMPv3 and MLDv2 protocol specifications explicitly state that a
host MUST NOT transition to EXCLUDE mode as a result of running out of
resources -- hence when a host runs out of resources, it will not fail
to provide SSM service.

6.  Acknowledgments

The authors would like to thank Vince Laviano, Nidhi Bhaskar, Steve
Deering, Toerless Eckert, and Pekka Savola and for their input and
careful review.

7.  Normative References

[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2,"
RFC 2236, November 1997.

[IGMPv3] Cain, B., Deering, S., Fenner, B., Kouvelas, I., and
Thyagarajan, A., "Internet Group Management Protocol, Version 3," RFC
3376, October 2002.

[MSFAPI] Thaler, D., Fenner, B., and Quinn, B.  "Socket Interface
Extensions for Multicast Source Filters," RFC3678, January 2004.

[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112,
August 1989.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997.

[SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP",
draft-holbrook-ssm-arch-04.txt.  Work in Progress.

[MLDv2] Vida, R., and Costa, L., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", draft-vida-mld-v2-08.txt. Work in progress.

[RFC2710] Deering, S., Fenner, B., and Haberman, B., "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.

Holbrook/Cain/Haberman                                         [Page 10]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004

8.  Informative References

[IANA-ALLOCATION] Internet Assigned Numbers Authority,

[RFC3306] Haberman, B., and Thaler, D., "Unicast-prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.

Authors' Addresses

     Hugh Holbrook
     Cisco Systems
     170 W. Tasman Drive.
     San Jose, CA 95134

     Brad Cain
     Storigen Systems
     650 Suffolk St.
     Lowell, MA 01854

     Brian Haberman
     Caspian Networks

Intellectual Property Rights Notice

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to  pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this

Holbrook/Cain/Haberman                                         [Page 11]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               16 Feb 2004

standard.  Please address the information to the IETF Executive

Full Copyright Statement

Copyright (C) The Internet Society (2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS

This document expires Aug 16, 2004.

Holbrook/Cain/Haberman                                         [Page 12]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/