draft-ietf-mboned-addrarch-01.txt   draft-ietf-mboned-addrarch-02.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: 2908,2909 (if approved) February 18, 2005 Obsoletes: 2776,2908,2909 (if August 8, 2005
Expires: August 19, 2005 approved)
Expires: February 9, 2006
Overview of the Internet Multicast Addressing Architecture Overview of the Internet Multicast Addressing Architecture
draft-ietf-mboned-addrarch-01.txt draft-ietf-mboned-addrarch-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 19, 2005. This Internet-Draft will expire on February 9, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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.
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 . . . . . . . . . . . . . . . . . 3
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 Scope-relative Allocation . . . . . . . . . . . . . . . . 5 2.2 Scope-relative 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 . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 7 3.4 Static IANA Assignment . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . 9 4.1 Prefix Allocation . . . . . . . . . . . . . . . . . . . . 9
4.2 Address Assignment . . . . . . . . . . . . . . . . . . . . 10 4.2 Address Assignment . . . . . . . . . . . . . . . . . . . . 10
4.3 Future Actions . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Future Actions . . . . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12
8.2 Informative References . . . . . . . . . . . . . . . . . . 12 8.2 Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
A. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
B. Multicast Address Discovery . . . . . . . . . . . . . . . . . 15 A.1 Changes since -01 . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 16
1. Introduction 1. Introduction
Good, up-to-date documentation of IP multicast is close to Good, up-to-date documentation of IP multicast is close to non-
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 of IP [RFC2908]. The consequence is that those who wish to learn of IP
multicast and how the addressing works do not get a clear view of the 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)
[I-D.ietf-ssm-arch] does not have these addressing problems; hence, [I-D.ietf-ssm-arch] does not have these addressing problems; hence,
this document focuses on Any Source Multicast (ASM) model. The this document focuses on Any Source Multicast (ASM) model.
applicability of SSM has been briefly discussed in
[I-D.ietf-mboned-ipv6-multicast-issues].
This memo obsoletes RFC 2908 and RFC 2909 and re-classifies them This memo obsoletes RFCs 2776, 2908, and 2909 and re-classifies them
Historic. 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 "assignment" interchangeably. However, the operator
and address management communities use these for two conceptually and address management communities use these for two conceptually
different processes. 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 Internet Assigned Numbers Authority (IANA) to
a Regional Internet Registry (RIR), from RIR to a Local Internet a Regional Internet Registry (RIR) or from RIR to a Local Internet
Registry (LIR) possibly through a National Internet Registry (NIR). Registry (LIR) possibly through a National Internet Registry (NIR).
Address assignments, on the other hand, are the leases of smaller Address assignments, on the other hand, are the leases of smaller
address blocks or even single addresses to the end-user sites or address blocks or even single addresses to the end-user sites or end-
end-users themselves. 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, the address assignment inside the node is significance (however, we discuss the address assignment inside the
still an issue discussed 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 to determine unique multicast address allocations. of the network to determine unique multicast address allocations.
2.1.1 GLOP Allocation 2.1.1 GLOP Allocation
GLOP address allocation [RFC3180] inserts the 16-bit public GLOP address allocation [RFC3180] inserts the 16-bit public
Autonomous System (AS) number in the middle of the IPv4 multicast Autonomous System (AS) number in the middle of the IPv4 multicast
skipping to change at page 4, line 44 skipping to change at page 4, line 40
tied to any prefix but to routing domains, so they cannot be used or tied to any prefix but to routing domains, so they cannot be used or
calculated automatically. calculated automatically.
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 first RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 first
bits of an IPv6 unicast address in the prefix part of the IPv6 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 mapping has been proposed for IPv4 A similar mapping has been proposed for IPv4 [I-D.ietf-mboned-ipv4-
[I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low uni-based-mcast], but it provides a rather low amount of addresses
amount of addresses (e.g., 1 per an IPv4 /24 block). While there (e.g., 1 per an IPv4 /24 block). While there exist large networks
exist large networks without an AS number of their own, this has not without an AS number of their own, this has not been seen to add
been seen to add sufficient value compared to GLOP addressing. sufficient value compared to GLOP addressing.
The IPv6 unicast-prefix -based allocations are an extremely useful The IPv6 unicast-prefix -based allocations are an extremely useful
way to allow each network operator, even each subnet, obtain way to allow each network operator, even each subnet, obtain
multicast addresses easily, through an easy computation. Further, as multicast addresses easily, through an easy computation. Further, as
the IPv6 multicast header also includes the scope value [RFC3513], the IPv6 multicast header also includes the scope value [RFC3513],
multicast groups of smaller scope can also be used with the same multicast groups of smaller scope can also be used with the same
mapping. 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
skipping to change at page 5, line 37 skipping to change at page 5, line 34
the IPv6 multicast address prefix [RFC3513]. the IPv6 multicast address prefix [RFC3513].
As IPv6 scope-relative allocations can be handled with unicast-prefix As IPv6 scope-relative allocations can be handled with unicast-prefix
-based multicast addressing as described in Section 2.1.2, and there -based multicast addressing as described in Section 2.1.2, and there
is no need for separate scope-relative allocations, we'll just is no need for separate scope-relative allocations, we'll just
discuss IPv4 in this section. discuss IPv4 in this section.
The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to The IPv4 scope-relative prefix 239.0.0.0/8 is further divided to
Local Scope (239.255.0.0/16) and Organization Local Scope Local Scope (239.255.0.0/16) and Organization Local Scope
(239.192.0.0/14); other parts of the administrative scopes are either (239.192.0.0/14); other parts of the administrative scopes are either
reserved for expansion or undefined [RFC2365]. reserved for expansion or undefined [RFC2365]. However, RFC 2365 is
ambiguous as to whether it's the enterprises or the IETF who are
allowed to expand the space.
Topologies which act under a single administration can easily use the Topologies which 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 which
need to be shared between multiple routing domains (but not need to be shared between multiple routing domains (but not
propagated through Internet) are more problematic and typically need propagated through Internet) are more problematic and typically need
an assignment of a global multicast address because their scope is an assignment of a global multicast address because their scope is
undefined. undefined.
There is a large number of multicast applications (such as "Norton There is a large number of multicast applications (such as "Norton
Ghost") which are restricted either to a link or a site, but it is Ghost") which are restricted either to a link or a site, but it is
extremely undesirable to propagate them further (either to the rest extremely undesirable to propagate them further (either to the rest
of the site, or beyond the site). Typically many such applications of the site, or beyond the site). Typically many such applications
have been given a static IANA address assignment; this makes it have been given a static IANA address assignment; this makes it
challenging to implement proper propagation limiting -- which could challenging to implement proper propagation limiting -- which could
be easier if such applications could have been assigned specific be easier if such applications could have been assigned specific
scope-relative addresses instead. This is an area of further future scope-relative addresses instead. This is an area of further future
work -- it might be able to mitigate this issue if there was more work.
coordination inside the scope-relative allocation block.
There has also been work on protocol to automatically discover
multicast scope zones [RFC2776], but it has never been seriously
implemented or deployed.
2.3 Static IANA Allocation 2.3 Static IANA Allocation
In some rare cases, some organizations may have been able to obtain In some rare cases, some organizations may have been able to obtain
static multicast address allocations directly from IANA. Typically static multicast address allocations (of up to 256 addresses)
these have been meant as a block of static assignments to multicast directly from IANA. Typically these have been meant as a block of
applications, as described in Section 3.4. In principle, IANA does static assignments to multicast applications, as described in
not allocate multicast address blocks to the operators but GLOP or Section 3.4. In principle, IANA does not allocate multicast address
Unicast-prefix -based allocations should be used instead. blocks to the operators but GLOP or Unicast-prefix -based allocations
should be used instead.
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.
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 there are no dynamic multicast address It can be concluded that there are no dynamic multicast address
allocation protocols, and other methods such as GLOP or allocation protocols, and other methods such as GLOP or unicast-
unicast-prefix -based addressing should be used instead. prefix -based addressing should be used instead.
3. Multicast Address Assignment 3. Multicast Address Assignment
For multicast address assignment, i.e., how an application learns the For multicast address assignment, i.e., how an application learns the
address it can use, or a node (or a set of nodes) learns an address address it can use, or a node (or a set of nodes) learns an address
it could use for an application, has a number of options as described it could use for an application, has a number of options as described
below. 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 the group-IDs for IPv6 multicast addresses for the assignment of the 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 is only compared to derived allocation. Derived multicast assignment has
being specified for IPv6 link-scoped multicast only been specified for IPv6 link-scoped multicast [I-D.ietf-ipv6-
[I-D.ietf-ipv6-link-scoped-mcast], where the EUI64 is embedded in the link-scoped-mcast], where the EUI64 is embedded in the multicast
multicast address, providing a node with unique multicast addresses address, providing a node with unique multicast addresses for link-
for link-local ASM communications. local ASM communications.
3.2 SSM Assignment inside the Node 3.2 SSM Assignment inside the Node
While the SSM multicast addresses have only local (to the node) While the SSM multicast addresses have only local (to the node)
significance, there is still a minor issue on how to assign the significance, there is still a minor issue on how to assign the
addresses between the applications running on the same node (or more addresses between the applications running on the same node (or more
precisely, an IP address). precisely, an 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 the applications are selected manually or the addresses for the applications are selected manually or
statically, but if done using an API, the API could check that the statically, but if done using an Application Programming Interface
addresses do not conflict prior to assigning one. (API), the API could check that the addresses do not conflict prior
to assigning one.
3.3 Manually Configured Assignment 3.3 Manually Configured Assignment
With manually configured assignment, the network operator which has a With manually configured assignment, the 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 which wants to use a multicast Typically the user or administrator which wants to use a multicast
address for particular application requests an address from the address for 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.
skipping to change at page 7, line 46 skipping to change at page 7, line 49
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 a globally unique assignment static IANA assignment refers to getting a globally unique assignment
for the particular application directly from IANA. Guidelines for for the particular application directly from IANA. Guidelines for
IANA are described in [I-D.ietf-mboned-rfc3171bis]. IANA are described in [RFC3171][I-D.ietf-mboned-rfc3171bis].
This is seen as lucrative because it's the simplest approach for This is seen as lucrative because it's the simplest approach for
application developers because they can then hard-code the multicast application developers because they can then hard-code the multicast
address, requiring no lease of the usable multicast address, and address. Hard-coding requires no lease of the usable multicast
likewise the client applications do not need to perform any kind of address, and likewise the client applications do not need to perform
service discovery (but depending on hard-coded addresses). However, any kind of service discovery (but depending on hard-coded
this is a bad approach architecturally, as we should focus on addresses). However, this is a bad approach architecturally, as we
enhancing and deploying service discovery and address assignment (as should focus on enhancing and deploying service discovery and address
needed) instead of encouraging a "land-grab" of multicast addresses. assignment (as needed) instead of encouraging a "land-grab" of
multicast addresses.
[RFC3138] describes how to handle those GLOP assignments (called
"eGLOP") which use the private-use AS number space (233.252.0.0/14).
It was envisioned that IANA would delegate the responsibility of
these to RIRs, which would assign or allocate addresses as best
seemed fit. However, this was never carried out as IANA did not make
these allocations to RIRs due to procedural reasons.
In summary, there are applications which have obtained a static IANA In summary, there are applications which have obtained a static IANA
assignment, some of which are really needed, and some of which assignment, some of which are really needed, and some of which
probably should not have been granted. probably should not have been granted.
3.5 Dynamic Assignments 3.5 Dynamic Assignments
The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from
Multicast Address Allocation Servers (MAAS) to applications and Multicast Address Allocation Servers (MAAS) to applications and
nodes, with Multicast Address Dynamic Client Allocation Protocol nodes, with Multicast Address Dynamic Client Allocation Protocol
(MADCAP) [RFC2730] as examples. Since then, there has been a (MADCAP) [RFC2730] as an example. Since then, there has been a
proposal for DHCPv6 assignment proposal for DHCPv6 assignment [I-D.jdurand-assign-addr-ipv6-
[I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]. multicast-dhcpv6].
Based on a multicast prefix, it would be rather straightforward to It would be rather straightforward to deploy a dynamic assignment
deploy a dynamic assignment protocol which would lease group protocol which would lease group addresses based on a multicast
addresses to the applications wishing to use multicast. For example, prefix to the applications wishing to use multicast. For example,
only few have implemented MADCAP, and it's not significantly only few have implemented MADCAP, and it's not significantly
deployed. Moreover, it is not clear how widely for example the APIs deployed. Moreover, it is not clear how widely for example the APIs
for communication between the multicast application and the MADCAP for communication between the multicast application and the MADCAP
client operating at the host have been implemented [RFC2771]. client operating at the host have been implemented [RFC2771].
An entirely different approach is Session Announcement Protocol (SAP) An entirely different approach is Session Announcement Protocol (SAP)
[RFC2974]. In addition to advertising global multicast sessions, the [RFC2974]. In addition to advertising global multicast sessions, the
protocol also has associated ranges of addresses for both IPv4 and protocol also has associated ranges of addresses for both IPv4 and
IPv6 which can be used by SAP-aware applications to create new groups IPv6 which can be used by SAP-aware applications to create new groups
and new group addresses. It is a rather tedious process to create a and new group addresses. Creating a session (and obtaining an
session (and obtain an address) this way which is why it isn't done address) is a rather tedious process which is why it isn't done all
all that often. (Note that the IPv6 SAP address is unroutable in the that often. (Note that the IPv6 SAP address is unroutable in the
inter-domain multicast.) inter-domain multicast.)
A conclusion about dynamic assignment protocols is that: A conclusion about dynamic assignment protocols is that:
1. multicast is not significantly attractive in the first place, 1. multicast is not significantly attractive in the first place,
2. very many applications have a static IANA assignment and thus 2. very many applications have a static IANA assignment and thus
require no dynamic or manual assignment, require no dynamic or manual assignment,
3. those that cannot be easily satisfied with IANA or manual 3. those that cannot be easily satisfied with IANA or manual
assignment (i.e., where dynamic assignment would be desirable) assignment (i.e., where dynamic assignment would be desirable)
are rather marginal, or are rather marginal, or
4. that there are other gaps why dynamic assignments are not seen as 4. that there are other gaps why dynamic assignments are not seen as
a useful approach (for example, issues related to service a useful approach (for example, issues related to service
discovery/rendezvous). discovery/rendezvous).
In consequence, more work on rendezvous/service discovery will be In consequence, more work on rendezvous/service discovery would be
needed to make dynamic assignment 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
Summary of prefix allocation methods for ASM is in Figure 1. Summary of prefix allocation methods for ASM is in Figure 1.
skipping to change at page 10, line 15 skipping to change at page 10, line 21
4.2 Address Assignment 4.2 Address Assignment
Summary of address assignment methods is in Figure 2. Summary of address assignment methods is in Figure 2.
+-------+--------------------------------+----------+----------+ +-------+--------------------------------+----------+----------+
| Sect. | Address assignment method | IPv4 | IPv6 | | Sect. | Address assignment method | IPv4 | IPv6 |
+-------+--------------------------------+----------+----------+ +-------+--------------------------------+----------+----------+
| 3.1 | Derived: link-scope addresses | No | Yes | | 3.1 | Derived: link-scope addresses | No | Yes |
| 3.2 | SSM (inside the node) | Yes | Yes | | 3.2 | SSM (inside the node) | Yes | Yes |
| 3.3 | Manual assignment | Yes | Yes | | 3.3 | Manual assignment | Yes | Yes |
| 3.4 | Static IANA assignment |LastResort|LastResort| | 3.4 | Static IANA/RIR assignment |LastResort|LastResort|
| 3.5 | Dynamic assignment protocols | Yes | Yes | | 3.5 | Dynamic assignment protocols | Yes | Yes |
+-------+--------------------------------+----------+----------+ +-------+--------------------------------+----------+----------+
Figure 2 Figure 2
o Manually configured assignment is what's typically done today, and o Manually configured assignment is what's typically done today, and
works to a sufficient degree in smaller scale. works to a sufficient degree in smaller scale.
o Static IANA assignment has been done extensively in the past, but o Static IANA assignment has been done extensively in the past, but
it needs to be tightened down to prevent problems caused by it needs to be tightened down to prevent problems caused by "land-
"land-grabbing". grabbing".
o Dynamic assignment, e.g., using MADCAP have been implemented, but o Dynamic assignment, e.g., using MADCAP have been implemented, but
there is no wide deployment, so a solution is there -- but either there is no wide deployment, so a solution is there. However,
there are other gaps in the multicast architecture or there is no either there are other gaps in the multicast architecture or there
need for it in the first place, when manual configuration is is no sufficient demand for it in the first place when manual and
possible, and static IANA assignments are still there. static IANA assignments are available. Assignments using SAP also
Assignments using SAP also exist but are not common; global SAP exist but are not common; global SAP assignment is unfeasible with
assignment is unfeasible with IPv6. IPv6.
o Derived assignments are only applicable in a fringe case of o Derived assignments are only applicable in a fringe case of link-
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; the result also more length, and an adequate solution provided; the result also
needs to be written down to be shown to the IANA static assignment needs to be written down to be shown to the IANA static assignment
requestors. See [I-D.savola-mboned-address-discovery-problems] requestors. See [I-D.ietf-mboned-addrdisc-problems] for more.
and Appendix B for more.
o IPv6 multicast DAD and/or multicast prefix communication o IPv6 multicast DAD and/or multicast prefix communication
mechanisms should be analyzed (e.g., mechanisms should be analyzed (e.g.,
[I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not, [I-D.jdurand-ipv6-multicast-ra]): whether there is demand or not,
and specify if yes. and specify if yes.
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 scope-relative address space for static allocation for IPv4 scope-relative address space for static allocation for
applications which should not be routed over the Internet (such as applications which should not be routed over the Internet (such as
backup software, etc. -- so that these wouldn't need to use backup software, etc. -- so that these wouldn't need to use global
global addresses which should never leak in any case). addresses which should never leak in any case).
o The IETF should seriously consider its static IANA allocations o The IETF should seriously consider its static IANA allocations
policy, e.g., "locking it down" to a stricter policy (like "IETF policy, e.g., "locking it down" to a stricter policy (like "IETF
Consensus") and looking at developing the discovery/rendezvous Consensus") and looking at developing the discovery/rendezvous
functions, if necessary. functions, if necessary.
5. Acknowledgements 5. Acknowledgements
Tutoring a couple multicast-related papers, the latest by Kaarle Tutoring a couple multicast-related papers, the latest by Kaarle
Ritvanen [RITVANEN] convinced the author that the up-to-date Ritvanen [RITVANEN] convinced the author that the up-to-date
skipping to change at page 11, line 38 skipping to change at page 11, line 44
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA, but as the allocation and This memo includes no request to IANA, but as the allocation and
assignment of multicast addresses are related to IANA functions, it assignment of multicast addresses are related to IANA functions, it
wouldn't hurt if the IANA reviewed this entire memo. wouldn't hurt if the IANA reviewed this entire memo.
IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still IANA considerations in sections 4.1.1 and 4.1.2 of [RFC2908] still
apply to the administratively scoped prefixes. apply to the administratively scoped prefixes.
IANA may be interested in reviewing the accuracy of the statement on
eGLOP address assignments in Section 3.4.
(RFC-editor: please remove this section at publication.) (RFC-editor: please remove this section at publication.)
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, 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-ipv6-link-scoped-mcast] [I-D.ietf-ipv6-link-scoped-mcast]
Park, J., "Link Scoped IPv6 Multicast Addresses", Park, J., "A Method for Generating Link Scoped IPv6
Internet-Draft draft-ietf-ipv6-link-scoped-mcast-08, Multicast Addresses", draft-ietf-ipv6-link-scoped-mcast-09
December 2004. (work in progress), July 2005.
[I-D.ietf-mboned-rfc3171bis]
Albanna, Z., Almeroth, K., Cotton, M. and D. Meyer, "IANA
Guidelines for IPv4 Multicast Address Assignments",
Internet-Draft draft-ietf-mboned-rfc3171bis-02, March
2004.
[I-D.ietf-ssm-arch] [I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", Internet-Draft draft-ietf-ssm-arch-06, September IP", draft-ietf-ssm-arch-06 (work in progress),
2004. September 2004.
[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.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001.
[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.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[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.
8.2 Informative References 8.2 Informative References
[I-D.iab-dns-choices]
Faltstrom, P. and R. Austein, "Design Choices When
Expanding DNS", Internet-Draft draft-iab-dns-choices-00,
October 2004.
[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]
Savola, P., "Lightweight Multicast Address Discovery
Problem Space", draft-ietf-mboned-addrdisc-problems-00
(work in progress), March 2005.
[I-D.ietf-mboned-ipv4-uni-based-mcast] [I-D.ietf-mboned-ipv4-uni-based-mcast]
Thaler, D., "Unicast-Prefix-based IPv4 Multicast Thaler, D., "Unicast-Prefix-based IPv4 Multicast
Addresses", Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02
Internet-Draft draft-ietf-mboned-ipv4-uni-based-mcast-02, (work in progress), October 2004.
October 2004.
[I-D.ietf-mboned-ipv6-multicast-issues] [I-D.ietf-mboned-rfc3171bis]
Savola, P., "IPv6 Multicast Deployment Issues", Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA
Internet-Draft draft-ietf-mboned-ipv6-multicast-issues-01, Guidelines for IPv4 Multicast Address Assignments",
September 2004. draft-ietf-mboned-rfc3171bis-02 (work in progress),
March 2004.
[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",
, June 2004. draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work
in progress), February 2005.
[I-D.jdurand-ipv6-multicast-ra] [I-D.jdurand-ipv6-multicast-ra]
Durand, J. and P. Savola, "Route Advertisement Option for Durand, J. and P. Savola, "Route Advertisement Option for
IPv6 Multicast Prefixes", IPv6 Multicast Prefixes",
Internet-Draft draft-jdurand-ipv6-multicast-ra-00, draft-jdurand-ipv6-multicast-ra-00 (work in progress),
February 2005. February 2005.
[I-D.palet-v6ops-tun-auto-disc]
Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point
Discovery Mechanisms",
Internet-Draft draft-palet-v6ops-tun-auto-disc-03, January
2005.
[I-D.savola-mboned-address-discovery-problems]
Savola, P., "Lightweight Multicast Address Discovery
Problem Space",
, 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", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June "Service Location Protocol, Version 2", RFC 2608,
1999. June 1999.
[RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
December 1999. December 1999.
[RFC2771] Finlayson, R., "An Abstract API for Multicast Address [RFC2771] Finlayson, R., "An Abstract API for Multicast Address
Allocation", RFC 2771, February 2000. Allocation", RFC 2771, February 2000.
[RFC2908] Thaler, D., Handley, M. and D. Estrin, "The Internet [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, Multicast Address Allocation Architecture", RFC 2908,
September 2000. September 2000.
[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
Kumar, S. and D. Thaler, "The Multicast Address-Set Claim Kumar, S., and D. Thaler, "The Multicast Address-Set Claim
(MASC) Protocol", RFC 2909, September 2000. (MASC) Protocol", RFC 2909, September 2000.
[RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138,
M. Carney, "Dynamic Host Configuration Protocol for IPv6 June 2001.
(DHCPv6)", RFC 3315, July 2003.
[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.
[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/>.
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
Appendix A. Open Issues Appendix A. Changes
(This section will be removed or merged with the rest before
publication..)
o Is the case for IPv4 Unicast-Prefix Base Multicast addressing
sufficiently strong, or could those organizations just get an AS
number themselves if they really wanted to do multicast?
Appendix B. Multicast Address Discovery
[[ NOTE IN DRAFT: the intent of this section has been mostly
superceded by [I-D.savola-mboned-address-discovery-problems] and
therefore it is put in the appendix, with pending removal in the
future.
As was noted in Section 3, multicast address discovery (i.e., service (To be removed prior to publication as an RFC.)
discovery or "rendezvous") is a problem with multicast address
assignment. In particular, an acceptable mechanism (mechanisms such
as Service Location Protocol (SLP) [RFC2608] seem to have been
considered too complex) seems to be missing which the hosts wishing
to participate in a group could use to find the address of that group
[MBONED-IETF59].
It is worth noting that as long as not deploying an address A.1 Changes since -01
assignment and service discovery protocols/mechanisms means that one
can get a static address assignment from IANA, there is little
interest from the application developers to actually do anything
except try to get the assignment from IANA. Conclusion: if we want
to use non-IANA processes, the assignments must be either forbidden
completely, or made sufficiently difficult that it's easier for the
application developers to take another route if a feasible mechanism
is available.
There are two issues in the service discovery: o Mention the mechanisms which haven't been so succesful: eGLOP and
MZAP.
1. The session initiator being able to publish the session somehow, o Remove the appendices on multicast address discovery (a separate
and draft now) and IPv4 unicast-prefix based multicast addressing.
2. The session participants finding out about the session (rather o Add a note on scope-relative address space and the expansion
than creating their own). ambiguity.
When manually configured or static IANA assignments are used, 1) o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt
should be relatively straightforward (if something needs to be
manually configured or statically assigned, putting it e.g., in DNS
should not be a problem). However, this is still more complex for
dynamic or derived assignments because it implies that the host or
the application has the right to make that publication on its own,
rather than through a manual process by an administrator.
2) is always a challenge, but could leverage for example DNS (e.g., o Minor editorial cleanups.
by relying on using SRV records with the DNS search path, as
described in [I-D.iab-dns-choices] and
[I-D.palet-v6ops-tun-auto-disc]).
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/