PIM Working Group Hermin Anggawijaya Internet-Draft Allied Telesis Labs, NZ Intended status: Standards Track October 19, 2015 Expires: April 21, 2016 Improving IGMPv3 and MLDv2 Resilience draft-anggawijaya-pim-resilient-gmp-00 Abstract Host devices send IGMP or MLD group membership report messages to tell the designated router (DR) which multicast groups they want to receive. These messages are sent repeatedly up to maximum number of times determined by the 'Robustness Variable' setting. However, in certain situations, those messages could get lost. This draft proposes a mechanism whereby host devices attached to a local area network where the querier and the DR are the same device, can request the querier to acknowledge each report message it receives, ensuring report messages reception by the DR. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire in February, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Anggawijaya April 21, 2016 [Page 1] Internet-Draft Resilient GMP October 2015 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Resilient GMP . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Resilient IGMP . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1 Message Formats . . . . . . . . . . . . . . . . . . . . 7 3.1.2 Host Behaviour . . . . . . . . . . . . . . . . . . . . 8 3.1.3 Router Behaviour . . . . . . . . . . . . . . . . . . . 9 3.1.4 Backward Compatibility . . . . . . . . . . . . . . . . 10 3.2 Resilient MLD . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 Message Formats . . . . . . . . . . . . . . . . . . . . 11 3.2.2 Host Behaviour . . . . . . . . . . . . . . . . . . . . 13 3.2.3 Router Behaviour . . . . . . . . . . . . . . . . . . . 14 3.2.4 Backward Compatibility . . . . . . . . . . . . . . . . 15 3.3 Operational Consideration . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5.1. On-link Query Message Forgery . . . . . . . . . . . . . . 15 5.2. On-link Membership Report Message Forgery . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Anggawijaya April 21, 2016 [Page 2] Internet-Draft Resilient GMP October 2015 1. Introduction IGMP and MLD, known collectively as Group Membership Protocols (GMPs) are used between hosts (multicast listeners) and their designated router. Hosts use these messages to tell the DR which multicast groups data they wish to receive. When a host wants to receive multicast data for a particular multicast group, it sends a membership report message to the DR. Upon receiving this message, the DR translate the message into a multicast join toward the upstream multicast router using multicast routing protocols, for the indicated group and the DR also maintains a state of the group membership. In order to confirm that hosts still want to continue receiving multicast data, the GMP querier periodically sends query messages to all users of the multicast group. All hosts requiring multicast data are required to send membership response messages to the querier. When the querier receives a membership report for a particular multicast group, the corresponding membership timer is reset. In a LAN with only one multicast router, the DR will be the same device as the querier. In a LAN where multiple multicast routers coexist, although there is no protocol requirements for the querier and the DR to be on the same device, it is quite common for the querier and the DR to be on the same device. In the following discussion, it is assumed that the querier and the DR to be the same device, and the terms querier and DR will be used interchangeably, referring to the same device. If the querier does not receive a membership report for a particular group before the group membership timer expires, the querier will delete the appropriate membership record, and the DR which maintains the same membership record using the same state machine, sends a multicast leave to its upstream router. Early physical and link layer technologies such as 802.3 10Base-T, are characterised by the possibility of frames getting lost during transmission. To compensate for the possibility of frame losses, both the hosts and querier are required to repeat their GMP protocol message transmissions. The number of retransmissions is determined by a Robustness Variable (RV) setting, which is announced by the querier. The RV is configured to reflect the robustness of the protocols against the perceived probability of frame loss within the link. Although wired link layer technology improvements have been made to minimise the possibility of frame loss, the following recent networking trends have tended to negate these effects: The growing tendency to increase the number of devices operating within a single broadcast domain, then interconnecting multiple domains using either bridged (or layer two switched) links. Anggawijaya April 21, 2016 [Page 3] Internet-Draft Resilient GMP October 2015 For example if a multicast listener sends a group membership report toward a querier located several physical links away, and one of the bridges or L2 switches in the path toward the querier is recovering from a reboot and not in a forwarding state the membership report message sent by the multicast listener could get lost. Multicast packet losses have also been proven to be more prevalent in the ubiquitous wireless (WiFi) link environments. This observation is well documented, see [VYNCKE] and [MCBRIDE]. In the above scenarios, if a membership report message and its subsequent retransmission is lost, then the multicast listener sending the message has to wait until the querier sends a general query message before another message can be sent. With the default GMP protocol values, this waiting period could be up to 125 seconds. Diagram 1 below illustrates a scenario in which membership report messages are lost between the listener and querier, causing the listener to experience excessive delay in receiving multicast data. Multicast listener GMP Querier |----------<---general query------------------| | | |. . . . . . . . . . . . . . . . . . . . . . | a | | |------------membership report->---X | b | | |------------membership report->---X | T | | i | | m |. . . . . . . . . . . . . . . . . . . . . . | c e | | | | | | | | V | | | | | | |----------<---general query------------------| d |------------membership report->--------------| |----------<---multicast data-----------------| e |----------<---multicast data-----------------| | ... | Ta-Tc - transient state period Tb-Te - delay for multicast data Tc-Td - 'dead' period Diagram 1. Current GMP operation with transient state on querier Anggawijaya April 21, 2016 [Page 4] Internet-Draft Resilient GMP October 2015 Increasing the RV value may help to alleviate the packet loss issue, but this also make the protocols unnecessarily chatty in normal conditions. This chattiness can have a serious impact if there are lots of multicast listeners in the same broadcast domain. This draft proposes a new mechanism that allows listeners to send multicast membership reports that are accompanied by a marker signalling the querier to acknowledge the reception of the membership report message in such a way that the multicast listener is sure that its membership report message has been received by the querier. And that the multicast listener does not need to repeat its message transmission RV number of times. However, if the group membership message is lost, the multicast listener can repeat the message transmission until either an acknowledgement is received, a general query is received, or the number of retransmissions reaches the maximum configured on the listener. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant BIDIR-PIM implementations. 3. Resilient GMP To make GMP more resilient, multicast listeners are allowed to keep sending group membership reports until an acknowledgement of the report is received from the querier. This mechanism is different to the original GMP specifications in that it allows a more robust delivery of membership report messages, and contains less protocol chatter if the link does not suffer from frame losses, i.e. the multicast listener will not unnecessarily retransmit the membership report messages. Diagram 2 below illustrates the behaviour of multicast listener and querier adhering to the mechanism proposed in this draft. Anggawijaya April 21, 2016 [Page 5] Internet-Draft Resilient GMP October 2015 Multicast listener GMP Querier |----------<---general query------------------| | | |. . . . . . . . . . . . . . . . . . . . . . | a | | |------------membership report->---X | b | | |------------membership report->---X | T | .... | i | .... | m |------------membership report->---X | e |. . . . . . . . . . . . . . . . . . . . . . | c | |------------membership report->--------------| | |----------<---report acknowledge-------------| V |----------<---multicast data-----------------| d |----------<---multicast data-----------------| | ... | Ta-Tc - transient state period Tb-Td - delay for multicast data Diagram 2. Resilient GMP operation with transient state on querier In order to apply this mechanism, a new message format is required that includes a flag to enable multicast listeners to request an acknowledgement from the querier. This message format is defined in the next section. The new behaviour as specified by this draft is disabled by default and must be enabled explicitly by the network operator. Anggawijaya April 21, 2016 [Page 6] Internet-Draft Resilient GMP October 2015 3.1. Resilient IGMP 3.1.1. Message Formats IGMPv3 Membership Report 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x22 | Reserved |R|A| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of Group Records (M) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record [2] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Group Record [M] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Please see [RFC3376] for the definitions of the existing fields. New flags defined in the membership report message are: R: 'Request for Acknowledgement' flag. Setting this flag indicates that the multicast listener sending the membership report requires an acknowledgement message in reply to the current membership report message. A: 'Membership report acknowledgement' flag. Setting this flag indicates that this message is an acknowledgement to the membership report message contained in this message. Anggawijaya April 21, 2016 [Page 7] Internet-Draft Resilient GMP October 2015 IGMPv3 Query 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x11 | Max Resp Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv|A|S| QRV | QQIC | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address [1] | +- -+ | Source Address [2] | +- . -+ . . . . . . +- -+ | Source Address [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Please see [RFC3376] for the definitions of the existing fields. The new flag defined in the IGMPv3 Query is: A : 'Acknowledgement Capable Querier' flag. Setting this flag indicates that the querier is capable of sending acknowledgements to membership reports to multicast listeners. 3.1.2. Host Behaviour This section describes the new behaviour of IGMP hosts implementing the mechanism as specified in this draft. 1. By default, an implementation of IGMP adhering to this draft MUST enable the new listener behaviour as specified below. And if configured to do so, it MAY also fall back to operate as per [RFC3376] specification. This provision also ensures that the an existing IGMPv3 implementation can operate with a querier implementing this draft. 2. A multicast listener adhering to this new specification MUST send its group membership reports with the R-flag set, and A-bit clear, in order to indicate its requirement that the querier acknowledges its group membership reports 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. Anggawijaya April 21, 2016 [Page 8] Internet-Draft Resilient GMP October 2015 4. As soon as a multicast listener receives a general query with the A-flag cleared, it MUST fall back to normal IGMPv3 operation as per [RFC3376] specification, i.e. all its membership reports must be sent with both R-flag and A-flag cleared, and it can only retransmit its messages (RV-1) number of times. This ensures that the new implementation of IGMP listener can inter-operate with existing IGMP querier implementations. 5. The multicast listener MUST keep retransmitting its membership report until: a. It receives an acknowledgement message from the querier or b. It detects that there are no querier present on the link. The listener will assume this situation if it has received no queries for a 'Querier Live Time' period since it transmitted the original membership report message. The Querier Live Time is calculated as 2.5 times the Query Interval time. 6. The retransmission of the group membership reports MUST be done at random intervals within the range (0, [Unsolicited Report Interval]). 7. If a multicast listener's interface state changes, the retransmission of the previous membership report messages MUST stop, because the state machine will send new membership report messages reflecting the state change. 8. A multicast listener MUST process only valid acknowledgement messages. Invalid messages MUST be dropped silently. A valid acknowledgement message MUST obey the following rules: a. The destination IP address must be equal to the IP address of the receiving interface, and cannot be a multicast, broadcast nor unspecified IP address. b. The R-flag of the report must be cleared and A-flag must be set. c. The checksum must be correct. d. The listener is able to match the acknowledgement message with the member report message waiting for an acknowledgement. 9. If a multicast listener send multicast membership reports consisting only of group records indicating that the host no longer wish to receive multicast data for the groups specified, such as BLOCK_OLD_SOURCES record, the report MAY be sent without the R-bit set. Note that by doing this, if the report is dropped then the DR will not send multicast leave to its upstream router and may result in unnecessary multicast data forwarding. 3.1.3. Router Behaviour This section describes the new behaviour of IGMP routers implementing the mechanism as specified in this draft. Anggawijaya April 21, 2016 [Page 9] Internet-Draft Resilient GMP October 2015 1. By default, a querier adhering to this draft MUST send queries with the A-flag set. The implementation SHOULD also enable operators to turn the new behaviour off administratively. 2. If a querier receives a membership report message it MUST perform the same report message validation as specified in [RFC3376], i.e. that all invalid report messages MUST be silently discarded. And in addition, it MUST also perform the following checks: a. That the A-flag is clear b. If the R-flag is set, check that the source IP address is not the unspecified IP address (0.0.0.0). 3. If a querier receives a valid membership report message with the R-flag set, it MUST send an acknowledgement by retransmitting the same report message back to the listener after performing the following alterations to the message: a. The source IP address MUST be set to the that of the receiving interface. b. The destination IP address MUST be set to the source IP address contained in the original message. c. The R-flag is cleared, and the A-flag is set. d. The checksum of the packet is recalculated. 4. If a querier receives a valid membership report message with the R-flag cleared, then it will just process the report message as per [RFC3376] specification. 5. When a querier sends a query, it MUST set the A flag, unless it is configured not to do so by the administrator. 3.1.4. Backward Compatibility To maintain compatibility with older version of IGMP implementations, both the listener and querier MUST fall back to the operation as per [RFC3376] specification, when the presence of older IGMP implementation is detected on the same network. Anggawijaya April 21, 2016 [Page 10] Internet-Draft Resilient GMP October 2015 3.2. Resilient MLD 3.2.1. Message Formats MLDv2 Membership Report 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 143 |R|A| Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Nr of Mcast Address Records (M)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [1] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [2] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Multicast Address Record [M] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Please see [RFC3810] for the definitions of the existing fields. The new flags defined in the membership report message are: R: 'Request for Acknowledgement' flag. Setting this flag indicates that the multicast listener sending the membership report requires an acknowledgement message in reply to the current membership report message. A: 'Membership report acknowledgement' flag. Setting this flag indicates that this message is an acknowledgement to the membership report message contained in this message. Anggawijaya April 21, 2016 [Page 11] Internet-Draft Resilient GMP October 2015 MLDv2 Query 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 130 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Response Code | Reserved |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * * | | * Multicast Address * | | * * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resv |S| QRV | QQIC | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * * | | * Source Address [1] * | | * * | | +- -+ | | * * | | * Source Address [2] * | | * * | | +- . -+ . . . . . . +- -+ | | * * | | * Source Address [N] * | | * * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Please see [RFC3810] for the definitions of the existing fields. Anggawijaya April 21, 2016 [Page 12] Internet-Draft Resilient GMP October 2015 The new flag defined in MLDv2 Query is: A : 'Acknowledgement Capable Querier' flag. Setting this flag indicates that this querier is capable of sending an acknowledgement to membership reports toward multicast listeners. 3.2.2. Host Behaviour This section describes the new behaviour of MLD hosts implementing the mechanism as specified in this draft. 1. By default, an implementation of MLD adhering to this draft MUST enable the new listener behaviour as specified below. And if configured to do so, it MAY also fall back to operate as per [RFC3810] specification. This also ensures that existing MLDv2 implementations can inter-operate with queriers implementing this draft. 2. A multicast listener adhering to this new specification MUST send a group membership reports with the R-flag set, and the A-bit clear, indicating its wish that the querier acknowledges the listener's group membership reports. 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. 4. As soon as a multicast listener receives a general query with the A-flag cleared, it MUST fall back to normal MLDv2 operation as per [RFC3810] specification, i.e. all its membership reports must be sent with both R-flag and A-flag cleared, and it can only retransmit its messages (RV-1) number of times. This ensures that the new implementation of MLD listener can inter-operate with existing MLD querier implementations. 5. The multicast listener MUST keep retransmitting the membership report until: a. It receives an acknowledgement message from the querier or b. It detects that there are no querier present on the link. The listener will assume this situation if it has receives no queries for 'Querier Live Time' period since it transmitted the original membership report message. The Querier Live Time is calculated as 2.5 times the Query Interval time. 6. The retransmission of the group membership reports MUST be done at random intervals within the range (0, [Unsolicited Report Interval]). 7. If a multicast listener's interface state changes, retransmission of the previous membership report message MUST stop, because the Anggawijaya April 21, 2016 [Page 13] Internet-Draft Resilient GMP October 2015 state machine will send a new membership report message reflecting the state change. 8. A multicast listener MUST process only valid acknowledgement messages. Invalid messages MUST be dropped silently. A valid acknowledgement message MUST obey the following rules: a. The destination IPv6 address must be equal to that of the receiving interface, and MUST NOT be a multicast or the unspecified (::) IPv6 address. b. The R-flag of the report must be cleared and A-flag must be set. c. The checksum must be correct. d. The listener is able to match the acknowledgement message with the member report message waiting for an acknowledgement. 9. If a multicast listener send multicast membership reports consisting only of group records indicating that the host no longer wish to receive multicast data for the groups specified, such as BLOCK_OLD_SOURCES record, the report MAY be sent without the R-bit set. Note that by doing this, if the report is dropped then the DR will not send multicast leave to its upstream router and may result in unnecessary multicast data forwarding. 3.2.3. Router Behaviour This section describes the new behaviour of MLD routers implementing the mechanism as specified in this draft. 1. By default, querier implementation adhering to this draft MUST send queries with the A-flag set. The implementation SHOULD also enable operators to turn the new behaviour off administratively. 2. If a querier receives a membership report message it MUST perform the same report message validation as specified in [RFC3810]. All invalid report messages MUST be silently discarded. It MUST also do the following checks: a. Ensure that the A-flag is clear. b. Check that if the R-flag is set, the source IPv6 address is not the unspecified IPv6 address (::). 3. If a querier receives a valid membership report message with the R-flag set, it MUST send an acknowledgement by retransmitting the same report message back to the listener after performing the following mandatory alterations to the message: a. Setting the source IPv6 address to the IPv6 address of the receiving interface. b. Setting the destination IPv6 address to the original source IPv6 address of the message. c. Clear the R-flag, and set the A-flag. d. Recalculate the packet's checksum. Anggawijaya April 21, 2016 [Page 14] Internet-Draft Resilient GMP October 2015 4. If a querier receives a valid membership report message with the R-flag unset, then it will process the report message as per [RFC3810] specification. 5. When a querier sends a query, it MUST set the A-flag, unless it is configured not to do so by the administrator. 3.2.4. Backward Compatibility To maintain compatibility with older version of MLD implementations, both the listener and querier MUST fall back to the operation as per [RFC3810] specification, when the presence of older MLD implementation is detected on the same network. 3.3 Operational Consideration If there are more than one multicast routers running IGMP/MLD in a LAN, it is advisable to have all the routers configured with the same setting for the 'Acknowledgement Capable Querier' flag to avoid temporary confusion on hosts as to whether they are allowed to send report messages with the R-flag set or not, during querier election time. 4. IANA Considerations This document has no actions for IANA. 5. Security Considerations The original specification of both IGMPv3 and MLDv2 have some defense capability against forged messages originated off-link. 5.1. On-link Query Message Forgery Apart from the threats described in both [RFC3376] and [RFC3810], extra threat exists in the form of forged query messages with the A-flag set, while the actual querier does not send queries with the A-flag set. This would make all listeners adhering to the mechanism proposed in this draft, keep sending extra retransmissions of the report messages without receiving acknowledgement from the querier) until they see the query with the A-flag cleared from the forged querier. To mitigate this attack, listener implementations might generate a log message if queries it receives from the same querier seem to have variable setting for the A-flag. 5.2. On-link Membership Report Message Forgery When a querier is configured to run the new implementation as specified in this draft, additional threats exist to those described in [RFC3376] and [RFC3810]. These extra threats exist in the form of forged membership report messages with the R-flag being set. This will make the querier unnecessarily send acknowledgements to the forged listener. However this attack is mitigated by the fact that the original listener will drop these messages since it does not expect to receive acknowledgement messages. Anggawijaya April 21, 2016 [Page 15] Internet-Draft Resilient GMP October 2015 6. Acknowledgements A special thank you goes to Stig Venaas for providing very valuable feedback and review on this document. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 7.2. Informative References [VYNCKE] E. Vyncke , P. Thubert , E. Levy-Abegnoli , A. Yourtchenko, "Why Network-Layer Multicast is Not Always Efficient At Datalink Layer", draft-vyncke-6man-mcast-not-efficient, February 2014. [MCBRIDE] M. McBride, C. Perkins, "Multicast Wifi Problem Statement", draft-mcbride-mboned-wifi-mcast-problem-statement, July, 2015. Authors' Address Hermin Anggawijaya Allied Telesis Labs NZ, Ltd 27 Nazareth Ave Christchurch 8024 New Zealand Email: hermin.anggawijaya@alliedtelesis.co.nz Anggawijaya April 21, 2016 [Page 16]