draft-ietf-mboned-addrarch-06.txt   draft-ietf-mboned-addrarch-07.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: 2908 (if approved) August 3, 2009 Obsoletes: 2908 (if approved) October 25, 2010
Intended status: Informational Intended status: Informational
Expires: February 4, 2010 Expires: April 28, 2011
Overview of the Internet Multicast Addressing Architecture 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 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. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on April 28, 2011.
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.
Copyright Notice 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The lack of up-to-date documentation on IP multicast address described in the Simplified BSD License.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3 1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3
2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4
2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4
2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4
2.1.2. Unicast-prefix-based Allocation . . . . . . . . . . . 4 2.1.2. Unicast-prefix-based Allocation . . . . . . . . . . . 4
2.2. Administratively Scoped Allocation . . . . . . . . . . . . 5 2.2. Administratively Scoped Allocation . . . . . . . . . . . . 5
2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6
2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6
3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 7 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6
3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7 3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7
3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7 3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7
3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7 3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7
3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 8 3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 8
3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8 3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8
3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8 3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8
3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8
4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 4. Summary and Future Directions . . . . . . . . . . . . . . . . 9
4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10 4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10
4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11
4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Changes between -05 and -06 . . . . . . . . . . . . . . . 15 A.1. Changes between -06 and -07 . . . . . . . . . . . . . . . 15
A.2. Changes between -04 and -05 . . . . . . . . . . . . . . . 15 A.2. Changes between -05 and -06 . . . . . . . . . . . . . . . 15
A.3. Changes between -03 and -04 . . . . . . . . . . . . . . . 16 A.3. Changes between -04 and -05 . . . . . . . . . . . . . . . 15
A.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 16 A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 16
A.5. Changes between -01 and -02 . . . . . . . . . . . . . . . 16 A.5. Changes between -02 and -03 . . . . . . . . . . . . . . . 16
A.6. Changes between -01 and -02 . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Good, up-to-date documentation of IP multicast is close to non- Good, up-to-date documentation of IP multicast is close to non-
existent. Particularly, this is an issue with multicast address existent. Particularly, this is an issue with multicast address
allocations (to networks and sites) and assignments (to hosts and allocations (to networks and sites) and assignments (to hosts and
applications). This problem is stressed by the fact that there applications). This problem is stressed by the fact that there
exists confusing or misleading documentation on the subject exists confusing or misleading documentation on the subject
[RFC2908]. The consequence is that those who wish to learn about IP [RFC2908]. The consequence is that those who wish to learn about IP
skipping to change at page 5, line 5 skipping to change at page 5, line 5
because the unicast-prefix-based allocation (described below) because the unicast-prefix-based allocation (described below)
addresses the same need in a simpler fashion. addresses the same need in a simpler fashion.
2.1.2. Unicast-prefix-based Allocation 2.1.2. Unicast-prefix-based Allocation
RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 high- 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 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 multicast address, leaving at least 32 bits of group-id space
available after the prefix mapping. available after the prefix mapping.
A similar IPv4 mapping is described in A similar IPv4 mapping is described in [RFC6034], but it provides a
[I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a limited limited number of addresses (e.g., 1 per an IPv4 /24 block).
number of addresses (e.g., 1 per an IPv4 /24 block).
The IPv6 unicast-prefix-based allocations are an extremely useful way The IPv6 unicast-prefix-based allocations are an extremely useful way
to allow each network operator, even each subnet, to obtain multicast to allow each network operator, even each subnet, to obtain multicast
addresses easily, through an easy computation. Further, as the IPv6 addresses easily, through an easy computation. Further, as the IPv6
multicast header also includes the scope value [RFC4291], multicast multicast header also includes the scope value [RFC4291], multicast
groups of smaller scope can also be used with the same mapping. groups of smaller scope can also be used with the same mapping.
The IPv6 Embedded RP technique [RFC3956], used with Protocol The IPv6 Embedded RP technique [RFC3956], used with Protocol
Independent Multicast - Sparse Mode (PIM-SM), further leverages the Independent Multicast - Sparse Mode (PIM-SM), further leverages the
unicast-prefix-based allocations, by embedding the unicast prefix and unicast-prefix-based allocations, by embedding the unicast prefix and
skipping to change at page 6, line 31 skipping to change at page 6, line 29
In some rare cases, organizations may have been able to obtain static In some rare cases, organizations may have been able to obtain static
multicast address allocations (of up to 256 addresses) directly from multicast address allocations (of up to 256 addresses) directly from
IANA. Typically these have been meant as a block of static IANA. Typically these have been meant as a block of static
assignments to multicast applications, as described in Section 3.4.1. assignments to multicast applications, as described in Section 3.4.1.
If another means of obtaining addresses is available that approach is If another means of obtaining addresses is available that approach is
preferable. preferable.
Especially for those operators that only have a 32-bit AS number and 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 need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the
previous so-called "eGLOP" block) is an option previous so-called "eGLOP" block) is an option [RFC5771].
[I-D.ietf-mboned-rfc3171bis].
2.4. Dynamic Allocation 2.4. Dynamic Allocation
RFC 2908 [RFC2908] proposed three different layers of multicast RFC 2908 [RFC2908] proposed three different layers of multicast
address allocation and assignment, where layers 3 (inter-domain address allocation and assignment, where layers 3 (inter-domain
allocation) and layer 2 (intra-domain allocation) could be applicable allocation) and layer 2 (intra-domain allocation) could be applicable
here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an here. Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an
example of the former, and Multicast Address Allocation Protocol example of the former, and Multicast Address Allocation Protocol
(AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest
and technical problems) is an example of the latter. and technical problems) is an example of the latter.
skipping to change at page 8, line 14 skipping to change at page 8, line 11
This is the most commonly used technique when the multicast This is the most commonly used technique when the multicast
application does not have a static IANA assignment. application does not have a static IANA assignment.
3.4. Static IANA Assignment 3.4. Static IANA Assignment
In contrast to manually configured assignment, as described above, In contrast to manually configured assignment, as described above,
static IANA assignment refers to getting an assignment for the static IANA assignment refers to getting an assignment for the
particular application directly from IANA. There are two main forms particular application directly from IANA. There are two main forms
of IANA assignment: global and scope-relative. Guidelines for IANA 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 3.4.1. Global IANA Assignment
Globally unique address assignment is seen as lucrative because it's Globally unique address assignment is seen as lucrative because it's
the simplest approach for application developers since they can then the simplest approach for application developers since they can then
hard-code the multicast address. Hard-coding requires no lease of hard-code the multicast address. Hard-coding requires no lease of
the usable multicast address, and likewise the client applications do the usable multicast address, and likewise the client applications do
not need to perform any kind of service discovery (but depending on not need to perform any kind of service discovery (but depending on
hard-coded addresses). However, there is an architectural scaling hard-coded addresses). However, there is an architectural scaling
problem with this approach, as it encourages a "land-grab" of the problem with this approach, as it encourages a "land-grab" of the
skipping to change at page 13, line 6 skipping to change at page 13, line 6
considerations; the security analysis of the mentioned protocols is considerations; the security analysis of the mentioned protocols is
out of scope of this memo. out of scope of this memo.
Obviously, especially the dynamic assignment protocols are inherently Obviously, especially the dynamic assignment protocols are inherently
vulnerable to resource exhaustion attacks, as discussed e.g., in vulnerable to resource exhaustion attacks, as discussed e.g., in
[RFC2730]. [RFC2730].
8. References 8. References
8.1. Normative 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, [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998. RFC 2365, July 1998.
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
BCP 53, RFC 3180, September 2001. BCP 53, RFC 3180, September 2001.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002. Multicast Addresses", RFC 3306, August 2002.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
skipping to change at page 13, line 43 skipping to change at page 13, line 32
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for [RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for
Generating Link-Scoped IPv6 Multicast Addresses", Generating Link-Scoped IPv6 Multicast Addresses",
RFC 4489, April 2006. RFC 4489, April 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. 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 8.2. Informative References
[I-D.ietf-malloc-aap] [I-D.ietf-malloc-aap]
Handley, M. and S. Hanna, "Multicast Address Allocation Handley, M. and S. Hanna, "Multicast Address Allocation
Protocol (AAP)", June 2000. Protocol (AAP)", June 2000.
[I-D.ietf-mboned-addrdisc-problems] [I-D.ietf-mboned-addrdisc-problems]
Savola, P., "Lightweight Multicast Address Discovery Savola, P., "Lightweight Multicast Address Discovery
Problem Space", draft-ietf-mboned-addrdisc-problems-02 Problem Space", draft-ietf-mboned-addrdisc-problems-02
(work in progress), March 2006. (work in progress), March 2006.
[I-D.ietf-mboned-session-announcement-req] [I-D.ietf-mboned-session-announcement-req]
Asaeda, H. and V. Roca, "Requirements for IP Multicast Asaeda, H. and V. Roca, "Requirements for IP Multicast
Session Announcement in the Internet", Session Announcement",
draft-ietf-mboned-session-announcement-req-01 (work in draft-ietf-mboned-session-announcement-req-03 (work in
progress), March 2009. progress), March 2010.
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]
Durand, J., "IPv6 multicast address assignment with Durand, J., "IPv6 multicast address assignment with
DHCPv6", DHCPv6",
draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work
in progress), February 2005. in progress), February 2005.
[MBONED-IETF59] [MBONED-IETF59]
"MBONED WG session at IETF59", "MBONED WG session at IETF59",
<http://www.ietf.org/proceedings/04mar/172.htm>. <http://www.ietf.org/proceedings/04mar/172.htm>.
skipping to change at page 15, line 18 skipping to change at page 15, line 14
[RITVANEN] [RITVANEN]
Ritvanen, K., "Multicast Routing and Addressing", HUT Ritvanen, K., "Multicast Routing and Addressing", HUT
Report, Seminar on Internetworking, May 2004, Report, Seminar on Internetworking, May 2004,
<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>. <http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
Appendix A. Changes Appendix A. Changes
(To be removed prior to publication as an RFC.) (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 Editorial updates.
o Obsolete only RFC2908; the rest only move to Historic. o Obsolete only RFC2908; the rest only move to Historic.
o Category is Informational instead of BCP (in line with the routing o Category is Informational instead of BCP (in line with the routing
architecture. architecture.
o Move 3171bis and v4-uni-based to Normative references in order to o Move 3171bis and v4-uni-based to Normative references in order to
make sure we don't go forward until they're resolved. make sure we don't go forward until they're resolved.
o Resolve pending issues per IETF75 discussion, in particular major o Resolve pending issues per IETF75 discussion, in particular major
changes to eGLOP and IANA policy discussions. 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 o Editorial updates. These and the following are from Spencer
Dawkins. Dawkins.
o New text explicitly stating that GLOP for v6 is not needed and 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. GLOP for 4byte ASNs isn't (and likely won't be) defined.
o Expand reasons for filtering difficulties with global IANA o Expand reasons for filtering difficulties with global IANA
assignments for local apps, and that it would be easier if these assignments for local apps, and that it would be easier if these
were done from the local pool. were done from the local pool.
o Explicitly mention dynamic allocations protocols' lack of benefit o Explicitly mention dynamic allocations protocols' lack of benefit
and abandonment. 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 o S/scope-relative/administratively scoped/ and expand Static IANA
Assignment section to two subsections; mainly from Dave Price. Assignment section to two subsections; mainly from Dave Price.
o Mention the routing challenges of IPv6 IANA assigned prefixes in o Mention the routing challenges of IPv6 IANA assigned prefixes in
section 4.2 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 o Reword architectural implications of Static IANA and editorial
improvements; mainly from John Kristoff. 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 o Mention the mechanisms which haven't been so successful: eGLOP and
MZAP. MZAP.
o Remove the appendices on multicast address discovery (a separate o Remove the appendices on multicast address discovery (a separate
draft now) and IPv4 unicast-prefix-based multicast addressing. draft now) and IPv4 unicast-prefix-based multicast addressing.
o Add a note on administratively scoped address space and the o Add a note on administratively scoped address space and the
expansion ambiguity. expansion ambiguity.
 End of changes. 21 change blocks. 
58 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/