draft-ietf-mboned-addrarch-04.txt   draft-ietf-mboned-addrarch-05.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: 2776,2908,2909 (if March 3, 2006 Obsoletes: 2776,2908,2909 October 16, 2006
approved) (if approved)
Intended status: Best Current Intended status: Best Current
Practice Practice
Expires: September 4, 2006 Expires: April 19, 2007
Overview of the Internet Multicast Addressing Architecture Overview of the Internet Multicast Addressing Architecture
draft-ietf-mboned-addrarch-04.txt draft-ietf-mboned-addrarch-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 September 4, 2006. This Internet-Draft will expire on April 19, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4 2.1. Derived Allocation . . . . . . . . . . . . . . . . . . . . 4
2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4 2.1.1. GLOP Allocation . . . . . . . . . . . . . . . . . . . 4
2.1.2. Unicast-prefix -based Allocation . . . . . . . . . . . 4 2.1.2. Unicast-prefix -based Allocation . . . . . . . . . . . 4
2.2. Administratively Scoped Allocation . . . . . . . . . . . . 5 2.2. Administratively Scoped Allocation . . . . . . . . . . . . 5
2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6 2.3. Static IANA Allocation . . . . . . . . . . . . . . . . . . 6
2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6 2.4. Dynamic Allocation . . . . . . . . . . . . . . . . . . . . 6
3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6 3. Multicast Address Assignment . . . . . . . . . . . . . . . . . 6
3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7 3.1. Derived Assignment . . . . . . . . . . . . . . . . . . . . 7
3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7 3.2. SSM Assignment inside the Node . . . . . . . . . . . . . . 7
3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7 3.3. Manually Configured Assignment . . . . . . . . . . . . . . 7
3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 7 3.4. Static IANA Assignment . . . . . . . . . . . . . . . . . . 8
3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8 3.4.1. Global IANA Assignment . . . . . . . . . . . . . . . . 8
3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8 3.4.2. Scope-relative IANA Assignment . . . . . . . . . . . . 8
3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 8 3.5. Dynamic Assignments . . . . . . . . . . . . . . . . . . . 9
4. Summary and Future Directions . . . . . . . . . . . . . . . . 9 4. Summary and Future Directions . . . . . . . . . . . . . . . . 10
4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10 4.1. Prefix Allocation . . . . . . . . . . . . . . . . . . . . 10
4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11 4.2. Address Assignment . . . . . . . . . . . . . . . . . . . . 11
4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Future Actions . . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15 A.1. Changes between -04 and -05 . . . . . . . . . . . . . . . 15
A.2. Changes between -03 and -04 . . . . . . . . . . . . . . . 16
A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 16
A.4. Changes between -01 and -02 . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
Good, up-to-date documentation of IP multicast is close to non- Good, up-to-date documentation of IP multicast is close to non-
existent. Particularly, this is an issue with multicast address existent. Particularly, this is an issue with multicast address
allocations (to networks and sites) and assignments (to hosts and allocations (to networks and sites) and assignments (to hosts and
applications). This problem is stressed by the fact that there applications). This problem is stressed by the fact that there
exists confusing or misleading documentation on the subject exists confusing or misleading documentation on the subject
[RFC2908]. The consequence is that those who wish to learn of 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)
[I-D.ietf-ssm-arch] does not have these addressing problems; hence, [RFC4607] does not have these addressing problems because SSM group
this document focuses on the Any Source Multicast (ASM) model. addresses have only local significance; hence, this document focuses
on the Any Source Multicast (ASM) model.
This memo obsoletes RFCs 2776, 2908, and 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 terms for two
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 Internet Assigned Numbers Authority (IANA) to
a Regional Internet Registry (RIR) or 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 end- address blocks or even single addresses to the end-user sites or 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
skipping to change at page 4, line 19 skipping to change at page 4, line 19
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 to determine unique multicast address allocations. of the network (e.g., an autonomous system (AS) number) 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 AS number
Autonomous System (AS) number in the middle of the IPv4 multicast in the middle of the IPv4 multicast prefix 233.0.0.0/8, so that each
prefix 233.0.0.0/8, so that each AS number can get a /24 worth of AS number can get a /24 worth of multicast addresses. While this is
multicast addresses. While this is sufficient for multicast testing sufficient for multicast testing or small scale use, it might not be
or small scale use, it might not be sufficient in all cases for sufficient in all cases for extensive multicast use.
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., from [RFC3180], AS 5662 maps to 233.22.30.0/24). A
usage issue is that GLOP addresses are not tied to any prefix but to usage issue is that GLOP addresses are not tied to any prefix but to
routing domains, so they cannot be used or calculated automatically. routing domains, so they cannot be used or calculated automatically.
GLOP allocation algorithm has not been defined for IPv6 multicast
because the unicast-prefix -based allocation (described below)
addresses the same need in a simpler fashion. GLOP hasn't been (and
likely never will be) specified for 4-byte AS numbers
[I-D.ietf-idr-as4bytes].
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 high-
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 mapping has been proposed for IPv4 A similar mapping has been proposed for IPv4
[I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low [I-D.ietf-mboned-ipv4-uni-based-mcast], but it provides a rather low
amount of addresses (e.g., 1 per an IPv4 /24 block). While there amount of addresses (e.g., 1 per an IPv4 /24 block). Although large
exist large networks without an AS number of their own, this has not networks without an AS number do exist, this technique has not been
been seen to add sufficient value compared to GLOP addressing. seen to add value compared to GLOP addressing.
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, 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 [RFC3513], multicast multicast header also includes the scope value [RFC3513], multicast
groups of smaller scope can also be used with the same mapping. groups of smaller scope can also be used with the same mapping.
The IPv6 Embedded RP technique [RFC3956], used with Protocol The IPv6 Embedded RP technique [RFC3956], used with Protocol
Independent Multicast - Sparse Mode (PIM-SM), further leverages the Independent Multicast - Sparse Mode (PIM-SM), further leverages the
unicast prefix based allocations, by embedding the unicast prefix and unicast prefix based allocations, by embedding the unicast prefix and
interface identifier of the PIM-SM Rendezvous Point (RP) in the interface identifier of the PIM-SM Rendezvous Point (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 to 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 but prefix depends on the decisions of the operator setting up the RP,
rather requires an assignment method. but instead requires an assignment method.
All the IPv6 unicast-prefix-based allocation techniques provide All the IPv6 unicast-prefix-based allocation techniques provide
sufficient amount of multicast address space for the network sufficient amount of multicast address space for the network
operators. operators.
2.2. Administratively Scoped Allocation 2.2. Administratively Scoped Allocation
Administratively scoped multicast [RFC2365] is provided by two Administratively scoped multicast address allocation [RFC2365] is
different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in provided by two different means: under 239.0.0.0/8 in IPv4 or by
the IPv6 multicast address prefix [RFC3513]. 4-bit encoding in the IPv6 multicast address prefix [RFC3513].
As 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 just discuss IPv4 in this section. Section 2.1.2, we'll just 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 to Local Scope (239.255.0.0/16) and Organization Local Scope divided to Local Scope (239.255.0.0/16) and Organization Local Scope
(239.192.0.0/14); other parts of the administrative scopes are either (239.192.0.0/14); other parts of the administrative scopes are either
reserved for expansion or undefined [RFC2365]. However, RFC 2365 is reserved for expansion or undefined [RFC2365]. However, RFC 2365 is
ambiguous as to whether it's the enterprises or the IETF who are ambiguous as to whether the enterprises or the IETF are allowed to
allowed to expand the space. 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 (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 is a large number of multicast applications (such as "Norton
Ghost") which are restricted either to a link or a site, and it is Ghost") which are restricted either to a link or a site, and it is
extremely undesirable to propagate them further (either to the rest extremely undesirable to propagate them further (beyond the link or
of the site, or beyond the site). Typically many such applications the site). Typically many such applications have been given or have
have been given or have hijacked a static IANA address assignment; hijacked a static IANA address assignment. The fact that assignments
this makes it challenging to implement proper propagation limiting -- to typically locally used applications come from the same range as
which could be easier if such applications could have been assigned global applications, implementing proper propagation limiting is
specific administratively scoped addresses instead. This is an area challenging. Filtering would be easier if such applications would in
of further future work. future be assigned specific administratively scoped addresses
instead. 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, some organizations may have been able to obtain In some rare cases, some organizations may have been able to obtain
static multicast address allocations (of up to 256 addresses) static multicast address allocations (of up to 256 addresses)
directly from IANA. Typically these have been meant as a block of directly from IANA. Typically these have been meant as a block of
static assignments to multicast applications, as described in static assignments to multicast applications, as described in
Section 3.4.1. In principle, IANA does not allocate multicast Section 3.4.1. In principle, IANA should not and does not allocate
address blocks to the operators but GLOP or Unicast-prefix-based multicast address blocks to the operators but GLOP or Unicast-prefix-
allocations should be used instead. 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 dynamic multicast address allocation
allocation protocols, and other methods such as GLOP or unicast- protocols provide no benefit beyond GLOP/unicast-prefix-based
prefix-based addressing should be used instead. mechanisms and have been abandoned.
3. Multicast Address Assignment 3. Multicast Address Assignment
For multicast address assignment, i.e., how an application learns the There are a number of possible ways for an application, node or set
address it can use, or a node (or a set of nodes) learns an address of nodes to learn a multicast address as described below.
it could use for an application, has a number of options 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 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 has compared to derived allocation. Derived multicast assignment has
only been specified for IPv6 link-scoped multicast only been specified for IPv6 link-scoped multicast [RFC4489], where
[I-D.ietf-ipv6-link-scoped-mcast], where the EUI64 is embedded in the the EUI64 is embedded in the multicast address, providing a node with
multicast address, providing a node with unique multicast addresses unique multicast addresses for link-local ASM communications.
for link-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 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 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, the network operator who has a With manually configured assignment, the network operator who has a
skipping to change at page 8, line 27 skipping to change at page 8, line 32
limited multicast address space. limited multicast address space.
[RFC3138] describes how to handle those GLOP assignments (called [RFC3138] describes how to handle those GLOP assignments (called
"eGLOP") which use the private-use AS number space (233.252.0.0/14). "eGLOP") which use the private-use AS number space (233.252.0.0/14).
It was envisioned that IANA would delegate the responsibility of It was envisioned that IANA would delegate the responsibility of
these to RIRs, which would assign or allocate addresses as best these to RIRs, which would assign or allocate addresses as best
seemed fit. However, this was never carried out as IANA did not make seemed fit. However, this was never carried out as IANA did not make
these allocations to RIRs due to procedural reasons. these allocations to RIRs due to procedural reasons.
In summary, there are applications which have obtained a global In summary, there are applications which have obtained a global
static IANA assignment and while some of which are really needed, static IANA assignment and while some of the assignments were really
some of which probably should not have been granted. Conversely, needed, others probably should not have been granted. Conversely,
there are some applications that have not obtained a static IANA there are some applications that have not obtained a static IANA
assignment, yet should have requested an assignment and been granted assignment, yet should have requested an assignment and been granted
one. one.
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
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
skipping to change at page 9, line 10 skipping to change at page 9, line 16
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 an example. 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-multicast-dhcpv6]. [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6].
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 which would lease group addresses based on a multicast
prefix to the applications wishing to use multicast. For example, prefix to the applications wishing to use multicast. However, only
only few have implemented MADCAP, and it's not significantly few have implemented MADCAP, and it hasn't been significantly
deployed. Moreover, it is not clear how widely for example the APIs deployed. So, it is not clear if the lack of deployment is due to a
for communication between the multicast application and the MADCAP currently missing need. Moreover, it is not clear how widely for
client operating at the host have been implemented [RFC2771]. example the APIs for communication between the multicast application
and the MADCAP client operating at the host have been implemented
[RFC2771].
An entirely different approach is Session Announcement Protocol (SAP) 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. Creating a session (and obtaining an and new group addresses. Creating a session (and obtaining an
address) is a rather tedious process which is why it isn't done all address) is a rather tedious process which is why it isn't done 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. most applications have a static IANA assignment and thus require
require no dynamic or manual assignment, 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 would be In consequence, more work on rendezvous/service discovery would be
skipping to change at page 10, line 13 skipping to change at page 10, line 18
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.
+-------+--------------------------------+--------+--------+ +-------+--------------------------------+--------+--------+
| 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 -yet | 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 | No | No | | 2.3 | Static IANA allocation | No | 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.
Figure 1 Figure 1
o Only ASM is affected by the assignment/allocation issues (however, o Only ASM is affected by the assignment/allocation issues (however,
both ASM and SSM have roughly the same address discovery issues). both ASM and SSM have roughly the same address discovery issues).
skipping to change at page 11, line 32 skipping to change at page 11, line 32
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 Global IANA assignment has been done extensively in the past, but o Global IANA assignment has been done extensively in the past, but
it needs to be tightened down to prevent problems caused by "land- it needs to be tightened down to prevent problems caused by "land-
grabbing". Scope-relative IANA assignment is acceptable but the grabbing". Scope-relative IANA assignment is acceptable but the
size of the pool is not very high. Inter-domain routing of IPv6 size of the pool is not very high. Inter-domain routing of IPv6
IANA-assigned prefixes is likely going to be challenging. IANA-assigned prefixes is likely going to be challenging.
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, so a solution is there. However, either is no wide deployment. So, either there are other gaps in the
there are other gaps in the multicast architecture or there is no multicast architecture or there is no sufficient demand for it in
sufficient demand for it in the first place when manual and static the first place when manual and static IANA assignments are
IANA assignments are available. Assignments using SAP also exist available. Assignments using SAP also exist but are not common;
but are not common; global SAP assignment is unfeasible with IPv6. global SAP assignment is unfeasible 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; 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.ietf-mboned-addrdisc-problems] for more. requestors. See [I-D.ietf-mboned-addrdisc-problems] for more.
skipping to change at page 12, line 19 skipping to change at page 12, line 19
use global addresses which should never leak in any case). use global 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 updated multicast
multicast address assignment/allocation documentation is necessary. 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 IETF59 [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, and Dave Price also suggested Jerome Durand, John Kristoff, Dave Price, and Spencer Dawkins also
improvements. suggested improvements.
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.
skipping to change at page 13, line 13 skipping to change at page 13, line 13
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]
Park, J., "A Method for Generating Link Scoped IPv6
Multicast Addresses", draft-ietf-ipv6-link-scoped-mcast-09
(work in progress), July 2005.
[I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", draft-ietf-ssm-arch-07 (work in progress),
October 2005.
[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, [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments", "IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001. 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.
skipping to change at page 13, line 46 skipping to change at page 13, line 36
[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.
[RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for
Generating Link-Scoped IPv6 Multicast Addresses",
RFC 4489, April 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
8.2. Informative References 8.2. Informative References
[I-D.ietf-idr-as4bytes]
Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", draft-ietf-idr-as4bytes-12 (work in
progress), November 2005.
[I-D.ietf-malloc-aap] [I-D.ietf-malloc-aap]
Handley, M. and S. Hanna, "Multicast Address Allocation Handley, M. and S. Hanna, "Multicast Address Allocation
Protocol (AAP)", June 2000. Protocol (AAP)", June 2000.
[I-D.ietf-mboned-addrdisc-problems] [I-D.ietf-mboned-addrdisc-problems]
Savola, P., "Lightweight Multicast Address Discovery Savola, P., "Lightweight Multicast Address Discovery
Problem Space", draft-ietf-mboned-addrdisc-problems-01 Problem Space", draft-ietf-mboned-addrdisc-problems-02
(work in progress), November 2005. (work in progress), March 2006.
[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", draft-ietf-mboned-ipv4-uni-based-mcast-02 Addresses", draft-ietf-mboned-ipv4-uni-based-mcast-02
(work in progress), October 2004. (work in progress), October 2004.
[I-D.ietf-mboned-rfc3171bis] [I-D.ietf-mboned-rfc3171bis]
Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA Albanna, Z., Almeroth, K., Cotton, M., and D. Meyer, "IANA
Guidelines for IPv4 Multicast Address Assignments", Guidelines for IPv4 Multicast Address Assignments",
draft-ietf-mboned-rfc3171bis-02 (work in progress), draft-ietf-mboned-rfc3171bis-02 (work in progress),
skipping to change at page 15, line 36 skipping to change at page 15, line 39
[RITVANEN] [RITVANEN]
Ritvanen, K., "Multicast Routing and Addressing", HUT Ritvanen, K., "Multicast Routing and Addressing", HUT
Report, Seminar on Internetworking, May 2004, Report, Seminar on Internetworking, May 2004,
<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>. <http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
Appendix A. Changes Appendix A. Changes
(To be removed prior to publication as an RFC.) (To be removed prior to publication as an RFC.)
A.1. Changes since -01 A.1. Changes between -04 and -05
o Editorial updates. These and the following are from Spencer
Dawkins.
o New text explictly stating that GLOP for v6 is not needed and GLOP
for 4byte ASNs isn't (and likely won't be) defined.
o Expand reasons for filtering difficulties with global IANA
assignments for local apps, and that it would be easier if these
were done from the local pool.
o Explicitly mention dynamic allocations protocols' lack of benefit
and abandonment.
A.2. Changes between -03 and -04
o S/scope-relative/administratively scoped/ and expand Static IANA
Assignment section to two subsections; mainly from Dave Price.
o Mention the routing challenges of IPv6 IANA assigned prefixes in
section 4.2
A.3. Changes between -02 and -03
o Reword architectural implications of Static IANA and editorial
improvements; mainly from John Kristoff.
A.4. Changes between -01 and -02
o Mention the mechanisms which haven't been so succesful: eGLOP and o Mention the mechanisms which haven't been so succesful: eGLOP and
MZAP. MZAP.
o Remove the appendices on multicast address discovery (a separate o Remove the appendices on multicast address discovery (a separate
draft now) and IPv4 unicast-prefix-based multicast addressing. draft now) and IPv4 unicast-prefix-based multicast addressing.
o Add a note on administraively scoped address space and the o Add a note on administratively scoped address space and the
expansion ambiguity. expansion ambiguity.
o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt o Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt
o Minor editorial cleanups. o Minor editorial cleanups.
Author's Address Author's Address
Pekka Savola Pekka Savola
CSC - Scientific Computing Ltd. CSC - Scientific Computing Ltd.
 End of changes. 41 change blocks. 
93 lines changed or deleted 132 lines changed or added

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