PIM Working Group Hermin Anggawijaya
Internet-Draft Allied Telesis Labs, NZ
Intended status: Standards Track February 23, 2016
Expires: August 26, 2016
Improving IGMPv3 and MLDv2 Resilience
draft-anggawijaya-pim-resilient-gmp-01
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 August 26, 2016.
Copyright Notice
Copyright (c) 2016 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 August 26, 2016 [Page 1]
Internet-Draft Resilient GMP February 2016
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 . . . . . . . . . . . . . . . . . . . . 9
3.1.3 Router Behaviour . . . . . . . . . . . . . . . . . . . 10
3.1.4 Backward Compatibility . . . . . . . . . . . . . . . . 11
3.2 Resilient MLD . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Message Formats . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Host Behaviour . . . . . . . . . . . . . . . . . . . . 15
3.2.3 Router Behaviour . . . . . . . . . . . . . . . . . . . 16
3.2.4 Backward Compatibility . . . . . . . . . . . . . . . . 17
3.3 Operational Consideration . . . . . . . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
4.1 IGMP Type Numbers . . . . . . . . . . . . . . . . . . . . . 17
4.2 ICMPv6 Type Numbers . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. On-link Query Message Forgery . . . . . . . . . . . . . . 18
5.2. On-link Membership Report Message Forgery . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Anggawijaya August 26, 2016 [Page 2]
Internet-Draft Resilient GMP February 2016
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 August 26, 2016 [Page 3]
Internet-Draft Resilient GMP February 2016
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 August 26, 2016 [Page 4]
Internet-Draft Resilient GMP February 2016
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 August 26, 2016 [Page 5]
Internet-Draft Resilient GMP February 2016
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 August 26, 2016 [Page 6]
Internet-Draft Resilient GMP February 2016
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| 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.
Anggawijaya August 26, 2016 [Page 7]
Internet-Draft Resilient GMP February 2016
IGMPv3 Membership Report Acknowledgement
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 = 0x23 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of Group Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All the fields in the IGMPv3 Membership Report Acknowledgement
message have the same specifications as in IGMPv3 Membership Report
message, except the type code is 0x23 (to be requested to IANA).
The format is chosen so that it is very convenient for the DR to
acknowledge membership report messages by simply copying the original
membership report message, and modifying the copied packet with new
IP source and destination addresses, IGMP packet type, and
recalculating both IP and IGMP checksums.
The membership report acknowledgement is sent unicast to the source
of the original membership report message being acknowledged.
Anggawijaya August 26, 2016 [Page 8]
Internet-Draft Resilient GMP February 2016
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 August 26, 2016 [Page 9]
Internet-Draft Resilient GMP February 2016
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 IGMP type is set to 0x23.
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 August 26, 2016 [Page 10]
Internet-Draft Resilient GMP February 2016
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. 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 transmitting an
acknowledgement packet whose content is the same as the membership
report message, with the following modifications:
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 IP checksum is recalculated.
d. The IGMP packet type is set to 0x23 (to be assigned by IANA).
e. The IGMP checksum 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 August 26, 2016 [Page 11]
Internet-Draft Resilient GMP February 2016
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 | Reserved |R| 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.
Anggawijaya August 26, 2016 [Page 12]
Internet-Draft Resilient GMP February 2016
MLDv2 Membership Report Acknowledgement
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 = 160 | Reserved |R| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All the fields in the MLDv2 Membership Report Acknowledgement
message have the same specifications as in MLDv2 Membership Report
message, except the type code is 160 (to be requested to IANA).
The format is chosen so that it is very convenient for the DR to
acknowledge membership report messages by simply copying the original
membership report message, and modifying the copied packet with new
IPv6 source and destination addresses, new ICMPv6 packet type, and
recalculating the MLDv2 checksum.
The membership report acknowledgement is sent unicast to the source
of the original membership report message being acknowledged.
Anggawijaya August 26, 2016 [Page 13]
Internet-Draft Resilient GMP February 2016
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 August 26, 2016 [Page 14]
Internet-Draft Resilient GMP February 2016
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 August 26, 2016 [Page 15]
Internet-Draft Resilient GMP February 2016
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 the IPv6 address
of the receiving interface, and MUST NOT be a multicast,
broadcast nor the unspecified IPv6 address (::).
b. The ICMPv6 packet type is set to 160.
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 transmitting an
acknowledgement packet whose content is the same as the membership
report message, with the following modifications:
a. The source IPv6 address MUST be set to the that of the
receiving interface.
b. The destination IPv6 address MUST be set to the source IPv6
address contained in the original message.
d. The ICMPv6 packet type is set to 160 (to be requested to IANA).
e. The MLDv2 checksum is recalculated.
Anggawijaya August 26, 2016 [Page 16]
Internet-Draft Resilient GMP February 2016
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
4.1. IGMP Type Numbers
Author of this document requests the following IGMP Type Number:
IGMPv3 Packet Type Value
------------------------------------------ -----
IGMPv3 Membership Report Acknowledegement 0x23
4.2. ICMPv6 Type Numbers
Author of this document requests the following ICMPv6 Type Number:
ICMPv6 Packet Type Value
------------------------------------------ -----
MLDv2 Membership Report Acknowledegement 160
Anggawijaya August 26, 2016 [Page 17]
Internet-Draft Resilient GMP February 2016
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.
6. Acknowledgements
A special thank you goes to Stig Venaas for providing very valuable
feedback and review on this document.
Anggawijaya August 26, 2016 [Page 18]
Internet-Draft Resilient GMP February 2016
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 August 26, 2016 [Page 19]