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) 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: 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]