idnits 2.17.1 draft-ietf-mboned-addrarch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 722. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 728. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document obsoletes RFC2908, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2909, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2776, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2006) is 6601 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2608' is defined on line 624, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3171 (Obsoleted by RFC 5771) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- No information found for draft-ietf-malloc-aap - is the name correct? == Outdated reference: A later version (-02) exists of draft-ietf-mboned-addrdisc-problems-01 == Outdated reference: A later version (-06) exists of draft-ietf-mboned-ipv4-uni-based-mcast-02 == Outdated reference: A later version (-08) exists of draft-ietf-mboned-rfc3171bis-02 -- Obsolete informational reference (is this intentional?): RFC 2908 (Obsoleted by RFC 6308) -- Obsolete informational reference (is this intentional?): RFC 3138 (Obsoleted by RFC 5771) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet-Draft CSC/FUNET 4 Obsoletes: 2776,2908,2909 (if March 3, 2006 5 approved) 6 Intended status: Best Current 7 Practice 8 Expires: September 4, 2006 10 Overview of the Internet Multicast Addressing Architecture 11 draft-ietf-mboned-addrarch-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 4, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The lack of up-to-date documentation on IP multicast address 45 allocation and assignment procedures has caused a great deal of 46 confusion. To clarify the situation, this memo describes the 47 allocation and assignment techniques and mechanisms currently (as of 48 this writing) in use. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3 54 2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 55 2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 56 2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 57 2.1.2. Unicast-prefix -based Allocation . . . . . . . . . . . 4 58 2.2. Administratively Scoped Allocation . . . . . . . . . . . . 5 59 2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 60 2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 61 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6 62 3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7 63 3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7 64 3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7 65 3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 7 66 3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8 67 3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8 68 3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 69 4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 70 4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10 71 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 72 4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 80 A.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 Intellectual Property and Copyright Statements . . . . . . . . . . 17 84 1. Introduction 86 Good, up-to-date documentation of IP multicast is close to non- 87 existent. Particularly, this is an issue with multicast address 88 allocations (to networks and sites) and assignments (to hosts and 89 applications). This problem is stressed by the fact that there 90 exists confusing or misleading documentation on the subject 91 [RFC2908]. The consequence is that those who wish to learn of IP 92 multicast and how the addressing works do not get a clear view of the 93 current situation. 95 The aim of this document is to provide a brief overview of multicast 96 addressing and allocation techniques. The term 'addressing 97 architecture' refers to the set of addressing mechanisms and methods 98 in an informal manner. 100 It is important to note that Source-specific Multicast (SSM) 101 [I-D.ietf-ssm-arch] does not have these addressing problems; hence, 102 this document focuses on the Any Source Multicast (ASM) model. 104 This memo obsoletes RFCs 2776, 2908, and 2909 and re-classifies them 105 Historic. 107 1.1. Terminology: Allocation or Assignment 109 Almost all multicast documents and many other RFCs (such as DHCPv4 110 [RFC2131] and DHCPv6 [RFC3315]) have used the terms address 111 "allocation" and "assignment" interchangeably. However, the operator 112 and address management communities use these for two conceptually 113 different processes. 115 In unicast operations, address allocations refer to leasing a large 116 block of addresses from Internet Assigned Numbers Authority (IANA) to 117 a Regional Internet Registry (RIR) or from RIR to a Local Internet 118 Registry (LIR) possibly through a National Internet Registry (NIR). 119 Address assignments, on the other hand, are the leases of smaller 120 address blocks or even single addresses to the end-user sites or end- 121 users themselves. 123 Therefore, in this memo, we will separate the two different 124 functions: "allocation" describes how larger blocks of addresses are 125 obtained by the network operators, and "assignment" describes how 126 applications, nodes or sets of nodes obtain a multicast address for 127 their use. 129 2. Multicast Address Allocation 131 Multicast address allocation, i.e., how a network operator might be 132 able to obtain a larger block of addresses, can be handled in a 133 number of ways as described below. 135 Note that these are all only pertinent to ASM -- SSM requires no 136 address block allocation because the group address has only local 137 significance (however, we discuss the address assignment inside the 138 node in Section 3.2). 140 2.1. Derived Allocation 142 Derived allocations take the unicast prefix or some other properties 143 of the network to determine unique multicast address allocations. 145 2.1.1. GLOP Allocation 147 GLOP address allocation [RFC3180] inserts the 16-bit public 148 Autonomous System (AS) number in the middle of the IPv4 multicast 149 prefix 233.0.0.0/8, so that each AS number can get a /24 worth of 150 multicast addresses. While this is sufficient for multicast testing 151 or small scale use, it might not be sufficient in all cases for 152 extensive multicast use. 154 A minor operational debugging issue with GLOP addresses is that the 155 connection between the AS and the prefix is not apparent from the 156 prefix when the AS number is greater than 255, but has to be 157 calculated (e.g., from [RFC3180], AS 5662 maps to 233.22.30.0/24). A 158 usage issue is that GLOP addresses are not tied to any prefix but to 159 routing domains, so they cannot be used or calculated automatically. 161 2.1.2. Unicast-prefix -based Allocation 163 RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first 164 bits of an IPv6 unicast address in the prefix part of the IPv6 165 multicast address, leaving at least 32 bits of group-id space 166 available after the prefix mapping. 168 A similar mapping has been proposed for IPv4 169 [I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low 170 amount of addresses (e.g., 1 per an IPv4 /24 block). While there 171 exist large networks without an AS number of their own, this has not 172 been seen to add sufficient value compared to GLOP addressing. 174 The IPv6 unicast-prefix-based allocations are an extremely useful way 175 to allow each network operator, even each subnet, obtain multicast 176 addresses easily, through an easy computation. Further, as the IPv6 177 multicast header also includes the scope value [RFC3513], multicast 178 groups of smaller scope can also be used with the same mapping. 180 The IPv6 Embedded RP technique [RFC3956], used with Protocol 181 Independent Multicast - Sparse Mode (PIM-SM), further leverages the 182 unicast prefix based allocations, by embedding the unicast prefix and 183 interface identifier of the PIM-SM Rendezvous Point (RP) in the 184 prefix. This provides all the necessary information needed to the 185 routing systems to run the group in either inter- or intra-domain 186 operation. A difference to RFC 3306 is, however, that the hosts 187 cannot calculate their "multicast prefix" automatically, as the 188 prefix depends on the decisions of the operator setting up the RP but 189 rather requires an assignment method. 191 All the IPv6 unicast-prefix-based allocation techniques provide 192 sufficient amount of multicast address space for the network 193 operators. 195 2.2. Administratively Scoped Allocation 197 Administratively scoped multicast [RFC2365] is provided by two 198 different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in 199 the IPv6 multicast address prefix [RFC3513]. 201 As IPv6 administratively scoped allocations can be handled with 202 unicast-prefix-based multicast addressing as described in 203 Section 2.1.2, we'll just discuss IPv4 in this section. 205 The IPv4 administratively scoped prefix 239.0.0.0/8 is further 206 divided to Local Scope (239.255.0.0/16) and Organization Local Scope 207 (239.192.0.0/14); other parts of the administrative scopes are either 208 reserved for expansion or undefined [RFC2365]. However, RFC 2365 is 209 ambiguous as to whether it's the enterprises or the IETF who are 210 allowed to expand the space. 212 Topologies which act under a single administration can easily use the 213 scoped multicast addresses for their internal groups. Groups which 214 need to be shared between multiple routing domains (but not 215 propagated through the Internet) are more problematic and typically 216 need an assignment of a global multicast address because their scope 217 is undefined. 219 There is a large number of multicast applications (such as "Norton 220 Ghost") which are restricted either to a link or a site, and it is 221 extremely undesirable to propagate them further (either to the rest 222 of the site, or beyond the site). Typically many such applications 223 have been given or have hijacked a static IANA address assignment; 224 this makes it challenging to implement proper propagation limiting -- 225 which could be easier if such applications could have been assigned 226 specific administratively scoped addresses instead. This is an area 227 of further future work. 229 There has also been work on a protocol to automatically discover 230 multicast scope zones [RFC2776], but it has never been widely 231 implemented or deployed. 233 2.3. Static IANA Allocation 235 In some rare cases, some organizations may have been able to obtain 236 static multicast address allocations (of up to 256 addresses) 237 directly from IANA. Typically these have been meant as a block of 238 static assignments to multicast applications, as described in 239 Section 3.4.1. In principle, IANA does not allocate multicast 240 address blocks to the operators but GLOP or Unicast-prefix-based 241 allocations should be used instead. 243 2.4. Dynamic Allocation 245 RFC 2908 [RFC2908] proposed three different layers of multicast 246 address allocation and assignment, where layers 3 (inter-domain 247 allocation) and layer 2 (intra-domain allocation) could be applicable 248 here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an 249 example of the former, and Multicast Address Allocation Protocol 250 (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest 251 and technical problems) is an example of the latter. 253 Both of the proposed allocation protocols were quite complex, and 254 have never been deployed or seriously implemented. 256 It can be concluded that there are no dynamic multicast address 257 allocation protocols, and other methods such as GLOP or unicast- 258 prefix-based addressing should be used instead. 260 3. Multicast Address Assignment 262 For multicast address assignment, i.e., how an application learns the 263 address it can use, or a node (or a set of nodes) learns an address 264 it could use for an application, has a number of options as described 265 below. 267 Any IPv6 address assignment method should be aware of the guidelines 268 for the assignment of the group-IDs for IPv6 multicast addresses 269 [RFC3307]. 271 3.1. Derived Assignment 273 There are significantly fewer options for derived address assignment 274 compared to derived allocation. Derived multicast assignment has 275 only been specified for IPv6 link-scoped multicast 276 [I-D.ietf-ipv6-link-scoped-mcast], where the EUI64 is embedded in the 277 multicast address, providing a node with unique multicast addresses 278 for link-local ASM communications. 280 3.2. SSM Assignment inside the Node 282 While the SSM multicast addresses have only local (to the node) 283 significance, there is still a minor issue on how to assign the 284 addresses between the applications running on the same node (or more 285 precisely, an IP address). 287 This assignment is not considered to be a problem because typically 288 the addresses for the applications are selected manually or 289 statically, but if done using an Application Programming Interface 290 (API), the API could check that the addresses do not conflict prior 291 to assigning one. 293 3.3. Manually Configured Assignment 295 With manually configured assignment, the network operator who has a 296 multicast address prefix assigns the multicast group addresses to the 297 requesting nodes using a manual process. 299 Typically the user or administrator which wants to use a multicast 300 address for particular application requests an address from the 301 network operator using phone, email, or similar means, and the 302 network operator provides the user with a multicast address. Then 303 the user/administrator of the node or application manually configures 304 the application to use the assigned multicast address. 306 This is a relatively simple process; it has been sufficient for 307 certain applications which require manual configuration in any case, 308 or which cannot or do not want to justify a static IANA assignment. 309 The manual assignment works when the number of participants in a 310 group is small, as each participant has to be manually configured. 312 This is the most commonly used technique when the multicast 313 application does not have a static IANA assignment. 315 3.4. Static IANA Assignment 317 In contrast to manually configured assignment, as described above, 318 static IANA assignment refers to getting an assignment for the 319 particular application directly from IANA. There are two main forms 320 of IANA assignment: global and scope-relative. Guidelines for IANA 321 are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. 323 3.4.1. Global IANA Assignment 325 Globally unique address assignment is seen as lucrative because it's 326 the simplest approach for application developers since they can then 327 hard-code the multicast address. Hard-coding requires no lease of 328 the usable multicast address, and likewise the client applications do 329 not need to perform any kind of service discovery (but depending on 330 hard-coded addresses). However, there is an architectural scaling 331 problem with this approach, as it encourages a "land-grab" of the 332 limited multicast address space. 334 [RFC3138] describes how to handle those GLOP assignments (called 335 "eGLOP") which use the private-use AS number space (233.252.0.0/14). 336 It was envisioned that IANA would delegate the responsibility of 337 these to RIRs, which would assign or allocate addresses as best 338 seemed fit. However, this was never carried out as IANA did not make 339 these allocations to RIRs due to procedural reasons. 341 In summary, there are applications which have obtained a global 342 static IANA assignment and while some of which are really needed, 343 some of which probably should not have been granted. Conversely, 344 there are some applications that have not obtained a static IANA 345 assignment, yet should have requested an assignment and been granted 346 one. 348 3.4.2. Scope-relative IANA Assignment 350 IANA also assigns numbers as an integer offset from the highest 351 address in each IPv4 administrative scope as described in [RFC2365]. 352 For example, the SLPv2 discovery scope-relative offset is "2", so 353 SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is 354 "239.255.255.253", within the IPv4 Organization Local-Scope 355 (239.192.0.0/14) it is "239.195.255.253", and so on. 357 Similar scope-relative assignments also exist with IPv6 [RFC2375]. 358 As IPv6 multicast addresses have much more flexible scoping, scope- 359 relative assignments are also applicable to global scopes. The 360 assignment policies are described in [RFC3307]. 362 3.5. Dynamic Assignments 364 The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from 365 Multicast Address Allocation Servers (MAAS) to applications and 366 nodes, with Multicast Address Dynamic Client Allocation Protocol 367 (MADCAP) [RFC2730] as an example. Since then, there has been a 368 proposal for DHCPv6 assignment 369 [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]. 371 It would be rather straightforward to deploy a dynamic assignment 372 protocol which would lease group addresses based on a multicast 373 prefix to the applications wishing to use multicast. For example, 374 only few have implemented MADCAP, and it's not significantly 375 deployed. Moreover, it is not clear how widely for example the APIs 376 for communication between the multicast application and the MADCAP 377 client operating at the host have been implemented [RFC2771]. 379 An entirely different approach is Session Announcement Protocol (SAP) 380 [RFC2974]. In addition to advertising global multicast sessions, the 381 protocol also has associated ranges of addresses for both IPv4 and 382 IPv6 which can be used by SAP-aware applications to create new groups 383 and new group addresses. Creating a session (and obtaining an 384 address) is a rather tedious process which is why it isn't done all 385 that often. (Note that the IPv6 SAP address is unroutable in the 386 inter-domain multicast.) 388 A conclusion about dynamic assignment protocols is that: 390 1. multicast is not significantly attractive in the first place, 392 2. very many applications have a static IANA assignment and thus 393 require no dynamic or manual assignment, 395 3. those that cannot be easily satisfied with IANA or manual 396 assignment (i.e., where dynamic assignment would be desirable) 397 are rather marginal, or 399 4. that there are other gaps why dynamic assignments are not seen as 400 a useful approach (for example, issues related to service 401 discovery/rendezvous). 403 In consequence, more work on rendezvous/service discovery would be 404 needed to make dynamic assignments more useful. 406 4. Summary and Future Directions 408 This section summarizes the mechanisms and analysis discussed in this 409 memo, and presents some potential future directions. 411 4.1. Prefix Allocation 413 Summary of prefix allocation methods for ASM is in Figure 1. 415 +-------+--------------------------------+--------+--------+ 416 | Sect. | Prefix allocation method | IPv4 | IPv6 | 417 +-------+--------------------------------+--------+--------+ 418 | 2.1.1 | Derived: GLOP | Yes | NoNeed*| 419 | 2.1.2 | Derived: Unicast-prefix-based |No -yet | Yes | 420 | 2.2 | Administratively scoped | Yes | NoNeed*| 421 | 2.3 | Static IANA allocation | No | No | 422 | 2.4 | Dynamic allocation protocols | No | No | 423 +-------+--------------------------------+--------+--------+ 424 * = the need satisfied by IPv6 unicast-prefix-based allocation. 426 Figure 1 428 o Only ASM is affected by the assignment/allocation issues (however, 429 both ASM and SSM have roughly the same address discovery issues). 431 o GLOP allocations seem to provide a sufficient IPv4 multicast 432 allocation mechanism for now, but could be extended in future. 433 Administratively scoped allocations provide the opportunity for 434 internal IPv4 allocations. 436 o Unicast-prefix-based addresses and the derivatives provide good 437 allocation strategy with IPv6, also for scoped multicast 438 addresses. 440 o Dynamic allocations are a too complex and unnecessary mechanism. 442 o Static IANA allocations are generally an architecturally 443 unacceptable approach. 445 4.2. Address Assignment 447 Summary of address assignment methods is in Figure 2. 449 +--------+--------------------------------+----------+----------+ 450 | Sect. | Address assignment method | IPv4 | IPv6 | 451 +--------+--------------------------------+----------+----------+ 452 | 3.1 | Derived: link-scope addresses | No | Yes | 453 | 3.2 | SSM (inside the node) | Yes | Yes | 454 | 3.3 | Manual assignment | Yes | Yes | 455 | 3.4.1 | Global IANA/RIR assignment |LastResort|LastResort| 456 | 3.4.2 | Scope-relative IANA assignment | Yes | Yes | 457 | 3.5 | Dynamic assignment protocols | Yes | Yes | 458 +--------+--------------------------------+----------+----------+ 460 Figure 2 462 o Manually configured assignment is what's typically done today, and 463 works to a sufficient degree in smaller scale. 465 o Global IANA assignment has been done extensively in the past, but 466 it needs to be tightened down to prevent problems caused by "land- 467 grabbing". Scope-relative IANA assignment is acceptable but the 468 size of the pool is not very high. Inter-domain routing of IPv6 469 IANA-assigned prefixes is likely going to be challenging. 471 o Dynamic assignment, e.g., MADCAP has been implemented, but there 472 is no wide deployment, so a solution is there. However, either 473 there are other gaps in the multicast architecture or there is no 474 sufficient demand for it in the first place when manual and static 475 IANA assignments are available. Assignments using SAP also exist 476 but are not common; global SAP assignment is unfeasible with IPv6. 478 o Derived assignments are only applicable in a fringe case of link- 479 scoped multicast. 481 4.3. Future Actions 483 o Multicast address discovery/"rendezvous" needs to be analyzed at 484 more length, and an adequate solution provided; the result also 485 needs to be written down to be shown to the IANA static assignment 486 requestors. See [I-D.ietf-mboned-addrdisc-problems] for more. 488 o IPv6 multicast DAD and/or multicast prefix communication 489 mechanisms should be analyzed (e.g., 490 [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, 491 and specify if yes. 493 o The IETF should consider whether to specify more ranges of the 494 IPv4 administratively scoped address space for static allocation 495 for applications which should not be routed over the Internet 496 (such as backup software, etc. -- so that these wouldn't need to 497 use global addresses which should never leak in any case). 499 o The IETF should seriously consider its static IANA allocations 500 policy, e.g., "locking it down" to a stricter policy (like "IETF 501 Consensus") and looking at developing the discovery/rendezvous 502 functions, if necessary. 504 5. Acknowledgements 506 Tutoring a couple multicast-related papers, the latest by Kaarle 507 Ritvanen [RITVANEN] convinced the author that the up-to-date 508 multicast address assignment/allocation documentation is necessary. 510 Multicast address allocations/assignments were discussed at the 511 MBONED WG session at IETF59 [MBONED-IETF59]. 513 Dave Thaler, James Lingard, and Beau Williamson provided useful 514 feedback for the preliminary version of this memo. Myung-Ki Shin, 515 Jerome Durand, John Kristoff, and Dave Price also suggested 516 improvements. 518 6. IANA Considerations 520 This memo includes no request to IANA, but as the allocation and 521 assignment of multicast addresses are related to IANA functions, it 522 wouldn't hurt if the IANA reviewed this entire memo. 524 IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still 525 apply to the administratively scoped prefixes. 527 IANA may be interested in reviewing the accuracy of the statement on 528 eGLOP address assignments in Section 3.4.1. 530 (RFC-editor: please remove this section at publication.) 532 7. Security Considerations 534 This memo only describes different approaches to allocating and 535 assigning multicast addresses, and this has no security 536 considerations; the security analysis of the mentioned protocols is 537 out of scope of this memo. 539 Obviously, especially the dynamic assignment protocols are inherently 540 vulnerable to resource exhaustion attacks, as discussed e.g., in 541 [RFC2730]. 543 8. References 545 8.1. Normative References 547 [I-D.ietf-ipv6-link-scoped-mcast] 548 Park, J., "A Method for Generating Link Scoped IPv6 549 Multicast Addresses", draft-ietf-ipv6-link-scoped-mcast-09 550 (work in progress), July 2005. 552 [I-D.ietf-ssm-arch] 553 Holbrook, H. and B. Cain, "Source-Specific Multicast for 554 IP", draft-ietf-ssm-arch-07 (work in progress), 555 October 2005. 557 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 558 RFC 2365, July 1998. 560 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 561 "IANA Guidelines for IPv4 Multicast Address Assignments", 562 BCP 51, RFC 3171, August 2001. 564 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 565 BCP 53, RFC 3180, September 2001. 567 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 568 Multicast Addresses", RFC 3306, August 2002. 570 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 571 Addresses", RFC 3307, August 2002. 573 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 574 (IPv6) Addressing Architecture", RFC 3513, April 2003. 576 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 577 Point (RP) Address in an IPv6 Multicast Address", 578 RFC 3956, November 2004. 580 8.2. Informative References 582 [I-D.ietf-malloc-aap] 583 Handley, M. and S. Hanna, "Multicast Address Allocation 584 Protocol (AAP)", June 2000. 586 [I-D.ietf-mboned-addrdisc-problems] 587 Savola, P., "Lightweight Multicast Address Discovery 588 Problem Space", draft-ietf-mboned-addrdisc-problems-01 589 (work in progress), November 2005. 591 [I-D.ietf-mboned-ipv4-uni-based-mcast] 592 Thaler, D., "Unicast-Prefix-based IPv4 Multicast 593 Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02 594 (work in progress), October 2004. 596 [I-D.ietf-mboned-rfc3171bis] 597 Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA 598 Guidelines for IPv4 Multicast Address Assignments", 599 draft-ietf-mboned-rfc3171bis-02 (work in progress), 600 March 2004. 602 [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] 603 Durand, J., "IPv6 multicast address assignment with 604 DHCPv6", 605 draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work 606 in progress), February 2005. 608 [I-D.jdurand-ipv6-multicast-ra] 609 Durand, J. and P. Savola, "Route Advertisement Option for 610 IPv6 Multicast Prefixes", 611 draft-jdurand-ipv6-multicast-ra-00 (work in progress), 612 February 2005. 614 [MBONED-IETF59] 615 "MBONED WG session at IETF59", 616 . 618 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 619 RFC 2131, March 1997. 621 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 622 Assignments", RFC 2375, July 1998. 624 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 625 "Service Location Protocol, Version 2", RFC 2608, 626 June 1999. 628 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 629 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 630 December 1999. 632 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 633 Allocation", RFC 2771, February 2000. 635 [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 636 Zone Announcement Protocol (MZAP)", RFC 2776, 637 February 2000. 639 [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet 640 Multicast Address Allocation Architecture", RFC 2908, 641 September 2000. 643 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 644 Kumar, S., and D. Thaler, "The Multicast Address-Set Claim 645 (MASC) Protocol", RFC 2909, September 2000. 647 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 648 Announcement Protocol", RFC 2974, October 2000. 650 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 651 June 2001. 653 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 654 and M. Carney, "Dynamic Host Configuration Protocol for 655 IPv6 (DHCPv6)", RFC 3315, July 2003. 657 [RITVANEN] 658 Ritvanen, K., "Multicast Routing and Addressing", HUT 659 Report, Seminar on Internetworking, May 2004, 660 . 662 Appendix A. Changes 664 (To be removed prior to publication as an RFC.) 666 A.1. Changes since -01 668 o Mention the mechanisms which haven't been so succesful: eGLOP and 669 MZAP. 671 o Remove the appendices on multicast address discovery (a separate 672 draft now) and IPv4 unicast-prefix-based multicast addressing. 674 o Add a note on administraively scoped address space and the 675 expansion ambiguity. 677 o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt 679 o Minor editorial cleanups. 681 Author's Address 683 Pekka Savola 684 CSC - Scientific Computing Ltd. 685 Espoo 686 Finland 688 Email: psavola@funet.fi 690 Full Copyright Statement 692 Copyright (C) The Internet Society (2006). 694 This document is subject to the rights, licenses and restrictions 695 contained in BCP 78, and except as set forth therein, the authors 696 retain all their rights. 698 This document and the information contained herein are provided on an 699 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 700 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 701 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 702 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 703 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 704 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 706 Intellectual Property 708 The IETF takes no position regarding the validity or scope of any 709 Intellectual Property Rights or other rights that might be claimed to 710 pertain to the implementation or use of the technology described in 711 this document or the extent to which any license under such rights 712 might or might not be available; nor does it represent that it has 713 made any independent effort to identify any such rights. Information 714 on the procedures with respect to rights in RFC documents can be 715 found in BCP 78 and BCP 79. 717 Copies of IPR disclosures made to the IETF Secretariat and any 718 assurances of licenses to be made available, or the result of an 719 attempt made to obtain a general license or permission for the use of 720 such proprietary rights by implementers or users of this 721 specification can be obtained from the IETF on-line IPR repository at 722 http://www.ietf.org/ipr. 724 The IETF invites any interested party to bring to its attention any 725 copyrights, patents or patent applications, or other proprietary 726 rights that may cover technology that may be required to implement 727 this standard. Please address the information to the IETF at 728 ietf-ipr@ietf.org. 730 Acknowledgment 732 Funding for the RFC Editor function is provided by the IETF 733 Administrative Support Activity (IASA).