[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
MALLOC working group                                Mark Handley, ACIRI
Internet Draft                 Stephen R. Hanna, Sun Microsystems, Inc.
October 1999                               draft-ietf-malloc-aap-01.txt
Expires: April 2000

              Multicast Address Allocation Protocol (AAP)

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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.

Abstract

   The document defines a Multicast Address Allocation Protocol (AAP)
   that forms a part of the Internet Multicast Address Allocation
   Architecture being defined by the IETF Multicast Address Allocation
   Working Group. AAP addresses the specific issue of coordination among
   Multicast Address Allocation Servers within a domain.

1. Introduction

   This document describes and defines the Multicast Address Allocation
   Protocol (AAP), which allows Multicast Address Allocation Servers
   (MAAS's) to coordinate multicast address allocation within a domain.

   Section 1 introduces the concepts and terms used throughout the
   document. Section 2 gives an overview of the protocol. Section 3
   describes how multicast scopes relate to the protocol.  Sections 4
   and 5 describe how MAAS's and Prefix Coordinators behave with respect
   to the protocol. Section 6 describes protocol details and message
   formats. Section 7 describes Security Considerations and section 8



Handley and Hanna                                               [Page 1]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   describes IANA Considerations. Section 9 lists acknowledgements,
   section 10 lists references, and section 11 gives the authors'
   addresses. Appendix A includes sample protocol interactions. Appendix
   B lists constants and timers defined in this document. Appendix C
   lists changes made in this version of the document. Appendix D lists
   unresolved issues.

1.1 Terminology

   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 RFC 2119 [3].

   Constants and timers defined in this document are listed in Appendix
   B. Their names are written in all caps with square braces surrounding
   them (like [TIMER-1]).

   References to other documents are listed in section 10. They are
   indicated by arabic numerals in square braces (like [1]).

1.2. Definitions

   AAP Address
     The reserved scope-relative multicast address used for the AAP
     protocol within an allocation domain.

   Allocation Domain (or domain)
     An administratively scoped multicast-capable region of the network,
     within which multicast addresses are allocated dynamically using an
     intra-domain protocol such as AAP.  Allocation domains will
     normally coincide with unicast Autonomous Systems (AS's).

     For more information, see section 3.

   Multicast
     IP Multicast, as defined in [4] and modified in [5].

   Multicast Address
     An IP multicast address or group address, as defined in [4] and
     [6].  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 [7].

   Multicast Address Allocation Server (MAAS)
     A host providing multicast address allocation services.



Handley and Hanna                                               [Page 2]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   Prefix Coordinator
     A host that announces the set of multicast addresses available for
     use within an allocation domain.

   Scope Zone
     One multicast scope may have several instances, which are known as
     Scope Zones or zones, for short.

     For instance, an organization may have multiple sites. Each site
     might have its own site-local Scope Zone, each of which would be an
     instance of the site-local Scope. However, a given interface on a
     given host would only ever be in at most one instance of a given
     scope.  Messages sent by a host in a site-local Scope Zone to an
     address in the site-local Scope would be limited to the site-local
     Scope Zone containing the host.

1.3 The Internet Multicast Address Allocation Architecture

   AAP fits into the Internet Multicast Address Allocation Architecture
   [1] being defined by the IETF Multicast Address Allocation Working
   Group. This architecture has three layers:

   o A host-server protocol or mechanism that a host uses to request
     multicast address allocation services from a Multicast Address
     Allocation Server (MAAS). An example of such a protocol is MADCAP
     [8].

   o An intra-domain protocol or mechanism that MAAS's use to coordinate
     allocations within a domain to ensure that they do not collide. AAP
     plays this role.

   o An inter-domain protocol or mechanism that coordinates multicast
     address allocation across domains to avoid duplicate allocations
     and perhaps achieve other goals, such as improving aggregation of
     multicast addresses to reduce the size of multicast routing tables.
     MASC [2] or static allocations by AS number [9] can be used at this
     layer.

1.4 Requirements

   The AAP protocol is designed to meet certain requirements which are
   appropriate for its role as an interdomain multicast address
   allocation protocol designed primarily to coordinate the actions of
   Multicast Address Allocation Servers within an allocation domain.

   o The first and most important requirement is to ensure the continued
     availability of multicast address allocation services. AAP has a
     decentralized architecture so that it can survive the failure of



Handley and Hanna                                               [Page 3]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


     one or more Multicast Address Allocation Servers or Prefix
     Coordinators.

     AAP is also designed to continue functioning during a short-term
     network partition. Long-term partitions may cause duplicate address
     allocations. Section 4.2.9 contains a more detailed discussion of
     how network partitions are handled.

   o Since multicast addresses are a relatively scarce commodity, AAP is
     designed to achieve high utilization. That is, it is designed to
     ensure that in a situation where demand for multicast addresses
     exceeds supply, all or almost all addresses can be in use
     simultaneously.

   o AAP helps MAAS's to detect and resist denial of service and other
     attacks. AAP messages may be authenticated so that unauthorized
     messages can be ignored. Even an attack from an authorized AAP
     server can be resisted by blocking all of its claims with Address
     In Use messages.

   o Duplicate address allocations (collisions) are largely avoided.
     Network partition, excessive packet loss, or unstable MAAS's can
     cause collisions, but this should be rare. When collisions occur,
     they can be detected via AAP. However, applications that use
     multicast must always be prepared to filter out extraneous traffic,
     since the IP Multicast model allows anyone to send on any multicast
     address.

2 Protocol Overview

   The Multicast Address Allocation Protocol (AAP) allows Multicast
   Address Allocation Servers (MAAS's) and Prefix Coordinators within an
   allocation domain to coordinate their actions.

   MAAS's and Prefix Coordinators communicate by sending UDP messages to
   a reserved port number and a reserved scope-relative multicast
   address (known as the AAP address). This ensures that all MAAS's and
   Prefix Coordinators within a domain receive all messages concerning
   address allocation within that domain. Assignments for the port
   number and scope-relative multicast address have been requested from
   IANA, but have not yet been assigned.

   Prefix Coordinators periodically announce the set of multicast
   addresses and lifetimes available for allocation within the domain
   using the Address Space Announce (ASA) message.

   MAAS's periodically announce with the Address In Use (AIU) message
   the set of multicast addresses that they have allocated. Before



Handley and Hanna                                               [Page 4]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   allocating addresses, a MAAS MUST listen on the AAP address for at
   least [STARTUP-WAIT] seconds so that it has a good idea of currently
   available addresses.

   To allocate one or more addresses, a MAAS sends an Address Claim
   (ACLM) message listing the addresses and lifetimes desired and
   retransmits this message at exponentially increasing intervals.  If
   another MAAS is aware of a conflicting allocation, it will send an
   AIU listing the conflict (using a randomized timer to avoid storms).
   If an AIU listing a conflict is received, the claiming MAAS will
   choose another set of addresses and start again by sending an ACLM
   for those addresses. If no AIU is received within [ANNOUNCE-WAIT]
   seconds, the claiming MAAS will consider the addresses allocated and
   being announcing them periodically using the AIU message.

   MAAS's can "preallocate" addresses using the Address Intent To Use
   (AITU) message. To preallocate one or more addresses, a MAAS
   periodically announces the preallocation using AITU. If another MAAS
   knows of a conflict, it responds as it would to a conflict to an
   ACLM. If a MAAS has sent at least two AITU messages without receiving
   notice of a conflict, it can skip the ACLM and move directly to
   sending an AIU and allocating the addresses.

   If a MAAS cannot meet its allocation needs with the addresses
   currently available for allocation, it can report this to the other
   MAAS's with an Address Not Available (ANA) message.

   An Address Space Report (ASRP) message is sent periodically by a MAAS
   (selected using random timeouts) to indicate to the Prefix
   Coordinator(s) how much of the current address space is in use and
   how many addresses are needed to satisfy demands.  Prefix
   Coordinator(s) are often small devices with no stable storage and
   this provides a way for them to track usage without having to track
   individual addresses. The Prefix Coordinator(s) may decide to
   increase or decrease the available address space in response to a
   single ASRP message or an observed trend in usage.

   If security is desired, IPsec is used to authenticate messages (using
   a manually configured shared key). Unauthenticated messages are
   ignored.

3 Scopes

   AAP can be used to manage global multicast addresses and/or
   administratively scoped multicast addresses [7]. A MAAS will
   typically use MZAP [10] to learn about the administrative scopes that
   it is in. For each scope, it will learn the range of addresses
   assigned to the scope, the name or names assigned to the scope, and



Handley and Hanna                                               [Page 5]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   whether the scope is a "large"/"divisible" scope or a
   "small"/"indivisible" scope.

   AAP MUST NOT be used to manage TTL-scoped multicast addresses.

3.1 Large Scopes

   A large scope is divided up using some interdomain multicast address
   allocation protocol or mechanism into multiple allocation domains.
   Some addresses within the large scope are assigned to each allocation
   domain and AAP (or some other intradomain protocol or mechanism) is
   used to manage these addresses within the allocation domain.

   A new administrative scope named the Allocation Scope is defined in
   section 3.3. Whenever AAP is to be used to manage addresses on large
   scopes, an Allocation Scope MUST be defined. Its boundary MUST
   coincide with the edge of the allocation domain and all large scopes
   active within the allocation domain MUST contain the Allocation
   Scope.

   The AAP traffic for managing large scopes within a given allocation
   domain is sent on the scope-relative multicast address reserved for
   AAP within the Allocation Scope.

   For the purposes of AAP, the global address space is considered to be
   a large scope, although it is not an administrative scope and its
   existence is not announced using MZAP.

3.2 Small Scopes

   The AAP traffic for managing a small scope is sent on the scope-
   relative multicast address reserved for AAP within the scope being
   managed. ASA and ASRP messages SHOULD NOT be used within a small
   scope and Prefix Coordinators are not needed, since there is no need
   to coordinate with an inter-domain protocol or mechanism. However,
   these messages MAY be sent for network management or other reasons.

   All small scopes active in an allocation domain MUST be contained
   within (or topologically equal to) the Allocation Scope for that
   allocation domain (if an Allocation Scope is defined).

3.3 The Allocation Scope -- 239.251.0.0/16

   The Allocation Scope is a new administrative scope, defined in this
   document and soon to be reserved with the IANA. The address space
   239.251.0.0/16 is reserved for the Allocation Scope. This is the
   scope that is used to run AAP for large scopes.




Handley and Hanna                                               [Page 6]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   If the Allocation Scope is not active within a region of the network,
   then AAP cannot be used to manage large scopes in that region.
   However, it can still be used to manage small scopes.

3.3.1 Expansion of the Allocation Scope

   The ranges 239.248.0.0/16, 239.249.0.0/16 and 239.250.0.0/16 are
   unassigned and available for expansion of this space.  These ranges
   should be left unassigned until the 239.251.0.0/16 space is no longer
   sufficient.

4 Multicast Address Allocation Servers

   A Multicast Address Allocation Server (MAAS) is a host providing
   multicast address allocation services. This host may be providing
   multicast address allocation services to other hosts using the MADCAP
   protocol (or some other protocol or mechanism). Alternatively, a MAAS
   may be concerned only with its own address allocation needs.

4.1 MAAS Requirements

   All MAAS's MUST maintain stable storage so that they remember their
   own address allocations, those of other MAAS's in the domain, and the
   addresses available in the domain. This stable storage MUST be
   maintained across power losses, reboots, etc.

   If the stable storage on one MAAS is lost, other MAAS's in the domain
   will continue to defend its allocations. However, the loss of stable
   storage on several MAAS's or the combination of a network outage with
   the loss of stable storage in a MAAS can result in duplicate address
   allocations.

   All MAAS's MUST attempt to maintain active participation in the AAP
   protocol at all times, with constant network connectivity. Occasional
   outages will be handled by by other MAAS's defending the missing
   MAAS's allocations, but an extended loss of connectivity with one or
   more MAAS's can result in duplicate address allocations.

   Because of these requirements (and because large numbers of MAAS's
   within an allocation domain can cause excess traffic and address
   space fragmentation), most hosts should not be MAAS's. Instead, a few
   reliable, well-connected hosts should be selected as MAAS's. Other
   hosts should connect to those MAAS's using a client-server protocol
   such as MADCAP. This will relieve them from the burdens of keeping
   the available addresses and all the allocations in the domain in
   stable storage, maintaining constant network connectivity and
   participation in the AAP protocol, and waiting [STARTUP-WAIT] seconds
   after joining the AAP address before they can allocate an address.



Handley and Hanna                                               [Page 7]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


4.2 Specification of MAAS Behavior

   The primary function of a MAAS is to allocate multicast addresses.
   The hard part is to do this robustly, efficiently, and without
   collisions.

4.2.1 The Allocation Record

   A MAAS MUST listen to messages sent to the AAP address for all scopes
   in which it is active. It MUST maintain a separate Allocation Record
   for each scope, including information about all allocations
   (announced using the AIU message), preallocations (announced using
   the AITU message), address requests (announced using the ANA
   message), and available addresses (announced using the ASA message).
   The information about allocations, preallocations, and address
   requests SHOULD be removed when they reach their end time.  The
   information about available addresses SHOULD be retained until it is
   superseded by information from a newer ASA message.

   The entries in this record allow a MAAS to defend the allocations of
   other MAAS's (if those MAAS's are unable to defend their own
   allocations for some reason). They also allow the MAAS to determine
   which addresses it should choose for its own allocations.

4.2.2 Defending Allocations

   A MAAS MUST send AIU messages periodically for all the addresses that
   it currently has allocated.  Each of these addresses SHOULD be
   included in an AIU message about every [REPEAT-INTERVAL] seconds.
   Actually, the MAAS SHOULD vary the interval by about 30% (+ or -) to
   avoid synchronization effects.

   For these regular AIU announcements (as opposed to AIU messages sent
   in response to ACLM or AITU messages or AIU messages sent with a
   shorter retransmission timer than [REPEAT-INTERVAL]), a MAAS SHOULD
   consolidate its allocated addresses into as few AIU messages as
   possible (while ensuring that the UDP payload of the AIU message does
   not exceed 500 bytes). The MAAS should also use a separate randomized
   timer for each of these messages or some similar technique to avoid
   synchronizing the time when the messages are sent. This will reduce
   the background traffic due to AIU messages and avoid synchronization
   effects.

   A MAAS that has just allocated one or more addresses SHOULD resend
   the AIU for those addresses again after [RESEND-WAIT] seconds, and
   again after a further [RESEND-WAIT]*2 seconds, doubling each time
   until the interval reaches [REPEAT-INTERVAL] seconds.




Handley and Hanna                                               [Page 8]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   When a MAAS A receives an ACLM or AITU message from another MAAS B,
   it SHOULD check its Allocation Record to see whether it believes that
   any of the addresses in question are already allocated (that is,
   whether it has received an AIU for those addresses). If so, it SHOULD
   set an Allocation Defense timer based on the algorithm below and
   follow the processing rules described in the next two paragraphs.

   If MAAS A sees an AIU message from someone other than MAAS B
   containing one or more of the addresses in question before the
   Allocation Defense timer expires, it SHOULD restart the timer with
   double its original value. If MAAS A sees an ACLM or AITU message
   from MAAS B with the same Request Sequence Number and a different set
   of addresses, it SHOULD cancel the Allocation Defense timer and check
   this message against the Allocation Record as described above.

   If MAAS A's Allocation Defense timer expires, it SHOULD send an AIU
   message containing the addresses in question and restart the timer
   with twice its previous value, unless that value was 0, in which case
   it SHOULD set it to [RESEND-WAIT]. If the timer interval becomes
   greater than [REPEAT-INTERVAL], the timer SHOULD be cancelled. In
   this case, the remote MAAS probably suffered some form of failure
   after sending the ACLM or AITU.

   The initial value for the Allocation Defense timer is determined as
   follows:

   o If MAAS A allocated one or more of the addresses in question, the
     initial value of the timer is 0.

   o If MAAS A did not allocate any of the addresses in question, the
     initial value of the timer (t) is set to a random number between
     [RESEND-WAIT]*2 and [RESEND-WAIT]*8.

4.2.3 Startup

   When a MAAS starts up, it MUST listen to AAP messages for at least
   [STARTUP-WAIT] before it can allocate addresses. For large scopes, it
   SHOULD also have received at least one ASA message.  If it does not
   receive an ASA message within this time, it MAY allocate addresses
   only if it has cached a previous ASA message which includes at least
   one range that has not reached its end time.

4.2.4 Allocating Addresses Using ACLM

   The simplest way to allocate addresses using AAP is to use the
   Address Claim (ACLM) message. The MAAS selects one or more addresses
   and an end time for the claim (using the techniques described in
   section 4.2.6). It then sends these addresses in an ACLM message.



Handley and Hanna                                               [Page 9]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   After sending the ACLM message, the MAAS SHOULD then set a Claim
   Timer for [ANNOUNCE-WAIT] seconds in the future. The MAAS SHOULD also
   resend the ACLM message after [RESEND-WAIT] seconds, and again after
   a further [RESEND-WAIT]*2 seconds, doubling each time until the Claim
   Timer expires.

   If the MAAS receives an ACLM message or an AIU message from another
   MAAS listing an address being claimed before the Claim Timer expires,
   this indicates a collision. It MUST cancel the Claim Timer and give
   up on the addresses mentioned in the ACLM or AIU message.  It MAY
   choose new addresses (possibly including addresses in the original
   claim for which no collisions were report), send another ACLM message
   with the same Request Sequence Number listing the new addresses, and
   set a new Claim Timer for [ANNOUNCE-WAIT] seconds in the future.

   If the MAAS receives an ASA message whose Expiration Time (after
   adjusting for clock skew, as described in section 6.3.1) is newer
   than the last ASA message processed and the newer ASA message does
   not indicate that all of the addresses being claimed are available,
   the MAAS MUST cancel the Claim Timer and give up on the unavailable
   addresses. This should not normally happen, since the MAAS should
   have been aware of the set of available addresses before it sent out
   the ACLM message and the set of available addresses should not change
   in a way that invalidates outstanding claims.

   If the Claim Timer expires, the MAAS can conclude that there is a
   good probability that the addresses being claimed are unique.  It
   SHOULD then send an AIU message listing those addresses and add the
   addresses to its list of allocated addresses.

4.2.4.1 Anticipatory Allocation

   A MAAS may allocate addresses because they are needed to satisfy an
   immediate demand or in anticipation of a future demand. Anticipatory
   allocation can reduce the amount of time required for a MAAS to
   respond to an allocation request.

   However, MAAS's SHOULD be moderate in their anticipatory allocations,
   especially those with distant end times.  If a MAAS allocates one or
   more addresses with a distant end time in anticipation of demand and
   then the MAAS fails, other MAAS's will defend the allocation and the
   address space will be effectively lost.

   Preallocation is a better way to handle this problem, as well as
   several others.

4.2.5 Preallocating Addresses using AITU




Handley and Hanna                                              [Page 10]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   Preallocation (using the Address Intent To Use or AITU message)
   allows a MAAS to indicate which addresses it intends to use in the
   future. Other MAAS's will attempt to avoid using these addresses.
   However, these addresses are not completely off-limits, as they would
   be if the MAAS allocated them (using the AIU message). Other MAAS's
   are free to allocate preallocated addresses if address space runs
   low.

   To preallocate an address, a MAAS selects one or more addresses and
   an end time for the preallocation (using the techniques described in
   section 4.2.6). It then sends these addresses in an AITU message.
   After sending the AITU message, the MAAS SHOULD then set a
   Preallocation Timer for [ANNOUNCE-WAIT] seconds in the future.

   The AITU message SHOULD be resent with the same time intervals as an
   AIU message - i.e. the interval between messages starts at [RESEND-
   WAIT] seconds and doubles until it reaches [REPEAT-INTERVAL].  As
   with an AIU message, the MAAS SHOULD vary the interval by about 30%
   (+ or -) to avoid synchronization effects.

   If the MAAS receives an ACLM, AITU, or AIU message from another MAAS
   listing one or more of the addresses being preallocated before the
   Preallocation Timer expires, this indicates a collision. It MUST
   cancel the Preallocation Timer and give up on that preallocation. It
   MAY choose another set of addresses, send another AITU message with
   the same Request Sequence Number listing the new addresses, set a new
   Preallocation Timer for [ANNOUNCE-WAIT] seconds in the future, and
   begin resending the AITU message again.

   If the MAAS receives an ASA message whose Expiration Time (after
   adjusting for clock skew, as described in section 6.3.1) is newer
   than the last ASA message processed and the newer ASA message does
   not indicate that all of the addresses in the AITU message are
   available, the MAAS MUST cancel the Preallocation Timer and give up
   on the unavailable addresses. This should not normally happen, since
   the MAAS should have been aware of the set of available addresses
   before it sent out the AITU message and the set of available
   addresses should not change in a way that invalidates outstanding
   claims.

   If the Preallocation Timer expires, the MAAS can conclude that there
   is a good probability that there is no collision. It SHOULD continue
   sending the AITU message listing these addresses and can add the
   addresses to its list of preallocated addresses.

   However, if the MAAS receives an AITU, ACLM, or AIU message from
   another MAAS listing one or more of the preallocated addresses, the
   MAAS MUST abandon the preallocation. Also, if the MAAS processes an



Handley and Hanna                                              [Page 11]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   ASA message that does not indicate that all of the addresses in the
   AITU message are available, the MAAS MUST abandon the preallocation.

4.2.5.1 Allocating a Preallocated Address

   Once a set of addresses has been preallocated, there should not be
   any collisions for those addresses. Therefore, the MAAS that
   preallocated the addresses can skip the ACLM portion of the
   allocation process and go directly to the normal process of sending
   an AIU message.

   To be explicit, when a MAAS that has preallocated some addresses
   wants to allocate one or more of those addresses, it SHOULD send an
   AIU message for the addresses, resend the AIU again after [RESEND-
   WAIT] seconds, and again after a further [RESEND-WAIT]*2 seconds,
   doubling each time until the interval reaches [REPEAT-INTERVAL]
   seconds.

   If the MAAS is allocating only a subset of the addresses that were
   preallocated, it SHOULD continue sending the AITU message for the
   remaining preallocated addresses.

4.2.5.2 Benefits of Preallocation

   Preallocation has several benefits. First, it allows a MAAS to
   respond to requests for addresses rapidly without requiring the MAAS
   to allocate addresses in anticipation of demand (which uses up
   address space needlessly).

   Second, and most importantly, it provides some protection against
   network partition. If MAAS's have preallocated addresses before a
   network partition, they can satisfy allocation requests safely by
   using those preallocated addresses.  Other MAAS's will avoid using
   those preallocated addresses because they heard the preallocation
   announcement before the network partition. See section 4.2.9 for
   limitations of this technique and more details about handling network
   partition.

4.2.6 Selecting Addresses for Allocation or Preallocation

   The first step in allocating or preallocating addresses is to select
   the addresses to use.

   The first selection criterion SHOULD be to favor addresses that have
   not been allocated or preallocated by any other MAAS. This can be
   determined by consulting the Allocation Record, including the set of
   addresses advertised in the most recent ASA message.




Handley and Hanna                                              [Page 12]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   If there are no more addresses that have not been allocated or
   preallocated by any other MAAS, then preallocation MUST NOT be done.
   However, allocation (using ACLM) is allowed. For allocation, the next
   choice SHOULD be addresses that have been preallocated and where the
   preallocation has been announced recently. After that SHOULD come
   addresses that have been preallocated and where the preallocation has
   not been announced recently.

   The rationale for this preference is that with addresses that have
   been preannounced recently, the MAAS that preallocated them will
   probably be able to hear the ACLM messages and stop preallocating the
   addresses.  With addresses that have not been preannounced recently,
   the MAAS that preallocated them may not be able to hear the ACLM
   messages (due to network partition or other failure) and may then
   proceed to allocate them, causing a collision.

   A further criterion that SHOULD be applied if the first criterion
   provides several options is that a MAAS SHOULD choose addresses from
   an address range whose end time is the shortest that will satisfy the
   requirements of the MAAS.

   If several options are still available, the MAAS SHOULD favor
   addresses which are adjacent to other addresses already allocated by
   the MAAS. This will allow the MAAS to avoid increasing the size of
   its AIU messages. And if there are still several options available,
   the MAAS SHOULD favor addresses that are far from addresses allocated
   by other MAAS's. This will make it more likely that this MAAS and the
   other MAAS's will be able to add adjacent addresses to their
   allocations in the future.

4.2.7 Choosing an End Time for Allocation or Preallocation

   When allocating or preallocating an address, a MAAS chooses an end
   time and includes this end time in the ACLM, AIU, or AITU messages
   that it sends. This is the time until which the addresses should be
   allocated (or preallocated). After this time, they may be removed
   from the Allocation Records of other MAAS's in the domain.

   The allocating MAAS can choose this end time in any way it likes, as
   long as the end time does not exceed the lifetime listed for that
   address in the ASA message. In order to avoid excess traffic, MAAS's
   SHOULD NOT use many short-lived allocations. Instead, they should use
   a few long-lived allocations and reuse those addresses. This also has
   the benefit of ensuring that if the network is partitioned,
   allocations for MAAS's on one side of the partition will not time out
   of the Allocation Records of MAAS's on the other side of the
   partition.




Handley and Hanna                                              [Page 13]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   A MAAS can change the end time for an allocated or preallocated
   address at any time by changing it in the AIU or AITU message for
   that address.  This technique can be used to extend an allocation or
   to shorten it. By reducing the end time to a time a few minutes after
   the current time, the allocation is effectively deleted.

   Note that if some MAAS's are partitioned from the network during the
   time when this deletion is being announced, they may defend the
   earlier allocation when they are later reconnected. In this case, the
   MAAS that deleted the allocation SHOULD advertise the allocation
   again with the correct end time (now in the past) so that it is
   deleted from the Allocation Records of the MAAS's that were
   partitioned.

   No start time is included in any AAP messages because all allocations
   start immediately. It is too difficult to manage two MAAS's with
   allocations for the same address at different times. However, a
   single MAAS can reuse an address for multiple clients over time.

4.2.8 Allocation Failure

   If no addresses are available that meet the demands placed on the
   MAAS (either because there are no addresses available at all or
   because the lifetimes of the available addresses are not long
   enough), the MAAS should indicate this by sending an Address Not
   Available (ANA) message. This will allow other MAAS's to note the
   allocation failure and report it to the Prefix Coordinator in the
   next ASRP message.  The Prefix Coordinator may, in response, attempt
   to allocate more addresses or get a longer lifetime.

   Since small scopes do not have Prefix Coordinators, MAAS's MUST NOT
   send ANA messages for small scopes. Instead, they MAY log the failed
   allocation so that the administrator can increase the number of
   addresses in the scope.

   An ANA message contains an address count and a requested lifetime.
   When an allocation fails, the MAAS SHOULD assemble and send an ANA
   message. After sending the ANA message, the MAAS SHOULD set an ANA
   Retransmission Timer for [ANNOUNCE-WAIT] seconds in the future. The
   MAAS SHOULD also resend the ANA message after [RESEND-WAIT] seconds,
   and again after a further [RESEND-WAIT]*2 seconds, doubling each time
   until the ANA Retransmission Timer expires.

   A MAAS that receives an ANA message SHOULD check to see if it already
   has noted this address request in its Allocation Record (by comparing
   the number of addresses, lifetime, and Request Sequence number). If
   not, it SHOULD add the request.




Handley and Hanna                                              [Page 14]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   Because ANA messages are not repeated indefinitely, each MAAS may
   have a different set of address requests in its Allocation Record.
   This is normal and should not cause a problem.

4.2.9 Network Partition

   The AAP protocol is designed to continue functioning properly in
   spite of short-term network partitions or server failures.

   However, certain steps should be taken to ensure optimal robustness.
   First, MAAS's SHOULD preallocate enough addresses to last through a
   short-term network partition (1 hour is a reasonable default).
   Second, if the network is partitioned, no new MAAS's should be added
   during the partition. Otherwise, the new MAAS's will not know about
   addresses preallocated by MAAS's separated from them by the network
   partition.

   The failure of one or more MAAS's should not cause significant
   problems. Other MAAS's will defend the allocations of the failed
   MAAS's until their end time. After that, the allocations will be
   deleted.

   The failure of one or more Prefix Coordinators is also accomodated.
   If another Prefix Coordinator is still around, it will pick up the
   duties of the failed Prefix Coordinator. If no Prefix Coordinators
   are working, the MAAS's will resend the latest ASA message until the
   Prefix Coordinators are working again. In this circumstance, the
   system should continue to work until the address lifetimes listed in
   the ASA message expire.

4.2.10 Interacting with Prefix Coordinators

   In "large" scopes, one or more Prefix Coordinators handle the
   interaction between MAAS's within the allocation domain and those in
   other allocation domains within the scope.  In particular, the Prefix
   Coordinators periodically announce the set of multicast addresses
   available for allocation within the domain using the Address Space
   Announce (ASA) message. And MAAS's periodically inform the Prefix
   Coordinators of how much address space is currently in use, using the
   Address Space Report (ASRP) message.

   Prefix Coordinators (along with the ASA and ASRP messages) are not
   needed or used in small scopes.  In a small scope, the complete set
   of addresses in the scope (as indicated by MZAP) is considered to be
   available for use within the allocation domain, for an indefinite
   lifetime.

4.2.10.1 Processing ASA Messages



Handley and Hanna                                              [Page 15]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   The ASA message lists a number of address ranges, each of which has
   an associated lifetime. The announcement also contains a timestamp to
   detect replays or clock skew and an expiration time.  Each ASA
   message MUST contain the complete set of addresses available for a
   given scope in the allocation domain at the time the message was
   sent. A Prefix Coordinator MUST NOT attempt to split the available
   addresses across multiple ASA messages.  As described in section
   4.2.11, each ASA message MUST pertain only to one scope and each MAAS
   (and Prefix Coordinator) MUST treat each scope separately.

   When an ASA message is received, a MAAS SHOULD adjust the Expiration
   Time for clock skew as described in section 6.3.1 and compare it to
   the adjusted Expiration Time of the last ASA message processed. If
   the adjusted Expiration Time of the newly received ASA message is
   earlier than or equal to the adjusted Expiration Time of the last ASA
   message processed, the newly received ASA message SHOULD be ignored.
   Otherwise, it SHOULD be processed.

   Under normal circumstances, the set of addresses available in the
   allocation domain should change in only three ways. First, addresses
   can be removed once they have reached the end of their lifetime.
   Second, the lifetime of one or more addresses can be extended. Third,
   new addresses can be added. Any other change in the set of available
   addresses (removing addresses, moving their start time later, or
   making their end time earlier) is called an invalidating change,
   since it may invalidate MAAS allocations and therefore SHOULD be
   strongly avoided.

   If an ASA message being processed does not contain any invalidating
   changes (as determined by comparing it to the last ASA message
   processed), it can be processed by updating the set of available
   addresses in the Allocation Record (and caching the UDP payload of
   the ASA message, as described later). If the ASA message extends the
   lifetime of one or more addresses or adds new addresses, any
   outstanding address requests in the Allocation Record SHOULD be
   checked to see if they have been satisfied. If so, they SHOULD be
   removed from the Allocation Record.

   It may sometimes be necessary to make an invalidating change. If a
   MAAS detects such a change, it should revise all allocations and
   preallocations in its Allocation Record to conform with the change.
   Actually, it need not revise its Allocation Record, but SHOULD behave
   within AAP as if it has done so.  The MAAS or its clients SHOULD also
   stop using the invalidated addresses in any way which conflicts with
   their revised status as soon as possible. If a MAAS detects an
   invalidating change, it MAY log a message or otherwise alert an
   administrator. An invalidating change is an unusual and highly
   undesirable situation.



Handley and Hanna                                              [Page 16]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   ASA messages MAY alternate between several cooperating Prefix
   Coordinators.  One common reason for invalidating changes is when an
   allocation domain has two Prefix Coordinators whose actions are not
   coordinated.  This is a serious error that may make it nearly
   impossible for MAAS's to allocate new addresses so this situation
   should be remedied as soon as possible.

   To prevent hostile parties from causing a denial of service by
   sending invalidating ASA messages, ASA messages SHOULD be
   authenticated and MAAS's SHOULD ignore unauthenticated ASA messages.
   See section 7 (Security Considerations) for more information.

4.2.10.2 Resending ASA Messages

   All ASA messages include an Expiration Time. Normally, the Expiration
   Time is set so that several newer ASA messages will have been sent
   before an ASA message expires. If an ASA message expires in a MAAS's
   Allocation Record (that is, no newer ASA messages have been received
   at the Expiration Time) and the MAAS is not in startup mode,
   something has gone wrong. Either the Prefix Coordinator has stopped
   sending ASA messages or they are being lost.

   Under such a circumstance, a MAAS MAY log an error or notify an
   operator. However, the MAAS SHOULD continue to work, using the
   information in the old ASA until the address lifetimes are exceeded.
   The MAAS SHOULD also resend the information included in the old ASA,
   as described in the next paragraph. This allows new MAAS's to find
   out what addresses are available for allocation.  It also allows a
   Prefix Coordinator to recover this information if it has lost it (by
   losing its stable storage or simply rebooting, if it does not have
   stable storage) and it cannot recover it via another mechanism (from
   its MASC peers, for instance).

   When an ASA message expires, each MAAS SHOULD choose a random number
   between [ASA-INTERVAL]*0.7 and [ASA-INTERVAL]*1.3.  It should set an
   ASA Resend timer for a time this far in the future. If the timer
   expires without an ASA message arriving, the MAAS SHOULD send an ASA
   message with the same contents as the expired ASA message, but with
   the Current Time field incremented by the amount of time passed since
   the expired ASA message was received.

   Updating the Current Time field ensures that anyone who receives the
   message will be able to adjust the times in the message properly to
   compensate for clock skew (as described in section 6.3.1). It also
   ensures that the Current Time will be greater than the Expiration
   Time, which makes it evident that this is a retransmitted ASA
   message.




Handley and Hanna                                              [Page 17]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   If the MAAS receives an ASA with an Expiration Time that is newer
   (after adjustment for clock skew) than the Expiration Time of the
   cached message before the timer expires, it SHOULD discard the timer
   and process the newer ASA message.

   If, however, the MAAS receives an ASA message that does not have a
   newer adjusted Expiration Time, the MAAS SHOULD simply reset the ASA
   Resend timer to a new random number in the same range.

4.2.10.3 Sending ASRP Messages

   Unless otherwise configured, all MAAS's SHOULD participate in sending
   periodic ASRP messages to the AAP address (for large scopes).  An
   ASRP message lists the same address ranges included in the most
   recent ASA message, along with the number of addresses used in each
   range. It may also include a list of address requests, each of which
   contains a number of addresses and a lifetime. As described in
   section 4.2.11, each ASRP message MUST pertain only to one scope and
   each MAAS (and Prefix Coordinator) MUST treat each scope separately.

   Whenever a MAAS completes its [STARTUP-WAIT] period, it SHOULD choose
   a random number between [ASRP-INTERVAL]*0.7 and [ASRP-INTERVAL]*1.3.
   It should set an ASRP Send timer for a time this far in the future.
   If the timer expires without an ASRP message for that scope being
   received, the MAAS SHOULD send an ASRP message containing a summary
   of current address space usage in the allocation domain for that
   scope. If an ASRP message for that scope is received before the timer
   expires, the MAAS SHOULD reset the ASRP Resend timer to a new random
   number in the same range.

   When sending an ASRP message, a MAAS should list each address range
   included in the most recent ASA message, along with the number of
   addresses used in each range (calculated by consulting the Allocation
   Record).  The address requests should be constructed based on the
   address requests noted in the Allocation Record. These requests
   SHOULD be combined to ensure that the UDP payload of the ASRP message
   does not exceed 500 bytes.  The address requests SHOULD be combined
   by finding requests whose end times are similar, adding their counts,
   and taking the earlier of the two start times. This (and other
   effects) will cause changes in the address request list from one ASRP
   message to another, but that is to be expected.

4.2.11 Handling Multiple Scopes

   When a MAAS is handling multiple scopes at the same time, it should
   treat each scope separately. With multiple large scopes which share a
   single allocation domain and Allocation Scope, each AAP message MUST
   pertain to only one scope, so that a MAAS that is not interested in a



Handley and Hanna                                              [Page 18]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   particular scope can discard messages pertaining to other scopes.

5 Prefix Coordinators

   A Prefix Coordinator is a host that announces the set of multicast
   addresses available for use within an allocation domain.  Prefix
   Coordinators are not needed for "small" scopes, where all addresses
   in the scope are available for use within the allocation domain.

   The mechanism or protocol by which a Prefix Coordinator determines
   the set of available addresses is not specified in this document. It
   may use an inter-domain protocol such as MASC, static allocations by
   AS number [9], or some other system.  It makes no difference to AAP
   or to the MAAS's.

5.1 Prefix Coordinator Requirements

   Prefix Coordinators SHOULD listen to and participate in the AAP
   protocol on a regular basis, in order to send ASA messages and
   receive ASRP messages. However, if a Prefix Coordinator is
   temporarily unable to participate in the AAP protocol, MAAS's within
   the allocation domain will step in and send ASA messages on its
   behalf.

   This ASA resend feature may also be used to restore the state of a
   Prefix Coordinator which has lost its state. Therefore, Prefix
   Coordinators need not have stable storage. If their state is lost
   (during a power failure, for instance), they can use the information
   in the ASA messages resent by MAAS's to restore their state.

   However, a prolonged outage on the part of a Prefix Coordinator will
   result in the expiration of the prefix lifetimes advertised by the
   Prefix Coordinator in its ASA message. And an inoperative Prefix
   Coordinator will not be able to respond to changes in demand, as
   reported by MAAS's using ASRP messages. Therefore, it is best for a
   Prefix Coordinator to be functioning at all times.

   A Prefix Coordinator can be a MASC router or another host. But it
   should be located on a machine with sufficient processing power and
   network connectivity to participate in the AAP protocol.

5.2 Specification of Prefix Coordinator Behavior

   The primary function of a Prefix Coordinator is to announce the set
   of multicast addresses available for use within an allocation domain.
   It is also responsible for accepting feedback from MAAS's regarding
   demand for addresses.




Handley and Hanna                                              [Page 19]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


5.2.1 Sending ASA Messages

   The ASA message lists a number of address ranges, each of which has
   an associated lifetime. The announcement also contains a timestamp to
   detect replays or clock skew and an expiration time.  Each ASA
   message MUST contain the complete set of addresses available for a
   given scope in the allocation domain at the time the message was
   sent.  A Prefix Coordinator MUST NOT attempt to split the available
   addresses across multiple ASA messages. As described in section
   5.2.3, each ASA message MUST pertain only to one scope and each MAAS
   (and Prefix Coordinator) MUST treat each scope separately.

   When a Prefix Coordinator is ready to begin announcing addresses in
   an allocation domain, the Prefix Coordinator SHOULD choose a random
   number between [ASA-INTERVAL]*1.7 and [ASA-INTERVAL]*2.3.  It should
   set an ASA Send timer for a time this far in the future. If the timer
   expires without a new (not resent) ASA message arriving, the Prefix
   Coordinator SHOULD send an ASA message and reset the timer to a new
   random number between [ASA-INTERVAL]*0.7 and [ASA-INTERVAL]*1.3.  A
   Prefix Coordinator can identify a resent ASA message by checking the
   Expiration Time in the message. If the Expiration Time exceeds the
   Current Time in the message, the message has been resent by a MAAS.

   If a Prefix Coordinator receives a new (not resent) ASA message
   before the timer expires, it should reset the timer to a new random
   number between [ASA-INTERVAL]*1.7 and [ASA-INTERVAL]*2.3.  If more
   than one Prefix Coordinator is operating within a domain, this timer
   mechanism should encourage one of the Prefix Coordinators (the "lead
   Prefix Coordinator") to take the lead, consistently sending ASA
   messages. However, if that Prefix Coordinator stops working (due to
   failure or network partition), another Prefix Coordinator will step
   in to take its place. The timers used by a Prefix Coordinator MAY be
   reduced to ensure that it will become the lead Prefix Coordinator.

5.2.1.1 Avoiding Invalidating Changes

   Under normal circumstances, the set of addresses available in the
   allocation domain should change in only three ways. First, addresses
   can be removed once they have reached the end of their lifetime.
   Second, the lifetime of one or more addresses can be extended. Third,
   new addresses can be added. Any other change in the set of available
   addresses (removing addresses, moving their start time later, or
   making their end time earlier) is called an invalidating change,
   since it may invalidate MAAS allocations and therefore SHOULD be
   strongly avoided.

   One common reason for invalidating changes is when an allocation
   domain has two Prefix Coordinators which are announcing different



Handley and Hanna                                              [Page 20]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   sets of available addresses.  This is a serious error that may make
   it nearly impossible for MAAS's to allocate new addresses so this
   situation should be remedied as soon as possible.

   If more than one Prefix Coordinator is active within a single
   allocation domain, the Prefix Coordinators MUST be configured so that
   their actions are coordinated. They MUST NOT announce different sets
   of addresses. To detect and correct such a situation, a Prefix
   Coordinator that detects ASA messages from another Prefix Coordinator
   that are not consistent with its own SHOULD notify an operator and
   stop sending ASA messages until it has not heard a new (not resent)
   inconsistent ASA message for at least [ASA-INTERVAL]*5 seconds. This
   default behavior may be overridden by configuration.

   This behavior allows a malicious person to send invalid ASA messages,
   confusing the MAAS's and keeping the valid Prefix Coordinator from
   sending ASA messages. The best solution for this problem is for
   MAAS's and Prefix Coordinators to ignore messages unless they are
   authenticated. Then the invalid ASA messages will be ignored.  Even
   without authentication, the valid Prefix Coordinator will notify the
   operator of the problem and the MAAS's MAY log an error or alert an
   administrator when they see an invalidating change.

5.2.2 Processing ASRP Messages

   Prefix Coordinators SHOULD (unless otherwise configured) listen for
   and process ASRP messages. ASRP messages are sent periodically by
   MAAS's and are intended to report address space usage to Prefix
   Coordinators.

   When a MAAS sends an ASRP message, it includes the address ranges it
   received in the ASA message it processed most recently, along with
   the number of addresses used in each range. It may also include a
   list of address requests, each of which contains a number of
   addresses and a lifetime. As described in section 4.2.11, each ASRP
   message MUST pertain only to one scope and each MAAS (and Prefix
   Coordinator) MUST treat each scope separately.

   When a Prefix Coordinator receives an ASRP message, it SHOULD ignore
   the message unless it is the lead Prefix Coordinator (unless
   otherwise configured). If the Prefix Coordinator is the lead Prefix
   Coordinator, it SHOULD first check to see whether the address ranges
   included in the ASRP message match the address ranges that it has
   most recently announced.  If the address ranges do not match, it
   SHOULD ignore the ASRP message and MAY log a message.

   Otherwise, the Prefix Coordinator MAY process the data included in
   the ASRP message in whatever way it deems appropriate. The algorithm



Handley and Hanna                                              [Page 21]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   used by the Prefix Coordinator to decide what actions to take, if
   any, and the mechanism or protocol used to effect these actions are
   beyond the scope of this document. However, with MASC the actions
   might include a request for more addresses and with a static
   allocation mechanism the actions might include a notice to an
   operator that more (or fewer) addresses are needed. Taking no action
   at all is also acceptable.

   In general, it is expected that the goals of the Prefix Coordinator
   in responding to ASRP messages may be as follows. If it notices that
   there is a growing demand for addresses, it may attempt to allocate
   more addresses via a higher-level mechanism. If it notices a
   diminishing demand, it may choose not to extend the lifetime of
   certain addresses. It may also choose to allocate addresses to
   respond directly to the list of address requests included in the ASRP
   message, although this is intended more as an indication of emergent
   demand than a specific request for addresses.

5.2.3 Handling Multiple Scopes

   When a Prefix Coordinator is handling multiple scopes at the same
   time, it should treat each scope separately. With multiple large
   scopes which share a single allocation domain and Allocation Scope,
   each AAP message MUST pertain to only one scope, so that a MAAS that
   is not interested in a particular scope can discard messages
   pertaining to other scopes.

6 Protocol Details

   This section describes the message formats and specifics of message
   processing.

6.1 Message Formats

   AAP messages are binary format, as the additional flexibility of
   having a textual format is not required in this case.

   All AAP messages start with a common header, followed by a body whose
   format differs depending on the message type. Figure 1 shows the
   format of the header and Table 1 describes each of the fields in the
   header. The numbers in parentheses indicate the size of each field in
   octets. The names for the fields given in the figure are used
   throughout this document to refer to the fields in AAP messages.

   All multi-octet quantities are in network byte-order.

   Any message whose UDP data is too short to hold this format (at least
   12 bytes) MUST be ignored.



Handley and Hanna                                              [Page 22]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   +-+-+-+-+-+-+-+-+
   |  version (1)  |
   +---------------+
   |  msgtype (1)  |
   +---------------+
   |  addrfamily   |
   |     (2)       |
   +---------------+
   |     rseq      |
   |     (3)       |
   |               |
   +---------------+
   |   mseq (1)    |
   +---------------+
   |               |
   |     body      |
   |  (variable)   |
   |      ...      |
   +---------------+

                 Figure 1:  Format of an AAP message

   FIELD      OCTETS       DESCRIPTION
   -----      ------       -----------

   version       1  Protocol version number (zero for this specification)
   msgtype       1  Message type (ACLM, AIU, etc.)
   addrfamily    2  Address family (IPv4, IPv6, etc.)
   rseq          3  Request sequence number
   mseq          1  Message sequence number
   body        var  Body (format varies by msgtype)

           Table 1:  Description of fields in an AAP message

6.1.1 The version field

   The version field MUST always be zero for this version of the
   protocol.  Any messages that include other values in this field MUST
   be ignored.

6.1.2 The msgtype field

   The msgtype field defines the "type" of a MADCAP message.

   For more information about this field, see section 6.2.

6.1.3 The addrfamily field




Handley and Hanna                                              [Page 23]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   The addrfamily field defines the default address family (such as IPv4
   or IPv6) for this AAP message, using the address family numbers
   defined in by the IANA (including those defined in [10]). Unless
   otherwise specified, all addresses included in the message will be
   from this family.

6.1.4 The rseq field

   The rseq field is a Request Sequence Number. The first message that a
   MAAS or Prefix Coordinator sends after a restart should have a
   request sequence number of 0 and the request sequence number should
   be incremented for every subsequent distinct message or request. When
   an AITU or ACLM message results in a detected clash, a new address is
   chosen and an new message is sent with the same rseq as the original.
   In such cases, the message sequence number (mseq) is incremented
   instead.  AIU messages always get new RSEQ if the addresses in use
   change, otherwise MSEQ is incremented instead.  ASA messages always
   get a new RSEQ because they may alternate sender between multiple
   Prefix Coordinators.

   At peak usage rates of one request per second, it is possible for the
   RSEQ space to wrap about every 6 months.  It is unlikely that any
   message sequence will last this long, but it conceivable that an AITU
   message sequence might do so.  Implementors should be aware of this
   possibility and avoid reusing the RSEQ value that is in use.

6.1.5 The mseq field

   The mseq field is a message sequence number that is used to identify
   different messages of the same request.  For example, if a MAAS sends
   a new ACLM message with RSEQ=27, MSEQ=0, and receives an AIU message
   from another MAAS for the same address, it then chooses a new address
   and sends a new ACLM message with RSEQ=27, MSEQ=1.  This may be
   resent after [RESEND-WAIT] seconds with RSEQ=27, MSEQ=2, after
   [RESEND-WAIT]*2 seconds with RSEQ=27, MSEQ=3, etc. After [ANNOUNCE-
   WAIT] seconds, the MAAS can send an AIU message for the address with
   RSEQ=28, MSEQ=0.

   MSEQ may wrap when AITU is sent for longer than about 2 hours (with
   default timer values) without an address being requested.  This
   should not cause a problem, but if MSEQ and RSEQ are being used to
   monitor loss, this should be taken into account.

   MSEQ may also wrap if a long serious of address collisions occurs
   when sending ACLM.  Under normal circumstances, this is extremely
   unlikely and probably signals a denial-of-service attack.
   Implementors should be aware of this possibility.




Handley and Hanna                                              [Page 24]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


6.1.6 The body field

   The format of the body field varies, depending on the value of the
   msgtype field. For more information, see section 6.4.

6.2. Message Types

   The msgtype field defines the type of an AAP message. Legal values
   for this field are:

           Value   Message Type
           -----   ------------
             0     Address Claim (ACLM)
             1     Address In Use (AIU)
             2     Address Intent To Use (AITU)
             3     Address Space Announce (ASA)
             4     Address Space Report (ASRP)
             5     Address Not Available (ANA)

      Table 2:  AAP message types

   Throughout this document, AAP messages are referred to by the type of
   the message; e.g., an AAP message with a message type of 1 is
   referred to as an AIU message.

   MAAS's and Prefix Coordinators MUST handle all AAP message types
   defined in this document in a manner consistent with this document.
   If a MAAS or Prefix Coordinator receives an AAP message whose message
   type it does not recognize, it MUST ignore the message.

   New AAP message types may only be defined by IETF Consensus, as
   described in section 7.

   For a brief description of the AAP message types, see section 2. For
   a description of how each message should be handled by MAAS's and
   Prefix Coordinators, see sections 4 and 5. And for a description of
   the format of the message body for each message type, see section
   6.4.

6.3 AAP Time Fields

   AAP messages contain a number of places where absolute times must be
   represented. These time values are represented as unsigned 32 bit
   integers in network byte order giving the number of seconds since
   00:00 UTC, 1st January 1970. This arbitrary baseline is convenient on
   many current operating systems and can be converted to an NTP [13]
   timestamp by adding decimal 2208988800. Thus AAP time fields will not
   wrap until the year 2106.



Handley and Hanna                                              [Page 25]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


6.3.1 Correcting for Clock Skew

   All AAP messages that include an absolute time field also include a
   Current Time field. This field SHOULD be used to detect and correct
   for clock skew. The sender SHOULD set the Current Time field to the
   time when the message is sent (as indicated by the sender's clock).
   The receiver SHOULD determine the difference between the Current Time
   indicated in the message and the time when the message is received
   (as indicated by the receiver's clock).  Then it SHOULD add this
   difference to all times in the AAP message.

   This will adjust the times to compensate for any clock skew between
   the sender and the receiver. Unfortunately, it will also cause times
   in the messages to drift backward due to message transmission time.
   However, this drift should not accumulate under normal circumstances.
   A few seconds' drift should not cause any problems with multicast
   address allocation, since MAAS's should be allowing minutes or hours
   of buffer time between allocations, anyway.

   See Appendix A for an example of correcting for clock skew.

6.4 Body Formats

   The format of the AAP message body depends on the value of the
   msgtype field. Here is a description of the body formats associated
   with all message types defined in this document.

6.4.1 Address Claim (ACLM)

   The Address Claim (ACLM) message is used by a MAAS to announce
   addresses that it wants to allocate.

       Current Time      Range 1     Range 2        ...
   +----+----+----+----+----...----+----...----+----...----+
   |   current-time    |     R1    |     R2    |           |
   +----+----+----+----+----...----+----...----+----...----+

   where each of the Ranges is of the following format:

       First       Last
      Address     Address         End Time
   +----...----+----...----+----+----+----+----+
   |   first   |   last    |      end-time     |
   +----...----+----...----+----+----+----+----+

   current-time is the current time at the sending MAAS.

   first and last are the first and last address in the range of



Handley and Hanna                                              [Page 26]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   addresses being claimed.  The address family of the addresses is
   determined by the addrfamily field in the message header.

   end-time is the time when the sending MAAS plans to stop using the
   addresses.

6.4.2 Address In Use (AIU)

   The Address In Use (AIU) message is used by a MAAS to announce
   addresses that it has allocated.

       Current Time      Range 1     Range 2        ...
   +----+----+----+----+----...----+----...----+----...----+
   |   current-time    |     R1    |     R2    |           |
   +----+----+----+----+----...----+----...----+----...----+

   where each of the Ranges is of the following format:

       First       Last
      Address     Address         End Time
   +----...----+----...----+----+----+----+----+
   |   first   |   last    |      end-time     |
   +----...----+----...----+----+----+----+----+

   current-time is the current time at the sending MAAS.

   first and last are the first and last address in the range of
   allocated addresses.  The address family of the addresses is
   determined by the addrfamily field in the message header.

   end-time is the time when the sending MAAS plans to stop using the
   addresses.

6.4.3 Address Intent To Use (AITU)

   The Address Intent To Use (AITU) message is used by a MAAS to
   announce addresses that wishes to preallocate.

       Current Time      Range 1     Range 2        ...
   +----+----+----+----+----...----+----...----+----...----+
   |   current-time    |     R1    |     R2    |           |
   +----+----+----+----+----...----+----...----+----...----+









Handley and Hanna                                              [Page 27]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   where each of the Ranges is of the following format:

       First       Last
      Address     Address         End Time
   +----...----+----...----+----+----+----+----+
   |   first   |   last    |      end-time     |
   +----...----+----...----+----+----+----+----+

   current-time is the current time at the sending MAAS.

   first and last are the first and last address in the range of
   addresses being preallocated.  The address family of the addresses is
   determined by the addrfamily field in the message header.

   end-time is the time when the sending MAAS plans to stop using the
   addresses.

6.4.4 Address Space Announce (ASA)

   The Address Space Announce (ASA) message is used by a Prefix
   Coordinator to announce the set of multicast addresses and lifetimes
   available for allocation within the domain using the Address Space
   Announce (ASA) message.

     Current Time   Expiration Time  Range 1   Range 2     ...
   +---+---+---+---+---+---+---+---+---...---+---...---+---...---+
   | current-time  |expiration-time|    R1   |    R2   |         |
   +---+---+---+---+---+---+---+---+---...---+---...---+---...---+

   where each of the Ranges is of the following format:

       First       Last
      Address     Address         End Time
   +----...----+----...----+----+----+----+----+
   |   first   |   last    |      end-time     |
   +----...----+----...----+----+----+----+----+

   current-time is the current time at the sending Prefix Coordinator.

   expiration-time is the time at which MAAS's should start resending
   this ASA message.

   first and last are the first and last address in the range of
   addresses.  The address family of the addresses is determined by the
   addrfamily field in the message header.

   end-time is the time until which the addresses are available for
   allocation.



Handley and Hanna                                              [Page 28]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


6.4.5 Address Space Report (ASRP)

   The Address Space Report (ASRP) message is sent by a MAAS to indicate
   to the Prefix Coordinator(s) how much of the current address space is
   in use and to request more address space.

       Current Time     Report List Request List
   +----+----+----+----+----...----+----...----+
   |   current-time    |  reports  |  requests |
   +----+----+----+----+----...----+----...----+

   where the Report List is a single octet count of reports, followed by
   the reports:

    Report
    Count   Report 1                Report n
   +-----+----...----+----...----+----...----+
   |  n  |  report-1 |           |  report-n |
   +-----+----...----+----...----+----...----+

   and each Report is of the following form:

       First       Last         Number of
      Address     Address    Addresses In Use
   +----...----+----...----+----+----+----+----+
   |   first   |   last    |   in-use-count    |
   +----...----+----...----+----+----+----+----+

   and the Request List is a single octet count of requests, followed by
   the requests:

    Request
    Count   Request 1               Request m
   +-----+----...----+----...----+----...----+
   |  m  | request-1 |           | request-m |
   +-----+----...----+----...----+----...----+

   and each Request is of the following form:

    Number of Addresses      End Time
        Requested            Requested
   +----+----+----+----+----+----+----+----+
   |  addrs-requested  | end-time-requested|
   +----+----+----+----+----+----+----+----+

   current-time is the current time at the sending MAAS.

   n is a single octet count of address space reports, one for each



Handley and Hanna                                              [Page 29]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   address range listed in the most recent ASA message processed.

   first and last are the first and last address in the range of
   addresses.  The address family of the addresses is determined by the
   addrfamily field in the message header.

   in-use-count is an unsigned four-octet number indicating the number
   of addresses in use in the range. If the number of addresses in use
   exceeds 0xfffffffe, then 0xffffffff is sent.

   m is a single octet count of address space requests.

   addrs-requested is an unsigned four-octet number indicating the
   number of addresses requested.

   end-time-requested is the time until which the addresses are desired
   to be available for allocation.

6.4.6 Address Not Available (ANA)

   The Address Not Available (ANA) message is sent by a MAAS to indicate
   that no addresses are available that meet its needs.

       Current Time        Address Count         End Time
   +----+----+----+----+----+----+----+----+----+----+----+----+
   |   current-time    |   address-count   |     end-time      |
   +----+----+----+----+----+----+----+----+----+----+----+----+

   current-time is the current time at the sending MAAS.

   address-count is an unsigned four-octet number indicating the number
   of addresses needed to satisfy the MAAS's needs.

   end-time is the time until which the addresses are needed.

7 Security Considerations

   Most attacks on AAP depend on being able to send a message that will
   be accepted by MAAS's and Prefix Coordinators as valid.

   A malicious party could send a false ASA message indicating that no
   addresses are available. This would cause MAAS's to stop allocating
   addresses (although they could continue to use addresses that they
   had already allocated). A false ASA message could also encourage
   MAAS's to allocate addresses that are already in use in another
   domain or addresses that will not be routed out of the domain.

   Another attack is to send an AIU message indicating a conflict



Handley and Hanna                                              [Page 30]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   whenever a MAAS tries to claim or preallocate an address. This would
   prevent the MAAS from claiming or preallocating any addresses.

   One more attack is to send an ASRP message reporting great demand
   when there is little. This could cause the Prefix Coordinator to
   allocate addresses that are not needed. Alternatively, a false ASRP
   could report little usage and demand when in fact there is a lot of
   usage and demand. This could cause the Prefix Coordinator to allocate
   too few addresses. Both of these attacks would take a while to
   effect, since the Prefix Coordinator typically changes the set of
   addresses available for allocation only slowly in response to long-
   term trends in demand.

   Of course, there is no way in the current multicast routing protocols
   to prevent an unauthorized party from sending data on an arbitrary
   multicast address or joining an arbitrary multicast group. Therefore,
   the multicast address allocation architecture is currently advisory
   in nature. Still, it is desirable to design for the future.

   The best way to address these attacks is by authenticating AAP
   messages and ignoring unauthenticated messages. Therefore, it is
   RECOMMENDED that when security is deemed necessary for AAP, IPsec be
   used to authenticate AAP messages and that unauthenticated messages
   be ignored.

   As currently specified and implemented, IPsec does not include
   support for group key establishment. The Secure Multicast Research
   Group (SMuG) in the IRTF is working on group key establishment and
   management techniques, but these are not yet ready for
   standardization. Therefore, for the time being, manual keying will
   need to be employed to establish and maintain a shared group key.
   However, it is hoped that the work of the SMuG group will allow for
   easier key establishment techniques in the future.

   It should also be mentioned that use of a shared group key does not
   protect against malicious acts by group members. Because all group
   members share a single key, it is not possible to securely determine
   which member sent a given message. In general, this should not be a
   problem for AAP, since all MAAS's and Prefix Coordinators are
   generally considered equal peers. But in some environments, this
   might be useful. Using asymmetric (public key) encryption would make
   it possible to securely determine which member sent a given message,
   but would add greatly to the cost of verifying the authenticity of
   each message. The SMuG group is also working on techniques for
   securely identifying the sender of a multicast message with greater
   efficiency. When these techniques are standardized, it may be useful
   to apply them to AAP.




Handley and Hanna                                              [Page 31]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   Protecting the confidentiality of AAP messages is not usually
   considered an important goal. Although some information about current
   network activities could be derived from monitoring AAP traffic, the
   same information (or more) could be derived from simple traffic
   analysis (who's using which multicast groups).

   Integrity protection for AAP messages is important, but will be taken
   care of by the IPsec authentication described above.

   Replay detection in a multicast situation is difficult.  Because a
   shared group key is employed, a per-sender sequence number is not
   practical. A clock may be used (and all AAP messages include such a
   clock), but synchronized clocks cannot be assumed and even with
   synchronized clocks, some leeway must be allowed for transmission
   delays.

   Fortunately, replay detection is not a requirement for AAP.  Replay
   of AIU, ANA, AITU messages should not be a problem, since they are
   supposed to be persistent anyway.  Replay of ACLM messages will not
   be harmful, since they will be rejected if they interfere with an
   existing allocation. Replay of ASA messages should not be very
   problematic, since any messages that are inconsistent with a Prefix
   Coordinator's own state will be reported by the Prefix Coordinator to
   an operator.  And replay of ASRP messages will simply result in the
   Prefix Coordinator not responding to changes in demand (which is a
   permissible action for the Prefix Coordinator, anyway).

   Once efficient techniques for sender authentication in a group are
   developed, per-sender sequence numbers should be used for replay
   detection.

8 IANA Considerations

   New AAP Message Types may only be defined by IETF Consensus, as
   described in [12]. Basically, this means that they are defined by
   RFCs approved by the IESG.

9 Acknowledgments

   The authors would like to thank the participants of the IETF
   Multicast Address Allocation Working Group (malloc) and the IETF as a
   whole for their assistance with this protocol.

10 References

   [1]  Handley, M., D. Thaler, D. Estrin, "The Internet Multicast
        Address Allocation Architecture", Internet Draft,
        draft-ietf-malloc-arch-02.txt, July 1999.



Handley and Hanna                                              [Page 32]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   [2]  Estrin, D., R. Govindan, M, Handley, S. Kumar, P. Radoslavov,
        D. Thaler, "The Multicast Address Set Claim (MASC) Protocol",
        Internet Draft, draft-ietf-malloc-masc-03.txt, August 1999.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [4]  Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
        August 1989.

   [5]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [6]  Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture",
        RFC 2373, July 1998.

   [7]  Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
        July 1998.

   [8]  Hanna, S., B. Patel, M. Shah, "Multicast Address Dynamic
        Client Allocation Protocol (MADCAP)", Internet Draft,
        draft-ietf-malloc-madcap-07.txt, September 1999.

   [9]  Meyer, D., and P. Lothberg, "GLOP Addressing in 233/8",
        Internet Draft, draft-ietf-mboned-glop-addressing-00.txt,
        October 1999.

   [10] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope
        Zone Announcement Protocol (MZAP)", Internet Draft,
        draft-ietf-mboned-mzap-04.txt, June 1999.

   [11] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
        October 1994.

   [12] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
        Considerations Section in RFCs", RFC 2434, October 1998.

   [13] Mills, D., "Network Time Protocol (Version 3) Specification,
        Implementation and Analysis", RFC 1305, March 1992.

11 Authors' Addresses

      Mark Handley
      AT&T Center for Internet Research at ISCI (ACIRI)
      1947 Center St., Suite 600
      Berkeley, CA 94704
      Email: mjh@aciri.org




Handley and Hanna                                              [Page 33]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


      Stephen R. Hanna
      Sun Microsystems, Inc.
      One Network Drive
      Burlington, MA 01803
      Phone: +1.781.442.0166
      Email: steve.hanna@sun.com

Appendix A: Examples

   This appendix will include several examples of typical AAP protocol
   exchanges. But it hasn't been written yet.

Appendix B: Recommended Constant Values

   Table 3 lists recommended values for constants defined in this
   specification.

           Constant Name             Recommended Value
           -------------             -----------------
           [STARTUP-WAIT]            150 seconds
           [CLAIM-WAIT]              4 seconds
           [RESEND-WAIT]             1 second
           [REPEAT-INTERVAL]         30 seconds
           [ASA-INTERVAL]            30 seconds
           [ASRP-INTERVAL]           30 seconds

      Table 3:  Recommended Constant Values

Appendix C: Change Log

   Note to the RFC Editor: This section should be removed before
   publication.

   Changes since draft-ietf-malloc-aap-01.txt:

   * Complete rewrite. Many details filled in.  * Use IPsec for
   security.  * Added support for IPv6 addresses.  * Added ANA message.

Appendix D: Unresolved Issues

   Note to the RFC Editor: This section should be removed before
   publication.

   This appendix lists unresolved issues. Please send comments to the
   authors.

   Is Prefix Coordinator really the right name for the hosts that
   announces the set of multicast addresses available for use within an



Handley and Hanna                                              [Page 34]


Internet Draft        draft-ietf-malloc-aap-02.txt          October 1999


   allocation domain? We don't require the addresses to be prefixes any
   more. Maybe they should be called Address Coordinators. Or Domain
   Address Coordinators.

   When a MAAS has just done a successful claim, is it really necessary
   to send AIU with an interval starting at [RESEND-INTERVAL]? We
   already did that with the ACLM!

   The old draft talked about MAAS's allocating from only one half of a
   prefix if utilization is low in that prefix. I don't see how that
   will work. There will probably be long-lived allocations all over the
   prefix. And I don't think it is needed. A Prefix Coordinator can just
   extend the lifetime of only part of the existing prefix. Or allocate
   a new, smaller set of addresses with a longer lifetime and let the
   old prefix expire.

   Should we add start times to the ASA message so that Prefix
   Coordinators can announce upcoming addresses? If so, should we let
   MAAS's allocate addresses before their start times? And should we add
   something to ASA that says "I'm working on these address requests,
   but these others are right out." That would give MAAS's a way to give
   feedback to their clients on address requests. I would be inclined to
   leave all of these things for the future, when they can be added (via
   new message types).



























Handley and Hanna                                              [Page 35]