--- 1/draft-ietf-mboned-addrarch-03.txt 2006-03-03 22:12:39.000000000 +0100 +++ 2/draft-ietf-mboned-addrarch-04.txt 2006-03-03 22:12:39.000000000 +0100 @@ -1,19 +1,21 @@ Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET -Obsoletes: 2776,2908,2909 (if October 18, 2005 +Obsoletes: 2776,2908,2909 (if March 3, 2006 approved) -Expires: April 21, 2006 +Intended status: Best Current +Practice +Expires: September 4, 2006 Overview of the Internet Multicast Addressing Architecture - draft-ietf-mboned-addrarch-03.txt + draft-ietf-mboned-addrarch-04.txt Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,65 +26,67 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 21, 2006. + This Internet-Draft will expire on September 4, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3 2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 2.1.2. Unicast-prefix -based Allocation . . . . . . . . . . . 4 - 2.2. Scope-relative Allocation . . . . . . . . . . . . . . . . 5 + 2.2. Administratively Scoped Allocation . . . . . . . . . . . . 5 2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6 3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7 3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7 3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7 3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 7 + 3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8 + 3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8 3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 - 4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 9 - 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 10 + 4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10 + 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 14 - A.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 + Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 + A.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 + Intellectual Property and Copyright Statements . . . . . . . . . . 17 1. Introduction Good, up-to-date documentation of IP multicast is close to non- existent. Particularly, this is an issue with multicast address allocations (to networks and sites) and assignments (to hosts and applications). This problem is stressed by the fact that there exists confusing or misleading documentation on the subject [RFC2908]. The consequence is that those who wish to learn of IP multicast and how the addressing works do not get a clear view of the @@ -154,25 +158,25 @@ usage issue is that GLOP addresses are not tied to any prefix but to routing domains, so they cannot be used or calculated automatically. 2.1.2. Unicast-prefix -based Allocation RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first bits of an IPv6 unicast address in the prefix part of the IPv6 multicast address, leaving at least 32 bits of group-id space available after the prefix mapping. - A similar mapping has been proposed for IPv4 [I-D.ietf-mboned-ipv4- - uni-based-mcast], but it provides a rather low amount of addresses - (e.g., 1 per an IPv4 /24 block). While there exist large networks - without an AS number of their own, this has not been seen to add - sufficient value compared to GLOP addressing. + A similar mapping has been proposed for IPv4 + [I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low + amount of addresses (e.g., 1 per an IPv4 /24 block). While there + exist large networks without an AS number of their own, this has not + been seen to add sufficient value compared to GLOP addressing. The IPv6 unicast-prefix-based allocations are an extremely useful way to allow each network operator, even each subnet, obtain multicast addresses easily, through an easy computation. Further, as the IPv6 multicast header also includes the scope value [RFC3513], multicast groups of smaller scope can also be used with the same mapping. The IPv6 Embedded RP technique [RFC3956], used with Protocol Independent Multicast - Sparse Mode (PIM-SM), further leverages the unicast prefix based allocations, by embedding the unicast prefix and @@ -181,68 +185,67 @@ routing systems to run the group in either inter- or intra-domain operation. A difference to RFC 3306 is, however, that the hosts cannot calculate their "multicast prefix" automatically, as the prefix depends on the decisions of the operator setting up the RP but rather requires an assignment method. All the IPv6 unicast-prefix-based allocation techniques provide sufficient amount of multicast address space for the network operators. -2.2. Scope-relative Allocation +2.2. Administratively Scoped Allocation Administratively scoped multicast [RFC2365] is provided by two different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in the IPv6 multicast address prefix [RFC3513]. - As IPv6 scope-relative allocations can be handled with unicast- - prefix-based multicast addressing as described in Section 2.1.2, and - there is no need for separate scope-relative allocations, we'll just - discuss IPv4 in this section. + As IPv6 administratively scoped allocations can be handled with + unicast-prefix-based multicast addressing as described in + Section 2.1.2, we'll just discuss IPv4 in this section. - The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to - Local Scope (239.255.0.0/16) and Organization Local Scope + The IPv4 administratively scoped prefix 239.0.0.0/8 is further + divided to Local Scope (239.255.0.0/16) and Organization Local Scope (239.192.0.0/14); other parts of the administrative scopes are either reserved for expansion or undefined [RFC2365]. However, RFC 2365 is ambiguous as to whether it's the enterprises or the IETF who are allowed to expand the space. Topologies which act under a single administration can easily use the scoped multicast addresses for their internal groups. Groups which need to be shared between multiple routing domains (but not propagated through the Internet) are more problematic and typically need an assignment of a global multicast address because their scope is undefined. There is a large number of multicast applications (such as "Norton Ghost") which are restricted either to a link or a site, and it is extremely undesirable to propagate them further (either to the rest of the site, or beyond the site). Typically many such applications have been given or have hijacked a static IANA address assignment; this makes it challenging to implement proper propagation limiting -- which could be easier if such applications could have been assigned - specific scope-relative addresses instead. This is an area of - further future work. + specific administratively scoped addresses instead. This is an area + of further future work. There has also been work on a protocol to automatically discover multicast scope zones [RFC2776], but it has never been widely implemented or deployed. 2.3. Static IANA Allocation In some rare cases, some organizations may have been able to obtain static multicast address allocations (of up to 256 addresses) directly from IANA. Typically these have been meant as a block of static assignments to multicast applications, as described in - Section 3.4. In principle, IANA does not allocate multicast address - blocks to the operators but GLOP or Unicast-prefix-based allocations - should be used instead. + Section 3.4.1. In principle, IANA does not allocate multicast + address blocks to the operators but GLOP or Unicast-prefix-based + allocations should be used instead. 2.4. Dynamic Allocation RFC 2908 [RFC2908] proposed three different layers of multicast address allocation and assignment, where layers 3 (inter-domain allocation) and layer 2 (intra-domain allocation) could be applicable here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an example of the former, and Multicast Address Allocation Protocol (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest and technical problems) is an example of the latter. @@ -262,24 +265,24 @@ below. Any IPv6 address assignment method should be aware of the guidelines for the assignment of the group-IDs for IPv6 multicast addresses [RFC3307]. 3.1. Derived Assignment There are significantly fewer options for derived address assignment compared to derived allocation. Derived multicast assignment has - only been specified for IPv6 link-scoped multicast [I-D.ietf-ipv6- - link-scoped-mcast], where the EUI64 is embedded in the multicast - address, providing a node with unique multicast addresses for link- - local ASM communications. + only been specified for IPv6 link-scoped multicast + [I-D.ietf-ipv6-link-scoped-mcast], where the EUI64 is embedded in the + multicast address, providing a node with unique multicast addresses + for link-local ASM communications. 3.2. SSM Assignment inside the Node While the SSM multicast addresses have only local (to the node) significance, there is still a minor issue on how to assign the addresses between the applications running on the same node (or more precisely, an IP address). This assignment is not considered to be a problem because typically the addresses for the applications are selected manually or @@ -305,54 +308,72 @@ or which cannot or do not want to justify a static IANA assignment. The manual assignment works when the number of participants in a group is small, as each participant has to be manually configured. This is the most commonly used technique when the multicast application does not have a static IANA assignment. 3.4. Static IANA Assignment In contrast to manually configured assignment, as described above, - static IANA assignment refers to getting a globally unique assignment - for the particular application directly from IANA. Guidelines for - IANA are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. + static IANA assignment refers to getting an assignment for the + particular application directly from IANA. There are two main forms + of IANA assignment: global and scope-relative. Guidelines for IANA + are described in [RFC3171][I-D.ietf-mboned-rfc3171bis]. - This is seen as lucrative because it's the simplest approach for - application developers because they can then hard-code the multicast - address. Hard-coding requires no lease of the usable multicast - address, and likewise the client applications do not need to perform - any kind of service discovery (but depending on hard-coded - addresses). However, there is an architectural scaling problem with - this approach, as it encourages a "land-grab" of the limited - multicast address space. +3.4.1. Global IANA Assignment + + Globally unique address assignment is seen as lucrative because it's + the simplest approach for application developers since they can then + hard-code the multicast address. Hard-coding requires no lease of + the usable multicast address, and likewise the client applications do + not need to perform any kind of service discovery (but depending on + hard-coded addresses). However, there is an architectural scaling + problem with this approach, as it encourages a "land-grab" of the + limited multicast address space. [RFC3138] describes how to handle those GLOP assignments (called "eGLOP") which use the private-use AS number space (233.252.0.0/14). It was envisioned that IANA would delegate the responsibility of these to RIRs, which would assign or allocate addresses as best seemed fit. However, this was never carried out as IANA did not make these allocations to RIRs due to procedural reasons. - In summary, there are applications which have obtained a static IANA - assignment and while some of which are really needed, some of which - probably should not have been granted. Conversely, there are some - applications that have not obtained a static IANA assignment, yet - should have requested an assignment and been granted one. + In summary, there are applications which have obtained a global + static IANA assignment and while some of which are really needed, + some of which probably should not have been granted. Conversely, + there are some applications that have not obtained a static IANA + assignment, yet should have requested an assignment and been granted + one. + +3.4.2. Scope-relative IANA Assignment + + IANA also assigns numbers as an integer offset from the highest + address in each IPv4 administrative scope as described in [RFC2365]. + For example, the SLPv2 discovery scope-relative offset is "2", so + SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is + "239.255.255.253", within the IPv4 Organization Local-Scope + (239.192.0.0/14) it is "239.195.255.253", and so on. + + Similar scope-relative assignments also exist with IPv6 [RFC2375]. + As IPv6 multicast addresses have much more flexible scoping, scope- + relative assignments are also applicable to global scopes. The + assignment policies are described in [RFC3307]. 3.5. Dynamic Assignments The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from Multicast Address Allocation Servers (MAAS) to applications and nodes, with Multicast Address Dynamic Client Allocation Protocol (MADCAP) [RFC2730] as an example. Since then, there has been a - proposal for DHCPv6 assignment [I-D.jdurand-assign-addr-ipv6- - multicast-dhcpv6]. + proposal for DHCPv6 assignment + [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]. It would be rather straightforward to deploy a dynamic assignment protocol which would lease group addresses based on a multicast prefix to the applications wishing to use multicast. For example, only few have implemented MADCAP, and it's not significantly deployed. Moreover, it is not clear how widely for example the APIs for communication between the multicast application and the MADCAP client operating at the host have been implemented [RFC2771]. An entirely different approach is Session Announcement Protocol (SAP) @@ -389,67 +410,70 @@ 4.1. Prefix Allocation Summary of prefix allocation methods for ASM is in Figure 1. +-------+--------------------------------+--------+--------+ | Sect. | Prefix allocation method | IPv4 | IPv6 | +-------+--------------------------------+--------+--------+ | 2.1.1 | Derived: GLOP | Yes | NoNeed*| | 2.1.2 | Derived: Unicast-prefix-based |No -yet | Yes | - | 2.2 | Separate Scope-relative | Yes | NoNeed*| + | 2.2 | Administratively scoped | Yes | NoNeed*| | 2.3 | Static IANA allocation | No | No | | 2.4 | Dynamic allocation protocols | No | No | +-------+--------------------------------+--------+--------+ * = the need satisfied by IPv6 unicast-prefix-based allocation. Figure 1 o Only ASM is affected by the assignment/allocation issues (however, both ASM and SSM have roughly the same address discovery issues). o GLOP allocations seem to provide a sufficient IPv4 multicast allocation mechanism for now, but could be extended in future. - Scope-relative allocations provide the opportunity for internal - IPv4 allocations. + Administratively scoped allocations provide the opportunity for + internal IPv4 allocations. o Unicast-prefix-based addresses and the derivatives provide good allocation strategy with IPv6, also for scoped multicast addresses. o Dynamic allocations are a too complex and unnecessary mechanism. o Static IANA allocations are generally an architecturally unacceptable approach. 4.2. Address Assignment Summary of address assignment methods is in Figure 2. - +-------+--------------------------------+----------+----------+ + +--------+--------------------------------+----------+----------+ | Sect. | Address assignment method | IPv4 | IPv6 | - +-------+--------------------------------+----------+----------+ + +--------+--------------------------------+----------+----------+ | 3.1 | Derived: link-scope addresses | No | Yes | | 3.2 | SSM (inside the node) | Yes | Yes | | 3.3 | Manual assignment | Yes | Yes | - | 3.4 | Static IANA/RIR assignment |LastResort|LastResort| + | 3.4.1 | Global IANA/RIR assignment |LastResort|LastResort| + | 3.4.2 | Scope-relative IANA assignment | Yes | Yes | | 3.5 | Dynamic assignment protocols | Yes | Yes | - +-------+--------------------------------+----------+----------+ + +--------+--------------------------------+----------+----------+ Figure 2 o Manually configured assignment is what's typically done today, and works to a sufficient degree in smaller scale. - o Static IANA assignment has been done extensively in the past, but + o Global IANA assignment has been done extensively in the past, but it needs to be tightened down to prevent problems caused by "land- - grabbing". + grabbing". Scope-relative IANA assignment is acceptable but the + size of the pool is not very high. Inter-domain routing of IPv6 + IANA-assigned prefixes is likely going to be challenging. o Dynamic assignment, e.g., MADCAP has been implemented, but there is no wide deployment, so a solution is there. However, either there are other gaps in the multicast architecture or there is no sufficient demand for it in the first place when manual and static IANA assignments are available. Assignments using SAP also exist but are not common; global SAP assignment is unfeasible with IPv6. o Derived assignments are only applicable in a fringe case of link- scoped multicast. @@ -460,54 +484,55 @@ more length, and an adequate solution provided; the result also needs to be written down to be shown to the IANA static assignment requestors. See [I-D.ietf-mboned-addrdisc-problems] for more. o IPv6 multicast DAD and/or multicast prefix communication mechanisms should be analyzed (e.g., [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, and specify if yes. o The IETF should consider whether to specify more ranges of the - IPv4 scope-relative address space for static allocation for - applications which should not be routed over the Internet (such as - backup software, etc. -- so that these wouldn't need to use global - addresses which should never leak in any case). + IPv4 administratively scoped address space for static allocation + for applications which should not be routed over the Internet + (such as backup software, etc. -- so that these wouldn't need to + use global addresses which should never leak in any case). o The IETF should seriously consider its static IANA allocations policy, e.g., "locking it down" to a stricter policy (like "IETF Consensus") and looking at developing the discovery/rendezvous functions, if necessary. 5. Acknowledgements Tutoring a couple multicast-related papers, the latest by Kaarle Ritvanen [RITVANEN] convinced the author that the up-to-date multicast address assignment/allocation documentation is necessary. Multicast address allocations/assignments were discussed at the MBONED WG session at IETF59 [MBONED-IETF59]. Dave Thaler, James Lingard, and Beau Williamson provided useful feedback for the preliminary version of this memo. Myung-Ki Shin, - Jerome Durand, and John Kristoff also suggested improvements. + Jerome Durand, John Kristoff, and Dave Price also suggested + improvements. 6. IANA Considerations This memo includes no request to IANA, but as the allocation and assignment of multicast addresses are related to IANA functions, it wouldn't hurt if the IANA reviewed this entire memo. IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still apply to the administratively scoped prefixes. IANA may be interested in reviewing the accuracy of the statement on - eGLOP address assignments in Section 3.4. + eGLOP address assignments in Section 3.4.1. (RFC-editor: please remove this section at publication.) 7. Security Considerations This memo only describes different approaches to allocating and assigning multicast addresses, and this has no security considerations; the security analysis of the mentioned protocols is out of scope of this memo. @@ -553,22 +578,22 @@ RFC 3956, November 2004. 8.2. Informative References [I-D.ietf-malloc-aap] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", June 2000. [I-D.ietf-mboned-addrdisc-problems] Savola, P., "Lightweight Multicast Address Discovery - Problem Space", draft-ietf-mboned-addrdisc-problems-00 - (work in progress), March 2005. + Problem Space", draft-ietf-mboned-addrdisc-problems-01 + (work in progress), November 2005. [I-D.ietf-mboned-ipv4-uni-based-mcast] Thaler, D., "Unicast-Prefix-based IPv4 Multicast Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02 (work in progress), October 2004. [I-D.ietf-mboned-rfc3171bis] Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", draft-ietf-mboned-rfc3171bis-02 (work in progress), @@ -586,20 +611,23 @@ draft-jdurand-ipv6-multicast-ra-00 (work in progress), February 2005. [MBONED-IETF59] "MBONED WG session at IETF59", . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. + [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address + Assignments", RFC 2375, July 1998. + [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. [RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000. @@ -636,39 +664,39 @@ (To be removed prior to publication as an RFC.) A.1. Changes since -01 o Mention the mechanisms which haven't been so succesful: eGLOP and MZAP. o Remove the appendices on multicast address discovery (a separate draft now) and IPv4 unicast-prefix-based multicast addressing. - o Add a note on scope-relative address space and the expansion - ambiguity. + o Add a note on administraively scoped address space and the + expansion ambiguity. o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt o Minor editorial cleanups. Author's Address Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland Email: psavola@funet.fi Full Copyright Statement - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE @@ -694,12 +722,12 @@ http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA).