idnits 2.17.1 draft-ietf-mboned-addrarch-02.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 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 685. ** 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 (August 8, 2005) is 6835 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 523, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mboned-ipv4-uni-based-mcast' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC2608' is defined on line 597, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-06 ** Obsolete normative reference: RFC 3171 (Obsoleted by RFC 5771) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) == 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 (~~), 11 warnings (==), 13 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 August 8, 2005 5 approved) 6 Expires: February 9, 2006 8 Overview of the Internet Multicast Addressing Architecture 9 draft-ietf-mboned-addrarch-02.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 February 9, 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 . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 10 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 76 A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 A.1 Changes since -01 . . . . . . . . . . . . . . . . . . . . 14 78 Intellectual Property and Copyright Statements . . . . . . . . 16 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 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, but has to be calculated (e.g., from [RFC3180], AS 5662 maps 153 to 233.22.30.0/24). A usage issue is that GLOP addresses are not 154 tied to any prefix but to routing domains, so they cannot be used or 155 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 171 way to allow each network operator, even each subnet, obtain 172 multicast addresses easily, through an easy computation. Further, as 173 the IPv6 multicast header also includes the scope value [RFC3513], 174 multicast groups of smaller scope can also be used with the same 175 mapping. 177 The IPv6 Embedded RP technique [RFC3956], used with Protocol 178 Independent Multicast - Sparse Mode (PIM-SM), further leverages the 179 unicast prefix based allocations, by embedding the unicast prefix and 180 interface identifier of the PIM-SM Rendezvous Point (RP) in the 181 prefix. This provides all the necessary information needed to the 182 routing systems to run the group in either inter- or intra-domain 183 operation. A difference to RFC 3306 is, however, that the hosts 184 cannot calculate their "multicast prefix" automatically, as the 185 prefix depends on the decisions of the operator setting up the RP but 186 rather requires an assignment method. 188 All the IPv6 unicast-prefix -based allocation techniques provide 189 sufficient amount of multicast address space for the network 190 operators. 192 2.2 Scope-relative Allocation 194 Administratively scoped multicast [RFC2365] is provided by two 195 different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in 196 the IPv6 multicast address prefix [RFC3513]. 198 As IPv6 scope-relative allocations can be handled with unicast-prefix 199 -based multicast addressing as described in Section 2.1.2, and there 200 is no need for separate scope-relative allocations, we'll just 201 discuss IPv4 in this section. 203 The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to 204 Local Scope (239.255.0.0/16) and Organization Local Scope 205 (239.192.0.0/14); other parts of the administrative scopes are either 206 reserved for expansion or undefined [RFC2365]. However, RFC 2365 is 207 ambiguous as to whether it's the enterprises or the IETF who are 208 allowed to expand the space. 210 Topologies which act under a single administration can easily use the 211 scoped multicast addresses for their internal groups. Groups which 212 need to be shared between multiple routing domains (but not 213 propagated through Internet) are more problematic and typically need 214 an assignment of a global multicast address because their scope is 215 undefined. 217 There is a large number of multicast applications (such as "Norton 218 Ghost") which are restricted either to a link or a site, but it is 219 extremely undesirable to propagate them further (either to the rest 220 of the site, or beyond the site). Typically many such applications 221 have been given a static IANA address assignment; this makes it 222 challenging to implement proper propagation limiting -- which could 223 be easier if such applications could have been assigned specific 224 scope-relative addresses instead. This is an area of further future 225 work. 227 There has also been work on protocol to automatically discover 228 multicast scope zones [RFC2776], but it has never been seriously 229 implemented or deployed. 231 2.3 Static IANA Allocation 233 In some rare cases, some organizations may have been able to obtain 234 static multicast address allocations (of up to 256 addresses) 235 directly from IANA. Typically these have been meant as a block of 236 static assignments to multicast applications, as described in 237 Section 3.4. In principle, IANA does not allocate multicast address 238 blocks to the operators but GLOP or Unicast-prefix -based allocations 239 should be used instead. 241 2.4 Dynamic Allocation 243 RFC 2908 [RFC2908] proposed three different layers of multicast 244 address allocation and assignment, where layers 3 (inter-domain 245 allocation) and layer 2 (intra-domain allocation) could be applicable 246 here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an 247 example of the former, and Multicast Address Allocation Protocol 248 (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest 249 and technical problems) is an example of the latter. 251 Both of the proposed allocation protocols were quite complex, and 252 have never been deployed or seriously implemented. 254 It can be concluded that there are no dynamic multicast address 255 allocation protocols, and other methods such as GLOP or unicast- 256 prefix -based addressing should be used instead. 258 3. Multicast Address Assignment 260 For multicast address assignment, i.e., how an application learns the 261 address it can use, or a node (or a set of nodes) learns an address 262 it could use for an application, has a number of options as described 263 below. 265 Any IPv6 address assignment method should be aware of the guidelines 266 for the assignment of the group-IDs for IPv6 multicast addresses 267 [RFC3307]. 269 3.1 Derived Assignment 271 There are significantly fewer options for derived address assignment 272 compared to derived allocation. Derived multicast assignment has 273 only been specified for IPv6 link-scoped multicast [I-D.ietf-ipv6- 274 link-scoped-mcast], where the EUI64 is embedded in the multicast 275 address, providing a node with unique multicast addresses for link- 276 local ASM communications. 278 3.2 SSM Assignment inside the Node 280 While the SSM multicast addresses have only local (to the node) 281 significance, there is still a minor issue on how to assign the 282 addresses between the applications running on the same node (or more 283 precisely, an IP address). 285 This assignment is not considered to be a problem because typically 286 the addresses for the applications are selected manually or 287 statically, but if done using an Application Programming Interface 288 (API), the API could check that the addresses do not conflict prior 289 to assigning one. 291 3.3 Manually Configured Assignment 293 With manually configured assignment, the network operator who has a 294 multicast address prefix assigns the multicast group addresses to the 295 requesting nodes using a manual process. 297 Typically the user or administrator which wants to use a multicast 298 address for particular application requests an address from the 299 network operator using phone, email, or similar means, and the 300 network operator provides the user with a multicast address. Then 301 the user/administrator of the node or application manually configures 302 the application to use the assigned multicast address. 304 This is a relatively simple process; it has been sufficient for 305 certain applications which require manual configuration in any case, 306 or which cannot or do not want to justify a static IANA assignment. 307 The manual assignment works when the number of participants in a 308 group is small, as each participant has to be manually configured. 310 This is the most commonly used technique when the multicast 311 application does not have a static IANA assignment. 313 3.4 Static IANA Assignment 315 In contrast to manually configured assignment, as described above, 316 static IANA assignment refers to getting a globally unique assignment 317 for the particular application directly from IANA. Guidelines for 318 IANA are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. 320 This is seen as lucrative because it's the simplest approach for 321 application developers because they can then hard-code the multicast 322 address. Hard-coding requires no lease of the usable multicast 323 address, and likewise the client applications do not need to perform 324 any kind of service discovery (but depending on hard-coded 325 addresses). However, this is a bad approach architecturally, as we 326 should focus on enhancing and deploying service discovery and address 327 assignment (as needed) instead of encouraging a "land-grab" of 328 multicast addresses. 330 [RFC3138] describes how to handle those GLOP assignments (called 331 "eGLOP") which use the private-use AS number space (233.252.0.0/14). 332 It was envisioned that IANA would delegate the responsibility of 333 these to RIRs, which would assign or allocate addresses as best 334 seemed fit. However, this was never carried out as IANA did not make 335 these allocations to RIRs due to procedural reasons. 337 In summary, there are applications which have obtained a static IANA 338 assignment, some of which are really needed, and some of which 339 probably should not have been granted. 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 an architecturally unacceptable 422 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., using MADCAP have been implemented, but 448 there is no wide deployment, so a solution is there. However, 449 either there are other gaps in the multicast architecture or there 450 is no sufficient demand for it in the first place when manual and 451 static IANA assignments are available. Assignments using SAP also 452 exist but are not common; global SAP assignment is unfeasible with 453 IPv6. 455 o Derived assignments are only applicable in a fringe case of link- 456 scoped multicast. 458 4.3 Future Actions 460 o Multicast address discovery/"rendezvous" needs to be analyzed at 461 more length, and an adequate solution provided; the result also 462 needs to be written down to be shown to the IANA static assignment 463 requestors. See [I-D.ietf-mboned-addrdisc-problems] for more. 465 o IPv6 multicast DAD and/or multicast prefix communication 466 mechanisms should be analyzed (e.g., 467 [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, 468 and specify if yes. 470 o The IETF should consider whether to specify more ranges of the 471 IPv4 scope-relative address space for static allocation for 472 applications which should not be routed over the Internet (such as 473 backup software, etc. -- so that these wouldn't need to use global 474 addresses which should never leak in any case). 476 o The IETF should seriously consider its static IANA allocations 477 policy, e.g., "locking it down" to a stricter policy (like "IETF 478 Consensus") and looking at developing the discovery/rendezvous 479 functions, if necessary. 481 5. Acknowledgements 483 Tutoring a couple multicast-related papers, the latest by Kaarle 484 Ritvanen [RITVANEN] convinced the author that the up-to-date 485 multicast address assignment/allocation documentation is necessary. 487 Multicast address allocations/assignments were discussed at the 488 MBONED WG session at IETF59 [MBONED-IETF59]. 490 Dave Thaler, James Lingard, and Beau Williamson provided useful 491 feedback for the preliminary version of this memo. Myung-Ki Shin and 492 Jerome Durand also suggested improvements. 494 6. IANA Considerations 496 This memo includes no request to IANA, but as the allocation and 497 assignment of multicast addresses are related to IANA functions, it 498 wouldn't hurt if the IANA reviewed this entire memo. 500 IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still 501 apply to the administratively scoped prefixes. 503 IANA may be interested in reviewing the accuracy of the statement on 504 eGLOP address assignments in Section 3.4. 506 (RFC-editor: please remove this section at publication.) 508 7. Security Considerations 510 This memo only describes different approaches to allocating and 511 assigning multicast addresses, and this has no security 512 considerations; the security analysis of the mentioned protocols is 513 out of scope of this memo. 515 Obviously, especially the dynamic assignment protocols are inherently 516 vulnerable to resource exhaustion attacks, as discussed e.g., in 517 [RFC2730]. 519 8. References 521 8.1 Normative References 523 [I-D.ietf-ipv6-link-scoped-mcast] 524 Park, J., "A Method for Generating Link Scoped IPv6 525 Multicast Addresses", draft-ietf-ipv6-link-scoped-mcast-09 526 (work in progress), July 2005. 528 [I-D.ietf-ssm-arch] 529 Holbrook, H. and B. Cain, "Source-Specific Multicast for 530 IP", draft-ietf-ssm-arch-06 (work in progress), 531 September 2004. 533 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 534 RFC 2365, July 1998. 536 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 537 "IANA Guidelines for IPv4 Multicast Address Assignments", 538 BCP 51, RFC 3171, August 2001. 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 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 550 (IPv6) Addressing Architecture", RFC 3513, April 2003. 552 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 553 Point (RP) Address in an IPv6 Multicast Address", 554 RFC 3956, November 2004. 556 8.2 Informative References 558 [I-D.ietf-malloc-aap] 559 Handley, M. and S. Hanna, "Multicast Address Allocation 560 Protocol (AAP)", June 2000. 562 [I-D.ietf-mboned-addrdisc-problems] 563 Savola, P., "Lightweight Multicast Address Discovery 564 Problem Space", draft-ietf-mboned-addrdisc-problems-00 565 (work in progress), March 2005. 567 [I-D.ietf-mboned-ipv4-uni-based-mcast] 568 Thaler, D., "Unicast-Prefix-based IPv4 Multicast 569 Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02 570 (work in progress), October 2004. 572 [I-D.ietf-mboned-rfc3171bis] 573 Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA 574 Guidelines for IPv4 Multicast Address Assignments", 575 draft-ietf-mboned-rfc3171bis-02 (work in progress), 576 March 2004. 578 [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] 579 Durand, J., "IPv6 multicast address assignment with 580 DHCPv6", 581 draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work 582 in progress), February 2005. 584 [I-D.jdurand-ipv6-multicast-ra] 585 Durand, J. and P. Savola, "Route Advertisement Option for 586 IPv6 Multicast Prefixes", 587 draft-jdurand-ipv6-multicast-ra-00 (work in progress), 588 February 2005. 590 [MBONED-IETF59] 591 "MBONED WG session at IETF59", 592 . 594 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 595 RFC 2131, March 1997. 597 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 598 "Service Location Protocol, Version 2", RFC 2608, 599 June 1999. 601 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 602 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 603 December 1999. 605 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 606 Allocation", RFC 2771, February 2000. 608 [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 609 Zone Announcement Protocol (MZAP)", RFC 2776, 610 February 2000. 612 [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet 613 Multicast Address Allocation Architecture", RFC 2908, 614 September 2000. 616 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 617 Kumar, S., and D. Thaler, "The Multicast Address-Set Claim 618 (MASC) Protocol", RFC 2909, September 2000. 620 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 621 Announcement Protocol", RFC 2974, October 2000. 623 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 624 June 2001. 626 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 627 and M. Carney, "Dynamic Host Configuration Protocol for 628 IPv6 (DHCPv6)", RFC 3315, July 2003. 630 [RITVANEN] 631 Ritvanen, K., "Multicast Routing and Addressing", HUT 632 Report, Seminar on Internetworking, May 2004, 633 . 635 Author's Address 637 Pekka Savola 638 CSC - Scientific Computing Ltd. 639 Espoo 640 Finland 642 Email: psavola@funet.fi 644 Appendix A. Changes 646 (To be removed prior to publication as an RFC.) 648 A.1 Changes since -01 650 o Mention the mechanisms which haven't been so succesful: eGLOP and 651 MZAP. 653 o Remove the appendices on multicast address discovery (a separate 654 draft now) and IPv4 unicast-prefix based multicast addressing. 656 o Add a note on scope-relative address space and the expansion 657 ambiguity. 659 o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt 661 o Minor editorial cleanups. 663 Intellectual Property Statement 665 The IETF takes no position regarding the validity or scope of any 666 Intellectual Property Rights or other rights that might be claimed to 667 pertain to the implementation or use of the technology described in 668 this document or the extent to which any license under such rights 669 might or might not be available; nor does it represent that it has 670 made any independent effort to identify any such rights. Information 671 on the procedures with respect to rights in RFC documents can be 672 found in BCP 78 and BCP 79. 674 Copies of IPR disclosures made to the IETF Secretariat and any 675 assurances of licenses to be made available, or the result of an 676 attempt made to obtain a general license or permission for the use of 677 such proprietary rights by implementers or users of this 678 specification can be obtained from the IETF on-line IPR repository at 679 http://www.ietf.org/ipr. 681 The IETF invites any interested party to bring to its attention any 682 copyrights, patents or patent applications, or other proprietary 683 rights that may cover technology that may be required to implement 684 this standard. Please address the information to the IETF at 685 ietf-ipr@ietf.org. 687 Disclaimer of Validity 689 This document and the information contained herein are provided on an 690 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 691 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 692 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 693 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 694 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 695 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 697 Copyright Statement 699 Copyright (C) The Internet Society (2005). This document is subject 700 to the rights, licenses and restrictions contained in BCP 78, and 701 except as set forth therein, the authors retain all their rights. 703 Acknowledgment 705 Funding for the RFC Editor function is currently provided by the 706 Internet Society.