Network Working Group                                   Zaid Albanna
INTERNET DRAFT                                          Worldcom
                                                        Kevin Almeroth
                                                        David Meyer
                                                        Cisco Systems
                                                        Michelle Schipper
Category                                                Best Current Practices
                                                        March, 2001

         IANA Guidelines for IPv4 Multicast Address Allocation

1. Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Albanna,Almeroth,Meyer,Schipper                                 [Page 1]

Internet Draftdraft-ietf-mboned-iana-IPv4-mcast-guidelines-00.txtMarch, 2001

2. Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

3. Abstract

   This memo provides guidance for the IANA in assigning IPv4 multicast

4. Introduction

   The Internet Assigned Numbers Authority (IANA) ( is
   charged with allocating parameter values for fields in protocols
   which have been designed, created or are maintained by the Internet
   Engineering Task Force (IETF).  RFC 2780 [RFC2780] provides the IANA
   guidance in the assignment of parameters for fields in newly
   developed protocols. This memo expands on section 4.4.2 of RFC 2780
   and attempts to codify existing IANA practice used in the assignment
   IPv4 multicast addresses.

   The terms "Specification Required", "Expert Review", "IESG Approval",
   "IETF Consensus", and "Standards Action", are used in this memo to
   refer to the processes described in [RFC2434]. The keywords MUST,
   SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119

   In general, due to the relatively small size of the IPv4 multicast
   addresses space, further allocation of IPv4 multicast address space
   is not recommended. Specifically, the IANA should only assign
   addresses in those cases where the dynamic selection (SDP/SAP), GLOP,
   SSM or Administratively Scoped address spaces cannot be used. The
   guidelines described below are reflected in

Albanna,Almeroth,Meyer,Schipper                                 [Page 2]

Internet Draftdraft-ietf-mboned-iana-IPv4-mcast-guidelines-00.txtMarch, 2001

5. Definition of Current Assignment Practice

   Unlike IPv4 unicast address assignment, where blocks of addresses are
   delegated to regional registries, IPv4 multicast addresses are
   assigned directly by the IANA.  Current allocations appear as follows
   [IANA]:   -     (224.0.0/24)  Local Network Control Block   -     (224.0.1/24)  Internetwork Control Block   -                   AD-HOC Block   -   (224.1/16)    ST Multicast Groups   -   (224.2/16)    SDP/SAP Block -               DIS Transient Block   - (225/8)       MALLOC Block   -               RESERVED   - (232/8)       Source Specific Multicast Block   - (233/8)       GLOP Block   -               RESERVED   - (239/8)       Administratively Scoped Block

   The IANA generally allocates addresses from the Local Network
   Control, Internetwork Control, and AD-HOC blocks. Allocation
   guidelines for each of these blocks, as well as for the MALLOC,
   Source Specific Multicast, GLOP and Administratively Scoped Blocks,
   are described below.

   Note that while some applications may informally use arbitrary parts
   of the IPv4 multicast address space (e.g., 229/8), an application
   MUST NOT use address space that is not allocated as described in this

6. Local Network Control Block (224.0.0/24)

   Addresses in the Local Network Control block are used for protocol
   control traffic that is not forwarded off link. Examples of this type
   of use include OSPFIGP All Routers ( [RFC2328].

6.1. Allocation Guidelines

   Allocation of addresses in the Local Network Configuration Block
   SHOULD BE be accompanied by a specification ("Specification
   Required"). This specification will typically take the form of an
   internet draft or RFC.

Albanna,Almeroth,Meyer,Schipper                                 [Page 3]

Internet Draftdraft-ietf-mboned-iana-IPv4-mcast-guidelines-00.txtMarch, 2001

7. Internetwork Control Block (224.0.1/24)

   Addresses in the Internetwork Control block are used for protocol
   control that must be forwarded through the Internet. Examples include (NTP [RFC2030]) and (mdhcpdisover [RFC2730]).

7.1. Allocation Guidelines

   Allocation of addresses in the Internetwork Control block SHOULD BE
   accompanied by a specification ("Specification Required"). This
   specification will typically take the form of an internet draft or

8. AD-HOC Block ( -

   Addresses in the AD-HOC block have traditionally been allocated for
   those applications that don't fit in either the Local or Internetwork
   Control blocks. These addresses are globally routed and are typically
   used by applications that require small blocks of addressing (e.g.,
   less than a /24).

8.1. Allocation Guidelines

   Allocation of addresses in the AD-HOC Block SHOULD BE accompanied by
   a specification ("Specification Required").This specification will
   typically take the form of an internet draft or RFC. In general, the
   IANA SHOULD NOT assign addressing in the AD-HOC Block.

9. SDP/SAP Block (224.2/16)

   Addresses in the SDP/SAP block are used by applications that receive
   addresses through the Session Announcement Protocol [RFC2974] for use
   via applications like the session directory tool (such as SDR [SDR]).

9.1. Allocation Guidelines

   Since addresses in the SDP/SAP block are chosen randomly from the
   range of addresses not already in use [RFC2974], no IANA allocation
   policy is required. Note that while no additional IANA allocation is
   required, addresses in the SDP/SAP block are explicitly for use by
   SDP/SAP and MUST NOT be used for other purposes.

Albanna,Almeroth,Meyer,Schipper                                 [Page 4]

Internet Draftdraft-ietf-mboned-iana-IPv4-mcast-guidelines-00.txtMarch, 2001

10. MALLOC Block (225/8)

   Addresses in the MALLOC block are dynamically allocated by the MALLOC
   suite of protocols [RFC2908]. This assignment is temporary and MUST
   BE reviewed annually.

10.1. Allocation Guidelines

   Since addresses in the MALLOC block are chosen by elements of the
   MALLOC architecture, no IANA allocation policy is required. Note that
   while no additional IANA allocation is required, addresses in the
   MALLOC block are explicitly for allocation by MALLOC servers and MUST
   NOT be used for other purposes.

11. Source Specific Multicast Block (232/8)

   The Source Specific Multicast (SSM) block use is outlined in [SSM].
   In general, SSM is an extension of IP Multicast in which traffic is
   forwarded to receivers from only those multicast sources for which
   the receivers have explicitly expressed interest, and is primarily
   targeted at one-to-many (broadcast) applications where large receiver
   audiences require traffic from a small number of well known sources.

11.1. Allocation Guidelines

   Because the SSM model essentially makes the entire multicast address
   space local to the host, no IANA allocation policy is required. Note,
   however, that while no additional IANA allocation is required,
   addresses in the SSM block are explicitly for use by SSM and MUST NOT
   be used for other purposes.

12. GLOP Block (233/8)

   Addresses in the GLOP block are globally scoped statically assigned
   addresses. The assignment is made by mapping a domain's autonomous
   system number into the middle two octets of 233.X.Y.0/24. The mapping
   and allocation is defined in [RFC2770].

Albanna,Almeroth,Meyer,Schipper                                 [Page 5]

Internet Draftdraft-ietf-mboned-iana-IPv4-mcast-guidelines-00.txtMarch, 2001

12.1. Allocation Guidelines

   Because addresses in the GLOP block are algorithmically preassigned,
   no IANA allocation policy is required. Note that while no additional
   IANA allocation is required, addresses in the GLOP block are
   allocated for use as defined in RFC 2770 and MUST NOT be used for
   other purposes.

13. Administratively Scoped Address Block (239/8)

   Addresses in the Administratively Scoped Address block are for local
   use within a domain and are described in [RFC2365].

13.1. Allocation Guidelines

   Since addresses in this block are local to a domain, no IANA
   allocation policy is required.

13.1.1. Relative Offsets

   The relative offsets are used to ensure that a service can be located
   independent of the extent of the enclosing scope (see RFC 2770 for
   details). Since there are only 256 such offsets, the IANA should only
   assign a relative offset to a protocol that provides an infra-
   structure supporting service. See [IANA] for the current set of

14. Annual Review

   Given the dynamic nature of IPv4 multicast and its associated infra-
   structure, and the previously undocumented IPv4 multicast address
   assignment guidelines, the IANA should conduct an annual review of
   currently assigned addresses.

14.1. Address Reclamation

   During the review described above, addresses that were mis-assigned
   should, where possible, be reclaimed or reassigned. An example of an
   address block that might be reclaimed is 224.1.0/24 [RFC1190], as
   this was an experimental allocation and is not in use. In addition,
   those allocations in 224.0.1/24 that are not used for Internet-wide

Albanna,Almeroth,Meyer,Schipper                                 [Page 6]

Internet Draftdraft-ietf-mboned-iana-IPv4-mcast-guidelines-00.txtMarch, 2001

   protocol control messages (as described above) above might be

   The IANA should also review assignments in the AD-HOC, DIS Transient
   Groups, and ST Multicast Groups blocks and reclaim those addresses
   that are not in use on the global Internet (i.e, those applications
   which can use SSM, GLOP, or Administratively Scoped addressing, or
   are not globally routed).

15. Use of IANA Reserved Addresses

   Applications MUST NOT use addressing in the IANA reserved blocks.

16. Appeals Process

   An applicant that is denied a multicast assignment may ask for
   additional consideration of its application. Such appeals SHOULD be
   granted only in those cases in which (i). the applicant did not
   provide a specification, or (ii). the applicant believes that the
   IANA did not understand the technical basis on which the application
   rests (and hence the need for assignment of globally scoped

16.1. Requirements [RFC2026]

   All appeals must include a detailed and specific description of the
   facts of the dispute.

   All appeals must be initiated within two months of the public
   knowledge of the action or decision to be challenged.

   At all stages of the appeals process, the individuals or bodies
   responsible for making the decisions have the discretion to define
   the specific procedures they will follow in the process of making
   their decision.

   In all cases a decision concerning the disposition of the dispute,
   and the communication of that decision to the parties involved, must
   be accomplished within a reasonable period of time.

Albanna,Almeroth,Meyer,Schipper                                 [Page 7]

Internet Draftdraft-ietf-mboned-iana-IPv4-mcast-guidelines-00.txtMarch, 2001

16.2. Process

   When an application is appealed, the application (and specification,
   if one was provided) is to be reviewed by the IESG, indicating to the
   IANA whether the application should be accepted. The IESG MAY
   additionally employ Expert Review of the application.

16.2.1. Process Failure

   If an applicant should disagree with an action taken by the IANA and
   IESG in this process, that application should first try to clairfy
   its position with the IANA. If the IANA is unable to satisfy the
   applicant, the applicant may ask for its application (and
   specification, if one was provided) to be reviewed by the IAB.

   The IAB decision is final with respect to the question of whether an
   assignment should be made.

17. Security Considerations

   Security issues are not discussed in this memo.

18. Acknowledgments

   The authors would like to thank Joe St. Sauver and John Meylor for
   their constructive feedback and comments.

19. Author's Address:

   Zaid Albanna
   22001 Loudoun County Parkway
   Ashburn, VA. 20147

   Kevin Almeroth
   UC Santa Barbara
   Sata Barbara, CA.

   David Meyer
   Cisco Systems, Inc.
   170 Tasman Drive

Albanna,Almeroth,Meyer,Schipper                                 [Page 8]

Internet Draftdraft-ietf-mboned-iana-IPv4-mcast-guidelines-00.txtMarch, 2001

   San Jose, CA, 95134

   Michelle Schipper

20. References


   [RFC1190]       C. Topolcic, "Experimental Internet Stream
                   Protocol, Version 2 (ST-II)", RFC 1190, October,

   [RFC2026]       S. Bradner, "The Internet Standards Process --
                   Revision 3", RFC2026, October 1996.

   [RFC2030]       Mills, D., Simple Network Time Protocol (SNTP) Version 4
                   for IPv4, IPv6 and OSI", D. Mills, October 1996.

   [RFC2119]       S. Bradner, "Key words for use in RFCs to
                   Indicate Requirement Levels", RFC 2119, March,

   [RFC2328]       J. Moy,"OSPF Version 2", RFC 2328, April, 1998.

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

   [RFC2434]       Narten, T. and H. Alvestrand, "Guidelines for
                   Writing an IANA Considerations Section in RFCs",
                   BCP 26, RFC 2434, October 1998.

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

   [RFC2770]       D. Meyer, and P. Lothberg, "GLOP Addressing in 233/8",
                   RFC 2770, February, 2000

   [RFC2780]       S. Bradner and V. Paxson, "IANA Allocation Guidelines
                   For Values In the Internet Protocol and Related
                   Headers", RFC2780, March, 2000

   [RFC2908]       D. Thaler, M. Handley, D.Estrin, "The Internet Multicast

Albanna,Almeroth,Meyer,Schipper                                 [Page 9]

Internet Draftdraft-ietf-mboned-iana-IPv4-mcast-guidelines-00.txtMarch, 2001

                   Address Allocation Architecture", RFC 2908, September 2000.

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


   [SSM]           Holbrook, H., and Cain, B., "Source-Specific Multicast
                   for IP", draft-holbrook-ssm-arch-01.txt, Work in

21. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Albanna,Almeroth,Meyer,Schipper                                [Page 10]