Skip to main content

Overview of the Internet Multicast Addressing Architecture

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6308.
Author Pekka Savola
Last updated 2015-10-14 (Latest revision 2010-10-25)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 6308 (Informational)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Ron Bonica
IESG note
Send notices to Marshall Eubanks <>, Hiroshi Ohta <>
Internet Engineering Task Force                                P. Savola
Internet-Draft                                                 CSC/FUNET
Obsoletes: 2908 (if approved)                           October 25, 2010
Intended status: Informational
Expires: April 28, 2011

       Overview of the Internet Multicast Addressing Architecture


   The lack of up-to-date documentation on IP multicast address
   allocation and assignment procedures has caused a great deal of
   confusion.  To clarify the situation, this memo describes the
   allocation and assignment techniques and mechanisms currently (as of
   this writing) in use.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 28, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as

Savola                   Expires April 28, 2011                 [Page 1]
Internet-Draft        Multicast Address Allocation          October 2010

   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology: Allocation or Assignment  . . . . . . . . . .  3
   2.  Multicast Address Allocation . . . . . . . . . . . . . . . . .  4
     2.1.  Derived Allocation . . . . . . . . . . . . . . . . . . . .  4
       2.1.1.  GLOP Allocation  . . . . . . . . . . . . . . . . . . .  4
       2.1.2.  Unicast-prefix-based Allocation  . . . . . . . . . . .  4
     2.2.  Administratively Scoped Allocation . . . . . . . . . . . .  5
     2.3.  Static IANA Allocation . . . . . . . . . . . . . . . . . .  6
     2.4.  Dynamic Allocation . . . . . . . . . . . . . . . . . . . .  6
   3.  Multicast Address Assignment . . . . . . . . . . . . . . . . .  6
     3.1.  Derived Assignment . . . . . . . . . . . . . . . . . . . .  7
     3.2.  SSM Assignment inside the Node . . . . . . . . . . . . . .  7
     3.3.  Manually Configured Assignment . . . . . . . . . . . . . .  7
     3.4.  Static IANA Assignment . . . . . . . . . . . . . . . . . .  8
       3.4.1.  Global IANA Assignment . . . . . . . . . . . . . . . .  8
       3.4.2.  Scope-relative IANA Assignment . . . . . . . . . . . .  8
     3.5.  Dynamic Assignments  . . . . . . . . . . . . . . . . . . .  8
   4.  Summary and Future Directions  . . . . . . . . . . . . . . . .  9
     4.1.  Prefix Allocation  . . . . . . . . . . . . . . . . . . . . 10
     4.2.  Address Assignment . . . . . . . . . . . . . . . . . . . . 11
     4.3.  Future Actions . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 15
     A.1.  Changes between -06 and -07  . . . . . . . . . . . . . . . 15
     A.2.  Changes between -05 and -06  . . . . . . . . . . . . . . . 15
     A.3.  Changes between -04 and -05  . . . . . . . . . . . . . . . 15
     A.4.  Changes between -03 and -04  . . . . . . . . . . . . . . . 16
     A.5.  Changes between -02 and -03  . . . . . . . . . . . . . . . 16
     A.6.  Changes between -01 and -02  . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16

Savola                   Expires April 28, 2011                 [Page 2]
Internet-Draft        Multicast Address Allocation          October 2010

1.  Introduction

   Good, up-to-date documentation of IP multicast is close to non-
   existent.  Particularly, this is an issue with multicast address
   allocations (to networks and sites) and assignments (to hosts and
   applications).  This problem is stressed by the fact that there
   exists confusing or misleading documentation on the subject
   [RFC2908].  The consequence is that those who wish to learn about IP
   multicast and how the addressing works do not get a clear view of the
   current situation.

   The aim of this document is to provide a brief overview of multicast
   addressing and allocation techniques.  The term 'addressing
   architecture' refers to the set of addressing mechanisms and methods
   in an informal manner.

   It is important to note that Source-specific Multicast (SSM)
   [RFC4607] does not have these addressing problems because SSM group
   addresses have only local significance; hence, this document focuses
   on the Any Source Multicast (ASM) model.

   This memo obsoletes and re-classifies to Historic RFC 2908, and re-
   classifies to Historic RFCs 2776 and 2909.

