draft-ietf-mboned-addrarch-07.txt   rfc6308.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force (IETF) P. Savola
Internet-Draft CSC/FUNET Request for Comments: 6308 CSC/FUNET
Obsoletes: 2908 (if approved) October 25, 2010 Obsoletes: 2908 June 2011
Intended status: Informational Category: Informational
Expires: April 28, 2011 ISSN: 2070-1721
Overview of the Internet Multicast Addressing Architecture Overview of the Internet Multicast Addressing Architecture
draft-ietf-mboned-addrarch-07.txt
Abstract Abstract
The lack of up-to-date documentation on IP multicast address The lack of up-to-date documentation on IP multicast address
allocation and assignment procedures has caused a great deal of allocation and assignment procedures has caused a great deal of
confusion. To clarify the situation, this memo describes the confusion. To clarify the situation, this memo describes the
allocation and assignment techniques and mechanisms currently (as of allocation and assignment techniques and mechanisms currently (as of
this writing) in use. this writing) in use.
Status of this Memo Status of This Memo
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 This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 28, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6308.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Terminology: Allocation or Assignment . . . . . . . . . . 3 1.1. Terminology: Allocation or Assignment ......................3
2. Multicast Address Allocation . . . . . . . . . . . . . . . . . 4 2. Multicast Address Allocation ....................................3
2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 2.1. Derived Allocation .........................................3
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 . . . . . . . . . . . . . . . . . 6 3. Multicast Address Assignment ....................................6
3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7 3.1. Derived Assignment .........................................6
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 .....................................7
3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8 3.4.1. Global IANA Assignment ..............................7
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 ..........................................9
4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 4.2. Address Assignment ........................................10
4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Future Actions ............................................11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements ...............................................11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations ............................................11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations ........................................11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References .....................................................12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References ......................................12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References ....................................13
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15
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 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
existent. Particularly, this is an issue with multicast address non-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
multicast and how the addressing works do not get a clear view of the multicast and how the addressing works do not get a clear view of the
current situation. current situation.
The aim of this document is to provide a brief overview of multicast The aim of this document is to provide a brief overview of multicast
addressing and allocation techniques. The term 'addressing addressing and allocation techniques. The term "addressing
architecture' refers to the set of addressing mechanisms and methods architecture" refers to the set of addressing mechanisms and methods
in an informal manner. in an informal manner.
It is important to note that Source-specific Multicast (SSM) It is important to note that Source-Specific Multicast (SSM)
[RFC4607] does not have these addressing problems because SSM group [RFC4607] does not have these addressing problems because SSM group
addresses have only local significance; hence, this document focuses addresses have only local significance; hence, this document focuses
on the Any Source Multicast (ASM) model. on the Any Source Multicast (ASM) model.
This memo obsoletes and re-classifies to Historic RFC 2908, and re- This memo obsoletes and re-classifies RFC 2908 to Historic, and
classifies to Historic RFCs 2776 and 2909. re-classifies RFCs 2776 and 2909 to Historic.
1.1. Terminology: Allocation or Assignment 1.1. Terminology: Allocation or Assignment
Almost all multicast documents and many other RFCs (such as DHCPv4 Almost all multicast documents and many other RFCs (such as DHCPv4
[RFC2131] and DHCPv6 [RFC3315]) have used the terms address [RFC2131] and DHCPv6 [RFC3315]) have used the terms "address
"allocation" and "assignment" interchangeably. However, the operator allocation" and "address assignment" interchangeably. However, the
and address management communities use these terms for two operator and address management communities use these terms for two
conceptually different processes. conceptually different processes.
In unicast operations, address allocations refer to leasing a large In unicast operations, address allocations refer to leasing a large
block of addresses from Internet Assigned Numbers Authority (IANA) to block of addresses from the Internet Assigned Numbers Authority
a Regional Internet Registry (RIR) or from RIR to a Local Internet (IANA) to a Regional Internet Registry (RIR), or from an RIR to a
Registry (LIR) possibly through a National Internet Registry (NIR). Local Internet Registry (LIR), possibly through a National Internet
Address assignments, on the other hand, are the leases of smaller Registry (NIR). Address assignments, on the other hand, are the
address blocks or even single addresses to the end-user sites or end- leases of smaller address blocks or even single addresses to the end-
users themselves. user sites or end-users themselves.
Therefore, in this memo, we will separate the two different Therefore, in this memo, we will separate the two different
functions: "allocation" describes how larger blocks of addresses are functions: "allocation" describes how larger blocks of addresses are
obtained by the network operators, and "assignment" describes how obtained by the network operators, and "assignment" describes how
applications, nodes or sets of nodes obtain a multicast address for applications, nodes, or sets of nodes obtain a multicast address for
their use. their use.
2. Multicast Address Allocation 2. Multicast Address Allocation
Multicast address allocation, i.e., how a network operator might be Multicast address allocation, i.e., how a network operator might be
able to obtain a larger block of addresses, can be handled in a able to obtain a larger block of addresses, can be handled in a
number of ways as described below. number of ways, as described below.
Note that these are all only pertinent to ASM -- SSM requires no Note that these are all only pertinent to ASM -- SSM requires no
address block allocation because the group address has only local address block allocation because the group address has only local
significance (however, we discuss the address assignment inside the significance (however, we discuss the address assignment inside the
node in Section 3.2). node in Section 3.2).
2.1. Derived Allocation 2.1. Derived Allocation
Derived allocations take the unicast prefix or some other properties Derived allocations take the unicast prefix or some other properties
of the network (e.g., an autonomous system (AS) number) to determine of the network (e.g., an autonomous system (AS) number) to determine
unique multicast address allocations. unique multicast address allocations.
2.1.1. GLOP Allocation 2.1.1. GLOP Allocation
GLOP address allocation [RFC3180] inserts the 16-bit public AS number GLOP address allocation [RFC3180] inserts the 16-bit public AS number
in the middle of the IPv4 multicast prefix 233.0.0.0/8, so that each in the middle of the IPv4 multicast prefix 233.0.0.0/8, so that each
AS number can get a /24 worth of multicast addresses. While this is AS number can get a /24 worth of multicast addresses. While this is
sufficient for multicast testing or small scale use, it might not be sufficient for multicast testing or small-scale use, it might not be
sufficient in all cases for extensive multicast use. sufficient in all cases for extensive multicast use.
A minor operational debugging issue with GLOP addresses is that the A minor operational debugging issue with GLOP addresses is that the
connection between the AS and the prefix is not apparent from the connection between the AS and the prefix is not apparent from the
prefix when the AS number is greater than 255, but has to be prefix when the AS number is greater than 255, but has to be
calculated (e.g., from [RFC3180], AS 5662 maps to 233.22.30.0/24). A calculated (e.g., as described in [RFC3180], AS 5662 maps to
usage issue is that GLOP addresses are not tied to any prefix but to 233.22.30.0/24). A usage issue is that GLOP addresses are not tied
routing domains, so they cannot be used or calculated automatically. to any prefix but to routing domains, so they cannot be used or
calculated automatically.
GLOP mapping is not available with 4-byte AS numbers [RFC4893]. GLOP mapping is not available with 4-byte AS numbers [RFC4893].
Unicast-prefix-based Allocation or an IANA allocation from "AD-HOC Unicast-prefix-based allocation or an IANA allocation from "AD-HOC
Block III" (the previous so-called "eGLOP" block) could be used Block III" (the previous so-called "EGLOP" (Extended GLOP) block)
instead as needed. could be used instead, as needed.
The GLOP allocation algorithm has not been defined for IPv6 multicast The GLOP allocation algorithm has not been defined for IPv6 multicast
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 that 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 [RFC6034], but it provides a A similar IPv4 mapping is described in [RFC6034], but it provides a
limited number of addresses (e.g., 1 per an IPv4 /24 block). limited number of addresses (e.g., 1 per 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 Rendezvous Point (RP) technique [RFC3956], used
Independent Multicast - Sparse Mode (PIM-SM), further leverages the with Protocol Independent Multicast - Sparse Mode (PIM-SM), further
unicast-prefix-based allocations, by embedding the unicast prefix and leverages the unicast-prefix-based allocations, by embedding the
interface identifier of the PIM-SM Rendezvous Point (RP) in the unicast prefix and interface identifier of the PIM-SM RP in the
prefix. This provides all the necessary information needed to the prefix. This provides all the necessary information needed to the
routing systems to run the group in either inter- or intra-domain routing systems to run the group in either inter- or intra-domain
operation. A difference from RFC 3306 is, however, that the hosts operation. A difference from RFC 3306 is, however, that the hosts
cannot calculate their "multicast prefix" automatically, as the cannot calculate their "multicast prefix" automatically (as the
prefix depends on the decisions of the operator setting up the RP, prefix depends on the decisions of the operator setting up the RP),
but instead requires an assignment method. but instead require an assignment method.
All the IPv6 unicast-prefix-based allocation techniques provide All the IPv6 unicast-prefix-based allocation techniques provide a
sufficient amount of multicast address space for network operators. sufficient amount of multicast address space for network operators.
2.2. Administratively Scoped Allocation 2.2. Administratively Scoped Allocation
Administratively scoped multicast address allocation [RFC2365] is Administratively scoped multicast address allocation [RFC2365] is
provided by two different means: under 239.0.0.0/8 in IPv4 or by provided by two different means: under 239.0.0.0/8 in IPv4 or by
4-bit encoding in the IPv6 multicast address prefix [RFC4291]. 4-bit encoding in the IPv6 multicast address prefix [RFC4291].
Since IPv6 administratively scoped allocations can be handled with Since IPv6 administratively scoped allocations can be handled with
unicast-prefix-based multicast addressing as described in unicast-prefix-based multicast addressing as described in
Section 2.1.2, we'll only discuss IPv4 in this section. Section 2.1.2, we'll only discuss IPv4 in this section.
The IPv4 administratively scoped prefix 239.0.0.0/8 is further The IPv4 administratively scoped prefix 239.0.0.0/8 is further
divided into Local Scope (239.255.0.0/16) and Organization Local divided into Local Scope (239.255.0.0/16) and Organization Local
Scope (239.192.0.0/14); other parts of the administrative scopes are Scope (239.192.0.0/14); other parts of the administrative scopes are
either reserved for expansion or undefined [RFC2365]. However, RFC either reserved for expansion or undefined [RFC2365]. However,
2365 is ambiguous as to whether the enterprises or the IETF are RFC 2365 is ambiguous as to whether the enterprises or the IETF are
allowed to expand the space. allowed to expand the space.
Topologies which act under a single administration can easily use the Topologies that act under a single administration can easily use the
scoped multicast addresses for their internal groups. Groups which scoped multicast addresses for their internal groups. Groups that
need to be shared between multiple routing domains (even if not need to be shared between multiple routing domains (even if not
propagated through the Internet) are more problematic and typically propagated through the Internet) are more problematic and typically
need an assignment of a global multicast address because their scope need an assignment of a global multicast address because their scope
is undefined. is undefined.
There is a large number of multicast applications (such as "Norton There are a large number of multicast applications (such as "Norton
Ghost") which are restricted either to a link or a site, and it is Ghost") that are restricted either to a link or a site, and it is
extremely undesirable to propagate them further (beyond the link or extremely undesirable to propagate them further (beyond the link or
the site). Typically many such applications have been given or have the site). Typically, many such applications have been given or have
hijacked a static IANA address assignment. Given the fact that hijacked a static IANA address assignment. Given the fact that
assignments to typically locally used applications come from the same assignments to typically locally used applications come from the same
range as global applications, implementing proper propagation range as global applications, implementing proper propagation
limiting is challenging. Filtering would be easier if a separate, limiting is challenging. Filtering would be easier if a separate,
identifiable range would be used for such assignments in the future; identifiable range would be used for such assignments in the future;
this is an area of further future work. this is an area of further future work.
There has also been work on a protocol to automatically discover There has also been work on a protocol to automatically discover
multicast scope zones [RFC2776], but it has never been widely multicast scope zones [RFC2776], but it has never been widely
implemented or deployed. implemented or deployed.
2.3. Static IANA Allocation 2.3. Static IANA Allocation
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
preferable. is 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 [RFC5771]. previous so-called "EGLOP" block) is an option [RFC5771].
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 layer 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. The Multicast Address-Set Claim Protocol (MASC) [RFC2909] is
example of the former, and Multicast Address Allocation Protocol an example of the former, and the Multicast Address Allocation
(AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest Protocol (AAP) [MALLOC-AAP] (abandoned in 2000 due to lack of
and technical problems) is an example of the latter. interest and technical problems) is an example of the latter.
Both of the proposed allocation protocols were quite complex, and Both of the proposed allocation protocols were quite complex, and
have never been deployed or seriously implemented. have never been deployed or seriously implemented.
It can be concluded that dynamic multicast address allocation It can be concluded that dynamic multicast address allocation
protocols provide no benefit beyond GLOP/unicast-prefix-based protocols provide no benefit beyond GLOP/unicast-prefix-based
mechanisms and have been abandoned. mechanisms and have been abandoned.
3. Multicast Address Assignment 3. Multicast Address Assignment
There are a number of possible ways for an application, node or set There are a number of possible ways for an application, node, or set
of nodes to learn a multicast address as described below. of nodes to learn a multicast address, as described below.
Any IPv6 address assignment method should be aware of the guidelines Any IPv6 address assignment method should be aware of the guidelines
for the assignment of group-IDs for IPv6 multicast addresses for the assignment of group-IDs for IPv6 multicast addresses
[RFC3307]. [RFC3307].
3.1. Derived Assignment 3.1. Derived Assignment
There are significantly fewer options for derived address assignment There are significantly fewer options for derived address assignment
compared to derived allocation. Derived multicast assignment has compared to derived allocation. Derived multicast assignment has
only been specified for IPv6 link-scoped multicast [RFC4489], where only been specified for IPv6 link-scoped multicast [RFC4489], where
the EUI64 is embedded in the multicast address, providing a node with the EUI64 is embedded in the multicast address, providing a node with
unique multicast addresses for link-local ASM communications. unique multicast addresses for link-local ASM communications.
3.2. SSM Assignment inside the Node 3.2. SSM Assignment inside the Node
While SSM multicast addresses have only local (to the node) While SSM multicast addresses have only local (to the node)
significance, there is still a minor issue on how to assign the significance, there is still a minor issue on how to assign the
addresses between the applications running on the same IP address. addresses between the applications running on the same IP address.
This assignment is not considered to be a problem because typically This assignment is not considered to be a problem, because typically
the addresses for these applications are selected manually or the addresses for these applications are selected manually or
statically, but if done using an Application Programming Interface statically, but if done using an Application Programming Interface
(API), the API could check that the addresses do not conflict prior (API), the API could check that the addresses do not conflict prior
to assigning one. to assigning one.
3.3. Manually Configured Assignment 3.3. Manually Configured Assignment
With manually configured assignment, a network operator who has a With manually configured assignment, a network operator who has a
multicast address prefix assigns the multicast group addresses to the multicast address prefix assigns the multicast group addresses to the
requesting nodes using a manual process. requesting nodes using a manual process.
Typically, the user or administrator that wants to use a multicast Typically, the user or administrator that wants to use a multicast
address for a particular application requests an address from the address for a particular application requests an address from the
network operator using phone, email, or similar means, and the network operator using phone, email, or similar means, and the
network operator provides the user with a multicast address. Then network operator provides the user with a multicast address. Then
the user/administrator of the node or application manually configures the user/administrator of the node or application manually configures
the application to use the assigned multicast address. the application to use the assigned multicast address.
This is a relatively simple process; it has been sufficient for This is a relatively simple process; it has been sufficient for
certain applications which require manual configuration in any case, certain applications that require manual configuration in any case,
or which cannot or do not want to justify a static IANA assignment. or that cannot or do not want to justify a static IANA assignment.
The manual assignment works when the number of participants in a The manual assignment works when the number of participants in a
group is small, as each participant has to be manually configured. group is small, as each participant has to be manually configured.
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 [RFC5771]. 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 depend 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
limited multicast address space. limited multicast address space.
3.4.2. Scope-relative IANA Assignment 3.4.2. Scope-Relative IANA Assignment
IANA also assigns numbers as an integer offset from the highest IANA also assigns numbers as an integer offset from the highest
address in each IPv4 administrative scope as described in [RFC2365]. address in each IPv4 administrative scope, as described in [RFC2365].
For example, the SLPv2 discovery scope-relative offset is "2", so For example, the SLPv2 discovery scope-relative offset is "2", so the
SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is
"239.255.255.253", within the IPv4 Organization Local-Scope "239.255.255.253"; within the IPv4 Organization Local-Scope
(239.192.0.0/14) it is "239.195.255.253", and so on. (239.192.0.0/14), it is "239.195.255.253"; and so on.
Similar scope-relative assignments also exist with IPv6 [RFC2375]. Similar scope-relative assignments also exist with IPv6 [RFC2375].
As IPv6 multicast addresses have much more flexible scoping, scope- As IPv6 multicast addresses have much more flexible scoping, scope-
relative assignments are also applicable to global scopes. The relative assignments are also applicable to global scopes. The
assignment policies are described in [RFC3307]. assignment policies are described in [RFC3307].
3.5. Dynamic Assignments 3.5. Dynamic Assignments
The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from Layer 1 as defined in RFC 2908 [RFC2908] described dynamic assignment
Multicast Address Allocation Servers (MAAS) to applications and from Multicast Address Allocation Servers (MAAS) to applications and
nodes, with Multicast Address Dynamic Client Allocation Protocol nodes, with the Multicast Address Dynamic Client Allocation Protocol
(MADCAP) [RFC2730] as an example. Since then, other mechanisms have (MADCAP) [RFC2730] as an example. Since then, other mechanisms have
also been proposed (e.g., DHCPv6 assignment also been proposed (e.g., DHCPv6 assignment
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]) but these have not [MCAST-DHCPv6]), but these have not gained traction.
gained traction.
It would be rather straightforward to deploy a dynamic assignment It would be rather straightforward to deploy a dynamic assignment
protocol which would lease group addresses based on a multicast protocol that would lease group addresses based on a multicast prefix
prefix to applications wishing to use multicast. However, only few to applications wishing to use multicast. However, only few have
have implemented MADCAP, and it hasn't been significantly deployed. implemented MADCAP (i.e., it is not significantly deployed). It is
So, it is not clear if the lack of deployment is due to a currently not clear if the sparse deployment is due to a lack of need for the
missing need. Moreover, it is not clear how widely for example the protocol. Moreover, it is not clear how widely, for example, the
APIs for communication between the multicast application and the APIs for communication between the multicast application and the
MADCAP client operating at the host have been implemented [RFC2771]. MADCAP client operating at the host have been implemented [RFC2771].
An entirely different approach is Session Announcement Protocol (SAP) An entirely different approach is the Session Announcement Protocol
[RFC2974]. In addition to advertising global multicast sessions, the (SAP) [RFC2974]. In addition to advertising global multicast
protocol also has associated ranges of addresses for both IPv4 and sessions, the protocol also has associated ranges of addresses for
IPv6 which can be used by SAP-aware applications to create new groups both IPv4 and IPv6 that can be used by SAP-aware applications to
and new group addresses. Creating a session (and obtaining an create new groups and new group addresses. Creating a session (and
address) is a rather tedious process which is why it isn't done all obtaining an address) is a rather tedious process, which is why it
that often. It is also worth noting that the IPv6 SAP address is isn't done all that often. It is also worth noting that the IPv6 SAP
unroutable in the inter-domain multicast. address is unroutable in the inter-domain multicast.
A conclusion about dynamic assignment protocols is that: Conclusions about dynamic assignment protocols are that:
1. multicast is not significantly attractive in the first place, 1. multicast is not significantly attractive in the first place,
2. most applications have a static IANA assignment and thus require 2. most applications have a static IANA assignment and thus require
no dynamic or manual assignment, no dynamic or manual assignment,
3. those that cannot be easily satisfied with IANA or manual 3. those applications that cannot be easily satisfied with IANA or
assignment (i.e., where dynamic assignment would be desirable) manual assignment (i.e., where dynamic assignment would be
are rather marginal, or desirable) are rather marginal, or
4. that there are other gaps why dynamic assignments are not seen as 4. there are other reasons why dynamic assignments are not seen as a
a useful approach (for example, issues related to service useful approach (for example, issues related to service
discovery/rendezvous). discovery/rendezvous).
In consequence, more work on rendezvous/service discovery would be In consequence, more work on rendezvous/service discovery would be
needed to make dynamic assignments more useful. needed to make dynamic assignments more useful.
4. Summary and Future Directions 4. Summary and Future Directions
This section summarizes the mechanisms and analysis discussed in this This section summarizes the mechanisms and analysis discussed in this
memo, and presents some potential future directions. memo, and presents some potential future directions.
4.1. Prefix Allocation 4.1. Prefix Allocation
A summary of prefix allocation methods for ASM is shown in Figure 1. A summary of prefix allocation methods for ASM is shown in Figure 1.
+-------+--------------------------------+--------+--------+ +-------+--------------------------------+--------+--------+
| Sect. | Prefix allocation method | IPv4 | IPv6 | | Sect. | Prefix allocation method | IPv4 | IPv6 |
+-------+--------------------------------+--------+--------+ +-------+--------------------------------+--------+--------+
| 2.1.1 | Derived: GLOP | Yes | NoNeed*| | 2.1.1 | Derived: GLOP | Yes | NoNeed*|
| 2.1.2 | Derived: Unicast-prefix-based | No | Yes | | 2.1.2 | Derived: Unicast-prefix-based | No | Yes |
| 2.2 | Administratively scoped | Yes | NoNeed*| | 2.2 | Administratively scoped | Yes | NoNeed*|
| 2.3 | Static IANA allocation | Yes** | No | | 2.3 | Static IANA allocation | Yes** | No |
| 2.4 | Dynamic allocation protocols | No | No | | 2.4 | Dynamic allocation protocols | No | No |
+-------+--------------------------------+--------+--------+ +-------+--------------------------------+--------+--------+
* = the need satisfied by IPv6 unicast-prefix-based allocation. * = the need satisfied by IPv6 unicast-prefix-based allocation
** = mainly using the AD-HOC block III (former "eGLOP") ** = mainly using the AD-HOC block III (formerly called "EGLOP")
Figure 1 Figure 1
o Only ASM is affected by the assignment/allocation issues. o Only ASM is affected by the assignment/allocation issues.
o With IPv4, GLOP allocations provide a sufficient IPv4 multicast o With IPv4, GLOP allocations provide a sufficient IPv4 multicast
allocation mechanism for those that have 16-bit AS number. IPv4 allocation mechanism for those that have a 16-bit AS number. IPv4
unicast-prefix based allocation offers some addresses. IANA is unicast-prefix-based allocation offers some addresses. IANA is
also allocating from the AD-HOC block III (former "eGLOP") with also allocating from the AD-HOC block III (formerly called
especially 32-bit AS number holders in mind. Administratively "EGLOP"), especially with 32-bit AS number holders in mind.
scoped allocations provide the opportunity for internal IPv4 Administratively scoped allocations provide the opportunity for
allocations. internal IPv4 allocations.
o With IPv6, unicast-prefix-based addresses and the derivatives o With IPv6, unicast-prefix-based addresses and the derivatives
provide a good allocation strategy and this also works for scoped provide a good allocation strategy, and this also works for scoped
multicast addresses. multicast addresses.
o Dynamic allocations are too complex and unnecessary a mechanism. o Dynamic allocations are too complex and unnecessary a mechanism.
4.2. Address Assignment 4.2. Address Assignment
A summary of address assignment methods is shown in Figure 2. A summary of address assignment methods is shown in Figure 2.
+--------+--------------------------------+----------+----------+ +--------+--------------------------------+----------+----------+
| Sect. | Address assignment method | IPv4 | IPv6 | | Sect. | Address assignment method | IPv4 | IPv6 |
skipping to change at page 11, line 26 skipping to change at page 10, line 42
| 3.4.2 | Scope-relative IANA assignment | Yes | Yes | | 3.4.2 | Scope-relative IANA assignment | Yes | Yes |
| 3.5 | Dynamic assignment protocols | Yes | Yes | | 3.5 | Dynamic assignment protocols | Yes | Yes |
+--------+--------------------------------+----------+----------+ +--------+--------------------------------+----------+----------+
Figure 2 Figure 2
o Manually configured assignment is typical today, and works to a o Manually configured assignment is typical today, and works to a
sufficient degree in smaller scale. sufficient degree in smaller scale.
o Global IANA assignment has been done extensively in the past. o Global IANA assignment has been done extensively in the past.
Scope-relative IANA assignment is acceptable but the size of the Scope-relative IANA assignment is acceptable, but the size of the
pool is not very high. Inter-domain routing of IPv6 IANA-assigned pool is not very high. Inter-domain routing of IPv6 IANA-assigned
prefixes is likely going to be challenging and as a result that prefixes is likely going to be challenging, and as a result that
approach is not very appealing. approach is not very appealing.
o Dynamic assignment, e.g., MADCAP has been implemented, but there o Dynamic assignment, e.g., MADCAP, has been implemented, but there
is no wide deployment. Therefore, either there are other gaps in is no wide deployment. Therefore, either there are other gaps in
the multicast architecture or there is no sufficient demand for it the multicast architecture, or there is no sufficient demand for
in the first place when manual and static IANA assignments are it in the first place when manual and static IANA assignments are
available. Assignments using SAP also exist but are not common; available. Assignments using SAP also exist but are not common;
global SAP assignment is unfeasible with IPv6. global SAP assignment is infeasible with IPv6.
o Derived assignments are only applicable in a fringe case of link- o Derived assignments are only applicable in a fringe case of link-
scoped multicast. scoped multicast.
4.3. Future Actions 4.3. Future Actions
o Multicast address discovery/"rendezvous" needs to be analyzed at o Multicast address discovery/"rendezvous" needs to be analyzed at
more length, and an adequate solution provided. See more length, and an adequate solution provided. See
[I-D.ietf-mboned-addrdisc-problems] and [ADDRDISC-PROB] and [MSA-REQ] for more information.
[I-D.ietf-mboned-session-announcement-req] for more.
o The IETF should consider whether to specify more ranges of the o The IETF should consider whether to specify more ranges of the
IPv4 administratively scoped address space for static allocation IPv4 administratively scoped address space for static allocation
for applications which should not be routed over the Internet for applications that should not be routed over the Internet (such
(such as backup software, etc. -- so that these wouldn't need to as backup software, etc. -- so that these wouldn't need to use
use global addresses which should never leak in any case). global addresses, which should never leak in any case).
o The IETF should consider its static IANA allocations policy, e.g., o The IETF should consider its static IANA allocations policy, e.g.,
"locking it down" to a stricter policy (like "IETF Consensus") and "locking it down" to a stricter policy (like "IETF Consensus") and
looking at developing the discovery/rendezvous functions, if looking at developing the discovery/rendezvous functions, if
necessary. necessary.
5. Acknowledgements 5. Acknowledgements
Tutoring a couple of multicast-related papers, the latest by Kaarle Tutoring a couple of multicast-related papers, the latest by Kaarle
Ritvanen [RITVANEN] convinced the author that updated multicast Ritvanen [RITVANEN], convinced the author that updated multicast
address assignment/allocation documentation is needed. address assignment/allocation documentation is needed.
Multicast address allocations/assignments were discussed at the Multicast address allocations/assignments were discussed at the
MBONED WG session at IETF59 [MBONED-IETF59]. MBONED WG session at IETF 59 [MBONED-IETF59].
Dave Thaler, James Lingard, and Beau Williamson provided useful Dave Thaler, James Lingard, and Beau Williamson provided useful
feedback for the preliminary version of this memo. Myung-Ki Shin, feedback for the preliminary version of this memo. Myung-Ki Shin,
Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred
Hoenes also suggested improvements. Hoenes also suggested improvements.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. IANA considerations in Sections 4.1.1 and 4.1.2 of obsoleted and now
Historic [RFC2908] were never implemented in the IANA registry.
IANA considerations in sections 4.1.1 and 4.1.2 of obsoleted and now
Historic [RFC2908] were never implemented in IANA registry. No
update is necessary.
(RFC-editor: This section may be removed prior to publication;
alternatively, the second paragraph may be left intact.)
7. Security Considerations 7. Security Considerations
This memo only describes different approaches to allocating and This memo only describes different approaches to allocating and
assigning multicast addresses, and this has no security assigning multicast addresses, and this has no security
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, the dynamic assignment protocols in particular are
vulnerable to resource exhaustion attacks, as discussed e.g., in inherently vulnerable to resource exhaustion attacks, as discussed,
[RFC2730]. e.g., in [RFC2730].
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, [RFC2365] Meyer, D., "Administratively Scoped IP Multicast",
RFC 2365, July 1998. BCP 23, 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
Addresses", RFC 3307, August 2002. Addresses", RFC 3307, August 2002.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
[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 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines
IPv4 Multicast Address Assignments", BCP 51, RFC 5771, for IPv4 Multicast Address Assignments", BCP 51,
March 2010. RFC 5771, March 2010.
[RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast [RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast
Addresses", RFC 6034, October 2010. Addresses", RFC 6034, October 2010.
8.2. Informative References 8.2. Informative References
[I-D.ietf-malloc-aap] [ADDRDISC-PROB]
Handley, M. and S. Hanna, "Multicast Address Allocation Savola, P., "Lightweight Multicast Address Discovery
Protocol (AAP)", June 2000. Problem Space", Work in Progress, March 2006.
[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",
draft-ietf-mboned-session-announcement-req-03 (work in
progress), March 2010.
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6] [MALLOC-AAP]
Durand, J., "IPv6 multicast address assignment with Handley, M. and S. Hanna, "Multicast Address Allocation
DHCPv6", Protocol (AAP)", Work in Progress, June 2000.
draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work
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>.
[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.
[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.
[RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
Zone Announcement Protocol (MZAP)", RFC 2776,
February 2000.
[RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet
Multicast Address Allocation Architecture", RFC 2908,
September 2000.
[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
Kumar, S., and D. Thaler, "The Multicast Address-Set Claim
(MASC) Protocol", RFC 2909, September 2000.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007.
[RITVANEN]
Ritvanen, K., "Multicast Routing and Addressing", HUT
Report, Seminar on Internetworking, May 2004,
<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
Appendix A. Changes
(To be removed prior to publication as an RFC.)
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.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 [MCAST-DHCPv6]
assignments for local apps, and that it would be easier if these Durand, J., "IPv6 multicast address assignment with
were done from the local pool. DHCPv6", Work in Progress, February 2005.
o Explicitly mention dynamic allocations protocols' lack of benefit [MSA-REQ] Asaeda, H. and V. Roca, "Requirements for IP Multicast
and abandonment. Session Announcement", Work in Progress, March 2010.
A.4. Changes between -03 and -04 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
o S/scope-relative/administratively scoped/ and expand Static IANA [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignment section to two subsections; mainly from Dave Price. Assignments", RFC 2375, July 1998.
o Mention the routing challenges of IPv6 IANA assigned prefixes in [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
section 4.2 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
December 1999.
A.5. Changes between -02 and -03 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address
Allocation", RFC 2771, February 2000.
o Reword architectural implications of Static IANA and editorial [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
improvements; mainly from John Kristoff. Zone Announcement Protocol (MZAP)", RFC 2776, February
2000.
A.6. Changes between -01 and -02 [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet
Multicast Address Allocation Architecture", RFC 2908,
September 2000.
o Mention the mechanisms which haven't been so successful: eGLOP and [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
MZAP. Kumar, S., and D. Thaler, "The Multicast Address-Set
Claim (MASC) Protocol", RFC 2909, September 2000.
o Remove the appendices on multicast address discovery (a separate [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
draft now) and IPv4 unicast-prefix-based multicast addressing. Announcement Protocol", RFC 2974, October 2000.
o Add a note on administratively scoped address space and the [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
expansion ambiguity. C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003.
o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007.
o Minor editorial cleanups. [RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT
Report, Seminar on Internetworking, May 2004,
<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
Author's Address Author's Address
Pekka Savola Pekka Savola
CSC - Scientific Computing Ltd. CSC - Scientific Computing Ltd.
Espoo Espoo
Finland Finland
Email: psavola@funet.fi EMail: psavola@funet.fi
 End of changes. 91 change blocks. 
323 lines changed or deleted 233 lines changed or added

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