draft-ietf-pim-explicit-tracking-08.txt   draft-ietf-pim-explicit-tracking-09.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: Standards Track December 3, 2013
Expires: April 10, 2014 Expires: June 6, 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-08 draft-ietf-pim-explicit-tracking-09
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 June 6, 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Membership State Information . . . . . . . . . . . . . . . . 4 3. Membership State Information . . . . . . . . . . . . . . . . 4
4. Specific Query Suppression . . . . . . . . . . . . . . . . . 4 4. Specific Query Suppression . . . . . . . . . . . . . . . . . 4
5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6
6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 7 6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 6
7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7 7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7
8. Compatibility with Older Version Protocols . . . . . . . . . 8 8. Compatibility with Older Version Protocols . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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 Also, a querier router periodically sends IGMP/MLD General Query
messages every General Query timer interval (i.e. [Query Interval] messages every General Query timer interval (i.e. [Query Interval]
value defined in [2][3]). Upon receiving the query messages, the value defined in [2][3]). Upon receiving the query messages, the
member hosts reply with "solicited" report messages. Routers then member hosts reply with "solicited" report messages. Routers then
keep their membership state information up to date. However, this keep their membership state information up to date. However, this
approach still does not guarantee that the membership state is always approach still does not guarantee that the membership state is always
perfectly synchronized. To minimize the possibility of having perfectly synchronized. To minimize the possibility of having
outdated membership information, routers may shorten the periodic outdated membership information, routers may shorten the periodic
General Query timer interval. Unfortunately, this increases the General Query timer interval. Unfortunately, this increases the
skipping to change at page 4, line 4 skipping to change at page 4, line 4
resource requirement might be sensitive. Operators may decide to resource requirement might be sensitive. 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 [2] and MLDv2 [3], and their lightweight by the standard IGMPv3 [2] and MLDv2 [3], and their lightweight
version protocols [4]; 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",
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC 2119 [1]. 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 "Null" 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
skipping to change at page 9, line 13 skipping to change at page 8, line 49
This document has no actions for IANA. This document has no actions for IANA.
10. 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. 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 2. Keeping a large number of invalid membership states on a router
router's implementation. consumes the router's memory resources.
3. Dealing with a large number of invalid membership states on a
router consumes the router's CPU and memory resources.
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.
11. Acknowledgements 11. Acknowledgements
Luis M. Contreras, Toerless Eckert, Sergio Figueiredo, Bharat Joshi, Luis M. Contreras, Toerless Eckert, Sergio Figueiredo, Bharat Joshi,
Nicolai Leymann, Stig Venaas, and others provided many constructive Nicolai Leymann, Magnus Nystrom, Stig Venaas, and others provided
and insightful comments. many constructive and insightful comments.
12. References 12. References
12.1. Normative References 12.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
skipping to change at page 10, line 11 skipping to change at page 10, line 9
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 12.2. Informative References
[5] Deering, S., "Host Extensions for IP Multicasting", RFC [5] Deering, S., "Host Extensions for IP Multicasting", RFC
1112, August 1989. 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 ("IGMP
/MLD Proxying")", RFC 4605, August 2006. /MLD Proxying")", RFC 4605, August 2006.
 End of changes. 14 change blocks. 
27 lines changed or deleted 37 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/