(or SCOP 3, if using IPv6), unless configured otherwise.
MADCAP servers that wish to provide services for scopes in which they
do not reside MUST make special efforts to ensure that their services
meet clients' needs for largely conflict-free allocation and accurate
scope list information. In particular, coordinating with other
servers that provide services for this scope may be difficult. Also,
establishing which scope the client is in may be difficult. If a
MADCAP server is not prepared to provide services for scopes in which
it does not reside, it SHOULD ignore DISCOVER and REQUEST messages
whose scope does not match or enclose the scope of the MADCAP Server
Multicast Address on which the request was received. It SHOULD also
ignore GETINFO messages that are not received on the MADCAP Server
Multicast Address for IPv4 Local Scope.
2.12. Clock Skew
The Current Time option is used to detect and handle clock skew
between MADCAP clients and servers. This option MUST be included in
any MADCAP message that includes an absolute time (such as the Start
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 not
synchronized. Many protocols (such as DHCP) ignore clock skew by
using relative times. MADCAP could use a similar technique, but this
leads to nasty situations due to the way multicast addresses are
used.
For example, assume that at 1 PM UTC a client whose clock is one hour
fast requests a lease for one hour starting in one hour. If we were
using relative times for MADCAP, the server, whose clock is set
correctly, would reserve a multicast address for 2 to 3 PM UTC and
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 one
hour and continue for one hour. This would coincide with the time the
server had reserved (although the client would think it was 3 to 4 PM
UTC).
However, multicast addresses are usually used by several parties at
once. The client would probably use SAP (or some other mechanism for
conveying SDP) to advertise a session using the multicast address
just leased. SDP uses absolute times, since it may be sent via email,
web, or other store-and-forward mechanisms. So the client would
advertise the session as running from 3 to 4 PM UTC. Any clients
whose clocks are set correctly would use the address during this
interval. Since the server only reserved the address from 2 to 3 PM
UTC, this might cause the address to be used for multiple sessions
simultaneously.
MADCAP cannot solve all clock skew problems. That is the domain of
NTP [4]. However, it does attempt to detect substantial clock skew
between MADCAP clients and servers so that this clock skew does not
cause massive collisions in multicast address usage later on.
The Current Time option contains the sender's opinion of the current
time in UTC at or about the time the message was assembled. Because
of delays in transmission and processing, this value will rarely
match the receiver's opinion of the current time at the time the
option is processed by the receiver. However, difference greater than
a minute or two probably indicate clock skew between the sender and
the receiver.
MADCAP servers SHOULD expect and tolerate a small amount of clock
skew with their clients by ensuring that multicast addresses are
allocated for an extra period of time [EXTRA-ALLOCATION-TIME] on
either side of the lease given to the client. However, large amounts
of clock skew require special handling. The value of [EXTRA-
ALLOCATION-TIME] MUST be a configurable parameter, since local
circumstances may vary. The RECOMMENDED default is one hour.
However, large amounts of clock skew will cause problems later when
sessions are advertised. If a MADCAP server detects clock skew
greater than [CLOCK-SKEW-ALLOWANCE], it MUST generate and process an
Excessive Clock Skew error, as described in section 2.6. The server
MAY also log a message. The value of [CLOCK-SKEW-ALLOWANCE] MUST be a
configurable parameter, since local circumstances may vary. The
RECOMMENDED default is 30 minutes.
2.13. Optional Features
Each MADCAP client or server MAY implement one or more optional
features. Optional features of MADCAP are identified with a two
octet feature code.
A MADCAP client MAY request, require, or indicate support for an
optional feature by including a Feature List option in a message. For
more information about optional features, see the description of the
Feature List option.
Table 4 lists the feature codes defined at this time and sections
2.13.1 and 2.13.2 describe how these features work.
New MADCAP feature codes may only be defined by IETF Consensus, as
described in section 5.
Feature Code Feature Name
------------ ------------
0 Server Mobility
1 Retry After
2 Shared Lease Identifier
Table 4: MADCAP Feature Codes
2.13.1. Server Mobility
The Server Mobility feature allows an address allocated on one MADCAP
server to be renewed or released on a different MADCAP server. This
requires communication and coordination among MADCAP servers. The
primary benefits are immunity to the failure of a single MADCAP
server and perhaps greater performance through load balancing.
In order to take advantage of the Server Mobility feature, a MADCAP
client must ensure that the feature is implemented by both the server
that is used for the original allocation and the server that is used
for the renewal or release. The best way to ensure this is to include
the Server Mobility feature in the required list of a Feature List
option in the REQUEST message used to allocate the address (and the
DISCOVER message, if one is used). When the time comes to renew or
release the address, the client SHOULD send a unicast RENEW or
RELEASE message to the server from which it allocated the address.
However, if this server is unavailable, the client MAY send the RENEW
or RELEASE message to any other server that includes the Server
Mobility feature in its list of supported features. The client can
find such a server by (for instance) sending an GETINFO message with
an Option Request List option that includes the Feature List option
code.
If the MADCAP client does not want to require this feature when
allocating addresses, it may include the feature in the requested
list of a Feature List option and see if the server includes the
feature in the required list of a Feature List option in the ACK
message.
Even if the Server Mobility feature is used, there is no guarantee
that a server will be available to perform the renewal or release or
that the renewal or release will succeed. Server connectivity may
have failed, for instance.
2.13.2. Retry After
The Retry After feature allows a MADCAP server to ask the MADCAP
client to retry its request later, as may be required when allocating
large numbers of addresses or allocating addresses for a long period
of time.
For instance, if a MADCAP client requests 1000 addresses,
administrative approval may be required or allocation of more
addresses from another MASC domain may be necessary. This may take
several hours or several days. If the MADCAP client and server both
support the Retry After feature, the MADCAP server can send back an
ACK message with a Retry Time option indicating when the addresses
may be ready. The client can retry its request after the Retry Time
to get the addresses.
If a MADCAP client includes the Retry After feature in the supported
list of a Feature List option in a REQUEST message, a MADCAP server
that supports the Retry After feature MAY decide to begin a lengthy
allocation process. In this case, the MADCAP server will include an
empty List of Address Ranges option in its ACK message, a Feature
List option that includes the Retry After feature in the required
list, and a Retry Time option with a time after which the client
should retry the REQUEST.
The client MUST NOT include the Retry After feature in the requested
or required list of a Feature List option, since the decision about
whether Retry After is desirable should be left to the MADCAP server.
At some later time (preferably after the time indicated in the Retry
Time option), the client SHOULD send a REQUEST message with all the
same options as the original REQUEST message (especially the Lease
Identifier option), but with a new xid value. The server MAY return
a normal ACK or NAK message at this point or it MAY continue the
transaction to a later time by including an empty List of Address
Ranges option in its ACK message, a Feature List option that includes
the Retry After feature in the required list, and a Retry Time option
with a later time after which the client should retry the REQUEST.
At any point after receiving the initial ACK message with the Retry
Time option, the client MAY terminate the allocation process and any
accompanying lease by sending to the server performing the allocation
(or another server if the Server Mobility feature is also in effect)
a RELEASE message with the Lease Identifier included in the original
REQUEST message.
The Retry After feature may also be used when renewing a lease. In
this case, the description above applies except that the client sends
a RENEW message instead of a REQUEST message.
If a client sends a RENEW message with a Lease Identifier that
matches a lease which is currently undergoing allocation with the
Retry After feature in response to a REQUEST message, the server MUST
generate and process an Invalid Request error in the manner described
in section 2.6. Also, if a client sends a RENEW message with a Lease
Identifier that matches a lease which is currently undergoing
allocation with the Retry After feature in response to a RENEW
message, but the options supplied with the two RENEW messages do not
match, the server MUST generate and process an Invalid Request error
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 feature
for some messages and not for others. This should not cause problems
for a robust MADCAP server. In general, servers should not expect
consistent behavior from clients except as required by this
specification. This also applies to clients' expectations.
2.13.3. Shared Lease Identifier
For conferencing applications, it may be desirable to allow
conference participants to modify a lease used for the conference.
The Shared Lease Identifier feature code is used to support this
requirement.
If this feature code was requested by the client and implemented by
the server when the lease was allocated, the server SHOULD disable
any authentication requirements pertaining to this lease, allowing
any client that knows the Lease Identifier to modify the lease.
A MADCAP client wishing to use the Shared Lease Identifier feature
should include this feature in the requested or required lists of the
Feature List option of a REQUEST message when first allocating the
lease. If the feature was required, the server SHOULD try to
implement it for this request and include the feature in the required
list of the response. If the server can not implement the feature for
this request, it MUST generate and process a Required Feature Not
Supported error in the manner described in section 2.6. If the
feature was requested, the server SHOULD try to implement the feature
and include the feature in the required list of the response.
However, if the server cannot implement the feature, it may simply
skip it.
Subsequent requests pertaining to a lease for which the Shared Lease
Identifier feature was implemented at allocation time MAY include the
Shared Lease Identifier feature in the requested or required lists of
the Feature List option. In this case, the server SHOULD try to
implement the feature by disabling any authentication requirements
pertaining to this lease, allowing any client that knows the Lease
Identifier to modify the lease, and including the feature in the
required list of the response. If the server cannot implement the
feature, it SHOULD skip it if the feature was requested. But if the
feature was required and the server cannot implement it, the server
MUST generate and process a Required Feature Not Supported error in
the manner described in section 2.6.
3. MADCAP Options
As described earlier, each MADCAP message includes an options field
consisting of a list of tagged parameters that are called "options".
All options consist of a two octet option code and a two octet option
length, followed by the number of octets specified by the option
length.
This section defines a set of option codes for use in MADCAP
messages. New options may be defined using the process defined in
section 5. The options are listed in numerical order.
Table 5 summarizes which options are allowed with each message type.
Option GETINFO ACK (in response to GETINFO)
------ ------ ---------------------------
Lease Time MUST NOT MUST NOT
Server Identifier MUST NOT MUST
Lease Identifier MUST MUST
Multicast Scope MUST NOT MUST NOT
Option Request List MUST MUST NOT
Start Time MUST NOT MUST NOT
Number of Addresses
Requested MUST NOT MUST NOT
Requested Language MAY MUST NOT
Multicast Scope List MUST NOT MAY
List of Address Ranges MUST NOT MUST NOT
Current Time MUST NOT MAY
Feature List MAY MAY
Retry Time MUST NOT MUST NOT
Minimum Lease Time MUST NOT MUST NOT
Maximum Start Time MUST NOT MUST NOT
Error MUST NOT MUST NOT
Option DISCOVER OFFER
------ -------- -----
Lease Time MAY MUST
Server Identifier MUST NOT MUST
Lease Identifier MUST MUST
Multicast Scope MUST MUST
Option Request List MUST NOT MUST NOT
Start Time MAY MAY
Number of Addresses
Requested MAY MUST NOT
Requested Language MUST NOT MUST NOT
Multicast Scope List MUST NOT MUST NOT
List of Address Ranges MAY MAY
Current Time MAY MAY
Feature List MAY MAY
Retry Time MUST NOT MUST NOT
Minimum Lease Time MAY MUST NOT
Maximum Start Time MAY MUST NOT
Error MUST NOT MUST NOT
Option REQUEST ACK (in response to REQUEST)
------ ------- ----------------------------
Lease Time MAY MUST
Server Identifier MUST (if MUST
multicast)
Lease Identifier MUST MUST
Multicast Scope MUST MUST
Option Request List MUST NOT MUST NOT
Start Time MAY MAY
Number of Addresses
Requested MAY MUST NOT
Requested Language MUST NOT MUST NOT
Multicast Scope List MUST NOT MUST NOT
List of Address Ranges MAY MUST
Current Time MAY MAY
Feature List MAY MAY
Retry Time MUST NOT MAY
Minimum Lease Time MAY MUST NOT
Maximum Start Time MAY MUST NOT
Error MUST NOT MUST NOT
Option RENEW ACK (in response to RENEW)
------ ----- --------------------------
Lease Time MAY MUST
Server Identifier MUST NOT MUST
Lease Identifier MUST MUST
Multicast Scope MUST NOT MUST
Option Request List MUST NOT MUST NOT
Start Time MAY MAY
Number of Addresses
Requested MUST NOT MUST NOT
Requested Language MUST NOT MUST NOT
Multicast Scope List MUST NOT MUST NOT
List of Address Ranges MUST NOT MUST
Current Time MAY MAY
Feature List MAY MAY
Retry Time MUST NOT MAY
Minimum Lease Time MAY MUST NOT
Maximum Start Time MAY MUST NOT
Error MUST NOT MUST NOT
Option RELEASE ACK (in response to RELEASE)
------ ------- ----------------------------
Lease Time MUST NOT MUST NOT
Server Identifier MUST NOT MUST
Lease Identifier MUST MUST
Multicast Scope MUST NOT MUST NOT
Option Request List MUST NOT MUST NOT
Start Time MUST NOT MUST NOT
Number of Addresses
Requested MUST NOT MUST NOT
Requested Language MUST NOT MUST NOT
Multicast Scope List MUST NOT MUST NOT
List of Address Ranges MUST NOT MUST NOT
Current Time MUST NOT MUST NOT
Feature List MAY MAY
Retry Time MUST NOT MUST NOT
Minimum Lease Time MUST NOT MUST NOT
Maximum Start Time MUST NOT MUST NOT
Error MUST NOT MUST NOT
Option NAK
------ ---
Lease Time MUST NOT
Server Identifier MUST
Lease Identifier MUST
Multicast Scope MUST NOT
Option Request List MUST NOT
Start Time MUST NOT
Number of Addresses
Requested MUST NOT
Requested Language MUST NOT
Multicast Scope List MUST NOT
List of Address Ranges MUST NOT
Current Time MUST NOT
Feature List MAY
Retry Time MUST NOT
Minimum Lease Time MUST NOT
Maximum Start Time MUST NOT
Error MUST
Table 5: Options allowed in MADCAP messages
3.1. End
The End option marks the end of valid information in the options
field. This option MUST be included at the end of the options field
in each MADCAP message.
The code for this option is 0, and its length is 0.
Code Len
+-----+-----+-----+-----+
| 0 | 0 |
+-----+-----+-----+-----+
3.2. Lease Time
This option is used in a client request (DISCOVER, REQUEST, or RENEW)
to allow the client to request a lease time for the multicast
address. In a server reply (OFFER or ACK), a MADCAP server uses this
option to specify the lease time it is willing to offer.
The time is in units of seconds, and is specified as a 32-bit
unsigned integer.
The code for this option is 1, and its length is 4.
Code Len Lease Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.3. Server Identifier
This option contains the IP address of a MADCAP server. A two octet
address family number (as defined by IANA, including those defined in
[10]) is stored first, followed by the address. The address family
for this address is not determined by the addrfamily field in the
fixed header so that addresses from one family may be allocated while
communicating with a server via addresses of another family.
All messages sent by a MADCAP server MUST include a Server Identifier
option with the IP address of the server sending the message.
MADCAP clients MUST include a Server Identifier option in multicast
REQUEST messages in order to indicate which OFFER message has been
accepted.
The code for this option is 2, and its minimum length is 3.
Code Len Address Family Address
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | n | family | a1 | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
3.4. Lease Identifier
This option is used by MADCAP clients to specify a unique lease
identifier. For more information about this option and how it is
used, see section 2.4.
The code for this option is 3, and its minimum length is 1.
Code Len Lease Identifier
+-----+-----+-----+-----+-----+-----+---
| 3 | n | i1 | i2 | ...
+-----+-----+-----+-----+-----+-----+---
3.5. Multicast Scope
The multicast scope option is used by the client to indicate the
requested multicast scope in a DISCOVER or REQUEST message. It is
also used by the MADCAP server to indicate the scope of an assigned
address.
The client may obtain the scope list through the Multicast Scope List
option or using some other means. The Scope ID is the first multicast
address in the scope. The address family of the Scope ID is
determined by the addrfamily field in the fixed header.
The code for this option is 4, and its minimum length is 1.
Code Len Scope ID
+-----+-----+-----+-----+-----+-----
| 4 | n | i1 | ...
+-----+-----+-----+-----+-----+-----
3.6. Option Request List
This option is used by a MADCAP client in an GETINFO message to
request that certain options be included in the server's ACK
response. The server SHOULD try to include the specified options in
its response, but is not required to do so.
The format of this option is a list of option codes.
The code for this option is 5 and the minimum length is 2.
Code Len Requested Options
+-----+-----+-----+-----+-----+-----+---...
| 5 | n | Option1 |
+-----+-----+-----+-----+-----+-----+---...
3.7. Start Time
The Start Time option specifies the starting time for a multicast
address lease.
A client may include this option in a DISCOVER, RENEW, or REQUEST
message to request a multicast address for use at a future time. A
server may include this option in an OFFER message or in an ACK in
response to REQUEST or RENEW message to indicate that a lease has
been granted which starts at a future time.
If the Start Time option is present, the IP Address Lease Time option
specifies the duration of the lease beginning at the Start Time
option value.
If the Start Time option is present, the Current Time option MUST
also be present, as described in section 2.12.
The time value is an unsigned 32 bit integer in network byte order
giving the number of seconds since 00:00 UTC, 1st January 1970. This
can be converted to an NTP timestamp by adding decimal 2208988800.
This time format will not wrap until the year 2106.
The code for this option is 6 and the length is 4.
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.8. Number of Addresses Requested
This option specifies the minimum and desired number of addresses
requested by the client. It is only used in DISCOVER and REQUEST
messages and is only sent by the client.
The minimum and desired number of addresses requested are unsigned 16
bit integers in network byte order. The minimum MUST be less than or
equal to the desired number. If a message is received where this is
not the case, the MADCAP server MUST generate and process an Invalid
Request error in the manner described in section 2.6.
The client MAY obtain more than one address either by repeating the
protocol for every address or by requesting several addresses at the
same time via this option. When the client is requesting only one
address, this option SHOULD NOT be included. A MADCAP server
receiving a DISCOVER or REQUEST packet including this option MUST
include between the minimum and desired number of addresses in any
OFFER or ACK response.
The code for this option is 7 and the length is 4.
Code Len Minimum Desired
+-----+-----+-----+-----+-----+-----+-----+-----+
| 7 | 4 | min | desired |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.9. Requested Language
This option specifies the language in which the MADCAP client would
like strings such as zone names to be returned. It is only included
in an GETINFO message sent by the client. It is an RFC1766 [6]
language tag. The proper way to handle this tag with respect to zone
names is discussed further in the definition of the Multicast Scope
List option.
The code for this option is 8 and the minimum length is 0.
Code Len Language Tag
+-----+-----+-----+-----+-----+-...-+-----+
| 8 | n | L1 | | Ln |
+-----+-----+-----+-----+-----+-...-+-----+
3.10. Multicast Scope List
This option is sent by the server in an ACK message in response to an
GETINFO message sent by the client.
If the client did not include a Requested Language option in its
GETINFO message, the MADCAP server SHOULD return all zone names for
each zone. If the client included a Requested Language option in its
GETINFO message, the MADCAP server MUST return no more than one zone
name for each zone. For each zone, the MADCAP server SHOULD first
look for a zone name that matches the requested language tag (using a
case-insensitive ASCII comparison). If any names match, one of them
should be returned. Otherwise, the MADCAP server SHOULD choose
another zone name to return (if any are defined). It SHOULD give
preference to zone names that are marked to be used if no name is
available in a desired language.
The code for this option is 9 and the minimum length is 0.
The format of the multicast scope list option is:
Code Len Count Scope List
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 9 | p | m | L1 | | Lm |
+-----+-----+-----+-----+-----+-----+-...-+-----+
The scope list is a list of m tuples, where each tuple is of the
form:
Scope ID Last Address TTL Name Encoded Name List
Count
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
| ... ID ... | ... Last ... | T | n | EN1 | | ENn |
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+
where Scope ID is the first multicast address in the scope, Last
Address is the last multicast address in the scope, TTL is the
multicast TTL value for the multicast addresses of the scope, and
Name Count is the number of encoded names for this zone (which may be
zero). The address family of the Scope ID and Last Address is
determined by the addrfamily field in the fixed header. Note that a
particular MADCAP server may be allocating addresses out of some
subset of the scope. For instance, the addresses in the scope may be
divided among several servers in some way.
Each encoded name is of the form
Name Lang Language Tag Name Name
Flags Length Length
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
| F | q | L1 | | Lq | r | N1 | | Nr |
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
where Name Flags is a flags field with flags defined below, Lang
Length is the length of the Language Tag in octets (which MUST NOT be
zero), Language Tag is a language tag indicating the language of the
zone name (as described in [6]), Name Length is the length of the
Name in octets (which MUST NOT be zero), and Name is a UTF-8 [5]
string indicating the name given to the scope zone.
The high bit of the Name Flags field is set if the following name
should be used if no name is available in a desired language.
Otherwise, this bit is cleared. All remaining bits in the octet
SHOULD be set to zero and MUST be ignored.
The Scope IDs of entries in the list MUST be unique and the scopes
SHOULD be listed from smallest (topologically speaking) to largest.
This makes it easier to display a consistent user interface, with
scopes usually keeping the same order. However, scopes may not be
strictly nested. In this circumstance, there is no strict ordering
from smallest to largest and the server must use another technique
for ordering the scope list.
Example:
There are two scopes supported by the multicast address allocation
server: Inside abcd.com with addresses 239.192.0.0-239.195.255.255,
and world with addresses 224.0.1.0-238.255.255.255. Then this option
will be given as:
Code Len Count
+-----+-----+-----+-----+-----+...
| 9 | 51 | 2 |
+-----+-----+-----+-----+-----+...
Scope ID Last Address TTL Name Name Lang Language
Count Flags Length Tag
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
|239|192| 0 | 0 |239|195|255|255|10 | 1 | 128 | 2 | en |
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
Name
Length Name
+------+--+--+-...-+--+--+...
| 15 | Inside abcd.com |
+------+--+--+-...-+--+--+...
Scope ID Last Address TTL Name Name Lang Language
Count Flags Length Tag
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
|224| 0 | 1 | 0 |238|255|255|255|16 | 1 | 128 | 2 | en |
+---+---+---+---+---+---+---+---+---+-----+-----+------+-...-+...
Name
Length Name
+------+--...--+
| 5 | world |
+------+--...--+
3.11. List of Address Ranges
This option is used by the server to provide the list of all the
address ranges allocated to the client.
This option is also used by the client when requesting a lease for a
specific set of addresses. This feature should be needed only rarely,
such as when a lease is accidentally allowed to expire and it needs
to be reallocated.
The address family of the addresses is determined by the addrfamily
field.
The code for this option is 10 and the minimum length is 0.
Code Len Address Range List
+-----+-----+-----+-----+-----+-----+-...-+-----+
| 10 | n | L1 | L2 | | Ln |
+-----+-----+-----+-----+-----+-----+-...-+-----+
where the Address Range List is of the following format.
StartAddress1 BlockSize1 StartAddress2 BlockSize2 ...
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
| ... S1 ... |B11|B12| ... S2 ... |B21|B22| |
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
3.12. Current Time
This option is used to express what the sender thinks the current
time is. This is useful for detecting clock skew. This option MUST be
included if the Start Time or Maximum Start Time options are used, as
described in section 2.12.
The time value is an unsigned 32 bit integer in network byte order
giving the number of seconds since 00:00 UTC, 1st January 1970. This
can be converted to an NTP [4] timestamp by adding decimal
2208988800. This time format will not wrap until the year 2106.
The code for this option is 11 and the length is 4.
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 11 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.13. Feature List
This option lists optional MADCAP features supported, requested, or
required, by the sender. This option MAY be included in any message
sent by a MADCAP server or client.
Optional features of MADCAP are identified with a two octet feature
code. New MADCAP feature codes may only be defined by IETF
Consensus, as described in section 5.
The Feature List option consists of three separate lists: supported
features, requested features, and required features. Each list
consists of an unordered list of feature codes. The supported list is
used by MADCAP clients or servers to indicate the features that the
sender supports. The requested and required lists are used by MADCAP
clients to indicate which features are requested of or required from
a MADCAP server. The required list is used by MADCAP servers to
indicate which features were implemented by the MADCAP server in
processing this message. Messages sent by MADCAP servers MUST NOT
include any feature codes in the requested list.
If a MADCAP client includes the Feature List option in a message, it
MAY include features in any of the lists: supported, requested, and
required. If a MADCAP server receives a message containing the
Feature List option and it does not support all of the features in
the required list, it MUST generate and process a Required Feature
Not Supported error in the manner described in section 2.6. If the
server supports all of the features in the required list, it MUST
implement them as appropriate for this message. It SHOULD try to
implement the features in the requested list and it MAY implement any
of the features in the supported list. If an optional feature (such
as Retry After) is not included in any part of the Feature List
option included in the client's message (or if the client does not
include a Feature List option in its message), the server MUST NOT
use that feature in its response.
If a MADCAP server does respond to a client's message that includes a
Feature List option, the server MUST include a Feature List option
with a supported features list that lists the features that it
supports, a required features list that lists the features that it
implemented in responding to this message (which must be included in
the supported features list of the client's Feature List option), and
an empty requested features list.
The code for this option is 12 and the minimum length is 6.
Code Len Supported Requested Required
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 12 | n | FL1 | FL2 | FL3 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
where each of the Feature Lists is of the following format:
Feature Feature Feature
Count Code 1 Code m
+-----+-----+-----+-----+-...-+-----+-----+
| m | FC1 | | FCm |
+-----+-----+-----+-----+-...-+-----+-----+
3.14. Retry Time
The Retry Time option specifies the time at which a client should
retry a REQUEST or RENEW message when using the Retry After feature.
This option should only be sent by a MADCAP server in an ACK when
responding to a REQUEST or RENEW message that includes the Retry
After feature in the supported, requested, or required list. For more
discussion of Retry After, see section 2.13.2.
If the Retry Time option is present, the Current Time option MUST
also be present.
The time value is an unsigned 32 bit integer in network byte order
giving the number of seconds since 00:00 UTC, 1st January 1970. This
can be converted to an NTP timestamp by adding decimal 2208988800.
This time format will not wrap until the year 2106.
The code for this option is 13 and the length is 4.
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 13 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.15. Minimum Lease Time
This option is used in a client request (DISCOVER, REQUEST, or RENEW)
to allow the client to specify a minimum lease time for the multicast
address. If a server cannot meet this minimum lease time, it MUST
generate and process a Valid Request Could Not Be Completed error in
the manner described in section 2.6.
The time is in units of seconds, and is specified as a 32-bit
unsigned integer.
The code for this option is 14, and its length is 4.
Code Len Lease Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 14 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.16. Maximum Start Time
The Maximum Start Time option specifies the latest starting time that
the client is willing to accept for a multicast address lease.
A client may include this option in a DISCOVER, RENEW, or REQUEST
message to specify that it does not want to receive a lease with a
starting time later than the specified value. If a server cannot meet
this maximum start time, it MUST generate and process a Valid Request
Could Not Be Completed error in the manner described in section 2.6.
If the Maximum Start Time option is present, the Current Time option
MUST also be present, as described in section 2.12.
The time value is an unsigned 32 bit integer in network byte order
giving the number of seconds since 00:00 UTC, 1st January 1970. This
can be converted to an NTP timestamp by adding decimal 2208988800.
This time format will not wrap until the year 2106.
The code for this option is 15 and the length is 4.
Code Len Time
+-----+-----+-----+-----+-----+-----+-----+-----+
| 15 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.17. Error
A MADCAP server includes this option in a NAK message to indicate why
the request failed. A MADCAP server MUST include an Error option in
each NAK message.
The first two octets of an Error option contain a MADCAP error code.
Several MADCAP error codes are defined later in this section. New
MADCAP error codes may only be defined by IETF Consensus, as
described in section 5.
Any remaining octets in the Error option contain extra data about the
error. The format of this data depends on the error code. The
definition of a MADCAP error code must include a definition of the
extra data to be included with that error code.
A client that receives a NAK message containing an Error option MAY
log or display a message indicating the error code and extra data
received. The client MUST NOT retransmit a message once a NAK
response to that message has been received. The client MAY adjust the
message to correct the error and send the corrected message or send a
message to a different server.
The code for this option is 16, and the minimum length is 2.
Code Len Error Code Extra Data
+-----+-----+-----+-----+-----+-----+-----+-----+ ...
| 16 | n | ecode | d1 d2
+-----+-----+-----+-----+-----+-----+-----+-----+ ...
3.17.1. Valid Request Could Not Be Completed
MADCAP error code 0 indicates that the request was valid, but could
not be completed with the available addresses and the current
configuration. The extra data is a two octet option code indicating
which option caused the problem. A value of 0xFFFF indicates that the
problem was not with a specific option.
3.17.2. Invalid Request
MADCAP error code 1 indicates that the request was malformed or
invalid in some other manner. The extra data is a two octet option
code indicating which option caused the problem. A value of 0xFFFF
indicates that the problem was not with a specific option.
3.17.3. Excessive Clock Skew
MADCAP error code 2 indicates excessive clock skew (see section
2.12). The extra data consists of a four octet time value
representing the server's idea of the current time, an unsigned 32
bit integer in network byte order giving the number of seconds since
00:00 UTC, 1st January 1970. This can be converted to an NTP
timestamp by adding decimal 2208988800. This time format will not
wrap until the year 2106.
3.17.4. Lease Identifier Not Recognized
MADCAP error code 3 indicates that the Lease Identifier was not
recognized (usually in response to a RENEW or RELEASE message). There
is no extra data.
3.17.5. Required Feature Not Supported
MADCAP error code 4 indicates that at least one feature included in
the required list of the Feature List option is not supported. The
extra data contains a list of the feature codes in the required list
that are not supported.
3.17.6. Experimental Use
MADCAP error codes 1024-2047 are reserved for experimental use. The
format of the extra data included with these error codes is not
defined.
4. Security Considerations
MADCAP has relatively basic security requirements. At present there
is no way of enforcing authorized use of multicast addresses in the
multicast routing/management protocols. Therefore, it is not
possible to identify unauthorized use of multicast address by an
adversary. Moreover, a multicast address allocated to a user/system
can be used by other systems without violating terms of the multicast
address allocation. For example, a system may reserve an address to
be used for a work group session where each and every member of the
work group is allowed to transmit packets using the allocated group
address. In other words, the multicast address allocation protocol
does not dictate how the address should be used, it only dictates the
time period for which it can be used and who gets to release it or
renew it. When an address is allocated to a system/user, it basically
means that no other user/system (most likely) will be allocated that
address for the time period, without any restrictions on its use.
To protect against rogue MADCAP servers (mis-configured servers and
intentional), clients in certain situations would like to
authenticate the server. Similarly, for auditing or book-keeping
purposes, the server may want to authenticate clients. Moreover, in
some cases, the server may have certain policies in place to restrict
the number of addresses that are allocated to a system or a user.
This feature is of much value when a well behaved but naive user or
client requests a large number of addresses, and therefore,
inadvertently impacts other users or systems. Therefore, an
administrator may want to exert a limited amount of control based on
the client identification. The client identification could be based
on the system or user identity. In most practical situations, system
identification will suffice, however, particularly in case of multi-
user systems, at times, user identification will play an important
role. Therefore, authentication capabilities based on user
identification may be desirable. As usual, data integrity is a strong
requirement and if not protected, can lead to many problems including
denial of service attacks.
In the case of MADCAP, confidentiality is not a strong requirement.
In most of the cases, at least when a multicast address is in use, an
adversary will be able to determine information that was contained in
the MADCAP messages. In some cases, the users/systems may want to
protect information in the MADCAP messages so that an adversary is
not able to determine relevant information in advance and thus, plan
an attack in advance. For example, if an adversary knows in advance
(based on MADCAP messages) that a particular user has requested a
large number of address for certain time period and scope, he may be
able to guess the purpose behind such request and target an attack.
When the Shared Lease Identifier feature is used, preserving the
confidentiality of MADCAP messages becomes more important. Also,
there may be features added to the protocol in the future that may
have stronger confidentiality requirements.
The IPSEC protocol [8] meets client/server identification and
integrity protection requirements stated above, requires no
modification to the MADCAP protocol, and leverages extensive work in
IETF and industry. Therefore, when security is a strong requirement,
IPSEC SHOULD be used for protecting all the unicast messages of
MADCAP protocol. When IPSEC based security is in use, all the
multicast packets except GETINFO MUST be dropped by the MADCAP
server. The prevalent implementations of IPSEC support client
identification in form of system identification and do not support
user identification. However, when desired, IPSEC with appropriate
API's may be required to support user identification.
5. IANA Considerations
This document defines several number spaces (MADCAP options, MADCAP
message types, MADCAP Lease Identifier types, MADCAP features, and
MADCAP error codes). For all of these number spaces, certain values
are defined in this specification. New values may only be defined by
IETF Consensus, as described in [7]. Basically, this means that they
are defined by RFCs approved by the IESG.
6. Acknowledgments
The authors would like to thank Rajeev Byrisetty, Steve Deering,
Peter Ford, Mark Handley, Van Jacobson, David Oran, Thomas Pfenning,
Dave Thaler, Ramesh Vyaghrapuri and the participants of the IETF for
their assistance with this protocol.
Much of this document is based on [1] and [2]. The authors of this
document would like to express their gratitude to the authors of
these previous works. Any errors in this document are solely the
fault of the authors of this document.
7. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC2131,
March 1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC2132, March 1997.
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[4] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC1305, March 1992.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[6] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995.
[7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.
[8] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[11] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC2460, December 1998.
[13] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998.
[14] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
8. Authors' Addresses
Stephen R. Hanna
Sun Microsystems, Inc.
One Network Drive
Burlington, MA 01803
Phone: +1.781.442.0166
EMail: steve.hanna@sun.com
Baiju V. Patel
Intel Corp.
Mail Stop: AG2-201
5200 NE Elam Young Parkway
Hillsboro, OR 97124
Phone: 503 696 8192
EMail: baiju.v.patel@intel.com
Munil Shah
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425 703 3924
EMail: munils@microsoft.com
APPENDIX A: Examples
This appendix includes several examples of typical MADCAP protocol
exchanges.
1. Multicast Scope List Discovery
In this example, a MADCAP client wants to determine the scope list in
effect. The client is using IPv4, so it starts by multicasting an
GETINFO packet to the MADCAP Server Multicast Address corresponding
to IPv4 Local Scope. This packet includes the Lease Identifier
option, an Option Request List including the Multicast Scope List
option code, and a Requested Language option containing the string
"en", since the client is configured to prefer the English language.
Two MADCAP servers respond by sending ACK messages. These ACK
messages include the Lease Identifier option and xid supplied by the
client, the server's Server Identifier, and the Multicast Scope List
with one name per scope (the one that most closely matches the
language tag "en").
The following figure illustrates this exchange.
Server Client Server
v v v
| | |
| | |
| _____________/|\_____________ |
|/ GETINFO | GETINFO \|
| | |
| | |
|\ | ____________/|
| \_________ | / ACK |
| ACK \ |/ |
| \ | |
| | |
v v v
Figure 2: Timeline diagram of messages exchanged
in Multicast Scope List Discovery example
2. Multicast Discovery and Address Allocation
In this example, the MADCAP client wants to allocate a multicast
address from the global scope for use during the next two hours.
The client begins by multicasting a DISCOVER packet to the MADCAP
Server Multicast Address associated with IPv4 Local Scope. This
packet includes the Lease Time, Lease Identifier, and Multicast Scope
options.
Any servers that receive the DISCOVER packet and can satisfy this
request temporarily reserve an address for the client and unicast an
OFFER packet to the client. These packets contain the Lease Time,
Server Identifier, Lease Identifier, and Multicast Scope options.
After an appropriate delay, the client multicasts a REQUEST packet to
the MADCAP Server Multicast Address. This packet contains all of the
options included in the DISCOVER packet, but also includes the Server
Identifier option, indicating which server it has selected for the
request.
The server whose Server Identifier matches the one specified by the
client responds with an ACK packet containing the options included in
the OFFER packet, as well as a List of Address Ranges option listing
the address allocated. All the other servers that had sent OFFER
packets stop reserving an address for the client and forget about the