Network Working Group V. Witana Internet-Draft A. Williams Expires: January 10, 2005 National ICT Australia July 12, 2004 A Simple IPv4 Multicast Address Allocation Protocol (SMAAP) draft-witana-multicast-alloc-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Specifies a peer-to-peer protocol for allocating dynamic IPv4 link local multicast addresses in an ad-hoc network. This protocol is intended for use in small networks without configured multicast address servers. Witana & Williams Expires January 10, 2005 [Page 1] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 Table of Contents 1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements and Design Considerations . . . . . . . . . . . . 6 4.1 Multicast Allocation Scope . . . . . . . . . . . . . . . . 6 4.2 API Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Conflict Resolution . . . . . . . . . . . . . . . . . . . 9 6. Protocol Message Format . . . . . . . . . . . . . . . . . . . 10 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Witana & Williams Expires January 10, 2005 [Page 2] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 1. Acknowledgements This draft has benefited from the work by Octavian Catrina and others on the Zeroconf Multicast Address Allocation Protocol (ZMAAP) as well as work by Mark Handley and Steve Hanna on the Multicast Address Allocation Protocol (AAP) Witana & Williams Expires January 10, 2005 [Page 3] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 2. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Witana & Williams Expires January 10, 2005 [Page 4] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 3. Introduction This draft defines a simple IPv4 link local multicast address allocation protocol for dynamic multicast addresses in an ad-hoc network. Such networks are typically small and configured servers and network administrators cannot be assumed. SMAAP is a peer-to-peer protocol that allows multicast allocation entities on hosts to coordinate their address allocations and avoid conflicts. Applications communicate with the multicast allocation entity on the host they are running in order to request a multicast address. The Internet Multicast Address Allocation Architecture [RFC2908] specifies a three-layer framework. In contrast SMAAP is a simple peer to peer protocol intended for deployment in small networks where a multi-layered, multi-protocol system is not required. Witana & Williams Expires January 10, 2005 [Page 5] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 4. Requirements and Design Considerations SMAAP SHOULD satisfy the general requirements for multicast address allocation mechanisms in RFC 2908 [RFC2908] i.e. robustness, availability, low probability of clashes and efficient use of address space. Several multicast address allocation schemes have been proposed including SSM [SSM] and the Multicast Address Dynamic Client Allocation Protocol [RFC2730]. To avoid conflict, different allocation mechanisms SHOULD NOT allocate the same address. The multicast address ranges allocated by SMAAP SHOULD be distinct by any other multicast address allocation protocols operating in the same network. 4.1 Multicast Allocation Scope Currently there is no designated IPv4 dynamic link local multicast scope [RFC2365]. There is insufficient space in the static link local multicast range to allocate a range for SMAAP. Therefore the SMAAP servers may allocate addresses from the IPv4 local scope 239.255.0.0/16. In the most likely scenario, SMAAP will be the only allocation mechanism deployed on that network. If a MADCAP server exists in the network, its scope list SHOULD be configured to exclude the local scope. Alternatively one of the reserved ranges such as 239.254.0.0/16 or 239.253.0.0/16 may be allocated for use by the SMAAP protocol. Either option provides a pool of 65280 addresses enabling the allocation of about 1300 multicast addresses with a low probability of conflict. There is a proposed extension to RFC 3306 [RFC3306], describing a mechanism for generating unique link scoped IPv6 multicast addresses based on the interface ID. Thus is no need for a mechanism such as SMAAP for IPv6. 4.2 API Considerations The Abstract Multicast Allocation API [RFC2771] describes the application's interface with the address allocation servers. The general form of the allocate_address operation, permits the allocation of a contiguous block of addresses, for a given lease, at a given start time. Maximum and minimum values may be specified for each of these parameters. The allocation of contiguous blocks of addresses in a de-centralized manner leads to fragmentation and wastage of addresses and is in conflict with the general requirement of achieving good address space utilization. The SMAAP API needs to support the following operations; namely Witana & Williams Expires January 10, 2005 [Page 6] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 allocate, deallocate address and change multicast address lifetime. In the interests of simplicity and efficiency the SMAAP API is limited allocating a specified number of (not necessarily contiguous) addresses for a specified fixed lifetime, for immediate use. As SMAAP only allocates multicast addresses from a single pre-configured scope and the IPv4 address family, this need not be specified in the API. Witana & Williams Expires January 10, 2005 [Page 7] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 5. Protocol Operation The SMAAP protocol is a peer-to-peer protocol used to claim and defend the address allocated by a SMAAP server. The protocol uses two messages: ACLM - Address claim, used to claim a desired address(es) for the lease duration AIU - Address in use, used to indicate that a address claimed in already in use SMAAP protocol messages are multicast on the SMAAP multicast address, all SMAAP servers listen on this address and port [TBD] To obtain a multicast address the application makes a request to the local SMAAP server, specifying the number of addresses required and lease lifetime. If the allocation is successful the SMAAP server returns an array of allocated addresses and and a unique lease identifier for each. The lease identifier is used by the application to extend the lifetime or deallocate the address. The lease identifier is only used internally between the application and SMAAP server and is not contained in the protocol messages. On receipt of an allocation request, the SMAAP server generates a random address (or set of addresses) within the pre-configured scope. In order to avoid collisions, the address SHOULD be generated using a pseudo random number seeded with the host MAC address or a random number generated according to the guidelines in RFC 1750 [RFC1750]. The SMAAP server MAY optionally cache addresses currently allocated in the domain based on the ACLM and AIU messages it hears. It MAY use this information to discard the address and generate a new address if a conflict is detected. The SMAAP server sends a ACLM message for the generated address(es). If multiple addresses are requested together, the SMAAP server MAY send multiple address claims in one ACLM message. The SMAAP server sends CLAIM_NUM messages spaced randomly between CLAIM_MIN and CLAIM_MAX seconds apart. If the SMAAP server received an AIU message during the duration between the transmission of the first ACLM message and CLAIM_WAIT seconds from the last ACLM message, this indicates a collision. AIU messages are sent on a per address basis. On receipt of an AIU message, the SMAAP server MUST discard the conflicting address. It MAY retry with a new address in a new ACLM message. If the claim timer expired without an AIU message being received the SMAAP server may assume that the address(es) is available for use. It MUST create an allocation record(s) containing the lease identifier and address and return this address, lease identifier array to the user. Witana & Williams Expires January 10, 2005 [Page 8] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 If a SMAAP server receives an ACLM message for an address in its allocation records, it MUST send an AIU message. A SMAAP server may receive multiple ACLM messages for the same multicast address due to the AIU message been lost, thus it MUST send an AIU message for each ACLM message it sees for which it has an allocation record. If the application wishes to extend a lease it will indicate it to the local SMAAP server at least CLAIM-EXPIRE seconds before the lease is due to expire. This creates a buffer between the the lease expiry and its re-allocation. The SMAAP server modifies the allocation record to the reflect the new period and returns. If the application wishes to deallocate the address, the SMAAP server will remove the allocation record and no longer defend that address. 5.1 Conflict Resolution If the network partitions and subsequent re-joins occur, there is a possibility of address allocation conflicts. Randomised allocation from a large address space reduces the likelihood of this occurring. Its impact is similar to an application using an address it did not allocate. Address conflicts also lead to non-optimal forwarding of multicast traffic by L2 switches. Applications receiving traffic from unexpected sources SHOULD discard them. Applications MAY prune the traffic using source specific prunes defined in IGMP version 3. Applications may also detect duplicate allocation by interaction with the session announcement or service discovery protocol used to advertise usage of the allocated multicast addresses. The application may choose to release its existing address and allocate a new one to avoid conflict. Witana & Williams Expires January 10, 2005 [Page 9] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 6. Protocol Message Format SMAAP uses two messages: Address Claim (ACLM), used to claim a desired address allocation and Address In Use (AIU), used to indicate an existing address allocation. SMAAP implementations MUST support both these messages. The SMAAP messages has the following format, the numbers in parenthesis indicate the size in octets of each field: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address 1 (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lease Lifetime 1 (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address n (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lease Lifetime 1 (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Version field indicates the SMAAP version. It MUST be 1 for the version described in this document The Message Type field defines the type of SMAAP message. The following values are defined: Value Message Type ----- ------------ 0 Address Claim (ACLM) 1 Address In Use (AIU) Each address claim or in use, is described by a multicast address/ lease lifetime pair. A single ACLM message MAY contain multiple address claims for efficiency. The Lease Lifetime is the number of seconds for which the application has requested this address. The other SMAAP servers MAY cache these addresses for this period, and use this information to reduce the probability of collision. Witana & Williams Expires January 10, 2005 [Page 10] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 7. Protocol Constants o CLAIM_WAIT 2 seconds (maximum wait for AIU response after sending of last ACLM) o CLAIM_NUM 3 (number of ACLM packets) o CLAIM_MIN 1 second (minimum delay till repeated ACLM) o CLAIM_MAX 2 seconds (maximum delay till repeated ACLM) o CLAIM_EXPIRE 120 seconds (seconds before lease expires to renew lease) Witana & Williams Expires January 10, 2005 [Page 11] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 8. Security Considerations A malicious application may attempt a denial of service attack by attempting to allocate a large number of addresses. Such attacks can be prevented by SMAAP servers implementing policy restrictions on the total number of addresses and rate limiting of the address allocation interval. A malicious SMAAP server can be combated by authorized hosts shared a pre-configured key to be used along with the IP Authentication Header [RFC2402] to detect and discard unauthorised datagrams. 9 References [IANA] IANA, "Address Family Numbers", . [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 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. [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [SSM] IANA, "Single-source IP Multicast Address Range", . Witana & Williams Expires January 10, 2005 [Page 12] ^L Internet-Draft IPv4 Multicast Address Allocation Protocol July 2004 Authors' Addresses Varuni Witana National ICT Australia Aidan Williams National ICT Australia