RFC relevance of identifier

As per Relevance of the word identifier, we have this rfc below:

Network Working Group S.
Requests for Comments: 2730 Sun Microsystems, Inc
Category: Standards Track B.
Intel Corp
M.
Microsoft Corp
December 1999

Multicast Address Dynamic Client Allocation Protocol (MADCAP

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

This document defines a protocol, Multicast Address Dynamic
Allocation Protocol (MADCAP), that allows hosts to request
addresses from multicast address allocation servers

1.

Multicast Address Dynamic Client Allocation Protocol (MADCAP) is
protocol that allows hosts to request multicast address
services from multicast address allocation servers. This protocol
part of the Multicast Address Allocation Architecture being
by the IETF Multicast Address Allocation Working Group. However,
may be used separately from the rest of that architecture
appropriate

1.1.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [9].

Constants used by this protocol are shown as [NAME-OF-CONSTANT],
summarized in Appendix B

Hanna, et al. Standards Track [Page 1]

RFC 2730 MADCAP December 1999

1.2.

This specification uses a number of terms that may not be familiar
the reader. This section defines some of these and refers to
documents for definitions of others

MADCAP client or
A host requesting multicast address allocation services via MADCAP

MADCAP server or
A host providing multicast address allocation services via MADCAP

IP Multicast, as defined in [11] and modified in [12].

Multicast
An IP multicast address or group address, as defined in [11]
[13]. An identifier for a group of nodes

Multicast
A range of multicast addresses configured so that traffic sent
these addresses is limited to some subset of the internetwork.
[3] and [13].

Scope
The lowest numbered address in a multicast scope. This
applies only within this document

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

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

Zone
A human readable name for a Scope Zone. An ISO 10646
string with an RFC 1766 [6] language tag. One zone may have
zone names, each in a different language. For instance, a zone
use within IBM's locations in Switzerland might have the names "
Suisse", "IBM Switzerland", "IBM Schweiz", and "IBM Svizzera"
language tags "fr", "en", "de", and "it".

Hanna, et al. Standards Track [Page 2]

RFC 2730 MADCAP December 1999

Multicast Scope
A list of multicast scope zones

Since it can be difficult to determine which multicast scope
are in effect, MADCAP clients can ask MADCAP servers to supply
Multicast Scope List listing all of the zones available to
client. For each scope zone, the list includes the range
multicast addresses for this scope, a maximum TTL or hop count
be used for this scope, and one or more zone names for this
zone

This definition applies only within this document

1.3. Motivation and Protocol

For multicast applications to be deployed everywhere, there is a
to define a protocol that any host may use to allocate
addresses. Here are the requirements for such a protocol

Quick response: The host should be able to allocate a
address and begin to use it promptly

Low network load: Hosts that are not allocating or
multicast addresses at the present time should not need to send
receive any network traffic

Support for intermittently connected or power managed systems:
should be able to be disconnected from the network, powered off,
otherwise inaccessible except during the brief period during
they are allocating a multicast address

Multicast address scopes: The protocol must be able to allocate
the administratively scoped and globally scoped multicast addresses

Efficient use of address space: The multicast address space is
small. The protocol should make efficient use of this
resource

Authentication: Because multicast addresses are scarce, it
important to protect against hoarding of these addresses. One way
do this is by authenticating clients. This is also a key
for establishing policies

Hanna, et al. Standards Track [Page 3]

RFC 2730 MADCAP December 1999

Policy neutral: Allocation policies (such as who can
addresses) should not be dictated by the protocol

Conferencing support: When allocating an address for use in
conferencing environment, members of the conference should be able
modify a multicast address lease used for the conference

1.4. Relationship with

MADCAP was originally based on DHCP. There are still
similarities and it may be possible to share some code between a
implementation and a MADCAP implementation. However, MADCAP
completely separate from DHCP, with no dependencies between the
and many significant differences

1.5. Protocol

MADCAP is built on a client-server model, where hosts request
allocation services from address allocation servers. When a
client wishes to request a service, it unicasts or multicasts
message to one or more MADCAP servers, each of which
responds with a message unicast to the client

All messages are UDP datagrams. The UDP data contains a fixed
header and a variable length options field. Options are encoded in
type-length-value format with two octets type and value fields.
fixed fields are version, msgtype (message type), addrfamily (
family), and xid (transaction identifier).

Retransmission is handled by the client. If a client sends a
and does not receive a response, it may retransmit its request a
times using an exponential backoff. To avoid executing the
client request twice when a retransmitted request is received
servers cache responses for a short period of time and resend
responses upon receiving retransmitted requests

Each request contains a msgtype, an xid, and a Lease
option. Clients must ensure that this triple is probably
across all MADCAP messages received by a MADCAP server over a
of [XID-REUSE-INTERVAL] (10 minutes). This allows the MADCAP
to use this triple as the key in its response cache

Messages sent by servers include the xid included in the
request so that clients can match up responses with requests

The msgtype field is a single octet that defines the "type" of
MADCAP message. Currently defined message types are listed in
2. They are: DISCOVER, OFFER, REQUEST, RENEW, ACK, NAK, RELEASE,

Hanna, et al. Standards Track [Page 4]

RFC 2730 MADCAP December 1999

GETINFO. DISCOVER, REQUEST, RENEW, RELEASE, and GETINFO messages
only sent by a client. OFFER, ACK, and NAK messages are only sent
a server

The REQUEST, RENEW, and RELEASE messages are used to request, renew
or release a lease on one or more multicast addresses. A
unicasts one of these messages to a server and the server
with an ACK or a NAK

The GETINFO message is used to request information, such as
multicast scope list, or to find MADCAP servers. A client may
an GETINFO message to a MADCAP server. However, it may not know
IP address of any MADCAP server. In that case, it will multicast
GETINFO message to a MADCAP Server Multicast Address and all
that wish to respond will send a unicast ACK or NAK back to
client

Each multicast scope has an associated MADCAP Server
Address. This address has been reserved by the IANA as the
with a relative offset of -1 from the last address of a
scope. MADCAP clients use this address to find MADCAP servers

The DISCOVER message is a message used to discover MADCAP
that can probably satisfy a REQUEST. DISCOVER messages are
multicast. Servers that can probably satisfy a REQUEST
to the parameters supplied in the DISCOVER message
reserve the addresses needed and send a unicast OFFER back to
client. The client selects a server with which to continue and
a multicast REQUEST including the server's Server Identifier to
same multicast address used for the DISCOVER. The chosen
responds with an ACK or NAK and the other servers stop reserving
addresses they were temporarily holding

For detailed descriptions of typical protocol exchanges,
Appendix A

MADCAP is a mechanism rather than a policy. MADCAP allows
system administrators to exercise control over
parameters where desired. For example, MADCAP servers may
configured to limit the number of multicast addresses allocated to
single client. Properly enforcing such a limit requires
security, as described in the Security Consideration section

MADCAP requests from a single host may be sent on behalf of
applications with different needs and requirements. MADCAP
MUST NOT assume that because one request from a MADCAP
supports a particular optional feature (like Retry After),
requests from that client will also support that optional feature

Hanna, et al. Standards Track [Page 5]

RFC 2730 MADCAP December 1999

2. Protocol

The MADCAP protocol is a client-server protocol. In general,
client unicasts or multicasts a message to one or more servers,
optionally respond with messages unicast to the client

A reserved port number dedicated for MADCAP is used on the
(port number 2535, as assigned by IANA). Any port number may be
on client machines. When a MADCAP server sends a message to a
client, it MUST use a destination port number that matches the
port number provided by the client in the message that caused
server to send its message

The next few sections describe the MADCAP message format and
types. A full list of MADCAP options is provided in section 3.

2.1. Message

Figure 1 gives the format of a MADCAP message and Table 1
each of the fields in the MADCAP message. The numbers in
indicate the size of each field in octets. The names for the
given in the figure will be used throughout this document to refer
the fields in MADCAP messages

All multi-octet quantities are in network byte-order

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

Hanna, et al. Standards Track [Page 6]

RFC 2730 MADCAP December 1999

+-+-+-+-+-+-+-+-+
| version (1) |
+---------------+
| msgtype (1) |
+---------------+
| addrfamily |
| (2) |
+---------------+
| |
| xid (4) |
| |
| |
+---------------+
| |
| options |
| (variable) |
| ... |
+---------------+

Figure 1: Format of a MADCAP

FIELD OCTETS
----- ------ -----------

version 1 Protocol version number (zero for this specification
msgtype 1 Message type (DISCOVER, GETINFO, etc.)
addrfamily 2 Address family (IPv4, IPv6, etc.)
xid 4 Transaction
options var Options

Table 1: Description of fields in a MADCAP

2.1.1. The version

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

2.1.2. The msgtype

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

For more information about this field, see section 2.2.

Hanna, et al. Standards Track [Page 7]

RFC 2730 MADCAP December 1999

2.1.3. The addrfamily

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

2.1.4. The xid

The xid field is a transaction identifier. This number MUST be
by the client so that the combination of xid, msgtype, and
Identifier is unique across all MADCAP messages received by a
server over a period of [XID-REUSE-INTERVAL] (10 minutes).

The xid field is used by the client and server to associate
and responses between a client and a server. Before a client sends
message, it chooses a number to use as an xid. The technique used
choose an xid is implementation-dependent, but whatever technique
used MUST make it unlikely that the same combination of xid, msgtype
and Lease Identifier will be used for two different messages
[XID-REUSE-INTERVAL] (even across multiple clients which do
communicate among themselves). This allows enough time for
message to be dropped from all server response caches (as
in the next few paragraphs) and for any network delays to
accomodated

The RECOMMENDED technique for choosing an xid is to choose a
four octet number as the first xid in a session and increment
value each time a new xid is needed. The random number chosen
not be cryptographically random. The random number may be chosen
any suitable technique, such as the one described in section A.6
RFC 1889 [14].

When a server responds to a client message, it MUST use the same
value in the response that the client used in the request.
allows the client to associate responses with the message that
are responding to

When retransmitting messages (as described in section 2.3),
client MUST retransmit them without changing them, thereby using
same xid and and Lease Identifier

If a server receives a message with the same xid, msgtype, and
Identifier as one received within [RESPONSE-CACHE-INTERVAL], it
treat this message as a retransmission of the previously received
and retransmit the response, if any. After [RESPONSE-CACHE-INTERVAL],
the server may forget about the previously received message and

Hanna, et al. Standards Track [Page 8]

RFC 2730 MADCAP December 1999

any retransmissions of this message as if they were new messages.
course, a server need not cache a message if it ends up ignoring
message. However, performance gains may be achieved by doing so

This avoids retransmissions causing multiple allocations,
requests are not idempotent. An appropriate value for [RESPONSE
CACHE-INTERVAL] would be sixty seconds, but it may have any
from zero seconds to 300 seconds (five minutes) and may be
dynamically according to resource constraints on the server
However, using a value less than sixty seconds is NOT
because this is the normal client retransmission period

2.1.5. The options

The options field consists of a list of tagged parameters that
called "options". All options consist of a two octet option code
a two octet option length, followed by the number of octets
by the option length. In the case of some options, the length
is a constant but must still be specified

The option field MUST contain a sequence of options with the last
being the End option (option code 0). Any message whose options
does not conform to this syntax MUST be ignored

Any MADCAP client or server sending a MADCAP message MAY include
of the options listed in section 3, subject to the restrictions
Table 5 and elsewhere in this document. They MAY also include
MADCAP options that are defined in the future. A MADCAP client
server MUST NOT include more than one option with the same
type in one MADCAP message

All MADCAP clients and servers MUST recognize all options listed
this document and behave in accordance with this document
receiving and processing any of these options. Any
options MUST be ignored and the rest of the message processed as
the unknown options were not present. If a MADCAP server receives
message that does not conform to the requirements of this
(for instance, not including all required options), an
Request error MUST be generated and processed in the manner
in section 2.6. If a MADCAP client receives a message that does
conform to the requirements of this document, it MUST ignore
message

The order of options within a message has no significance and
order MUST be supported in an equivalent manner, with the
that the End option must occur once per message, as the last
in the option field

Hanna, et al. Standards Track [Page 9]

RFC 2730 MADCAP December 1999

New MADCAP option codes may only be defined by IETF Consensus,
described in section 5.

2.2. Message

The msgtype field defines the "type" of a MADCAP message.
values for this field are

Value Message
----- ------------
1
2
3
4
5
6
7
8

Table 2: MADCAP message

Throughout this document, MADCAP messages will be referred to by
type of the message; e.g., a MADCAP message with a message type of 8
will be referred to as an GETINFO message

Here are descriptions of the MADCAP message types. Table 5,
appears at the beginning of section 3, summarizes which options
allowed with each message type

MADCAP clients and servers MUST handle all MADCAP message
defined in this document in a manner consistent with this document

If a MADCAP server receives a message whose message type it does
recognize, an Invalid Request error MUST be generated and
in the manner described in section 2.6. If a MADCAP client receives
message whose message type it does not recognize, it MUST ignore
message

Note, however, that under some circumstances this document
or suggests that clients or servers ignore messages with
message types even though they may be recognized. For instance
clients that do not send DISCOVER messages SHOULD ignore
messages. Also, secure servers SHOULD ignore DISCOVER messages
all servers SHOULD ignore DISCOVER messages that they cannot satisfy

New MADCAP message types may only be defined by IETF Consensus,
described in section 5.

Hanna, et al. Standards Track [Page 10]

RFC 2730 MADCAP December 1999

2.2.1.

The GETINFO message is used by a MADCAP client that wants to
configuration parameters, especially a multicast scope list.
message also allows a client to determine which servers are likely
be able to handle future requests

The MADCAP client sends out an GETINFO message. The message may
unicast to a particular MADCAP server or multicast to a MADCAP
Multicast Address. For more details about the MADCAP Server
Address, see section 2.10.

If a server receives an GETINFO message and it can process
request successfully, it MUST unicast an ACK message to the client
All GETINFO messages MUST include an Option Request List option.
server SHOULD try to include the specified options in its response
but is not required to do so (especially if it does not
them).

If a server receives an GETINFO message and it does not process
request successfully, it MUST generate and process an error in
manner described in section 2.6.

If a client sends an GETINFO message and does not receive any
messages in response, it SHOULD resend its GETINFO message,
described in section 2.3.

When a MADCAP client sends an GETINFO message, it MAY include
Requested Language option, which specifies which language the
would prefer for the zone names in the Multicast Scope List.
proper way to handle this tag with respect to zone names is
in the definition of the Multicast Scope List option

2.2.2.

The DISCOVER message is a multicast message sent by a MADCAP
that wants to discover MADCAP servers that can probably satisfy
REQUEST

MADCAP clients are not required to use the DISCOVER message.
MAY employ other methods to find MADCAP servers, such as sending
multicast GETINFO message, caching an IP address that worked in
past or being configured with an IP address. Using the
message has the particular advantage that it allows clients
receive responses from all servers that can satisfy the request

Hanna, et al. Standards Track [Page 11]

RFC 2730 MADCAP December 1999

The MADCAP client begins by sending a multicast DISCOVER message to
MADCAP Server Multicast Address. Any servers that wish to assist
client respond by sending a unicast OFFER message to the client. If
server can only process the request with a shorter lease time
later start time than the client requested, it SHOULD send an
message with the lease time or start time that it can offer
However, it MUST NOT offer a lease time shorter than the
lease time specified by the client or a start time later than
maximum start time specified by the client

For more details about the MADCAP Server Multicast Address,
section 2.10.

If a client sends a DISCOVER message and does not receive any
messages in response, the client SHOULD retransmit its
message, as described in section 2.3.

If a client sends a DISCOVER message and receives one or more
messages in response, it SHOULD select the server it wants to use (
any) and send a multicast REQUEST message identifying that
within [DISCOVER-DELAY] after receiving the first OFFER message.
section 2.2.4 for more information about the REQUEST message

The mechanism used by the client in selecting the server it wants
use is implementation dependent. The client MAY choose the
acceptable response or it MAY wait some period of time (no more
[DISCOVER-DELAY]) and choose the best response received in
period of time (if the first response has a smaller lease time
requested, for instance).

The value of [DISCOVER-DELAY] is also implementation dependent,
the RECOMMENDED value is the current retransmit timer, as
in section 2.3. Waiting too long (approaching [OFFER-HOLD]) may
servers to drop the addresses they have reserved

When a MADCAP client sends a DISCOVER message, it MAY include
Lease Time, Minimum Lease Time, Start Time, Maximum Start Time
Number of Addresses Requested, and List of Address Ranges options
describing the addresses it wants to receive. However, it need
include any of these options. If one of these options is
included, the server will provide the appropriate default (
available for Lease Time, no minimum for Minimum Lease Time, as
as possible for Start Time, no maximum for Maximum Start Time,
for Number of Addresses Requested, and any addresses available
List of Address Ranges). The Multicast Scope option MUST be
in the DISCOVER message so that the server knows what scope should
used. The Current Time option MUST be included if the Start Time
Maximum Start Time options are included. The Lease Identifier

Hanna, et al. Standards Track [Page 12]

RFC 2730 MADCAP December 1999

MUST always be included

2.2.3.

The OFFER message is a unicast message sent by a MADCAP server
response to a DISCOVER message that it can probably satisfy

A MADCAP server is never required to send an OFFER message
response to a DISCOVER message. For instance, it may not be able
satisfy the client's request or it may have been configured
respond only to certain types of DISCOVER messages or not to
to DISCOVER messages at all

If a MADCAP server decides to send an OFFER message, it MUST
the Lease Time and Multicast Scope options, describing the
it is willing to provide. However, it need not include the List
Address Ranges option. If the List of Address Ranges Allocated
is not included, it is assumed that the server is willing to
the number of addresses that the client requested. If the Start
option is not included, it is assumed that the server is willing
provide the start time requested by the client (if any). The
Time option MUST be included if the Start Time option is included

If a server can process the request with a shorter lease time
later start time than the client requested, it SHOULD send an
message with the lease time or start time that it can offer
However, it MUST NOT offer a lease time shorter than the
lease time specified by the client or a start time later than
maximum start time specified by the client

If the server sends an OFFER message, it SHOULD attempt to
enough addresses to complete the transaction. If it receives
multicast REQUEST message with the same Lease Identifier option
the DISCOVER message for which it is holding these addresses and
Server Identifier option that does not match its own, it SHOULD
holding the addresses. The server SHOULD also stop holding
addresses after an appropriate delay [OFFER-HOLD] if the
is not completed. The value of this delay is implementation-specific
but a value of at least 60 seconds is RECOMMENDED

As with all messages sent by the server, the xid field MUST match
xid field included in the client request to which this message
responding. The Lease Identifier option MUST be included, with
value matching the one included in the client request. The
Identifier option MUST be included, with the value being the server'
IP address. And the packet MUST NOT be retransmitted

Hanna, et al. Standards Track [Page 13]

RFC 2730 MADCAP December 1999

2.2.4.

The REQUEST message is used by a MADCAP client that wants to
one or more multicast addresses. It is not used for renewing
existing lease. The RENEW message is used for that

If a REQUEST message is completing a transaction initiated by
DISCOVER message, the following procedure MUST be followed so
all MADCAP servers know which server was selected. The client
multicast a REQUEST message to the same MADCAP Server
Address that the DISCOVER message was sent to. The same
Identifier used in the DISCOVER message MUST be used in the
message. Also, the Server Identifier option MUST be included,
the Server Identifier of the server selected

If a REQUEST message is not completing a transaction initiated by
DISCOVER message, the REQUEST message MUST be unicast to the
server that the client wants to use. In this case, the
Identifier option MAY be included, but need not be

If the selected server can process the request successfully,
SHOULD unicast an ACK message to the client. Otherwise, it
generate and process an error in the manner described in section 2.6.
If a server can process the request with a shorter lease time
later start time than the client requested, it SHOULD send an
message with the lease time or start time that it can offer. However
it MUST NOT offer a lease time shorter than the minimum lease
specified by the client or a start time later than the maximum
time specified by the client

When a MADCAP client sends a REQUEST message, it MAY include
Lease Time, Minimum Lease Time, Start Time, Maximum Start Time
Number of Addresses Requested, and List of Address Ranges options
describing the addresses it wants to receive. However, it need
include any of these options. If one of these options is
included, the server will provide the appropriate default (
available for Lease Time, no minimum for Minimum Lease Time, as
as possible for Start Time, no maximum for Maximum Start Time,
for Number of Addresses Requested, and any addresses available
List of Address Ranges). The Multicast Scope option MUST be
in the REQUEST message so that the server knows what scope should
used. The Current Time option MUST be included if the Start Time
Maximum Start Time options are included

If a client sends a REQUEST message and does not receive any ACK
NAK messages in response, the client SHOULD resend its
message, as described in section 2.3.

Hanna, et al. Standards Track [Page 14]

RFC 2730 MADCAP December 1999

If the server responds with a NAK or fails to respond within
reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY],
client MAY try to find another server by sending a DISCOVER
with another xid or sending a REQUEST message with another xid
another server. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60
seconds

2.2.5.

The ACK message is used by a MADCAP server to respond
to an GETINFO, REQUEST, or RELEASE message. The server unicasts
ACK message to the client from which it received the message to
it is responding

The set of options included with an ACK message differs, depending
what sort of message it is responding to

If the ACK message is responding to an GETINFO message, it
include any options requested by the client using the Option
List option

If the ACK message is responding to a REQUEST message, it
include Lease Time, Multicast Scope, and List of Address
options. It MAY include a Start Time option. If a Start Time
is included, a Current Time option MUST also be included. If no
Time option is included, the lease is assumed to start immediately

If the ACK message is responding to a RENEW message, it MUST
Lease Time, Multicast Scope, and List of Address Ranges options.
MAY include a Start Time option. If a Start Time option is included
a Current Time option MUST also be included. If no Start Time
is included, the lease is assumed to start immediately

If the ACK message is responding to a RELEASE message, it MUST
include Server Identifier and Lease Identifier options

As with all messages sent by the server, the xid field MUST match
xid field included in the client request to which this message
responding. The Lease Identifier option MUST be included, with
value matching the one included in the client request. The
Identifier option MUST be included, with the value being the server'
IP address. And the packet MUST NOT be retransmitted

2.2.6.

The NAK message is used by a MADCAP server to respond negatively to
message. The server unicasts the NAK message to the client from
it received the message to which it is responding

Hanna, et al. Standards Track [Page 15]

RFC 2730 MADCAP December 1999

As with all messages sent by the server, the xid field MUST match
xid field included in the client request to which this message
responding. The Lease Identifier option MUST be included, with
value matching the one included in the client request. The
Identifier option MUST be included, with the value being the server'
IP address. The Error option MUST be included with an error
indicating what went wrong. And the packet MUST NOT be retransmitted

2.2.7.

The RENEW message is used by a MADCAP client that wants to renew
multicast address lease, changing the lease time or start time

The client unicasts the RENEW message to a MADCAP server. If
server can process the request successfully, it SHOULD unicast an
message to the client. Otherwise, it MUST generate and process
error in the manner described in section 2.6.

The lease to be renewed is whichever one was allocated with a
Identifier option matching the one provided in the RENEW message

When a MADCAP client sends a RENEW message, it MAY include the
Time, Minimum Lease Time, Start Time, and Maximum Start Time options
describing the new lease it wants to receive. However, it need
include any of these options. If one of these options is
included, the server will provide the appropriate default (
available for Lease Time, no minimum for Minimum Lease Time, as
as possible for Start Time, and no maximum for Maximum Start Time).
The Current Time option MUST be included if the Start Time or
Start Time options are included

If a client sends a RENEW message and does not receive any ACK or
messages in response, the client SHOULD resend its RENEW message,
described in section 2.3.

If the server responds with a NAK or fails to respond within
reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY],
client MAY send a RENEW message with another xid to another server
provided that the Server Mobility feature was used in the
REQUEST message and that this feature is required for the
RENEW message sent to another server. For more information about
Server Mobility feature, see section 2.13.1. The RECOMMENDED
for [NO-RESPONSE-DELAY] is 60 seconds

