As per Relevance of the word addresses, we have this rfc below:
Network Working Group D.
Request for Comments: 2908
Category: Informational M.
D.
September 2000
The Internet Multicast Address Allocation
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document proposes a multicast address allocation
(MALLOC) for the Internet. The architecture is modular with
layers, comprising a host-server mechanism, an intra-domain server
server coordination mechanism, and an inter-domain mechanism
Table of
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.
This document proposes a multicast address allocation
(MALLOC) for the Internet, and is intended to be generic enough
apply to both IPv4 and IPv6 environments
As with unicast addresses, the usage of any given multicast
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.
example, it may be globally valid and unique, or it may be
private address which is valid only within a local area
This architecture assumes that the primary scoping mechanism in
is administrative scoping, as described in RFC 2365 [1].
solutions that work for TTL scoping are possible, they
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
this architecture is widely used
2.
From a design point of view, the important properties of
allocation mechanisms are robustness, timeliness, low probability
clashing allocations, and good address space utilization
situations where space is scare. Where this interacts with
routing, it is desirable for multicast addresses to be allocated in
manner that aids aggregation of routing state
o Robustness/
The robustness requirement is that an application requiring
allocation of an address should always be able to obtain one,
in the presence of other network failures
o
From a timeliness point of view, a short delay of up to a
seconds is probably acceptable before the client is given
address with reasonable confidence in its uniqueness. If
session is defined in advance, the address should be allocated
soon as possible, and should not wait until just before
Thaler, et al. Informational [Page 2]
RFC 2908 MALLOC Architecture September 2000
session starts. It is in some cases acceptable to change
multicast addresses used by the session up until the time when
session actually starts, but this should only be done when
averts a significant problem such as an address clash that
discovered after initial session definition
o Low Probability of
A multicast address allocation scheme should always be able
allocate an address that can be guaranteed not to clash with
of another session. A top-down partitioning of the address
would be required to completely guarantee that no clashes
occur
o Address Space Packing in Scarcity
In situations where address space is scarce, simply
the address space would result in significant fragmentation of
address space. This is because one would need enough
space in each address space partition to give a reasonable
of assurance that addresses could still be allocated for
significant time in the event of a network partition.
addition, providing backup allocation servers in such a hierarchy
so that fail-over (including partitioning of a server and
backup from each other) does not cause collisions would
further to the address space fragmentation
Since guaranteeing no clashes in a robust manner
partitioning the address space, providing a hard guarantee
to inefficient address space usage. Hence, when address space
scarce, it is difficult to achieve constant availability
timeliness, guarantee no clashes, and achieve good address
usage. As a result, we must prioritize these properties.
believe that, when address space is scarce, achieving good
space packing and constant availability are more important
guaranteeing that address clashes never occur. What we aim for
these situations is a very high probability that an address
does not occur, but we accept that there is a finite
of this happening. Should a clash occur (or should an
start using an address it did not allocate, which may also lead
a clash), either the clash can be detected and addresses changed
or hosts receiving additional traffic can prune that traffic
source-specific prunes available in IGMP version 3, and so we
not believe that this is a disastrous situation
In summary, tolerating the possibility of clashes is likely
allow allocation of a very high proportion of the address space
the presence of network conditions such as those observed in [3].
Thaler, et al. Informational [Page 3]
RFC 2908 MALLOC Architecture September 2000
We believe that we can get good packing and good availability
good collision avoidance, while we would have to
packing and availability significantly to avoid all collisions
Finally, in situations where address space is not scarce, such
with IPv6, achieving good address space usage is less important
and hence partitioning may potentially be used to guarantee
collisions among hosts that use this architecture
2.1. Address
Multicast addresses may be allocated in any of three ways
Static
Statically allocated addresses are allocated by IANA for
protocols that require well-known addresses to work. Examples
static addresses are 224.0.1.1 which is used for the Network
Protocol [13] and 224.2.127.255 which is used for global
multicast session announcements. Applications that use
for bootstrap purposes should not normally be given their
static multicast address, but should bootstrap themselves using
well-known service location address which can be used to
the binding between local services and multicast addresses
Static addresses typically have a permanent lifetime, and a
defined by the scope range in which they reside. As such,
static address is valid everywhere (although the set of
may be different depending on location), and may be hard-
into applications, devices, embedded systems, etc.
addresses are also useful for devices which support sending
not receiving multicast IP datagrams (Level 1 conformance
specified in RFC 1112 [7]), or even are incapable of receiving
data at all, such as a wireless broadcasting device
Scope-relative
RFC 2365 [1] reserves the highest 256 addresses in
administrative scope range for relative assignments.
assignments are made by IANA and consist of an offset which
valid in every scope. Relative addresses are reserved
infrastructure protocols which require an address in every scope
and this offset may be hard-coded into applications, devices
embedded systems, etc. Such devices must have a way (e.g.
MZAP [9] or via MADCAP [4]) to obtain the list of scopes in
they reside
Thaler, et al. Informational [Page 4]
RFC 2908 MALLOC Architecture September 2000
The offsets assigned typically have a permanent lifetime, and
valid in every scope and location. Hence, the scope-
address in a given scope range has a lifetime equal to that of
scope range in which it falls
Dynamic
For most purposes, the correct way to use multicast is to obtain
dynamic multicast address. These addresses are provided on
and have a specific lifetime. An application should request
address only for as long as it expects to need the address.
some circumstances, an address will be granted for a period
time that is less than the time that was requested. This
occur rarely if the request is for a reasonable amount of time
Applications should be prepared to cope with this when it occurs
At any time during the lifetime of an existing address
applications may also request an extension of the lifetime,
such extensions will be granted when possible. When the
extension is not granted, the application is expected to request
new address to take over from the old address when it expires,
to be able to cope with this situation gracefully. As
unicast addresses, no guarantee of reachability of an address
provided by the network once the lifetime expires
These restrictions on address lifetime are necessary to allow
address allocation architecture to be organized around
usage patterns in a manner that ensures addresses are
and multicast routing is reasonably close to optimal.
contrast, statically allocated addresses may be given sub-
routing
3. Overview of the
The architecture is modular so that each layer may be used, upgraded
or replaced independently of the others. Layering also
isolation, in that different mechanisms at the same layer can be
by different organizations without adversely impacting other layers
There are three layers in this architecture (Figure 1). Note
these layer numbers are different from the layer numbers in
TCP/IP stack, which describe the path of data packets
Thaler, et al. Informational [Page 5]
RFC 2908 MALLOC Architecture September 2000
+--------------------------+ +------------------------+
| | | |
| to other peers | | to other peers |
| || // | | || // || |
| Prefix | | Prefix Prefix |
| Coordinator | |Coordinator Coordinator
+------------||------------+ +-------||----//---------+
||Layer 3 || //
+------------||------------------------------||--//-----------+
| Prefix Prefix |
| Coordinator=======================Coordinator |
| ^ ^ |
| +----------------+-------------+ |
| | Layer 2 | | |
| MAAS<---/ | +---> MAAS |
| ^ ^ v ^ |
| . . MAAS . |
| . .Layer 1 ^ .Layer 1 |
| v v .Layer 1 v |
| Client Client v Client |
| Client |
+-------------------------------------------------------------+
Figure 1: An Overview of the Multicast Address Allocation
Layer 1
A protocol or mechanism that a multicast client uses to request
multicast address from a multicast address allocation
(MAAS). When the server grants an address, it becomes
server's responsibility to ensure that this address is not
reused elsewhere within the address's scope during the
granted
Examples of possible protocols or mechanisms at this layer
MADCAP [4], HTTP to access a web page for allocation, and
static address assignments
An abstract API for applications to use for dynamic allocation
independent of the Layer 1 protocol/mechanism in use, is given
[11].
Layer 2
An intra-domain protocol or mechanism that MAAS's use
coordinate allocations to ensure they do not allocate
addresses. A MAAS must have stable storage, or some
robustness mechanism, to ensure that uniqueness is
across MAAS failures and reboots
Thaler, et al. Informational [Page 6]
RFC 2908 MALLOC Architecture September 2000
MAASs also use the Layer 2 protocol/mechanism to acquire (
"Prefix Coordinators") the ranges of multicast addresses out
which they may allocate addresses
In this document we use the term "allocation domain" to mean
administratively scoped multicast-capable region of the network
within which addresses in a specific range may be allocated by
Layer 2 protocol/mechanism
Examples of protocols or mechanisms at this layer include AAP [5],
and manual configuration of MAAS's
Layer 3
An inter-domain protocol or mechanism that allocates
address ranges (with lifetimes) to Prefix Coordinators
Individual addresses may then be allocated out of these ranges
MAAS's inside allocation domains as described above
Examples of protocols or mechanisms at this layer include MASC [6]
(in which Prefix Coordinators are typically routers without
stable storage requirement), and static allocations by AS
as described in [10] (in which Prefix Coordinators are
human administrators).
Each of the three layers serves slightly different purposes and
such, protocols or mechanisms at each layer may require
design tradeoffs
4.
To allocate dynamic addresses within administrative scopes, a
must be able to learn which scopes are in effect, what their
ranges and names are, and which addresses or subranges within
scope are valid for dynamic allocation by the MAAS
The first two tasks, learning the scopes in effect and the
range and name(s) of each scope, may be provided by
configuration or dynamically learned. For example, a MAAS may
passively listen to MZAP [9] messages to acquire this information
To determine the subrange for dynamic allocation, there are two
for each scope, corresponding to small "indivisible" scopes, and
"divisible" scopes. Note that MZAP identifies which scopes
divisible and which are not
(1) For small scopes, the allocation domain corresponds to the
topology within the administrative scope. Hence, all
inside the scope may use the entire address range (minus the
Thaler, et al. Informational [Page 7]
RFC 2908 MALLOC Architecture September 2000
256 addresses reserved as scope-relative addresses), and use
Layer 2 mechanism/protocol to coordinate allocations. For
scopes, Prefix Coordinators are not involved
Hence, for small scopes, the effective "allocation domain"
may be different for different scopes. Note that a small
indivisible scope could be larger or smaller than the
Scope used for big scopes (see below).
(2) For big scopes (including the global scope), the area inside
scope may be large enough that simply using a Layer 2
mechanism/protocol may be inefficient or otherwise undesirable
In this case, the scope must span multiple allocation domains
and the Layer 3 mechanism/protocol must be used to divvy up
scoped address space among the allocation domains. Hence, a
may learn of the scope via MZAP, but must acquire a subrange
which to allocate from a Prefix Coordinator
For simplicity, the effective "allocation domain" area will
the same for all big scopes, being the granularity at which
big scopes are divided up. We define the administrative scope
this granularity to be the "Allocation Scope".
4.1. Allocation
The Allocation Scope is a new administrative scope, defined in
document and to be reserved by IANA with values as noted below.
is the scope that is used by a Layer 2 protocol/mechanism
coordinate address allocation for addresses in larger,
scopes
We expect that the Allocation Scope will often coincide with
unicast Autonomous System (AS) boundary
If an AS is too large, or the network administrator wishes to
different intra-domain multicast routing in different parts of an AS
that AS can be split by manual setup of an allocation scope
that is not an AS boundary. This is done by setting up a
boundary dividing the unicast AS into two or more
allocation domains
If an AS is too small, and address space is scarce, address
fragmentation may occur if the AS is its own allocation domain
Here, the AS can instead be treated as part of its provider'
allocation domain, and use a Layer 2 protocol/mechanism to
allocation between its MAAS's (if any) and those of its provider.
AS should probably take this course of action if
Thaler, et al. Informational [Page 8]
RFC 2908 MALLOC Architecture September 2000
o it is connected to a single provider
o it does not provide transit for another AS,
o it needs fewer than (say) 256 multicast addresses of larger
AS scope allocated on average
4.1.1. The IPv4 Allocation Scope -- 239.251.0.0/16
The address space 239.251.0.0/16 is to be reserved for the
Scope. The ranges 239.248.0.0/16, 239.249.0.0/16 and 239.250.0.0/16
are to be left unassigned and available for expansion of this space
These ranges should be left unassigned until the 239.251.0.0/16
is no longer sufficient
4.1.2. The IPv6 Allocation Scope -- SCOP 6
The IPv6 "scop" value 6 is to be used for the Allocation Scope
5. Overview of the Allocation
Once Layer 3 allocation has been performed for large,
scopes, and each Prefix Coordinator has acquired one or more ranges
then those ranges are passed to all MAAS's within the
Coordinator's domain via a Layer 2 mechanism/protocol
MAAS's within the domain receive these ranges and store them as
currently allowable addresses for that domain. Each range is
for a given lifetime (also acquired via the Layer 3
mechanism/protocol) and is not revoked before the lifetime
expired. MAAS's also learn of small scopes (e.g., via MZAP)
store the ranges associated with them
Using the Layer 2 mechanism/protocol, each MAAS ensures that it
exclude any addresses which have been or will be allocated by
MAAS's within its domain
When a client needs a multicast address, it first needs to
what the scope of the intended session should be, and locate a
capable of allocating addresses within that scope
To pick a scope, the client will either simply choose a well-
scope, such as the global scope, or it will enumerate the
scopes (e.g., by sending a MADCAP query, or by listening to
messages over time) and allow a user to select one
Thaler, et al. Informational [Page 9]
RFC 2908 MALLOC Architecture September 2000
Locating a MAAS can be done via a variety of methods,
manual configuration, using a service location protocol such as
[12], or via a mechanism provided by a Layer 1 protocol itself
MADCAP, for instance, includes such a facility
Once the client has chosen a scope and located a MAAS, it
requests an address in that scope from the MAAS located. Along
the request it also passes the acceptable range for the lifetimes
the allocation it desires. For example, if the Layer 1 protocol
use is MADCAP, the client sends a MADCAP REQUEST message to the MAAS
and waits for a NAK message or an ACK message containing
allocated information
Upon receiving a request from a client, the MAAS then chooses
unused address in a range for the specified scope, with a
which both satisfies the acceptable range specified by the client
and is within the lifetime of the actual range
The MAAS uses the Layer 2 mechanism/protocol to ensure that such
address does not clash with any addresses allocated by other MAASs
For example, if Layer 2 uses manual configuration of non-
ranges, then this simply consists of adhering to the range
in the local MAAS. If, on the other hand, AAP is used at Layer 2
provide less address space fragmentation, the MAAS advertises
proposed allocation domain-wide using AAP. If no clashing AAP
is received within a short time interval, then the address
returned to the client via the Layer 1 protocol/mechanism. If
clashing claim is received by the MAAS, then it chooses a
address and tries again. AAP also allows each MAAS to pre-reserve
small "pool" of addresses for which it need not wait to
clashes
If a domain ever begins to run out of available multicast addresses
a Prefix Coordinator in that domain uses the Layer 3
protocol/mechanism to acquire more space
6. Security
The architecture described herein does not prevent an
from just sending to or joining a multicast address
allocating it (just as the same is true for unicast addresses today).
However, there is no guarantee that data for unallocated
will be delivered by the network. That is, routers may drop data
unallocated addresses if they have some way of checking whether
destination address has been allocated. For example, if the
routers of a domain participate in the Layer 2 protocol/mechanism
cache the set of allocated addresses, then data for
Thaler, et al. Informational [Page 10]
RFC 2908 MALLOC Architecture September 2000
addresses in a range allocated by that domain can be dropped
creating multicast forwarding state with an empty outgoing
list and/or pruning back the tree branches for those groups
A malicious application may attempt a denial-of-service attack
attempting to allocate a large number of addresses, thus
to exhaust the supply of available addresses. Other attacks
releasing or modifying the allocation of another party.
attacks can be combatted through the use of authentication
policy restrictions (such as a maximum number of addresses that
be allocated by a single party).
Hence, protocols/mechanisms that implement layers of
architecture should be deployable in a secure fashion. For example
one should support authentication with policy restrictions,
should not allow someone unauthorized to release or modify
allocation of another party
7.
Steve Hanna provided valuable feedback on this document. The
of the MALLOC WG and the MBone community provided the motivation
this work
8.
[1] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
2365, July 1998.
[2] Mark Handley, "Multicast Session Directories and
Allocation", Chapter 6 of PhD Thesis entitled "On
Multimedia Conferencing Systems", University of London, 1997.
[3] Mark Handley, "An Analysis of Mbone Performance", Chapter 4
PhD Thesis entitled "On Scalable Multimedia
Systems", University of London, 1997.
[4] Hanna, S., Patel, B. and M. Shah, "Multicast Address
Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[5] Handley, M. and S. Hanna, "Multicast Address Allocation
(AAP)", Work in Progress
[6] Estrin, D., Govindan, R., Handley, M., Kumar, S., Radoslavov, P
and D. Thaler, "The Multicast Address-Set Claim (MASC
Protocol", RFC 2909, September 2000.
Thaler, et al. Informational [Page 11]
RFC 2908 MALLOC Architecture September 2000
[7] Deering, S., "Host Extensions for IP Multicasting", STD 5,
1112, August 1989.
[8] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[9] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope
Announcement Protocol (MZAP)", RFC 2776, February 2000.
[10] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC 2770,
February 2000.
[11] Finlayson, R., "Abstract API for Multicast Address Allocation",
RFC 2771, February 2000.
[12] Guttman, E., Perkins, C., Veizades, J. and M. Day, "
Location Protocol, Version 2", RFC 2608, June 1999.
[13] Mills, D., "Network Time Protocol (Version 3) Specification
Implementation and Analysis", RFC 1305, March 1992.
9. Authors'
Dave
Microsoft
One Microsoft
Redmond, WA 98052-6399
EMail: dthaler@microsoft.
Mark
AT&T Center for Internet Research at
1947 Center St, Suite 600
Berkeley, CA 94704
EMail: mjh@aciri.
Deborah
Computer Science Dept/
University of Southern
Los Angeles, CA 90089
EMail: estrin@usc.
Thaler, et al. Informational [Page 12]
RFC 2908 MALLOC Architecture September 2000
10. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Thaler, et al. Informational [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
