NETWORK Working Group Octavian Catrina, Editor INTERNET-DRAFT International University Category: Standards Track Dave Thaler 22 October 2002 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. Comments on this document should be sent to the zeroconf@merit.edu mailing list. 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 (2001). 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: 22 April 2002 [Page 1] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 1.1 Changes since the last version of this document . . . . 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 and Lease Lifetime . . . . . . . . . . . 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 [ZCREQTS]. 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 [RFC2908] 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 Catrina, et. al. Expires: 22 April 2002 [Page 2] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 in those allocations. 1.1 Changes since the previous version of this document 1. Timers introduced before AIU responses to ACLM messages are sent If there are many members of a group, an ACLM for that group's allocation would cause a massive implosion of AIUs - like a distributed denial of service attack. While it is unlikely that ZMAAP will be used for large groups maintained by of thousands of mini-MAASs, we won't rule out the possibility. Currently mini-MAASs respond to ACLMs with an AIU immediately. Now, before sending an AIU in response to an ACLM, mini-MAASs will wait a random interval and listen for other AIUs defending the allocation. If such an AIU is received, the mini-MAAS cancels its waiting timer and does not send the AIU. 2. To prevent thrashing, rules slow down and stop allocation attempts As more and more addresses in an address space are allocated, claims for random address ranges in the address space have a higher chance of collision. To prevent thrashing (excessively repeated attempts for allocation), new rules are 3. Security: Text on WEP removed 4. Add a magic number to ZMAAP headers This will be used to detect collision in the use of the same multicast address by multiple applications. 5. Clarification of address range conflicts Non overlapping ranges conflict even if the lease id is the same. 2. Terminology This document uses the following terms: Multicast IP Multicast, as defined in [RFC1112] and [RFC2460]. Multicast Address An IP multicast address or group address, as defined in [RFC1112] and [RFC2373]. An identifier for a group of nodes. Multicast Scope A range of multicast addresses configured so that traffic Catrina, et. al. Expires: 22 April 2002 [Page 3] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 sent to these addresses is limited to some subset of the internetwork. See [RFC2365] and [RFC2373]. 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 [RFC2119]. 3. Requirements and Design Considerations As described in [RFC2771], a multicast allocation API provides two main services to multicast applications. First, it allows enumeration of the set of available multicast scopes applications may attempt to allocate in. Second, applications can dynamically allocate multicast addresses in scopes they specify. Hosts may also use MADCAP [RFC2730] 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 [SSM] addresses). ZMAAP satisfies the general requirements for multicast address allocation mechanisms specified in [RFC2908]: 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. ZMAAP is expected to work in a 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. Catrina, et. al. Expires: 22 April 2002 [Page 4] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 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. Three messages are used for this purpose: Address In Use (AIU), Address Claim (ACLM). To obtain a multicast address allocation, an application makes a request to a local mini-MAAS, specifying the scope and number of addresses. The mini-MAAS selects the addresses to be allocated and multicasts a ZMAAP ACLM request to the other mini-MAASs. The mini- MAAS issues this request 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 ask a local mini-MAAS to defend an address allocation it uses, learned through another mechanism (for example, through the use of an API). 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. Mini-MAASs may cache information about allocations to aid in selecting addresses which do not conflict with others. A cache entry is maintained for the duration of the intended allocation lifetime indicated in ZMAAP messages. The lifetime can be extended using AIU messages. If an address is not in the cache, it is considered available for allocation. 4.2 Transmission of ZMAAP Messages A mini-MAAS sends 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 Catrina, et. al. Expires: 22 April 2002 [Page 5] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 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 [RFC2373] (3) IPv6 Dynamic Subnet-Local [RFC2373] (4) IPv4 Unicast-Prefix-based [TBD] (5) IPv6 Unicast-Prefix-based [UNIPREFIX] To date, no range of addresses for (1) or (4) has been defined. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x1b | 0xd7 | 0x3b | 0x48 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lease descriptor 1 (variable) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lease descriptor N (variable) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The initial 4 bytes in the message constitute a 'magic number' which is used to detect protocol collisions on the port and multicast group Catrina, et. al. Expires: 22 April 2002 [Page 6] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 where ZMAAP is operating. Any message which does not begin with the magic number MUST be silently discarded. 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 [IANA]. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | | | | | Catrina, et. al. Expires: 22 April 2002 [Page 7] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 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 distinguishes different allocations of the same address range. 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. 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 the allocations it makes or it maintains as a result of requests from its local applications. This will be referred to as the 'allocation record.' It MAY also cache state information for other allocations, 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. Catrina, et. al. Expires: 22 April 2002 [Page 8] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 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, after waiting. Each successive attempt T, the mini-MAAS waits for a uniformly distributed random interval from 0 to ([RESTART-WAIT] * T) milliseconds. 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. If there is any overlapping between address ranges in the received ACLM and address ranges in its allocation record, the mini-MAAS MUST respond with an AIU. This AIU contains the Lease Descriptors of the mini-MAASs own allocations whose address ranges overlap with those in the ACLM. Note that the AIU is sent regardless of whether the Lease Identifiers for an overlapping range match (same allocation) or not (conflicting allocations). The other mini-MAAS will be able to distinguish these cases using the Lease Identifier and take an appropriate action. To send an AIU in response to an ACLM message, the mini-MAAS starts a random Defense Timer, uniformly distributed from 0 to [DEFEND-WAIT] milliseconds. During this waiting interval, the mini-MAAS listens Catrina, et. al. Expires: 22 April 2002 [Page 9] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 for AIU response to the ACLM. If the mini-MAAS detects the same AIU which it would have sent, the mini-MAAS cancels the Defense Timer. Otherwise, when the Defense Timer expires, the mini-MAAS sends the AIU. ZMAAP allows address allocations to persist without the initial 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 an allocation to its 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 adding 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 an Allocation Conflict 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 without exactly matching recorded allocations then an allocation conflict exists. Also, if an address range in an AIU matches a recorded address allocation with a different lease identifiery, this also indicates a conflict. The mini-MAAS 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 and Lease Lifetime A mini-MAAS maintains an address allocation in its record as long as a local application uses it. When an allocation is not needed anymore by any local application, the mini-MAAS removes it from the allocation record, so it stops Catrina, et. al. Expires: 22 April 2002 [Page 10] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 defending it. However, the allocation can still be defended by other mini-MAASs interested in preserving it. When an allocation is no longer defended by any mini-MAAS, the addresses can be reallocated. The Lease Lifetime indicated in ZMAAP messages limits the lifetime of cache entries used to assist in address selection for new allocations. A mini-MAAS MAY send AIUs to extend an expiring lifetime for any of its allocations. It SHOULD NOT send AIUs to reduce the lifetime (in particular set it to 0), since other mini- MAASs may intend to preserve it. 5. Timer Default Values ANNOUNCE-WAIT 3 seconds RESEND-WAIT 200 milliseconds RESTART-WAIT 100 milliseconds DEFEND-WAIT 100 milliseconds 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 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 counter these threats, IP or link layer security could be applied to authenticate messages and thereby prevent the attacks listed above. For example, if all authorized hosts in the network shared a preconfigured key, this could be used with the IP Authentication Header [RFC2402] to discard unauthenticated datagrams. Admittedly, preconfiguration of keys runs counter to the goals of zero configuration networking. There's no free lunch. 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: 22 April 2002 [Page 11] Internet Draft Zeroconf Multicast Allocation Protocol October 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 [RFC2771]. This API is specified in a separate document [ZMAAPAPI]. 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) [RFC2974]. They are described using the Session Description Protocol (SDP) [RFC2327]. SAP describes how to announce sessions for IPv4 using global and adminstrative scoped multicast. This technique can be 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 Catrina, et. al. Expires: 22 April 2002 [Page 12] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 announced session. 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. References [IANA] Address Family Numbers. http://www.isi.edu/in- notes/iana/assignments/address-family-numbers [MDNS] Ebisov, L., Aboba, B., Thaler, D., "Multicast DNS", draft- ietf-dnsext-mdns-06.txt, October 2001. Work in progress. [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, August 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2327] Handley, M., Jacobson, V., "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [RFC2373] Hinden, R. and Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. [RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000. [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000. [RFC2974] Handley, M., Perkins, C., Whelan, E., "Session Announcement Protocol", RFC 2974, October 2000. [SSM] IANA, "Single-source IP Multicast Address Range", Catrina, et. al. Expires: 22 April 2002 [Page 13] Internet Draft Zeroconf Multicast Allocation Protocol October 2001 http://www.isi.edu/in-notes/iana/assignments/single-source- multicast, October 1998. [UNIPREFIX] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 Multicast Addresses", Internet Draft, draft-ietf-ipngwg-uni- based-mcast-03.txt, October 2001. Work in progress. [V4LL] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 link- local addresses", draft-ietf-zeroconf-ipv4-linklocal-04.txt, July 2001. Work in progress. [ZCREQTS] Hattig, M., "Zeroconf Requirements", draft-ietf-zeroconf- reqts-06.txt, November 2000. Work in progress. [ZMAAPAPI] Guttman, E., "An API for the Zeroconf Multicast Address Allocation Protocol", draft-ietf-zeroconf-zmaap-api-00.txt. 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: 22 April 2002 [Page 14] Internet Draft Zeroconf Multicast Allocation Protocol October 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 (2001). 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: 22 April 2002 [Page 15]