RFC 2908 (rfc2908) - Page 2 of 13
The Internet Multicast Address Allocation Architecture
Alternative Format: Original Text Document
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