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",
<http://www.iana.org/assignments/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", <http://
www.isi.edu/in-notes/iana/assignments/
single-source-multicast>.
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