Hanna, et al. Standards Track [Page 16]

RFC 2730 MADCAP December 1999

2.2.8.

The RELEASE message is used by a MADCAP client that wants
deallocate one or more multicast addresses before their
expires

The client unicasts the RELEASE message to the MADCAP server
which it allocated the addresses. If the selected server can
the request successfully, it MUST unicast an ACK message to
client. Otherwise, it MUST generate and process an error in
manner described in section 2.6.

The lease to be released is whichever one was allocated with a
Identifier option matching the one provided in the RELEASE message
It is not possible to release only part of the addresses in a
lease

If a client sends a RELEASE message and does not receive any ACK
NAK messages in response, the client SHOULD resend its
message, as described in section 2.3.

If the server responds with a NAK or fails to respond within
reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY],
client MAY send a RELEASE message with another xid to another server
provided that the Server Mobility feature was used in the
REQUEST message and that this feature is required for the
RELEASE message sent to another server. For more information
the Server Mobility feature, see section 2.13.1. The
value for [NO-RESPONSE-DELAY] is 60 seconds

2.3.

MADCAP clients are responsible for all message retransmission.
client MUST adopt a retransmission strategy that incorporates
exponential backoff algorithm to determine the delay
retransmissions. The delay between retransmissions SHOULD be
to allow sufficient time for replies from the server to be
based on the characteristics of the internetwork between the
and the server

