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]
