idnits 2.17.1 draft-anggawijaya-pim-resilient-gmp-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 3. If a multicast listener sends a group membership report message with an unspecified source IP address, it MUST not send the reports with the R-flag set. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 3. If a multicast listener sends a membership report message with an unspecified source IPv6 address (::), it MUST not send the reports with the R-flag set. -- The document date (February 23, 2016) is 2977 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) -- Looks like a reference, but probably isn't: '1' on line 588 -- Looks like a reference, but probably isn't: '2' on line 596 == Missing Reference: 'M' is mentioned on line 549, but not defined == Missing Reference: 'N' is mentioned on line 607, but not defined == Unused Reference: 'RFC2119' is defined on line 785, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group Hermin Anggawijaya 3 Internet-Draft Allied Telesis Labs, NZ 4 Intended status: Standards Track February 23, 2016 5 Expires: August 26, 2016 7 Improving IGMPv3 and MLDv2 Resilience 8 draft-anggawijaya-pim-resilient-gmp-01 10 Abstract 12 Host devices send IGMP or MLD group membership report messages to 13 tell the designated router (DR) which multicast groups they want to 14 receive. 15 These messages are sent repeatedly up to maximum number of times 16 determined by the 'Robustness Variable' setting. However, in certain 17 situations, those messages could get lost. 18 This draft proposes a mechanism whereby host devices attached to a 19 local area network where the querier and the DR are the same device, 20 can request the querier to acknowledge each report message it 21 receives, ensuring report messages reception by the DR. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that other 30 groups may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire in August 26, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Resilient GMP . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1 Resilient IGMP . . . . . . . . . . . . . . . . . . . . . . 7 65 3.1.1 Message Formats . . . . . . . . . . . . . . . . . . . . 7 66 3.1.2 Host Behaviour . . . . . . . . . . . . . . . . . . . . 9 67 3.1.3 Router Behaviour . . . . . . . . . . . . . . . . . . . 10 68 3.1.4 Backward Compatibility . . . . . . . . . . . . . . . . 11 69 3.2 Resilient MLD . . . . . . . . . . . . . . . . . . . . . . . 12 70 3.2.1 Message Formats . . . . . . . . . . . . . . . . . . . . 12 71 3.2.2 Host Behaviour . . . . . . . . . . . . . . . . . . . . 15 72 3.2.3 Router Behaviour . . . . . . . . . . . . . . . . . . . 16 73 3.2.4 Backward Compatibility . . . . . . . . . . . . . . . . 17 74 3.3 Operational Consideration . . . . . . . . . . . . . . . . . 17 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 4.1 IGMP Type Numbers . . . . . . . . . . . . . . . . . . . . . 17 77 4.2 ICMPv6 Type Numbers . . . . . . . . . . . . . . . . . . . . 17 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 79 5.1. On-link Query Message Forgery . . . . . . . . . . . . . . 18 80 5.2. On-link Membership Report Message Forgery . . . . . . . . 18 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 84 7.2. Informative References . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 88 IGMP and MLD, known collectively as Group Membership Protocols (GMPs) 89 are used between hosts (multicast listeners) and their designated 90 router. Hosts use these messages to tell the DR which multicast 91 groups data they wish to receive. 93 When a host wants to receive multicast data for a particular 94 multicast group, it sends a membership report message to the DR. 95 Upon receiving this message, the DR translate the message into a 96 multicast join toward the upstream multicast router using multicast 97 routing protocols, for the indicated group and the DR also maintains 98 a state of the group membership. 100 In order to confirm that hosts still want to continue receiving 101 multicast data, the GMP querier periodically sends query messages to 102 all users of the multicast group. All hosts requiring multicast data 103 are required to send membership response messages to the querier. 104 When the querier receives a membership report for a particular 105 multicast group, the corresponding membership timer is reset. 106 In a LAN with only one multicast router, the DR will be the same 107 device as the querier. In a LAN where multiple multicast routers 108 coexist, although there is no protocol requirements for the querier 109 and the DR to be on the same device, it is quite common for the 110 querier and the DR to be on the same device. In the following 111 discussion, it is assumed that the querier and the DR to be the same 112 device, and the terms querier and DR will be used interchangeably, 113 referring to the same device. 115 If the querier does not receive a membership report for a particular 116 group before the group membership timer expires, the querier will 117 delete the appropriate membership record, and the DR which maintains 118 the same membership record using the same state machine, sends a 119 multicast leave to its upstream router. 121 Early physical and link layer technologies such as 802.3 10Base-T, 122 are characterised by the possibility of frames getting lost during 123 transmission. To compensate for the possibility of frame losses, both 124 the hosts and querier are required to repeat their GMP protocol 125 message transmissions. The number of retransmissions is determined by 126 a Robustness Variable (RV) setting, which is announced by the 127 querier. The RV is configured to reflect the robustness of the 128 protocols against the perceived probability of frame loss within the 129 link. 131 Although wired link layer technology improvements have been made to 132 minimise the possibility of frame loss, the following recent 133 networking trends have tended to negate these effects: 134 The growing tendency to increase the number of devices operating 135 within a single broadcast domain, then interconnecting multiple 136 domains using either bridged (or layer two switched) links. 138 For example if a multicast listener sends a group membership report 139 toward a querier located several physical links away, and one of the 140 bridges or L2 switches in the path toward the querier is recovering 141 from a reboot and not in a forwarding state the membership report 142 message sent by the multicast listener could get lost. 143 Multicast packet losses have also been proven to be more prevalent in 144 the ubiquitous wireless (WiFi) link environments. This observation 145 is well documented, see [VYNCKE] and [MCBRIDE]. 147 In the above scenarios, if a membership report message and its 148 subsequent retransmission is lost, then the multicast listener 149 sending the message has to wait until the querier sends a general 150 query message before another message can be sent. With the default 151 GMP protocol values, this waiting period could be up to 125 seconds. 153 Diagram 1 below illustrates a scenario in which membership report 154 messages are lost between the listener and querier, causing the 155 listener to experience excessive delay in receiving multicast data. 157 Multicast listener GMP Querier 158 |----------<---general query------------------| 159 | | 160 |. . . . . . . . . . . . . . . . . . . . . . | a 161 | | 162 |------------membership report->---X | b 163 | | 164 |------------membership report->---X | T 165 | | i 166 | | m 167 |. . . . . . . . . . . . . . . . . . . . . . | c e 168 | | | 169 | | | 170 | | V 171 | | 172 | | 173 | | 174 |----------<---general query------------------| d 175 |------------membership report->--------------| 176 |----------<---multicast data-----------------| e 177 |----------<---multicast data-----------------| 178 | ... | 180 Ta-Tc - transient state period 181 Tb-Te - delay for multicast data 182 Tc-Td - 'dead' period 184 Diagram 1. Current GMP operation with transient state on querier 185 Increasing the RV value may help to alleviate the packet loss issue, 186 but this also make the protocols unnecessarily chatty in normal 187 conditions. This chattiness can have a serious impact if there are 188 lots of multicast listeners in the same broadcast domain. 190 This draft proposes a new mechanism that allows listeners to send 191 multicast membership reports that are accompanied by a marker 192 signalling the querier to acknowledge the reception of the membership 193 report message in such a way that the multicast listener is sure that 194 its membership report message has been received by the querier. And 195 that the multicast listener does not need to repeat its message 196 transmission RV number of times. However, if the group membership 197 message is lost, the multicast listener can repeat the message 198 transmission until either an acknowledgement is received, a general 199 query is received, or the number of retransmissions reaches the 200 maximum configured on the listener. 202 2. Terminology 204 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 205 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 206 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 207 indicate requirement levels for compliant BIDIR-PIM implementations. 209 3. Resilient GMP 211 To make GMP more resilient, multicast listeners are allowed to keep 212 sending group membership reports until an acknowledgement of the 213 report is received from the querier. This mechanism is different to 214 the original GMP specifications in that it allows a more robust 215 delivery of membership report messages, and contains less protocol 216 chatter if the link does not suffer from frame losses, i.e. the 217 multicast listener will not unnecessarily retransmit the membership 218 report messages. 220 Diagram 2 below illustrates the behaviour of multicast listener and 221 querier adhering to the mechanism proposed in this draft. 223 Multicast listener GMP Querier 224 |----------<---general query------------------| 225 | | 226 |. . . . . . . . . . . . . . . . . . . . . . | a 227 | | 228 |------------membership report->---X | b 229 | | 230 |------------membership report->---X | T 231 | .... | i 232 | .... | m 233 |------------membership report->---X | e 234 |. . . . . . . . . . . . . . . . . . . . . . | c | 235 |------------membership report->--------------| | 236 |----------<---report acknowledge-------------| V 237 |----------<---multicast data-----------------| d 238 |----------<---multicast data-----------------| 239 | ... | 241 Ta-Tc - transient state period 242 Tb-Td - delay for multicast data 244 Diagram 2. Resilient GMP operation with transient state on querier 246 In order to apply this mechanism, a new message format is required 247 that includes a flag to enable multicast listeners to request an 248 acknowledgement from the querier. This message format is defined in 249 the next section. 251 The new behaviour as specified by this draft is disabled by default 252 and must be enabled explicitly by the network operator. 254 3.1. Resilient IGMP 256 3.1.1. Message Formats 258 IGMPv3 Membership Report 260 0 1 2 3 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type = 0x22 | Reserved |R| Checksum | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Reserved | Number of Group Records (M) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 . . 269 . Group Record [1] . 270 . . 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 . . 275 . Group Record [2] . 276 . . 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | . | 280 . . . 281 | . | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 . . 285 . Group Record [M] . 286 . . 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Please see [RFC3376] for the definitions of the existing fields. 292 New flags defined in the membership report message are: 293 R: 'Request for Acknowledgement' flag. Setting this flag indicates 294 that the multicast listener sending the membership report 295 requires an acknowledgement message in reply to the 296 current membership report message. 298 IGMPv3 Membership Report Acknowledgement 300 0 1 2 3 301 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type = 0x23 | Reserved | Checksum | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Reserved | Number of Group Records (M) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 . . 309 . Group Record [1] . 310 . . 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 . . 315 . Group Record [2] . 316 . . 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | . | 320 . . . 321 | . | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 . . 325 . Group Record [M] . 326 . . 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 All the fields in the IGMPv3 Membership Report Acknowledgement 331 message have the same specifications as in IGMPv3 Membership Report 332 message, except the type code is 0x23 (to be requested to IANA). 333 The format is chosen so that it is very convenient for the DR to 334 acknowledge membership report messages by simply copying the original 335 membership report message, and modifying the copied packet with new 336 IP source and destination addresses, IGMP packet type, and 337 recalculating both IP and IGMP checksums. 339 The membership report acknowledgement is sent unicast to the source 340 of the original membership report message being acknowledged. 342 IGMPv3 Query 344 0 1 2 3 345 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type = 0x11 | Max Resp Code | Checksum | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Group Address | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Resv|A|S| QRV | QQIC | Number of Sources (N) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Source Address [1] | 354 +- -+ 355 | Source Address [2] | 356 +- . -+ 357 . . . 358 . . . 359 +- -+ 360 | Source Address [N] | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Please see [RFC3376] for the definitions of the existing fields. 365 The new flag defined in the IGMPv3 Query is: 367 A : 'Acknowledgement Capable Querier' flag. Setting this flag 368 indicates that the querier is capable of sending acknowledgements 369 to membership reports to multicast listeners. 371 3.1.2. Host Behaviour 373 This section describes the new behaviour of IGMP hosts implementing 374 the mechanism as specified in this draft. 376 1. By default, an implementation of IGMP adhering to this draft MUST 377 enable the new listener behaviour as specified below. And if 378 configured to do so, it MAY also fall back to operate as per 379 [RFC3376] specification. This provision also ensures that the 380 an existing IGMPv3 implementation can operate with a querier 381 implementing this draft. 383 2. A multicast listener adhering to this new specification MUST send 384 its group membership reports with the R-flag set, and A-bit clear, 385 in order to indicate its requirement that the querier acknowledges 386 its group membership reports 388 3. If a multicast listener sends a group membership report message 389 with an unspecified source IP address, it MUST not send the 390 reports with the R-flag set. 392 4. As soon as a multicast listener receives a general query with the 393 A-flag cleared, it MUST fall back to normal IGMPv3 operation as 394 per [RFC3376] specification, i.e. all its membership reports must 395 be sent with both R-flag and A-flag cleared, and it can only 396 retransmit its messages (RV-1) number of times. This ensures that 397 the new implementation of IGMP listener can inter-operate with 398 existing IGMP querier implementations. 400 5. The multicast listener MUST keep retransmitting its membership 401 report until: 402 a. It receives an acknowledgement message from the querier or 403 b. It detects that there are no querier present on the link. The 404 listener will assume this situation if it has received no 405 queries for a 'Querier Live Time' period since it transmitted 406 the original membership report message. The Querier Live Time 407 is calculated as 2.5 times the Query Interval time. 409 6. The retransmission of the group membership reports MUST be done at 410 random intervals within the range 411 (0, [Unsolicited Report Interval]). 413 7. If a multicast listener's interface state changes, the 414 retransmission of the previous membership report messages MUST 415 stop, because the state machine will send new membership report 416 messages reflecting the state change. 418 8. A multicast listener MUST process only valid acknowledgement 419 messages. Invalid messages MUST be dropped silently. A valid 420 acknowledgement message MUST obey the following rules: 421 a. The destination IP address must be equal to the IP address of 422 the receiving interface, and cannot be a multicast, broadcast 423 nor unspecified IP address. 424 b. The IGMP type is set to 0x23. 425 c. The checksum must be correct. 426 d. The listener is able to match the acknowledgement message with 427 the member report message waiting for an acknowledgement. 429 9. If a multicast listener send multicast membership reports 430 consisting only of group records indicating that the host no 431 longer wish to receive multicast data for the groups specified, 432 such as BLOCK_OLD_SOURCES record, the report MAY be sent without 433 the R-bit set. Note that by doing this, if the report is dropped 434 then the DR will not send multicast leave to its upstream router 435 and may result in unnecessary multicast data forwarding. 437 3.1.3. Router Behaviour 439 This section describes the new behaviour of IGMP routers implementing 440 the mechanism as specified in this draft. 442 1. By default, a querier adhering to this draft MUST send queries 443 with the A-flag set. The implementation SHOULD also enable 444 operators to turn the new behaviour off administratively. 446 2. If a querier receives a membership report message it MUST perform 447 the same report message validation as specified in [RFC3376], i.e. 448 that all invalid report messages MUST be silently discarded. And 449 in addition, it MUST also perform the following checks: 450 a. If the R-flag is set, check that the source IP address is not 451 the unspecified IP address (0.0.0.0). 453 3. If a querier receives a valid membership report message with the 454 R-flag set, it MUST send an acknowledgement by transmitting an 455 acknowledgement packet whose content is the same as the membership 456 report message, with the following modifications: 457 a. The source IP address MUST be set to the that of the receiving 458 interface. 459 b. The destination IP address MUST be set to the source IP address 460 contained in the original message. 461 c. The IP checksum is recalculated. 462 d. The IGMP packet type is set to 0x23 (to be assigned by IANA). 463 e. The IGMP checksum is recalculated. 465 4. If a querier receives a valid membership report message with the 466 R-flag cleared, then it will just process the report message as 467 per [RFC3376] specification. 469 5. When a querier sends a query, it MUST set the A flag, unless it is 470 configured not to do so by the administrator. 472 3.1.4. Backward Compatibility 474 To maintain compatibility with older version of IGMP implementations, 475 both the listener and querier MUST fall back to the operation as per 476 [RFC3376] specification, when the presence of older IGMP 477 implementation is detected on the same network. 479 3.2. Resilient MLD 481 3.2.1. Message Formats 483 MLDv2 Membership Report 485 0 1 2 3 486 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Type = 143 | Reserved |R| Checksum | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Reserved |Nr of Mcast Address Records (M)| 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | | 493 . . 494 . Multicast Address Record [1] . 495 . . 496 | | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | | 499 . . 500 . Multicast Address Record [2] . 501 . . 502 | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | . | 505 . . . 506 | . | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | 509 . . 510 . Multicast Address Record [M] . 511 . . 512 | | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Please see [RFC3810] for the definitions of the existing fields. 517 The new flags defined in the membership report message are: 518 R: 'Request for Acknowledgement' flag. Setting this flag indicates 519 that the multicast listener sending the membership report requires 520 an acknowledgement message in reply to the current membership 521 report message. 523 MLDv2 Membership Report Acknowledgement 524 0 1 2 3 525 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type = 160 | Reserved |R| Checksum | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Reserved |Nr of Mcast Address Records (M)| 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | | 532 . . 533 . Multicast Address Record [1] . 534 . . 535 | | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | | 538 . . 539 . Multicast Address Record [2] . 540 . . 541 | | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | . | 544 . . . 545 | . | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | | 548 . . 549 . Multicast Address Record [M] . 550 . . 551 | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 All the fields in the MLDv2 Membership Report Acknowledgement 555 message have the same specifications as in MLDv2 Membership Report 556 message, except the type code is 160 (to be requested to IANA). 557 The format is chosen so that it is very convenient for the DR to 558 acknowledge membership report messages by simply copying the original 559 membership report message, and modifying the copied packet with new 560 IPv6 source and destination addresses, new ICMPv6 packet type, and 561 recalculating the MLDv2 checksum. 563 The membership report acknowledgement is sent unicast to the source 564 of the original membership report message being acknowledged. 566 MLDv2 Query 568 0 1 2 3 569 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type = 130 | Code | Checksum | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Maximum Response Code | Reserved |A| 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | | 576 * * 577 | | 578 * Multicast Address * 579 | | 580 * * 581 | | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Resv |S| QRV | QQIC | Number of Sources (N) | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | | 586 * * 587 | | 588 * Source Address [1] * 589 | | 590 * * 591 | | 592 +- -+ 593 | | 594 * * 595 | | 596 * Source Address [2] * 597 | | 598 * * 599 | | 600 +- . -+ 601 . . . 602 . . . 603 +- -+ 604 | | 605 * * 606 | | 607 * Source Address [N] * 608 | | 609 * * 610 | | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Please see [RFC3810] for the definitions of the existing fields. 615 The new flag defined in MLDv2 Query is: 616 A : 'Acknowledgement Capable Querier' flag. Setting this flag 617 indicates that this querier is capable of sending an 618 acknowledgement to membership reports toward multicast listeners. 620 3.2.2. Host Behaviour 621 This section describes the new behaviour of MLD hosts implementing 622 the mechanism as specified in this draft. 624 1. By default, an implementation of MLD adhering to this draft MUST 625 enable the new listener behaviour as specified below. And if 626 configured to do so, it MAY also fall back to operate as per 627 [RFC3810] specification. This also ensures that existing MLDv2 628 implementations can inter-operate with queriers implementing this 629 draft. 631 2. A multicast listener adhering to this new specification MUST send 632 a group membership reports with the R-flag set, and the A-bit 633 clear, indicating its wish that the querier acknowledges the 634 listener's group membership reports. 636 3. If a multicast listener sends a membership report message with 637 an unspecified source IPv6 address (::), it MUST not send the 638 reports with the R-flag set. 640 4. As soon as a multicast listener receives a general query with the 641 A-flag cleared, it MUST fall back to normal MLDv2 operation as per 642 [RFC3810] specification, i.e. all its membership reports must be 643 sent with both R-flag and A-flag cleared, and it can only 644 retransmit its messages (RV-1) number of times. This ensures that 645 the new implementation of MLD listener can inter-operate with 646 existing MLD querier implementations. 648 5. The multicast listener MUST keep retransmitting the membership 649 report until: 650 a. It receives an acknowledgement message from the querier or 651 b. It detects that there are no querier present on the link. The 652 listener will assume this situation if it has receives no 653 queries for 'Querier Live Time' period since it transmitted the 654 original membership report message. The Querier Live Time is 655 calculated as 2.5 times the Query Interval time. 657 6. The retransmission of the group membership reports MUST be done at 658 random intervals within the range 659 (0, [Unsolicited Report Interval]). 661 7. If a multicast listener's interface state changes, retransmission 662 of the previous membership report message MUST stop, because the 663 state machine will send a new membership report message reflecting 664 the state change. 666 8. A multicast listener MUST process only valid acknowledgement 667 messages. Invalid messages MUST be dropped silently. A valid 668 acknowledgement message MUST obey the following rules: 669 a. The destination IPv6 address MUST be equal to the IPv6 address 670 of the receiving interface, and MUST NOT be a multicast, 671 broadcast nor the unspecified IPv6 address (::). 672 b. The ICMPv6 packet type is set to 160. 673 c. The checksum must be correct. 674 d. The listener is able to match the acknowledgement message with 675 the member report message waiting for an acknowledgement. 677 9. If a multicast listener send multicast membership reports 678 consisting only of group records indicating that the host no 679 longer wish to receive multicast data for the groups specified, 680 such as BLOCK_OLD_SOURCES record, the report MAY be sent without 681 the R-bit set. Note that by doing this, if the report is dropped 682 then the DR will not send multicast leave to its upstream router 683 and may result in unnecessary multicast data forwarding. 685 3.2.3. Router Behaviour 686 This section describes the new behaviour of MLD routers implementing 687 the mechanism as specified in this draft. 689 1. By default, querier implementation adhering to this draft MUST 690 send queries with the A-flag set. The implementation SHOULD also 691 enable operators to turn the new behaviour off administratively. 693 2. If a querier receives a membership report message it MUST perform 694 the same report message validation as specified in [RFC3810]. All 695 invalid report messages MUST be silently discarded. It MUST also 696 do the following checks: 697 a. Ensure that the A-flag is clear. 698 b. Check that if the R-flag is set, the source IPv6 address is not 699 the unspecified IPv6 address (::). 701 3. If a querier receives a valid membership report message with the 702 R-flag set, it MUST send an acknowledgement by transmitting an 703 acknowledgement packet whose content is the same as the membership 704 report message, with the following modifications: 705 a. The source IPv6 address MUST be set to the that of the 706 receiving interface. 707 b. The destination IPv6 address MUST be set to the source IPv6 708 address contained in the original message. 709 d. The ICMPv6 packet type is set to 160 (to be requested to IANA). 710 e. The MLDv2 checksum is recalculated. 712 4. If a querier receives a valid membership report message with the 713 R-flag unset, then it will process the report message as per 714 [RFC3810] specification. 716 5. When a querier sends a query, it MUST set the A-flag, unless it is 717 configured not to do so by the administrator. 719 3.2.4. Backward Compatibility 720 To maintain compatibility with older version of MLD implementations, 721 both the listener and querier MUST fall back to the operation as per 722 [RFC3810] specification, when the presence of older MLD 723 implementation is detected on the same network. 725 3.3 Operational Consideration 726 If there are more than one multicast routers running IGMP/MLD in a 727 LAN, it is advisable to have all the routers configured with the 728 same setting for the 'Acknowledgement Capable Querier' flag to avoid 729 temporary confusion on hosts as to whether they are allowed to send 730 report messages with the R-flag set or not, during querier election 731 time. 733 4. IANA Considerations 735 4.1. IGMP Type Numbers 737 Author of this document requests the following IGMP Type Number: 739 IGMPv3 Packet Type Value 740 ------------------------------------------ ----- 741 IGMPv3 Membership Report Acknowledegement 0x23 743 4.2. ICMPv6 Type Numbers 745 Author of this document requests the following ICMPv6 Type Number: 747 ICMPv6 Packet Type Value 748 ------------------------------------------ ----- 749 MLDv2 Membership Report Acknowledegement 160 751 5. Security Considerations 752 The original specification of both IGMPv3 and MLDv2 have some defense 753 capability against forged messages originated off-link. 755 5.1. On-link Query Message Forgery 756 Apart from the threats described in both [RFC3376] and [RFC3810], 757 extra threat exists in the form of forged query messages with the 758 A-flag set, while the actual querier does not send queries with 759 the A-flag set. This would make all listeners adhering to the 760 mechanism proposed in this draft, keep sending extra retransmissions 761 of the report messages without receiving acknowledgement from the 762 querier) until they see the query with the A-flag cleared from the 763 forged querier. To mitigate this attack, listener implementations 764 might generate a log message if queries it receives from the same 765 querier seem to have variable setting for the A-flag. 767 5.2. On-link Membership Report Message Forgery 768 When a querier is configured to run the new implementation as 769 specified in this draft, additional threats exist to those described 770 in [RFC3376] and [RFC3810]. These extra threats exist in the form of 771 forged membership report messages with the R-flag being set. This 772 will make the querier unnecessarily send acknowledgements to the 773 forged listener. However this attack is mitigated by the fact that 774 the original listener will drop these messages since it does not 775 expect to receive acknowledgement messages. 777 6. Acknowledgements 778 A special thank you goes to Stig Venaas for providing very valuable 779 feedback and review on this document. 781 7. References 783 7.1. Normative References 785 [RFC2119] Bradner, S., "Key words for use in RFCs to 786 Indicate Requirement Levels", BCP 14, RFC 2119, 787 March 1997. 789 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and 790 A. Thyagarajan, "Internet Group Management Protocol, 791 Version 3", RFC 3376, October 2002. 793 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 794 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 796 7.2. Informative References 798 [VYNCKE] E. Vyncke , P. Thubert , E. Levy-Abegnoli , 799 A. Yourtchenko, "Why Network-Layer Multicast is Not 800 Always Efficient At Datalink Layer", 801 draft-vyncke-6man-mcast-not-efficient, February 802 2014. 804 [MCBRIDE] M. McBride, C. Perkins, "Multicast Wifi Problem 805 Statement", 806 draft-mcbride-mboned-wifi-mcast-problem-statement, 807 July, 2015. 809 Authors' Address 811 Hermin Anggawijaya 812 Allied Telesis Labs NZ, Ltd 813 27 Nazareth Ave 814 Christchurch 8024 815 New Zealand 817 Email: hermin.anggawijaya@alliedtelesis.co.nz