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