idnits 2.17.1 draft-ietf-pim-explicit-tracking-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3307 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group H. Asaeda 3 Internet-Draft NICT 4 Intended status: Standards Track March 9, 2015 5 Expires: September 10, 2015 7 IGMP/MLD-Based Explicit Membership Tracking Function for Multicast 8 Routers 9 draft-ietf-pim-explicit-tracking-11 11 Abstract 13 This document describes the IGMP/MLD-based explicit membership 14 tracking function for multicast routers and IGMP/MLD proxy devices 15 supporting IGMPv3/MLDv2. The explicit membership tracking function 16 contributes to saving network resources and shortening leave latency. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 10, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Membership State Information . . . . . . . . . . . . . . . . 4 55 4. Specific Query Suppression . . . . . . . . . . . . . . . . . 5 56 5. Shortening Leave Latency . . . . . . . . . . . . . . . . . . 6 57 6. Risk of Wrong Membership State . . . . . . . . . . . . . . . 7 58 7. All-Zero and Unspecified Source Addresses . . . . . . . . . . 7 59 8. Compatibility with Older Version Protocols . . . . . . . . . 8 60 9. Interoperability . . . . . . . . . . . . . . . . . . . . . . 8 61 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 64 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 13.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 The Internet Group Management Protocol (IGMP) version 3 [2] for IPv4 72 and the Multicast Listener Discovery Protocol (MLD) version 2 [3] for 73 IPv6 are the standard protocols used by member hosts and multicast 74 routers. Lightweight IGMPv3 and Lightweight MLDv2 (or LW-IGMPv3 and 75 LW-MLDv2) [4] are subsets of the standard IGMPv3 and MLDv2. 77 When a host starts/finishes listening to particular multicast 78 channels, it sends IGMP/MLD State-Change Report messages specifying 79 the corresponding channel information as the join/leave request to 80 its upstream router (i.e., an adjacent multicast router or IGMP/MLD 81 proxy device [8]). The "unsolicited" report messages are sent only 82 when the host joins/leaves the channels. Since IGMP/MLD are non- 83 reliable protocols, unsolicited report messages may be lost or may 84 not reach upstream routers. To alleviate this problem, unsolicited 85 report messages are retransmitted a number of times according to the 86 value of the [Robustness Variable] defined in [2][3]. 88 In addition, a querier router periodically sends IGMP/MLD General 89 Query messages every General Query timer interval (i.e. [Query 90 Interval] value defined in [2][3]). Upon receiving the query 91 messages, the member hosts reply with "solicited" report messages. 92 Routers then keep their membership state information up to date. 93 However, this approach still does not guarantee that the membership 94 state is always perfectly synchronized. To minimize the possibility 95 of having outdated membership information, routers may shorten the 96 periodic General Query timer interval. Unfortunately, this increases 97 the number of transmitted solicited report messages and induces 98 network congestion. And the greater the amount of network 99 congestion, the greater the potential for IGMP/MLD report messages 100 being lost and the membership state information being outdated in the 101 router. 103 IGMPv3 [2], MLDv2 [3], and these lightweight protocols [4] can 104 provide the ability to keep track of the downstream (adjacent) 105 multicast membership state in multicast routers, yet the 106 specifications are not clearly given. This document describes the 107 "IGMP/MLD-based explicit member tracking function" for multicast 108 routers and a way for routers to implement the function. By enabling 109 this explicit tracking function, routers can keep track of the 110 downstream multicast membership state. 112 The explicit tracking function is important for the scalability of 113 multicast networks, and might be widely implemented in modern 114 multicast routers. However, it could seriously break IGMP/MLD 115 communications if not implemented or configured correctly. For 116 example, the explicit tracking function is useful for shortening 117 leave latency, while wrong implementations or configurations in 118 routers on a LAN may not work properly that the operators expect. 120 This document aims to get the explicit tracking function correctly. 121 Regarding the way for shortening leave latency, it specifies the way 122 to do it by tuning the values used by IGMPv3 [2], MLDv2 [3], and 123 their lightweight version protocols [4], or by enabling the mechanism 124 called "specific query suppression" with a robust link state. The 125 latter mechanism does not make the router send any specific query 126 message(s) and immediately leave the group or sources when the sole 127 member has left according to its membership state information. 129 This document describes the risk of having wrong membership state as 130 well. The explicit tracking function does not change the reliability 131 of the message transmission. The list of tracked member hosts may be 132 outdated in the router because of host departure from the network 133 without sending State-Change Report messages or loss of such messages 134 due to network congestion. This document guides for setting up 135 appropriate values or mechanisms used with the explicit tracking 136 function in routers. 138 The explicit tracking function potentially requires a large amount of 139 memory so that routers keep all membership states. Particularly when 140 a router needs to maintain a large number of member hosts, this 141 resource requirement might be sensitive. As the security 142 consideration, this document describes that operators may decide to 143 disable this function when their routers have insufficient memory 144 resources, despite the benefits. 146 The explicit tracking function does not change message formats used 147 by IGMPv3 [2], MLDv2 [3], and their lightweight version protocols 148 [4]; nor does it change a multicast data sender's and receiver's 149 behavior. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [1]. 157 3. Membership State Information 159 A router enabling the explicit tracking function maintains the 160 "membership state information". When a multicast router receives a 161 Current-State or State-Change Report message, it creates or modifies 162 this membership state information to maintain the membership state up 163 to date. 165 The membership state information consists of the following 166 information: 168 (S, G, number of receivers, (receiver records)) 170 where "S" denotes source address, "G" denotes group or multicast 171 address, and each receiver record is of the form: 173 (IGMP/MLD membership/listener report sender's address) 175 In the state information, each S and G indicates a single IPv4/IPv6 176 address. S is set to "All sources" for Any-Source Multicast (ASM) 177 communication (i.e., (*,G) join reception). In order to simplify the 178 implementation, Lightweight-IGMPv3/MLDv2 [4] do not keep the state of 179 (S,G) joined with EXCLUDE filter mode; if a router receives an (S,G) 180 join/leave request with EXCLUDE filter mode from the downstream 181 hosts, the router translates the request to a (*,G) join state/leave 182 request and records the state and the receivers' addresses in the 183 maintained membership state information. 185 The membership state information must be identified properly even 186 though a receiver (i.e., IGMP/MLD Report sender) sends the identical 187 report messages multiple times. And the maintained membership state 188 information will be flushed when the router reboots or restarts the 189 multicast routing processes. 191 4. Specific Query Suppression 193 In accordance with [2] and [3], when a router receives the State- 194 Change Report and needs to confirm whether any hosts are still 195 interested in a channel or not, the router sends the corresponding 196 Group-Specific or Group-and-Source Specific Query messages as defined 197 in Section 6.4.2 of [2] and Section 7.4.2 of [3]. The queries sent 198 by actions defined in these sections need to be transmitted [Last 199 Member Query Count] (LMQC) or [Last Listener Query Count] (LLQC) 200 times, once every [Last Member Query Interval] (LMQI) or [Last 201 Listener Query Interval] (LLQI), in order to confirm the sole member. 202 (The default values for LMQI/LLQI defined in [2][3] are 1 second. 203 The default values for LMQC/LLQC are the [Robustness Variable] value 204 whose default value is 2.) All member hosts joining the identical 205 channel then reply with their own states after acquiring these query 206 messages. However, transmitting a large number of IGMP/MLD Report 207 messages consumes network resources, and this may pose a particular 208 problem especially when many hosts joining the identical channel send 209 these reports simultaneously. 211 The explicit tracking function provides a mechanism called "specific 212 query suppression". With the specific query suppression, regardless 213 of the LMQC/LLQC values, if the router receives one or more replies 214 from the downstream member(s), it SHOULD stop (i.e., cancel) 215 retransmitting the specific query message(s) for the specified source 216 and/or group. It reduces the number of Group-Specific or Group-and- 217 Source Specific Query messages transmitted from a router, and in turn 218 reduces the number of Current-State Report messages transmitted from 219 member hosts. This contributes to saving network resources. 221 The specific query suppression MAY define an option called "robust 222 link state". A router enabling the specific query suppression with a 223 robust link state does not send any specific query message(s) and 224 immediately leave the group or sources when the sole member has left 225 according to its membership state information. The specific query 226 suppression with a robust link state hence does not rely on LMQC/LLQC 227 and LMQI/LLQI values. This contributes to shortening leave latency 228 described in Section 5. However, this behavior requires that the 229 router perfectly tracks all member hosts. (See a risk of wrong 230 membership expectation described in Section 6.) 232 Note that the default behavior of the router that supports the 233 explicit tracking function SHOULD disable this specific query 234 suppression, in order to avoid the risk caused by the wrong 235 membership expectation or by the case in which multiple multicast 236 routers exist on a LAN and the querier router is not the forwarder 237 router. The former case is described in Section 6. For the latter 238 case, when the querier suppresses the specific query message 239 transmission, and expects that the State-Change Report sender is not 240 the sole member of the channel, it does not send the specific query. 241 Then the routers (including the forwarder) on the same LAN do not 242 receive a Current-State Report message from the corresponding member 243 hosts. The forwarder in this case may prune the routing path, 244 although there are other member hosts subscribing to the channel on 245 the LAN. 247 5. Shortening Leave Latency 249 A router enabling the explicit tracking function can shorten leave 250 latencies by tuning the following values; [Last Member Query Count] 251 (LMQC), [Last Listener Query Count] (LLQC), [Last Member Query 252 Interval] (LMQI), [Last Listener Query Interval] (LLQI), and 253 [Robustness Variable] values. 255 The [Last Member Query Interval] (LMQI) and [Last Listener Query 256 Interval] (LLQI) values defined in the standard specifications [2][3] 257 specify the maximum time allowed for a member host to send a 258 responding Report. The [Last Member Query Count] (LMQC) and [Last 259 Listener Query Count] (LLQC) are the number of Group-Specific Queries 260 or Group-and-Source Specific Queries sent before the router assumes 261 there are no local members. The [Last Member Query Time] (LMQT) and 262 [Last Listener Query Time] (LLQT) values are the total time the 263 router should wait for a report after the Querier has sent the first 264 query. 266 The default values for LMQI/LLQI defined in [2][3] are 1 second, yet, 267 for a router enabling the explicit tracking function, the LMQI/LLQI 268 may be set to 1 second or shorter. As well, the default values for 269 LMQC/LLQC are the [Robustness Variable] value whose default value is 270 2, yet the LMQC/LLQC may be set to 1 for the router. Smaller LMQC/ 271 LLQC values give shorter LMQT/LLQT, which shorten the leave 272 latencies. 274 Furthermore, if operators are confident that their link is fairly 275 robust (e.g., the [Robustness Variable] value is appropriately 276 configured so that the chances of unsolicited messages being lost are 277 sufficiently low), and if the querier router always acts as the 278 forwarder router for all multicast channels in the LAN, they will set 279 smaller LMQC/LLQC and shorter LMQI/LLQI (and hence shorter LMQT/LLQT) 280 with the specific query suppression, or enable the specific query 281 suppression with a robust link state (Section 4) for their routers. 283 Note that setting smaller LMQC/LLQC and shorter LMQI/LLQI values or 284 adopting the specific query suppression with a robust link state 285 poses the risk of wrong membership state described in Section 6. 287 Operators setting these values or enabling that mechanism must 288 recognize this tradeoff. 290 6. Risk of Wrong Membership State 292 There are possibilities that a router's membership expectation is 293 inconsistent due to an outdated membership state. For example, (1) a 294 router expects that more than one corresponding member host exists on 295 its LAN, but in fact no member host exists for that multicast 296 channel, or (2) a router expects that no corresponding member host 297 exists on its LAN, but in fact one or more than one member host 298 exists for that multicast channel. 300 The first case may occur in an environment where the sole member host 301 departs the network without sending a State-Change Report message. 302 The router later detects that there is no member host for the 303 corresponding channels when it does not receive a Current-State 304 Report within the timeout of the response for the periodic General 305 Query (and then the group or source timers are expired). However, 306 this situation prolongs leave latency and wastes network resources 307 since the router forwards unneeded traffic for a while. 309 The second case occurs when a router sends a specific query but does 310 not receive a Current-State Report from a downstream host within an 311 LMQT or LLQT period. It recognizes that no member host exists on the 312 LAN and might prune the routing path. The router reestablishes the 313 routing path when it receives the solicited report message for the 314 channels. However, the downstream hosts may loose the data packets 315 until the routing path is reestablished and the data forwarding is 316 restarted. 318 If operators do not believe that their link is fairly robust or that 319 they can configure the [Robustness Variable] value appropriately, 320 they may configure the LMQC/LLQC value to 2 (the default value of the 321 [Robustness Variable] value) or bigger value for their routers. In 322 this case, the routers would enable the explicit tracking function 323 but may want to disable the specific query suppression specified in 324 Section 4. Such configurations will not contribute to saving network 325 resources, but reduce the risk of the incorrect membership 326 expectation. 328 7. All-Zero and Unspecified Source Addresses 330 The IGMPv3 specification [2] mentions that an IGMPv3 report is 331 usually sent with a valid IP source address, yet it permits a host to 332 use the 0.0.0.0 source address (since the host has not yet acquired 333 an IP address), and routers must accept a report with this source 334 address. 336 When a router enabling the explicit tracking function receives IGMP 337 report messages with an all-zero source address, it deals with the 338 IGMP report messages correctly as defined in [2] and continuously 339 keeps track of the membership state. However, the router SHOULD NOT 340 maintain the host specifying all-zero source address in its 341 membership state information. The router will maintain its 342 membership state information by checking Current-State reports as 343 ordinary routers do. 345 On the other hand, the MLDv2 specification [3] mentions that routers 346 silently discard a message that is sent with an invalid link-local 347 address or sent with the unspecified address (::), without taking any 348 action, because of security considerations. According to this 349 specification, whether the explicit tracking function is used or not, 350 a router does not deal with a member hosts sending an MLD report 351 message with the unspecified source address. 353 8. Compatibility with Older Version Protocols 355 The explicit tracking function does not work with older versions of 356 IGMP or MLD, IGMPv1 [5], IGMPv2 [6], or MLDv1 [7], because a member 357 host using these protocols enables "membership report suppression" by 358 which the host will cancel sending pending membership reports if a 359 similar report is observed from another member on the network. 361 To preserve compatibility with older versions of IGMP/MLD, routers 362 supporting IGMPv3/MLDv2 enable the host compatibility mode defined in 363 [2][3]. The host compatibility mode of an interface changes the 364 operational protocol version on the LAN whenever an older version 365 query (than the current compatibility mode) is heard or when certain 366 timer conditions occur. The routers can hence support downstream 367 hosts that are not upgraded to the latest versions and run membership 368 report suppression. 370 Therefore, if a multicast router supporting IGMPv3/MLDv2 and enabling 371 the explicit tracking function changes its compatibility mode to the 372 older versions, the router SHOULD disable the explicit tracking 373 function while it acts as the older version router. 375 9. Interoperability 377 There might be various ways to implement the explicit tracking 378 function. Some existing implementations may not implement the 379 mechanisms such as specific query suppression described in this 380 document. Yet, the explicit tracking function does not change on- 381 wire behavior, and the function or mechanisms described in this 382 document do not break the interoperability between the existing 383 implementations and the implementation based on this specification. 385 On the other hand, for the future implementation for the explicit 386 tracking function, since this document specifies the minimum but 387 effective sets of the explicit tracking function, it is RECOMMENDED 388 to refer and follow this specification as the standard implementation 389 for that function. 391 10. IANA Considerations 393 This document has no actions for IANA. 395 11. Security Considerations 397 The explicit tracking function potentially requires a large amount of 398 memory so that routers keep all membership states. It gives some 399 impact in the cases where (1) a router attaches to a link or an IGMP/ 400 MLD proxy device [8] that has a large number of member hosts, and a 401 router has insufficient memory resources to maintain a large number 402 of member hosts, or (2) a malicious host sends a large number of 403 invalid IGMP/MLD State-Change Report messages without any intent to 404 join the specified channels. 406 For the first case, operators may disable the explicit tracking 407 function, despite the benefits mentioned above. For the second case, 408 some serious threats may be induced. For instance; 410 1. Transmitting a large number of invalid IGMP/MLD report messages 411 consumes network resources. 413 2. Keeping a large number of invalid membership states on a router 414 consumes the router's memory resources. 416 3. Dealing with a large number of invalid membership states on a 417 router consumes the router's CPU resources. 419 In order to mitigate such threats, a router enabling the explicit 420 tracking function may limit a total amount of membership information 421 the router can store, or may rate-limit State-Change Report messages 422 per host. When the router enables rate-limiting per host, the router 423 MAY ignore the received State-Change Report messages to minimize the 424 processing overhead or prevent DoS attacks. The rate limit is left 425 to the router's implementation. 427 12. Acknowledgements 429 Luis M. Contreras, Toerless Eckert, Adrian Farrel, Sergio 430 Figueiredo, Bharat Joshi, Nicolai Leymann, Magnus Nystrom, Stig 431 Venaas, and others provided many constructive and insightful 432 comments. 434 13. References 436 13.1. Normative References 438 [1] Bradner, S., "Key words for use in RFCs to indicate 439 requirement levels", RFC 2119, March 1997. 441 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 442 Thyagarajan, "Internet Group Management Protocol, Version 443 3", RFC 3376, October 2002. 445 [3] Vida, R. and L. Costa, "Multicast Listener Discovery 446 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 448 [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 449 Group Management Protocol Version 3 (IGMPv3) and Multicast 450 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 451 February 2010. 453 13.2. Informative References 455 [5] Deering, S., "Host Extensions for IP Multicasting", RFC 456 1112, August 1989. 458 [6] Fenner, W., "Internet Group Management Protocol, Version 459 2", RFC 2236, November 1997. 461 [7] Deering, S., Fenner, W., and B. Haberman, "Multicast 462 Listener Discovery (MLD) for IPv6", RFC 2710, October 463 1999. 465 [8] Fenner, B., He, H., Haberman, B., and H. Sandick, 466 "Internet Group Management Protocol (IGMP) / Multicast 467 Listener Discovery (MLD)-Based Multicast Forwarding 468 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 470 Author's Address 472 Hitoshi Asaeda 473 National Institute of Information and Communications Technology 474 4-2-1 Nukui-Kitamachi 475 Koganei, Tokyo 184-8795 476 Japan 478 Email: asaeda@nict.go.jp