idnits 2.17.1 draft-ietf-mboned-addrarch-01.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 713. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == 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. 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 (February 18, 2005) is 7007 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) == Outdated reference: A later version (-09) exists of draft-ietf-ipv6-link-scoped-mcast-08 == Outdated reference: A later version (-08) exists of draft-ietf-mboned-rfc3171bis-02 == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-06 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) == Outdated reference: A later version (-08) exists of draft-iab-dns-choices-00 == Outdated reference: A later version (-06) exists of draft-ietf-mboned-ipv4-uni-based-mcast-02 == Outdated reference: A later version (-02) exists of draft-ietf-mboned-ipv6-multicast-issues-01 == Outdated reference: A later version (-01) exists of draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 -- Obsolete informational reference (is this intentional?): RFC 2908 (Obsoleted by RFC 6308) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Savola 2 Internet-Draft CSC/FUNET 3 Obsoletes: 2908,2909 (if approved) February 18, 2005 4 Expires: August 19, 2005 6 Overview of the Internet Multicast Addressing Architecture 7 draft-ietf-mboned-addrarch-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 August 19, 2005. 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 11 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 74 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 76 A. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 B. Multicast Address Discovery . . . . . . . . . . . . . . . . . 15 78 Intellectual Property and Copyright Statements . . . . . . . . 16 80 1. Introduction 82 Good, up-to-date documentation of IP multicast is close to 83 non-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. The 99 applicability of SSM has been briefly discussed in 100 [I-D.ietf-mboned-ipv6-multicast-issues]. 102 This memo obsoletes RFC 2908 and RFC 2909 and re-classifies them 103 Historic. 105 1.1 Terminology: Allocation or Assignment 107 Almost all multicast documents and many other RFCs (such as DHCPv4 108 [RFC2131] and DHCPv6 [RFC3315]) have used the terms address 109 "allocation" and "assignment" interchangeably. However, the operator 110 and address management communities use these for two conceptually 111 different processes. 113 In unicast operations, address allocations refer to leasing a large 114 block of addresses from Internet Assigned Numbers Authority (IANA) to 115 a Regional Internet Registry (RIR), from RIR to a Local Internet 116 Registry (LIR) possibly through a National Internet Registry (NIR). 117 Address assignments, on the other hand, are the leases of smaller 118 address blocks or even single addresses to the end-user sites or 119 end-users themselves. 121 Therefore, in this memo, we will separate the two different 122 functions: "allocation" describes how larger blocks of addresses are 123 obtained by the network operators, and "assignment" describes how 124 applications, nodes or sets of nodes obtain a multicast address for 125 their use. 127 2. Multicast Address Allocation 129 Multicast address allocation, i.e., how a network operator might be 130 able to obtain a larger block of addresses, can be handled in a 131 number of ways as described below. 133 Note that these are all only pertinent to ASM -- SSM requires no 134 address block allocation because the group address has only local 135 significance (however, the address assignment inside the node is 136 still an issue discussed in Section 3.2). 138 2.1 Derived Allocation 140 Derived allocations take the unicast prefix or some other properties 141 of the network to determine unique multicast address allocations. 143 2.1.1 GLOP Allocation 145 GLOP address allocation [RFC3180] inserts the 16-bit public 146 Autonomous System (AS) number in the middle of the IPv4 multicast 147 prefix 233.0.0.0/8, so that each AS number can get a /24 worth of 148 multicast addresses. While this is sufficient for multicast testing 149 or small scale use, it might not be sufficient in all cases for 150 extensive multicast use. 152 A minor operational debugging issue with GLOP addresses is that the 153 connection between the AS and the prefix is not apparent from the 154 prefix, but has to be calculated (e.g., from [RFC3180], AS 5662 maps 155 to 233.22.30.0/24). A usage issue is that GLOP addresses are not 156 tied to any prefix but to routing domains, so they cannot be used or 157 calculated automatically. 159 2.1.2 Unicast-prefix -based Allocation 161 RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first 162 bits of an IPv6 unicast address in the prefix part of the IPv6 163 multicast address, leaving at least 32 bits of group-id space 164 available after the prefix mapping. 166 A similar mapping has been proposed for IPv4 167 [I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low 168 amount of addresses (e.g., 1 per an IPv4 /24 block). While there 169 exist large networks without an AS number of their own, this has not 170 been seen to add sufficient value compared to GLOP addressing. 172 The IPv6 unicast-prefix -based allocations are an extremely useful 173 way to allow each network operator, even each subnet, obtain 174 multicast addresses easily, through an easy computation. Further, as 175 the IPv6 multicast header also includes the scope value [RFC3513], 176 multicast groups of smaller scope can also be used with the same 177 mapping. 179 The IPv6 Embedded RP technique [RFC3956], used with Protocol 180 Independent Multicast - Sparse Mode (PIM-SM), further leverages the 181 unicast prefix based allocations, by embedding the unicast prefix and 182 interface identifier of the PIM-SM Rendezvous Point (RP) in the 183 prefix. This provides all the necessary information needed to the 184 routing systems to run the group in either inter- or intra-domain 185 operation. A difference to RFC 3306 is, however, that the hosts 186 cannot calculate their "multicast prefix" automatically, as the 187 prefix depends on the decisions of the operator setting up the RP but 188 rather requires an assignment method. 190 All the IPv6 unicast-prefix -based allocation techniques provide 191 sufficient amount of multicast address space for the network 192 operators. 194 2.2 Scope-relative Allocation 196 Administratively scoped multicast [RFC2365] is provided by two 197 different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in 198 the IPv6 multicast address prefix [RFC3513]. 200 As IPv6 scope-relative allocations can be handled with unicast-prefix 201 -based multicast addressing as described in Section 2.1.2, and there 202 is no need for separate scope-relative allocations, we'll just 203 discuss IPv4 in this section. 205 The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to 206 Local Scope (239.255.0.0/16) and Organization Local Scope 207 (239.192.0.0/14); other parts of the administrative scopes are either 208 reserved for expansion or undefined [RFC2365]. 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 -- it might be able to mitigate this issue if there was more 226 coordination inside the scope-relative allocation block. 228 2.3 Static IANA Allocation 230 In some rare cases, some organizations may have been able to obtain 231 static multicast address allocations directly from IANA. Typically 232 these have been meant as a block of static assignments to multicast 233 applications, as described in Section 3.4. In principle, IANA does 234 not allocate multicast address blocks to the operators but GLOP or 235 Unicast-prefix -based allocations should be used instead. 237 2.4 Dynamic Allocation 239 RFC 2908 [RFC2908] proposed three different layers of multicast 240 address allocation and assignment, where layers 3 (inter-domain 241 allocation) and layer 2 (intra-domain allocation) could be applicable 242 here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an 243 example of the former, and Multicast Address Allocation Protocol 244 (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest 245 and technical problems) is an example of the latter. 247 Both of the proposed allocation protocols were quite complex, and 248 have never been deployed or seriously implemented. 250 It can be concluded that there are no dynamic multicast address 251 allocation protocols, and other methods such as GLOP or 252 unicast-prefix -based addressing should be used instead. 254 3. Multicast Address Assignment 256 For multicast address assignment, i.e., how an application learns the 257 address it can use, or a node (or a set of nodes) learns an address 258 it could use for an application, has a number of options as described 259 below. 261 Any IPv6 address assignment method should be aware of the guidelines 262 for the assignment of the group-IDs for IPv6 multicast addresses 263 [RFC3307]. 265 3.1 Derived Assignment 267 There are significantly fewer options for derived address assignment 268 compared to derived allocation. Derived multicast assignment is only 269 being specified for IPv6 link-scoped multicast 270 [I-D.ietf-ipv6-link-scoped-mcast], where the EUI64 is embedded in the 271 multicast address, providing a node with unique multicast addresses 272 for link-local ASM communications. 274 3.2 SSM Assignment inside the Node 276 While the SSM multicast addresses have only local (to the node) 277 significance, there is still a minor issue on how to assign the 278 addresses between the applications running on the same node (or more 279 precisely, an IP address). 281 This assignment is not considered to be a problem because typically 282 the addresses for the applications are selected manually or 283 statically, but if done using an API, the API could check that the 284 addresses do not conflict prior to assigning one. 286 3.3 Manually Configured Assignment 288 With manually configured assignment, the network operator which has a 289 multicast address prefix assigns the multicast group addresses to the 290 requesting nodes using a manual process. 292 Typically the user or administrator which wants to use a multicast 293 address for particular application requests an address from the 294 network operator using phone, email, or similar means, and the 295 network operator provides the user with a multicast address. Then 296 the user/administrator of the node or application manually configures 297 the application to use the assigned multicast address. 299 This is a relatively simple process; it has been sufficient for 300 certain applications which require manual configuration in any case, 301 or which cannot or do not want to justify a static IANA assignment. 302 The manual assignment works when the number of participants in a 303 group is small, as each participant has to be manually configured. 305 This is the most commonly used technique when the multicast 306 application does not have a static IANA assignment. 308 3.4 Static IANA Assignment 310 In contrast to manually configured assignment, as described above, 311 static IANA assignment refers to getting a globally unique assignment 312 for the particular application directly from IANA. Guidelines for 313 IANA are described in [I-D.ietf-mboned-rfc3171bis]. 315 This is seen as lucrative because it's the simplest approach for 316 application developers because they can then hard-code the multicast 317 address, requiring no lease of the usable multicast address, and 318 likewise the client applications do not need to perform any kind of 319 service discovery (but depending on hard-coded addresses). However, 320 this is a bad approach architecturally, as we should focus on 321 enhancing and deploying service discovery and address assignment (as 322 needed) instead of encouraging a "land-grab" of multicast addresses. 324 In summary, there are applications which have obtained a static IANA 325 assignment, some of which are really needed, and some of which 326 probably should not have been granted. 328 3.5 Dynamic Assignments 330 The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from 331 Multicast Address Allocation Servers (MAAS) to applications and 332 nodes, with Multicast Address Dynamic Client Allocation Protocol 333 (MADCAP) [RFC2730] as examples. Since then, there has been a 334 proposal for DHCPv6 assignment 335 [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]. 337 Based on a multicast prefix, it would be rather straightforward to 338 deploy a dynamic assignment protocol which would lease group 339 addresses to the applications wishing to use multicast. For example, 340 only few have implemented MADCAP, and it's not significantly 341 deployed. Moreover, it is not clear how widely for example the APIs 342 for communication between the multicast application and the MADCAP 343 client operating at the host have been implemented [RFC2771]. 345 An entirely different approach is Session Announcement Protocol (SAP) 346 [RFC2974]. In addition to advertising global multicast sessions, the 347 protocol also has associated ranges of addresses for both IPv4 and 348 IPv6 which can be used by SAP-aware applications to create new groups 349 and new group addresses. It is a rather tedious process to create a 350 session (and obtain an address) this way which is why it isn't done 351 all that often. (Note that the IPv6 SAP address is unroutable in the 352 inter-domain multicast.) 354 A conclusion about dynamic assignment protocols is that: 356 1. multicast is not significantly attractive in the first place, 358 2. very many applications have a static IANA assignment and thus 359 require no dynamic or manual assignment, 361 3. those that cannot be easily satisfied with IANA or manual 362 assignment (i.e., where dynamic assignment would be desirable) 363 are rather marginal, or 365 4. that there are other gaps why dynamic assignments are not seen as 366 a useful approach (for example, issues related to service 367 discovery/rendezvous). 369 In consequence, more work on rendezvous/service discovery will be 370 needed to make dynamic assignment more useful. 372 4. Summary and Future Directions 374 This section summarizes the mechanisms and analysis discussed in this 375 memo, and presents some potential future directions. 377 4.1 Prefix Allocation 379 Summary of prefix allocation methods for ASM is in Figure 1. 381 +-------+--------------------------------+--------+--------+ 382 | Sect. | Prefix allocation method | IPv4 | IPv6 | 383 +-------+--------------------------------+--------+--------+ 384 | 2.1.1 | Derived: GLOP | Yes | NoNeed*| 385 | 2.1.2 | Derived: Unicast-prefix -based |No -yet | Yes | 386 | 2.2 | Separate Scope-relative | Yes | NoNeed*| 387 | 2.3 | Static IANA allocation | No | No | 388 | 2.4 | Dynamic allocation protocols | No | No | 389 +-------+--------------------------------+--------+--------+ 390 * = the need satisfied by IPv6 unicast-prefix -based allocation. 392 Figure 1 394 o Only ASM is affected by the assignment/allocation issues (however, 395 both ASM and SSM have roughly the same address discovery issues). 397 o GLOP allocations seem to provide a sufficient IPv4 multicast 398 allocation mechanism for now, but could be extended in future. 399 Scope-relative allocations provide the opportunity for internal 400 IPv4 allocations. 402 o Unicast-prefix -based addresses and the derivatives provide good 403 allocation strategy with IPv6, also for scoped multicast 404 addresses. 406 o Dynamic allocations are a too complex and unnecessary mechanism. 408 o Static IANA allocations are an architecturally unacceptable 409 approach. 411 4.2 Address Assignment 413 Summary of address assignment methods is in Figure 2. 415 +-------+--------------------------------+----------+----------+ 416 | Sect. | Address assignment method | IPv4 | IPv6 | 417 +-------+--------------------------------+----------+----------+ 418 | 3.1 | Derived: link-scope addresses | No | Yes | 419 | 3.2 | SSM (inside the node) | Yes | Yes | 420 | 3.3 | Manual assignment | Yes | Yes | 421 | 3.4 | Static IANA assignment |LastResort|LastResort| 422 | 3.5 | Dynamic assignment protocols | Yes | Yes | 423 +-------+--------------------------------+----------+----------+ 425 Figure 2 427 o Manually configured assignment is what's typically done today, and 428 works to a sufficient degree in smaller scale. 430 o Static IANA assignment has been done extensively in the past, but 431 it needs to be tightened down to prevent problems caused by 432 "land-grabbing". 434 o Dynamic assignment, e.g., using MADCAP have been implemented, but 435 there is no wide deployment, so a solution is there -- but either 436 there are other gaps in the multicast architecture or there is no 437 need for it in the first place, when manual configuration is 438 possible, and static IANA assignments are still there. 439 Assignments using SAP also exist but are not common; global SAP 440 assignment is unfeasible with IPv6. 442 o Derived assignments are only applicable in a fringe case of 443 link-scoped multicast. 445 4.3 Future Actions 447 o Multicast address discovery/"rendezvous" needs to be analyzed at 448 more length, and an adequate solution provided; the result also 449 needs to be written down to be shown to the IANA static assignment 450 requestors. See [I-D.savola-mboned-address-discovery-problems] 451 and Appendix B for more. 453 o IPv6 multicast DAD and/or multicast prefix communication 454 mechanisms should be analyzed (e.g., 455 [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, 456 and specify if yes. 458 o The IETF should consider whether to specify more ranges of the 459 IPv4 scope-relative address space for static allocation for 460 applications which should not be routed over the Internet (such as 461 backup software, etc. -- so that these wouldn't need to use 462 global addresses which should never leak in any case). 464 o The IETF should seriously consider its static IANA allocations 465 policy, e.g., "locking it down" to a stricter policy (like "IETF 466 Consensus") and looking at developing the discovery/rendezvous 467 functions, if necessary. 469 5. Acknowledgements 471 Tutoring a couple multicast-related papers, the latest by Kaarle 472 Ritvanen [RITVANEN] convinced the author that the up-to-date 473 multicast address assignment/allocation documentation is necessary. 475 Multicast address allocations/assignments were discussed at the 476 MBONED WG session at IETF59 [MBONED-IETF59]. 478 Dave Thaler, James Lingard, and Beau Williamson provided useful 479 feedback for the preliminary version of this memo. Myung-Ki Shin and 480 Jerome Durand also suggested improvements. 482 6. IANA Considerations 484 This memo includes no request to IANA, but as the allocation and 485 assignment of multicast addresses are related to IANA functions, it 486 wouldn't hurt if the IANA reviewed this entire memo. 488 IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still 489 apply to the administratively scoped prefixes. 491 (RFC-editor: please remove this section at publication.) 493 7. Security Considerations 495 This memo only describes different approaches to allocating and 496 assigning multicast addresses, and this has no security 497 considerations; the security analysis of the mentioned protocols is 498 out of scope of this memo. 500 Obviously, especially the dynamic assignment protocols are inherently 501 vulnerable to resource exhaustion attacks, as discussed e.g., in 502 [RFC2730]. 504 8. References 506 8.1 Normative References 508 [I-D.ietf-ipv6-link-scoped-mcast] 509 Park, J., "Link Scoped IPv6 Multicast Addresses", 510 Internet-Draft draft-ietf-ipv6-link-scoped-mcast-08, 511 December 2004. 513 [I-D.ietf-mboned-rfc3171bis] 514 Albanna, Z., Almeroth, K., Cotton, M. and D. Meyer, "IANA 515 Guidelines for IPv4 Multicast Address Assignments", 516 Internet-Draft draft-ietf-mboned-rfc3171bis-02, March 517 2004. 519 [I-D.ietf-ssm-arch] 520 Holbrook, H. and B. Cain, "Source-Specific Multicast for 521 IP", Internet-Draft draft-ietf-ssm-arch-06, September 522 2004. 524 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 525 RFC 2365, July 1998. 527 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 528 BCP 53, RFC 3180, September 2001. 530 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 531 Multicast Addresses", RFC 3306, August 2002. 533 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 534 Addresses", RFC 3307, August 2002. 536 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 537 (IPv6) Addressing Architecture", RFC 3513, April 2003. 539 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 540 Point (RP) Address in an IPv6 Multicast Address", 541 RFC 3956, November 2004. 543 8.2 Informative References 545 [I-D.iab-dns-choices] 546 Faltstrom, P. and R. Austein, "Design Choices When 547 Expanding DNS", Internet-Draft draft-iab-dns-choices-00, 548 October 2004. 550 [I-D.ietf-malloc-aap] 551 Handley, M. and S. Hanna, "Multicast Address Allocation 552 Protocol (AAP)", June 2000. 554 [I-D.ietf-mboned-ipv4-uni-based-mcast] 555 Thaler, D., "Unicast-Prefix-based IPv4 Multicast 556 Addresses", 557 Internet-Draft draft-ietf-mboned-ipv4-uni-based-mcast-02, 558 October 2004. 560 [I-D.ietf-mboned-ipv6-multicast-issues] 561 Savola, P., "IPv6 Multicast Deployment Issues", 562 Internet-Draft draft-ietf-mboned-ipv6-multicast-issues-01, 563 September 2004. 565 [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] 566 Durand, J., "IPv6 multicast address assignment with 567 DHCPv6", 568 Internet-Draft draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 569 , June 2004. 571 [I-D.jdurand-ipv6-multicast-ra] 572 Durand, J. and P. Savola, "Route Advertisement Option for 573 IPv6 Multicast Prefixes", 574 Internet-Draft draft-jdurand-ipv6-multicast-ra-00, 575 February 2005. 577 [I-D.palet-v6ops-tun-auto-disc] 578 Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point 579 Discovery Mechanisms", 580 Internet-Draft draft-palet-v6ops-tun-auto-disc-03, January 581 2005. 583 [I-D.savola-mboned-address-discovery-problems] 584 Savola, P., "Lightweight Multicast Address Discovery 585 Problem Space", 586 Internet-Draft draft-savola-mboned-address-discovery-problems-00 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, June 598 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 [RFC2908] Thaler, D., Handley, M. and D. Estrin, "The Internet 608 Multicast Address Allocation Architecture", RFC 2908, 609 September 2000. 611 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 612 Kumar, S. and D. Thaler, "The Multicast Address-Set Claim 613 (MASC) Protocol", RFC 2909, September 2000. 615 [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session 616 Announcement Protocol", RFC 2974, October 2000. 618 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 619 M. Carney, "Dynamic Host Configuration Protocol for IPv6 620 (DHCPv6)", RFC 3315, July 2003. 622 [RITVANEN] 623 Ritvanen, K., "Multicast Routing and Addressing", HUT 624 Report, Seminar on Internetworking, May 2004, 625 . 627 Author's Address 629 Pekka Savola 630 CSC - Scientific Computing Ltd. 631 Espoo 632 Finland 634 Email: psavola@funet.fi 636 Appendix A. Open Issues 638 (This section will be removed or merged with the rest before 639 publication..) 641 o Is the case for IPv4 Unicast-Prefix Base Multicast addressing 642 sufficiently strong, or could those organizations just get an AS 643 number themselves if they really wanted to do multicast? 645 Appendix B. Multicast Address Discovery 647 [[ NOTE IN DRAFT: the intent of this section has been mostly 648 superceded by [I-D.savola-mboned-address-discovery-problems] and 649 therefore it is put in the appendix, with pending removal in the 650 future. 652 As was noted in Section 3, multicast address discovery (i.e., service 653 discovery or "rendezvous") is a problem with multicast address 654 assignment. In particular, an acceptable mechanism (mechanisms such 655 as Service Location Protocol (SLP) [RFC2608] seem to have been 656 considered too complex) seems to be missing which the hosts wishing 657 to participate in a group could use to find the address of that group 658 [MBONED-IETF59]. 660 It is worth noting that as long as not deploying an address 661 assignment and service discovery protocols/mechanisms means that one 662 can get a static address assignment from IANA, there is little 663 interest from the application developers to actually do anything 664 except try to get the assignment from IANA. Conclusion: if we want 665 to use non-IANA processes, the assignments must be either forbidden 666 completely, or made sufficiently difficult that it's easier for the 667 application developers to take another route if a feasible mechanism 668 is available. 670 There are two issues in the service discovery: 672 1. The session initiator being able to publish the session somehow, 673 and 675 2. The session participants finding out about the session (rather 676 than creating their own). 678 When manually configured or static IANA assignments are used, 1) 679 should be relatively straightforward (if something needs to be 680 manually configured or statically assigned, putting it e.g., in DNS 681 should not be a problem). However, this is still more complex for 682 dynamic or derived assignments because it implies that the host or 683 the application has the right to make that publication on its own, 684 rather than through a manual process by an administrator. 686 2) is always a challenge, but could leverage for example DNS (e.g., 687 by relying on using SRV records with the DNS search path, as 688 described in [I-D.iab-dns-choices] and 689 [I-D.palet-v6ops-tun-auto-disc]). 691 Intellectual Property Statement 693 The IETF takes no position regarding the validity or scope of any 694 Intellectual Property Rights or other rights that might be claimed to 695 pertain to the implementation or use of the technology described in 696 this document or the extent to which any license under such rights 697 might or might not be available; nor does it represent that it has 698 made any independent effort to identify any such rights. Information 699 on the procedures with respect to rights in RFC documents can be 700 found in BCP 78 and BCP 79. 702 Copies of IPR disclosures made to the IETF Secretariat and any 703 assurances of licenses to be made available, or the result of an 704 attempt made to obtain a general license or permission for the use of 705 such proprietary rights by implementers or users of this 706 specification can be obtained from the IETF on-line IPR repository at 707 http://www.ietf.org/ipr. 709 The IETF invites any interested party to bring to its attention any 710 copyrights, patents or patent applications, or other proprietary 711 rights that may cover technology that may be required to implement 712 this standard. Please address the information to the IETF at 713 ietf-ipr@ietf.org. 715 Disclaimer of Validity 717 This document and the information contained herein are provided on an 718 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 719 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 720 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 721 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 722 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 723 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 725 Copyright Statement 727 Copyright (C) The Internet Society (2005). This document is subject 728 to the rights, licenses and restrictions contained in BCP 78, and 729 except as set forth therein, the authors retain all their rights. 731 Acknowledgment 733 Funding for the RFC Editor function is currently provided by the 734 Internet Society.