--- 1/draft-ietf-mboned-addrarch-06.txt 2010-10-25 12:14:30.000000000 +0200 +++ 2/draft-ietf-mboned-addrarch-07.txt 2010-10-25 12:14:30.000000000 +0200 @@ -1,97 +1,96 @@ Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET -Obsoletes: 2908 (if approved) August 3, 2009 +Obsoletes: 2908 (if approved) October 25, 2010 Intended status: Informational -Expires: February 4, 2010 +Expires: April 28, 2011 Overview of the Internet Multicast Addressing Architecture - draft-ietf-mboned-addrarch-06.txt + draft-ietf-mboned-addrarch-07.txt + +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. Status of this Memo - This Internet-Draft is submitted to IETF in full conformance with the + This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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 February 4, 2010. + This Internet-Draft will expire on April 28, 2011. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -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. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. 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. Administratively Scoped Allocation . . . . . . . . . . . . 5 2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 - 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 7 + 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 . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . 10 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 - A.1. Changes between -05 and -06 . . . . . . . . . . . . . . . 15 - A.2. Changes between -04 and -05 . . . . . . . . . . . . . . . 15 - A.3. Changes between -03 and -04 . . . . . . . . . . . . . . . 16 - A.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 16 - A.5. Changes between -01 and -02 . . . . . . . . . . . . . . . 16 + A.1. Changes between -06 and -07 . . . . . . . . . . . . . . . 15 + A.2. Changes between -05 and -06 . . . . . . . . . . . . . . . 15 + A.3. Changes between -04 and -05 . . . . . . . . . . . . . . . 15 + A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 16 + A.5. Changes between -02 and -03 . . . . . . . . . . . . . . . 16 + A.6. Changes between -01 and -02 . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 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 about IP @@ -174,23 +173,22 @@ because the unicast-prefix-based allocation (described below) addresses the same need in a simpler fashion. 2.1.2. Unicast-prefix-based Allocation RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 high- order 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 IPv4 mapping is described in - [I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a limited - number of addresses (e.g., 1 per an IPv4 /24 block). + A similar IPv4 mapping is described in [RFC6034], but it provides a + limited number of addresses (e.g., 1 per an IPv4 /24 block). The IPv6 unicast-prefix-based allocations are an extremely useful way to allow each network operator, even each subnet, to obtain multicast addresses easily, through an easy computation. Further, as the IPv6 multicast header also includes the scope value [RFC4291], 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 @@ -248,22 +246,21 @@ In some rare cases, 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.1. If another means of obtaining addresses is available that approach is preferable. Especially for those operators that only have a 32-bit AS number and need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the - previous so-called "eGLOP" block) is an option - [I-D.ietf-mboned-rfc3171bis]. + previous so-called "eGLOP" block) is an option [RFC5771]. 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. @@ -325,21 +322,21 @@ 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 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 [I-D.ietf-mboned-rfc3171bis]. + are described in [RFC5771]. 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 @@ -530,31 +527,20 @@ considerations; the security analysis of the mentioned protocols is out of scope of this memo. Obviously, especially the dynamic assignment protocols are inherently vulnerable to resource exhaustion attacks, as discussed e.g., in [RFC2730]. 8. References 8.1. Normative References - [I-D.ietf-mboned-ipv4-uni-based-mcast] - Thaler, D., "Unicast-Prefix-based IPv4 Multicast - Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-06 - (work in progress), March 2009. - - [I-D.ietf-mboned-rfc3171bis] - Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for - IPv4 Multicast Address Assignments", - draft-ietf-mboned-rfc3171bis-07 (work in progress), - April 2009. - [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001. [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast @@ -567,36 +553,43 @@ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for Generating Link-Scoped IPv6 Multicast Addresses", RFC 4489, April 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. + [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for + IPv4 Multicast Address Assignments", BCP 51, RFC 5771, + March 2010. + + [RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast + Addresses", RFC 6034, October 2010. + 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-02 (work in progress), March 2006. [I-D.ietf-mboned-session-announcement-req] Asaeda, H. and V. Roca, "Requirements for IP Multicast - Session Announcement in the Internet", - draft-ietf-mboned-session-announcement-req-01 (work in - progress), March 2009. + Session Announcement", + draft-ietf-mboned-session-announcement-req-03 (work in + progress), March 2010. [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] Durand, J., "IPv6 multicast address assignment with DHCPv6", draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work in progress), February 2005. [MBONED-IETF59] "MBONED WG session at IETF59", . @@ -638,64 +631,69 @@ [RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT Report, Seminar on Internetworking, May 2004, . Appendix A. Changes (To be removed prior to publication as an RFC.) -A.1. Changes between -05 and -06 +A.1. Changes between -06 and -07 + + o Update uni-based-mcast and iana updates references to point to + RFCs. + +A.2. Changes between -05 and -06 o Editorial updates. o Obsolete only RFC2908; the rest only move to Historic. o Category is Informational instead of BCP (in line with the routing architecture. o Move 3171bis and v4-uni-based to Normative references in order to make sure we don't go forward until they're resolved. o Resolve pending issues per IETF75 discussion, in particular major changes to eGLOP and IANA policy discussions. -A.2. Changes between -04 and -05 +A.3. Changes between -04 and -05 o Editorial updates. These and the following are from Spencer Dawkins. o New text explicitly stating that GLOP for v6 is not needed and GLOP for 4byte ASNs isn't (and likely won't be) defined. o Expand reasons for filtering difficulties with global IANA assignments for local apps, and that it would be easier if these were done from the local pool. o Explicitly mention dynamic allocations protocols' lack of benefit and abandonment. -A.3. Changes between -03 and -04 +A.4. Changes between -03 and -04 o S/scope-relative/administratively scoped/ and expand Static IANA Assignment section to two subsections; mainly from Dave Price. o Mention the routing challenges of IPv6 IANA assigned prefixes in section 4.2 -A.4. Changes between -02 and -03 +A.5. Changes between -02 and -03 o Reword architectural implications of Static IANA and editorial improvements; mainly from John Kristoff. -A.5. Changes between -01 and -02 +A.6. Changes between -01 and -02 o Mention the mechanisms which haven't been so successful: 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 administratively scoped address space and the expansion ambiguity.