idnits 2.17.1 draft-ietf-mboned-addrarch-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (October 25, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2908 (Obsoleted by RFC 6308) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 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: 2908 (if approved) October 25, 2010 5 Intended status: Informational 6 Expires: April 28, 2011 8 Overview of the Internet Multicast Addressing Architecture 9 draft-ietf-mboned-addrarch-07.txt 11 Abstract 13 The lack of up-to-date documentation on IP multicast address 14 allocation and assignment procedures has caused a great deal of 15 confusion. To clarify the situation, this memo describes the 16 allocation and assignment techniques and mechanisms currently (as of 17 this writing) in use. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 28, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3 55 2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 56 2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 57 2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 58 2.1.2. Unicast-prefix-based Allocation . . . . . . . . . . . 4 59 2.2. Administratively Scoped Allocation . . . . . . . . . . . . 5 60 2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 61 2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 62 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6 63 3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7 64 3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7 65 3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7 66 3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 8 67 3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8 68 3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8 69 3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 70 4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 71 4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10 72 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 73 4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 81 A.1. Changes between -06 and -07 . . . . . . . . . . . . . . . 15 82 A.2. Changes between -05 and -06 . . . . . . . . . . . . . . . 15 83 A.3. Changes between -04 and -05 . . . . . . . . . . . . . . . 15 84 A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 16 85 A.5. Changes between -02 and -03 . . . . . . . . . . . . . . . 16 86 A.6. Changes between -01 and -02 . . . . . . . . . . . . . . . 16 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 Good, up-to-date documentation of IP multicast is close to non- 92 existent. Particularly, this is an issue with multicast address 93 allocations (to networks and sites) and assignments (to hosts and 94 applications). This problem is stressed by the fact that there 95 exists confusing or misleading documentation on the subject 96 [RFC2908]. The consequence is that those who wish to learn about IP 97 multicast and how the addressing works do not get a clear view of the 98 current situation. 100 The aim of this document is to provide a brief overview of multicast 101 addressing and allocation techniques. The term 'addressing 102 architecture' refers to the set of addressing mechanisms and methods 103 in an informal manner. 105 It is important to note that Source-specific Multicast (SSM) 106 [RFC4607] does not have these addressing problems because SSM group 107 addresses have only local significance; hence, this document focuses 108 on the Any Source Multicast (ASM) model. 110 This memo obsoletes and re-classifies to Historic RFC 2908, and re- 111 classifies to Historic RFCs 2776 and 2909. 113 1.1. Terminology: Allocation or Assignment 115 Almost all multicast documents and many other RFCs (such as DHCPv4 116 [RFC2131] and DHCPv6 [RFC3315]) have used the terms address 117 "allocation" and "assignment" interchangeably. However, the operator 118 and address management communities use these terms for two 119 conceptually different processes. 121 In unicast operations, address allocations refer to leasing a large 122 block of addresses from Internet Assigned Numbers Authority (IANA) to 123 a Regional Internet Registry (RIR) or from RIR to a Local Internet 124 Registry (LIR) possibly through a National Internet Registry (NIR). 125 Address assignments, on the other hand, are the leases of smaller 126 address blocks or even single addresses to the end-user sites or end- 127 users themselves. 129 Therefore, in this memo, we will separate the two different 130 functions: "allocation" describes how larger blocks of addresses are 131 obtained by the network operators, and "assignment" describes how 132 applications, nodes or sets of nodes obtain a multicast address for 133 their use. 135 2. Multicast Address Allocation 137 Multicast address allocation, i.e., how a network operator might be 138 able to obtain a larger block of addresses, can be handled in a 139 number of ways as described below. 141 Note that these are all only pertinent to ASM -- SSM requires no 142 address block allocation because the group address has only local 143 significance (however, we discuss the address assignment inside the 144 node in Section 3.2). 146 2.1. Derived Allocation 148 Derived allocations take the unicast prefix or some other properties 149 of the network (e.g., an autonomous system (AS) number) to determine 150 unique multicast address allocations. 152 2.1.1. GLOP Allocation 154 GLOP address allocation [RFC3180] inserts the 16-bit public AS number 155 in the middle of the IPv4 multicast prefix 233.0.0.0/8, so that each 156 AS number can get a /24 worth of multicast addresses. While this is 157 sufficient for multicast testing or small scale use, it might not be 158 sufficient in all cases for extensive multicast use. 160 A minor operational debugging issue with GLOP addresses is that the 161 connection between the AS and the prefix is not apparent from the 162 prefix when the AS number is greater than 255, but has to be 163 calculated (e.g., from [RFC3180], AS 5662 maps to 233.22.30.0/24). A 164 usage issue is that GLOP addresses are not tied to any prefix but to 165 routing domains, so they cannot be used or calculated automatically. 167 GLOP mapping is not available with 4-byte AS numbers [RFC4893]. 168 Unicast-prefix-based Allocation or an IANA allocation from "AD-HOC 169 Block III" (the previous so-called "eGLOP" block) could be used 170 instead as needed. 172 The GLOP allocation algorithm has not been defined for IPv6 multicast 173 because the unicast-prefix-based allocation (described below) 174 addresses the same need in a simpler fashion. 176 2.1.2. Unicast-prefix-based Allocation 178 RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 high- 179 order bits of an IPv6 unicast address in the prefix part of the IPv6 180 multicast address, leaving at least 32 bits of group-id space 181 available after the prefix mapping. 183 A similar IPv4 mapping is described in [RFC6034], but it provides a 184 limited number of addresses (e.g., 1 per an IPv4 /24 block). 186 The IPv6 unicast-prefix-based allocations are an extremely useful way 187 to allow each network operator, even each subnet, to obtain multicast 188 addresses easily, through an easy computation. Further, as the IPv6 189 multicast header also includes the scope value [RFC4291], multicast 190 groups of smaller scope can also be used with the same mapping. 192 The IPv6 Embedded RP technique [RFC3956], used with Protocol 193 Independent Multicast - Sparse Mode (PIM-SM), further leverages the 194 unicast-prefix-based allocations, by embedding the unicast prefix and 195 interface identifier of the PIM-SM Rendezvous Point (RP) in the 196 prefix. This provides all the necessary information needed to the 197 routing systems to run the group in either inter- or intra-domain 198 operation. A difference from RFC 3306 is, however, that the hosts 199 cannot calculate their "multicast prefix" automatically, as the 200 prefix depends on the decisions of the operator setting up the RP, 201 but instead requires an assignment method. 203 All the IPv6 unicast-prefix-based allocation techniques provide 204 sufficient amount of multicast address space for network operators. 206 2.2. Administratively Scoped Allocation 208 Administratively scoped multicast address allocation [RFC2365] is 209 provided by two different means: under 239.0.0.0/8 in IPv4 or by 210 4-bit encoding in the IPv6 multicast address prefix [RFC4291]. 212 Since IPv6 administratively scoped allocations can be handled with 213 unicast-prefix-based multicast addressing as described in 214 Section 2.1.2, we'll only discuss IPv4 in this section. 216 The IPv4 administratively scoped prefix 239.0.0.0/8 is further 217 divided into Local Scope (239.255.0.0/16) and Organization Local 218 Scope (239.192.0.0/14); other parts of the administrative scopes are 219 either reserved for expansion or undefined [RFC2365]. However, RFC 220 2365 is ambiguous as to whether the enterprises or the IETF are 221 allowed to expand the space. 223 Topologies which act under a single administration can easily use the 224 scoped multicast addresses for their internal groups. Groups which 225 need to be shared between multiple routing domains (even if not 226 propagated through the Internet) are more problematic and typically 227 need an assignment of a global multicast address because their scope 228 is undefined. 230 There is a large number of multicast applications (such as "Norton 231 Ghost") which are restricted either to a link or a site, and it is 232 extremely undesirable to propagate them further (beyond the link or 233 the site). Typically many such applications have been given or have 234 hijacked a static IANA address assignment. Given the fact that 235 assignments to typically locally used applications come from the same 236 range as global applications, implementing proper propagation 237 limiting is challenging. Filtering would be easier if a separate, 238 identifiable range would be used for such assignments in the future; 239 this is an area of further future work. 241 There has also been work on a protocol to automatically discover 242 multicast scope zones [RFC2776], but it has never been widely 243 implemented or deployed. 245 2.3. Static IANA Allocation 247 In some rare cases, organizations may have been able to obtain static 248 multicast address allocations (of up to 256 addresses) directly from 249 IANA. Typically these have been meant as a block of static 250 assignments to multicast applications, as described in Section 3.4.1. 251 If another means of obtaining addresses is available that approach is 252 preferable. 254 Especially for those operators that only have a 32-bit AS number and 255 need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the 256 previous so-called "eGLOP" block) is an option [RFC5771]. 258 2.4. Dynamic Allocation 260 RFC 2908 [RFC2908] proposed three different layers of multicast 261 address allocation and assignment, where layers 3 (inter-domain 262 allocation) and layer 2 (intra-domain allocation) could be applicable 263 here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an 264 example of the former, and Multicast Address Allocation Protocol 265 (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest 266 and technical problems) is an example of the latter. 268 Both of the proposed allocation protocols were quite complex, and 269 have never been deployed or seriously implemented. 271 It can be concluded that dynamic multicast address allocation 272 protocols provide no benefit beyond GLOP/unicast-prefix-based 273 mechanisms and have been abandoned. 275 3. Multicast Address Assignment 277 There are a number of possible ways for an application, node or set 278 of nodes to learn a multicast address as described below. 280 Any IPv6 address assignment method should be aware of the guidelines 281 for the assignment of group-IDs for IPv6 multicast addresses 282 [RFC3307]. 284 3.1. Derived Assignment 286 There are significantly fewer options for derived address assignment 287 compared to derived allocation. Derived multicast assignment has 288 only been specified for IPv6 link-scoped multicast [RFC4489], where 289 the EUI64 is embedded in the multicast address, providing a node with 290 unique multicast addresses for link-local ASM communications. 292 3.2. SSM Assignment inside the Node 294 While SSM multicast addresses have only local (to the node) 295 significance, there is still a minor issue on how to assign the 296 addresses between the applications running on the same IP address. 298 This assignment is not considered to be a problem because typically 299 the addresses for these applications are selected manually or 300 statically, but if done using an Application Programming Interface 301 (API), the API could check that the addresses do not conflict prior 302 to assigning one. 304 3.3. Manually Configured Assignment 306 With manually configured assignment, a network operator who has a 307 multicast address prefix assigns the multicast group addresses to the 308 requesting nodes using a manual process. 310 Typically, the user or administrator that wants to use a multicast 311 address for a particular application requests an address from the 312 network operator using phone, email, or similar means, and the 313 network operator provides the user with a multicast address. Then 314 the user/administrator of the node or application manually configures 315 the application to use the assigned multicast address. 317 This is a relatively simple process; it has been sufficient for 318 certain applications which require manual configuration in any case, 319 or which cannot or do not want to justify a static IANA assignment. 320 The manual assignment works when the number of participants in a 321 group is small, as each participant has to be manually configured. 323 This is the most commonly used technique when the multicast 324 application does not have a static IANA assignment. 326 3.4. Static IANA Assignment 328 In contrast to manually configured assignment, as described above, 329 static IANA assignment refers to getting an assignment for the 330 particular application directly from IANA. There are two main forms 331 of IANA assignment: global and scope-relative. Guidelines for IANA 332 are described in [RFC5771]. 334 3.4.1. Global IANA Assignment 336 Globally unique address assignment is seen as lucrative because it's 337 the simplest approach for application developers since they can then 338 hard-code the multicast address. Hard-coding requires no lease of 339 the usable multicast address, and likewise the client applications do 340 not need to perform any kind of service discovery (but depending on 341 hard-coded addresses). However, there is an architectural scaling 342 problem with this approach, as it encourages a "land-grab" of the 343 limited multicast address space. 345 3.4.2. Scope-relative IANA Assignment 347 IANA also assigns numbers as an integer offset from the highest 348 address in each IPv4 administrative scope as described in [RFC2365]. 349 For example, the SLPv2 discovery scope-relative offset is "2", so 350 SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is 351 "239.255.255.253", within the IPv4 Organization Local-Scope 352 (239.192.0.0/14) it is "239.195.255.253", and so on. 354 Similar scope-relative assignments also exist with IPv6 [RFC2375]. 355 As IPv6 multicast addresses have much more flexible scoping, scope- 356 relative assignments are also applicable to global scopes. The 357 assignment policies are described in [RFC3307]. 359 3.5. Dynamic Assignments 361 The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from 362 Multicast Address Allocation Servers (MAAS) to applications and 363 nodes, with Multicast Address Dynamic Client Allocation Protocol 364 (MADCAP) [RFC2730] as an example. Since then, other mechanisms have 365 also been proposed (e.g., DHCPv6 assignment 366 [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]) but these have not 367 gained traction. 369 It would be rather straightforward to deploy a dynamic assignment 370 protocol which would lease group addresses based on a multicast 371 prefix to applications wishing to use multicast. However, only few 372 have implemented MADCAP, and it hasn't been significantly deployed. 373 So, it is not clear if the lack of deployment is due to a currently 374 missing need. Moreover, it is not clear how widely for example the 375 APIs for communication between the multicast application and the 376 MADCAP client operating at the host have been implemented [RFC2771]. 378 An entirely different approach is Session Announcement Protocol (SAP) 379 [RFC2974]. In addition to advertising global multicast sessions, the 380 protocol also has associated ranges of addresses for both IPv4 and 381 IPv6 which can be used by SAP-aware applications to create new groups 382 and new group addresses. Creating a session (and obtaining an 383 address) is a rather tedious process which is why it isn't done all 384 that often. It is also worth noting that the IPv6 SAP address is 385 unroutable in the inter-domain multicast. 387 A conclusion about dynamic assignment protocols is that: 389 1. multicast is not significantly attractive in the first place, 391 2. most applications have a static IANA assignment and thus require 392 no dynamic or manual assignment, 394 3. those that cannot be easily satisfied with IANA or manual 395 assignment (i.e., where dynamic assignment would be desirable) 396 are rather marginal, or 398 4. that there are other gaps why dynamic assignments are not seen as 399 a useful approach (for example, issues related to service 400 discovery/rendezvous). 402 In consequence, more work on rendezvous/service discovery would be 403 needed to make dynamic assignments more useful. 405 4. Summary and Future Directions 407 This section summarizes the mechanisms and analysis discussed in this 408 memo, and presents some potential future directions. 410 4.1. Prefix Allocation 412 A summary of prefix allocation methods for ASM is shown in Figure 1. 414 +-------+--------------------------------+--------+--------+ 415 | Sect. | Prefix allocation method | IPv4 | IPv6 | 416 +-------+--------------------------------+--------+--------+ 417 | 2.1.1 | Derived: GLOP | Yes | NoNeed*| 418 | 2.1.2 | Derived: Unicast-prefix-based | No | Yes | 419 | 2.2 | Administratively scoped | Yes | NoNeed*| 420 | 2.3 | Static IANA allocation | Yes** | No | 421 | 2.4 | Dynamic allocation protocols | No | No | 422 +-------+--------------------------------+--------+--------+ 423 * = the need satisfied by IPv6 unicast-prefix-based allocation. 424 ** = mainly using the AD-HOC block III (former "eGLOP") 426 Figure 1 428 o Only ASM is affected by the assignment/allocation issues. 430 o With IPv4, GLOP allocations provide a sufficient IPv4 multicast 431 allocation mechanism for those that have 16-bit AS number. IPv4 432 unicast-prefix based allocation offers some addresses. IANA is 433 also allocating from the AD-HOC block III (former "eGLOP") with 434 especially 32-bit AS number holders in mind. Administratively 435 scoped allocations provide the opportunity for internal IPv4 436 allocations. 438 o With IPv6, unicast-prefix-based addresses and the derivatives 439 provide a good allocation strategy and this also works for scoped 440 multicast addresses. 442 o Dynamic allocations are too complex and unnecessary a mechanism. 444 4.2. Address Assignment 446 A summary of address assignment methods is shown in Figure 2. 448 +--------+--------------------------------+----------+----------+ 449 | Sect. | Address assignment method | IPv4 | IPv6 | 450 +--------+--------------------------------+----------+----------+ 451 | 3.1 | Derived: link-scope addresses | No | Yes | 452 | 3.2 | SSM (inside the node) | Yes | Yes | 453 | 3.3 | Manual assignment | Yes | Yes | 454 | 3.4.1 | Global IANA/RIR assignment |LastResort|LastResort| 455 | 3.4.2 | Scope-relative IANA assignment | Yes | Yes | 456 | 3.5 | Dynamic assignment protocols | Yes | Yes | 457 +--------+--------------------------------+----------+----------+ 459 Figure 2 461 o Manually configured assignment is typical today, and works to a 462 sufficient degree in smaller scale. 464 o Global IANA assignment has been done extensively in the past. 465 Scope-relative IANA assignment is acceptable but the size of the 466 pool is not very high. Inter-domain routing of IPv6 IANA-assigned 467 prefixes is likely going to be challenging and as a result that 468 approach is not very appealing. 470 o Dynamic assignment, e.g., MADCAP has been implemented, but there 471 is no wide deployment. Therefore, either there are other gaps in 472 the multicast architecture or there is no sufficient demand for it 473 in the first place when manual and static IANA assignments are 474 available. Assignments using SAP also exist but are not common; 475 global SAP assignment is unfeasible with IPv6. 477 o Derived assignments are only applicable in a fringe case of link- 478 scoped multicast. 480 4.3. Future Actions 482 o Multicast address discovery/"rendezvous" needs to be analyzed at 483 more length, and an adequate solution provided. See 484 [I-D.ietf-mboned-addrdisc-problems] and 485 [I-D.ietf-mboned-session-announcement-req] for more. 487 o The IETF should consider whether to specify more ranges of the 488 IPv4 administratively scoped address space for static allocation 489 for applications which should not be routed over the Internet 490 (such as backup software, etc. -- so that these wouldn't need to 491 use global addresses which should never leak in any case). 493 o The IETF should consider its static IANA allocations policy, e.g., 494 "locking it down" to a stricter policy (like "IETF Consensus") and 495 looking at developing the discovery/rendezvous functions, if 496 necessary. 498 5. Acknowledgements 500 Tutoring a couple of multicast-related papers, the latest by Kaarle 501 Ritvanen [RITVANEN] convinced the author that updated multicast 502 address assignment/allocation documentation is needed. 504 Multicast address allocations/assignments were discussed at the 505 MBONED WG session at IETF59 [MBONED-IETF59]. 507 Dave Thaler, James Lingard, and Beau Williamson provided useful 508 feedback for the preliminary version of this memo. Myung-Ki Shin, 509 Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred 510 Hoenes also suggested improvements. 512 6. IANA Considerations 514 This memo includes no request to IANA. 516 IANA considerations in sections 4.1.1 and 4.1.2 of obsoleted and now 517 Historic [RFC2908] were never implemented in IANA registry. No 518 update is necessary. 520 (RFC-editor: This section may be removed prior to publication; 521 alternatively, the second paragraph may be left intact.) 523 7. Security Considerations 525 This memo only describes different approaches to allocating and 526 assigning multicast addresses, and this has no security 527 considerations; the security analysis of the mentioned protocols is 528 out of scope of this memo. 530 Obviously, especially the dynamic assignment protocols are inherently 531 vulnerable to resource exhaustion attacks, as discussed e.g., in 532 [RFC2730]. 534 8. References 535 8.1. Normative References 537 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 538 RFC 2365, July 1998. 540 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 541 BCP 53, RFC 3180, September 2001. 543 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 544 Multicast Addresses", RFC 3306, August 2002. 546 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 547 Addresses", RFC 3307, August 2002. 549 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 550 Point (RP) Address in an IPv6 Multicast Address", 551 RFC 3956, November 2004. 553 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 554 Architecture", RFC 4291, February 2006. 556 [RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for 557 Generating Link-Scoped IPv6 Multicast Addresses", 558 RFC 4489, April 2006. 560 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 561 IP", RFC 4607, August 2006. 563 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 564 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 565 March 2010. 567 [RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast 568 Addresses", RFC 6034, October 2010. 570 8.2. Informative References 572 [I-D.ietf-malloc-aap] 573 Handley, M. and S. Hanna, "Multicast Address Allocation 574 Protocol (AAP)", June 2000. 576 [I-D.ietf-mboned-addrdisc-problems] 577 Savola, P., "Lightweight Multicast Address Discovery 578 Problem Space", draft-ietf-mboned-addrdisc-problems-02 579 (work in progress), March 2006. 581 [I-D.ietf-mboned-session-announcement-req] 582 Asaeda, H. and V. Roca, "Requirements for IP Multicast 583 Session Announcement", 584 draft-ietf-mboned-session-announcement-req-03 (work in 585 progress), March 2010. 587 [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] 588 Durand, J., "IPv6 multicast address assignment with 589 DHCPv6", 590 draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work 591 in progress), February 2005. 593 [MBONED-IETF59] 594 "MBONED WG session at IETF59", 595 . 597 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 598 RFC 2131, March 1997. 600 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 601 Assignments", RFC 2375, July 1998. 603 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 604 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 605 December 1999. 607 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 608 Allocation", RFC 2771, February 2000. 610 [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 611 Zone Announcement Protocol (MZAP)", RFC 2776, 612 February 2000. 614 [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet 615 Multicast Address Allocation Architecture", RFC 2908, 616 September 2000. 618 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 619 Kumar, S., and D. Thaler, "The Multicast Address-Set Claim 620 (MASC) Protocol", RFC 2909, September 2000. 622 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 623 Announcement Protocol", RFC 2974, October 2000. 625 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 626 and M. Carney, "Dynamic Host Configuration Protocol for 627 IPv6 (DHCPv6)", RFC 3315, July 2003. 629 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 630 Number Space", RFC 4893, May 2007. 632 [RITVANEN] 633 Ritvanen, K., "Multicast Routing and Addressing", HUT 634 Report, Seminar on Internetworking, May 2004, 635 . 637 Appendix A. Changes 639 (To be removed prior to publication as an RFC.) 641 A.1. Changes between -06 and -07 643 o Update uni-based-mcast and iana updates references to point to 644 RFCs. 646 A.2. Changes between -05 and -06 648 o Editorial updates. 650 o Obsolete only RFC2908; the rest only move to Historic. 652 o Category is Informational instead of BCP (in line with the routing 653 architecture. 655 o Move 3171bis and v4-uni-based to Normative references in order to 656 make sure we don't go forward until they're resolved. 658 o Resolve pending issues per IETF75 discussion, in particular major 659 changes to eGLOP and IANA policy discussions. 661 A.3. Changes between -04 and -05 663 o Editorial updates. These and the following are from Spencer 664 Dawkins. 666 o New text explicitly stating that GLOP for v6 is not needed and 667 GLOP for 4byte ASNs isn't (and likely won't be) defined. 669 o Expand reasons for filtering difficulties with global IANA 670 assignments for local apps, and that it would be easier if these 671 were done from the local pool. 673 o Explicitly mention dynamic allocations protocols' lack of benefit 674 and abandonment. 676 A.4. Changes between -03 and -04 678 o S/scope-relative/administratively scoped/ and expand Static IANA 679 Assignment section to two subsections; mainly from Dave Price. 681 o Mention the routing challenges of IPv6 IANA assigned prefixes in 682 section 4.2 684 A.5. Changes between -02 and -03 686 o Reword architectural implications of Static IANA and editorial 687 improvements; mainly from John Kristoff. 689 A.6. Changes between -01 and -02 691 o Mention the mechanisms which haven't been so successful: eGLOP and 692 MZAP. 694 o Remove the appendices on multicast address discovery (a separate 695 draft now) and IPv4 unicast-prefix-based multicast addressing. 697 o Add a note on administratively scoped address space and the 698 expansion ambiguity. 700 o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt 702 o Minor editorial cleanups. 704 Author's Address 706 Pekka Savola 707 CSC - Scientific Computing Ltd. 708 Espoo 709 Finland 711 Email: psavola@funet.fi