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