1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
|
<pre>Network Working Group S. Deering
Request for Comments: 2710 Cisco Systems
Category: Standards Track W. Fenner
AT&T Research
B. Haberman
IBM
October 1999
<span class="h1">Multicast Listener Discovery (MLD) for IPv6</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document specifies the protocol used by an IPv6 router to
discover the presence of multicast listeners (that is, nodes wishing
to receive multicast packets) on its directly attached links, and to
discover specifically which multicast addresses are of interest to
those neighboring nodes. This protocol is referred to as Multicast
Listener Discovery or MLD. MLD is derived from version 2 of IPv4's
Internet Group Management Protocol, IGMPv2. One important difference
to note is that MLD uses ICMPv6 (IP Protocol 58) message types,
rather than IGMP (IP Protocol 2) message types.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Definitions</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="#ref-KEYWORDS" title=""Key words for use in RFCs to Indicate Requirement Levels"">KEYWORDS</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Introduction</span>
The purpose of Multicast Listener Discovery (MLD) is to enable each
IPv6 router to discover the presence of multicast listeners (that is,
nodes wishing to receive multicast packets) on its directly attached
links, and to discover specifically which multicast addresses are of
interest to those neighboring nodes. This information is then
<span class="grey">Deering, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
provided to whichever multicast routing protocol is being used by the
router, in order to ensure that multicast packets are delivered to
all links where there are interested receivers.
MLD is an asymmetric protocol, specifying different behaviors for
multicast listeners and for routers. For those multicast addresses
to which a router itself is listening, the router performs both parts
of the protocol, including responding to its own messages.
If a router has more than one interface to the same link, it need
perform the router part of MLD over only one of those interfaces.
Listeners, on the other hand, must perform the listener part of MLD
on all interfaces from which an application or upper-layer protocol
has requested reception of multicast packets.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Message Format</span>
MLD is a sub-protocol of ICMPv6, that is, MLD message types are a
subset of the set of ICMPv6 messages, and MLD messages are identified
in IPv6 packets by a preceding Next Header value of 58. All MLD
messages described in this document are sent with a link-local IPv6
Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert
option [<a href="#ref-RTR-ALERT" title=""IPv6 Router Alert Option"">RTR-ALERT</a>] in a Hop-by-Hop Options header. (The Router Alert
option is necessary to cause routers to examine MLD messages sent to
multicast addresses in which the routers themselves have no
interest.)
MLD messages have the following format:
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Delay | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="grey">Deering, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Type</span>
There are three types of MLD messages:
Multicast Listener Query (Type = decimal 130)
There are two subtypes of Multicast Listener Query messages:
- General Query, used to learn which multicast addresses have
listeners on an attached link.
- Multicast-Address-Specific Query, used to learn if a
particular multicast address has any listeners on an attached
link.
These two subtypes are differentiated by the contents of the
Multicast Address field, as described in <a href="#section-3.6">section 3.6</a>.
Multicast Listener Report (Type = decimal 131)
Multicast Listener Done (Type = decimal 132)
In the rest of this document, the above messages types are referred
to simply as "Query", "Report", and "Done".
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Code</span>
Initialized to zero by the sender; ignored by receivers.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Checksum</span>
The standard ICMPv6 checksum, covering the entire MLD message plus a
"pseudo-header" of IPv6 header fields [<a href="#ref-ICMPv6" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">ICMPv6</a>,<a href="#ref-IPv6" title=""Internet Protocol, Version 6 (IPv6) Specification"">IPv6</a>].
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Maximum Response Delay</span>
The Maximum Response Delay field is meaningful only in Query
messages, and specifies the maximum allowed delay before sending a
responding Report, in units of milliseconds. In all other messages,
it is set to zero by the sender and ignored by receivers.
Varying this value allows the routers to tune the "leave latency"
(the time between the moment the last node on a link ceases listening
to a particular multicast address and moment the routing protocol is
notified that there are no longer any listeners for that address), as
discussed in <a href="#section-7.8">section 7.8</a>. It also allows tuning of the burstiness of
MLD traffic on a link, as discussed in <a href="#section-7.3">section 7.3</a>.
<span class="grey">Deering, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Reserved</span>
Initialized to zero by the sender; ignored by receivers.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Multicast Address</span>
In a Query message, the Multicast Address field is set to zero when
sending a General Query, and set to a specific IPv6 multicast address
when sending a Multicast-Address-Specific Query.
In a Report or Done message, the Multicast Address field holds a
specific IPv6 multicast address to which the message sender is
listening or is ceasing to listen, respectively.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Other fields</span>
The length of a received MLD message is computed by taking the IPv6
Payload Length value and subtracting the length of any IPv6 extension
headers present between the IPv6 header and the MLD message. If that
length is greater than 24 octets, that indicates that there are other
fields present beyond the fields described above, perhaps belonging
to a future backwards-compatible version of MLD. An implementation
of the version of MLD specified in this document MUST NOT send an MLD
message longer than 24 octets and MUST ignore anything past the first
24 octets of a received MLD message. In all cases, the MLD checksum
MUST be computed over the entire MLD message, not just the first 24
octets.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Description</span>
Note that defaults for timer values are described later in this
document. Timer and counter names appear in square brackets.
Routers use MLD to learn which multicast addresses have listeners on
each of their attached links. Each router keeps a list, for each
attached link, of which multicast addresses have listeners on that
link, and a timer associated with each of those addresses. Note that
the router needs to learn only that listeners for a given multicast
address are present on a link; it does NOT need to learn the identity
(e.g., unicast address) of those listeners or even how many listeners
are present.
For each attached link, a router selects one of its link-local
unicast addresses on that link to be used as the IPv6 Source Address
in all MLD packets it transmits on that link.
<span class="grey">Deering, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
For each interface over which the router is operating the MLD
protocol, the router must configure that interface to listen to all
link-layer multicast address that can be generated by IPv6
multicasts. For example, an Ethernet-attached router must set its
Ethernet address reception filter to accept all Ethernet multicast
addresses that start with the hexadecimal value 3333 [<a href="#ref-IPv6-ETHER" title=""Transmission of IPv6 Packets over Ethernet Networks"">IPv6-ETHER</a>]; in
the case of an Ethernet interface that does not support the filtering
of such a range of multicast address, it must be configured to accept
ALL Ethernet multicast addresses, in order to meet the requirements
of MLD.
With respect to each of its attached links, a router may assume one
of two roles: Querier or Non-Querier. There is normally only one
Querier per link. All routers start up as a Querier on each of their
attached links. If a router hears a Query message whose IPv6 Source
Address is numerically less than its own selected address for that
link, it MUST become a Non-Querier on that link. If [Other Querier
Present Interval] passes without receiving, from a particular
attached link, any Queries from a router with an address less than
its own, a router resumes the role of Querier on that link.
A Querier for a link periodically [Query Interval] sends a General
Query on that link, to solicit reports of all multicast addresses of
interest on that link. On startup, a router SHOULD send [Startup
Query Count] General Queries spaced closely together [Startup Query
Interval] on all attached links in order to quickly and reliably
discover the presence of multicast listeners on those links.
General Queries are sent to the link-scope all-nodes multicast
address (FF02::1), with a Multicast Address field of 0, and a Maximum
Response Delay of [Query Response Interval].
When a node receives a General Query, it sets a delay timer for each
multicast address to which it is listening on the interface from
which it received the Query, EXCLUDING the link-scope all-nodes
address and any multicast addresses of scope 0 (reserved) or 1
(node-local). Each timer is set to a different random value, using
the highest clock granularity available on the node, selected from
the range [0, Maximum Response Delay] with Maximum Response Delay as
specified in the Query packet. If a timer for any address is already
running, it is reset to the new random value only if the requested
Maximum Response Delay is less than the remaining value of the
running timer. If the Query packet specifies a Maximum Response
Delay of zero, each timer is effectively set to zero, and the action
specified below for timer expiration is performed immediately.
<span class="grey">Deering, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
When a node receives a Multicast-Address-Specific Query, if it is
listening to the queried Multicast Address on the interface from
which the Query was received, it sets a delay timer for that address
to a random value selected from the range [0, Maximum Response
Delay], as above. If a timer for the address is already running, it
is reset to the new random value only if the requested Maximum
Response Delay is less than the remaining value of the running timer.
If the Query packet specifies a Maximum Response Delay of zero, the
timer is effectively set to zero, and the action specified below for
timer expiration is performed immediately.
If a node's timer for a particular multicast address on a particular
interface expires, the node transmits a Report to that address via
that interface; the address being reported is carried in both the
IPv6 Destination Address field and the MLD Multicast Address field of
the Report packet. The IPv6 Hop Limit of 1 (as well as the presence
of a link-local IPv6 Source Address) prevent the packet from
traveling beyond the link to which the reporting interface is
attached.
If a node receives another node's Report from an interface for a
multicast address while it has a timer running for that same address
on that interface, it stops its timer and does not send a Report for
that address, thus suppressing duplicate reports on the link.
When a router receives a Report from a link, if the reported address
is not already present in the router's list of multicast address
having listeners on that link, the reported address is added to the
list, its timer is set to [Multicast Listener Interval], and its
appearance is made known to the router's multicast routing component.
If a Report is received for a multicast address that is already
present in the router's list, the timer for that address is reset to
[Multicast Listener Interval]. If an address's timer expires, it is
assumed that there are no longer any listeners for that address
present on the link, so it is deleted from the list and its
disappearance is made known to the multicast routing component.
When a node starts listening to a multicast address on an interface,
it should immediately transmit an unsolicited Report for that address
on that interface, in case it is the first listener on the link. To
cover the possibility of the initial Report being lost or damaged, it
is recommended that it be repeated once or twice after short delays
[Unsolicited Report Interval]. (A simple way to accomplish this is
to send the initial Report and then act as if a Multicast-Address-
Specific Query was received for that address, and set a timer
appropriately).
<span class="grey">Deering, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
When a node ceases to listen to a multicast address on an interface,
it SHOULD send a single Done message to the link-scope all-routers
multicast address (FF02::2), carrying in its Multicast Address field
the address to which it is ceasing to listen. If the node's most
recent Report message was suppressed by hearing another Report
message, it MAY send nothing, as it is highly likely that there is
another listener for that address still present on the same link. If
this optimization is implemented, it MUST be able to be turned off
but SHOULD default to on.
When a router in Querier state receives a Done message from a link,
if the Multicast Address identified in the message is present in the
Querier's list of addresses having listeners on that link, the
Querier sends [Last Listener Query Count] Multicast-Address-Specific
Queries, one every [Last Listener Query Interval] to that multicast
address. These Multicast-Address-Specific Queries have their Maximum
Response Delay set to [Last Listener Query Interval]. If no Reports
for the address are received from the link after the response delay
of the last query has passed, the routers on the link assume that the
address no longer has any listeners there; the address is therefore
deleted from the list and its disappearance is made known to the
multicast routing component. This process is continued to its
resolution (i.e. until a Report is received or the last Multicast-
Address-Specific Query is sent with no response) despite any
transition from Querier to Non-Querier on this link.
Routers in Non-Querier state MUST ignore Done messages.
When a router in Non-Querier state receives a Multicast-Address-
Specific Query, if its timer value for the identified multicast
address is greater than [Last Listener Query Count] times the Maximum
Response Delay specified in the message, it sets the address's timer
to that latter value.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Node State Transition Diagram</span>
Node behavior is more formally specified by the state transition
diagram below. A node may be in one of three possible states with
respect to any single IPv6 multicast address on any single interface:
- "Non-Listener" state, when the node is not listening to the address
on the interface (i.e., no upper-layer protocol or application has
requested reception of packets to that multicast address). This
is the initial state for all multicast addresses on all
interfaces; it requires no storage in the node.
<span class="grey">Deering, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
- "Delaying Listener" state, when the node is listening to the
address on the interface and has a report delay timer running for
that address.
- "Idle Listener" state, when the node is listening to the address on
the interface and does not have a report delay timer running for
that address.
There are five significant events that can cause MLD state
transitions:
- "start listening" occurs when the node starts listening to the
address on the interface. It may occur only in the Non-Listener
state.
- "stop listening" occurs when the node stops listening to the
address on the interface. It may occur only in the Delaying
Listener and Idle Listener states.
- "query received" occurs when the node receives either a valid
General Query message, or a valid Multicast-Address-Specific Query
message. To be valid, the Query message MUST come from a link-
local IPv6 Source Address, be at least 24 octets long, and have a
correct MLD checksum. The Multicast Address field in the MLD
message must contain either zero (a General Query) or a valid
multicast address (a Multicast- Address-Specific Query). A
General Query applies to all multicast addresses on the interface
from which the Query is received. A Multicast-Address-Specific
Query applies to a single multicast address on the interface from
which the Query is received. Queries are ignored for addresses in
the Non-Listener state.
- "report received" occurs when the node receives a valid MLD Report
message. To be valid, the Report message MUST come from a link-
local IPv6 Source Address, be at least 24 octets long, and have a
correct MLD checksum. A Report applies only to the address
identified in the Multicast Address field of the Report, on the
interface from which the Report is received. It is ignored in the
Non-Listener or Idle Listener state.
- "timer expired" occurs when the report delay timer for the address
on the interface expires. It may occur only in the Delaying
Listener state.
<span class="grey">Deering, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
All other events, such as receiving invalid MLD messages or MLD
message types other than Query or Report, are ignored in all states.
There are seven possible actions that may be taken in response to the
above events:
- "send report" for the address on the interface. The Report message
is sent to the address being reported.
- "send done" for the address on the interface. If the flag saying
we were the last node to report is cleared, this action MAY be
skipped. The Done message is sent to the link-scope all-routers
address (FF02::2).
- "set flag" that we were the last node to send a report for this
address.
- "clear flag" since we were not the last node to send a report for
this address.
- "start timer" for the address on the interface, using a delay value
chosen uniformly from the interval [0, Maximum Response Delay],
where Maximum Response Delay is specified in the Query. If this
is an unsolicited Report, the timer is set to a delay value chosen
uniformly from the interval [0, [Unsolicited Report Interval] ].
- "reset timer" for the address on the interface to a new value,
using a delay value chosen uniformly from the interval [0, Maximum
Response Delay], as described in "start timer".
- "stop timer" for the address on the interface.
In all of the following state transition diagrams, each state
transition arc is labeled with the event that causes the transition,
and, in parentheses, any actions taken during the transition. Note
that the transition is always triggered by the event; even if the
action is conditional, the transition still occurs.
<span class="grey">Deering, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
________________
| |
| |
| |
| |
--------->| Non-Listener |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| stop listening | start listening | stop listening
| (stop timer, |(send report, | (send done if
| send done if | set flag, | flag set)
| flag set) | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying | (start timer) | Idle |
---->| Listener |------------------->| Listener |
| | | report received | |
| | | (stop timer, | |
| | | clear flag) | |
| |_________________|------------------->|_________________|
| query received | timer expired
| (reset timer if | (send report,
| Max Resp Delay | set flag)
| < current timer) |
-------------------
The link-scope all-nodes address (FF02::1) is handled as a special
case. The node starts in Idle Listener state for that address on
every interface, never transitions to another state, and never sends
a Report or Done for that address.
MLD messages are never sent for multicast addresses whose scope is 0
(reserved) or 1 (node-local).
MLD messages ARE sent for multicast addresses whose scope is 2
(link-local), including Solicited-Node multicast addresses [ADDR-
ARCH], except for the link-scope, all-nodes address (FF02::1).
<span class="grey">Deering, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Router State Transition Diagram</span>
Router behavior is more formally specified by the state transition
diagrams below.
A router may be in one of two possible states with respect to any
single attached link:
- "Querier", when this router is designated to transmit MLD Queries
on this link.
- "Non-Querier", when there is another router designated to transmit
MLD Queries on this link.
The following three events can cause the router to change states:
- "query timer expired" occurs when the timer set for query
transmission expires. This event is significant only when in the
Querier state.
- "query received from a router with a lower IP address" occurs when
a valid MLD Query is received from a router on the same link with
a lower IPv6 Source Address. To be valid, the Query message MUST
come from a link-local IPv6 Source Address, be at least 24 octets
long, and have a correct MLD checksum.
- "other querier present timer expired" occurs when the timer set to
note the presence of another querier with a lower IP address on
the link expires. This event is significant only when in the
Non-Querier state.
There are three actions that may be taken in response to the above
events:
- "start general query timer" for the attached link to [Query
Interval].
- "start other querier present timer" for the attached link to [Other
Querier Present Interval].
- "send general query" on the attached link. The General Query is
sent to the link-scope all-nodes address (FF02::1), and has a
Maximum Response Delay of [Query Response Interval].
<span class="grey">Deering, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
--------------------------------
_______|________ gen. query timer |
--------- | | expired |
| Initial |---------------->| | (send general query, |
--------- (send gen. q., | | start gen. q. timer) |
start initial gen. q. | |<----------------------
timer) | Querier |
| |
-----| |<---
| | | |
| |________________| |
query received from a | | other querier
router with a lower | | present timer
IP address | | expired
(start other querier | ________________ | (send gen. query,
present timer) | | | | start gen. q. timer)
| | | |
| | | |
---->| Non |----
| Querier |
| |
| |
---->| |----
| |________________| |
| query received from a |
| router with a lower IP |
| address |
| (start other querier |
| present timer) |
---------------------------
A router starts in the Initial state on all attached links, and
immediately transitions to Querier state.
In addition, to keep track of which multicast addresses have
listeners, a router may be in one of three possible states with
respect to any single IPv6 multicast address on any single attached
link:
- "No Listeners Present" state, when there are no nodes on the link
that have sent a Report for this multicast address. This is the
initial state for all multicast addresses on the router; it
requires no storage in the router.
- "Listeners Present" state, when there is a node on the link that
has sent a Report for this multicast address.
<span class="grey">Deering, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
- "Checking Listeners" state, when the router has received a Done
message but has not yet heard a Report for the identified address.
There are five significant events that can cause router state
transitions:
- "report received" occurs when the router receives a Report for the
address from the link. To be valid, the Report message MUST come
from a link-local IPv6 Source Address, be at least 24 octets long,
and have a correct MLD checksum.
- "done received" occurs when the router receives a Done message for
the address from the link. To be valid, the Done message MUST
come from a link-local IPv6 Source Address, be at least 24 octets
long, and have a correct MLD checksum. This event is significant
only in the "Listerners Present" state and when the router is a
Querier.
- "multicast-address-specific query received" occurs when a router
receives a Multicast-Address-Specific Query for the address from
the link. To be valid, the Query message MUST come from a link-
local IPv6 Source Address, be at least 24 octets long, and have a
correct MLD checksum. This event is significant only in the
"Listeners Present" state and when the router is a Non-Querier.
- "timer expired" occurs when the timer set for a multicast address
expires. This event is significant only in the "Listeners
Present" or "Checking Listeners" state.
- "retransmit timer expired" occurs when the timer set to retransmit
a Multicast-Address-Specific Query expires. This event is
significant only in the "Checking Listeners" state.
There are seven possible actions that may be taken in response to the
above events:
- "start timer" for the address on the link - also resets the timer
to its initial value [Multicast Listener Interval] if the timer is
currently running.
- "start timer*" for the address on the link - this alternate action
sets the timer to the minimum of its current value and either
[Last Listener Query Interval] * [Last Listener Query Count] if
this router is a Querier, or the Maximum Response Delay in the
Query message * [Last Listener Query Count] if this router is a
non-Querier.
<span class="grey">Deering, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
- "start retransmit timer" for the address on the link [Last Listener
Query Interval].
- "clear retransmit timer" for the address on the link.
- "send multicast-address-specific query" for the address on the
link. The Multicast-Address-Specific Query is sent to the address
being queried, and has a Maximum Response Delay of [Last Listener
Query Interval].
- "notify routing +" internally notify the multicast routing protocol
that there are listeners to this address on this link.
- "notify routing -" internally notify the multicast routing protocol
that there are no longer any listeners to this address on this
link.
The following state diagrams apply per group per link. There are two
diagrams; one for routers in Querier state and one for routers in
Non-Querier state. The transition between Querier and Non-Querier
state on a link is handled specially. All groups on that link in "No
Listeners Present" or "Listeners Present" states switch state
transition diagrams when the Querier/Non-Querier state transition
occurs. However, any groups in "Checking Listeners" state continue
with the same state transition diagram until the "Checking Listeners"
state is exited. E.g. a router that starts as a Querier, receives a
Done message for a group and then receives a Query from a router with
a lower address (causing a transition to the Non-Querier state)
continues to send multicast-address-specific queries for the group in
question until it either receives a Report or its timer expires, at
which time it starts performing the actions of a Non-Querier for this
group.
<span class="grey">Deering, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
The state transition diagram for a router in Querier state follows:
________________
| |
| |timer expired
timer expired| |(notify routing -,
(notify routing -)| No Listeners |clear rxmt tmr)
------->| Present |<---------
| | | |
| | | |
| |________________| | ---------------
| | | | rexmt timer |
| report received| | | expired |
| (notify routing +,| | | (send m-a-s |
| start timer)| | | query, |
__________|______ | ________|_|______ st rxmt |
| |<------------ | | tmr) |
| | | |<-------
| | report received | |
| | (start timer, | |
| | clear rxmt tmr) | |
| Listeners |<-------------------| Checking |
| Present | done received | Listeners |
| | (start timer*, | |
| | start rxmt timer, | |
| | send m-a-s query) | |
--->| |------------------->| |
| |_________________| |_________________|
| report received |
| (start timer) |
-----------------
<span class="grey">Deering, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
The state transition diagram for a router in Non-Querier state is
similar, but non-Queriers do not send any messages and are only
driven by message reception.
________________
| |
| |
timer expired| |timer expired
(notify routing -)| No Listeners |(notify routing -)
--------->| Present |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| |report received |
| |(notify routing +,|
| | start timer) |
________|________ | ________|________
| |<--------- | |
| | report received | |
| | (start timer) | |
| Listeners |<-------------------| Checking |
| Present | m-a-s query rec'd | Listeners |
| | (start timer*) | |
---->| |------------------->| |
| |_________________| |_________________|
| report received |
| (start timer) |
-----------------
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. List of timers and default values</span>
Most of these timers are configurable. If non-default settings are
used, they MUST be consistent among all routers on a single link.
Note that parentheses are used to group expressions to make the
algebra clear.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Robustness Variable</span>
The Robustness Variable allows tuning for the expected packet loss on
a link. If a link is expected to be lossy, the Robustness Variable
may be increased. MLD is robust to (Robustness Variable - 1) packet
losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be
one. Default: 2
<span class="grey">Deering, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Query Interval</span>
The Query Interval is the interval between General Queries sent by
the Querier. Default: 125 seconds.
By varying the [Query Interval], an administrator may tune the number
of MLD messages on the link; larger values cause MLD Queries to be
sent less often.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Query Response Interval</span>
The Maximum Response Delay inserted into the periodic General
Queries. Default: 10000 (10 seconds)
By varying the [Query Response Interval], an administrator may tune
the burstiness of MLD messages on the link; larger values make the
traffic less bursty, as node responses are spread out over a larger
interval. The number of seconds represented by the [Query Response
Interval] must be less than the [Query Interval].
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Multicast Listener Interval</span>
The Multicast Listener Interval is the amount of time that must pass
before a router decides there are no more listeners for an address on
a link. This value MUST be ((the Robustness Variable) times (the
Query Interval)) plus (one Query Response Interval).
<span class="h3"><a class="selflink" id="section-7.5" href="#section-7.5">7.5</a>. Other Querier Present Interval</span>
The Other Querier Present Interval is the length of time that must
pass before a router decides that there is no longer another router
which should be the querier on a link. This value MUST be ((the
Robustness Variable) times (the Query Interval)) plus (one half of
one Query Response Interval).
<span class="h3"><a class="selflink" id="section-7.6" href="#section-7.6">7.6</a>. Startup Query Interval</span>
The Startup Query Interval is the interval between General Queries
sent by a Querier on startup. Default: 1/4 the Query Interval.
<span class="h3"><a class="selflink" id="section-7.7" href="#section-7.7">7.7</a>. Startup Query Count</span>
The Startup Query Count is the number of Queries sent out on startup,
separated by the Startup Query Interval. Default: the Robustness
Variable.
<span class="grey">Deering, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
<span class="h3"><a class="selflink" id="section-7.8" href="#section-7.8">7.8</a>. Last Listener Query Interval</span>
The Last Listener Query Interval is the Maximum Response Delay
inserted into Multicast-Address-Specific Queries sent in response to
Done messages, and is also the amount of time between Multicast-
Address-Specific Query messages. Default: 1000 (1 second)
This value may be tuned to modify the "leave latency" of the link. A
reduced value results in reduced time to detect the departure of the
last listener for an address.
<span class="h3"><a class="selflink" id="section-7.9" href="#section-7.9">7.9</a>. Last Listener Query Count</span>
The Last Listener Query Count is the number of Multicast-Address-
Specific Queries sent before the router assumes there are no
remaining listeners for an address on a link. Default: the
Robustness Variable.
<span class="h3"><a class="selflink" id="section-7.10" href="#section-7.10">7.10</a>. Unsolicited Report Interval</span>
The Unsolicited Report Interval is the time between repetitions of a
node's initial report of interest in a multicast address. Default:
10 seconds.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Message Destinations</span>
This information is provided elsewhere in the document, but is
summarized here for convenience.
Message Type IPv6 Destination Address
------------ ------------------------
General Query link-scope all-nodes (FF02::1)
Multicast-Address-Specific Query the multicast address being queried
Report the multicast address being reported
Done link-scope all-routers (FF02::2)
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
We consider the ramifications of a forged message of each type. Note
that the requirement that nodes verify that the IPv6 Source Address
of all received MLD messages is a link-local address defends them
from acting on forged MLD messages originated off-link, so we discuss
only the effects of on-link forgery.
<span class="grey">Deering, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
Query message:
A forged Query message from a machine with a lower IP address
than the current Querier will cause Querier duties to be
assigned to the forger. If the forger then sends no more Query
messages, other routers' Other Querier Present timer will time
out and one will resume the role of Querier. During this time,
if the forger ignores Done messages, traffic might flow to
addresses with no listeners for up to [Multicast Listener
Interval].
A forged Query message sent to an address with listeners will
cause one or more nodes that are listeners to that address to
send a Report. This causes a small amount of extra traffic on
the link, but causes no protocol problems.
Report message:
A forged Report message may cause routers to think there are
listeners for an address present on a link when there are not.
However, since listening to a multicast address is generally an
unprivileged operation, a local user may trivially gain the same
result without forging any messages.
Done message:
A forged Done message will cause the Querier to send out
Multicast-Address-Specific Queries for the address in question.
This causes extra processing on each router and on each of the
address's listeners, and extra packets on the link, but cannot
cause loss of desired traffic.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
MLD was derived from IGMPv2 [<a href="#ref-IGMPv2" title=""Internet Group Management Protocol, Version 2"">IGMPv2</a>], which was designed by Rosen
Sharma and Steve Deering and documented by Bill Fenner.
<span class="grey">Deering, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
[<a id="ref-ADDR-ARCH">ADDR-ARCH</a>] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", <a href="./rfc2373">RFC 2373</a>, July 1998.
[<a id="ref-ICMPv6">ICMPv6</a>] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", <a href="./rfc2463">RFC 2463</a>, December 1998.
[<a id="ref-IGMPv2">IGMPv2</a>] Fenner, W., "Internet Group Management Protocol, Version
2", <a href="./rfc2236">RFC 2236</a>, November 1997.
[<a id="ref-IPv6">IPv6</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-IPv6-ETHER">IPv6-ETHER</a>] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", <a href="./rfc2464">RFC 2464</a>, December, 1998.
[<a id="ref-KEYWORDS">KEYWORDS</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RTR-ALERT">RTR-ALERT</a>] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option", <a href="./rfc2711">RFC 2711</a>, October 1999.
[<a id="ref-STD-PROC">STD-PROC</a>] Bradner, S., "The Internet Standards Process -- Revision
3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.
<span class="grey">Deering, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Authors' Addresses</span>
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 527 8213
EMail: deering@cisco.com
William C. Fenner
AT&T Research
75 Willow Road
Menlo Park, CA 94025
USA
Phone: +1 650 867 6073
EMail: fenner@research.att.com
Brian Haberman
IBM Corporation
800 Park Office Drive
Research Triangle Park, NC 27709
USA
Phone: +1 919 254 2673
EMail: haberman@raleigh.ibm.com
<span class="grey">Deering, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc2710">RFC 2710</a> Multicast Listener Discovery for IPv6 October 1999</span>
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Deering, et al. Standards Track [Page 22]
</pre>
|