1.1.  Terminology: Allocation or Assignment

   Almost all multicast documents and many other RFCs (such as DHCPv4
   [RFC2131] and DHCPv6 [RFC3315]) have used the terms address
   "allocation" and "assignment" interchangeably.  However, the operator
   and address management communities use these terms for two
   conceptually different processes.

   In unicast operations, address allocations refer to leasing a large
   block of addresses from Internet Assigned Numbers Authority (IANA) to
   a Regional Internet Registry (RIR) or from RIR to a Local Internet
   Registry (LIR) possibly through a National Internet Registry (NIR).
   Address assignments, on the other hand, are the leases of smaller
   address blocks or even single addresses to the end-user sites or end-
   users themselves.

   Therefore, in this memo, we will separate the two different
   functions: "allocation" describes how larger blocks of addresses are
   obtained by the network operators, and "assignment" describes how
   applications, nodes or sets of nodes obtain a multicast address for
   their use.

Savola                   Expires April 28, 2011                 [Page 3]
Internet-Draft        Multicast Address Allocation          October 2010

2.  Multicast Address Allocation

   Multicast address allocation, i.e., how a network operator might be
   able to obtain a larger block of addresses, can be handled in a
   number of ways as described below.

   Note that these are all only pertinent to ASM -- SSM requires no
   address block allocation because the group address has only local
   significance (however, we discuss the address assignment inside the
   node in Section 3.2).

2.1.  Derived Allocation

   Derived allocations take the unicast prefix or some other properties
   of the network (e.g., an autonomous system (AS) number) to determine
   unique multicast address allocations.

