< draft-ietf-pim-explicit-tracking-08.txt   draft-ietf-pim-explicit-tracking-13.txt >
PIM Working Group H. Asaeda PIM Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track October 07, 2013 Intended status: Experimental November 1, 2015
Expires: April 10, 2014 Expires: May 4, 2016
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-08 draft-ietf-pim-explicit-tracking-13
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 and IGMP/MLD proxy devices tracking function for multicast routers and IGMP/MLD proxy devices
supporting IGMPv3/MLDv2. The explicit membership tracking function supporting IGMPv3/MLDv2. The explicit membership tracking function
contributes to saving network resources and shortening leave latency. contributes to saving network resources and shortening leave latency.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 April 10, 2014. This Internet-Draft will expire on May 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation and Experimentation . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Membership State Information . . . . . . . . . . . . . . . . 4 3. Membership State Information . . . . . . . . . . . . . . . . 4
4. Specific Query Suppression . . . . . . . . . . . . . . . . . 4 4. Specific Query Suppression . . . . . . . . . . . . . . . . . 5
5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6
6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 7 6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 7
7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7 7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 8
8. Compatibility with Older Version Protocols . . . . . . . . . 8 8. Compatibility with Older Version Protocols . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Interoperability . . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 13.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4 The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4
and the Multicast Listener Discovery Protocol (MLD) version 2 [3] 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) [4] are subsets of the standard IGMPv3 and MLDv2. LW-MLDv2) [4] are subsets of the standard IGMPv3 and MLDv2.
When a host starts/finishes listening to particular multicast When a host starts/finishes listening to particular multicast
channels, it sends IGMP/MLD State-Change Report messages specifying channels, it sends IGMP/MLD State-Change Report messages specifying
the corresponding channel information as the join/leave request to the corresponding channel information as the join/leave request to
its upstream router (i.e., an adjacent multicast router or IGMP/MLD its upstream router (i.e., an adjacent multicast router or IGMP/MLD
proxy device [8]). The "unsolicited" report messages are sent only proxy device [8]). The "unsolicited" report messages are sent only
when the host joins/leaves the channels. Since IGMP/MLD are non- when the host joins/leaves the channels. Since IGMP/MLD are non-
reliable protocols, unsolicited report messages may be lost or may reliable protocols, unsolicited report messages may be lost or may
not reach upstream routers. To alleviate the problem, unsolicited not reach upstream routers. To alleviate this problem, unsolicited
report messages are transmitted the [Robustness Variable] times report messages are retransmitted a number of times according to the
(defined in [2][3]). value of the [Robustness Variable] defined in [2][3].
Also, a querier router periodically sends IGMP/MLD General Query In addition, a querier router periodically sends IGMP/MLD General
messages every General Query timer interval (i.e. [Query Interval] Query messages every General Query timer interval (i.e. [Query
value defined in [2][3]). Upon receiving the query messages, the Interval] value defined in [2][3]). Upon receiving the query
member hosts reply with "solicited" report messages. Routers then messages, the member hosts reply with "solicited" report messages.
keep their membership state information up to date. However, this Routers then keep their membership state information up to date.
approach still 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.
IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can
provide the ability to keep track of the downstream (adjacent) provide the ability to keep track of the downstream (adjacent)
multicast membership state in multicast routers, yet the multicast membership state in 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 a way for routers to implement the function. By enabling routers and a way for routers to implement the function. By enabling
this explicit tracking function, routers can keep track of the this explicit tracking function, routers can keep track of the
downstream multicast membership state. This function enables the downstream multicast membership state. The explicit tracking
following things: function contributes to saving network resources and shortening leave
latency.
o Reducing the number of transmitted query and report messages
o Shortening leave latencies
o Per-host accounting The explicit tracking function does not change message formats used
by IGMPv3 [2], MLDv2 [3], and their lightweight version protocols
[4]; nor does it change a multicast data sender's and receiver's
behavior.
o Maintaining multicast channel characteristics (or statistics) 1.1. Motivation and Experimentation
where this document mainly focuses on the above first and second This document specifies an experimental extension to IGMPv3/MLDv2.
bullets in the following sections. It makes some fundamental changes to how IGMPv3/MLDv2 works in that
membership state does not require periodic updates, and it partly
turns IGMPv3/MLDv2 into a hard-state protocol. Also, a mechanism
called "specific query suppression" with a robust link state is a new
concept. It does not make the router 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.
Note that the explicit tracking function does not change the The explicit tracking function does not change the reliability of the
reliability of the message transmission. The list of tracked member message transmission. The list of tracked member hosts may be
hosts may be outdated in the router because of host departure from outdated in the router because of host departure from the network
the network without sending State-Change Report messages or loss of without sending State-Change Report messages or loss of such messages
such messages due to network congestion. Therefore, a router due to network congestion. This document describes the risk of
enabling the function may still need to send periodic IGMPv3/MLDv2 having wrong membership state and guides for setting up appropriate
General Query messages and solicit IGMPv3/MLDv2 report messages from values or mechanisms used with the explicit tracking function in
downstream member hosts to maintain an up-to-date membership state. routers.
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 might be sensitive. Operators may decide to resource requirement might be sensitive. As the security
consideration, this document describes that 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.
The explicit tracking function does not change message formats used It is likely that experiences from early implementations and
by the standard IGMPv3 [2] and MLDv2 [3], and their lightweight deployments will lead to at least minor changes in the protocol. Any
version protocols [4]; nor does it change a multicast data sender's experiments using this protocol extension are encouraged. Reports
and receiver's behavior. from such experiments planned with pre-specified objectives and
scenarios are particularly encouraged. Results from such
experiments, documenting the following, are of particular importance:
o Operation in networks that contain both routers implementing this
extension, and routers implementing only [2][3][4], in particular
are there any unexpected interactions that can break the network?
o Operation in networks that contain both routers implementing this
extension, and routers implementing older versions of IGMP or MLD,
IGMPv1 [5], IGMPv2 [6], or MLDv1 [7].
o Operation in networks with dynamic topology changes.
o Operation in networks with invalid or outdated membership states.
o Network performance, including leave latency and packet delivery
results.
o Resource requirements observed from running the protocol,
including processing, storage, and bandwidth.
o Any other implementation issues.
Once there is some deployment experience, making this a Standards
Track protocol should be considered.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
this document are to be interpreted as described in RFC 2119 [1]. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
3. 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 or modifies Current-State or State-Change Report message, it creates or modifies
this membership state information to maintain the membership state up this membership state information to maintain the membership state up
to date. to date.
The membership state information consists of the following The membership state information consists of the following
information: information:
(S, G, number of receivers, (receiver records)) (S, G, number of receivers, (receiver records))
where each receiver record is of the form: where "S" denotes source address, "G" denotes group or multicast
address, and each receiver record is of the form:
(IGMP/MLD membership/listener report sender's address) (IGMP/MLD membership/listener report sender's address)
In the state information, each S and G indicates a single IPv4/IPv6 In the state information, each S and G indicates a single IPv4/IPv6
address. S is set to "Null" for Any-Source Multicast (ASM) address. S is set to "All sources" for Any-Source Multicast (ASM)
communication (i.e., (*,G) join reception). In order to simplify the communication (i.e., (*,G) join reception). In order to simplify the
implementation, Lightweight-IGMPv3/MLDv2 [4] do not keep the state of implementation, Lightweight-IGMPv3/MLDv2 [4] do not keep the state of
(S,G) joined with EXCLUDE filter mode; if a router receives an (S,G) (S,G) joined with EXCLUDE filter mode; if a router receives an (S,G)
join/leave request with EXCLUDE filter mode from the downstream join/leave request with EXCLUDE filter mode from the downstream
hosts, the router translates the request to a (*,G) join state/leave hosts, the router translates the request to a (*,G) join state/leave
request and records the state and the receivers' addresses in the request and records the state and the receivers' addresses in the
maintained membership state information. maintained membership state information.
The membership state information must be identified properly even The membership state information must be identified properly even
though a receiver (i.e., IGMP/MLD Report sender) sends the identical though a receiver (i.e., IGMP/MLD Report sender) sends the identical
skipping to change at page 5, line 4 skipping to change at page 5, line 42
In accordance with [2] and [3], when a router receives the State- In accordance with [2] and [3], when a router receives the State-
Change Report and needs to confirm whether any hosts are still Change Report and needs to confirm whether any hosts are still
interested in a channel or not, the router sends the corresponding interested in a channel or not, the router sends the corresponding
Group-Specific or Group-and-Source Specific Query messages as defined Group-Specific or Group-and-Source Specific Query messages as defined
in Section 6.4.2 of [2] and Section 7.4.2 of [3]. The queries sent in Section 6.4.2 of [2] and Section 7.4.2 of [3]. The queries sent
by actions defined in these sections need to be transmitted [Last by actions defined in these sections need to be transmitted [Last
Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC) Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC)
times, once every [Last Member Query Interval] (LMQI) or [Last times, once every [Last Member Query Interval] (LMQI) or [Last
Listener Query Interval] (LLQI), in order to confirm the sole member. 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 LMQI/LLQI defined in [2][3] are 1 second.
The default values for LMQC/LLQC are the [Robustness Variable] value The default values for LMQC/LLQC are the [Robustness Variable] value
whose default value is 2.) All member hosts joining the identical whose default value is 2.) All member hosts joining the identical
channel then reply with their own states after acquiring these query channel then reply with their own states after acquiring these query
messages. However, transmitting a large number of IGMP/MLD Report messages. However, transmitting a large number of IGMP/MLD Report
messages consumes network resources, and this may pose a particular messages consumes network resources, and this may pose a particular
problem especially when many hosts joining the identical channel send problem especially when many hosts joining the identical channel send
these reports simultaneously. these reports simultaneously.
The explicit tracking function provides a method called "specific The explicit tracking function provides a mechanism called "specific
query suppression" that reduces the number of Group-Specific or query suppression". With the specific query suppression, regardless
Group-and-Source Specific Query messages transmitted from a router. of the LMQC/LLQC values, if the router receives one or more replies
This in turn reduces the number of Current-State Report messages from the downstream member(s), it SHOULD stop (i.e., cancel)
transmitted from member hosts. retransmitting the specific query message(s) for the specified source
and/or group. It reduces the number of Group-Specific or Group-and-
Source Specific Query messages transmitted from a router, and in turn
reduces the number of Current-State Report messages transmitted from
member hosts. This contributes to saving network resources.
With the specific query suppression, regardless of the LMQC/LLQC The specific query suppression MAY define an option called "robust
values, if the router receives one or more replies from the link state". If an operator is confident that the link is stable and
downstream member(s), it can stop (i.e., cancel) retransmitting the robust enough and thus the tracked membership state information is
specific query message(s) for the specified source and/or group. perfectly synchronized with the current (actual) member hosts, s/he
This contributes to saving network resources. can enable the specific query suppression with a robust link state.
A router enabling the specific query suppression with a robust link
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
with a robust link 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.)
If the router is confident that the tracked membership state
information is perfectly synchronized with the current (actual)
member hosts, the specific query suppression in a "robust link state"
may also be implemented with the explicit tracking function. A
router enabling the specific query suppression in a robust link 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 a
robust link 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 wrong suppression, in order to avoid the risk caused by the wrong
membership expectation or by the case in which multiple multicast membership expectation or by the case in which multiple multicast
routers exist on a LAN and the querier router is not the forwarder routers exist on a LAN and the querier router is not the forwarder
router. The former case is described in Section 6. For the latter router. The former case is described in Section 6. For the latter
case, when the querier suppresses the specific query message case, when the querier suppresses the specific query message
transmission, and expects that the State-Change Report sender is not transmission, and expects that the State-Change Report sender is not
the sole member of the channel, it does not send the specific query. the sole member of the channel, it does not send the specific query.
Then the routers (including the forwarder) on the same LAN do not Then the routers (including the forwarder) on the same LAN do not
skipping to change at page 7, line 5 skipping to change at page 7, line 28
LLQC values give shorter LMQT/LLQT, which shorten the leave LLQC values give shorter LMQT/LLQT, which shorten the leave
latencies. latencies.
Furthermore, if operators are confident that their link is fairly Furthermore, if operators are confident that their link is fairly
robust (e.g., the [Robustness Variable] value is appropriately robust (e.g., the [Robustness Variable] value is appropriately
configured so that the chances of unsolicited messages being lost are configured so that the chances of unsolicited messages being lost are
sufficiently low), and if the querier router always acts as the sufficiently low), and if the querier router always acts as the
forwarder router for all multicast channels in the LAN, they will set forwarder router for all multicast channels in the LAN, they will set
smaller LMQC/LLQC and shorter LMQI/LLQI (and hence shorter LMQT/LLQT) smaller LMQC/LLQC and shorter LMQI/LLQI (and hence shorter LMQT/LLQT)
with the specific query suppression, or enable the specific query with the specific query suppression, or enable the specific query
suppression in a robust link state (Section 4) for their routers. suppression with a robust link state (Section 4) for their routers.
Note that setting smaller LMQC/LLQC values or adopting the specific Note that setting smaller LMQC/LLQC and shorter LMQI/LLQI values or
query suppression in a robust link state poses the risk of wrong adopting the specific query suppression with a robust link state
membership state described in Section 6. Operators setting smaller poses the risk of wrong membership state described in Section 6.
LMQC/LLQC values must recognize this tradeoff. Operators setting these values or enabling that mechanism must
recognize this tradeoff.
6. Risk of Wrong Membership State 6. Risk of Wrong Membership State
There are possibilities that a router's membership expectation is There are possibilities that a router's membership expectation is
inconsistent due to an outdated membership state. For example, (1) a inconsistent due to an outdated membership state. For example, (1) a
router expects that more than one corresponding member host exists on router expects that more than one corresponding member host exists on
its LAN, but in fact no member host exists for that multicast its LAN, but in fact no member host exists for that multicast
channel, or (2) a router expects that no corresponding member host channel, or (2) a router expects that no corresponding member host
exists on its LAN, but in fact one or more than one member host exists on its LAN, but in fact one or more than one member host
exists for that multicast channel. exists for that multicast channel.
skipping to change at page 8, line 49 skipping to change at page 9, line 27
query (than the current compatibility mode) is heard or when certain query (than the current compatibility mode) is heard or when certain
timer conditions occur. The routers can hence support downstream timer conditions occur. The routers can hence support downstream
hosts that are not upgraded to the latest versions and run membership hosts that are not upgraded to the latest versions and run membership
report suppression. report suppression.
Therefore, if a multicast router supporting IGMPv3/MLDv2 and enabling Therefore, if a multicast router supporting IGMPv3/MLDv2 and enabling
the explicit tracking function changes its compatibility mode to the the explicit tracking function changes its compatibility mode to the
older versions, the router SHOULD disable the explicit tracking older versions, the router SHOULD disable the explicit tracking
function while it acts as the older version router. function while it acts as the older version router.
9. IANA Considerations 9. Interoperability
There might be various ways to implement the explicit tracking
function. Some existing implementations may not implement the
mechanisms such as specific query suppression described in this
document. Yet, the explicit tracking function does not change on-
wire behavior, and the function or mechanisms described in this
document do not break the interoperability between the existing
implementations and the implementation based on this specification.
On the other hand, for the future implementation for the explicit
tracking function, since this document specifies the minimum but
effective sets of the explicit tracking function, it is RECOMMENDED
to refer and follow this specification as the standard implementation
for that function.
10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
10. Security Considerations 11. 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. It gives some memory so that routers keep all membership states. It gives some
impact in the cases where (1) a router attaches to a link or an IGMP/ impact in the cases where (1) a router attaches to a link or an IGMP/
MLD proxy device [8] that has a large number of member hosts, and a MLD proxy device [8] that has a large number of member hosts, and a
router has insufficient memory resources to maintain a large number router has insufficient memory resources to maintain a large number
of member hosts, or (2) a malicious host sends a large number of of member hosts, or (2) a malicious host sends a large number of
invalid IGMP/MLD report messages. invalid IGMP/MLD State-Change Report messages without any intent to
join the specified channels.
For the first case, operators may disable the explicit tracking For the first case, operators may disable the explicit tracking
function, despite the benefits mentioned above. For the second case, function, despite the benefits mentioned above. For the second case,
some serious threats may be induced. In order to prevent abuse, a some serious threats may be induced. For instance;
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.
A router may rate-limit State-Change Report messages per host. When 1. Transmitting a large number of invalid IGMP/MLD report messages
the router enables rate-limiting per host, the router MAY ignore the consumes network resources.
received State-Change Report messages to minimize the processing
overhead or prevent DoS attacks. The rate limit is left to the
router's implementation.
11. Acknowledgements 2. Keeping a large number of invalid membership states on a router
consumes the router's memory resources.
Luis M. Contreras, Toerless Eckert, Sergio Figueiredo, Bharat Joshi, 3. Dealing with a large number of invalid membership states on a
Nicolai Leymann, Stig Venaas, and others provided many constructive router consumes the router's CPU resources.
and insightful comments.
12. References In order to mitigate such threats, a router enabling the explicit
tracking function may limit a total amount of membership information
the router can store, or may rate-limit State-Change Report messages
per host. When 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.
12.1. Normative References 12. Acknowledgements
Luis M. Contreras, Toerless Eckert, Adrian Farrel, Sergio
Figueiredo, Bharat Joshi, Nicolai Leymann, Magnus Nystrom, Alvaro
Retana, Stig Venaas, and others provided many constructive and
insightful comments.
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate [1] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997. requirement levels", RFC 2119, March 1997.
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[3] Vida, R. and L. Costa, "Multicast Listener Discovery [3] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
February 2010. February 2010.
12.2. Informative References 13.2. Informative References
[5] Deering, S., "Host Extensions for IP Multicasting", RFC [5] Deering, S., "Host Extensions for IP Multicasting",
1112, August 1989. RFC 1112, August 1989.
[6] Fenner, W., "Internet Group Management Protocol, Version [6] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2373, July 1997. 2", RFC 2236, November 1997.
[7] Deering, S., Fenner, W., and B. Haberman, "Multicast [7] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October Listener Discovery (MLD) for IPv6", RFC 2710, October
1999. 1999.
[8] Fenner, B., He, H., Haberman, B., and H. Sandick, [8] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP Listener Discovery (MLD)-Based Multicast Forwarding
/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006.
Author's Address Author's Address
Hitoshi Asaeda Hitoshi Asaeda
National Institute of Information and Communications Technology National Institute of Information and Communications Technology
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. 39 change blocks. 
114 lines changed or deleted 177 lines changed or added

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