NETWORK Working Group Octavian Catrina, Editor
INTERNET-DRAFT International University
Category: Standards Track Dave Thaler
19 February 2001 Bernard Aboba
Expires in six months Microsoft
Erik Guttman
Sun Microsystems
Zeroconf Multicast Address Allocation Protocol (ZMAAP)
<draft-ietf-zeroconf-zmaap-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
Today, with the rapid rise of home networking, there is an increasing
need for auto-configuration mechanisms. This document specifies a
protocol to be used on small networks without a multicast address
allocation server in order to allow peer to peer allocation of
multicast addresses.
Catrina, et. al. Expires: 21 July 2001 [Page 1]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . .
2. Terminology . . . . . . . . . . . . . . . . . . . . . . .
3. Requirements and Design Considerations . . . . . . . . . .
4. Zeroconf Multicast Address Allocation Protocol . . . . . .
4.1 Protocol Overview . . . . . . . . . . . . . . . . . . .
4.1.1 Address Allocation Record . . . . . . . . . . . . . .
4.1.2 ZMAAP Claim and Defend Interactions . . . . . . . . .
4.1.3 Renewing and Releasing Allocations . . . . . . . . . .
4.1.4 Multicast Transmission of ZMAAP Messages . . . . . . .
4.2 Protocol Messages . . . . . . . . . . . . . . . . . . .
4.2.1 Message Header . . . . . . . . . . . . . . . . . . . .
4.2.2 Time Fields . . . . . . . . . . . . . . . . . . . . .
4.2.3 Lease Descriptors . . . . . . . . . . . . . . . . . .
4.3 Sending Periodic Advertisements . . . . . . . . . . . .
4.4 Address Allocation . . . . . . . . . . . . . . . . . . .
4.4.1 Learning Current Allocations . . . . . . . . . . . . .
4.4.2 Address Selection . . . . . . . . . . . . . . . . . .
4.4.3 Address Claiming . . . . . . . . . . . . . . . . . . .
4.4.4 Advertising a New Allocation . . . . . . . . . . . . .
4.5. Shared Control of an Address Allocation . . . . . . . .
4.6 Changing the allocation lifetime . . . . . . . . . . . .
4.7 Processing Received ACLM Messages . . . . . . . . . . .
4.8 Processing Received AIU Messages . . . . . . . . . . . .
5. Transitions between environments . . . . . . . . . . . . .
5.1 Transition requirements . . . . . . . . . . . . . . . .
5.2 Zero-configuration host behavior . . . . . . . . . . . .
5.2.1 Multicast Scope Enumeration . . . . . . . . . . . . .
5.2.2 Multicast Address Allocation . . . . . . . . . . . . .
5.2.3 Host Transitioning Rules . . . . . . . . . . . . . . .
5.3 Zero-configuration router behavior . . . . . . . . . . .
5.3.1 Scope Enumeration . . . . . . . . . . . . . . . . . .
5.3.2 Address Allocation . . . . . . . . . . . . . . . . . .
5.3.3 Router Transitioning Rules . . . . . . . . . . . . . .
6. Timer Default Values . . . . . . . . . . . . . . . . . . .
7. Security Considerations . . . . . . . . . . . . . . . . .
8. IANA Considerations . . . . . . . . . . . . . . . . . . .
Appendix A: Compatibility issues with AAP . . . . . . . .
Appendix B: Application Programmer Interface (API) Issues
Appendix C: Session Management Implications . . . . . . .
Appendix D: Open Issues . . . . . . . . . . . . . . . . .
Acknowledgments . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . .
Author's Contact Information . . . . . . . . . . . . . . .
Full Copyright Statement . . . . . . . . . . . . . . . . .
Catrina, et. al. Expires: 21 July 2001 [Page 2]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
1. Introduction
The Internet Multicast Address Allocation Architecture [1] provides a
framework which includes multicast address allocation servers (MAASs)
that allocate addresses to hosts. The Multicast Address Dynamic
Client Allocation Protocol (MADCAP) [2] has been proposed as the
protocol via which hosts and servers communicate.
However, servers and network administration staff are not available
in all environments. Home networks and ad-hoc networks, for example,
need to rely entirely on zero-configuration protocols [14]. This
document defines the Zeroconf Multicast Address Allocation Protocol
(ZMAAP), that allows hosts on small networks without a multicast
address allocation server to allocate multicast addresses using a
peer to peer protocol.
2. Terminology
This document uses the following terms:
Multicast
IP Multicast, as defined in [10] and [11].
Multicast Address
An IP multicast address or group address, as defined in [10]
and [3]. An identifier for a group of nodes.
Multicast Scope
A range of multicast addresses configured so that traffic
sent to these addresses is limited to some subset of the
internetwork. See [6] and [3].
Multicast Address Allocation Server (MAAS)
A host providing multicast address allocation services to
network clients.
Mini-MAAS
A process providing multicast address allocation services to
application processes running on the same host. Mini-MAASs
cooperate to provide network-wide services in small networks
without MAASs.
Configured environment
A network area (such as the Internet or an enterprise network)
which is managed by one or more administrators or organizations.
Zero-configuration environment
A network area consisting of devices which have no manual
configuration done to them, and are not managed by an
administrator or organization.
Catrina, et. al. Expires: 21 July 2001 [Page 3]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
There are two primary zero-configuration scenarios which we
distinguish from a configured environment in this document.
Isolated
A group of hosts communicate as peers in a zero-configuration
environment. In this scenario, there are no address allocation
servers, and likely no routers.
Edge
In this scenario, we assume there is a router which connects a
zero-configuration environment to a configured environment
such as the Internet. In this scenario, there are no address
allocation servers configured in the zero-configuration area,
and there may or may not be servers in the configured
environment.
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [4].
3. Requirements and Design Considerations
As described in [5], a host provides two main services to its
multicast applications through some API. First, it must allow
applications to enumerate the set of available multicast scopes.
Second, it must allow applications to dynamically allocate multicast
addresses in scopes they specify (request, renew, and release
addresses). Note that acquiring a set of scopes does not necessarily
imply that addresses are available in each scope, only that it is
legal for an application to request an address in one.
In a configured environment all these services are provided by MAASs,
using MADCAP, a client-server protocol (see [1] and [2]).
Applications use MADCAP to discover MAASs (MADCAP servers), enumerate
available multicast scopes, and dynamically allocate addresses. MAASs
learn the multicast scopes in effect either through manual
configuration, or (preferably) automatically by listening to MZAP [8]
scope announcements.
MADCAP servers may not be present in a zero-configuration
environment. Each host instantiates its own mini-MAAS to handle the
allocations requested by its applications. These mini-MAASs need a
peer-to-peer protocol to coordinate their allocations (avoid multiple
allocations of the same address). ZMAAP has been defined for this
purpose.
In the absence of MADCAP servers and MZAP scope announcements, the
mini-MAASs can only allocate in particular well-known multicast
scopes with specified address ranges. For IPv4, they can allocate in
the Local scope [6] and the Single-source multicast address range
[7]. For IPv6, the set of ranges includes: Interface-local scope [3],
Catrina, et. al. Expires: 21 July 2001 [Page 4]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
Link-local scope [3], Admin-local scope [3], Site-local scope [3] and
Unicast-prefixed-based multicast addresses (including Source-specific
addresses) [13].
Applications can obtain the following services from a Mini-MAAS
making use of ZMAAP:
- Obtain an enumeration of supported multicast scopes.
- Allocate an address in a specified scope, for a limited time.
- Change the lifetime of an allocated address.
- Deallocate an address (set its lifetime to zero).
- Get notified when an allocation has been cancelled by the mini-
MAAS due to an allocation conflict.
- Register to share the control of an existing allocation made by
another application process (to change the lifetime and get
notified about an allocation conflict).
ZMAAP must satisfy the general requirements for multicast address
allocation mechanisms specified in [1]: robustness, availability and
low probability of clashes in the presence of host and network
failures, short allocation delay and efficient use of the address
space. Note that ZMAAP is expected to work in a particularly
unreliable environment (for example on laptops in an ad-hoc network,
that can be switched off and back on at any moment).
Hosts should be able to allocate multicast addresses in a configured
environment as well as in a zero-configuration environment. For any
multicast scopes in which the mini-MAASs as well as the MADCAP
servers can allocate addresses, special mechanisms must be provided
for transitions between these environments (the Local scope, for
example). For this purpose, a MADCAP client can be used in
conjunction with ZMAAP, to determine if servers are present or not,
and to enable transitions.
4. Zeroconf Multicast Address Configuration Protocol
4.1 Protocol Overview
ZMAAP is a peer-to-peer protocol that allows mini-MAASs to coordinate
their multicast address allocations. Two messages are used for this
purpose: Address In Use (AIU) and Address Claim (ACLM).
4.1.1 Address Allocation Record
A mini-MAAS MUST maintain state information for its own allocations.
It MAY also maintain state information for allocations made by the
other mini-MAASs, learned from received ZMAAP messages. The state
information is stored for the duration of the allocation's lifetime
and updated according to received ZMAAP messages and local
application requests. A unique identifier ("lease identifier") is
associated with each allocation to distinguish allocations of the
same addresses made by different mini-MAASs.
Catrina, et. al. Expires: 21 July 2001 [Page 5]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
In ZMAAP, the application process that requests an allocation and the
local mini-MAAS that provides it have by default the control of that
allocation (to maintain it or release it). However, ZMAAP also
provides mechanisms that enable multicast sessions to continue
without the allocator. Other session participants can share the
control of the address allocation by registering with their local
mini-MAASs and indicating the lease identifier (learned from the
session initiator via some session announcement mechanism).
Registered participants can change the allocation lifetime and are
notified if the allocation is canceled due to a conflict.
Authorization and coordination of the participants for this shared
control remains entirely the responsibility of the multicast
application and are out of the scope of this specification.
4.1.2 ZMAAP Claim and Defend Interactions
To obtain a multicast address allocation, an application issues a
request to the local mini-MAAS indicating the scope, the number of
addresses and the desired lifetime. The mini-MAAS selects addresses
in the specified scope which it believes to be free (e.g., random
choice among addresses that do not appear in its allocation record).
Then, it uses ZMAAP claiming procedure to check with the other mini-
MAASs if the addresses have already been allocated.
Claiming consists in multicasting several times, at increasing
intervals, an ACLM message that indicates a lease id, the desired
addresses and the lifetime. When receiving an ACLM, the other mini-
MAASs check their records to determine if the addresses appear as
allocated. If so, the existing allocation must be defended. The
defense consists in multicasting an AIU message that indicates the
lease id, the addresses and the lifetime of the existing allocation.
If the claimant mini-MAAS receives an AIU, it gives up claiming,
selects other addresses and tries again. If the claiming terminates
without reception of an AIU, the claimant commits the allocation and
announces this by multicasting an AIU message.
Mini-MAASs that record only their own allocations can operate
efficiently and with low probability of conflicting allocations if
they allocate only a small part of the address space in a multicast
scope. With random address selection from a sparsely used address
space, most of the claims succeed. In the presence of the allocator,
the claim/defend procedure prevents conflicting allocations. If the
allocator is absent, possible (but rather unlikely) conflicting
claims remain undetected. For example, the allocator may be isolated
by a temporary network partition or shut down.
A mini-MAAS MAY maintain records of allocations made by other mini-
MAASs to improve operation in the absence of the allocator and/or
when larger parts of the address space is allocated. A mini-MAAS can
build up a cache of any allocations learned from received AIU
messages. Alternatively, such records are added only when local
Catrina, et. al. Expires: 21 July 2001 [Page 6]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
applications register to share the control of existing allocations
they use. When a mini-MAAS receives such a request, it uses the
claiming procedure described above to check if the allocation exists
and initialize its record.
A mini-MAAS that made an allocation MUST defend it against claims by
multicasting immediately an AIU message. Other mini-MAASs that
recorded the allocation can also detect the conflicting claim. They
MAY defend the allocation when the owner is unable to do so. To avoid
bursts of AIUs, they wait a random time before trying to defend and,
if they receive an AIU defending the allocation, cancel their own
transmission.
Allocation conflicts may still occasionally occur. When an AIU
message is received indicating an address allocation with a lease id
different from the recorded one, the allocation record is updated
according to the AIU. In particular, a mini-MAAS which allocated an
address and learns from an AIU that the same address is also
allocated by another mini-MAAS MUST give up the address in favor of
the other one. In such cases, registered local processes that use the
cancelled allocation should be notified.
(Remark: When address ranges are allocated, this can become quite
tricky. A range in the received AIU may (partially) overlap with one
or more ranges in the allocation record.)
4.1.3 Renewing and Releasing Allocations
An application can change the lifetime of an allocation it controls
by issuing a request to its local mini-MAAS indicating the lease
identifier and the new lifetime. The local mini-MAAS updates its
record and multicasts an AIU message indicating the new lifetime.
It is possible to extend or to reduce the current lifetime and, in
particular, to deallocate an address by setting a zero lifetime.
4.1.4 Multicast Transmission of ZMAAP Messages
All ZMAAP messages are multicast using UDP. The reserved UDP port
number is TBD. The address allocations communicated in any message
MUST belong to the same multicast scope. All messages are sent to a
reserved IPv4 scope-relative multicast address, or IPv6 variable
scope multicast address, called in the following the ZMAAP multicast
address. These address assignments are TBD. The destination address
of a message MUST be in the same multicast scope as the address
allocations it contains. A mini-MAAS MUST listen to messages sent to
the ZMAAP multicast address for all scopes in which it is active.
ZMAAP messages MUST be transmitted with values as defined below, in
Table 1.
Catrina, et. al. Expires: 21 July 2001 [Page 7]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
IPv6 Hop Limit
Allocation Scope IPv4 TTL Source Address Scope
---------------- -------- --------------------
IPv4 Local Scope [6] 255 IPv4 routable address
IPv4 Singe-Source [7] 255 IPv4 routable address
IPv6 Interface-Local [3] 1 IPv6 any scope
IPv6 Link-Local [3] 1 IPv6 any scope
IPv6 Admin-Local [3] 255 Site or Global
IPv6 Site-Local [3] 255 Site or Global
IPv6 Unicast-Prefixed [13] 255 IPv6 any scope
Table 1: ZMAAP Multicast Transmission Values
ZMAAP messages MUST NOT be multicast with a Link-Local IPv4 source
addresses [15]. Likewise, ZMAAP messages transmitted with Admin- or
Site-Local scope MUST NOT be multicast with a IPv6 Link-Local source
address.
4.2 Protocol Messages
ZMAAP uses two messages: Address In Use (AIU) and Address Claim
(ACLM). ZMAAP implementations MUST support both these messages.
The ACLM message is used by a mini-MAAS to announce an address
allocation it wants to make.
The AIU message is used to announce address allocations that have
been committed, defend them against claims and change their lifetime.
The ZMAAP messages have the following common format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZMAAP Header (8) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease descriptor 1 (variable) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease descriptor N (variable) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Catrina, et. al. Expires: 21 July 2001 [Page 8]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
4.2.1. Message Header
The ZMAAP message header has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Must be Zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Version field indicates the ZMAAP version. It MUST be 1 for the
version described in this document.
The Message Type field defines the type of ZMAAP message. The
following values are defined:
Value Message type
----- ------------
0 Address Claim (ACLM)
1 Address In Use (AIU)
The Address Family field indicates the address family for all the
addresses in the ZMAAP message, using the values defined by IANA
[12]. This version of ZMAAP supports the IPv4 and IPv6 address
families:
Value Address Family
----- --------------
1 IPv4
2 IPv6
4.2.2 Time Fields
ZMAAP messages contain relative times represented as unsigned 32 bit
integers representing a number of seconds until the data in the
message is no longer valid.
4.2.3 Lease Descriptors
Address allocations are described in ZMAAP messages using Lease
Descriptors. All the addresses belong to the address family indicated
by the Address Family field in the message header.
An IPv4 address is represented by 4 bytes in network byte order. The
lease descriptor for IPv4 addresses has the following format:
Catrina, et. al. Expires: 21 July 2001 [Page 9]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial address in the range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Final address in the range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An IPv6 address is represented by 16 bytes in network byte order.
The lease descriptor for IPv6 addresses has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initial address in the range |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Final address in the range |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease-Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The initial and final addresses define the range of addresses claimed
or allocated. When individual addresses are allocated rather than
ranges, the Initial and Final addresses are identical.
Lease-Time is the relative time when the allocation terminates, with
respect to message transmission time. The Lease-Time SHOULD not be
set to more than [MAX-LEASE] seconds.
The Lease Identifier is used to distinguish allocations of the same
address range made by different mini-MAASs. It is assigned by the
allocator mini-MAAS, using an implementation dependent method. For
example, it can be computed as a hash of the allocator's address and
the allocation time (and UDP transmission port in case more than one
mini-MAAS resides on the same host).
The number of lease descriptors in a ZMAAP message is limited by the
condition that the message fits into a payload of maximum 576 bytes
for IPv4 packets and 1280 bytes for IPv6 packets. If the number of
Catrina, et. al. Expires: 21 July 2001 [Page 10]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
lease descriptors is too large to fit into the maximum payload, they
are sent in separate ZMAAP messages.
4.3. Periodic Advertisments
A mini-MAAS MUST NOT send AIU messages periodically for the addresses
that it currently has allocated.
4.4 Address Allocation
4.4.1 Learning Current Allocations
A mini-MAAS MAY build up a cache of address allocations using the AIU
messages sent by other mini-MAASs. This cache can decrease the
likelihood of conflicts when the mini-MAAS claims an address.
4.4.2 Address Selection
To allocate multicast addresses, an application issues a request to
the local mini-MAAS, indicating the scope, the number of addresses
desired, and the lifetime. The mini-MAAS selects free addresses by
consulting its allocation records and creates a lease descriptor. To
reduce the likelihood of collisions, a random selection of the free
addresses is strongly recommended.
4.4.3 Address Claiming
The mini-MAAS starts the claiming by sending an ACLM message
containing the lease descriptor. After sending the ACLM message it
MUST start a Claim Timer for [ANNOUNCE-WAIT] seconds. Also, it SHOULD
resend the ACLM message, first after [RESEND-WAIT] seconds, and later
doubling each time the interval, until either the Claim Timer
expires, or the claim is aborted.
If the mini-MAAS receives an AIU message or an ACLM message listing
addresses being claimed, it MUST abort the claiming, stop the Claim
Timer, and give up on the addresses indicated in the AIU or ACLM
message. It MAY select new addresses and restart the claiming
procedure.
If the Claim Timer expires, the mini-MAAS commits the allocation and
communicates the lease to the application.
4.4.4 Advertising a New Allocation
To complete a new address allocation, a mini-MAAS SHOULD send an AIU
message containing its lease descriptor.
4.5 Shared Control of an Address Allocation
ZMAAP only requires that a mini-MAAS must record and defend the
Catrina, et. al. Expires: 21 July 2001 [Page 11]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
allocations it has made. This is sufficient for sessions that can
only continue as long as the allocator of the multicast address (the
initiator) is present. However, it is not adequate in many other
situations. Participants in a multicast session may desire that the
session continues even if the allocator exits or becomes otherwise
unavailable. They need the support of their local mini-MAASs in order
to maintain the allocation or learn when it becomes invalid due to a
conflict.
A mini-MAAS SHOULD allow an application to register a multicast
address allocation it uses (but has been made by another session
participant). The application issues a request indicating a lease
descriptor (learned, e.g., using SAP [16]). Typically, the mini-MAAS
does not have a record for the indicated allocation. In this case,
the mini-MAAS MUST claim it using ACLM messages, as described in
section 4.4.3. An AIU reply with matching address range and lease
identifier confirms the allocation. The mini-MAAS records the
allocation as belonging to another mini-MAAS and later defends it as
described in section 4.7. Otherwise, the claiming may result either
in the allocation of the addresses, if no AIU message is received, or
the detection of an allocation conflict.
4.6 Changing the allocation lifetime
An application can change the lifetime of an allocation it controls
by issuing a request to its local mini-MAAS indicating the lease
identifier and the new lifetime. The local mini-MAAS updates its
record and multicasts an AIU message indicating the new lifetime.
It is possible to extend or to reduce the current lifetime and, in
particular, to deallocate an address. The deallocation can be
announced by setting the Lease-Time of the allocation in the AIU
messages to zero.
Note that lifetime changes made during network partitions can have
undesired effects, because some mini-MAASs cannot record them.
Lifetime extensions, like new allocations, can result in duplicate
allocations. Lifetime reduction or deallocation can result in various
other situations, from the relatively benign defense of expired
allocations, to the more unpleasant cancellation of new allocations
due to false conflicts (with deallocated addresses).
4.7 Processing Received ACLM Messages
A mini-MAAS that receives an ACLM message MUST check its allocation
record to determine the status of the addresses being claimed.
If the mini-MAAS is currently trying to allocate any of the addresses
in the ACLM message, the procedure in section 4.4.3 applies.
If the mini-MAAS is the allocator of any addresses in the ACLM
Catrina, et. al. Expires: 21 July 2001 [Page 12]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
message, it MUST send immediately an AIU message containing the lease
descriptor(s) of its own allocation(s).
If the mini-MAAS determines that any address in the ACLM message is
allocated by another mini-MAAS, it MAY defend that allocation if the
owner seems unable to do so. If the mini-MAAS supports the shared
control described in section 4.8 and a local application registered
for the allocation, then the mini-MAAS MUST defend it. For this
purpose, the mini-MAAS sets a timer to a random delay between
[RESEND-WAIT]*2 and [RESEND-WAIT]*8. If it receives an AIU defending
the allocation, it cancels the timer. Otherwise, when the timer
expires, it sends an AIU message containing the lease descriptor(s)
of the defended allocation(s). Due to the delayed defense, the
retransmissions made by the claimant may not be sufficient to ensure
reliability. The defender MAY resend the AIU message in such a case.
Otherwise, the ACLM contains an allocation unknown to the mini-MAAS
and needs not take further action. (It MAY record the addresses in
the ACLM message as "claimed", to avoid their selection for
allocation.)
4.8 Processing Received AIU Messages
A mini-MAAS that receives an AIU message MUST check its allocation
record to determine the status of the indicated allocations.
If the mini-MAAS is currently trying to allocate any of the addresses
in the AIU message, the procedure in section 4.4.3 applies. The mini-
MAAS MAY add the allocations indicated in the AIU message to its
cache.
If an allocation in the AIU message matches one of the recorded
allocations (same addresses, same lease identifier), then the AIU
just defends or changes the lifetime of the existing allocation. The
mini-MAAS only updates the lifetime, if necessary.
If any addresses in the AIU message appear in recorded allocations
but the lease descriptors do not match (different address ranges or
lease identifier), then an allocation conflict exists. The mini-MAAS
MUST cancel the recorded allocation and replace it with the
allocation in the AIU message. Also, the mini-MAAS SHOULD inform any
local applications registered for the canceled allocation.
Otherwise, the AIU message contains allocations unknown to the mini-
MAAS. The mini-MAAS MAY add them to its cache.
Catrina, et. al. Expires: 21 July 2001 [Page 13]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
5. Transitions between environments
5.1 Transition requirements
Hosts should be able to allocate multicast addresses in a configured
environment as well as in a zero-configuration environment (isolated
and edge scenarios). If the hosts allocate addresses in scopes
managed by MADCAP servers, special mechanisms must be provided to
enable transitions between these environments:
Isolated to Edge transition
A mechanism MUST be provided to transition between the Isolated
and Edge scenarios. This happens when a router is added to connect
an Isolated area to a configured environment, such as when a host
in an Isolated environment dials an Internet Service Provider
(ISP) and becomes a router. Similarly, the reverse transition
occurs if the router goes down.
Isolated to Configured transition
A mechanism MUST be provided to transition between an Isolated and
a Configured environment. This occurs, for example, in a corporate
environment when a router comes up or goes down. When a router is
down, any hosts on disconnected links may be in an Isolated
environment.
5.2 Zero-configuration host behavior
5.2.1 Multicast Scope Enumeration
A host SHOULD attempt to find a MADCAP server and acquire the list of
multicast scopes available, using MADCAP's GETINFO request as
described in [2]. It SHOULD try this at startup time and periodically
thereafter. It MAY instead wait until an application wants to
enumerate scopes, at the expense of increasing the time needed.
If any servers are found, a host should use the set of scopes
returned by them. In addition, it may also use several registered
multicast address ranges, such as Link-local [3], Interface-local
[3], Single-Source [7,13], and Unicast-prefix-based [13] addresses.
If no servers are found, a host can assume the existence of any well-
known scopes with specified ranges. Besides the scopes listed above,
these include the Global scope and administrative scopes such as:
Local scope and Organization-Local scope [6], Allocation scope [1],
etc. In this situation, a host MAY also begin passively listening to
MZAP [8] messages to build up its scope list further. (MZAP sends
very low frequency reports of scopes to listeners inside those
scopes.)
Catrina, et. al. Expires: 21 July 2001 [Page 14]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
5.2.2 Multicast Address Allocation
Interface-Local and Single-Source multicast addresses can be
allocated without any coordination between hosts. A host can use any
local, implementation-dependent algorithm. (Note that ZMAAP may be
used to coordinate these allocations on a single host.)
Allocations of Link-Local and Unicast-prefix-based multicast
addresses need to be coordinated using ZMAAP.
For all other scopes, the following procedures apply.
If the host has recently tried to obtain the scope list, then the
host already knows whether any MAASs are present. If it has not tried
recently, then the host can use MADCAP to discover a server when it
wants to allocate an address.
If a server is present, the host simply uses MADCAP to allocate
addresses.
If no server is present, the host's action depends on the type of
scope specified in the allocation request. If the scope is "big"
(Global scope, or any scope obtained from MZAP and identified by MZAP
as "big"), no addresses may be allocated. Otherwise, if the scope is
"small", addresses may be allocated using ZMAAP. The host MUST NOT
allocate the last 256 addresses in the range as these are reserved
for scope-relative addresses [6]. Hosts that use ZMAAP for these
scopes should implement MADCAP and mechanisms for transitioning to a
configured environment.
5.2.3 Host Transitioning Rules
This section describes transitioning rules to be used for addresses
which are managed by a MADCAP server, if it is present. The basic
idea is that once ZMAAP is used, the mini-MAASs continue to function
to prevent inconsistency among hosts which discover the MADCAP server
at different times.
If a MADCAP server is not present, a mini-MAAS MAY allocate from the
IPv4 Local, IPv6 link-local or IPv6 site-local scopes. A mini-MAAS
which does this MUST periodically attempt to discover MADCAP servers,
issuing a multicast MADCAP DISCOVER message once every [MADCAP-POLL]
seconds.
Once a MADCAP server is discovered, a mini-MAAS MUST make all new
allocations in the scopes listed above using MADCAP, instead of
ZMAAP. A mini-MAAS MUST also attempt to transfer each of its own
current allocations to the MADCAP server using a MADCAP REQUEST
message. If such an attempt fails (e.g., due to an allocation
conflict with the server), local applications registered with the
allocation SHOULD be informed that their allocation has been
Catrina, et. al. Expires: 21 July 2001 [Page 15]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
canceled.
The mini-MAAS SHOULD continue to defend the allocations it transfers
to the server against claims made by the other mini-MAASs for a
duration of [MADCAP-POLL]*3 seconds since server discovery.
Afterwards, the mini-MAAS considers the transition completed and
abandons those allocations.
After discovering the MADCAP server, the mini-MAAS can continue to
allocate addresses using ZMAAP from the other multicast scopes that
are not managed by the server (like Link-local scope).
5.3 Zero-configuration router behavior
In the Edge scenario, a zero-configuration router exists, with a link
which connects to a configured environment. Here, there is likely a
well-understood distinction between the local area and the external
environment, as well as a potential requirement to be able to scope
some data to the local area. Hence, if the router detects that it is
an "Edge" router (i.e. a router in an Edge scenario), it instantiates
"IPv4 Local Scope" and "IPv6 Admin scope" boundaries on that link.
It SHOULD also instantiate Site-scope boundaries as well.
However, before it can do this, a router must be able to distinguish
between whether it is in an Edge scenario, or in a configured
environment. This could be done in any implementation-specific
manner. For example, the router could assume it is in a zero-
configuration environment unless it is specifically configured
otherwise. This would appear to be acceptable, since if it is in a
configured environment, the router would typically be configured
anyway.
If the router determines that it is an Edge router, the router SHOULD
instantiate a Local scope boundary and become a mini-MAAS with
behavior as follows.
5.3.1 Scope Enumeration
To acquire a set of scopes, the router performs the same actions as
those described for hosts in Section 5.2.1, with MADCAP queries being
sent out over the link to the configured environment.
When the router receives GETINFO messages from clients in the zero-
configuration environment asking for the scope list, it responds as a
MADCAP server would, by including the scope list it acquired above.
5.3.2 Address Allocation
Local scope addresses can be allocated immediately by the router as
if it were a MADCAP server. For addresses in all larger scopes, the
following procedures apply.
Catrina, et. al. Expires: 21 July 2001 [Page 16]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
If a MADCAP server was found in the configured environment, the
router acts as a MADCAP proxy and relays the request to an
appropriate server as if it were a client. The response is relayed
back to the client as if it were a server.
If no MADCAP server was found in the configured environment, the
router MAY allocate addresses itself if it implements ZMAAP to
coordinate with any other MAASs (such as other Edge routers) reached
via the configured environment.
5.3.3 Router Transitioning Rules
In an Edge environment, the Edge router should periodically (either
at regular intervals, or only when hosts request addresses or scope
lists) re-check whether a server is available in the configured
environment.
Similarly, if the Edge router stops receiving responses from any
servers in the configured environment, the behavior specified in the
previous sections allows it to continue allocating addresses.
6. Timer Default Values
ANNOUNCE-WAIT 3 seconds
RESEND-WAIT 200 milliseconds
REPEAT-INTERVAL 10 seconds
MADCAP-POLL 5 minutes
MAX-LEASE TBD
7. Security Considerations
In the interest of simplicity, this draft does not prescribe a means
of securing the multicast auto-configuration mechanism. Thus it is
possible that hosts will allocate conflicting multicast addresses for
a period of time, or that non-conforming hosts will attempt to deny
service to other hosts by allocating the same multicast addresses.
A 'greedy' mini-MAAS which simply ignored others' advertisements and
allocated any address it wished could steal addresses from others.
If there were more than one such 'greedy' mini-MAAS on the network,
address allocation conflicts would never be detected or corrected.
Since MADCAP is used as a mechanism for determining whether to auto-
configure, it should be noted that it is likely that hosts in small
network scenarios will not attempt to secure their MADCAP traffic.
If unsecured, MADCAP is vulnerable to a number of threats, including
message modification and attacks by rogue servers and unauthenticated
clients. While the procedure described in this document does not
preclude implementation of MADCAP security, the extra configuration
required to set this up represents an implementation barrier in the
Catrina, et. al. Expires: 21 July 2001 [Page 17]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
home network. As a result, it is likely that most home routers will
not support MADCAP authentication, and that those networks will
remain vulnerable to attack.
These threats are most serious in wireless networks such as 802.11,
since attackers on a wired network will require physical access to
the home network, while wireless attackers may reside outside the
home. In order to provide for privacy equivalent to a wired network,
the 802.11 specification provides for RC4-based encryption. This is
known as the "Wired Equivalency Privacy" (WEP) specification,
described in [9]. Where WEP is implemented, an attacker will need to
obtain the WEP key prior to gaining access to the home network.
8. IANA Considerations
This document requires an allocation for a UDP port number, an IPv4
administrative scope-relative multicast address and an IPv6 variable
scope group id - unless ZMAAP uses the same as allocated for AAP.
Appendix A Compatibility Issues with AAP
1. ZMAAP doesn't process all AAP messages.
2. ZMAAP does not use AAP sequence numbers.
3. ZMAAP AIU and ACLM messages have an additional Lease Identifier
field.
4. ZMAAP uses relative not absolute times for leases.
5. ZMAAP does not rely on MAAS's to defend each others' allocations.
6. ZMAAP does not send out periodic advertisements.
7. ZMAAP does not rely on each MAAS keeping an allocation record
except for its own allocations.
Appendix B Application Programmer Interface (API) Issues
1. Allow an application to register/deregister interest in an
allocation it has not made itself (use lease id to disambiguate).
This will cause the local mini-MAAS to maintain a record for the
allocation, defend it, detect an allocation conflict and inform
the application about the loss of the allocation or a lifetime
change.
Appendix C Session Management Implications
1. Need to find out about sessions (ie. groups) with external
mechanism (ie. SAP/SDP)
Catrina, et. al. Expires: 21 July 2001 [Page 18]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
Appendix D Open Issues
1. The announcements for allocation commitment and lifetime change
are currently done unreliably, with a single AIU. Should they be made
reliable? How?
2. Should this document contain a specific API?
3. Should this document cite AAP?
4. Should AAP and ZMAAP be compatible? If so, should AAP change to
fit ZMAAP requirements (seqnos, lease ids, etc)
8. References
[1] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast
Address Allocation Architecture", RFC 2908, September 2000.
[2] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[3] Hinden, R. and Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Finlayson, R., "An Abstract API for Multicast Address
Allocation", RFC 2771, February 2000.
[6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[7] IANA, "Single-source IP Multicast Address Range",
http://www.isi.edu/in-notes/iana/assignments/single-source-
multicast, October 1998.
[8] Handley, M., Thaler, D., and Kermode, R., "Multicast-Scope Zone
Announcement Protocol (MZAP)", RFC 2776, February 2000.
[9] Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks
- Specific Requirements Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std.
802.11-1997, 1997.
[10] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
August 1989.
[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
Catrina, et. al. Expires: 21 July 2001 [Page 19]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
[12] Address Family Numbers. http://www.isi.edu/in-
notes/iana/assignments/address-family-numbers
[13] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 Multicast
Addresses", Internet Draft, draft-ietf-ipngwg-uni-based-
mcast-01.txt, January 2001. Work in progress.
[14] Hattig, M., "Zeroconf Requirements", draft-ietf-zeroconf-
reqts-06.txt, November 2000. Work in progress.
[15] Cheshire, S., "Dynamic Configuration of IPv4 link-local
addresses", draft-ietf-zeroconf-ipv4-linklocal-01.txt, November
2000. Work in progress.
[16] Handley, M., Perkins, C., Whelan, E., Session Announcement
Protocol, RFC 2974, October 2000.
Acknowledgments
This draft has been derived from work by Mark Handley and Steve Hanna
on the Multicast Address Allocation Protocol (AAP). Prashant
Agarwal's master thesis work at International University provided
insights helpful for enriching and subsetting AAP for zero
configuration application.
Authors' Addresses
Octavian Catrina, Editor
International University in Germany
International University Campus 2
D-76646 Bruchsal, Germany
Phone: +49 7251 700 221
EMail: Octavian.Catrina@i-u.de
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 (425) 703-8835
EMail: dthaler@microsoft.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 (425) 936-6605
EMail: bernarda@microsoft.com
Catrina, et. al. Expires: 21 July 2001 [Page 20]
Internet Draft Zeroconf Multicast Allocation Protocol February 2001
Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt Germany
Phone: +49 172 865 5497
Email: erik.guttman@sun.com
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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
English.
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
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Catrina, et. al. Expires: 21 July 2001 [Page 21]
