The Internet Multicast Address Allocation Architecture
RFC 2908

Document Type RFC - Historic (September 2000; No errata)
Obsoleted by RFC 6308
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2908 (Historic)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         D. Thaler
Request for Comments: 2908                                    Microsoft
Category: Informational                                      M. Handley
                                                                  ACIRI
                                                              D. Estrin
                                                                    ISI
                                                         September 2000

         The Internet Multicast Address Allocation Architecture

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document proposes a multicast address allocation architecture
   (MALLOC) for the Internet.  The architecture is modular with three
   layers, comprising a host-server mechanism, an intra-domain server-
   server coordination mechanism, and an inter-domain mechanism.

Table of Contents

   1: Introduction ................................................  2
   2: Requirements ................................................  2
   3.1: Address Dynamics ..........................................  4
   3: Overview of the Architecture ................................  5
   4: Scoping .....................................................  7
   4.1: Allocation Scope ..........................................  8
   4.1.1: The IPv4 Allocation Scope -- 239.251.0.0/16 .............  9
   4.1.2: The IPv6 Allocation Scope -- SCOP 6 .....................  9
   5: Overview of the Allocation Process ..........................  9
   6: Security Considerations ..................................... 10
   7: Acknowledgments ............................................. 11
   8: References .................................................. 11
   9: Authors' Addresses .......................................... 12
   10: Full Copyright Statement ................................... 13

Thaler, et al.               Informational                      [Page 1]
RFC 2908                  MALLOC Architecture             September 2000

1.  Introduction

   This document proposes a multicast address allocation architecture
   (MALLOC) for the Internet, and is intended to be generic enough to
   apply to both IPv4 and IPv6 environments.

   As with unicast addresses, the usage of any given multicast address
   is limited in two dimensions:

   Lifetime:
      An address has a start time and a (possibly infinite) end time,
      between which it is valid.

   Scope:
      An address is valid over a specific area of the network.  For
      example, it may be globally valid and unique, or it may be a
      private address which is valid only within a local area.

   This architecture assumes that the primary scoping mechanism in use
   is administrative scoping, as described in RFC 2365 [1].  While
   solutions that work for TTL scoping are possible, they introduce
   significant additional complication for address allocation [2].
   Moreover, TTL scoping is a poor solution for multicast scope control,
   and our assumption is that usage of TTL scoping will decline before
   this architecture is widely used.

2.  Requirements

   From a design point of view, the important properties of multicast
   allocation mechanisms are robustness, timeliness, low probability of
   clashing allocations, and good address space utilization in
   situations where space is scare.  Where this interacts with multicast
   routing, it is desirable for multicast addresses to be allocated in a
   manner that aids aggregation of routing state.

   o  Robustness/Availability

      The robustness requirement is that an application requiring the
      allocation of an address should always be able to obtain one, even
      in the presence of other network failures.

   o  Timeliness

      From a timeliness point of view, a short delay of up to a few
      seconds is probably acceptable before the client is given an
      address with reasonable confidence in its uniqueness.  If the
      session is defined in advance, the address should be allocated as
      soon as possible, and should not wait until just before the

Thaler, et al.               Informational                      [Page 2]
RFC 2908                  MALLOC Architecture             September 2000

      session starts.  It is in some cases acceptable to change the
      multicast addresses used by the session up until the time when the
      session actually starts, but this should only be done when it
      averts a significant problem such as an address clash that was
      discovered after initial session definition.

   o  Low Probability of Clashes

      A multicast address allocation scheme should always be able to
      allocate an address that can be guaranteed not to clash with that
Show full document text