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
|
<pre>Network Working Group H. Holbrook
Request for Comments: 4607 Arastra, Inc.
Category: Standards Track B. Cain
Acopia Networks
August 2006
<span class="h1">Source-Specific Multicast for IP</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 (2006).
Abstract
IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to
232.255.255.255) range are designated as source-specific multicast
(SSM) destination addresses and are reserved for use by source-
specific applications and protocols. For IP version 6 (IPv6), the
address prefix FF3x::/32 is reserved for source-specific multicast
use. This document defines an extension to the Internet network
service that applies to datagrams sent to SSM addresses and defines
the host and router requirements to support this extension.
<span class="grey">Holbrook & Cain Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Semantics of Source-Specific Multicast Addresses ................<a href="#page-5">5</a>
<a href="#section-3">3</a>. Terminology .....................................................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Host Requirements ...............................................<a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. Extensions to the IP Module Interface ......................<a href="#page-7">7</a>
<a href="#section-4.2">4.2</a>. Requirements on the Host IP Module .........................<a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. Allocation of Source-Specific Multicast Addresses ..........<a href="#page-9">9</a>
<a href="#section-5">5</a>. Router Requirements ............................................<a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. Packet Forwarding .........................................<a href="#page-10">10</a>
<a href="#section-5.2">5.2</a>. Protocols .................................................<a href="#page-10">10</a>
<a href="#section-6">6</a>. Link-Layer Transmission of Datagrams ...........................<a href="#page-11">11</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-7.1">7.1</a>. IPsec and SSM .............................................<a href="#page-12">12</a>
<a href="#section-7.2">7.2</a>. SSM and <a href="./rfc2401">RFC 2401</a> IPsec Caveats ............................<a href="#page-12">12</a>
<a href="#section-7.3">7.3</a>. Denial of Service .........................................<a href="#page-13">13</a>
<a href="#section-7.4">7.4</a>. Spoofed Source Addresses ..................................<a href="#page-13">13</a>
<a href="#section-7.5">7.5</a>. Administrative Scoping ....................................<a href="#page-14">14</a>
<a href="#section-8">8</a>. Transition Considerations ......................................<a href="#page-14">14</a>
<a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-15">15</a>
<a href="#section-10">10</a>. Acknowledgements ..............................................<a href="#page-15">15</a>
<a href="#section-11">11</a>. Normative References ..........................................<a href="#page-16">16</a>
<a href="#section-12">12</a>. Informative References ........................................<a href="#page-17">17</a>
<span class="grey">Holbrook & Cain Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Internet Protocol (IP) multicast service model is defined in <a href="./rfc1112">RFC</a>
<a href="./rfc1112">1112</a> [<a href="./rfc1112" title=""Host extensions for IP multicasting"">RFC1112</a>]. <a href="./rfc1112">RFC 1112</a> specifies that a datagram sent to an IP
multicast address (224.0.0.0 through 239.255.255.255) G is delivered
to each "upper-layer protocol module" that has requested reception of
datagrams sent to address G. <a href="./rfc1112">RFC 1112</a> calls the network service
identified by a multicast destination address G a "host group". This
model supports both one-to-many and many-to-many group communication.
This document uses the term "Any-Source Multicast" (ASM) to refer to
model of multicast defined in <a href="./rfc1112">RFC 1112</a>. <a href="./rfc3513">RFC 3513</a> [<a href="./rfc3513" title=""Internet Protocol Version 6 (IPv6) Addressing Architecture"">RFC3513</a>] specifies
the form of IPv6 multicast addresses with ASM semantics.
IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are
currently designated as source-specific multicast (SSM) destination
addresses and are reserved for use by source-specific applications
and protocols [<a href="#ref-IANA-ALLOC">IANA-ALLOC</a>].
For IPv6, the address prefix FF3x::/32 is reserved for source-
specific multicast use, where 'x' is any valid scope identifier, by
[<a href="#ref-IPv6-UBM" title=""Unicast-Prefix-based IPv6 Multicast Addresses"">IPv6-UBM</a>]. Using the terminology of [<a href="#ref-IPv6-UBM" title=""Unicast-Prefix-based IPv6 Multicast Addresses"">IPv6-UBM</a>], all SSM addresses
must have P=1, T=1, and plen=0. [<a href="#ref-IPv6-MALLOC" title=""Allocation Guidelines for IPv6 Multicast Addresses"">IPv6-MALLOC</a>] mandates that the
network prefix field of an SSM address also be set to zero, hence all
SSM addresses fall in the FF3x::/96 range. Future documents may
allow a non-zero network prefix field if, for instance, a new IP-
address-to-MAC-address mapping is defined. Thus, address allocation
should occur within the FF3x::/96 range, but a system should treat
all of FF3x::/32 as SSM addresses, to allow for compatibility with
possible future uses of the network prefix field.
Addresses in the range FF3x::4000:0001 through FF3x::7FFF:FFFF are
reserved in [<a href="#ref-IPv6-MALLOC" title=""Allocation Guidelines for IPv6 Multicast Addresses"">IPv6-MALLOC</a>] for allocation by IANA. Addresses in the
range FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic
allocation by a host, as described in [<a href="#ref-IPv6-MALLOC" title=""Allocation Guidelines for IPv6 Multicast Addresses"">IPv6-MALLOC</a>]. Addresses in
the range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6
SSM addresses. ([<a href="#ref-IPv6-MALLOC" title=""Allocation Guidelines for IPv6 Multicast Addresses"">IPv6-MALLOC</a>] indicates that FF3x::0000:0001 to
FF3x::3FFF:FFFF must set P=0 and T=0, but for SSM, [<a href="#ref-IPv6-UBM" title=""Unicast-Prefix-based IPv6 Multicast Addresses"">IPv6-UBM</a>]
mandates that P=1 and T=1, hence their designation as invalid.) The
treatment of a packet sent to such an invalid address is undefined --
a router or host MAY choose to drop such a packet.
Source-specific multicast delivery semantics are provided for a
datagram sent to an SSM address. That is, a datagram with source IP
address S and SSM destination address G is delivered to each upper-
layer "socket" that has specifically requested the reception of
datagrams sent to address G by source S, and only to those sockets.
The network service identified by (S,G), for SSM address G and source
<span class="grey">Holbrook & Cain Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
host address S, is referred to as a "channel". In contrast to the
ASM model of <a href="./rfc1112">RFC 1112</a>, SSM provides network-layer support for one-
to-many delivery only.
The benefits of source-specific multicast include:
Elimination of cross-delivery of traffic when two sources
simultaneously use the same source-specific destination address.
The simultaneous use of an SSM destination address by multiple
sources and different applications is explicitly supported.
Avoidance of the need for inter-host coordination when choosing
source-specific addresses, as a consequence of the above.
Avoidance of many of the router protocols and algorithms that are
needed to provide the ASM service model. For instance, the
"shared trees" and Rendezvous Points of the PIM - Sparse Mode
(PIM-SM) protocol [<a href="#ref-PIM-SM" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">PIM-SM</a>] are not necessary to support the
source-specific model. The router mechanisms required to support
SSM are in fact largely a subset of those that are used to support
ASM. For example, the shortest-path tree mechanism of the PIM-SM
protocol can be adapted to provide SSM semantics.
Like ASM, the set of receivers is unknown to an SSM sender. An SSM
source is provided with neither the identity of receivers nor their
number.
SSM is particularly well-suited to dissemination-style applications
with one or more senders whose identities are known before the
application begins. For instance, a data dissemination application
that desires to provide a secondary data source in case the primary
source fails over might implement this by using one channel for each
source and advertising both of them to receivers. SSM can be used to
build multi-source applications where all participants' identities
are not known in advance, but the multi-source "rendezvous"
functionality does not occur in the network layer in this case. Just
like in an application that uses unicast as the underlying transport,
this functionality can be implemented by the application or by an
application-layer library.
Multicast resource discovery of the form in which a client sends a
multicast query directly to a "service location group" to which
servers listen is not directly supported by SSM.
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="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Holbrook & Cain Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
This document defines the semantics of source-specific multicast
addresses and specifies the policies governing their use. In
particular, it defines an extension to the Internet network service
that applies to datagrams sent to SSM addresses and defines host
extensions to support the network service. Hosts, routers,
applications, and protocols that use these addresses MUST comply with
the policies outlined in this document. Failure of a host to comply
may prevent that host or other hosts on the same LAN from receiving
traffic sent to an SSM channel. Failure of a router to comply may
cause SSM traffic to be delivered to parts of the network where it is
unwanted, unnecessarily burdening the network.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Semantics of Source-Specific Multicast Addresses</span>
The source-specific multicast service is defined as follows:
A datagram sent with source IP address S and destination IP
address G in the SSM range is delivered to each host socket that
has specifically requested delivery of datagrams sent by S to G,
and only to those sockets.
Where, using the terminology of [<a href="#ref-IGMPv3" title=""Internet Group Management Protocol, Version 3"">IGMPv3</a>],
"socket" is an implementation-specific parameter used to
distinguish among different requesting entities (e.g., programs or
processes or communication end-points within a program or process)
within the requesting host; the socket parameter of BSD Unix
system calls is a specific example.
Any host may send a datagram to any SSM address, and delivery is
provided according to the above semantics.
The IP module interface to upper-layer protocols is extended to allow
a socket to "Subscribe" to or "Unsubscribe" from a particular channel
identified by an SSM destination address and a source IP address.
The extended interface is defined in <a href="#section-4.1">Section 4.1</a>. It is meaningless
for an application or host to request reception of datagrams sent to
an SSM destination address G, as is supported in the any-source
multicast model, without also specifying a corresponding source
address, and routers MUST ignore any such request.
Multiple source applications on different hosts can use the same SSM
destination address G without conflict because datagrams sent by each
source host Si are delivered only to those sockets that requested
delivery of datagrams sent to G specifically by Si.
<span class="grey">Holbrook & Cain Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
The key distinguishing property of the model is that a channel is
identified (addressed) by the combination of a unicast source address
and a multicast destination address in the SSM range. So, for
example, the channel
S,G = (192.0.2.1, 232.7.8.9)
differs from
S,G = (192.0.2.2, 232.7.8.9),
even though they have the same destination address portion.
Similarly, for IPv6,
S,G = (2001:3618::1, FF33::1234)
and
S,G = (2001:3618::2, FF33::1234)
are different channels.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
To reduce confusion when talking about the any-source and source-
specific multicast models, we use different terminology when
discussing them.
We use the term "channel" to refer to the service associated with an
SSM address. A channel is identified by the combination of an SSM
destination address and a specific source, e.g., an (S,G) pair.
We use the term "host group" (used in <a href="./rfc1112">RFC 1112</a>) to refer to the
service associated with "regular" ASM multicast addresses (excluding
those in the SSM range). A host group is identified by a single
multicast address.
Any host can send to a host group, and similarly, any host can send
to an SSM destination address. A packet sent by a host S to an ASM
destination address G is delivered to the host group identified by G.
A packet sent by host S to an SSM destination address G is delivered
to the channel identified by (S,G). The receiver operations allowed
on a host group are called "join(G)" and "leave(G)" (as per <a href="./rfc1112">RFC</a>
<a href="./rfc1112">1112</a>). The receiver operations allowed on a channel are called
"Subscribe(S,G)" and "Unsubscribe(S,G)".
<span class="grey">Holbrook & Cain Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
The following table summarizes the terminology:
Service Model: any-source source-specific
Network Abstraction: group channel
Identifier: G S,G
Receiver Operations: Join, Leave Subscribe, Unsubscribe
We note that, although this document specifies a new service model
available to applications, the protocols and techniques necessary to
support the service model are largely a subset of those used to
support ASM.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Host Requirements</span>
This section describes requirements on hosts that support source-
specific multicast, including:
- Extensions to the IP Module Interface
- Extensions to the IP Module
- Allocation of SSM Addresses
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Extensions to the IP Module Interface</span>
The IP module interface to upper-layer protocols is extended to allow
protocols to request reception of all datagrams sent to a particular
channel.
Subscribe ( socket, source-address, group-address, interface )
Unsubscribe ( socket, source-address, group-address, interface )
where
"socket" is as previously defined in <a href="#section-2">Section 2</a>,
and, paraphrasing [<a href="#ref-IGMPv3" title=""Internet Group Management Protocol, Version 3"">IGMPv3</a>],
"interface" is a local identifier of the network interface on
which reception of the channel identified by the (source-
address,group-address) pair is to be enabled or disabled. A
special value may be used to indicate a "default" interface. If
reception of the same channel is desired on multiple interfaces,
Subscribe is invoked once for each.
<span class="grey">Holbrook & Cain Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
The above are strictly abstract functional interfaces -- the
functionality can be provided in an implementation-specific way. On
a host that supports the multicast source filtering application
programming interface of [<a href="#ref-MSFAPI" title=""Socket Interface Extensions for Multicast Source Filters"">MSFAPI</a>], for instance, the Subscribe and
Unsubscribe interfaces may be supported via that API. When a host
has been configured to know the SSM address range (whether the
configuration mechanism is manual or through a protocol), the host's
operating system SHOULD return an error to an application that makes
a non-source-specific request to receive multicast sent to an SSM
destination address.
A host that does not support these IP module interfaces (e.g., ASM-
only hosts) and their underlying protocols cannot expect to reliably
receive traffic sent on an SSM channel. As specified below in
<a href="#section-5.2">Section 5.2</a>, routers will not set up SSM forwarding state or forward
datagrams in response to an ASM join request.
Widespread implementations of the IP packet reception interface
(e.g., the recvfrom() system call in BSD Unix) do not allow a
receiver to determine the destination address to which a datagram was
sent. On a host with such an implementation, the destination address
of a datagram cannot be inferred when the socket on which the
datagram is received is Subscribed to multiple channels. Host
operating systems SHOULD provide a way for a host to determine both
the source and the destination address to which a datagram was sent.
(As one example, the Linux operating system provides the destination
of a packet as part of the response to the recvmsg() system call.)
Until this capability is present, applications may be forced to use
higher-layer mechanisms to identify the channel to which a datagram
was sent.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Requirements on the Host IP Module</span>
An incoming datagram destined to an SSM address MUST be delivered by
the IP module to all sockets that have indicated (via Subscribe) a
desire to receive data that matches the datagram's source address,
destination address, and arriving interface. It MUST NOT be
delivered to other sockets.
When the first socket on host H subscribes to a channel (S,G) on
interface I, the host IP module on H sends a request on interface I
to indicate to neighboring routers that the host wishes to receive
traffic sent by source S to source-specific multicast destination G.
Similarly, when the last socket on a host unsubscribes from a channel
on interface I, the host IP module sends an unsubscription request
for that channel to interface I.
<span class="grey">Holbrook & Cain Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
These requests will typically be Internet Group Management Protocol
version 3 (IGMPv3) messages for IPv4, or Multicast Listener Discovery
Version 2 (MLDv2) messages for IPv6 [<a href="#ref-IGMPv3" title=""Internet Group Management Protocol, Version 3"">IGMPv3</a>,<a href="#ref-MLDv2" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">MLDv2</a>]. A host that
supports the SSM service model MUST implement the host portion of
[<a href="#ref-IGMPv3" title=""Internet Group Management Protocol, Version 3"">IGMPv3</a>] for IPv4 and [<a href="#ref-MLDv2" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">MLDv2</a>] for IPv6. It MUST also conform to the
IGMPv3/MLDv2 behavior described in [<a href="#ref-GMP-SSM" title=""Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast"">GMP-SSM</a>].
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Allocation of Source-Specific Multicast Addresses</span>
The SSM destination address 232.0.0.0 is reserved, and it must not be
used as a destination address. Similarly, FF3x::4000:0000 is also
reserved. The goal of reserving these two addresses is to preserve
one invalid SSM destination for IPv4 and IPv6, which can be useful in
an implementation as a null value. The address range 232.0.0.1 -
232.0.0.255 is currently reserved for allocation by IANA. SSM
destination addresses in the range FF3x::4000:0001 through
FF3x::7FFF:FFFF are similarly reserved for IANA allocation
[<a href="#ref-IPv6-MALLOC" title=""Allocation Guidelines for IPv6 Multicast Addresses"">IPv6-MALLOC</a>]. The motivation to reserve these addresses is outlined
below in <a href="#section-9">Section 9</a>, "IANA Considerations".
The policy for allocating the rest of the SSM addresses to sending
applications is strictly locally determined by the sending host.
When allocating SSM addresses dynamically, a host or host operating
system MUST NOT allocate sequentially starting at the first allowed
address. It is RECOMMENDED to allocate SSM addresses to applications
randomly, while ensuring that allocated addresses are not given
simultaneously to multiple applications (and avoiding the reserved
addresses). For IPv6, the randomization should apply to the lowest
31 bits of the address.
As described in <a href="#section-6">Section 6</a>, the mapping of an IP packet with SSM
destination address onto a link-layer multicast address does not take
into account the datagram's source IP address (on commonly-used link
layers like Ethernet). If all hosts started at the first allowed
address, then with high probability, many source-specific channels on
shared-medium local area networks would use the same link-layer
multicast address. As a result, traffic destined for one channel
subscriber would be delivered to another's IP module, which would
then have to discard the datagram.
A host operating system SHOULD provide an interface to allow an
application to request a unique allocation of a channel destination
address in advance of a session's commencement, and this allocation
database SHOULD persist across host reboots. By providing persistent
allocations, a host application can advertise the session in advance
<span class="grey">Holbrook & Cain Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
of its start time on a web page or in another directory. (We note
that this issue is not specific to SSM applications -- the same
problem arises for ASM.)
This document neither defines the interfaces for requesting or
returning addresses nor specifies the host algorithms for storing
those allocations. One plausible abstract API is defined in <a href="./rfc2771">RFC 2771</a>
[<a href="./rfc2771" title=""An Abstract API for Multicast Address Allocation"">RFC2771</a>]. Note that <a href="./rfc2771">RFC 2771</a> allows an application to request an
address within a specific range of addresses. If this interface is
used, the starting address of the range SHOULD be selected at random
by the application.
For IPv6, administratively scoped SSM channel addresses are created
by choosing an appropriate scope identifier for the SSM destination
address. Normal IPv6 multicast scope boundaries [<a href="#ref-SCOPINGv6" title=""IPv6 Scoped Address Architecture"">SCOPINGv6</a>] are
applied to traffic sent to an SSM destination address, including any
relevant boundaries applied to both the source and destination
address.
No globally agreed-upon administratively-scoped address range
[<a href="#ref-ADMIN-SCOPE" title=""Administratively Scoped IP Multicast"">ADMIN-SCOPE</a>] is currently defined for IPv4 source-specific
multicast. For IPv4, administrative scoping of SSM addresses can be
implemented within an administrative domain by filtering outgoing SSM
traffic sent to a scoped address at the domain's boundary routers.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Router Requirements</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Packet Forwarding</span>
A router that receives an IP datagram with a source-specific
destination address MUST silently drop it unless a neighboring host
or router has communicated a desire to receive packets sent from the
source and to the destination address of the received packet.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Protocols</span>
Certain IP multicast routing protocols already have the ability to
communicate source-specific joins to neighboring routers (in
particular, PIM-SM [<a href="#ref-PIM-SM" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">PIM-SM</a>]), and these protocols can, with slight
modifications, be used to provide source-specific semantics. A
router that supports the SSM service model MUST implement the PIM-SSM
subset of the PIM-SM protocol from [<a href="#ref-PIM-SM" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">PIM-SM</a>] and MUST implement the
router portion of [<a href="#ref-IGMPv3" title=""Internet Group Management Protocol, Version 3"">IGMPv3</a>] for IPv4 and [<a href="#ref-MLDv2" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">MLDv2</a>] for IPv6. An SSM
router MUST also conform to the IGMPv3/MLDv2 behavior described in
[<a href="#ref-GMP-SSM" title=""Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast"">GMP-SSM</a>].
<span class="grey">Holbrook & Cain Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
With PIM-SSM, successful establishment of an (S,G) forwarding path
from the source S to any receiver depends on hop-by-hop forwarding of
the explicit join request from the receiver toward the source. The
protocol(s) and algorithms that are used to select the forwarding
path for this explicit join must provide a loop-free path. When
using PIM-SSM, the PIM-SSM implementation MUST (at least) support the
ability to use the unicast topology database for this purpose.
A network can concurrently support SSM in the SSM address range and
any-source multicast in the rest of the multicast address space, and
it is expected that this will be commonplace. In such a network, a
router may receive a non-source-specific, or "(*,G)" in conventional
terminology, request for delivery of traffic in the SSM range from a
neighbor that does not implement source-specific multicast in a
manner compliant with this document. A router that receives such a
non-source-specific request for data in the SSM range MUST NOT use
the request to establish forwarding state and MUST NOT propagate the
request to other neighboring routers. A router MAY log an error in
such a case. This applies both to any request received from a host
(e.g., an IGMPv1 or IGMPv2 [<a href="#ref-IGMPv2" title=""Internet Group Management Protocol, Version 2"">IGMPv2</a>] host report) and to any request
received from a routing protocol (e.g., a PIM-SM (*,G) join). The
inter-router case is further discussed in <a href="#section-8">Section 8</a>, "Transition
Considerations".
It is essential that all routers in the network give source-specific
semantics to the same range of addresses in order to achieve the full
benefit of SSM. To comply with this specification, a router MUST
treat ALL IANA-allocated SSM addresses with source-specific
semantics.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Link-Layer Transmission of Datagrams</span>
Source-specific multicast packets are transmitted on link-layer
networks as specified in <a href="./rfc1112">RFC 1112</a> for IPv4 and as in [<a href="#ref-ETHERv6" title=""Transmission of IPv6 Packets over Ethernet Networks"">ETHERv6</a>] for
IPv6. On most shared-medium link-layer networks that support
multicast (e.g., Ethernet), the IP source address is not used in the
selection of the link-layer destination address. Consequently, on
such a network, all packets sent to destination address G will be
delivered to any host that has subscribed to any channel (S,G),
regardless of S. Therefore, the IP module MUST filter packets it
receives from the link layer before delivering them to the socket
layer.
<span class="grey">Holbrook & Cain Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
This section outlines security issues pertaining to SSM. The
following topics are addressed: IPsec, denial-of-service attacks,
source spoofing, and security issues related to administrative
scoping.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. IPsec and SSM</span>
The IPsec Authentication Header (AH) and Encapsulating Security
Payload (ESP) can be used to secure SSM traffic, if a multicast-
capable implementation of IPsec (as required in [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>]) is used by
the receivers.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. SSM and <a href="./rfc2401">RFC 2401</a> IPsec Caveats</span>
For existing implementations of <a href="./rfc2401">RFC 2401</a> IPsec (now superseded by
[<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>]), there are a few caveats related to SSM. They are listed
here. In <a href="./rfc2401">RFC 2401</a> IPsec, the source address is not used as part of
the key in the SAD lookup. As a result, two senders that happen to
use the same SSM destination address and the same Security Parameter
Index (SPI) will "collide" in the SAD at any host that is receiving
both channels. Because the channel addresses and SPIs are both
allocated autonomously by the senders, there is no reasonable means
to ensure that each sender uses a unique destination address or SPI.
A problem arises if a receiver subscribes simultaneously to two
unrelated channels using IPsec whose sources happen to be using the
same IP destination address (IPDA) and the same IPsec SPI. Because
the channel destination addresses are allocated autonomously by the
senders, any two hosts can simultaneously use the same destination
address, and there is no reasonable means to ensure that this does
not happen. The <IPDA,SPI> tuple, however, consists of 56 bits that
are generally randomly chosen (24 bits of the IP destination and 32
bits of the SPI), and a conflict is unlikely to occur through random
chance.
If such a collision occurs, a receiver will not be able to
simultaneously receive IPsec-protected traffic from the two colliding
sources. A receiver can detect this condition by noticing that it is
receiving traffic from two different sources with the same SPI and
the same SSM destination address.
<span class="grey">Holbrook & Cain Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Denial of Service</span>
A subscription request creates (S,G) state in a router to record the
subscription, invokes processing on that router, and possibly causes
processing at neighboring routers. A host can mount a denial-of-
service attack by requesting a large number of subscriptions. Denial
of service can result if:
- a large amount of traffic arrives when it was otherwise
undesired, consuming network resources to deliver it and host
resources to drop it;
- a large amount of source-specific multicast state is created in
network routers, using router memory and CPU resources to store
and process the state; or
- a large amount of control traffic is generated to manage the
source-specific state, using router CPU and network bandwidth.
To reduce the damage from such an attack, a router MAY have
configuration options to limit, for example, the following items:
- The total rate at which all hosts on any one interface are
allowed to initiate subscriptions (to limit the damage caused by
forged source-address attacks).
- The total number of subscriptions that can be initiated from any
single interface or host.
Any decision by an implementor to artificially limit the rate or
number of subscriptions should be taken carefully, however, as future
applications may use large numbers of channels. Tight limits on the
rate or number of channel subscriptions would inhibit the deployment
of such applications.
A router SHOULD verify that the source of a subscription request is a
valid address for the interface on which it was received. Failure to
do so would exacerbate a spoofed-source address attack.
We note that these attacks are not unique to SSM -- they are also
present for any-source multicast.
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Spoofed Source Addresses</span>
By forging the source address in a datagram, an attacker can
potentially violate the SSM service model by transmitting datagrams
on a channel belonging to another host. Thus, an application
requiring strong authentication should not assume that all packets
<span class="grey">Holbrook & Cain Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
that arrive on a channel were sent by the requested source without
higher-layer authentication mechanisms. The IPSEC Authentication
Header [RFC2401, <a href="./rfc4301">RFC4301</a>] may be used to authenticate the source of
an SSM transmission, for instance.
Some degree of protection against spoofed source addresses in
multicast is already fairly widespread, because the commonly deployed
IP multicast routing protocols [<a href="#ref-PIM-DM" title=""Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)"">PIM-DM</a>, <a href="#ref-PIM-SM" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">PIM-SM</a>, <a href="#ref-DVMRP" title=""Distance Vector Multicast Routing Protocol"">DVMRP</a>] incorporate a
"reverse-path forwarding check" that validates that a multicast
packet arrived on the expected interface for its source address.
Routing protocols used for SSM SHOULD incorporate such a check.
Source Routing [<a href="./rfc791" title=""Internet Protocol"">RFC791</a>] (both Loose and Strict) in combination with
source address spoofing may be used to allow an impostor of the true
channel source to inject packets onto an SSM channel. An SSM router
SHOULD by default disallow source routing to an SSM destination
address. A router MAY have a configuration option to allow source
routing. Anti-source spoofing mechanisms, such as source address
filtering at the edges of the network, are also strongly encouraged.
<span class="h3"><a class="selflink" id="section-7.5" href="#section-7.5">7.5</a>. Administrative Scoping</span>
Administrative scoping should not be relied upon as a security
measure [<a href="#ref-ADMIN-SCOPE" title=""Administratively Scoped IP Multicast"">ADMIN-SCOPE</a>]; however, in some cases it is part of a
security solution. It should be noted that no administrative scoping
exists for IPv4 source-specific multicast. An alternative approach
is to manually configure traffic filters to create such scoping if
necessary.
Furthermore, for IPv6, neither source nor destination address scoping
should be used as a security measure. In some currently-deployed
IPv6 routers (those that do not conform to [<a href="#ref-SCOPINGv6" title=""IPv6 Scoped Address Architecture"">SCOPINGv6</a>]), scope
boundaries are not always applied to all source address (for
instance, an implementation may filter link-local addresses but
nothing else). Such a router may incorrectly forward an SSM channel
(S,G) through a scope boundary for S.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Transition Considerations</span>
A host that complies with this document will send ONLY source-
specific host reports for addresses in the SSM range. As stated
above, a router that receives a non-source-specific (e.g., IGMPv1 or
IGMPv2 or MLDv1 [<a href="./rfc2710" title=""Multicast Listener Discovery (MLD) for IPv6"">RFC2710</a>]) host report for a source-specific
multicast destination address MUST ignore these reports. Failure to
do so would violate the SSM service model promised to the sender:
that a packet sent to (S,G) would only be delivered to hosts that
specifically requested delivery of packets sent to G by S.
<span class="grey">Holbrook & Cain Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
During a transition period, it would be possible to deliver SSM
datagrams in a domain where the routers do not support SSM semantics
by simply forwarding any packet destined to G to all hosts that have
requested subscription of (S,G) for any S. However, this
implementation risks unduly burdening the network infrastructure by
delivering (S,G) datagrams to hosts that did not request them. Such
an implementation for addresses in the SSM range is specifically not
compliant with <a href="#section-5.2">Section 5.2</a> of this document.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
IANA allocates IPv4 addresses in the range 232.0.0.1 through
232.0.0.255 and IPv6 addresses in the range FF3x:4000:0001 to
FF3x::7FFF:FFFF. These addresses are allocated according to IETF
Consensus [<a href="#ref-IANA-CONSID" title="">IANA-CONSID</a>]. These address ranges are reserved for
services with wide applicability that either require that or would
strongly benefit if all hosts use a well-known SSM destination
address for that service. Any proposal for allocation must consider
the fact that, on an Ethernet network, all datagrams sent to any SSM
destination address will be transmitted with the same link-layer
destination address, regardless of the source. Furthermore, the fact
that SSM destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same
link-layer addresses as the reserved IP multicast group range
224.0.0.0/24 must also be considered. Similar consideration should
be given to the IPv6 reserved multicast addresses. 232.0.0.0 and
FF3x::4000:0000 should not be allocated, as suggested above.
Except for the aforementioned addresses, IANA SHALL NOT allocate any
SSM destination address to a particular entity or application. To do
so would compromise one of the important benefits of the source-
specific model: the ability for a host to simply and autonomously
allocate a source-specific multicast address from a large flat
address space.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
The SSM service model draws on a variety of prior work on alternative
approaches to IP multicast, including the EXPRESS multicast model of
Holbrook and Cheriton [<a href="#ref-EXPRESS" title=""Explicitly Requested Source-Specific Multicast: EXPRESS support for Large- scale Single-source Applications."">EXPRESS</a>], Green's [<a href="#ref-SMRP" title=""Method and System of Multicast Routing for Groups with a Single Transmitter."">SMRP</a>], and the Simple
Multicast proposal of Perlman, et al. [<a href="#ref-SIMPLE" title=""Simple Multicast: A Design for Simple, Low-Overhead Multicast"">SIMPLE</a>]. We would also like
to thank Jon Postel and David Cheriton for their support in
reassigning the 232/8 address range to SSM. Brian Haberman
contributed to the IPv6 portion of this document. Thanks to Pekka
Savola for a careful review.
<span class="grey">Holbrook & Cain Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Normative References</span>
[<a id="ref-ETHERv6">ETHERv6</a>] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", <a href="./rfc2464">RFC 2464</a>, December 1998.
[<a id="ref-GMP-SSM">GMP-SSM</a>] Holbrook, H. and B. Cain, "Using Internet Group
Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for
Source-Specific Multicast", <a href="./rfc4604">RFC 4604</a>, August 2006.
[<a id="ref-IGMPv3">IGMPv3</a>] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", <a href="./rfc3376">RFC 3376</a>, October 2002.
[<a id="ref-IPv6-UBM">IPv6-UBM</a>] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", <a href="./rfc3306">RFC 3306</a>, August 2002.
[<a id="ref-IPv6-MALLOC">IPv6-MALLOC</a>] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", <a href="./rfc3307">RFC 3307</a>, August 2002.
[<a id="ref-MLDv2">MLDv2</a>] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", <a href="./rfc3810">RFC 3810</a>, June 2004.
[<a id="ref-PIM-SM">PIM-SM</a>] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas.
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", <a href="./rfc4601">RFC 4601</a>, August
2006.
[<a id="ref-RFC791">RFC791</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
September 1981.
[<a id="ref-RFC1112">RFC1112</a>] Deering, S., "Host extensions for IP multicasting", STD
5, <a href="./rfc1112">RFC 1112</a>, August 1989.
[<a id="ref-RFC2401">RFC2401</a>] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.
[<a id="ref-RFC3513">RFC3513</a>] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", <a href="./rfc3513">RFC 3513</a>, April 2003.
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
<span class="grey">Holbrook & Cain Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Informative References</span>
[<a id="ref-ADMIN-SCOPE">ADMIN-SCOPE</a>] Meyer, D., "Administratively Scoped IP Multicast", <a href="https://www.rfc-editor.org/bcp/bcp23">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp23">23</a>, <a href="./rfc2365">RFC 2365</a>, July 1998.
[<a id="ref-DVMRP">DVMRP</a>] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", <a href="./rfc1075">RFC 1075</a>, November
1988.
[<a id="ref-EXPRESS">EXPRESS</a>] Holbrook, H., and Cheriton, D. "Explicitly Requested
Source-Specific Multicast: EXPRESS support for Large-
scale Single-source Applications." Proceedings of ACM
SIGCOMM '99, Cambridge, MA, September 1999.
[<a id="ref-IANA-ALLOC">IANA-ALLOC</a>] Internet Assigned Numbers Authority,
<a href="http://www.iana.org/assignments/multicast-addresses">http://www.iana.org/assignments/multicast-addresses</a>.
[<a id="ref-IANA-CONSID">IANA-CONSID</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC</a>
<a href="./rfc2434">2434</a>, October 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-MSFAPI">MSFAPI</a>] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", <a href="./rfc3678">RFC 3678</a>,
January 2004.
[<a id="ref-PIM-DM">PIM-DM</a>] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", <a href="./rfc3973">RFC 3973</a>, January 2005.
[<a id="ref-RFC2119">RFC2119</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-RFC2710">RFC2710</a>] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", <a href="./rfc2710">RFC 2710</a>, October
1999.
[<a id="ref-RFC2771">RFC2771</a>] Finlayson, R., "An Abstract API for Multicast Address
Allocation", <a href="./rfc2771">RFC 2771</a>, February 2000.
[<a id="ref-SCOPINGv6">SCOPINGv6</a>] Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
and B. Zill, "IPv6 Scoped Address Architecture", <a href="./rfc4007">RFC</a>
<a href="./rfc4007">4007</a>, March 2005.
<span class="grey">Holbrook & Cain Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
[<a id="ref-SIMPLE">SIMPLE</a>] R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z.
Wang, T. Maufer, C. Diot, and M. Green, "Simple
Multicast: A Design for Simple, Low-Overhead
Multicast", Work in Progress, October 1999.
[<a id="ref-SMRP">SMRP</a>] Green, M. "Method and System of Multicast Routing for
Groups with a Single Transmitter." United States
Patent Number 5,517,494.
Authors' Addresses
Brad Cain
Acopia Networks
EMail: bcain99@gmail.com
Hugh Holbrook
Arastra, Inc.
P.O. Box 10905
Palo Alto, CA 94303
Phone: +1 650 331-1620
EMail: holbrook@arastra.com
<span class="grey">Holbrook & Cain Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4607">RFC 4607</a> Source-Specific Multicast August 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Holbrook & Cain Standards Track [Page 19]
</pre>
|
