idnits 2.17.1 draft-ietf-mboned-addrarch-05.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 767. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- The draft header indicates that this document obsoletes RFC2908, but the abstract doesn't seem to mention this, which it should. -- 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 16, 2006) is 6401 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2608' is defined on line 635, 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) == Outdated reference: A later version (-13) exists of draft-ietf-idr-as4bytes-12 == 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 (~~), 6 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 October 16, 2006 5 (if approved) 6 Intended status: Best Current 7 Practice 8 Expires: April 19, 2007 10 Overview of the Internet Multicast Addressing Architecture 11 draft-ietf-mboned-addrarch-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 19, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The lack of up-to-date documentation on IP multicast address 45 allocation and assignment procedures has caused a great deal of 46 confusion. To clarify the situation, this memo describes the 47 allocation and assignment techniques and mechanisms currently (as of 48 this writing) in use. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3 54 2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 55 2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 56 2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 57 2.1.2. Unicast-prefix -based Allocation . . . . . . . . . . . 4 58 2.2. Administratively Scoped Allocation . . . . . . . . . . . . 5 59 2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 60 2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 61 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6 62 3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7 63 3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7 64 3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7 65 3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 8 66 3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8 67 3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8 68 3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 9 69 4. Summary and Future Directions . . . . . . . . . . . . . . . . 10 70 4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10 71 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 72 4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 80 A.1. Changes between -04 and -05 . . . . . . . . . . . . . . . 15 81 A.2. Changes between -03 and -04 . . . . . . . . . . . . . . . 16 82 A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 16 83 A.4. Changes between -01 and -02 . . . . . . . . . . . . . . . 16 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 Intellectual Property and Copyright Statements . . . . . . . . . . 17 87 1. Introduction 89 Good, up-to-date documentation of IP multicast is close to non- 90 existent. Particularly, this is an issue with multicast address 91 allocations (to networks and sites) and assignments (to hosts and 92 applications). This problem is stressed by the fact that there 93 exists confusing or misleading documentation on the subject 94 [RFC2908]. The consequence is that those who wish to learn about IP 95 multicast and how the addressing works do not get a clear view of the 96 current situation. 98 The aim of this document is to provide a brief overview of multicast 99 addressing and allocation techniques. The term 'addressing 100 architecture' refers to the set of addressing mechanisms and methods 101 in an informal manner. 103 It is important to note that Source-specific Multicast (SSM) 104 [RFC4607] does not have these addressing problems because SSM group 105 addresses have only local significance; hence, this document focuses 106 on the Any Source Multicast (ASM) model. 108 This memo obsoletes RFCs 2776, 2908, and 2909 and re-classifies them 109 Historic. 111 1.1. Terminology: Allocation or Assignment 113 Almost all multicast documents and many other RFCs (such as DHCPv4 114 [RFC2131] and DHCPv6 [RFC3315]) have used the terms address 115 "allocation" and "assignment" interchangeably. However, the operator 116 and address management communities use these terms for two 117 conceptually different processes. 119 In unicast operations, address allocations refer to leasing a large 120 block of addresses from Internet Assigned Numbers Authority (IANA) to 121 a Regional Internet Registry (RIR) or from RIR to a Local Internet 122 Registry (LIR) possibly through a National Internet Registry (NIR). 123 Address assignments, on the other hand, are the leases of smaller 124 address blocks or even single addresses to the end-user sites or end- 125 users themselves. 127 Therefore, in this memo, we will separate the two different 128 functions: "allocation" describes how larger blocks of addresses are 129 obtained by the network operators, and "assignment" describes how 130 applications, nodes or sets of nodes obtain a multicast address for 131 their use. 133 2. Multicast Address Allocation 135 Multicast address allocation, i.e., how a network operator might be 136 able to obtain a larger block of addresses, can be handled in a 137 number of ways as described below. 139 Note that these are all only pertinent to ASM -- SSM requires no 140 address block allocation because the group address has only local 141 significance (however, we discuss the address assignment inside the 142 node in Section 3.2). 144 2.1. Derived Allocation 146 Derived allocations take the unicast prefix or some other properties 147 of the network (e.g., an autonomous system (AS) number) to determine 148 unique multicast address allocations. 150 2.1.1. GLOP Allocation 152 GLOP address allocation [RFC3180] inserts the 16-bit public AS number 153 in the middle of the IPv4 multicast prefix 233.0.0.0/8, so that each 154 AS number can get a /24 worth of multicast addresses. While this is 155 sufficient for multicast testing or small scale use, it might not be 156 sufficient in all cases for extensive multicast use. 158 A minor operational debugging issue with GLOP addresses is that the 159 connection between the AS and the prefix is not apparent from the 160 prefix when the AS number is greater than 255, but has to be 161 calculated (e.g., from [RFC3180], AS 5662 maps to 233.22.30.0/24). A 162 usage issue is that GLOP addresses are not tied to any prefix but to 163 routing domains, so they cannot be used or calculated automatically. 165 GLOP allocation algorithm has not been defined for IPv6 multicast 166 because the unicast-prefix -based allocation (described below) 167 addresses the same need in a simpler fashion. GLOP hasn't been (and 168 likely never will be) specified for 4-byte AS numbers 169 [I-D.ietf-idr-as4bytes]. 171 2.1.2. Unicast-prefix -based Allocation 173 RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 high- 174 order bits of an IPv6 unicast address in the prefix part of the IPv6 175 multicast address, leaving at least 32 bits of group-id space 176 available after the prefix mapping. 178 A similar mapping has been proposed for IPv4 179 [I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low 180 amount of addresses (e.g., 1 per an IPv4 /24 block). Although large 181 networks without an AS number do exist, this technique has not been 182 seen to add value compared to GLOP addressing. 184 The IPv6 unicast-prefix-based allocations are an extremely useful way 185 to allow each network operator, even each subnet, to obtain multicast 186 addresses easily, through an easy computation. Further, as the IPv6 187 multicast header also includes the scope value [RFC3513], multicast 188 groups of smaller scope can also be used with the same mapping. 190 The IPv6 Embedded RP technique [RFC3956], used with Protocol 191 Independent Multicast - Sparse Mode (PIM-SM), further leverages the 192 unicast prefix based allocations, by embedding the unicast prefix and 193 interface identifier of the PIM-SM Rendezvous Point (RP) in the 194 prefix. This provides all the necessary information needed to the 195 routing systems to run the group in either inter- or intra-domain 196 operation. A difference from RFC 3306 is, however, that the hosts 197 cannot calculate their "multicast prefix" automatically, as the 198 prefix depends on the decisions of the operator setting up the RP, 199 but instead requires an assignment method. 201 All the IPv6 unicast-prefix-based allocation techniques provide 202 sufficient amount of multicast address space for the network 203 operators. 205 2.2. Administratively Scoped Allocation 207 Administratively scoped multicast address allocation [RFC2365] is 208 provided by two different means: under 239.0.0.0/8 in IPv4 or by 209 4-bit encoding in the IPv6 multicast address prefix [RFC3513]. 211 Since IPv6 administratively scoped allocations can be handled with 212 unicast-prefix-based multicast addressing as described in 213 Section 2.1.2, we'll just discuss IPv4 in this section. 215 The IPv4 administratively scoped prefix 239.0.0.0/8 is further 216 divided to Local Scope (239.255.0.0/16) and Organization Local Scope 217 (239.192.0.0/14); other parts of the administrative scopes are either 218 reserved for expansion or undefined [RFC2365]. However, RFC 2365 is 219 ambiguous as to whether the enterprises or the IETF are allowed to 220 expand the space. 222 Topologies which act under a single administration can easily use the 223 scoped multicast addresses for their internal groups. Groups which 224 need to be shared between multiple routing domains (even if not 225 propagated through the Internet) are more problematic and typically 226 need an assignment of a global multicast address because their scope 227 is undefined. 229 There is a large number of multicast applications (such as "Norton 230 Ghost") which are restricted either to a link or a site, and it is 231 extremely undesirable to propagate them further (beyond the link or 232 the site). Typically many such applications have been given or have 233 hijacked a static IANA address assignment. The fact that assignments 234 to typically locally used applications come from the same range as 235 global applications, implementing proper propagation limiting is 236 challenging. Filtering would be easier if such applications would in 237 future be assigned specific administratively scoped addresses 238 instead. This is an area of further future work. 240 There has also been work on a protocol to automatically discover 241 multicast scope zones [RFC2776], but it has never been widely 242 implemented or deployed. 244 2.3. Static IANA Allocation 246 In some rare cases, some organizations may have been able to obtain 247 static multicast address allocations (of up to 256 addresses) 248 directly from IANA. Typically these have been meant as a block of 249 static assignments to multicast applications, as described in 250 Section 3.4.1. In principle, IANA should not and does not allocate 251 multicast address blocks to the operators but GLOP or Unicast-prefix- 252 based allocations should be used instead. 254 2.4. Dynamic Allocation 256 RFC 2908 [RFC2908] proposed three different layers of multicast 257 address allocation and assignment, where layers 3 (inter-domain 258 allocation) and layer 2 (intra-domain allocation) could be applicable 259 here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an 260 example of the former, and Multicast Address Allocation Protocol 261 (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest 262 and technical problems) is an example of the latter. 264 Both of the proposed allocation protocols were quite complex, and 265 have never been deployed or seriously implemented. 267 It can be concluded that dynamic multicast address allocation 268 protocols provide no benefit beyond GLOP/unicast-prefix-based 269 mechanisms and have been abandoned. 271 3. Multicast Address Assignment 273 There are a number of possible ways for an application, node or set 274 of nodes to learn a multicast address as described below. 276 Any IPv6 address assignment method should be aware of the guidelines 277 for the assignment of the group-IDs for IPv6 multicast addresses 278 [RFC3307]. 280 3.1. Derived Assignment 282 There are significantly fewer options for derived address assignment 283 compared to derived allocation. Derived multicast assignment has 284 only been specified for IPv6 link-scoped multicast [RFC4489], where 285 the EUI64 is embedded in the multicast address, providing a node with 286 unique multicast addresses for link-local ASM communications. 288 3.2. SSM Assignment inside the Node 290 While the SSM multicast addresses have only local (to the node) 291 significance, there is still a minor issue on how to assign the 292 addresses between the applications running on the same IP address. 294 This assignment is not considered to be a problem because typically 295 the addresses for the applications are selected manually or 296 statically, but if done using an Application Programming Interface 297 (API), the API could check that the addresses do not conflict prior 298 to assigning one. 300 3.3. Manually Configured Assignment 302 With manually configured assignment, the network operator who has a 303 multicast address prefix assigns the multicast group addresses to the 304 requesting nodes using a manual process. 306 Typically the user or administrator which wants to use a multicast 307 address for particular application requests an address from the 308 network operator using phone, email, or similar means, and the 309 network operator provides the user with a multicast address. Then 310 the user/administrator of the node or application manually configures 311 the application to use the assigned multicast address. 313 This is a relatively simple process; it has been sufficient for 314 certain applications which require manual configuration in any case, 315 or which cannot or do not want to justify a static IANA assignment. 316 The manual assignment works when the number of participants in a 317 group is small, as each participant has to be manually configured. 319 This is the most commonly used technique when the multicast 320 application does not have a static IANA assignment. 322 3.4. Static IANA Assignment 324 In contrast to manually configured assignment, as described above, 325 static IANA assignment refers to getting an assignment for the 326 particular application directly from IANA. There are two main forms 327 of IANA assignment: global and scope-relative. Guidelines for IANA 328 are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. 330 3.4.1. Global IANA Assignment 332 Globally unique address assignment is seen as lucrative because it's 333 the simplest approach for application developers since they can then 334 hard-code the multicast address. Hard-coding requires no lease of 335 the usable multicast address, and likewise the client applications do 336 not need to perform any kind of service discovery (but depending on 337 hard-coded addresses). However, there is an architectural scaling 338 problem with this approach, as it encourages a "land-grab" of the 339 limited multicast address space. 341 [RFC3138] describes how to handle those GLOP assignments (called 342 "eGLOP") which use the private-use AS number space (233.252.0.0/14). 343 It was envisioned that IANA would delegate the responsibility of 344 these to RIRs, which would assign or allocate addresses as best 345 seemed fit. However, this was never carried out as IANA did not make 346 these allocations to RIRs due to procedural reasons. 348 In summary, there are applications which have obtained a global 349 static IANA assignment and while some of the assignments were really 350 needed, others probably should not have been granted. Conversely, 351 there are some applications that have not obtained a static IANA 352 assignment, yet should have requested an assignment and been granted 353 one. 355 3.4.2. Scope-relative IANA Assignment 357 IANA also assigns numbers as an integer offset from the highest 358 address in each IPv4 administrative scope as described in [RFC2365]. 359 For example, the SLPv2 discovery scope-relative offset is "2", so 360 SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is 361 "239.255.255.253", within the IPv4 Organization Local-Scope 362 (239.192.0.0/14) it is "239.195.255.253", and so on. 364 Similar scope-relative assignments also exist with IPv6 [RFC2375]. 365 As IPv6 multicast addresses have much more flexible scoping, scope- 366 relative assignments are also applicable to global scopes. The 367 assignment policies are described in [RFC3307]. 369 3.5. Dynamic Assignments 371 The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from 372 Multicast Address Allocation Servers (MAAS) to applications and 373 nodes, with Multicast Address Dynamic Client Allocation Protocol 374 (MADCAP) [RFC2730] as an example. Since then, there has been a 375 proposal for DHCPv6 assignment 376 [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]. 378 It would be rather straightforward to deploy a dynamic assignment 379 protocol which would lease group addresses based on a multicast 380 prefix to the applications wishing to use multicast. However, only 381 few have implemented MADCAP, and it hasn't been significantly 382 deployed. So, it is not clear if the lack of deployment is due to a 383 currently missing need. Moreover, it is not clear how widely for 384 example the APIs for communication between the multicast application 385 and the MADCAP client operating at the host have been implemented 386 [RFC2771]. 388 An entirely different approach is Session Announcement Protocol (SAP) 389 [RFC2974]. In addition to advertising global multicast sessions, the 390 protocol also has associated ranges of addresses for both IPv4 and 391 IPv6 which can be used by SAP-aware applications to create new groups 392 and new group addresses. Creating a session (and obtaining an 393 address) is a rather tedious process which is why it isn't done all 394 that often. (Note that the IPv6 SAP address is unroutable in the 395 inter-domain multicast.) 397 A conclusion about dynamic assignment protocols is that: 399 1. multicast is not significantly attractive in the first place, 401 2. most applications have a static IANA assignment and thus require 402 no dynamic or manual assignment, 404 3. those that cannot be easily satisfied with IANA or manual 405 assignment (i.e., where dynamic assignment would be desirable) 406 are rather marginal, or 408 4. that there are other gaps why dynamic assignments are not seen as 409 a useful approach (for example, issues related to service 410 discovery/rendezvous). 412 In consequence, more work on rendezvous/service discovery would be 413 needed to make dynamic assignments more useful. 415 4. Summary and Future Directions 417 This section summarizes the mechanisms and analysis discussed in this 418 memo, and presents some potential future directions. 420 4.1. Prefix Allocation 422 Summary of prefix allocation methods for ASM is in Figure 1. 424 +-------+--------------------------------+--------+--------+ 425 | Sect. | Prefix allocation method | IPv4 | IPv6 | 426 +-------+--------------------------------+--------+--------+ 427 | 2.1.1 | Derived: GLOP | Yes | NoNeed*| 428 | 2.1.2 | Derived: Unicast-prefix-based | No | Yes | 429 | 2.2 | Administratively scoped | Yes | NoNeed*| 430 | 2.3 | Static IANA allocation | No | No | 431 | 2.4 | Dynamic allocation protocols | No | No | 432 +-------+--------------------------------+--------+--------+ 433 * = the need satisfied by IPv6 unicast-prefix-based allocation. 435 Figure 1 437 o Only ASM is affected by the assignment/allocation issues (however, 438 both ASM and SSM have roughly the same address discovery issues). 440 o GLOP allocations seem to provide a sufficient IPv4 multicast 441 allocation mechanism for now, but could be extended in future. 442 Administratively scoped allocations provide the opportunity for 443 internal IPv4 allocations. 445 o Unicast-prefix-based addresses and the derivatives provide good 446 allocation strategy with IPv6, also for scoped multicast 447 addresses. 449 o Dynamic allocations are a too complex and unnecessary mechanism. 451 o Static IANA allocations are generally an architecturally 452 unacceptable approach. 454 4.2. Address Assignment 456 Summary of address assignment methods is in Figure 2. 458 +--------+--------------------------------+----------+----------+ 459 | Sect. | Address assignment method | IPv4 | IPv6 | 460 +--------+--------------------------------+----------+----------+ 461 | 3.1 | Derived: link-scope addresses | No | Yes | 462 | 3.2 | SSM (inside the node) | Yes | Yes | 463 | 3.3 | Manual assignment | Yes | Yes | 464 | 3.4.1 | Global IANA/RIR assignment |LastResort|LastResort| 465 | 3.4.2 | Scope-relative IANA assignment | Yes | Yes | 466 | 3.5 | Dynamic assignment protocols | Yes | Yes | 467 +--------+--------------------------------+----------+----------+ 469 Figure 2 471 o Manually configured assignment is what's typically done today, and 472 works to a sufficient degree in smaller scale. 474 o Global IANA assignment has been done extensively in the past, but 475 it needs to be tightened down to prevent problems caused by "land- 476 grabbing". Scope-relative IANA assignment is acceptable but the 477 size of the pool is not very high. Inter-domain routing of IPv6 478 IANA-assigned prefixes is likely going to be challenging. 480 o Dynamic assignment, e.g., MADCAP has been implemented, but there 481 is no wide deployment. So, either there are other gaps in the 482 multicast architecture or there is no sufficient demand for it in 483 the first place when manual and static IANA assignments are 484 available. Assignments using SAP also exist but are not common; 485 global SAP assignment is unfeasible with IPv6. 487 o Derived assignments are only applicable in a fringe case of link- 488 scoped multicast. 490 4.3. Future Actions 492 o Multicast address discovery/"rendezvous" needs to be analyzed at 493 more length, and an adequate solution provided; the result also 494 needs to be written down to be shown to the IANA static assignment 495 requestors. See [I-D.ietf-mboned-addrdisc-problems] for more. 497 o IPv6 multicast DAD and/or multicast prefix communication 498 mechanisms should be analyzed (e.g., 499 [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, 500 and specify if yes. 502 o The IETF should consider whether to specify more ranges of the 503 IPv4 administratively scoped address space for static allocation 504 for applications which should not be routed over the Internet 505 (such as backup software, etc. -- so that these wouldn't need to 506 use global addresses which should never leak in any case). 508 o The IETF should seriously consider its static IANA allocations 509 policy, e.g., "locking it down" to a stricter policy (like "IETF 510 Consensus") and looking at developing the discovery/rendezvous 511 functions, if necessary. 513 5. Acknowledgements 515 Tutoring a couple multicast-related papers, the latest by Kaarle 516 Ritvanen [RITVANEN] convinced the author that updated multicast 517 address assignment/allocation documentation is needed. 519 Multicast address allocations/assignments were discussed at the 520 MBONED WG session at IETF59 [MBONED-IETF59]. 522 Dave Thaler, James Lingard, and Beau Williamson provided useful 523 feedback for the preliminary version of this memo. Myung-Ki Shin, 524 Jerome Durand, John Kristoff, Dave Price, and Spencer Dawkins also 525 suggested improvements. 527 6. IANA Considerations 529 This memo includes no request to IANA, but as the allocation and 530 assignment of multicast addresses are related to IANA functions, it 531 wouldn't hurt if the IANA reviewed this entire memo. 533 IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still 534 apply to the administratively scoped prefixes. 536 IANA may be interested in reviewing the accuracy of the statement on 537 eGLOP address assignments in Section 3.4.1. 539 (RFC-editor: please remove this section at publication.) 541 7. Security Considerations 543 This memo only describes different approaches to allocating and 544 assigning multicast addresses, and this has no security 545 considerations; the security analysis of the mentioned protocols is 546 out of scope of this memo. 548 Obviously, especially the dynamic assignment protocols are inherently 549 vulnerable to resource exhaustion attacks, as discussed e.g., in 550 [RFC2730]. 552 8. References 554 8.1. Normative References 556 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 557 RFC 2365, July 1998. 559 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 560 "IANA Guidelines for IPv4 Multicast Address Assignments", 561 BCP 51, RFC 3171, August 2001. 563 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 564 BCP 53, RFC 3180, September 2001. 566 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 567 Multicast Addresses", RFC 3306, August 2002. 569 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 570 Addresses", RFC 3307, August 2002. 572 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 573 (IPv6) Addressing Architecture", RFC 3513, April 2003. 575 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 576 Point (RP) Address in an IPv6 Multicast Address", 577 RFC 3956, November 2004. 579 [RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for 580 Generating Link-Scoped IPv6 Multicast Addresses", 581 RFC 4489, April 2006. 583 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 584 IP", RFC 4607, August 2006. 586 8.2. Informative References 588 [I-D.ietf-idr-as4bytes] 589 Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 590 Number Space", draft-ietf-idr-as4bytes-12 (work in 591 progress), November 2005. 593 [I-D.ietf-malloc-aap] 594 Handley, M. and S. Hanna, "Multicast Address Allocation 595 Protocol (AAP)", June 2000. 597 [I-D.ietf-mboned-addrdisc-problems] 598 Savola, P., "Lightweight Multicast Address Discovery 599 Problem Space", draft-ietf-mboned-addrdisc-problems-02 600 (work in progress), March 2006. 602 [I-D.ietf-mboned-ipv4-uni-based-mcast] 603 Thaler, D., "Unicast-Prefix-based IPv4 Multicast 604 Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02 605 (work in progress), October 2004. 607 [I-D.ietf-mboned-rfc3171bis] 608 Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA 609 Guidelines for IPv4 Multicast Address Assignments", 610 draft-ietf-mboned-rfc3171bis-02 (work in progress), 611 March 2004. 613 [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] 614 Durand, J., "IPv6 multicast address assignment with 615 DHCPv6", 616 draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work 617 in progress), February 2005. 619 [I-D.jdurand-ipv6-multicast-ra] 620 Durand, J. and P. Savola, "Route Advertisement Option for 621 IPv6 Multicast Prefixes", 622 draft-jdurand-ipv6-multicast-ra-00 (work in progress), 623 February 2005. 625 [MBONED-IETF59] 626 "MBONED WG session at IETF59", 627 . 629 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 630 RFC 2131, March 1997. 632 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 633 Assignments", RFC 2375, July 1998. 635 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 636 "Service Location Protocol, Version 2", RFC 2608, 637 June 1999. 639 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 640 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 641 December 1999. 643 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 644 Allocation", RFC 2771, February 2000. 646 [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 647 Zone Announcement Protocol (MZAP)", RFC 2776, 648 February 2000. 650 [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet 651 Multicast Address Allocation Architecture", RFC 2908, 652 September 2000. 654 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 655 Kumar, S., and D. Thaler, "The Multicast Address-Set Claim 656 (MASC) Protocol", RFC 2909, September 2000. 658 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 659 Announcement Protocol", RFC 2974, October 2000. 661 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 662 June 2001. 664 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 665 and M. Carney, "Dynamic Host Configuration Protocol for 666 IPv6 (DHCPv6)", RFC 3315, July 2003. 668 [RITVANEN] 669 Ritvanen, K., "Multicast Routing and Addressing", HUT 670 Report, Seminar on Internetworking, May 2004, 671 . 673 Appendix A. Changes 675 (To be removed prior to publication as an RFC.) 677 A.1. Changes between -04 and -05 679 o Editorial updates. These and the following are from Spencer 680 Dawkins. 682 o New text explictly stating that GLOP for v6 is not needed and GLOP 683 for 4byte ASNs isn't (and likely won't be) defined. 685 o Expand reasons for filtering difficulties with global IANA 686 assignments for local apps, and that it would be easier if these 687 were done from the local pool. 689 o Explicitly mention dynamic allocations protocols' lack of benefit 690 and abandonment. 692 A.2. Changes between -03 and -04 694 o S/scope-relative/administratively scoped/ and expand Static IANA 695 Assignment section to two subsections; mainly from Dave Price. 697 o Mention the routing challenges of IPv6 IANA assigned prefixes in 698 section 4.2 700 A.3. Changes between -02 and -03 702 o Reword architectural implications of Static IANA and editorial 703 improvements; mainly from John Kristoff. 705 A.4. Changes between -01 and -02 707 o Mention the mechanisms which haven't been so succesful: eGLOP and 708 MZAP. 710 o Remove the appendices on multicast address discovery (a separate 711 draft now) and IPv4 unicast-prefix-based multicast addressing. 713 o Add a note on administratively scoped address space and the 714 expansion ambiguity. 716 o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt 718 o Minor editorial cleanups. 720 Author's Address 722 Pekka Savola 723 CSC - Scientific Computing Ltd. 724 Espoo 725 Finland 727 Email: psavola@funet.fi 729 Full Copyright Statement 731 Copyright (C) The Internet Society (2006). 733 This document is subject to the rights, licenses and restrictions 734 contained in BCP 78, and except as set forth therein, the authors 735 retain all their rights. 737 This document and the information contained herein are provided on an 738 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 739 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 740 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 741 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 742 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 743 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 745 Intellectual Property 747 The IETF takes no position regarding the validity or scope of any 748 Intellectual Property Rights or other rights that might be claimed to 749 pertain to the implementation or use of the technology described in 750 this document or the extent to which any license under such rights 751 might or might not be available; nor does it represent that it has 752 made any independent effort to identify any such rights. Information 753 on the procedures with respect to rights in RFC documents can be 754 found in BCP 78 and BCP 79. 756 Copies of IPR disclosures made to the IETF Secretariat and any 757 assurances of licenses to be made available, or the result of an 758 attempt made to obtain a general license or permission for the use of 759 such proprietary rights by implementers or users of this 760 specification can be obtained from the IETF on-line IPR repository at 761 http://www.ietf.org/ipr. 763 The IETF invites any interested party to bring to its attention any 764 copyrights, patents or patent applications, or other proprietary 765 rights that may cover technology that may be required to implement 766 this standard. Please address the information to the IETF at 767 ietf-ipr@ietf.org. 769 Acknowledgment 771 Funding for the RFC Editor function is provided by the IETF 772 Administrative Support Activity (IASA).