NETWORK Working Group Octavian Catrina, Editor
INTERNET-DRAFT International University
Category: Standards Track Dave Thaler
6 June 2001 Bernard Aboba
Expires in six months Microsoft
Erik Guttman
Sun Microsystems
Zeroconf Multicast Address Allocation Protocol (ZMAAP)
<draft-ietf-zeroconf-zmaap-01.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: 6 December 2001 [Page 1]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . .
2. Terminology . . . . . . . . . . . . . . . . . . . . . . .
3. Requirements and Design Considerations . . . . . . . . . .
4. Zeroconf Multicast Address Allocation Protocol . . . . . .
4.1 Protocol Overview . . . . . . . . . . . . . . . . . . .
4.2 Transmission of ZMAAP messages . . . . . . . . . . . . .
4.3 Protocol Message Format . . . . . . . . . . . . . . . .
4.4 ZMAAP mini-MAAS behavior . . . . . . . . . . . . . . . .
4.4.1 Claiming an Address
4.4.2 Defending an Address
4.4.3 Verifying a Lease Descriptor
4.4.4 Detecting a Collision
4.4.5 Deallocation of an Address
5. Timer Default Values . . . . . . . . . . . . . . . . . . .
6. Security Considerations . . . . . . . . . . . . . . . . .
7. IANA Considerations . . . . . . . . . . . . . . . . . . .
Appendix A: Application Programmer Interface (API) Issues
Appendix B: Session Management Implications . . . . . . .
Acknowledgments . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . .
Author's Contact Information . . . . . . . . . . . . . . .
Full Copyright Statement . . . . . . . . . . . . . . . . .
1. Introduction
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 to allocate addresses without the
need for multicast address allocation servers.
The Internet Multicast Address Allocation Architecture [1] provides a
three-layer framework for allocating multicast addresses. The top
layer is used to decide which address range to use for allocation.
The middle layer is used to coordinate among peers allocating from
the same range. The bottom layer is used to provide scalability in a
managed environment whereby a small number of servers can allocate
addresses to a large number of hosts. In a zero-configuration
environment, less scalability is required, and hence the bottom layer
will not be needed. ZMAAP thus fits into the Multicast Address
Allocation Architecture as a middle-layer protocol which is used
between end nodes.
ZMAAP allows applications to allocate unique addresses from certain
address ranges, to defend those allocations and to detect conflicts
in those allocations.
Catrina, et. al. Expires: 6 December 2001 [Page 2]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
Other topics discussed are a ZMAAP API and interactions with the
Session Announcement 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 node providing multicast address allocation services to
network clients.
Mini-MAAS
A service providing multicast address allocation services to
applications running on the same host. Mini-MAASs
cooperate to provide network-wide services in small networks
without MAASs.
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. Enumerating 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.
Hosts may also use MADCAP [2] for these features. MADCAP provides
various functions, including allocation of addresses in scopes which
are not available using ZMAAP.
In general, applications should be unaware of which protocol is being
used to allocate multicast addresses (e.g., MADCAP, ZMAAP, or local
allocation of SSM addresses). It is implementation-specific how this
Catrina, et. al. Expires: 6 December 2001 [Page 3]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
is done, but one example would be for a service to run on the host
that does all allocation, and interacts with applications though a
common API.
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).
Applications can obtain the following services from a Mini-MAAS
making use of ZMAAP. For further discussion, see Appendix A.
- Obtain an enumeration of supported multicast scopes.
- Allocate an address in a specified scope.
- Renew an existing address allocation, which an application is
using.
- Get notified when an allocation has been cancelled by the mini-
MAAS due to an allocation conflict.
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).
To obtain a multicast address allocation, an application requests a
range of addresses (specifying the scope and number of addresses) to
a local mini-MAAS. The mini-MAAS issues a ZMAAP ACLM request to the
appropriate address, indicating a randomly selected range of
addresses. The mini-MAAS issues this message repeatedly.
Two things may occur. If an AIU response is received, the mini-MAAS
has requested a range of addresses which conflicts with an existing
allocation. In this case, the mini-MAAS must select a new range of
addresses and try again, or give up. If, on the other hand, the
receives no AIU response when the allotted time expire, it assumes it
has succeeded in allocating an address.
A mini-MAAS will defend an address allocation which it has made. An
application can also inform a local mini-MAAS, (for example, through
the use of an API) to defend an address allocation. A mini-MAAS
which receives an ACLM message which it defends will issue an AIU
response immediately, indicating that the allocation already exists
and the ACLM message conflicts.
Catrina, et. al. Expires: 6 December 2001 [Page 4]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
Allocations are only valid for a limited length of time, indicated in
AIU messages. Before the allocation expires, it may be extended by
any mini-MAAS. Mini-MAASs cache information about allocations to aid
in selecting addresses which do not conflict with others. If an
address is not in the cache, it is considered available for
allocation.
4.2 Transmission of ZMAAP Messages
A mini-MAAS send AIU messages for the addresses that it currently has
allocated, before their allocation lifetime expires.
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 has
allocated addresses or is in the process of allocating addresses.
ZMAAP is used to allocate addresses in all ranges for which
coordination must be done among multiple machines, but within an area
smaller than an Admin scope. This way, the ranges used by MADCAP,
ZMAAP, and SSM are all disjoint and clear ownership is preserved.
MADCAP is used for ranges which require coordination across an Admin
scope or larger, and SSM does not require coordination among multiple
machines.
The ranges which are defined or under discussion today, which ZMAAP
would be used for, include:
Allocation Scope
----------------
(1) IPv4 Dynamic Link-Local [TBD]
(2) IPv6 Dynamic Link-Local [3]
(3) IPv6 Dynamic Subnet-Local [3]
(4) IPv4 Unicast-Prefix-based [TBD]
(5) IPv6 Unicast-Prefix-based [13]
To date, no range of addresses for (1) or (4) has been defined.
Catrina, et. al. Expires: 6 December 2001 [Page 5]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
4.3 Protocol Message Format
ZMAAP uses two messages: Address In Use (AIU), used to announce an
existing address allocation, and Address Claim (ACLM), used to
announce a desired address allocation. ZMAAP implementations MUST
support both these messages.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease descriptor 1 (variable) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease descriptor N (variable) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Lease descriptors describe address allocations in ZMAAP messages.
An IPv4 address is represented by 4 bytes in network byte order. The
lease descriptor for IPv4 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 |
Catrina, et. al. Expires: 6 December 2001 [Page 6]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Final address in the range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Addresses in the lease descriptor belong to the address family
indicated by the Address Family field in the message header.
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 Lease Lifetime is the number of seconds which a lease may be
cached after it has been received.
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
lease descriptors is too large to fit into the maximum payload, they
are sent in separate ZMAAP messages.
Catrina, et. al. Expires: 6 December 2001 [Page 7]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
4.4 ZMAAP mini-MAAS behavior
A ZMAAP mini-MAAS performs four functions: Claiming, defending,
verifying and detecting conflicts in allocations.
A mini-MAAS MUST maintain state information for its own allocations.
This will be referred to as the 'allocation record.'
It MAY also maintain state information for allocations made by other
mini-MAASs, learned from received ZMAAP messages. This could be
useful, for example, to assist in selecting multicast addresses that
will be unlikely to conflict with preexisting allocations. The term
'allocation record' as used below will NOT include this state
information.
4.4.1 Claiming an address
To allocate multicast addresses, an application makes a request from
the local mini-MAAS, indicating the scope, the number of addresses
desired and the allocation lifetime.
The mini-MAAS selects free addresses by consulting its allocation
record and creates a lease descriptor. To reduce the likelihood of
collisions, a random selection of the free addresses is strongly
recommended (see Section 4.3). A unique identifier ("lease
identifier") is associated with each allocation to distinguish
allocations of the same addresses.
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 after each send, 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. To complete a new address
allocation, a mini-MAAS MUST send an AIU message containing its lease
descriptor.
4.4.2 Defending an Address
A mini-MAAS MUST defend all allocations in its allocation record.
Catrina, et. al. Expires: 6 December 2001 [Page 8]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
If a mini-MAAS receives an ACLM with the same Lease Identifier as an
allocation in its allocation record, it MUST respond with an AIU
message, immediately. This AIU message MUST contain the Lease
Descriptor present in the allocation record.
The ACLM with a matching Lease Identifier could in conflict with an
allocation in its allocation record, or exactly match it. Either
way, the mini-MAAS responds with an AIU message.
Care must be taken to ensure that the range of addresses specified in
the AIU does not overlap the range of any other allocation in the
allocation record. If it does, this is an allocation conflict and
the mini-MAAS MUST send an AIU containing the Lease Descriptor of the
allocation with which the ACLM is in conflict.
ZMAAP provides mechanisms that enable address allocations to continue
without the allocator. Other session participants can share the
defense 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, see
Appendix B.) A mini-MAAS MAY add a lease identifier to its
allocation record, even if it was not the mini-MAAS which allocated
the address. Before it does this, it MUST verify the lease
identifier is correct (see Section 4.4.3).
4.4.3 Verifying a Lease Descriptor
A valid lease identifier matches an existing (defended) allocation,
and does not conflict with any other allocations.
A mini-MAAS MUST verify the validity of a lease identifier before it
adds it to its allocation record for 'shared defense' of an address
(see Section 4.4.2 and Appendix A).
To verify a lease identifier is correct, the mini-MAAS claims it
using ACLM messages, as described in section 4.4.1.
4.4.4. Detecting a Collision
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 mini-MAAS MUST try a different address or
give up trying to allocate addresses (see Section 4.4.1).
If any ranges in the AIU message overlap with recorded allocations
but the lease descriptors do not match (different address ranges or
lease identifier), then an allocation conflict exists. The mini-MAAS
Catrina, et. al. Expires: 6 December 2001 [Page 9]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
MUST remove the allocation from its allocation record. The mini-MAAS
will inform any local applications registered for the canceled
allocation, if it has implemented this functionality (see Appendix
A).
4.4.5. Deallocation of an Address
Addresses SHOULD NOT be explicitely deallocated (i.e. by sending an
AIU with Lifetime set to 0). Instead, allocations SHOULD be allowed
to expire. This allows any mini-MAAS interested in preserving the
allocation to send an AIU before the expiration to prolong the
allocation.
5. Timer Default Values
ANNOUNCE-WAIT 3 seconds
RESEND-WAIT 200 milliseconds
REPEAT-INTERVAL 10 seconds
DETECT-INTERVAL 5 minutes
6. 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.
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.
7. IANA Considerations
This document requires an allocation for a UDP port number, and a
range of IPv4 multicast addresses for link-local dynamic multicast
address allocation.
Catrina, et. al. Expires: 6 December 2001 [Page 10]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
Appendix A Application Programmer Interface (API) Definition
The ZMAAP API will be presented as a set of abstract functions
followed by language specific mappings. These functions and their
names are derived from the Abstract API for Multicast Address
Allocation [5]. This API is specified in a separate document [18].
What distinguishes the ZMAAP API from the general multicast address
allocation API is the need for two additional functions: Shared
ownership, for renewal and defense of allocations, and conflict
notification for applications to determine if and when an allocation
can no longer be used.
Normally the mini-MAAS allocating an address maintains an allocation
record entry for it. This implies the mini-MAAS will defend the
address from conflicting claims and will send AIU messages before the
lease lifetime expires for all active allocations. In the case of
'shared ownership', (initiated via the ZMAAP API), a mini-MAAS first
verifies that the lease is still valid (section 4.4.3), then it adds
the record to its own allocation record.
Appendix B Session Management Implications
Multicast address allocation alone is not useful. A mechanism is
needed in order to discover sessions using multicast allocations.
This serves applications attempting to join an existing session,
those initiating new sessions and also for rendezvous at a new
session address if there has been a conflict with an address
currently in use.
Sessions are announced using the Session Announcement Protocol (SAP)
[16]. They are described using the Session Description Protocol
(SDP) [17].
SAP describes how to announce sessions for IPv4 using global and
adminstrative scoped multicast. This technique is used to announce
sessions which are allocated in other scopes as well. For IPv4 link-
local scope session announcement, an IP time-to-live of 1 is used.
This limits propogation of the announcement to the same scope where
it is meaningful.
An additional SDP session attribute SHOULD be included for use in
announcing sessions for addresses allocated with ZMAAP. This
attribute allows coordination with ZMAAP.
a=zmaap-lease-id:<lease-id>
<lease-id> is set to the lease identifier associated with the
announced session.
Catrina, et. al. Expires: 6 December 2001 [Page 11]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
An application which receives a session announcement with this
attribute may use it to form a Lease Descriptor and request the ZMAAP
API to either defend the allocation or for notification if there is
an address allocation conflict. See Appendix B.
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.
[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.
Catrina, et. al. Expires: 6 December 2001 [Page 12]
Internet Draft Zeroconf Multicast Allocation Protocol June 2001
[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.
[17] Handley, M., Jacobson, V., "SDP: Session Description Protocol",
RFC 2327, April 1998.
[18] Guttman, E., "An API for the Zeroconf Multicast Address
Allocation Protocol", draft-ietf-zeroconf-zmaap-api-00.txt. A
work in Progress.
Acknowledgments
This draft has been benefited 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
helpful insights.
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: 6 December 2001 [Page 13]
Internet Draft Zeroconf Multicast Allocation Protocol June 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: 6 December 2001 [Page 14]