The RECOMMENDED algorithm is to use a 4 second delay before the
retransmission and to double this delay for each
retransmission, with a maximum delay of 16 seconds and a maximum
three retransmissions. If an initial transmission was sent at
(in seconds) t and no responses were received,
transmissions would be at t+4, t+12, and t+28. If no response
been received by t+60, the client would stop retransmitting and
another course of action (such as logging an error or sending

Hanna, et al. Standards Track [Page 17]

RFC 2730 MADCAP December 1999

message to another address

The client MAY provide an indication of retransmission attempts
the user as an indication of the progress of the process. The
MAY halt retransmission at any point

2.4. The Lease

The Lease Identifier option is included in each MADCAP message.
value is used to identify a lease and MUST be unique across
leases requested by all clients in a multicast address
domain

The first octet of the Lease Identifier is the Lease Identifier type
Table 3 lists the Lease Identifier types defined at this time
sections 2.4.1 and 2.4.2 describe these Lease Identifier types

New MADCAP Lease Identifier types may only be defined by
Consensus, as described in section 5.

Lease Identifier Type
--------------------- ----
0 Random Lease
1 Address-Specific Lease

Table 3: MADCAP Lease Identifier

The MADCAP server does not need to parse the Lease Identifier.
SHOULD use the Lease Identifier only as an opaque identifier,
must be unique for each lease. The purpose of defining
Lease Identifier types is to allow MADCAP clients that already have
globally unique address to avoid the possibility of Lease
collisions by using this address together with a client-
identifier. MADCAP clients that do not have a globally unique
SHOULD use Lease Identifier type 0.

In addition to associating client and server messages (along with
msgtype and xid fields, as described in the next section), the
Identifier is used to determine which lease a RENEW or
request refers to. MADCAP servers SHOULD match the Lease
included in a RENEW or RELEASE message with the Lease Identifier
in an initial REQUEST message. If the Lease Identifier does
match, a MADCAP server MUST generate and process a Lease
Not Recognized error in the manner described in section 2.6.

Hanna, et al. Standards Track [Page 18]

RFC 2730 MADCAP December 1999

For conferencing applications, it may be desirable to
conference participants to modify a lease used for the conference
The Shared Lease Identifier feature code is used to support
requirement. If this feature code was requested by the client
implemented by the server when the lease was allocated, the
SHOULD disable any authentication requirements and allow any
that knows the Lease Identifier to modify the lease

As described in the Security Considerations section, MADCAP
is not terribly useful without admission control in the
routing infrastructure. However, if MADCAP security is desired
using the Shared Lease Identifier feature, the confidentiality of
Lease Identifier MUST be maintained by encrypting all messages
contain it. A Lease Identifier that includes a long
random number (at least eight octets in length) MUST be used in
circumstance so that it is not easy to guess the Lease Identifier

2.4.1. Random Lease

The first octet of a Random Lease Identifier is the Lease
type (0 to indicate Random Lease Identifier). After this come
sequence of octets, which SHOULD represent a long random number (
least 16 octets) from a decent random number generator

A Random Lease Identifier does not include any indication of
length. It is assumed that this may be determined by external means
such as a length field preceding the Lease Identifier

Lease
Type Random
+---------+-------------...
| 0 |
+---------+-------------...

2.4.2. Address-Specific Lease

The first octet of an Address-Specific Lease Identifier is the
Identifier type (1 to indicate Address-Specific Lease Identifier).
After this comes a two octet IANA-defined address family
(including those defined in [10]), an address from the
address family, and a client-specific identifier (such as a
number or the current time).

An Address-Specific Lease Identifier does not include any
of its length. It is assumed that this may be determined by
means, such as a length field preceding the Lease Identifier

Hanna, et al. Standards Track [Page 19]

RFC 2730 MADCAP December 1999

Lease ID Address Family Address Client-
Type Number
+---------+---------+---------+-----...-----+-----...-----+
| 1 | addrfamily | address | cli-spec id |
+---------+---------+---------+-----...-----+-----...-----+

2.5. Associating Client and Server

Messages between clients and servers are associated with one
using the Lease Identifier and the xid field. As described in
2.1.4, the client MUST choose an xid so that it is unlikely that
same combination of xid, msgtype, and Lease Identifier will be
for two different messages within [XID-REUSE-INTERVAL] (even
multiple clients which do not communicate among themselves).
Lease Identifier option, msgtype, and xid field MUST be included
each message sent by the client or the server

The client MUST check the Lease Identifier option and xid field
each incoming message to ensure that they match the Lease
and xid for an outstanding transaction. If not, the message MUST
ignored. The server MUST check the Lease Identifier option and
field in each incoming message to establish the proper context
the message. If a server cannot process a message because it
invalid for its context, the server MUST generate and process
Invalid Request error, as described in section 2.6. A
can be an attempt to allocate a multicast address (consisting
DISCOVER, OFFER, REQUEST, ACK, and NAK messages), an attempt to
a lease (consisting of RENEW, ACK, and NAK messages), an attempt
release a previously allocated multicast address (consisting
RELEASE, ACK, and NAK messages), or an attempt to
configuration parameters (consisting of GETINFO, ACK, and
messages).

2.6. Processing

If a MADCAP server encounters an error while processing a message
there are two different ways to process this error. If it is
that the message is not a NAK, the server SHOULD respond with a
containing the appropriate Error option. However, the server
decide to completely ignore chronic offenders. If the message is
NAK or it is not clear whether the message is a NAK (for instance
the message is garbled or has an incorrect version number),
server SHOULD ignore the message. This avoids NAK loops

If a MADCAP client encounters an error while processing a message,
MUST ignore the message

Hanna, et al. Standards Track [Page 20]

RFC 2730 MADCAP December 1999

2.7. Multicast

RFC 2365 [3] provides for dividing the multicast address space into
number of administrative scopes. Routers should be configured so
each scope corresponds to a particular partition of the network
disjoint regions. Messages sent to a multicast address that
within a certain administrative scope should only be delivered
hosts that have joined that multicast group *and* fall within
same region as the sender. For instance, packets sent to an
in the organization-local scope should only be delivered to
that have joined that group and fall within the same organization
the sender

Different sets of scopes may be in effect at different places in
network and at different times. Before attempting to allocate
address from an administrative scope (other than global or link-
scope, which are always in effect), a MADCAP client SHOULD
that the scope is in effect at its location at this time.
techniques that a MADCAP client may use to determine the set
administrative scopes in effect (the scope list) are:
configuration or configuration via MADCAP (using the Multicast
List option).

If a MADCAP client is unable to determine its scope list using one
these techniques, it MAY temporarily assume a scope list
of a single scope. If it is using IPv4, it SHOULD use IPv4
Scope (239.255.0.0/16), with a maximum TTL of 16. If it is
IPv6, it SHOULD use SCOP 3, with a maximum hop count of 16.
this temporary scope list, it MAY attempt to contact a MADCAP
that can provide a scope list for it

When a MADCAP client requests an address with a DISCOVER or
message, it MUST specify the administrative scope from which
address should be allocated. This scope is indicated with
Multicast Scope option. Likewise, the server MUST include
Multicast Scope option in all OFFER messages and all ACK
sent in response to REQUEST messages

2.8. Multicast

Another way to limit propagation of multicast messages is by
TTL scoping. This technique has several disadvantages in
to administratively scoped multicast addresses (as described in [3]),
but it is currently in widespread usage

With TTL scoping, areas of the network are designated as scopes
Routers on the edges of these areas are configured with
thresholds so that multicast packets are not forwarded unless

Hanna, et al. Standards Track [Page 21]

RFC 2730 MADCAP December 1999

remaining TTL exceeds this threshold. A packet which should
restricted to a given TTL scope should have an initial TTL less
that scope's TTL threshold. Similar techniques may be used with IPv6,
using the Hop Count field instead of the TTL field

MADCAP may be used in an environment where administrative scoping
not in use and TTL scoping is. Under these circumstances, a
server MAY return a scope list that includes scopes with TTLs
than 255. The MADCAP client MAY then allocate addresses from
scopes, but MUST NOT set the TTL field of any packet sent to such
address to a value greater than the maximum TTL indicated in
scope list. In such an environment, it is recommended that the
Server Multicast Addresses associated with the IPv4 Local Scope (
SCOP 3 for IPv6) be configured using TTL thresholds so that
sent to these addresses with TTL of 16 are not sent outside
appropriate boundary. This will allow MADCAP clients to use
default behavior for finding MADCAP servers

In an environment where administrative scoping is in use, the
TTLs in the scope list SHOULD be 255. The admin scope zone
routers will prevent leakage of MADCAP packets beyond
limits

2.9. Locating MADCAP

There are several ways for a MADCAP client to locate a MADCAP server
For instance, the client may be configured with an IP address

The RECOMMENDED technique is for the client to send an
message to a MADCAP Server Multicast Address and wait for
responses. This technique is described in more detail in the
section

2.10. MADCAP Server Multicast

Each multicast scope has an associated MADCAP Server
Address. This address has been reserved by the IANA as the
with a relative offset of -1 from the last address of a
scope

A MADCAP client looking for servers that can provide
allocation services MAY send an GETINFO message to a MADCAP
Multicast Address. Any MADCAP servers listening to this
SHOULD respond with a unicast ACK message to the client if they
to offer a response

Hanna, et al. Standards Track [Page 22]

RFC 2730 MADCAP December 1999

The MADCAP Server Multicast Address used by a client MAY
established by configuration. If a client has no such configuration
it SHOULD use the MADCAP Server Multicast Address associated
IPv4 Local Scope (or SCOP 3 for IPv6) with maximum TTL of 16,
otherwise configured

2.11. Going Beyond the Local

If a client receives no response to a message sent to a MADCAP
Multicast Address (after retransmission), it MAY send the message
a larger scope and repeat this process as necessary. However,
client MUST NOT send a MADCAP message to the MADCAP Server
Address associated with the global scope

This technique allows MADCAP servers to provide services for
in which they do not reside. However, this is a dangerous
complicated technique and is NOT RECOMMENDED at this time
Therefore, MADCAP clients SHOULD only send multicast messages to
MADCAP Server Multicast Address corresponding to the IPv4 Local
(or SCOP 3, if using IPv6), unless configured otherwise

MADCAP servers that wish to provide services for scopes in which
do not reside MUST make special efforts to ensure that their
meet clients' needs for largely conflict-free allocation and
scope list information. In particular, coordinating with
servers that provide services for this scope may be difficult. Also
establishing which scope the client is in may be difficult. If
MADCAP server is not prepared to provide services for scopes in
it does not reside, it SHOULD ignore DISCOVER and REQUEST
whose scope does not match or enclose the scope of the MADCAP
Multicast Address on which the request was received. It SHOULD
ignore GETINFO messages that are not received on the MADCAP
Multicast Address for IPv4 Local Scope

2.12. Clock

The Current Time option is used to detect and handle clock
between MADCAP clients and servers. This option MUST be included
any MADCAP message that includes an absolute time (such as the
Time option). It MAY be included in any DISCOVER, OFFER, REQUEST
RENEW, or ACK message

Clock skew is a situation where two systems have clocks that are
synchronized. Many protocols (such as DHCP) ignore clock skew
using relative times. MADCAP could use a similar technique, but
leads to nasty situations due to the way multicast addresses
used

Hanna, et al. Standards Track [Page 23]

RFC 2730 MADCAP December 1999

For example, assume that at 1 PM UTC a client whose clock is one
fast requests a lease for one hour starting in one hour. If we
using relative times for MADCAP, the server, whose clock is
correctly, would reserve a multicast address for 2 to 3 PM UTC
grant the request. If the client was the only one using the lease
everything would be OK. The client would start using the lease in
hour and continue for one hour. This would coincide with the time
server had reserved (although the client would think it was 3 to 4
UTC).

However, multicast addresses are usually used by several parties
once. The client would probably use SAP (or some other mechanism
conveying SDP) to advertise a session using the multicast
just leased. SDP uses absolute times, since it may be sent via email
web, or other store-and-forward mechanisms. So the client
advertise the session as running from 3 to 4 PM UTC. Any
whose clocks are set correctly would use the address during
interval. Since the server only reserved the address from 2 to 3
UTC, this might cause the address to be used for multiple
simultaneously

MADCAP cannot solve all clock skew problems. That is the domain
NTP [4]. However, it does attempt to detect substantial clock
between MADCAP clients and servers so that this clock skew does
cause massive collisions in multicast address usage later on

The Current Time option contains the sender's opinion of the
time in UTC at or about the time the message was assembled.
of delays in transmission and processing, this value will
match the receiver's opinion of the current time at the time
option is processed by the receiver. However, difference greater
a minute or two probably indicate clock skew between the sender
the receiver

MADCAP servers SHOULD expect and tolerate a small amount of
skew with their clients by ensuring that multicast addresses
allocated for an extra period of time [EXTRA-ALLOCATION-TIME]
either side of the lease given to the client. However, large
of clock skew require special handling. The value of [EXTRA
ALLOCATION-TIME] MUST be a configurable parameter, since
circumstances may vary. The RECOMMENDED default is one hour

However, large amounts of clock skew will cause problems later
sessions are advertised. If a MADCAP server detects clock
greater than [CLOCK-SKEW-ALLOWANCE], it MUST generate and process
Excessive Clock Skew error, as described in section 2.6. The
MAY also log a message. The value of [CLOCK-SKEW-ALLOWANCE] MUST be
configurable parameter, since local circumstances may vary.

Hanna, et al. Standards Track [Page 24]

RFC 2730 MADCAP December 1999

RECOMMENDED default is 30 minutes

2.13. Optional

Each MADCAP client or server MAY implement one or more
features. Optional features of MADCAP are identified with a
octet feature code

A MADCAP client MAY request, require, or indicate support for
optional feature by including a Feature List option in a message.
more information about optional features, see the description of
Feature List option

Table 4 lists the feature codes defined at this time and
2.13.1 and 2.13.2 describe how these features work

New MADCAP feature codes may only be defined by IETF Consensus,
described in section 5.

Feature Code Feature
------------ ------------
0 Server
1 Retry
2 Shared Lease

Table 4: MADCAP Feature

2.13.1. Server

The Server Mobility feature allows an address allocated on one
server to be renewed or released on a different MADCAP server.
requires communication and coordination among MADCAP servers.
primary benefits are immunity to the failure of a single
server and perhaps greater performance through load balancing

In order to take advantage of the Server Mobility feature, a
client must ensure that the feature is implemented by both the
that is used for the original allocation and the server that is
for the renewal or release. The best way to ensure this is to
the Server Mobility feature in the required list of a Feature
option in the REQUEST message used to allocate the address (and
DISCOVER message, if one is used). When the time comes to renew
release the address, the client SHOULD send a unicast RENEW
RELEASE message to the server from which it allocated the address
However, if this server is unavailable, the client MAY send the
or RELEASE message to any other server that includes the
Mobility feature in its list of supported features. The client
find such a server by (for instance) sending an GETINFO message

Hanna, et al. Standards Track [Page 25]

RFC 2730 MADCAP December 1999

an Option Request List option that includes the Feature List
code

If the MADCAP client does not want to require this feature
allocating addresses, it may include the feature in the
list of a Feature List option and see if the server includes
feature in the required list of a Feature List option in the
message

Even if the Server Mobility feature is used, there is no
that a server will be available to perform the renewal or release
that the renewal or release will succeed. Server connectivity
have failed, for instance

2.13.2. Retry

The Retry After feature allows a MADCAP server to ask the
client to retry its request later, as may be required when
large numbers of addresses or allocating addresses for a long
of time

For instance, if a MADCAP client requests 1000 addresses
administrative approval may be required or allocation of
addresses from another MASC domain may be necessary. This may
several hours or several days. If the MADCAP client and server
support the Retry After feature, the MADCAP server can send back
ACK message with a Retry Time option indicating when the
may be ready. The client can retry its request after the Retry
to get the addresses

If a MADCAP client includes the Retry After feature in the
list of a Feature List option in a REQUEST message, a MADCAP
that supports the Retry After feature MAY decide to begin a
allocation process. In this case, the MADCAP server will include
empty List of Address Ranges option in its ACK message, a
List option that includes the Retry After feature in the
list, and a Retry Time option with a time after which the
should retry the REQUEST

The client MUST NOT include the Retry After feature in the
or required list of a Feature List option, since the decision
whether Retry After is desirable should be left to the MADCAP server

Hanna, et al. Standards Track [Page 26]

RFC 2730 MADCAP December 1999

At some later time (preferably after the time indicated in the
Time option), the client SHOULD send a REQUEST message with all
same options as the original REQUEST message (especially the
Identifier option), but with a new xid value. The server MAY
a normal ACK or NAK message at this point or it MAY continue
transaction to a later time by including an empty List of
Ranges option in its ACK message, a Feature List option that
the Retry After feature in the required list, and a Retry Time
with a later time after which the client should retry the REQUEST

At any point after receiving the initial ACK message with the
Time option, the client MAY terminate the allocation process and
accompanying lease by sending to the server performing the
(or another server if the Server Mobility feature is also in effect
a RELEASE message with the Lease Identifier included in the
REQUEST message

The Retry After feature may also be used when renewing a lease.
this case, the description above applies except that the client
a RENEW message instead of a REQUEST message

If a client sends a RENEW message with a Lease Identifier
matches a lease which is currently undergoing allocation with
Retry After feature in response to a REQUEST message, the server
generate and process an Invalid Request error in the manner
in section 2.6. Also, if a client sends a RENEW message with a
Identifier that matches a lease which is currently
allocation with the Retry After feature in response to a
message, but the options supplied with the two RENEW messages do
match, the server MUST generate and process an Invalid Request
in the manner described in section 2.6.

Note that the Retry After feature may complicate the application API
For this reason, a MADCAP client may request the Retry After
for some messages and not for others. This should not cause
for a robust MADCAP server. In general, servers should not
consistent behavior from clients except as required by
specification. This also applies to clients' expectations

2.13.3. Shared Lease

For conferencing applications, it may be desirable to
conference participants to modify a lease used for the conference
The Shared Lease Identifier feature code is used to support
requirement

Hanna, et al. Standards Track [Page 27]

RFC 2730 MADCAP December 1999

If this feature code was requested by the client and implemented
the server when the lease was allocated, the server SHOULD
any authentication requirements pertaining to this lease,
any client that knows the Lease Identifier to modify the lease

A MADCAP client wishing to use the Shared Lease Identifier
should include this feature in the requested or required lists of
Feature List option of a REQUEST message when first allocating
lease. If the feature was required, the server SHOULD try
implement it for this request and include the feature in the
list of the response. If the server can not implement the feature
this request, it MUST generate and process a Required Feature
Supported error in the manner described in section 2.6. If
feature was requested, the server SHOULD try to implement the
and include the feature in the required list of the response
However, if the server cannot implement the feature, it may
skip it

Subsequent requests pertaining to a lease for which the Shared
Identifier feature was implemented at allocation time MAY include
Shared Lease Identifier feature in the