idnits 2.17.1 draft-ietf-mboned-addrarch-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 700. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (October 18, 2005) is 6755 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ipv6-link-scoped-mcast' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mboned-ipv4-uni-based-mcast' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC2608' is defined on line 596, 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-00 == 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 (~~), 10 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 October 18, 2005 5 approved) 6 Expires: April 21, 2006 8 Overview of the Internet Multicast Addressing Architecture 9 draft-ietf-mboned-addrarch-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 21, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The lack of up-to-date documentation on IP multicast address 43 allocation and assignment procedures has caused a great deal of 44 confusion. To clarify the situation, this memo describes the 45 allocation and assignment techniques and mechanisms currently (as of 46 this writing) in use. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3 52 2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 53 2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 54 2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 55 2.1.2. Unicast-prefix -based Allocation . . . . . . . . . . . 4 56 2.2. Scope-relative Allocation . . . . . . . . . . . . . . . . 5 57 2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 58 2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 59 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6 60 3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7 61 3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7 62 3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7 63 3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 7 64 3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 65 4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 66 4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 9 67 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 10 68 4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 75 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 14 76 A.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 14 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 Intellectual Property and Copyright Statements . . . . . . . . . . 15 80 1. Introduction 82 Good, up-to-date documentation of IP multicast is close to non- 83 existent. Particularly, this is an issue with multicast address 84 allocations (to networks and sites) and assignments (to hosts and 85 applications). This problem is stressed by the fact that there 86 exists confusing or misleading documentation on the subject 87 [RFC2908]. The consequence is that those who wish to learn of IP 88 multicast and how the addressing works do not get a clear view of the 89 current situation. 91 The aim of this document is to provide a brief overview of multicast 92 addressing and allocation techniques. The term 'addressing 93 architecture' refers to the set of addressing mechanisms and methods 94 in an informal manner. 96 It is important to note that Source-specific Multicast (SSM) 97 [I-D.ietf-ssm-arch] does not have these addressing problems; hence, 98 this document focuses on the Any Source Multicast (ASM) model. 100 This memo obsoletes RFCs 2776, 2908, and 2909 and re-classifies them 101 Historic. 103 1.1. Terminology: Allocation or Assignment 105 Almost all multicast documents and many other RFCs (such as DHCPv4 106 [RFC2131] and DHCPv6 [RFC3315]) have used the terms address 107 "allocation" and "assignment" interchangeably. However, the operator 108 and address management communities use these for two conceptually 109 different processes. 111 In unicast operations, address allocations refer to leasing a large 112 block of addresses from Internet Assigned Numbers Authority (IANA) to 113 a Regional Internet Registry (RIR) or from RIR to a Local Internet 114 Registry (LIR) possibly through a National Internet Registry (NIR). 115 Address assignments, on the other hand, are the leases of smaller 116 address blocks or even single addresses to the end-user sites or end- 117 users themselves. 119 Therefore, in this memo, we will separate the two different 120 functions: "allocation" describes how larger blocks of addresses are 121 obtained by the network operators, and "assignment" describes how 122 applications, nodes or sets of nodes obtain a multicast address for 123 their use. 125 2. Multicast Address Allocation 127 Multicast address allocation, i.e., how a network operator might be 128 able to obtain a larger block of addresses, can be handled in a 129 number of ways as described below. 131 Note that these are all only pertinent to ASM -- SSM requires no 132 address block allocation because the group address has only local 133 significance (however, we discuss the address assignment inside the 134 node in Section 3.2). 136 2.1. Derived Allocation 138 Derived allocations take the unicast prefix or some other properties 139 of the network to determine unique multicast address allocations. 141 2.1.1. GLOP Allocation 143 GLOP address allocation [RFC3180] inserts the 16-bit public 144 Autonomous System (AS) number in the middle of the IPv4 multicast 145 prefix 233.0.0.0/8, so that each AS number can get a /24 worth of 146 multicast addresses. While this is sufficient for multicast testing 147 or small scale use, it might not be sufficient in all cases for 148 extensive multicast use. 150 A minor operational debugging issue with GLOP addresses is that the 151 connection between the AS and the prefix is not apparent from the 152 prefix when the AS number is greater than 255, but has to be 153 calculated (e.g., from [RFC3180], AS 5662 maps to 233.22.30.0/24). A 154 usage issue is that GLOP addresses are not tied to any prefix but to 155 routing domains, so they cannot be used or calculated automatically. 157 2.1.2. Unicast-prefix -based Allocation 159 RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first 160 bits of an IPv6 unicast address in the prefix part of the IPv6 161 multicast address, leaving at least 32 bits of group-id space 162 available after the prefix mapping. 164 A similar mapping has been proposed for IPv4 [I-D.ietf-mboned-ipv4- 165 uni-based-mcast], but it provides a rather low amount of addresses 166 (e.g., 1 per an IPv4 /24 block). While there exist large networks 167 without an AS number of their own, this has not been seen to add 168 sufficient value compared to GLOP addressing. 170 The IPv6 unicast-prefix-based allocations are an extremely useful way 171 to allow each network operator, even each subnet, obtain multicast 172 addresses easily, through an easy computation. Further, as the IPv6 173 multicast header also includes the scope value [RFC3513], multicast 174 groups of smaller scope can also be used with the same mapping. 176 The IPv6 Embedded RP technique [RFC3956], used with Protocol 177 Independent Multicast - Sparse Mode (PIM-SM), further leverages the 178 unicast prefix based allocations, by embedding the unicast prefix and 179 interface identifier of the PIM-SM Rendezvous Point (RP) in the 180 prefix. This provides all the necessary information needed to the 181 routing systems to run the group in either inter- or intra-domain 182 operation. A difference to RFC 3306 is, however, that the hosts 183 cannot calculate their "multicast prefix" automatically, as the 184 prefix depends on the decisions of the operator setting up the RP but 185 rather requires an assignment method. 187 All the IPv6 unicast-prefix-based allocation techniques provide 188 sufficient amount of multicast address space for the network 189 operators. 191 2.2. Scope-relative Allocation 193 Administratively scoped multicast [RFC2365] is provided by two 194 different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in 195 the IPv6 multicast address prefix [RFC3513]. 197 As IPv6 scope-relative allocations can be handled with unicast- 198 prefix-based multicast addressing as described in Section 2.1.2, and 199 there is no need for separate scope-relative allocations, we'll just 200 discuss IPv4 in this section. 202 The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to 203 Local Scope (239.255.0.0/16) and Organization Local Scope 204 (239.192.0.0/14); other parts of the administrative scopes are either 205 reserved for expansion or undefined [RFC2365]. However, RFC 2365 is 206 ambiguous as to whether it's the enterprises or the IETF who are 207 allowed to expand the space. 209 Topologies which act under a single administration can easily use the 210 scoped multicast addresses for their internal groups. Groups which 211 need to be shared between multiple routing domains (but not 212 propagated through the Internet) are more problematic and typically 213 need an assignment of a global multicast address because their scope 214 is undefined. 216 There is a large number of multicast applications (such as "Norton 217 Ghost") which are restricted either to a link or a site, and it is 218 extremely undesirable to propagate them further (either to the rest 219 of the site, or beyond the site). Typically many such applications 220 have been given or have hijacked a static IANA address assignment; 221 this makes it challenging to implement proper propagation limiting -- 222 which could be easier if such applications could have been assigned 223 specific scope-relative addresses instead. This is an area of 224 further future work. 226 There has also been work on a protocol to automatically discover 227 multicast scope zones [RFC2776], but it has never been widely 228 implemented or deployed. 230 2.3. Static IANA Allocation 232 In some rare cases, some organizations may have been able to obtain 233 static multicast address allocations (of up to 256 addresses) 234 directly from IANA. Typically these have been meant as a block of 235 static assignments to multicast applications, as described in 236 Section 3.4. In principle, IANA does not allocate multicast address 237 blocks to the operators but GLOP or Unicast-prefix-based allocations 238 should be used instead. 240 2.4. Dynamic Allocation 242 RFC 2908 [RFC2908] proposed three different layers of multicast 243 address allocation and assignment, where layers 3 (inter-domain 244 allocation) and layer 2 (intra-domain allocation) could be applicable 245 here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an 246 example of the former, and Multicast Address Allocation Protocol 247 (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest 248 and technical problems) is an example of the latter. 250 Both of the proposed allocation protocols were quite complex, and 251 have never been deployed or seriously implemented. 253 It can be concluded that there are no dynamic multicast address 254 allocation protocols, and other methods such as GLOP or unicast- 255 prefix-based addressing should be used instead. 257 3. Multicast Address Assignment 259 For multicast address assignment, i.e., how an application learns the 260 address it can use, or a node (or a set of nodes) learns an address 261 it could use for an application, has a number of options as described 262 below. 264 Any IPv6 address assignment method should be aware of the guidelines 265 for the assignment of the group-IDs for IPv6 multicast addresses 266 [RFC3307]. 268 3.1. Derived Assignment 270 There are significantly fewer options for derived address assignment 271 compared to derived allocation. Derived multicast assignment has 272 only been specified for IPv6 link-scoped multicast [I-D.ietf-ipv6- 273 link-scoped-mcast], where the EUI64 is embedded in the multicast 274 address, providing a node with unique multicast addresses for link- 275 local ASM communications. 277 3.2. SSM Assignment inside the Node 279 While the SSM multicast addresses have only local (to the node) 280 significance, there is still a minor issue on how to assign the 281 addresses between the applications running on the same node (or more 282 precisely, an IP address). 284 This assignment is not considered to be a problem because typically 285 the addresses for the applications are selected manually or 286 statically, but if done using an Application Programming Interface 287 (API), the API could check that the addresses do not conflict prior 288 to assigning one. 290 3.3. Manually Configured Assignment 292 With manually configured assignment, the network operator who has a 293 multicast address prefix assigns the multicast group addresses to the 294 requesting nodes using a manual process. 296 Typically the user or administrator which wants to use a multicast 297 address for particular application requests an address from the 298 network operator using phone, email, or similar means, and the 299 network operator provides the user with a multicast address. Then 300 the user/administrator of the node or application manually configures 301 the application to use the assigned multicast address. 303 This is a relatively simple process; it has been sufficient for 304 certain applications which require manual configuration in any case, 305 or which cannot or do not want to justify a static IANA assignment. 306 The manual assignment works when the number of participants in a 307 group is small, as each participant has to be manually configured. 309 This is the most commonly used technique when the multicast 310 application does not have a static IANA assignment. 312 3.4. Static IANA Assignment 314 In contrast to manually configured assignment, as described above, 315 static IANA assignment refers to getting a globally unique assignment 316 for the particular application directly from IANA. Guidelines for 317 IANA are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. 319 This is seen as lucrative because it's the simplest approach for 320 application developers because they can then hard-code the multicast 321 address. Hard-coding requires no lease of the usable multicast 322 address, and likewise the client applications do not need to perform 323 any kind of service discovery (but depending on hard-coded 324 addresses). However, there is an architectural scaling problem with 325 this approach, as it encourages a "land-grab" of the limited 326 multicast address space. 328 [RFC3138] describes how to handle those GLOP assignments (called 329 "eGLOP") which use the private-use AS number space (233.252.0.0/14). 330 It was envisioned that IANA would delegate the responsibility of 331 these to RIRs, which would assign or allocate addresses as best 332 seemed fit. However, this was never carried out as IANA did not make 333 these allocations to RIRs due to procedural reasons. 335 In summary, there are applications which have obtained a static IANA 336 assignment and while some of which are really needed, some of which 337 probably should not have been granted. Conversely, there are some 338 applications that have not obtained a static IANA assignment, yet 339 should have requested an assignment and been granted one. 341 3.5. Dynamic Assignments 343 The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from 344 Multicast Address Allocation Servers (MAAS) to applications and 345 nodes, with Multicast Address Dynamic Client Allocation Protocol 346 (MADCAP) [RFC2730] as an example. Since then, there has been a 347 proposal for DHCPv6 assignment [I-D.jdurand-assign-addr-ipv6- 348 multicast-dhcpv6]. 350 It would be rather straightforward to deploy a dynamic assignment 351 protocol which would lease group addresses based on a multicast 352 prefix to the applications wishing to use multicast. For example, 353 only few have implemented MADCAP, and it's not significantly 354 deployed. Moreover, it is not clear how widely for example the APIs 355 for communication between the multicast application and the MADCAP 356 client operating at the host have been implemented [RFC2771]. 358 An entirely different approach is Session Announcement Protocol (SAP) 359 [RFC2974]. In addition to advertising global multicast sessions, the 360 protocol also has associated ranges of addresses for both IPv4 and 361 IPv6 which can be used by SAP-aware applications to create new groups 362 and new group addresses. Creating a session (and obtaining an 363 address) is a rather tedious process which is why it isn't done all 364 that often. (Note that the IPv6 SAP address is unroutable in the 365 inter-domain multicast.) 367 A conclusion about dynamic assignment protocols is that: 369 1. multicast is not significantly attractive in the first place, 371 2. very many applications have a static IANA assignment and thus 372 require no dynamic or manual assignment, 374 3. those that cannot be easily satisfied with IANA or manual 375 assignment (i.e., where dynamic assignment would be desirable) 376 are rather marginal, or 378 4. that there are other gaps why dynamic assignments are not seen as 379 a useful approach (for example, issues related to service 380 discovery/rendezvous). 382 In consequence, more work on rendezvous/service discovery would be 383 needed to make dynamic assignments more useful. 385 4. Summary and Future Directions 387 This section summarizes the mechanisms and analysis discussed in this 388 memo, and presents some potential future directions. 390 4.1. Prefix Allocation 392 Summary of prefix allocation methods for ASM is in Figure 1. 394 +-------+--------------------------------+--------+--------+ 395 | Sect. | Prefix allocation method | IPv4 | IPv6 | 396 +-------+--------------------------------+--------+--------+ 397 | 2.1.1 | Derived: GLOP | Yes | NoNeed*| 398 | 2.1.2 | Derived: Unicast-prefix-based |No -yet | Yes | 399 | 2.2 | Separate Scope-relative | Yes | NoNeed*| 400 | 2.3 | Static IANA allocation | No | No | 401 | 2.4 | Dynamic allocation protocols | No | No | 402 +-------+--------------------------------+--------+--------+ 403 * = the need satisfied by IPv6 unicast-prefix-based allocation. 405 Figure 1 407 o Only ASM is affected by the assignment/allocation issues (however, 408 both ASM and SSM have roughly the same address discovery issues). 410 o GLOP allocations seem to provide a sufficient IPv4 multicast 411 allocation mechanism for now, but could be extended in future. 412 Scope-relative allocations provide the opportunity for internal 413 IPv4 allocations. 415 o Unicast-prefix-based addresses and the derivatives provide good 416 allocation strategy with IPv6, also for scoped multicast 417 addresses. 419 o Dynamic allocations are a too complex and unnecessary mechanism. 421 o Static IANA allocations are generally an architecturally 422 unacceptable approach. 424 4.2. Address Assignment 426 Summary of address assignment methods is in Figure 2. 428 +-------+--------------------------------+----------+----------+ 429 | Sect. | Address assignment method | IPv4 | IPv6 | 430 +-------+--------------------------------+----------+----------+ 431 | 3.1 | Derived: link-scope addresses | No | Yes | 432 | 3.2 | SSM (inside the node) | Yes | Yes | 433 | 3.3 | Manual assignment | Yes | Yes | 434 | 3.4 | Static IANA/RIR assignment |LastResort|LastResort| 435 | 3.5 | Dynamic assignment protocols | Yes | Yes | 436 +-------+--------------------------------+----------+----------+ 438 Figure 2 440 o Manually configured assignment is what's typically done today, and 441 works to a sufficient degree in smaller scale. 443 o Static IANA assignment has been done extensively in the past, but 444 it needs to be tightened down to prevent problems caused by "land- 445 grabbing". 447 o Dynamic assignment, e.g., MADCAP has been implemented, but there 448 is no wide deployment, so a solution is there. However, either 449 there are other gaps in the multicast architecture or there is no 450 sufficient demand for it in the first place when manual and static 451 IANA assignments are available. Assignments using SAP also exist 452 but are not common; global SAP assignment is unfeasible with IPv6. 454 o Derived assignments are only applicable in a fringe case of link- 455 scoped multicast. 457 4.3. Future Actions 459 o Multicast address discovery/"rendezvous" needs to be analyzed at 460 more length, and an adequate solution provided; the result also 461 needs to be written down to be shown to the IANA static assignment 462 requestors. See [I-D.ietf-mboned-addrdisc-problems] for more. 464 o IPv6 multicast DAD and/or multicast prefix communication 465 mechanisms should be analyzed (e.g., 466 [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, 467 and specify if yes. 469 o The IETF should consider whether to specify more ranges of the 470 IPv4 scope-relative address space for static allocation for 471 applications which should not be routed over the Internet (such as 472 backup software, etc. -- so that these wouldn't need to use global 473 addresses which should never leak in any case). 475 o The IETF should seriously consider its static IANA allocations 476 policy, e.g., "locking it down" to a stricter policy (like "IETF 477 Consensus") and looking at developing the discovery/rendezvous 478 functions, if necessary. 480 5. Acknowledgements 482 Tutoring a couple multicast-related papers, the latest by Kaarle 483 Ritvanen [RITVANEN] convinced the author that the up-to-date 484 multicast address assignment/allocation documentation is necessary. 486 Multicast address allocations/assignments were discussed at the 487 MBONED WG session at IETF59 [MBONED-IETF59]. 489 Dave Thaler, James Lingard, and Beau Williamson provided useful 490 feedback for the preliminary version of this memo. Myung-Ki Shin, 491 Jerome Durand, and John Kristoff also suggested improvements. 493 6. IANA Considerations 495 This memo includes no request to IANA, but as the allocation and 496 assignment of multicast addresses are related to IANA functions, it 497 wouldn't hurt if the IANA reviewed this entire memo. 499 IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still 500 apply to the administratively scoped prefixes. 502 IANA may be interested in reviewing the accuracy of the statement on 503 eGLOP address assignments in Section 3.4. 505 (RFC-editor: please remove this section at publication.) 507 7. Security Considerations 509 This memo only describes different approaches to allocating and 510 assigning multicast addresses, and this has no security 511 considerations; the security analysis of the mentioned protocols is 512 out of scope of this memo. 514 Obviously, especially the dynamic assignment protocols are inherently 515 vulnerable to resource exhaustion attacks, as discussed e.g., in 516 [RFC2730]. 518 8. References 520 8.1. Normative References 522 [I-D.ietf-ipv6-link-scoped-mcast] 523 Park, J., "A Method for Generating Link Scoped IPv6 524 Multicast Addresses", draft-ietf-ipv6-link-scoped-mcast-09 525 (work in progress), July 2005. 527 [I-D.ietf-ssm-arch] 528 Holbrook, H. and B. Cain, "Source-Specific Multicast for 529 IP", draft-ietf-ssm-arch-07 (work in progress), 530 October 2005. 532 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 533 RFC 2365, July 1998. 535 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 536 "IANA Guidelines for IPv4 Multicast Address Assignments", 537 BCP 51, RFC 3171, August 2001. 539 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 540 BCP 53, RFC 3180, September 2001. 542 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 543 Multicast Addresses", RFC 3306, August 2002. 545 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 546 Addresses", RFC 3307, August 2002. 548 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 549 (IPv6) Addressing Architecture", RFC 3513, April 2003. 551 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 552 Point (RP) Address in an IPv6 Multicast Address", 553 RFC 3956, November 2004. 555 8.2. Informative References 557 [I-D.ietf-malloc-aap] 558 Handley, M. and S. Hanna, "Multicast Address Allocation 559 Protocol (AAP)", June 2000. 561 [I-D.ietf-mboned-addrdisc-problems] 562 Savola, P., "Lightweight Multicast Address Discovery 563 Problem Space", draft-ietf-mboned-addrdisc-problems-00 564 (work in progress), March 2005. 566 [I-D.ietf-mboned-ipv4-uni-based-mcast] 567 Thaler, D., "Unicast-Prefix-based IPv4 Multicast 568 Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02 569 (work in progress), October 2004. 571 [I-D.ietf-mboned-rfc3171bis] 572 Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA 573 Guidelines for IPv4 Multicast Address Assignments", 574 draft-ietf-mboned-rfc3171bis-02 (work in progress), 575 March 2004. 577 [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] 578 Durand, J., "IPv6 multicast address assignment with 579 DHCPv6", 580 draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work 581 in progress), February 2005. 583 [I-D.jdurand-ipv6-multicast-ra] 584 Durand, J. and P. Savola, "Route Advertisement Option for 585 IPv6 Multicast Prefixes", 586 draft-jdurand-ipv6-multicast-ra-00 (work in progress), 587 February 2005. 589 [MBONED-IETF59] 590 "MBONED WG session at IETF59", 591 . 593 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 594 RFC 2131, March 1997. 596 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 597 "Service Location Protocol, Version 2", RFC 2608, 598 June 1999. 600 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 601 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 602 December 1999. 604 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 605 Allocation", RFC 2771, February 2000. 607 [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 608 Zone Announcement Protocol (MZAP)", RFC 2776, 609 February 2000. 611 [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet 612 Multicast Address Allocation Architecture", RFC 2908, 613 September 2000. 615 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 616 Kumar, S., and D. Thaler, "The Multicast Address-Set Claim 617 (MASC) Protocol", RFC 2909, September 2000. 619 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 620 Announcement Protocol", RFC 2974, October 2000. 622 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 623 June 2001. 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 [RITVANEN] 630 Ritvanen, K., "Multicast Routing and Addressing", HUT 631 Report, Seminar on Internetworking, May 2004, 632 . 634 Appendix A. Changes 636 (To be removed prior to publication as an RFC.) 638 A.1. Changes since -01 640 o Mention the mechanisms which haven't been so succesful: eGLOP and 641 MZAP. 643 o Remove the appendices on multicast address discovery (a separate 644 draft now) and IPv4 unicast-prefix-based multicast addressing. 646 o Add a note on scope-relative address space and the expansion 647 ambiguity. 649 o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt 651 o Minor editorial cleanups. 653 Author's Address 655 Pekka Savola 656 CSC - Scientific Computing Ltd. 657 Espoo 658 Finland 660 Email: psavola@funet.fi 662 Full Copyright Statement 664 Copyright (C) The Internet Society (2005). 666 This document is subject to the rights, licenses and restrictions 667 contained in BCP 78, and except as set forth therein, the authors 668 retain all their rights. 670 This document and the information contained herein are provided on an 671 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 672 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 673 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 674 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 675 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 676 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 678 Intellectual Property 680 The IETF takes no position regarding the validity or scope of any 681 Intellectual Property Rights or other rights that might be claimed to 682 pertain to the implementation or use of the technology described in 683 this document or the extent to which any license under such rights 684 might or might not be available; nor does it represent that it has 685 made any independent effort to identify any such rights. Information 686 on the procedures with respect to rights in RFC documents can be 687 found in BCP 78 and BCP 79. 689 Copies of IPR disclosures made to the IETF Secretariat and any 690 assurances of licenses to be made available, or the result of an 691 attempt made to obtain a general license or permission for the use of 692 such proprietary rights by implementers or users of this 693 specification can be obtained from the IETF on-line IPR repository at 694 http://www.ietf.org/ipr. 696 The IETF invites any interested party to bring to its attention any 697 copyrights, patents or patent applications, or other proprietary 698 rights that may cover technology that may be required to implement 699 this standard. Please address the information to the IETF at 700 ietf-ipr@ietf.org. 702 Acknowledgment 704 Funding for the RFC Editor function is currently provided by the 705 Internet Society.