Multicast Address Dynamic Client Allocation Protocol (MADCAP)
Extracted elements (28)
MADCAP uses absolute times rather than relative times for leases because multicast sessions are typically advertised via SAP/SDP, which uses absolute times and may be distributed via email or web. A client with a skewed clock using relative times could advertise a session window outside the server's reserved period, causing simultaneous use of addresses by multiple sessions.
MADCAP was originally based on DHCP but is completely separate with no dependencies between the two, despite some similarities. Code sharing between DHCP and MADCAP implementations may be possible but is not assumed.
The DISCOVER/OFFER/REQUEST three-way handshake allows a client to receive competing OFFERs from multiple servers simultaneously, choose the best one, and notify unchosen servers via a multicast REQUEST containing the selected Server Identifier so they can release their temporary address reservations.
In environments using TTL scoping instead of administrative scoping, a client MUST NOT set the TTL of packets sent to an allocated address to a value greater than the maximum TTL indicated in the scope list. Administrative scope boundary routers are not present in such environments to prevent leakage.
A MADCAP client MUST NOT send any MADCAP message to the MADCAP Server Multicast Address associated with the global scope. Clients SHOULD restrict multicast messages to the IPv4 Local Scope address (or SCOP 3 for IPv6) unless otherwise configured.
A REQUEST message completing a DISCOVER transaction MUST be multicast to the same MADCAP Server Multicast Address used for DISCOVER and MUST include the Server Identifier of the selected server and the same Lease Identifier used in the DISCOVER. A standalone REQUEST MUST be unicast to the chosen server.
ACK responding to a REQUEST MUST include Lease Time, Multicast Scope, and List of Address Ranges options. ACK responding to a RELEASE MUST include only Server Identifier and Lease Identifier. NAK MUST include an Error option with an error code and MUST NOT be retransmitted.
All MADCAP clients and servers MUST recognize all options defined in this document. Unrecognized options MUST be ignored and the rest of the message processed normally. A MADCAP client MUST NOT include more than one option with the same option type in a single message.
Clients MUST use an exponential backoff retransmission strategy. The recommended algorithm starts with a 4-second delay, doubling up to 16 seconds, with at most 3 retransmissions; if no response by t+60 seconds the client stops retransmitting. Retransmitted messages MUST be identical to the original (same xid and Lease Identifier).
If a MADCAP server detects clock skew greater than [CLOCK-SKEW-ALLOWANCE] (recommended default 30 minutes), it MUST return an Excessive Clock Skew error. Servers MUST make EXTRA-ALLOCATION-TIME (recommended default 1 hour) and CLOCK-SKEW-ALLOWANCE configurable parameters.
MADCAP server MUST listen on UDP port 2535. When sending a response to a client the server MUST use a destination port matching the source port used by the client in the triggering message.
The combination of xid, msgtype, and Lease Identifier MUST be unique across all messages received by a server within [XID-REUSE-INTERVAL] (10 minutes). A server receiving a message with the same triple within [RESPONSE-CACHE-INTERVAL] MUST treat it as a retransmission and resend the cached response; RESPONSE-CACHE-INTERVAL may range from 0 to 300 seconds but values under 60 seconds are NOT RECOMMENDED.
The version field MUST be zero. Any message with a non-zero version MUST be ignored.
MADCAP defines 8 message types: DISCOVER (1), OFFER (2), REQUEST (3), RENEW (4), ACK (5), NAK (6), RELEASE (7), GETINFO (8). DISCOVER, REQUEST, RENEW, RELEASE, and GETINFO are client-only; OFFER, ACK, and NAK are server-only.
The MADCAP Server Multicast Address for each scope is the address at relative offset -1 from the last address of that scope, reserved by IANA. Clients SHOULD default to the address for IPv4 Local Scope (or SCOP 3 for IPv6) with maximum TTL of 16 when no configuration is present.
Three optional feature codes: Server Mobility (0) allows renew/release on a different server than the one that allocated; Retry After (1) lets servers defer large allocations; Shared Lease Identifier (2) allows any client knowing the Lease Identifier to modify the lease, intended for conferencing.
Two Lease Identifier types: type 0 (Random) uses at least 16 octets of random data; type 1 (Address-Specific) uses a 2-octet address family number, an address from that family, and a client-specific identifier such as a sequence number. Clients without a globally unique address SHOULD use type 0.
This document establishes IANA registries for MADCAP message type codes (values 1–8 defined; new values require IETF Consensus), option codes (values 0–16 defined; new values require IETF Consensus), feature codes (values 0–2 defined; new values require IETF Consensus), and Lease Identifier types (values 0–1 defined; new values require IETF Consensus). UDP port 2535 is assigned to MADCAP.
MADCAP security (authentication) is not effective without admission control in the multicast routing infrastructure. Without such control, authenticated allocation does not prevent unauthorized use of multicast addresses. Authentication is a prerequisite for policy enforcement such as limiting addresses per client.
When using the Shared Lease Identifier feature with MADCAP security, the confidentiality of the Lease Identifier MUST be maintained by encrypting all messages containing it. The Lease Identifier MUST include at least 8 cryptographically random octets to resist guessing attacks.
Current Time option (code 11, length 4): 32-bit unsigned integer giving seconds since 00:00 UTC 1 January 1970. MUST accompany any Start Time or Maximum Start Time option; convertible to NTP timestamp by adding 2208988800.
Lease Time option (code 1, length 4): 32-bit unsigned integer specifying lease duration in seconds. Used in client DISCOVER/REQUEST/RENEW to request a duration and in server OFFER/ACK to specify the granted duration.
List of Address Ranges option (code 10, minimum length 0): list of (StartAddress, BlockSize) pairs encoding contiguous ranges of allocated multicast addresses. Address family is determined by the addrfamily header field.
MADCAP fixed header: version (1 octet, always 0), msgtype (1 octet), addrfamily (2 octets, IANA address family number), xid (4 octets, transaction ID). Options field follows as variable-length TLV list. All multi-octet quantities are in network byte order. Messages shorter than 12 bytes MUST be ignored.
Multicast Scope List option (code 9): variable-length list of scope tuples each containing Scope ID (first multicast address), Last Address, TTL, Name Count, and encoded names. Each encoded name includes a Name Flags octet, RFC 1766 Language Tag, and a UTF-8 zone name string.
Number of Addresses Requested option (code 7, length 4): two 16-bit unsigned integers (minimum, desired). The minimum MUST be less than or equal to desired; violation triggers an Invalid Request error. Servers MUST allocate between minimum and desired addresses in their response.
Options are encoded as a 2-octet option code followed by a 2-octet option length, followed by the specified number of octets. The options field MUST end with the End option (code 0, length 0). Any message whose options field does not conform to this syntax MUST be ignored.
Server Identifier option (code 2, minimum length 3): 2-octet IANA address family number followed by the server's IP address. MUST be included in all server-originated messages and in multicast REQUEST messages from clients to indicate which OFFER was accepted.