MALLOC working group Mark Handley, ACIRI Internet Draft draft-ietf-malloc-aap-00.txt June 1999 Expires: December 1999 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 a larger multicast address allocation architecture currently being defined. AAP addresses the specific issue of intra-domain multicast address allocation between multicast address allocation servers. 1. Introduction This document defines a Multicast Address Allocation Protocol (AAP) that forms a part of a larger multicast address allocation architecture [1]. The general framework within which AAP is designed to operate is best described by describing the process by which a multicast address is allocated: o As a continuous process, a higher level protocol, MASC [2] provides a multicast address set, from which addresses should be allocated to an allocation domain. o MASC routers periodically send advertisements of this address set Handley [Page 1] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 to Multicast Address Allocation Servers (MAAS) within the allocation domain using AAP address-set advertisement messages. o When a client requires a multicast address, it sends a request to a MAAS for information about the scope zones that include the server. The MAAS returns this information. o The client then chooses a scope zone, and requests an address for a certain period of time. o The MAAS chooses an address from the address set that is not currently in use, and multicasts an AAP address-claim message to all the other MAASs in the allocation domain. If no-one objects to this announcement, then the MAAS starts to periodically multicast an AAP address-in-use message to all the MAASs in the allocation domain, and it returns the address to the client to use. 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]. 1.2. Definitions 2. Specification of Behavior Within an allocation domain, MAASs are all multicast peers - there is no hierarchy or configured peering. To allocate an address, a MAAS should have been listening to AAP address-set messages and AAP address-in-use messages for a considerable period of time (known at STARTUP-WAIT) so that it has a good idea of currently available addresses. MAASs that have not been listening for at least STARTUP- WAIT SHOULD NOT respond to a client's request for an address. 2.1. AAP Packet Types The following packet types are defined: Address-Set-Announce (ASA) This AAP message is normally sent from a MASC router to all the MAAS servers in an allocation domain. It lists a number of address-sets, each of which has an associated lifetime. The announcement contains a timestamp to detect replays or broken clocks, an expiry time, and the address of the last MASC router to send an Address-Set-Announce (ASA) message to this group. The address-set contained in such a message MUST be the complete Handley [Page 2] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 address-set available to MAASs at that time. An address-set MUST NOT be spilt across multiple ASA messages. ASA messages MAY alternate between several cooperating MASC routers. Each ASA message contains the address of the last router to send such a message to the domain. This information is present to detect cases where two MASC routers are sending messages to the domain without hearing each others messages. This is for fault diagnosis purposes, and may be used to trigger an alarm for a network operator to investigate the failure. It may not be counted upon for any other purpose. ASA messages MUST be digitally signed by the router that sends them. MAASs MAY be configured to ignore ASA messages from unknown routers. The ASA expiry time is the time by which all MAASs within the domain should reasonably have heard a new ASA message. Typically approximately five ASA messages should have arrived during the between the timestamp time and the expiry time. If no ASA message is forthcoming by this expiry time, this MAY be used to raise alarms that some unexpected failure has occurred. Addresses SHOULD still be allocated by such a MAAS, but request protocols that permit it MAY report a lack of confidence in the address. Note that in the absence of ASA messages from MASC routers with an expiry time in the future, cached ASA messages may be resent by MAASs. These cached messages will have an expiry time in the past, but are still valid unless a new ASA message is received from a MASC router. MAASs MUST cache the most recent (as defined by timestamp) ASA message that was signed with an acceptable signature in its entirety including the digital signature. If no new ASA message has been heard after the expiry time given in the ASA message, a MAAS may assume that the MASC routers have all lost state and need refreshing. If this happens, the MAAS sets a timer for a random interval between in the range [ASA-INTERVAL*0.7, ASA-INTERVAL*1.3]. If the timer expires without a newer ASA message arriving, the cached ASA message is sent to the AAP group, and the timer set again. If the MAAS receives the same ASA message from another MAAS it resets its timer to a new random interval in the same range. However, if it receives a new ASA message with a valid signature and a newer timestamp, it caches the new ASA message and clears its timer. This process is required because we cannot rely on MASC routers to have stable storage. Normally a router that reboots can re-obtain its address sets from its peers but in some rare circumstances this may not happen. MAASs are required to have stable storage, and need to store this information anyway, so they Handley [Page 3] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 provide a backup mechanism whereby the router state can be restored to the point where it left off. Server-Signature (SSIG) This AAP message gives the public key of a new server and the expiry time for this key. Such a server can be a new MAAS or a new MASC router. This key MUST be digitally signed by one or more additional servers. It may be multicast from any node in the allocation domain to all the MAASs in the domain, and is used to bootstrap the trust of both MASC routers and MAASs. A typical bootstrap mechanism might be for all MAAS's and MASC routers in a domain to be configured with the public key of one or more primary AAP nodes (either MAAS's or MASC routers). The primary AAP node is trusted by all the other AAP nodes in the domain. By default, other AAP nodes might not be trusted (this is an administrative decision). However, by configuring the primary AAP node with the address and public key of the new AAP node, we can bootstrap the trust of the other legitimate AAP nodes without needing to manually configure all the AAP nodes in the domain with knowledge of each other. To do this the primary AAP node(s) sends digitally signed SSIG packets periodically listing all the AAP nodes in the domain, their public keys, and their key expiry times. Receivers of these SSIG packets can now trust other AAP messages from the listed nodes until the key expiry time. Address-Claim (ACLM) This AAP message is multicast from a MAAS attempting to allocate an address to all other MAASs in the domain. The message contains a list of the addresses being requested, the beginning and end times for the allocation, and a request sequence number. The MAAS sending this message has already listened to other announcements, and is reasonably certain that the addresses listed are not in use. It sends this message to check that it has not missed a recent announcement by another MAAS. It expects that no reply will be forthcoming, but waits ANNOUNCE-WAIT seconds to ensure this is the case. Two possible messages might be received that would indicate a problem with the announcement. o ASA might be sent by a MASC router to indicate that the address allocation was not valid for the address-set currently available. This is extremely unlikely to occur with a compliant MAAS, and MASC routers are not required to listen to AAP ACLM messages. o Address-In-Use (AIU) might be sent be another MAAS to indicate Handley [Page 4] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 that the address was already in use. This can be sent if the same address is already allocated for the same time interval. In either case, the MAAS SHOULD change its allocation and send another ACLM message with the same request sequence number. The only exception to this is if the MAAS suspects a denial of service attack is in progress (see section 5.1). This message MAY be digitally signed by the MAAS sending it. Address-Intent-To-Use (AITU) This AAP message is similar to an ACLM message except it lacks the start and end times for each address. It indicates that the MAAS sending it intends to choose the indicated address(es) next. It allows an address to be pre-claimed but in a manner that is non- exclusive - it may be overridden by an Address-In-Use message or an ACLM message. A MAAS MUST NOT send AITU for an address for which someone else is already sending AITU. A server hearing AITU from another server MAY send ACLM to claim that address and MUST send AIU to defend that address if it had already allocated it. It SHOULD also send AIU after an appropriate time delay if no-one else does and if the AITU messages was already allocated by someone else. The rules for this are identical to those for triggered AIU messages caused by ACLM. The reason for AITU is to allow MAASs to sometimes allocate an address with no delay, whereas using ACLM requires waiting for at least ANNOUNCE-WAIT seconds. The model is as follows: o A MAAS sends AITU for an address. It MUST have sent it at least twice, with the second copy sent at least ANNOUNCE-WAIT seconds ago and not more than 1.3*BASE-REPEAT-INTERVAL ago. During that time it MUST NOT have heard an ACLM or AIU message for that address. Under such circumstances the address may be handed immediately to a new client and an AIU message immediately sent. o If a MAAS is sending AITU for an address and it hears AITU, AIU or ACLM from another server for the same address, it must stop sending AITU and cannot now hand the address to a client. The address becomes just like any other address that the MAAS has just heard an AIU or ACLM message (as appropriate) for. o It is also possible that an ASA message will arrive indicating that the address being claimed is not valid. If this occurs, the MAAS should cease sending AITU for this address. This is unlikely to occur in a correctly configured network, but may occur if the physical topology of the network is reconfigured. Handley [Page 5] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 The reason for having two message types, AITU and ACLM, is to prevent unnecessary address space exhaustion. If the space is near to exhaustion, sending ACLM to reserve an address for which the server does not yet have an immediate use would exhaust the space unnecessarily. Sending AITU allows some of the servers (those sending AITU) to perform immediate allocation, whereas the others would need to perform ACLM to get the same addresses. This message MAY be digitally signed by the MAAS sending it. Address-In-Use (AIU) This AAP message is multicast periodically from a MAAS to all other MAASs in the domain to indicate that addresses are in use. The message contains a list of addresses, each with an associated start and stop time. This message may also be sent by any MAAS that notices a ACLM message that would cause a clash. See section XXX for details of the timing of such response messages. This message MAY be digitally signed by the MAAS sending it. The reason for having an AIU message distinct from ACLM is to prevent failed claims being cached by other servers. MAASs MUST cache addresses from AIU messages sent by other servers as in-use until the end of the address lifetime or until the MAAS is restarted. However, addresses from ACLM messages only need caching as in-use until they hear a subsequent ACLM for a different address with the same sequence number, an AIU message for the same address (in which case the cache is extended for the address lifetime), or time out the address after BASE-REPEAT-INTERVAL seconds. Address-Space-Report (ASRP) The AAP message is periodically multicast from a MAAS to all the MASC routers for the domain indicating the current address space usage. It contains a set of address ranges, the numbers of addresses being used from each range, and the last expiry dates for each of those numbers of addresses. This reflects the address sets being provided by MASC. Typically an ASRP message will contain one number of addresses being used for each address set provided by MASC with the expiry date being that of the last address to expire in the address set. However, if the MAAS node sending ASRP determines it necessary, it may split each MASC range into multiple smaller ranges and report those separately. Thus if usage of a prefix has declined and the MAASs have only been allocating from the lower half of a prefix (for example), then reporting the two halves of the prefix separately would ensure that MASC only renews the half of the prefix in use. If ASRP reported the whole range, Handley [Page 6] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 then MASC might still only renew half the prefix, but would not be able to intelligently choose which half to renew. These messages SHOULD be digitally signed. If any MAAS in the domain is trusted by the MASC routers, that server should send the ASRP messages. If not, any MAAS may take over this role. This is achieved by using shorter randomised timeouts for the trusted servers as explained in section XXX. How the MAAS calculates the address space required is explained in section XXX. 3. Specification of MAAS Behaviour When a MAAS starts up, it MUST listen to AAP messages for at least START-WAIT time before it can respond to an address allocation request, and SHOULD have received at least one ASA message. If it does not receive an ASA message within this time, it MAY respond to an allocation request only if it has cached a previous ASA message which includes at least one range that has not reached its end time. There are two ways to claim an address - on demand, or in advance. The in-advance mechanism is an optimization of the on-demand mechanism, and falls back to the on-demand mechanism when there is a conflict. In the on-demand mechanism, when a MAAS receives a request for the allocation of an address, that request will contain a start and end- time. The MAAS SHOULD choose the address-set from those that were advertised to it that satisfies the greatest proportion of the time in the request. Alternatively if more than one address-set satisfies all the time in the request, the address set with the shortest remaining lifetime should be chosen. From that address-set it SHOULD then choose at random an address that is not already being advertised by any MAAS . It should then send this address in an ACLM message with the start-time from the request and the minimum of the address- set end-time and the request end-time. It SHOULD then set a timer for ANNOUNCE-WAIT seconds in the future. If the MAAS receives an ACLM message or an AIU message from another MAAS listing the same address before the timer expires, then it should cancel the timer, choose another address in the same manner, send another ACLM message with the same sequence number listing the new address, and set a new timer for ANNOUNCE-WAIT seconds in the future. Such a MAAS MAY also resend the ACLM after RESEND-WAIT seconds, and again after a further RESEND-WAIT*2 seconds, doubling each time until the timer expires. If the timer expires, the MAAS can conclude that there is a good probability that the address is unique, and it can then send an AIU Handley [Page 7] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 message listing this address, add the address to its list of allocated addresses, and return the address along with the (possibly modified) end-time to the client. 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 every BASE-REPEAT-INTERVAL seconds +/- 30% of this value to avoid synchronisation effects. A MAAS that has just allocated an address SHOULD resend that address again after RESEND- WAIT seconds, and again after a further RESEND-WAIT*2 seconds, doubling each time until the interval reaches BASE-REPEAT-INTERVAL seconds. In some circumstances a MAAS may receive large numbers of requests for addresses, each for very short period of time. Sending triggered announcements for each of these requests increases the delay before granting addresses and may create a significant amount of AAP traffic. If it desires, such a server MAY pro-actively allocate a pool of addresses using the process described above, and may then may grant these requests immediately out of this pool. As the server MUST have already sent AIU messages for these pooled addresses, there should be no clash. Such servers should maintain the minimum pool to allow them to perform their task well. Applications requiring multicast addresses MUST NOT assume that a MAAS will always grant them addresses with no delay, and SHOULD assume that the server will take at least ANNOUNCE-WAIT seconds to allocate them an address. Depending on the request protocol being used by the client, a server MAY communicate ANNOUNCE-WAIT to clients when they request a list of current scope zones before requesting a multicast address, or it MAY send an interim reply to the client indicating how long it expects allocation to take. An alternative mechanism to the on-demand ACLM mechanism is to express an intent to use an address using AITU messages. These are more useful for servers that allocate few addresses but wish to do so with minimal delay. To do this a MAAS chooses an unused address and sends an AITU message announcing its intention that this is the next address it will use. The message does not reserve the address, but does prevent anyone else sending an AITU message for the same address. After sending its first AITU message for an address, a period of ANNOUNCE-WAIT must elapse before the address is usable. Any ACLM, AITU or AIU messages received that list this same address cause the MAAS to cancel its timer and choose a new address. The AITU message should be resent with the same time intervals as an AIU message - i.e. the interval between messages doubles each time until it reaches BASE-REPEAT-INTERVAL. After the initial ANNOUNCE-WAIT interval has expired, if no other server has sent AITU, ACML or AIU for the address, it becomes eligible for allocation to a client. A Handley [Page 8] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 request for an address can be satisfied immediately with this address, and the server then sends an AIU message for the address, resending the AIU again after RESEND-WAIT seconds, and again after a further RESEND-WAIT*2 seconds, doubling each time until the interval reaches BASE-REPEAT-INTERVAL seconds. If a MAAS has heard AITU messages for all the available addresses in a domain it cannot choose an address and send AITU. However, if it receives a request for an address from a client, it should choose one of the unallocated addresses at random ignoring the fact that someone else was sending AITU, and send an ACLM claim message in the normal way. If some of the unallocated addresses in a domain are reported in AITU messages and some are not, a MAAS that wishes to claim an address using ACLM SHOULD choose at random one of the addresses not reported in AITU messages. 3.1. Triggered Responses When a MAAS A receives an ACLM or an AITU message from MAAS B containing an address that clashes with an address in use in its cache, it should set a timer based on the algorithm below. If server A sees an AIU message from a server other than B containing this address before the timer expires, it should restart the timer with double its original value. If server A sees an ACLM or an AITU from server B with the same sequence number as before, it should cancel its timer. If server A's timer expires, it should send an AIU message containing the address in question, and should restart the timer with twice its previous value, unless that value was 0, in which case it sets it to INITIAL-TIMER. If the timer interval becomes greater than BASE- 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 and we revert to the normal announcement mechanism. The initial value for the timer is determined as follows: o If server A is the server that was originating the announcement for the address in question, the initial value of the timer is 0. o If server A is not the server that was originating the announcement for this address, the server calculates the timer, t, as follows: X is chosen from the uniform random interval [0:1] (D2/R) Handley [Page 9] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 t=D1+R*log2(2 *X+1) D1 defaults to R. D2 defaults to DEFAULT-D2 seconds. R is an estimate of maximum round trip time for the domain, and defaults to DEFAULT-RTT. This value MAY be reduced to reduce delays for some domains. If the value is increased, it MUST be increased in all MAASs in the domain. This equation results is an exponential random distribution between D1 and D2 seconds. The default value of D2 is useful for up to several thousand MAASs in a domain to ensure that close to one server responds. If a MAAS has sent an ACLM message and has an ANNOUNCE-WAIT timer running, and it receives another ACLM message for the same address from another MAAS, it SHOULD immediately choose another multicast address and send a new ACLM message with the same sequence number. It MUST NOT send an AIU message in this state in response to an ACLM message. It does not matter which server chooses a new address in these circumstances, so it is not necessary to inform the other site. 3.2. Scope of AAP Messages AAP messages are sent to a well known multicast address (239.??.??.??) and port (????). This multicast address MUST be administratively scoped so as not to leave the allocation domain. The TTL on packets SHOULD be set to 255. Note: AAP is not intended to perform multicast address allocation for TTL-scoped sessions. Non-global sessions SHOULD be constrained using administrative scoping only. 3.3 AAP Timers Most AAP timers are defined in terms of DEFAULT-RTT. This is intended to be an approximation of the largest propagation delay across the domain and back. The default value for DEFAULT-RTT is intended to be reasonable for most allocation domains, but if the domain is very small with little queuing delay, or very large, then this value can be changed. Clearly increasing DEFAULT-RTT decreases performance and increases the wait for addresses. If the real RTT across the domain is significantly greater than the configured default value of DEFAULT-RTT, unnecessary additional traffic may be generated. If the real RTT across the domain is significantly less that the configured default value of DEFAULT-RTT, AAP will perform as intended, but could be tuned to reduce the allocation delay. Handley [Page 10] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 The following AAP timers are defined: START-WAIT START-WAIT = Max(5 * SET-REPEAT-INTERVAL, 5 * BASE-REPEAT-INTERVAL) seconds. SET-REPEAT-INTERVAL SET-REPEAT-INTERVAL defaults to 30 seconds. ANNOUNCE-WAIT ANNOUNCE-WAIT defaults to 40 * DEFAULT-RTT. RESEND-WAIT RESEND-WAIT defaults to 10 * DEFAULT-RTT. INITIAL-TIMER INITIAL-TIMER defaults to 2 * DEFAULT-RTT. DEFAULT-RTT DEFAULT-RTT defaults to 100ms. DEFAULT-D2 DEFAULT-D2 defaults to 30 * DEFAULT-RTT. ASA-INTERVAL ASA-INTERVAL defaults to 30 seconds. BASE-REPEAT-INTERVAL BASE-REPEAT-INTERVAL = Max(30, SIZE*NO-OF-ADDRESSES/BASE-RATE) seconds. where: NO-OF-ADDRESSES is the number of addresses currently allocated within the domain. SIZE is the size in bytes of a single (address,start-time,stop- time) triple from an AIU message. Handley [Page 11] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 BASE-RATE BASE-RATE is the approximate background rate for announcement traffic within a domain with a significant number of addresses allocated. For IPv4, the rate only reaches this level with around 3000 addresses allocated within a domain. It defaults to 1250 bytes/second. 4. Packet Formats AAP messages are binary format, as the additional flexibility of having a textual format is not required in this case. All AAP packets start with the following common header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=0 |STYPE|P| SLEN | PTYPE | ATYPE | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSEQ | MSEQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 4 bits This field identifies the version of AAP. The version defined by this specification is 0. Signature Type (STYPE): 4 bits This field identifies the type of digital signature used to sign the message. The values are defined as follows: 0. No signature present. SLEN MUST also be zero. 1. PGP signature used. The format is described in TBD. Signature Length (SLEN): 8 bits This field indicates the length of the digital signature in the packet as a multiple of 32 bit words. If the signature is not a multiple of 32 bits long, the last byte of the signature indicates the number of padding bytes that have been added to the end of the signature. These padding bytes are then included in the signature length, and the signature padding bit (P) is set. Packet Type (PTYPE): 4 bits Handley [Page 12] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 This field indicates the type of AAP packet this is. It is one of the following values: 0. Address-Set-Announce (ASA) 1. Server-Signature (SSIG) 2. Address-Claim (ACLM) 3. Address-Intent-to-Use (AITU) 4. Address-In-Use (AIU) 5. Address-Space-Report (ASRP) Address Type (ATYPE): 4 bits This field indicates the address type used in the packet. Multiple address types (for example IPv4 and IPv6) can be used within the same domain at the same time. However, only a single address type may be used within one AAP packet. The following values are defined: 0. IP version 4. 1. IP version 6. Request Sequence (RSEQ): 24 bits This field is a sequence number. The first packet an AAP node (MAAS or MASC router) sends should have sequence number 0, and the sequence number should be incremented for every subsequent distinct message or request. Retransmissions of claims are made with the same RSEQ as the original but increasing MSEQ. 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 alternate sender between multiple MASC routers. 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 Handley [Page 13] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 use. Message Sequence (MSEQ): 8 bits This field is a packet sequence number that is used to identify different messages of the same request. For example, if a server sends a new ACLM message with RSEQ=27, MSEQ=0, and receives an AIU message from another server for that 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 ANNOUNCE-WAIT seconds, the server 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. Immediately following the common header is a digital signature of the payload of the packet. This can be of variable length. Following the digital signature are the packet contents, the format of which depend on both the ATYPE and PTYPE fields. 4.1. AAP Time Fields AAP packets contain a number of places where absolute times must be represented. Unless otherwise stated, 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 timestamp by adding decimal 2208988800. Thus AAP time fields will not wrap until the year 2106. 4.2. IPv4 Packet Formats (ATYPE=0) 4.2.1 Address-Set-Announce (ASA) An address set announce packet for IPv4 contains an address set refresh time, followed by one or more address sets: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Handley [Page 14] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiry time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicast Address | |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| The current time is an AAP time field (see section 4.1) and gives the current time at the router sending this message. The address set refresh time is an AAP time field giving the time by which another ASA message should have been received. Within each address set, the multicast address indicates an IPv4 base address. The mask indicates which bits from the base address are wildcarded, i.e, can be set be the address allocator. For example, if the base address is: 0xE0020000 (224.2.0.0) and the mask is 0x000100FF then addresses 224.2.0.0-224.2.0.255 and 224.3.0.0- 224.3.0.255 are available. Note that the mask does not have to be contiguous. All MAASs MUST be able to cope with discontiguous masks, although in some cases only contiguous masks may be supplied by MASC. The address set expiry time is an AAP time field giving the time at which the address set will expire. Addresses should only be granted from this address set up until this time. The address set expiry time is an AAP time field giving the time at which the address set will expire. Addresses should only be granted from this address set up until this time. 4.2.2. SERVER-SIGNATURE TBD 4.2.3. Address-Claim (ACLM) An ACLM packet for IPv4 contains the current time at the MAAS and one or more addresses: Handley [Page 15] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicast Address | |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| The multicast address lists the specific address being requested. Start-time and end-time are AAP time fields giving the range of time for which the address is required. Multicast addresses within the packet MUST be in increasing numerical order. 4.2.4. Address-Intent-to-Use (AITU) An AITU packet for IPv4 contains the current time at the MAAS and one or more addresses: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicast Address | |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| The multicast address lists the specific address being requested. Multicast addresses within the packet MUST be in increasing numerical order. 4.2.5. Address-In-Use (AIU) An AIU packet for IPv4 contains the current time at the MAAS, a refresh timeout, and one or more addresses as for ACLM. Handley [Page 16] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicast Address | |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| The current-time is an AAP time field used to discover MAASs that have incorrectly set clocks, or to identify the age of proxy announcements when a MAAS has died. Multicast addresses within the packet MUST be in increasing numerical order. Where a MAAS has more addresses than will fit in one packet, they may be split over several packets. There SHOULD be no overlap in numerical ranges of addresses between these packets. An exception to this is if a MAAS is announcing its own addresses and those of another server, when it SHOULD announce its own addresses in different packets from those it is proxy announcing. Ordering the addresses in this way increases the efficiency of processing packets received at a MAAS. The refresh-time is an AAP time field used to indicate that another message from the same server should have been received by this time. This time SHOULD be far enough in the future that at least five messages from this server would have been expected to have been heard. If no messages are heard in this interval, other MAASs MAY conclude that this MAAS has died or been partitioned. In such circumstances they MAY make a proxy announcement (see section XXX). 4.2.6. Address-Space-Report (ASRP) An ASRQ packet for IPv4 contains one or more pairs of number of addresses and lifetimes: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Handley [Page 17] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 | number of addresses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | end-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Generally speaking, if the MAAS is happy with its current address set, it should simply report the address set back to the MASC servers with this message. However, if the address space is insufficient, the MAAS should either add one or more additional pairs of number of addresses and lifetime, or increase the number of addresses from one of the existing pairs. If the address set is larger than required, this is not usually dealt with until addresses need to be allocated from a set with a longer lifetime than those in the existing set. At this time, the MAAS will replace one or more of the pairs from the existing set with a smaller but longer duration pair. 4.3. IPv6 Packet Formats (ATYPE=1) TBD 5. Security 5.1. Denial of Service Attacks TBD 6. References [1] Handley, M., D. Thaler, D. Estrin, "The Internet Multicast Address Allocation Architecture", Internet Draft, draft-ietf-malloc-arch-01.txt, April 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-01.txt, August 1998. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 7. Author's Address Mark Handley AT&T Center for Internet Research at ISCI (ACIRI) 1947 Center St., Suite 600 Berkeley, CA 94704-119 Handley [Page 18] Internet Draft draft-ietf-malloc-aap-01.txt December 1999 USA Email: mjh@aciri.org Handley [Page 19]