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
|
<pre>Internet Engineering Task Force (IETF) P. Savola
Request for Comments: 6308 CSC/FUNET
Obsoletes: <a href="./rfc2908">2908</a> June 2011
Category: Informational
ISSN: 2070-1721
<span class="h1">Overview of the Internet Multicast Addressing Architecture</span>
Abstract
The lack of up-to-date documentation on IP multicast address
allocation and assignment procedures has caused a great deal of
confusion. To clarify the situation, this memo describes the
allocation and assignment techniques and mechanisms currently (as of
this writing) in use.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6308">http://www.rfc-editor.org/info/rfc6308</a>.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Savola Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Terminology: Allocation or Assignment ......................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Multicast Address Allocation ....................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Derived Allocation .........................................<a href="#page-3">3</a>
<a href="#section-2.1.1">2.1.1</a>. GLOP Allocation .....................................<a href="#page-4">4</a>
<a href="#section-2.1.2">2.1.2</a>. Unicast-Prefix-Based Allocation .....................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Administratively Scoped Allocation .........................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Static IANA Allocation .....................................<a href="#page-6">6</a>
<a href="#section-2.4">2.4</a>. Dynamic Allocation .........................................<a href="#page-6">6</a>
<a href="#section-3">3</a>. Multicast Address Assignment ....................................<a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. Derived Assignment .........................................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. SSM Assignment inside the Node .............................<a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. Manually Configured Assignment .............................<a href="#page-7">7</a>
<a href="#section-3.4">3.4</a>. Static IANA Assignment .....................................<a href="#page-7">7</a>
<a href="#section-3.4.1">3.4.1</a>. Global IANA Assignment ..............................<a href="#page-7">7</a>
<a href="#section-3.4.2">3.4.2</a>. Scope-Relative IANA Assignment ......................<a href="#page-8">8</a>
<a href="#section-3.5">3.5</a>. Dynamic Assignments ........................................<a href="#page-8">8</a>
<a href="#section-4">4</a>. Summary and Future Directions ...................................<a href="#page-9">9</a>
<a href="#section-4.1">4.1</a>. Prefix Allocation ..........................................<a href="#page-9">9</a>
<a href="#section-4.2">4.2</a>. Address Assignment ........................................<a href="#page-10">10</a>
<a href="#section-4.3">4.3</a>. Future Actions ............................................<a href="#page-11">11</a>
<a href="#section-5">5</a>. Acknowledgements ...............................................<a href="#page-11">11</a>
<a href="#section-6">6</a>. IANA Considerations ............................................<a href="#page-11">11</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-12">12</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-12">12</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Good, up-to-date documentation of IP multicast is close to
non-existent. Particularly, this is an issue with multicast address
allocations (to networks and sites) and assignments (to hosts and
applications). This problem is stressed by the fact that there
exists confusing or misleading documentation on the subject
[<a href="./rfc2908" title=""The Internet Multicast Address Allocation Architecture"">RFC2908</a>]. The consequence is that those who wish to learn about IP
multicast and how the addressing works do not get a clear view of the
current situation.
The aim of this document is to provide a brief overview of multicast
addressing and allocation techniques. The term "addressing
architecture" refers to the set of addressing mechanisms and methods
in an informal manner.
<span class="grey">Savola Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
It is important to note that Source-Specific Multicast (SSM)
[<a href="./rfc4607" title=""Source-Specific Multicast for IP"">RFC4607</a>] does not have these addressing problems because SSM group
addresses have only local significance; hence, this document focuses
on the Any Source Multicast (ASM) model.
This memo obsoletes and re-classifies <a href="./rfc2908">RFC 2908</a> to Historic, and
re-classifies RFCs 2776 and 2909 to Historic.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology: Allocation or Assignment</span>
Almost all multicast documents and many other RFCs (such as DHCPv4
[<a href="./rfc2131" title=""Dynamic Host Configuration Protocol"">RFC2131</a>] and DHCPv6 [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>]) have used the terms "address
allocation" and "address assignment" interchangeably. However, the
operator and address management communities use these terms for two
conceptually different processes.
In unicast operations, address allocations refer to leasing a large
block of addresses from the Internet Assigned Numbers Authority
(IANA) to a Regional Internet Registry (RIR), or from an RIR to a
Local Internet Registry (LIR), possibly through a National Internet
Registry (NIR). Address assignments, on the other hand, are the
leases of smaller address blocks or even single addresses to the end-
user sites or end-users themselves.
Therefore, in this memo, we will separate the two different
functions: "allocation" describes how larger blocks of addresses are
obtained by the network operators, and "assignment" describes how
applications, nodes, or sets of nodes obtain a multicast address for
their use.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Multicast Address Allocation</span>
Multicast address allocation, i.e., how a network operator might be
able to obtain a larger block of addresses, can be handled in a
number of ways, as described below.
Note that these are all only pertinent to ASM -- SSM requires no
address block allocation because the group address has only local
significance (however, we discuss the address assignment inside the
node in <a href="#section-3.2">Section 3.2</a>).
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Derived Allocation</span>
Derived allocations take the unicast prefix or some other properties
of the network (e.g., an autonomous system (AS) number) to determine
unique multicast address allocations.
<span class="grey">Savola Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. GLOP Allocation</span>
GLOP address allocation [<a href="./rfc3180" title=""GLOP Addressing in 233/8"">RFC3180</a>] inserts the 16-bit public AS number
in the middle of the IPv4 multicast prefix 233.0.0.0/8, so that each
AS number can get a /24 worth of multicast addresses. While this is
sufficient for multicast testing or small-scale use, it might not be
sufficient in all cases for extensive multicast use.
A minor operational debugging issue with GLOP addresses is that the
connection between the AS and the prefix is not apparent from the
prefix when the AS number is greater than 255, but has to be
calculated (e.g., as described in [<a href="./rfc3180" title=""GLOP Addressing in 233/8"">RFC3180</a>], AS 5662 maps to
233.22.30.0/24). A usage issue is that GLOP addresses are not tied
to any prefix but to routing domains, so they cannot be used or
calculated automatically.
GLOP mapping is not available with 4-byte AS numbers [<a href="./rfc4893" title=""BGP Support for Four-octet AS Number Space"">RFC4893</a>].
Unicast-prefix-based allocation or an IANA allocation from "AD-HOC
Block III" (the previous so-called "EGLOP" (Extended GLOP) block)
could be used instead, as needed.
The GLOP allocation algorithm has not been defined for IPv6 multicast
because the unicast-prefix-based allocation (described below)
addresses the same need in a simpler fashion.
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. Unicast-Prefix-Based Allocation</span>
<a href="./rfc3306">RFC 3306</a> [<a href="./rfc3306" title=""Unicast-Prefix-based IPv6 Multicast Addresses"">RFC3306</a>] describes a mechanism that embeds up to 64 high-
order bits of an IPv6 unicast address in the prefix part of the IPv6
multicast address, leaving at least 32 bits of group-id space
available after the prefix mapping.
A similar IPv4 mapping is described in [<a href="./rfc6034" title=""Unicast-Prefix-Based IPv4 Multicast Addresses"">RFC6034</a>], but it provides a
limited number of addresses (e.g., 1 per IPv4 /24 block).
The IPv6 unicast-prefix-based allocations are an extremely useful way
to allow each network operator, even each subnet, to obtain multicast
addresses easily, through an easy computation. Further, as the IPv6
multicast header also includes the scope value [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>], multicast
groups of smaller scope can also be used with the same mapping.
The IPv6 Embedded Rendezvous Point (RP) technique [<a href="./rfc3956" title=""Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address"">RFC3956</a>], used
with Protocol Independent Multicast - Sparse Mode (PIM-SM), further
leverages the unicast-prefix-based allocations, by embedding the
unicast prefix and interface identifier of the PIM-SM RP in the
prefix. This provides all the necessary information needed to the
routing systems to run the group in either inter- or intra-domain
operation. A difference from <a href="./rfc3306">RFC 3306</a> is, however, that the hosts
<span class="grey">Savola Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
cannot calculate their "multicast prefix" automatically (as the
prefix depends on the decisions of the operator setting up the RP),
but instead require an assignment method.
All the IPv6 unicast-prefix-based allocation techniques provide a
sufficient amount of multicast address space for network operators.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Administratively Scoped Allocation</span>
Administratively scoped multicast address allocation [<a href="./rfc2365" title=""Administratively Scoped IP Multicast"">RFC2365</a>] is
provided by two different means: under 239.0.0.0/8 in IPv4 or by
4-bit encoding in the IPv6 multicast address prefix [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>].
Since IPv6 administratively scoped allocations can be handled with
unicast-prefix-based multicast addressing as described in
<a href="#section-2.1.2">Section 2.1.2</a>, we'll only discuss IPv4 in this section.
The IPv4 administratively scoped prefix 239.0.0.0/8 is further
divided into Local Scope (239.255.0.0/16) and Organization Local
Scope (239.192.0.0/14); other parts of the administrative scopes are
either reserved for expansion or undefined [<a href="./rfc2365" title=""Administratively Scoped IP Multicast"">RFC2365</a>]. However,
<a href="./rfc2365">RFC 2365</a> is ambiguous as to whether the enterprises or the IETF are
allowed to expand the space.
Topologies that act under a single administration can easily use the
scoped multicast addresses for their internal groups. Groups that
need to be shared between multiple routing domains (even if not
propagated through the Internet) are more problematic and typically
need an assignment of a global multicast address because their scope
is undefined.
There are a large number of multicast applications (such as "Norton
Ghost") that are restricted either to a link or a site, and it is
extremely undesirable to propagate them further (beyond the link or
the site). Typically, many such applications have been given or have
hijacked a static IANA address assignment. Given the fact that
assignments to typically locally used applications come from the same
range as global applications, implementing proper propagation
limiting is challenging. Filtering would be easier if a separate,
identifiable range would be used for such assignments in the future;
this is an area of further future work.
There has also been work on a protocol to automatically discover
multicast scope zones [<a href="./rfc2776" title=""Multicast-Scope Zone Announcement Protocol (MZAP)"">RFC2776</a>], but it has never been widely
implemented or deployed.
<span class="grey">Savola Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Static IANA Allocation</span>
In some rare cases, organizations may have been able to obtain static
multicast address allocations (of up to 256 addresses) directly from
IANA. Typically, these have been meant as a block of static
assignments to multicast applications, as described in <a href="#section-3.4.1">Section 3.4.1</a>.
If another means of obtaining addresses is available, that approach
is preferable.
Especially for those operators that only have a 32-bit AS number and
need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the
previous so-called "EGLOP" block) is an option [<a href="./rfc5771" title=""IANA Guidelines for IPv4 Multicast Address Assignments"">RFC5771</a>].
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Dynamic Allocation</span>
<a href="./rfc2908">RFC 2908</a> [<a href="./rfc2908" title=""The Internet Multicast Address Allocation Architecture"">RFC2908</a>] proposed three different layers of multicast
address allocation and assignment, where layer 3 (inter-domain
allocation) and layer 2 (intra-domain allocation) could be applicable
here. The Multicast Address-Set Claim Protocol (MASC) [<a href="./rfc2909" title=""The Multicast Address-Set Claim (MASC) Protocol"">RFC2909</a>] is
an example of the former, and the Multicast Address Allocation
Protocol (AAP) [<a href="#ref-MALLOC-AAP">MALLOC-AAP</a>] (abandoned in 2000 due to lack of
interest and technical problems) is an example of the latter.
Both of the proposed allocation protocols were quite complex, and
have never been deployed or seriously implemented.
It can be concluded that dynamic multicast address allocation
protocols provide no benefit beyond GLOP/unicast-prefix-based
mechanisms and have been abandoned.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Multicast Address Assignment</span>
There are a number of possible ways for an application, node, or set
of nodes to learn a multicast address, as described below.
Any IPv6 address assignment method should be aware of the guidelines
for the assignment of group-IDs for IPv6 multicast addresses
[<a href="./rfc3307" title=""Allocation Guidelines for IPv6 Multicast Addresses"">RFC3307</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Derived Assignment</span>
There are significantly fewer options for derived address assignment
compared to derived allocation. Derived multicast assignment has
only been specified for IPv6 link-scoped multicast [<a href="./rfc4489" title=""A Method for Generating Link-Scoped IPv6 Multicast Addresses"">RFC4489</a>], where
the EUI64 is embedded in the multicast address, providing a node with
unique multicast addresses for link-local ASM communications.
<span class="grey">Savola Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. SSM Assignment inside the Node</span>
While SSM multicast addresses have only local (to the node)
significance, there is still a minor issue on how to assign the
addresses between the applications running on the same IP address.
This assignment is not considered to be a problem, because typically
the addresses for these applications are selected manually or
statically, but if done using an Application Programming Interface
(API), the API could check that the addresses do not conflict prior
to assigning one.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Manually Configured Assignment</span>
With manually configured assignment, a network operator who has a
multicast address prefix assigns the multicast group addresses to the
requesting nodes using a manual process.
Typically, the user or administrator that wants to use a multicast
address for a particular application requests an address from the
network operator using phone, email, or similar means, and the
network operator provides the user with a multicast address. Then
the user/administrator of the node or application manually configures
the application to use the assigned multicast address.
This is a relatively simple process; it has been sufficient for
certain applications that require manual configuration in any case,
or that cannot or do not want to justify a static IANA assignment.
The manual assignment works when the number of participants in a
group is small, as each participant has to be manually configured.
This is the most commonly used technique when the multicast
application does not have a static IANA assignment.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Static IANA Assignment</span>
In contrast to manually configured assignment, as described above,
static IANA assignment refers to getting an assignment for the
particular application directly from IANA. There are two main forms
of IANA assignment: global and scope-relative. Guidelines for IANA
are described in [<a href="./rfc5771" title=""IANA Guidelines for IPv4 Multicast Address Assignments"">RFC5771</a>].
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Global IANA Assignment</span>
Globally unique address assignment is seen as lucrative because it's
the simplest approach for application developers, since they can then
hard-code the multicast address. Hard-coding requires no lease of
the usable multicast address, and likewise the client applications do
<span class="grey">Savola Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
not need to perform any kind of service discovery (but depend on
hard-coded addresses). However, there is an architectural scaling
problem with this approach, as it encourages a "land-grab" of the
limited multicast address space.
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Scope-Relative IANA Assignment</span>
IANA also assigns numbers as an integer offset from the highest
address in each IPv4 administrative scope, as described in [<a href="./rfc2365" title=""Administratively Scoped IP Multicast"">RFC2365</a>].
For example, the SLPv2 discovery scope-relative offset is "2", so the
SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is
"239.255.255.253"; within the IPv4 Organization Local-Scope
(239.192.0.0/14), it is "239.195.255.253"; and so on.
Similar scope-relative assignments also exist with IPv6 [<a href="./rfc2375" title=""IPv6 Multicast Address Assignments"">RFC2375</a>].
As IPv6 multicast addresses have much more flexible scoping, scope-
relative assignments are also applicable to global scopes. The
assignment policies are described in [<a href="./rfc3307" title=""Allocation Guidelines for IPv6 Multicast Addresses"">RFC3307</a>].
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Dynamic Assignments</span>
Layer 1 as defined in <a href="./rfc2908">RFC 2908</a> [<a href="./rfc2908" title=""The Internet Multicast Address Allocation Architecture"">RFC2908</a>] described dynamic assignment
from Multicast Address Allocation Servers (MAAS) to applications and
nodes, with the Multicast Address Dynamic Client Allocation Protocol
(MADCAP) [<a href="./rfc2730" title=""Multicast Address Dynamic Client Allocation Protocol (MADCAP)"">RFC2730</a>] as an example. Since then, other mechanisms have
also been proposed (e.g., DHCPv6 assignment
[<a href="#ref-MCAST-DHCPv6">MCAST-DHCPv6</a>]), but these have not gained traction.
It would be rather straightforward to deploy a dynamic assignment
protocol that would lease group addresses based on a multicast prefix
to applications wishing to use multicast. However, only few have
implemented MADCAP (i.e., it is not significantly deployed). It is
not clear if the sparse deployment is due to a lack of need for the
protocol. Moreover, it is not clear how widely, for example, the
APIs for communication between the multicast application and the
MADCAP client operating at the host have been implemented [<a href="./rfc2771" title=""An Abstract API for Multicast Address Allocation"">RFC2771</a>].
An entirely different approach is the Session Announcement Protocol
(SAP) [<a href="./rfc2974" title=""Session Announcement Protocol"">RFC2974</a>]. In addition to advertising global multicast
sessions, the protocol also has associated ranges of addresses for
both IPv4 and IPv6 that can be used by SAP-aware applications to
create new groups and new group addresses. Creating a session (and
obtaining an address) is a rather tedious process, which is why it
isn't done all that often. It is also worth noting that the IPv6 SAP
address is unroutable in the inter-domain multicast.
<span class="grey">Savola Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
Conclusions about dynamic assignment protocols are that:
1. multicast is not significantly attractive in the first place,
2. most applications have a static IANA assignment and thus require
no dynamic or manual assignment,
3. those applications that cannot be easily satisfied with IANA or
manual assignment (i.e., where dynamic assignment would be
desirable) are rather marginal, or
4. there are other reasons why dynamic assignments are not seen as a
useful approach (for example, issues related to service
discovery/rendezvous).
In consequence, more work on rendezvous/service discovery would be
needed to make dynamic assignments more useful.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Summary and Future Directions</span>
This section summarizes the mechanisms and analysis discussed in this
memo, and presents some potential future directions.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Prefix Allocation</span>
A summary of prefix allocation methods for ASM is shown in Figure 1.
+-------+--------------------------------+--------+--------+
| Sect. | Prefix allocation method | IPv4 | IPv6 |
+-------+--------------------------------+--------+--------+
| 2.1.1 | Derived: GLOP | Yes | NoNeed*|
| 2.1.2 | Derived: Unicast-prefix-based | No | Yes |
| 2.2 | Administratively scoped | Yes | NoNeed*|
| 2.3 | Static IANA allocation | Yes** | No |
| 2.4 | Dynamic allocation protocols | No | No |
+-------+--------------------------------+--------+--------+
* = the need satisfied by IPv6 unicast-prefix-based allocation
** = mainly using the AD-HOC block III (formerly called "EGLOP")
Figure 1
<span class="grey">Savola Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
o Only ASM is affected by the assignment/allocation issues.
o With IPv4, GLOP allocations provide a sufficient IPv4 multicast
allocation mechanism for those that have a 16-bit AS number. IPv4
unicast-prefix-based allocation offers some addresses. IANA is
also allocating from the AD-HOC block III (formerly called
"EGLOP"), especially with 32-bit AS number holders in mind.
Administratively scoped allocations provide the opportunity for
internal IPv4 allocations.
o With IPv6, unicast-prefix-based addresses and the derivatives
provide a good allocation strategy, and this also works for scoped
multicast addresses.
o Dynamic allocations are too complex and unnecessary a mechanism.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Address Assignment</span>
A summary of address assignment methods is shown in Figure 2.
+--------+--------------------------------+----------+----------+
| Sect. | Address assignment method | IPv4 | IPv6 |
+--------+--------------------------------+----------+----------+
| 3.1 | Derived: link-scope addresses | No | Yes |
| 3.2 | SSM (inside the node) | Yes | Yes |
| 3.3 | Manual assignment | Yes | Yes |
| 3.4.1 | Global IANA/RIR assignment |LastResort|LastResort|
| 3.4.2 | Scope-relative IANA assignment | Yes | Yes |
| 3.5 | Dynamic assignment protocols | Yes | Yes |
+--------+--------------------------------+----------+----------+
Figure 2
o Manually configured assignment is typical today, and works to a
sufficient degree in smaller scale.
o Global IANA assignment has been done extensively in the past.
Scope-relative IANA assignment is acceptable, but the size of the
pool is not very high. Inter-domain routing of IPv6 IANA-assigned
prefixes is likely going to be challenging, and as a result that
approach is not very appealing.
o Dynamic assignment, e.g., MADCAP, has been implemented, but there
is no wide deployment. Therefore, either there are other gaps in
the multicast architecture, or there is no sufficient demand for
it in the first place when manual and static IANA assignments are
available. Assignments using SAP also exist but are not common;
global SAP assignment is infeasible with IPv6.
<span class="grey">Savola Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
o Derived assignments are only applicable in a fringe case of link-
scoped multicast.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Future Actions</span>
o Multicast address discovery/"rendezvous" needs to be analyzed at
more length, and an adequate solution provided. See
[<a href="#ref-ADDRDISC-PROB">ADDRDISC-PROB</a>] and [<a href="#ref-MSA-REQ" title=""Requirements for IP Multicast Session Announcement"">MSA-REQ</a>] for more information.
o The IETF should consider whether to specify more ranges of the
IPv4 administratively scoped address space for static allocation
for applications that should not be routed over the Internet (such
as backup software, etc. -- so that these wouldn't need to use
global addresses, which should never leak in any case).
o The IETF should consider its static IANA allocations policy, e.g.,
"locking it down" to a stricter policy (like "IETF Consensus") and
looking at developing the discovery/rendezvous functions, if
necessary.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgements</span>
Tutoring a couple of multicast-related papers, the latest by Kaarle
Ritvanen [<a href="#ref-RITVANEN" title=""Multicast Routing and Addressing"">RITVANEN</a>], convinced the author that updated multicast
address assignment/allocation documentation is needed.
Multicast address allocations/assignments were discussed at the
MBONED WG session at IETF 59 [<a href="#ref-MBONED-IETF59">MBONED-IETF59</a>].
Dave Thaler, James Lingard, and Beau Williamson provided useful
feedback for the preliminary version of this memo. Myung-Ki Shin,
Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred
Hoenes also suggested improvements.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
IANA considerations in Sections <a href="#section-4.1.1">4.1.1</a> and <a href="#section-4.1.2">4.1.2</a> of obsoleted and now
Historic [<a href="./rfc2908" title=""The Internet Multicast Address Allocation Architecture"">RFC2908</a>] were never implemented in the IANA registry.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
This memo only describes different approaches to allocating and
assigning multicast addresses, and this has no security
considerations; the security analysis of the mentioned protocols is
out of scope of this memo.
<span class="grey">Savola Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
Obviously, the dynamic assignment protocols in particular are
inherently vulnerable to resource exhaustion attacks, as discussed,
e.g., in [<a href="./rfc2730" title=""Multicast Address Dynamic Client Allocation Protocol (MADCAP)"">RFC2730</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2365">RFC2365</a>] Meyer, D., "Administratively Scoped IP Multicast",
<a href="https://www.rfc-editor.org/bcp/bcp23">BCP 23</a>, <a href="./rfc2365">RFC 2365</a>, July 1998.
[<a id="ref-RFC3180">RFC3180</a>] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
<a href="https://www.rfc-editor.org/bcp/bcp53">BCP 53</a>, <a href="./rfc3180">RFC 3180</a>, September 2001.
[<a id="ref-RFC3306">RFC3306</a>] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", <a href="./rfc3306">RFC 3306</a>, August 2002.
[<a id="ref-RFC3307">RFC3307</a>] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", <a href="./rfc3307">RFC 3307</a>, August 2002.
[<a id="ref-RFC3956">RFC3956</a>] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
<a href="./rfc3956">RFC 3956</a>, November 2004.
[<a id="ref-RFC4291">RFC4291</a>] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", <a href="./rfc4291">RFC 4291</a>, February 2006.
[<a id="ref-RFC4489">RFC4489</a>] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for
Generating Link-Scoped IPv6 Multicast Addresses",
<a href="./rfc4489">RFC 4489</a>, April 2006.
[<a id="ref-RFC4607">RFC4607</a>] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", <a href="./rfc4607">RFC 4607</a>, August 2006.
[<a id="ref-RFC5771">RFC5771</a>] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines
for IPv4 Multicast Address Assignments", <a href="https://www.rfc-editor.org/bcp/bcp51">BCP 51</a>,
<a href="./rfc5771">RFC 5771</a>, March 2010.
[<a id="ref-RFC6034">RFC6034</a>] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast
Addresses", <a href="./rfc6034">RFC 6034</a>, October 2010.
<span class="grey">Savola Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-ADDRDISC-PROB">ADDRDISC-PROB</a>]
Savola, P., "Lightweight Multicast Address Discovery
Problem Space", Work in Progress, March 2006.
[<a id="ref-MALLOC-AAP">MALLOC-AAP</a>]
Handley, M. and S. Hanna, "Multicast Address Allocation
Protocol (AAP)", Work in Progress, June 2000.
[<a id="ref-MBONED-IETF59">MBONED-IETF59</a>]
"MBONED WG session at IETF59",
<<a href="http://www.ietf.org/proceedings/04mar/172.htm">http://www.ietf.org/proceedings/04mar/172.htm</a>>.
[<a id="ref-MCAST-DHCPv6">MCAST-DHCPv6</a>]
Durand, J., "IPv6 multicast address assignment with
DHCPv6", Work in Progress, February 2005.
[<a id="ref-MSA-REQ">MSA-REQ</a>] Asaeda, H. and V. Roca, "Requirements for IP Multicast
Session Announcement", Work in Progress, March 2010.
[<a id="ref-RFC2131">RFC2131</a>] Droms, R., "Dynamic Host Configuration Protocol",
<a href="./rfc2131">RFC 2131</a>, March 1997.
[<a id="ref-RFC2375">RFC2375</a>] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", <a href="./rfc2375">RFC 2375</a>, July 1998.
[<a id="ref-RFC2730">RFC2730</a>] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", <a href="./rfc2730">RFC 2730</a>,
December 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-RFC2776">RFC2776</a>] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
Zone Announcement Protocol (MZAP)", <a href="./rfc2776">RFC 2776</a>, February
2000.
[<a id="ref-RFC2908">RFC2908</a>] Thaler, D., Handley, M., and D. Estrin, "The Internet
Multicast Address Allocation Architecture", <a href="./rfc2908">RFC 2908</a>,
September 2000.
[<a id="ref-RFC2909">RFC2909</a>] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
Kumar, S., and D. Thaler, "The Multicast Address-Set
Claim (MASC) Protocol", <a href="./rfc2909">RFC 2909</a>, September 2000.
[<a id="ref-RFC2974">RFC2974</a>] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", <a href="./rfc2974">RFC 2974</a>, October 2000.
<span class="grey">Savola Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6308">RFC 6308</a> Multicast Address Allocation June 2011</span>
[<a id="ref-RFC3315">RFC3315</a>] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, July 2003.
[<a id="ref-RFC4893">RFC4893</a>] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", <a href="./rfc4893">RFC 4893</a>, May 2007.
[<a id="ref-RITVANEN">RITVANEN</a>] Ritvanen, K., "Multicast Routing and Addressing", HUT
Report, Seminar on Internetworking, May 2004,
<<a href="http://www.tml.hut.fi/Studies/T-110.551/2004/papers/">http://www.tml.hut.fi/Studies/T-110.551/2004/papers/</a>>.
Author's Address
Pekka Savola
CSC - Scientific Computing Ltd.
Espoo
Finland
EMail: psavola@funet.fi
Savola Informational [Page 14]
</pre>
|