2.1.1.  GLOP Allocation

   GLOP address allocation [RFC3180] inserts the 16-bit public AS number
   in the middle of the IPv4 multicast prefix, so that each
   AS number can get a /24 worth of multicast addresses.  While this is
   sufficient for multicast testing or small scale use, it might not be
   sufficient in all cases for extensive multicast use.

   A minor operational debugging issue with GLOP addresses is that 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
   calculated (e.g., from [RFC3180], AS 5662 maps to  A
   usage issue is that GLOP addresses are not tied to any prefix but to
   routing domains, so they cannot be used or calculated automatically.

   GLOP mapping is not available with 4-byte AS numbers [RFC4893].
   Unicast-prefix-based Allocation or an IANA allocation from "AD-HOC
   Block III" (the previous so-called "eGLOP" block) could be used
   instead as needed.

   The 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.

2.1.2.  Unicast-prefix-based Allocation

   RFC 3306 [RFC3306] describes a mechanism which embeds up to 64 high-
   order bits of an IPv6 unicast address in the prefix part of the IPv6
   multicast address, leaving at least 32 bits of group-id space
   available after the prefix mapping.

Savola                   Expires April 28, 2011                 [Page 4]
Internet-Draft        Multicast Address Allocation          October 2010

   A similar IPv4 mapping is described in [RFC6034], but it provides a
   limited number of addresses (e.g., 1 per an IPv4 /24 block).

   The IPv6 unicast-prefix-based allocations are an extremely useful way
   to allow each network operator, even each subnet, to obtain multicast
   addresses easily, through an easy computation.  Further, as the IPv6
   multicast header also includes the scope value [RFC4291], multicast
   groups of smaller scope can also be used with the same mapping.

   The IPv6 Embedded RP technique [RFC3956], used with Protocol
   Independent Multicast - Sparse Mode (PIM-SM), further leverages the
   unicast-prefix-based allocations, by embedding the unicast prefix and
   interface identifier of the PIM-SM Rendezvous Point (RP) in the
   prefix.  This provides all the necessary information needed to the
   routing systems to run the group in either inter- or intra-domain
   operation.  A difference from RFC 3306 is, however, that the hosts
   cannot calculate their "multicast prefix" automatically, as the
   prefix depends on the decisions of the operator setting up the RP,
   but instead requires an assignment method.

   All the IPv6 unicast-prefix-based allocation techniques provide
   sufficient amount of multicast address space for network operators.

2.2.  Administratively Scoped Allocation

   Administratively scoped multicast address allocation [RFC2365] is
   provided by two different means: under in IPv4 or by
   4-bit encoding in the IPv6 multicast address prefix [RFC4291].

   Since IPv6 administratively scoped allocations can be handled with
   unicast-prefix-based multicast addressing as described in
   Section 2.1.2, we'll only discuss IPv4 in this section.

   The IPv4 administratively scoped prefix is further
   divided into Local Scope ( and Organization Local
   Scope (; other parts of the administrative scopes are
   either reserved for expansion or undefined [RFC2365].  However, RFC
   2365 is ambiguous as to whether the enterprises or the IETF are
   allowed to expand the space.

   Topologies which act under a single administration can easily use the
   scoped multicast addresses for their internal groups.  Groups which
   need to be shared between multiple routing domains (even if not
   propagated through the Internet) are more problematic and typically
   need an assignment of a global multicast address because their scope
   is undefined.

   There is a large number of multicast applications (such as "Norton

Savola                   Expires April 28, 2011                 [Page 5]
Internet-Draft        Multicast Address Allocation          October 2010

   Ghost") which are restricted either to a link or a site, and it is
   extremely undesirable to propagate them further (beyond the link or
   the site).  Typically many such applications have been given or have
   hijacked a static IANA address assignment.  Given the fact that
   assignments to typically locally used applications come from the same
   range as global applications, implementing proper propagation
   limiting is challenging.  Filtering would be easier if a separate,
   identifiable range would be used for such assignments in the future;
   this is an area of further future work.

   There has also been work on a protocol to automatically discover
   multicast scope zones [RFC2776], but it has never been widely
   implemented or deployed.

2.3.  Static IANA Allocation

   In some rare cases, organizations may have been able to obtain static
   multicast address allocations (of up to 256 addresses) directly from
   IANA.  Typically these have been meant as a block of static
   assignments to multicast applications, as described in Section 3.4.1.
   If another means of obtaining addresses is available that approach is

   Especially for those operators that only have a 32-bit AS number and
   need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the
   previous so-called "eGLOP" block) is an option [RFC5771].

2.4.  Dynamic Allocation

   RFC 2908 [RFC2908] proposed three different layers of multicast
   address allocation and assignment, where layers 3 (inter-domain
   allocation) and layer 2 (intra-domain allocation) could be applicable
   here.  Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an
   example of the former, and Multicast Address Allocation Protocol
   (AAP) [I-D.ietf-malloc-aap] (abandoned in 2000 due lack of interest
   and technical problems) is an example of the latter.

   Both of the proposed allocation protocols were quite complex, and
   have never been deployed or seriously implemented.

   It can be concluded that dynamic multicast address allocation
   protocols provide no benefit beyond GLOP/unicast-prefix-based
   mechanisms and have been abandoned.

3.  Multicast Address Assignment

   There are a number of possible ways for an application, node or set

Savola                   Expires April 28, 2011                 [Page 6]
Internet-Draft        Multicast Address Allocation          October 2010

   of nodes to learn a multicast address as described below.

   Any IPv6 address assignment method should be aware of the guidelines
   for the assignment of group-IDs for IPv6 multicast addresses

3.1.  Derived Assignment

   There are significantly fewer options for derived address assignment
   compared to derived allocation.  Derived multicast assignment has
   only been specified for IPv6 link-scoped multicast [RFC4489], where
   the EUI64 is embedded in the multicast address, providing a node with
   unique multicast addresses for link-local ASM communications.

3.2.  SSM Assignment inside the Node

   While SSM multicast addresses have only local (to the node)
   significance, there is still a minor issue on how to assign the
   addresses between the applications running on the same IP address.

   This assignment is not considered to be a problem because typically
   the addresses for these applications are selected manually or
   statically, but if done using an Application Programming Interface
   (API), the API could check that the addresses do not conflict prior
   to assigning one.

3.3.  Manually Configured Assignment

   With manually configured assignment, a network operator who has a
   multicast address prefix assigns the multicast group addresses to the
   requesting nodes using a manual process.

   Typically, the user or administrator that wants to use a multicast
   address for a particular application requests an address from the
   network operator using phone, email, or similar means, and the
   network operator provides the user with a multicast address.  Then
   the user/administrator of the node or application manually configures
   the application to use the assigned multicast address.

   This is a relatively simple process; it has been sufficient for
   certain applications which require manual configuration in any case,
   or which cannot or do not want to justify a static IANA assignment.
   The manual assignment works when the number of participants in a
   group is small, as each participant has to be manually configured.

   This is the most commonly used technique when the multicast
   application does not have a static IANA assignment.

Savola                   Expires April 28, 2011                 [Page 7]
Internet-Draft        Multicast Address Allocation          October 2010

3.4.  Static IANA Assignment

   In contrast to manually configured assignment, as described above,
   static IANA assignment refers to getting an assignment for the
   particular application directly from IANA.  There are two main forms
   of IANA assignment: global and scope-relative.  Guidelines for IANA
   are described in [RFC5771].

3.4.1.  Global IANA Assignment

   Globally unique address assignment is seen as lucrative because it's
   the simplest approach for application developers since they can then
   hard-code the multicast address.  Hard-coding requires no lease of
   the usable multicast address, and likewise the client applications do
   not need to perform any kind of service discovery (but depending on
   hard-coded addresses).  However, there is an architectural scaling
   problem with this approach, as it encourages a "land-grab" of the
   limited multicast address space.

3.4.2.  Scope-relative IANA Assignment

   IANA also assigns numbers as an integer offset from the highest
   address in each IPv4 administrative scope as described in [RFC2365].
   For example, the SLPv2 discovery scope-relative offset is "2", so
   SLPv2 discovery address within IPv4 Local-Scope ( is
   "", within the IPv4 Organization Local-Scope
   ( it is "", and so on.

   Similar scope-relative assignments also exist with IPv6 [RFC2375].
   As IPv6 multicast addresses have much more flexible scoping, scope-
   relative assignments are also applicable to global scopes.  The
   assignment policies are described in [RFC3307].

3.5.  Dynamic Assignments

   The layer 1 of RFC 2908 [RFC2908] described dynamic assignment from
   Multicast Address Allocation Servers (MAAS) to applications and
   nodes, with Multicast Address Dynamic Client Allocation Protocol
   (MADCAP) [RFC2730] as an example.  Since then, other mechanisms have
   also been proposed (e.g., DHCPv6 assignment
   [I-D.jdurand-assign-addr-ipv6-multicast-dhcpv6]) but these have not
   gained traction.

   It would be rather straightforward to deploy a dynamic assignment
   protocol which would lease group addresses based on a multicast
   prefix to applications wishing to use multicast.  However, only few
   have implemented MADCAP, and it hasn't been significantly deployed.
   So, it is not clear if the lack of deployment is due to a currently

Savola                   Expires April 28, 2011                 [Page 8]
Internet-Draft        Multicast Address Allocation          October 2010

   missing need.  Moreover, it is not clear how widely for 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)
   [RFC2974].  In addition to advertising global multicast sessions, the
   protocol also has associated ranges of addresses for both IPv4 and
   IPv6 which can be used by SAP-aware applications to create new groups
   and new group addresses.  Creating a session (and obtaining an
   address) is a rather tedious process which is why it isn't done all
   that often.  It is also worth noting that the IPv6 SAP address is
   unroutable in the inter-domain multicast.

   A conclusion about dynamic assignment protocols is that:

   1.  multicast is not significantly attractive in the first place,

   2.  most applications have a static IANA assignment and thus require
       no dynamic or manual assignment,

   3.  those that cannot be easily satisfied with IANA or manual
       assignment (i.e., where dynamic assignment would be desirable)
       are rather marginal, or

   4.  that there are other gaps why dynamic assignments are not seen as
       a useful approach (for example, issues related to service

   In consequence, more work on rendezvous/service discovery would be
   needed to make dynamic assignments more useful.

4.  Summary and Future Directions

   This section summarizes the mechanisms and analysis discussed in this
   memo, and presents some potential future directions.

Savola                   Expires April 28, 2011                 [Page 9]
Internet-Draft        Multicast Address Allocation          October 2010

4.1.  Prefix Allocation

   A summary of prefix allocation methods for ASM is shown in Figure 1.

      | Sect. | Prefix allocation method       | IPv4   | IPv6   |
      | 2.1.1 | Derived: GLOP                  |  Yes   | NoNeed*|
      | 2.1.2 | Derived: Unicast-prefix-based  |   No   |  Yes   |
      |  2.2  | Administratively scoped        |  Yes   | NoNeed*|
      |  2.3  | Static IANA allocation         |  Yes** |   No   |
      |  2.4  | Dynamic allocation protocols   |   No   |   No   |
      *  = the need satisfied by IPv6 unicast-prefix-based allocation.
      ** = mainly using the AD-HOC block III (former "eGLOP")

                                 Figure 1

   o  Only ASM is affected by the assignment/allocation issues.

   o  With IPv4, GLOP allocations provide a sufficient IPv4 multicast
      allocation mechanism for those that have 16-bit AS number.  IPv4
      unicast-prefix based allocation offers some addresses.  IANA is
      also allocating from the AD-HOC block III (former "eGLOP") with
      especially 32-bit AS number holders in mind.  Administratively
      scoped allocations provide the opportunity for internal IPv4

   o  With IPv6, unicast-prefix-based addresses and the derivatives
      provide a good allocation strategy and this also works for scoped
      multicast addresses.

   o  Dynamic allocations are too complex and unnecessary a mechanism.

Savola                   Expires April 28, 2011                [Page 10]
Internet-Draft        Multicast Address Allocation          October 2010

4.2.  Address Assignment

   A summary of address assignment methods is shown in Figure 2.

      | Sect.  | Address assignment method      | IPv4     | IPv6     |
      |  3.1   | Derived: link-scope addresses  |  No      |   Yes    |
      |  3.2   | SSM (inside the node)          |  Yes     |   Yes    |
      |  3.3   | Manual assignment              |  Yes     |   Yes    |
      |  3.4.1 | Global IANA/RIR assignment     |LastResort|LastResort|
      |  3.4.2 | Scope-relative IANA assignment |  Yes     |   Yes    |
      |  3.5   | Dynamic assignment protocols   |  Yes     |   Yes    |

                                 Figure 2

   o  Manually configured assignment is typical today, and works to a
      sufficient degree in smaller scale.

   o  Global IANA assignment has been done extensively in the past.
      Scope-relative IANA assignment is acceptable but the size of the
      pool is not very high.  Inter-domain routing of IPv6 IANA-assigned
      prefixes is likely going to be challenging and as a result that
      approach is not very appealing.

   o  Dynamic assignment, e.g., MADCAP has been implemented, but there
      is no wide deployment.  Therefore, either there are other gaps in
      the multicast architecture or there is no sufficient demand for it
      in the first place when manual and static IANA assignments are
      available.  Assignments using SAP also exist but are not common;
      global SAP assignment is unfeasible with IPv6.

   o  Derived assignments are only applicable in a fringe case of link-
      scoped multicast.

4.3.  Future Actions

   o  Multicast address discovery/"rendezvous" needs to be analyzed at
      more length, and an adequate solution provided.  See
      [I-D.ietf-mboned-addrdisc-problems] and
      [I-D.ietf-mboned-session-announcement-req] for more.

   o  The IETF should consider whether to specify more ranges of the
      IPv4 administratively scoped address space for static allocation
      for applications which should not be routed over the Internet
      (such as backup software, etc. -- so that these wouldn't need to
      use global addresses which should never leak in any case).

Savola                   Expires April 28, 2011                [Page 11]
Internet-Draft        Multicast Address Allocation          October 2010

   o  The IETF should consider its static IANA allocations policy, e.g.,
      "locking it down" to a stricter policy (like "IETF Consensus") and
      looking at developing the discovery/rendezvous functions, if

5.  Acknowledgements

   Tutoring a couple of multicast-related papers, the latest by Kaarle
   Ritvanen [RITVANEN] convinced the author that updated multicast
   address assignment/allocation documentation is needed.

   Multicast address allocations/assignments were discussed at the
   MBONED WG session at IETF59 [MBONED-IETF59].

   Dave Thaler, James Lingard, and Beau Williamson provided useful
   feedback for the preliminary version of this memo.  Myung-Ki Shin,
   Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred
   Hoenes also suggested improvements.

6.  IANA Considerations

   This memo includes no request to IANA.

   IANA considerations in sections 4.1.1 and 4.1.2 of obsoleted and now
   Historic [RFC2908] were never implemented in IANA registry.  No
   update is necessary.

   (RFC-editor: This section may be removed prior to publication;
   alternatively, the second paragraph may be left intact.)

7.  Security Considerations

   This memo only describes different approaches to allocating and
   assigning multicast addresses, and this has no security
   considerations; the security analysis of the mentioned protocols is
   out of scope of this memo.

   Obviously, especially the dynamic assignment protocols are inherently
   vulnerable to resource exhaustion attacks, as discussed e.g., in

8.  References

Savola                   Expires April 28, 2011                [Page 12]
Internet-Draft        Multicast Address Allocation          October 2010

8.1.  Normative References

   [RFC2365]  Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
              RFC 2365, July 1998.

   [RFC3180]  Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
              BCP 53, RFC 3180, September 2001.

   [RFC3306]  Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
              Multicast Addresses", RFC 3306, August 2002.

   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, August 2002.

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, November 2004.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4489]  Park, J-S., Shin, M-K., and H-J. Kim, "A Method for
              Generating Link-Scoped IPv6 Multicast Addresses",
              RFC 4489, April 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
              March 2010.

   [RFC6034]  Thaler, D., "Unicast-Prefix-Based IPv4 Multicast
              Addresses", RFC 6034, October 2010.

8.2.  Informative References

              Handley, M. and S. Hanna, "Multicast Address Allocation
              Protocol (AAP)", June 2000.

              Savola, P., "Lightweight Multicast Address Discovery
              Problem Space", draft-ietf-mboned-addrdisc-problems-02
              (work in progress), March 2006.

              Asaeda, H. and V. Roca, "Requirements for IP Multicast

Savola                   Expires April 28, 2011                [Page 13]
Internet-Draft        Multicast Address Allocation          October 2010

              Session Announcement",
              draft-ietf-mboned-session-announcement-req-03 (work in
              progress), March 2010.

              Durand, J., "IPv6 multicast address assignment with
              draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01 (work
              in progress), February 2005.

              "MBONED WG session at IETF59",

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2375]  Hinden, R. and S. Deering, "IPv6 Multicast Address
              Assignments", RFC 2375, July 1998.

   [RFC2730]  Hanna, S., Patel, B., and M. Shah, "Multicast Address
              Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
              December 1999.

   [RFC2771]  Finlayson, R., "An Abstract API for Multicast Address
              Allocation", RFC 2771, February 2000.

   [RFC2776]  Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
              Zone Announcement Protocol (MZAP)", RFC 2776,
              February 2000.

   [RFC2908]  Thaler, D., Handley, M., and D. Estrin, "The Internet
              Multicast Address Allocation Architecture", RFC 2908,
              September 2000.

   [RFC2909]  Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
              Kumar, S., and D. Thaler, "The Multicast Address-Set Claim
              (MASC) Protocol", RFC 2909, September 2000.

   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, October 2000.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4893]  Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
              Number Space", RFC 4893, May 2007.

Savola                   Expires April 28, 2011                [Page 14]
Internet-Draft        Multicast Address Allocation          October 2010

              Ritvanen, K., "Multicast Routing and Addressing", HUT
              Report, Seminar on Internetworking, May 2004,

Appendix A.  Changes

   (To be removed prior to publication as an RFC.)

A.1.  Changes between -06 and -07

   o  Update uni-based-mcast and iana updates references to point to

A.2.  Changes between -05 and -06

   o  Editorial updates.

   o  Obsolete only RFC2908; the rest only move to Historic.

   o  Category is Informational instead of BCP (in line with the routing

   o  Move 3171bis and v4-uni-based to Normative references in order to
      make sure we don't go forward until they're resolved.

   o  Resolve pending issues per IETF75 discussion, in particular major
      changes to eGLOP and IANA policy discussions.

A.3.  Changes between -04 and -05

   o  Editorial updates.  These and the following are from Spencer

   o  New text explicitly stating that GLOP for v6 is not needed and
      GLOP for 4byte ASNs isn't (and likely won't be) defined.

   o  Expand reasons for filtering difficulties with global IANA
      assignments for local apps, and that it would be easier if these
      were done from the local pool.

   o  Explicitly mention dynamic allocations protocols' lack of benefit
      and abandonment.

Savola                   Expires April 28, 2011                [Page 15]
Internet-Draft        Multicast Address Allocation          October 2010

A.4.  Changes between -03 and -04

   o  S/scope-relative/administratively scoped/ and expand Static IANA
      Assignment section to two subsections; mainly from Dave Price.

   o  Mention the routing challenges of IPv6 IANA assigned prefixes in
      section 4.2

A.5.  Changes between -02 and -03

   o  Reword architectural implications of Static IANA and editorial
      improvements; mainly from John Kristoff.

A.6.  Changes between -01 and -02

   o  Mention the mechanisms which haven't been so successful: eGLOP and

   o  Remove the appendices on multicast address discovery (a separate
      draft now) and IPv4 unicast-prefix-based multicast addressing.

   o  Add a note on administratively scoped address space and the
      expansion ambiguity.

   o  Remove the references to draft-ietf-mboned-ipv6-issues-xx.txt

   o  Minor editorial cleanups.

Author's Address

   Pekka Savola
   CSC - Scientific Computing Ltd.


Savola                   Expires April 28, 2011                [Page 16]