draft-ietf-pim-explicit-tracking-05.txt   draft-ietf-pim-explicit-tracking-06.txt 
PIM Working Group H. Asaeda PIM Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track February 25, 2013 Intended status: Standards Track July 15, 2013
Expires: August 29, 2013 Expires: January 16, 2014
IGMP/MLD-Based Explicit Membership Tracking Function for Multicast IGMP/MLD-Based Explicit Membership Tracking Function for Multicast
Routers Routers
draft-ietf-pim-explicit-tracking-05 draft-ietf-pim-explicit-tracking-06
Abstract Abstract
This document describes the IGMP/MLD-based explicit membership This document describes the IGMP/MLD-based explicit membership
tracking function for multicast routers supporting IGMPv3/MLDv2. The tracking function for multicast routers supporting IGMPv3/MLDv2. The
explicit tracking function contributes to saving network resources explicit membership tracking function contributes to saving network
and fast leaves (i.e. shortening leave latency). resources and shortening leave latency, and enables operators to see
which downstream routers(s) on a LAN are joined to which multicast
tree.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Explicit Tracking Function . . . . . . . . . . . . . . . . . . 4 3. Membership State Information . . . . . . . . . . . . . . . . 4
3.1. Membership State Information . . . . . . . . . . . . . . . 4 4. Specific Query Suppression . . . . . . . . . . . . . . . . . 4
3.2. Specific Query Suppression . . . . . . . . . . . . . . . . 5 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 5
3.3. Shortening Leave Latency . . . . . . . . . . . . . . . . . 6 6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 6
4. Lowering the Possibility of Outdated Membership State . . . . 7 7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7
5. All-Zero and Unspecified Source Addresses . . . . . . . . . . 8 8. Compatibility with Older Version Protocols . . . . . . . . . 7
6. Compatibility with Older Version Protocols . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Internet Group Management Protocol (IGMP) version 3 [1] for IPv4 The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4
and the Multicast Listener Discovery Protocol (MLD) version 2 [2] for and the Multicast Listener Discovery Protocol (MLD) version 2 [3] for
IPv6 are the standard protocols used by member hosts and multicast IPv6 are the standard protocols used by member hosts and multicast
routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and
LW-MLDv2) [3] are subsets of the standard IGMPv3 and MLDv2. When a LW-MLDv2) [4] are subsets of the standard IGMPv3 and MLDv2.
host starts/finishes listening to particular multicast channels, it
sends IGMP/MLD State-Change Report messages specifying the
corresponding channel information as the join/leave request to its
upstream router (i.e., an adjacent multicast router or IGMP/MLD proxy
device [5]). The "unsolicited" report messages are sent only when
the host joins/leaves the channels.
IGMP/MLD are non-reliable protocols; the unsolicited report messages When a host starts/finishes listening to particular multicast
may be lost or may not reach upstream routers. To alleviate the channels, it sends IGMP/MLD State-Change Report messages specifying
problem, routers need to update membership information by the corresponding channel information as the join/leave request to
periodically sending IGMP/MLD General Query messages. Member hosts its upstream router (i.e., an adjacent multicast router or IGMP/MLD
then reply with "solicited" report messages whenever they receive the proxy device [8]). The "unsolicited" report messages are sent only
query messages. when the host joins/leaves the channels. Since IGMP/MLD are non-
reliable protocols, unsolicited report messages may be lost or may
not reach upstream routers. To alleviate the problem, unsolicited
report messages are transmitted the [Robustness Variable] times
(defined in [2][3]).
Multicast routers are capable of periodically maintaining the Also, a querier router periodically sends IGMP/MLD General Query
multicast membership state of downstream hosts attached to the same messages within the General Query timer interval (i.e. [Query
link by acquiring unsolicited report messages and synchronizing the Interval] value defined in [2][3]). Upon receiving the query
actual membership state within the General Query timer interval messages, the member hosts reply with "solicited" report messages.
(i.e., [Query Interval] value defined in [1][2].) However, this Routers then keep their membership state information up to date.
approach does not guarantee that the membership state is always However, this approach still does not guarantee that the membership
perfectly synchronized. To minimize the possibility of having state is always perfectly synchronized. To minimize the possibility
outdated membership information, routers may shorten the periodic of having outdated membership information, routers may shorten the
General Query timer interval. Unfortunately, this increases the periodic General Query timer interval. Unfortunately, this increases
number of transmitted solicited report messages and induces network the number of transmitted solicited report messages and induces
congestion. And the greater the amount of network congestion, the network congestion. And the greater the amount of network
greater the potential for IGMP/MLD report messages being lost and the congestion, the greater the potential for IGMP/MLD report messages
membership state information being outdated in the router. being lost and the membership state information being outdated in the
router.
The IGMPv3 [1] and MLDv2 [2] protocols and these lightweight IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can
protocols [3] can provide the ability to keep track of the downstream provide the ability to keep track of the downstream (adjacent)
(adjacent) multicast membership state to multicast routers, yet the multicast membership state to multicast routers, yet the
specifications are not clearly given. This document describes the specifications are not clearly given. This document describes the
"IGMP/MLD-based explicit member tracking function" for multicast "IGMP/MLD-based explicit member tracking function" for multicast
routers and details a way for routers to implement the function. By routers and a way for routers to implement the function. By enabling
enabling this explicit tracking function, routers can keep track of this explicit tracking function, routers can keep track of the
the downstream multicast membership state. This function enables the downstream multicast membership state. This function enables the
following: following things:
o Reducing the number of transmitted query and report messages o Reducing the number of transmitted query and report messages
o Shortening leave latencies o Shortening leave latencies
o Per-host accounting o Per-host accounting
o Maintaining multicast channel characteristics (or statistics) o Maintaining multicast channel characteristics (or statistics)
In addition, the processing of IGMP membership or MLD listener where this document mainly focuses on the above first and second
messages consumes CPU resources on individual IGMP/MLD querier and bullets in the following sections.
report sender devices. The explicit tracking function therefore
reduces not only the network load but also the CPU load on these
devices.
The explicit tracking function does not guarantee that the membership Note that the explicit tracking function does not change the
state will always be perfectly synchronized; the list of tracked reliability of the message transmission. The list of tracked member
member hosts may be outdated in the router because of host departure hosts may be outdated in the router because of host departure from
from the network without sending State-Change Report messages or loss the network without sending State-Change Report messages or loss of
of such messages due to network congestion. Therefore, a router such messages due to network congestion. Therefore, a router even
enabling the function ought to send periodic IGMPv3/MLDv2 General enabling the function may need to send periodic IGMPv3/MLDv2 General
Query messages and solicit IGMPv3/MLDv2 report messages from Query messages and solicit IGMPv3/MLDv2 report messages from
downstream member hosts to maintain an up-to-date membership state. downstream member hosts to maintain an up-to-date membership state,
while the function contributes to saving network resources by tuning
query timers or values.
The explicit tracking function potentially requires a large amount of The explicit tracking function potentially requires a large amount of
memory so that routers keep all membership states. Particularly when memory so that routers keep all membership states. Particularly when
a router needs to maintain a large number of member hosts, this a router needs to maintain a large number of member hosts, this
resource requirement could have an impact. Operators may decide to resource requirement could have an impact. Operators may decide to
disable this function when their routers have insufficient memory disable this function when their routers have insufficient memory
resources, despite the benefits mentioned above. resources, despite the benefits mentioned above.
The explicit tracking function does not change message formats used The explicit tracking function does not change message formats used
by the standard IGMPv3 [1] and MLDv2 [2], and their lightweight by the standard IGMPv3 [2] and MLDv2 [3], and their lightweight
version protocols [3]; nor does it change a multicast data sender's version protocols [4]; nor does it change a multicast data sender's
and receiver's behavior. and receiver's behavior.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [4]. this document are to be interpreted as described in RFC 2119 [1].
3. Explicit Tracking Function
3.1. Membership State Information 3. Membership State Information
A router enabling the explicit tracking function maintains the A router enabling the explicit tracking function maintains the
"membership state information". When a multicast router receives a "membership state information". When a multicast router receives a
Current-State or State-Change Report message, it creates this Current-State or State-Change Report message, it creates or modifies
membership state information or adds or deletes the receiver IP this membership state information to maintain the membership state up
address to or from it. If there are no more receivers maintained, to date.
the router may keep the membership state information with an empty
receiver list.
The membership state information consists of the following
information:
(S, G, number of receivers, (receiver records))
where each receiver record is of the form:
(IGMP/MLD membership/listener report sender's address) The membership state information is also known as the following
"interface state" defined by the standard IGMPv3 and MLDv2
specifications [2][3].
This state information must work properly when a receiver (i.e., (multicast address, filter mode, source list)
report sender) sends the identical report messages multiple times.
In the state information, each S and G indicates a single IPv4/IPv6 The membership state information must be identified properly even
address. S is set to "Null" for Any-Source Multicast (ASM) though a receiver (i.e., IGMP/MLD Report sender) sends the identical
communication (i.e., (*,G) join reception). In order to simplify the report messages multiple times.
implementation, the explicit tracking function MAY NOT keep the state
of (S,G) joined with EXCLUDE filter mode. In that case, if a router
receives an (S,G) join/leave request with EXCLUDE filter mode from
the downstream hosts, the router translates the request to a (*,G)
join state/leave request and records the state and the receivers'
addresses in the maintained membership state information. Note that
this membership state translation does not change the routing
protocol behavior. The routing protocol must deal with the original
join/leave request and translate the request only for the membership
state information.
3.2. Specific Query Suppression 4. Specific Query Suppression
In accordance with [1] and [2], whenever a router receives the State- In accordance with [2] and [3], when a router receives the State-
Change Report, it sends the corresponding Group-Specific or Group- Change Report and needs to confirm whether any hosts are still
and-Source Specific Query messages to confirm whether or not the interested in a channel or not, the router sends the corresponding
report sender is the sole member host. All member hosts joining the Group-Specific or Group-and-Source Specific Query messages along with
identical channel send their own Current-State Report messages after the definition of Section 6.4.2 of [2] and Section 7.4.2 of [3]. The
acquiring these query messages. Transmitting a large number of queries sent by actions defined in these sections need to be
Current-State Report messages consumes network resources, and this transmitted [Last Member Query Count] (LMQC) or [Last Listener Query
may pose a particular problem when many hosts joining the identical Count] (LLQC) times, once every [Last Member Query Interval] (LMQI)
or [Last Listener Query Interval] (LLQI), in order to confirm the
sole member. (The default values for LMQI/LLQI defined in [2][3] are
1 second. The default values for LMQC/LLQC are the [Robustness
Variable] value whose default value is 2.) All member hosts joining
the identical channel then reply their own states after acquiring
these query messages. However, transmitting a large number of IGMP/
MLD Report messages consumes network resources, and this may pose a
particular problem especially when many hosts joining the identical
channel send these reports simultaneously. channel send these reports simultaneously.
The explicit tracking function can reduce the number of Group- The explicit tracking function provides a method called "specific
Specific or Group-and-Source Specific Query messages transmitted from query suppression" that reduces the number of Group-Specific or
a router, and reduce the number of Current-State Report messages Group-and-Source Specific Query messages transmitted from a router.
transmitted from member hosts. If a router enables the explicit This in turn reduces the number of Current-State Report messages
tracking function with "specific query suppression", it suppresses transmitted from member hosts.
specific query transmission and transmits specific query messages
only when the router expects that the State-Change Report sender is
the sole member of the channel, based on its membership state
information (expressed in Section 3.1).
As standard behavior for [1] and [2], a router also sends a Group- With the specific query suppression, regardless of the LMQC/LLQC
Specific or Group-and-Source Specific Query multiple times when it values, if the router receives one or more replies from the
receives a State Change Report message (e.g., leave request) from a downstream member(s), it can stop (i.e., cancel) retransmitting the
member host. This is in order to confirm whether or not the host is specific query message(s) and lower the corresponding source/group
the sole member. However, if the router enabling the explicit timers. This contributes to saving network resources.
tracking function runs specific query suppression and receives one or
more replies for the specific query retransmission from the The specific query suppression in "hard state" may also be
downstream member(s), the router can cancel resending of the implemented with the explicit tracking function; a router enabling
identical specific query message(s). the specific query suppression in hard state does not send any
specific query message(s) and immediately leave the group or sources
when the sole member has left according to its membership state
information. The specific query suppression in hard state hence does
not rely on LMQC/LLQC and LMQI/LLQI values. This contributes to
shortening leave latency described in Section 5. However, this
behavior requires that the router perfectly tracks all member hosts.
(See a risk of wrong membership expectation described in Section 6.)
Note that the default behavior of the router that supports the Note that the default behavior of the router that supports the
explicit tracking function SHOULD disable this specific query explicit tracking function SHOULD disable this specific query
suppression in order to avoid the risk caused by the situation in suppression, in order to avoid the risk caused by the wrong
which multiple multicast routers exist on a LAN and the querier membership expectation or by the case in which multiple multicast
router is not the forwarder router. When the querier suppresses the routers exist on a LAN and the querier router is not the forwarder
specific query message transmission, and expects that the State- router. The former case is described in Section 6. For the latter
Change Report sender is not the sole member of the channel, it does case, when the querier suppresses the specific query message
not send the specific query and none of the routers on the same LAN transmission, and expects that the State-Change Report sender is not
receive a Current-State Report message from the corresponding member the sole member of the channel, it does not send the specific query
hosts. The forwarder in this case may prune the routing path though and none of the routers on the same LAN receive a Current-State
there are other member hosts subscribing to the channel on the LAN. Report message from the corresponding member hosts. The forwarder in
this case may prune the routing path though there are other member
hosts subscribing to the channel on the LAN.
3.3. Shortening Leave Latency 5. Shortening Leave Latency
A router enabling the explicit tracking function can shorten leave A router enabling the explicit tracking function can shorten leave
latencies by tuning several timers and values to what it expects latencies by tuning the following values; [Last Member Query Count]
whether or not the State-Change Report sender is the channel's sole (LMQC), [Last Listener Query Count] (LLQC), [Last Member Query
member. Interval] (LMQI), [Last Listener Query Interval] (LLQI), and
[Robustness Variable] values.
The [Last Member Query Interval] (LMQI) and [Last Listener Query The [Last Member Query Interval] (LMQI) and [Last Listener Query
Interval] (LLQI) values specify the maximum time allowed for a member Interval] (LLQI) values defined in the standard specifications [2][3]
host to send a responding Report before the router prunes the channel specify the maximum time allowed for a member host to send a
from the network. The [Last Member Query Count] (LMQC) and [Last responding Report. The [Last Member Query Count] (LMQC) and [Last
Listener Query Count] (LLQC) are the number of Group-Specific Queries Listener Query Count] (LLQC) are the number of Group-Specific Queries
or Group-and-Source Specific Queries sent before the router assumes or Group-and-Source Specific Queries sent before the router assumes
there are no local members. The [Last Member Query Time] (LMQT) and there are no local members. The [Last Member Query Time] (LMQT) and
[Last Listener Query Time] (LLQT) values are the total time the [Last Listener Query Time] (LLQT) values are the total time the
router should wait for a report after the Querier has sent the first router should wait for a report after the Querier has sent the first
query. query.
The default value for LMQI/LLQI defined in the standard The default values for LMQI/LLQI defined in [2][3] are 1 second, yet,
specifications [1][2] is 1 second. For a router enabling the for a router enabling the explicit tracking function, the LMQI/LLQI
explicit tracking function, the LMQI/LLQI MAY be set to 1 second or may be set to 1 second or shorter. As well, the default values for
shorter. The LMQC/LLQC values MAY be set to 1 for the router, LMQC/LLQC are the [Robustness Variable] value whose default value is
whereas their default values are the [Robustness Variable] value 2, yet the LMQC/LLQC may be set to 1 for the router. Smaller LMQC/
whose default value is 2. Smaller LMQC/LLQC values give smaller LLQC values give shorter LMQT/LLQT, which shorten the leave
LMQT/LLQT, which shortens the leave latencies. On the other hand, latencies.
setting smaller LMQC/LLQC values poses the risk described in
Section 4. Operators setting smaller LMQC/LLQC values must recognize
this tradeoff.
4. Lowering the Possibility of Outdated Membership State Furthermore, if operators believe that their link is fairly robust or
that they can configure the [Robustness Variable] value appropriately
so that the chances of unsolicited messages being lost are
sufficiently low, and if the querier router is always the forwarder
router in their link, they will set smaller LMQC/LLQC and shorter
LMQI/LLQI (and hence shorter LMQT/LLQT) with the specific query
suppression or enable the specific query suppression in hard state
(Section 4) for their routers.
There are possibilities that a router enables the explicit tracking Note that setting smaller LMQC/LLQC values or adopting the specific
function but its membership expectation will be inconsistent due to query suppression in hard state poses the risk of wrong membership
an outdated membership state. For example, (1) a router expects that state described in Section 6. Operators setting smaller LMQC/LLQC
more than one corresponding member host exists on its LAN, but in values must recognize this tradeoff.
fact no member host exists for that multicast channel, or (2) a
router expects that no corresponding member host exists on its LAN,
but in fact more than one member host exists for that multicast
channel. These cases are particularly likely for a router that
enables specific query suppression (as in Section 3.2) and configures
small LMQC/LLQC for shortening leave latency (as in Section 3.3).
The first of these cases may occur in an environment where the sole 6. Risk of Wrong Membership State
member host departs the network without sending a State-Change Report
message. This is because a router enabling specific query There are possibilities that a router's membership expectation is
suppression does not send a specific query if it believes the report inconsistent due to an outdated membership state. For example, (1) a
sender is not the sole member host. The router later detects that router expects that more than one corresponding member host exists on
there is no member host for the corresponding channels when it does its LAN, but in fact no member host exists for that multicast
not receive a Current-State Report within the timeout of the response channel, or (2) a router expects that no corresponding member host
for the periodic General Query. However, this situation prolongs exists on its LAN, but in fact one or more than one member host
leave latency and wastes network resources since the router forwards exists for that multicast channel.
unneeded traffic until that point.
The first case may occur in an environment where the sole member host
departs the network without sending a State-Change Report message.
The router later detects that there is no member host for the
corresponding channels when it does not receive a Current-State
Report within the timeout of the response for the periodic General
Query (and then the group or source timers are expired). However,
this situation prolongs leave latency and wastes network resources
since the router forwards unneeded traffic for a while.
The second case occurs when a router sends a specific query but does The second case occurs when a router sends a specific query but does
not receive a State-Change Report from a downstream host within an not receive a Current-State Report from a downstream host within an
LMQT or LLQT period. It recognizes that no member host exists on the LMQT or LLQT period. It recognizes that no member host exists on the
LAN and might prune the routing path. The router reestablishes the LAN and might prune the routing path. The router reestablishes the
routing path when it receives the solicited report message for the routing path when it receives the solicited report message for the
channels. However, the downstream hosts may loose the data packets channels. However, the downstream hosts may loose the data packets
until the routing path is reestablished and the data forwarding is until the routing path is reestablished and the data forwarding is
restarted. restarted.
In order to reduce the possibility of the incorrect membership If operators do not believe that their link is fairly robust or that
expectation and keep the up-to-date membership state information, they can configure the [Robustness Variable] value appropriately,
when a router enabling the explicit tracking function enables they may configure the LMQC/LLQC value to 2 (the default value of the
specific query suppression, the router SHOULD configure the LMQC/LLQC [Robustness Variable] value) or bigger value for their routers. In
value to 2 (the default value of the [Robustness Variable] value) or this case, the routers would enable the explicit tracking function
higher; or, when a router enabling the explicit tracking function but may want to disable the specific query suppression specified in
configures a small LMQC/LLQC, the router SHOULD NOT enable specific Section 4. Such configurations will not contribute to saving network
query suppression. resources, but reduce the risk of the incorrect membership
expectation.
5. All-Zero and Unspecified Source Addresses 7. All-Zero and Unspecified Source Addresses
The IGMPv3 specification [1] mentions that an IGMPv3 report is The IGMPv3 specification [2] mentions that an IGMPv3 report is
usually sent with a valid IP source address, yet it permits a host to usually sent with a valid IP source address, yet it permits a host to
use the 0.0.0.0 source address (since the host has not yet acquired use the 0.0.0.0 source address (since the host has not yet acquired
an IP address), and routers must accept a report with this source an IP address), and routers must accept a report with this source
address. The MLDv2 specification [2] mentions that an MLDv2 report address.
must be sent with a valid IPv6 link-local source address, yet an
MLDv2 report may be sent with the unspecified address (::) if the
sending interface has not acquired a valid link-local address. [2]
also mentions that routers silently discard a message that is not
sent with a valid link-local address or sent with the unspecified
address, without taking any action, because of security
considerations.
When a router enabling the explicit tracking function receives IGMP/ When a router enabling the explicit tracking function receives IGMP
MLD report messages with an all-zero or unspecified source address, report messages with an all-zero source address, it deals with the
it deals with the IGMP/MLD report messages correctly as defined in IGMP report messages correctly as defined in [2] and continuously
[1][2] and continuously keeps track of the membership state, but keeps track of the membership state. However, the router SHOULD NOT
SHOULD NOT maintain the host specifying all-zero or an unspecified maintain the host specifying all-zero source address in its
source address in its membership state information. membership state information. The router will maintain its
membership state information by checking Current-State reports as
ordinary routers do.
6. Compatibility with Older Version Protocols On the other hand, the MLDv2 specification [3] mentions that routers
silently discard a message that is sent with an invalid link-local
address or sent with the unspecified address (::), without taking any
action, because of security considerations. According to this
specification, whether the explicit tracking function is used or not,
a router does not deal with a member hosts sending an MLD report
message with the unspecified source address.
8. Compatibility with Older Version Protocols
The explicit tracking function does not work with older versions of The explicit tracking function does not work with older versions of
IGMP or MLD, IGMPv1 [6], IGMPv2 [7], or MLDv1 [8], because a member IGMP or MLD, IGMPv1 [5], IGMPv2 [6], or MLDv1 [7], because a member
host using these protocols enables "membership report suppression" by host using these protocols enables "membership report suppression" by
which the host will cancel sending pending membership reports if a which the host will cancel sending pending membership reports if a
similar report is observed from another member on the network. similar report is observed from another member on the network.
To preserve compatibility with older versions of IGMP/MLD, routers To preserve compatibility with older versions of IGMP/MLD, routers
need to support downstream hosts that are not upgraded to the latest supporting IGMPv3/MLDv2 enable the host compatibility mode defined in
versions and run membership report suppression. Therefore, if a [2][3]. The host compatibility mode of an interface changes the
multicast router enabling the explicit tracking function changes its operational protocol version on the LAN whenever an older version
compatibility mode to the older versions, the router SHOULD disable query (than the current compatibility mode) is heard or when certain
the explicit tracking function. On the other hand, the router MAY timer conditions occur. The routers can hence support downstream
NOT flush the maintained membership state information. When the hosts that are not upgraded to the latest versions and run membership
router changes back to IGMPv3 or MLDv2 mode, it resumes the function report suppression.
with the old membership state information even if the state
information is outdated. This provides "smooth state transition"
that does not initiate the membership state information from scratch
and synchronizes the actual membership state smoothly.
7. IANA Considerations Therefore, if a multicast router supporting IGMPv3/MLDv2 and enabling
the explicit tracking function changes its compatibility mode to the
older versions, the router SHOULD disable the explicit tracking
function while it acts as the older version router.
9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Security Considerations 10. Security Considerations
The explicit tracking function potentially requires a large amount of The explicit tracking function potentially requires a large amount of
memory so that routers keep all membership states. Especially when memory so that routers keep all membership states. It gives some
malicious hosts send a large number of invalid IGMP/MLD report impact in the cases where (1) a router attaches to a link or an IGMP/
messages, some serious threats may be induced. In order to prevent MLD proxy device [8] that has a large number of member hosts, and a
abuse, a router enabling the explicit tracking function MAY need to router has insufficient memory resources to maintain a large number
rate-limit a total amount of membership information the router can of member hosts, or (2) a malicious host sends a large number of
store and an amount of membership information the router can store invalid IGMP/MLD report messages.
per host. The rate limit is left to the router's implementation.
9. Acknowledgements For the first case, operators may disable the explicit tracking
function, despite the benefits mentioned above. For the second case,
some serious threats may be induced. In order to prevent abuse, a
router enabling the explicit tracking function may need to limit a
total amount of membership information the router can store and an
amount of membership information the router can store per host.
Toerless Eckert, Sergio Figueiredo, Nicolai Leymann, Stig Venaas, and A router may rate-limit State-Change Report messages per host. When
others provided many constructive and insightful comments. the router enables rate-limiting per host, the router MAY ignore the
received State-Change Report messages to minimize the processing
overhead or prevent DoS attacks. The rate limit is left to the
router's implementation.
10. References 11. Acknowledgements
Luis M. Contreras, Toerless Eckert, Sergio Figueiredo, Bharat Joshi,
Nicolai Leymann, Stig Venaas, and others provided many constructive
and insightful comments.
10.1. Normative References 12. References
[1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 12.1. Normative References
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [1] Bradner, S., "Key words for use in RFCs to indicate
(MLDv2) for IPv6", RFC 3810, June 2004. requirement levels", RFC 2119, March 1997.
[3] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Management Protocol Version 3 (IGMPv3) and Multicast Listener Thyagarajan, "Internet Group Management Protocol, Version
Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010. 3", RFC 3376, October 2002.
[4] Bradner, S., "Key words for use in RFCs to indicate requirement [3] Vida, R. and L. Costa, "Multicast Listener Discovery
levels", RFC 2119, March 1997. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
10.2. Informative References [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
February 2010.
[5] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 12.2. Informative References
Group Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
RFC 4605, August 2006.
[6] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, [5] Deering, S., "Host Extensions for IP Multicasting", RFC
August 1989. 1112, August 1989.
[7] Fenner, W., "Internet Group Management Protocol, Version 2", [6] Fenner, W., "Internet Group Management Protocol, Version
RFC 2373, July 1997. 2", RFC 2373, July 1997.
[8] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener [7] Deering, S., Fenner, W., and B. Haberman, "Multicast
Discovery (MLD) for IPv6", RFC 2710, October 1999. Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
Author's Address [8] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP
/MLD Proxying")", RFC 4605, August 2006.
Author's Address
Hitoshi Asaeda Hitoshi Asaeda
National Institute of Information and Communications Technology (NICT) National Institute of Information and Communications Technology (NICT)
Network Architecture Laboratory Network Research Headquarters
4-2-1 Nukui-Kitamachi 4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795 Koganei, Tokyo 184-8795
Japan Japan
Email: asaeda@nict.go.jp Email: asaeda@nict.go.jp
 End of changes. 63 change blocks. 
253 lines changed or deleted 271 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/