INTERNET-DRAFT IGMPv3/MLDv2 for SSM H. Holbrook
Expires Sep 2, 2003 Cisco Systems
B. Cain
Storigen Systems
B. Haberman
Caspian Networks
Mar 2, 2003
Using IGMPv3 and MLDv2 For Source-Specific Multicast
<draft-holbrook-idmr-igmpv3-ssm-04.txt>
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
Holbrook/Cain/Haberman [Page 1]
=0C
INTERNET-DRAFT IGMPv3/MLDv2 for SSM 2 Mar 2003
Abstract
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 particular form of multicast in which a
network multicast transmission is bound to a specific source. This
document describes clarifications of and modifications to the behavior
of IGMPv3 and MLDv2 to accomodate source-specific multicast.
1. Introduction
The Internet Group Management Protocol (IGMP) [RFC1112,IGMPv2,IGMPv3],
is the standard mechanism for communicating IP multicast group
membership requests from a host to its locally attached routers in IPv4.
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. For IPv6, MLD version 2 (MLDv2)
provides the analagous functionality of IGMPv3 for IPv4.
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 reference IGMPv3 and MLDv2
capable group management protocols.
The SFGMP algorithms and message processing rules require small changes
to support and facilitate the use of the source-specific multicast
model. This document defines the modifications required of the host and
router portions of IGMPv3 and MLDv2 to support SSM. In some cases this
document also clarifies the behavior of IGMPv3 and MLDv2 in the presence
of SSM.
2. GMP Host Requirements for Source-Specific Multicast
The 232/8 address range is currently allocated for SSM by IANA [IANA-
ALLOCATION] for IPv4. In IPv6, the range is FF3x::/32 [RFC3306,SSM]
(where 'x' is a valid IPv6 multicast scope value). Hosts and routers
may be configured to apply SSM semantics to other addresses as well, as
described below.
The GMP module on a host or router SHOULD have a configuration mechanism
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
Holbrook/Cain/Haberman [Page 2]
=0C
INTERNET-DRAFT IGMPv3/MLDv2 for SSM 2 Mar 2003
configuration. Protocol mechanisms to set this option may be defined in
the future.
A host with such a configuration option is described as an "SSM-aware"
host. This section defines small modifications to the SFGMP protocol
module for an SSM-aware host. These modifications facilitate the
application use of source-specific multicast. It is important to note
that SSM can be used by any host, including a non-SSM-aware host, that
supports the source filtering APIs and whose operating system supports
the appropriate SFGMP. This section defines SFGMP modifications to make
SSM work better when the host knows the SSM address range, but they are
not strict prerequisites for the use of SSM.
2.1. API requirements
If the host IP module receives a non source-specific request to receive
multicast traffic to an SSM destination address, the host IP module of
an SSM-aware host SHOULD return an error to the application. On a non-
SSM-aware host, an application that use 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,
as a properly configured router will refuse to process the request, and
the application will receive no indication other than a failure to
receive any traffic.
This section documents the behavior of hosts with respect to sending and
receiving the following GMP message types:
- IGMPv1/v2 and MLDv1 Reports
- IGMPv3 and MLDv2 Reports
- IGMPv1/v2 and MLDv1 Queries
- IGMPv2 Leave and MLDv1 Done
- IGMPv2 and MLDv1 Group Specific Query
- IGMPv3 and MLDv2 Group Specific Query
- IGMPv3 and MLDv2 Group-and-Source Specific Query
2.2. IGMPv1/v2 and MLDv1 Reports
An SSM-aware host SHOULD NOT send an IGMPv1, IGMPv2, or MLDv1 report for
an SSM address. [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. Suppressing reports in this scenario
would provide an avenue for an attacker to deny SSM service to other
hosts on the link.
Holbrook/Cain/Haberman [Page 3]
=0C
INTERNET-DRAFT IGMPv3/MLDv2 for SSM 2 Mar 2003
2.3. IGMPv3 and MLDv2 Reports
Source-specific multicast destination-and-source pairs (channels) are
reported by using SFGMP (IGMPv3 or MLDv2) messages. 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 one 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.
A CHANGE_TO_INCLUDE_MODE record may be sent by a host, for instance,
when the SSM address range is changed through configuration. A router
processes such a record normally.
A host that is configured to know the SSM address range 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
EXCLUDE mode does not apply to SSM addresses, and the filter mode used
for an SSM address should never change to or from EXCLUDE mode for an
SSM address. Furthermore, routers ignore MODE_IS_EXCLUDE and
CHANGE_TO_EXCLUDE_MODE requests.
2.4. 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
Holbrook/Cain/Haberman [Page 4]
=0C
INTERNET-DRAFT IGMPv3/MLDv2 for SSM 2 Mar 2003
source address. As a result, SSM semantics will no longer be applied to
G 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 compliant with this
document or if the host and the router disagree about the SSM address
range.
A host SHOULD log an error if it receives an IGMPv1, IGMPv2, or MLDv1
query for an SSM address.
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.5. IGMPv2 Leave and MLDv1 Done
IGMP Leave/Done messages are not processed by hosts. IGMPv2 Leave and
MLDv1 Done messages are not sent for SSM addresses.
2.6. 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 according to [IGMPv3][MLDv2], even if the group queried
is a source-specific destination address. The transmission of such a
query indicates that the sending router is either not compliant with
this document or that is not configured with the same SSM address
range(s) as the receiving host. A host SHOULD log an error in this
case.
2.7. 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.
Although in the current IGMPv3 and MLDv2 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.
Holbrook/Cain/Haberman [Page 5]
=0C
INTERNET-DRAFT IGMPv3/MLDv2 for SSM 2 Mar 2003
2.8. 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.
A host MUST be able to process a query with multiple sources listed per
group.
3. Router Requirements for Source-Specific Multicast
Routers must be aware of the SSM address range. The 232/8 and FF3x::/32
address ranges are currently allocated for SSM by IANA [IANA-
ALLOCATION][RFC3306]. An SSM router may have a configuration option to
apply SSM semantics to other addresses, as well. If this configuration
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
addresses:
- IGMPv3 and MLDv2 Reports
- IGMPv3 and MLDv2 General Query
- IGMPv3 and MLDv2 Group-Specific Query
- IGMPv3 and MLDv2 Group-and-Source Specific Query
- IGMPv1/v2 and MLDv1 Reports
- IGMPv1/v2 and MLDv1 Queries
- IGMPv2 Leave and MLDv1 Done
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
A router MUST process any other group records within the report. A
CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Records MUST be processed as
normal.
Holbrook/Cain/Haberman [Page 6]
=0C
INTERNET-DRAFT IGMPv3/MLDv2 for SSM 2 Mar 2003
3.2. IGMPv3 and MLDv2 General Queries
SFGMP General Queries are used to periodically build the total desired
membership state on a subnet. These queries are used for the same
purpose in the source-specific address range -- no change in behavior is
required. An SSM router sends periodic SFGMP General Queries as per the
IGMPv3 and MLDv2 specifications.
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 writing, a router conformant to [IGMPv3][MLDv2] would never
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
[IGMPv3][MLDv2].
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 host that does not support the source-specific model.
A router SHOULD ignore all such reports in the source-specific address
range and specifically SHOULD NOT use them to establish IP forwarding
state. A router MAY log an error if it receives such a report.
3.6. IGMPv1/v2 and MLDv1 Queries
The GMP querier on a shared-medium network is elected to be the one with
lowest source IP address, per [IGMPv3] and [MLDv2]. Therefore, an
IGMPv3 or MLDv2 router will yield to an IGMPv1, IGMPv2, or MLDv1 querier
with a lower IP address. SFGMP routers that lose the querier election
to a lower version router MUST log an error, as per the IGMPv3 and MLDv2
specifications.
Holbrook/Cain/Haberman [Page 7]
=0C
INTERNET-DRAFT IGMPv3/MLDv2 for SSM 2 Mar 2003
3.7. IGMPv2 Leave and MLDv1 Done
An IGMPv2 Leave or MLDv1 Done message may be received for a source-
specific address from a host that does not support the source-specific
model. A router SHOULD ignore all such messages in the source-specific
address range and MAY log an error.
4. Security Considerations
The specific protocol modifications described in this document are not
known to create any security concerns that were not already present when
IGMPv3 or MLDv2 was used with ASM-style multicast. The reader is
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 by sending non-source-specific reports.
5. Notes
[To be removed before going to the IESG.]
5.1. Change history
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
normative/informative.
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 the statement
conflicted with the existing IGMPv3 specifications. This situation
indicates a serious configuration error and if the querying router has
Holbrook/Cain/Haberman [Page 8]
=0C
INTERNET-DRAFT IGMPv3/MLDv2 for SSM 2 Mar 2003
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, and Steve
Deering 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., and A. Thyagarajan, "Internet Group
Management Protocol, Version 3," RFC 3376, October 2002.
[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",
Work in Progress.
[MLDv2] Vida, R., and Costa, L., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", draft-vida-mld-v2-06.txt, Work in progress.
[RFC2710] Deering, S., Fenner, B., and Haberman, B., "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
8. Informative References
[IANA-ALLOCATION] Internet Assigned Numbers Authority,
http://www.isi.edu/in-notes/iana/assignments/multicast-addresses.
[RFC3306] Haberman, B., and Thaler, D., "Unicast-prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
Holbrook/Cain/Haberman [Page 9]
=0C
INTERNET-DRAFT IGMPv3/MLDv2 for SSM 2 Mar 2003
Authors' Addresses
Hugh Holbrook
Cisco Systems
170 W. Tasman Drive.
San Jose, CA 95134
holbrook@cisco.com
Brad Cain
Storigen Systems
650 Suffolk St.
Lowell, MA 01854
bcain99@storigen.com
Brian Haberman
Caspian Networks
bkhabs@nc.rr.com
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
standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
Holbrook/Cain/Haberman [Page 10]
=0C
INTERNET-DRAFT IGMPv3/MLDv2 for SSM 2 Mar 2003
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
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
This document expires Sep 3, 2003.
Holbrook/Cain/Haberman [Page 11]
=0C
