RFC 2730
Multicast Address Dynamic Client Allocation Protocol (MADCAP)
1. Introduction 🧚
okay so bestie, this doc is the MADCAP spec, which is short for Multicast Address Dynamic Client Allocation Protocol 🦋 It came out in December 1999 as a Standards Track doc, and the authors are S. Hanna (Sun Microsystems, Inc.), B. Patel (Intel Corp.), and M. Shah (Microsoft Corp.). Since it's Standards Track, it's built to be implemented, not just vibed about. The title block doesn't list anything it obsoletes or updates, so no drama there 💅
Status of this Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🫶
Copyright Notice 🌸
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract 🎀
This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. It's basically the "may I please have an address" protocol 🙈
1. Introduction 🧚
Multicast Address Dynamic Client Allocation Protocol (MADCAP) is a protocol that lets hosts ask multicast address allocation servers for address allocation services. This protocol is part of the Multicast Address Allocation Architecture that the IETF Multicast Address Allocation Working Group is defining. However, it may be used separately from the rest of that architecture, as appropriate. Main character energy, no cap 👑
1.1. Terminology 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [9].
Constants used by this protocol are shown as [NAME-OF-CONSTANT], and summarized in Appendix B.
1.2. Definitions 📚
okay so this section defines a bunch of terms that might be new to you. Some of them are defined here, and for others it points you to other docs.
MADCAP client or client A host requesting multicast address allocation services via MADCAP.
MADCAP server or server A host providing multicast address allocation services via MADCAP.
Multicast IP Multicast, as defined in [11] and modified in [12].
Multicast Address An IP multicast address or group address, as defined in [11] and [13]. An identifier for a group of nodes.
Multicast Scope A range of multicast addresses configured so that traffic sent to these addresses is limited to some subset of the internetwork. See [3] and [13].
Scope ID The lowest numbered address in a multicast scope. This definition applies only within this document.
Scope Zone One multicast scope may have several instances, which are known as Scope Zones or zones, for short.
For instance, an organization may have multiple sites. Each site might have its own site-local Scope Zone, and each of those would be an instance of the site-local Scope. However, a given interface on a given host would only ever be in at most one instance of a given scope. Messages sent by a host in a site-local Scope Zones to an address in the site-local Scope would be limited to the site-local Scope Zone containing the host. zones within zones, it's giving organized 🧚
Zone Name A human readable name for a Scope Zone. An ISO 10646 character string with an RFC 1766 [6] language tag. One zone may have several zone names, each in a different language. For instance, a zone for use within IBM's locations in Switzerland might have the names "IBM Suisse", "IBM Switzerland", "IBM Schweiz", and "IBM Svizzera" with language tags "fr", "en", "de", and "it". the multilingual flex is real 🌈
Multicast Scope List A list of multicast scope zones.
Since it can be hard to figure out which multicast scope zones are in effect, MADCAP clients can ask MADCAP servers to supply a Multicast Scope List that lists all of the zones available to the client. For each scope zone, the list includes the range of multicast addresses for this scope, a maximum TTL or hop count to be used for this scope, and one or more zone names for this scope zone.
This definition applies only within this document.
1.3. Motivation and Protocol Requirements 🦋
For multicast applications to be deployed everywhere, we need a protocol that any host can use to allocate multicast addresses. Here are the requirements for such a protocol, and they're lowkey a whole vibe:
Quick response: The host should be able to allocate a multicast address and begin to use it promptly. ⚡
Low network load: Hosts that are not allocating or deallocating multicast addresses at the present time should not need to send or receive any network traffic. 🌙
Support for intermittently connected or power managed systems: Hosts should be able to be disconnected from the network, powered off, or otherwise inaccessible except during the brief period during which they are allocating a multicast address. 🔋
Multicast address scopes: The protocol must be able to allocate both the administratively scoped and globally scoped multicast addresses. 🌍
Efficient use of address space: The multicast address space is fairly small. The protocol should make efficient use of this scarce resource. 🍓
Authentication: Because multicast addresses are scarce, it is important to protect against hoarding of these addresses. One way to do this is by authenticating clients. This is also a key prerequisite for establishing policies. 🔐
Policy neutral: Allocation policies (such as who can allocate addresses) should not be dictated by the protocol. 🫶
Conferencing support: When allocating an address for use in a conferencing environment, members of the conference should be able to modify a multicast address lease used for the conference. 🎙️
1.4. Relationship with DHCP 🧚
MADCAP was originally based on DHCP. There are still some similarities, and it may be possible to share some code between a DHCP implementation and a MADCAP implementation. However, MADCAP is completely separate from DHCP, with no dependencies between the two and many significant differences. not the same protocol, bestie 🙅♀️
1.5. Protocol Overview 🌸
MADCAP is built on a client-server model, where hosts request address allocation services from address allocation servers. When a MADCAP client wants to request a service, it unicasts or multicasts a message to one or more MADCAP servers, and each of those optionally responds with a message unicast to the client.
All messages are UDP datagrams. The UDP data contains a fixed length header and a variable length options field. Options are encoded in a type-length-value format with two octets type and value fields. The fixed fields are version, msgtype (message type), addrfamily (address family), and xid (transaction identifier).
Retransmission is handled by the client. If a client sends a message and does not receive a response, it may retransmit its request a few times using an exponential backoff. To avoid executing the same client request twice when a retransmitted request is received, servers cache responses for a short period of time and resend cached responses upon receiving retransmitted requests. caching so it doesn't do the same thing twice, iconic 💅
Each request contains a msgtype, an xid, and a Lease Identifier option. Clients must ensure that this triple is probably unique across all MADCAP messages received by a MADCAP server over a period of [XID-REUSE-INTERVAL] (10 minutes). This allows the MADCAP server to use this triple as the key in its response cache. the triple is the cache key, so keep it unique 🔑
Messages sent by servers include the xid included in the original request so that clients can match up responses with requests. 🎀
The msgtype field is a single octet that defines the "type" of a MADCAP message. Currently defined message types are listed in Table 2. They are: DISCOVER, OFFER, REQUEST, RENEW, ACK, NAK, RELEASE, and GETINFO. DISCOVER, REQUEST, RENEW, RELEASE, and GETINFO messages are only sent by a client. OFFER, ACK, and NAK messages are only sent by a server.
The REQUEST, RENEW, and RELEASE messages are used to request, renew, or release a lease on one or more multicast addresses. A client unicasts one of these messages to a server, and the server responds with an ACK or a NAK. 📨
The GETINFO message is used to request information, such as the multicast scope list, or to find MADCAP servers. A client may unicast a GETINFO message to a MADCAP server. However, it may not know the IP address of any MADCAP server. In that case, it will multicast a GETINFO message to a MADCAP Server Multicast Address, and all servers that wish to respond will send a unicast ACK or NAK back to the client. the find-a-server move 🔍
Each multicast scope has an associated MADCAP Server Multicast Address. This address has been reserved by the IANA as the address with a relative offset of -1 from the last address of a multicast scope. MADCAP clients use this address to find MADCAP servers. 🧭
The DISCOVER message is used to discover MADCAP servers that can probably satisfy a REQUEST. DISCOVER messages are always multicast. Servers that can probably satisfy a REQUEST corresponding to the parameters supplied in the DISCOVER message temporarily reserve the addresses needed and send a unicast OFFER back to the client. The client selects a server to continue with and sends a multicast REQUEST including the server's Server Identifier to the same multicast address used for the DISCOVER. The chosen server responds with an ACK or NAK, and the other servers stop reserving the addresses they were temporarily holding. the group chat decides who gets the address 🫣
For detailed descriptions of typical protocol exchanges, consult Appendix A. 📖
MADCAP is a mechanism rather than a policy. MADCAP allows local system administrators to exercise control over configuration parameters where desired. For example, MADCAP servers may be configured to limit the number of multicast addresses allocated to a single client. Properly enforcing such a limit requires cryptographic security, as described in the Security Consideration section. 🔒
MADCAP requests from a single host may be sent on behalf of different applications with different needs and requirements. MADCAP servers MUST NOT assume that because one request from a MADCAP client supports a particular optional feature (like Retry After), future requests from that client will also support that optional feature.
the servers can't assume the client's next request is just as capable as the last one. Don't get too comfy, bestie 🙈
2. Protocol Description 🦋
The MADCAP protocol is a client-server protocol. In general, the client unicasts or multicasts a message to one or more servers, which optionally respond with messages unicast to the client.
A reserved port number dedicated for MADCAP is used on the server (port number 2535, as assigned by IANA). Any port number may be used on client machines. When a MADCAP server sends a message to a MADCAP client, it MUST use a destination port number that matches the source port number provided by the client in the message that caused the server to send its message. 🎯
The next few sections describe the MADCAP message format and message types. A full list of MADCAP options is provided in section 3. ✨
2.1. Message Format ✨
okay so here's the shape of a MADCAP message 🎀 Figure 1 shows the layout, and Table 1 breaks down every field. The numbers in parentheses are how many octets each field takes up. We'll use these field names all the way through, so bookmark them 🔖
All multi-octet quantities are in network byte-order. 🌐
Any message whose UDP data is too short to hold this format (at least 12 bytes) MUST be ignored. 💀 no tiny messages allowed, bestie
+-+-+-+-+-+-+-+-+
| version (1) |
+---------------+
| msgtype (1) |
+---------------+
| addrfamily |
| (2) |
+---------------+
| |
| xid (4) |
| |
| |
+---------------+
| |
| options |
| (variable) |
| ... |
+---------------+Figure 1: Format of a MADCAP message
FIELD OCTETS DESCRIPTION
----- ------ -----------
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 ID
options var Options fieldTable 1: Description of fields in a MADCAP message
2.1.1. The version field
The version field must always be zero for this version of the protocol. 🙅 Any messages that include other values in this field MUST be ignored. bye bye, wrong version 👋
2.1.2. The msgtype field
The msgtype field defines the "type" of the MADCAP message. 📬
For more information about this field, see section 2.2. 💁
2.1.3. The addrfamily field
The addrfamily field sets the default address family (like IPv4 or IPv6) for this MADCAP message, using the address family numbers defined in by the IANA (including those defined in [10]). 🌍 Unless otherwise specified, every address in the message comes from this family.
2.1.4. The xid field
The xid field is a transaction identifier. 🪪 This number MUST be chosen by the client so that the combination of xid, msgtype, and Lease Identifier is unique across all MADCAP messages received by a MADCAP server over a period of [XID-REUSE-INTERVAL] (10 minutes). it's giving uniqueness, no duplicates allowed 💅
The xid field is how the client and server match up messages and their responses 🫶 Before a client sends a message, it picks a number to use as an xid. The technique for picking one is implementation-dependent, but whatever technique is used MUST make it unlikely that the same combination of xid, msgtype, and Lease Identifier will be used for two different messages within [XID-REUSE-INTERVAL] (even across multiple clients which do not communicate among themselves). That gives enough time for the message to be dropped from all server response caches (as described in the next few paragraphs) and for any network delays to be accommodated. ⏳
The RECOMMENDED technique for choosing an xid is to pick a random four octet number as the first xid in a session, then increment it each time a new xid is needed. ✨ The random number doesn't need to be cryptographically random. It can be chosen via any suitable technique, such as the one described in section A.6 of RFC 1889 [14].
When a server responds to a client message, it MUST use the same xid value in the response that the client used in the request. 🎯 This lets the client connect each response to the message it's answering.
When retransmitting messages (as described in section 2.3), the client MUST retransmit them without changing them, so they keep the same xid and Lease Identifier. 🔁 no edits on the replay, periodt
If a server receives a message with the same xid, msgtype, and Lease Identifier as one received within [RESPONSE-CACHE-INTERVAL], it MUST treat this message as a retransmission of the previously received one and retransmit the response, if any. 👀 After [RESPONSE-CACHE-INTERVAL], the server may forget about the previously received message and treat any retransmissions of this message as brand-new messages. Of course, a server doesn't need to cache a message if it ends up ignoring it. However, performance gains may be achieved by doing so. 🚀
This stops retransmissions from causing multiple allocations, since requests are not idempotent. 🙅♀️ An appropriate value for [RESPONSE-CACHE-INTERVAL] would be sixty seconds, but it can be anything from zero seconds to 300 seconds (five minutes), and it may be adjusted dynamically according to resource constraints on the server. ⚖️ However, using a value less than sixty seconds is NOT RECOMMENDED, because sixty seconds is the normal client retransmission period. 🙈
2.1.5. The options field
The options field is a list of tagged parameters called "options". 🏷️ Every option has a two octet option code and a two octet option length, followed by as many octets as the option length says. For some options the length field is a constant, but it still has to be specified. 🧾
The option field MUST contain a sequence of options, with the last one being the End option (option code 0). Any message whose options field doesn't follow this syntax MUST be ignored. 🚫
Any MADCAP client or server sending a MADCAP message MAY include any of the options listed in section 3, subject to the restrictions in Table 5 and elsewhere in this document. They MAY also include other MADCAP options that are defined in the future. 🔮 A MADCAP client or server MUST NOT include more than one option with the same option type in one MADCAP message. one per type, no doubles 💖
All MADCAP clients and servers MUST recognize all options listed in this document and behave in accordance with this document when receiving and processing any of them. Any unrecognized options MUST be ignored, and the rest of the message gets processed as if the unknown options weren't there. 🫥 If a MADCAP server gets a message that doesn't conform to this document's requirements (for instance, one missing required options), an Invalid Request error MUST be generated and processed the way section 2.6 describes. ❌ If a MADCAP client gets a message that doesn't conform to this document's requirements, it MUST ignore the message.
The order of options within a message has no significance, and any order MUST be supported in an equivalent manner. The only exception is the End option, which must occur once per message, as the last option in the option field. 🏁
New MADCAP option codes may only be defined by IETF Consensus, as described in section 5. 🗳️ gatekeeping, but make it fashion 👑
2.2. Message Types
The msgtype field defines the "type" of a MADCAP message. 🦋 The legal values for this field are:
Value Message Type
----- ------------
1 DISCOVER
2 OFFER
3 REQUEST
4 RENEW
5 ACK
6 NAK
7 RELEASE
8 GETINFOTable 2: MADCAP message types
Throughout this document, MADCAP messages get called by their type. For example, a MADCAP message with a message type of 8 is called a GETINFO message. 🏷️ Here are the descriptions of each type. Table 5, at the beginning of section 3, sums up which options are allowed with each message type. 📋
MADCAP clients and servers MUST handle all MADCAP message types defined in this document in a manner consistent with this document. 💯
If a MADCAP server receives a message whose message type it doesn't recognize, an Invalid Request error MUST be generated and processed the way section 2.6 describes. If a MADCAP client receives a message whose message type it doesn't recognize, it MUST ignore the message. 🙃
Note, however, that in some situations this document requires or suggests that clients or servers ignore messages with certain message types, even if they're recognized. For instance, clients that don't send DISCOVER messages SHOULD ignore OFFER messages. Also, secure servers SHOULD ignore DISCOVER messages, and all servers SHOULD ignore DISCOVER messages they can't satisfy. 🙈 plot twist energy
New MADCAP message types may only be defined by IETF Consensus, as described in section 5. 🗳️
2.2.1. GETINFO
The GETINFO message is how a MADCAP client asks for configuration parameters, especially a multicast scope list. ✨ It also lets a client figure out which servers are likely to handle its future requests. 🔍
The MADCAP client sends out a GETINFO message. It can be unicast to a particular MADCAP server, or multicast to the MADCAP Server Multicast Address. For more details about that address, see section 2.10. 📮
If a server receives a GETINFO message and can process the request successfully, it MUST unicast an ACK message to the client. 💌 Every GETINFO message MUST include an Option Request List option. The server SHOULD try to include the specified options in its response, but it isn't required to do so (especially if it doesn't recognize them). 🤷♀️
If a server receives a GETINFO message and doesn't process the request successfully, it MUST generate and process an error the way section 2.6 describes. 🥲
If a client sends a GETINFO message and doesn't get any ACK messages back, it SHOULD resend its GETINFO message, as described in section 2.3. 🔄
When a MADCAP client sends a GETINFO message, it MAY include the Requested Language option, which says which language the client would prefer for the zone names in the Multicast Scope List. 🌸 How to handle that tag for zone names is covered in the definition of the Multicast Scope List option. 📖
2.2.2. DISCOVER 🔍
okay so DISCOVER is the multicast message a MADCAP client sends when it's shopping around for MADCAP servers that can probably satisfy a REQUEST 💅 basically the client going "hey everyone, who's got addresses for me?" ✨
MADCAP clients are not required to use DISCOVER, bestie. They MAY find servers other ways, like sending a multicast GETINFO message, caching an IP address that worked in the past, or being configured with an IP address. But DISCOVER is iconic because it lets the client hear back from every server that can satisfy the request 🫶
The client starts by multicasting a DISCOVER message to a MADCAP Server Multicast Address. Any servers that want to help respond with a unicast OFFER message back to the client. If a server can only manage a shorter lease time or a later start time than the client asked for, it SHOULD send an OFFER with the lease time or start time it can actually offer. BUT it MUST NOT offer a lease time shorter than the minimum lease time the client specified, or a start time later than the maximum start time the client specified. Boundaries, periodt 🙅
For more details about the MADCAP Server Multicast Address, see section 2.10.
If the client sends a DISCOVER and gets no OFFERs back, it SHOULD retransmit its DISCOVER message, as described in section 2.3. 🔁
If the client sends a DISCOVER and gets one or more OFFERs, it SHOULD select the server it wants to use (if any) and multicast a REQUEST message identifying that server within [DISCOVER-DELAY] after receiving the first OFFER message. See section 2.2.4 for more info about the REQUEST message 🎀
How the client picks its server is implementation dependent 🌈 It MAY take the first acceptable response, or it MAY wait some period of time (no more than [DISCOVER-DELAY]) and choose the best response it got in that window. Like, if the first one has a smaller lease time than requested, maybe wait for a better one 🧐
The value of [DISCOVER-DELAY] is also implementation dependent, but the RECOMMENDED value is the current retransmit timer, as specified in section 2.3. Now here's the tea ☕ waiting too long (approaching [OFFER-HOLD]) may cause servers to drop the addresses they reserved for you. Don't be that client 🙈
When a MADCAP client sends a DISCOVER message, it MAY include the 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. But it doesn't need to include any of them. If one of these options is missing, the server fills in the default: maximum available for Lease Time, no minimum for Minimum Lease Time, as soon as possible for Start Time, no maximum for Maximum Start Time, one for Number of Addresses Requested, and any addresses available for List of Address Ranges. The Multicast Scope option MUST be included in the DISCOVER message so the server knows what scope to use. The Current Time option MUST be included if the Start Time or Maximum Start Time options are included. The Lease Identifier option MUST always be included 💜
2.2.3. OFFER 🎁
The OFFER message is a unicast message sent by a MADCAP server in response to a DISCOVER message that it can probably satisfy ✨
A MADCAP server is never required to send an OFFER in response to a DISCOVER. Maybe it can't satisfy the client's request, or it was configured to only respond to certain types of DISCOVER messages, or it doesn't respond to DISCOVERs at all. Totally valid 💁
If a MADCAP server decides to send an OFFER, it MUST include the Lease Time and Multicast Scope options, describing the addresses it is willing to provide. It doesn't need to include the List of Address Ranges option though. If the List of Address Ranges Allocated option is not included, it's assumed the server is willing to provide the number of addresses the client requested. If the Start Time option is not included, it's assumed the server is willing to provide the start time the client requested (if any). The Current Time option MUST be included if the Start Time option is included 🕰️
If a server can process the request with a shorter lease time or later start time than the client requested, it SHOULD send an OFFER with the lease time or start time it can offer. BUT it MUST NOT offer a lease time shorter than the minimum lease time the client specified, or a start time later than the maximum start time the client specified. Same boundaries as always, bestie 🙅
If the server sends an OFFER, it SHOULD try to hold enough addresses to complete the transaction 🔒 If it receives a multicast REQUEST message with the same Lease Identifier option as the DISCOVER message it's holding these addresses for, AND a Server Identifier option that doesn't match its own, it SHOULD stop holding the addresses. The server SHOULD also stop holding the addresses after an appropriate delay [OFFER-HOLD] if the transaction isn't 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 the xid field included in the client request this message is responding to. The Lease Identifier option MUST be included, with the value matching the one in the client request. The Server Identifier option MUST be included, with the value being the server's IP address. And the packet MUST NOT be retransmitted 🚫
2.2.4. REQUEST 📦
The REQUEST message is used by a MADCAP client that wants to allocate one or more multicast addresses. It is not used for renewing an existing lease. The RENEW message is used for that 🔄
If a REQUEST message is completing a transaction initiated by a DISCOVER message, the following procedure MUST be followed so that all MADCAP servers know which server was selected 📣 The client MUST multicast the REQUEST message to the same MADCAP Server Multicast Address the DISCOVER message was sent to. The same Lease Identifier used in the DISCOVER message MUST be used in the REQUEST message. Also, the Server Identifier option MUST be included, using the Server Identifier of the server selected.
If a REQUEST message is not completing a transaction initiated by a DISCOVER message, the REQUEST message MUST be unicast to the MADCAP server the client wants to use. In this case, the Server Identifier option MAY be included, but it doesn't have to be.
If the selected server can process the request successfully, it SHOULD unicast an ACK message to the client. Otherwise, it SHOULD 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 or later start time than the client requested, it SHOULD send an ACK with the lease time or start time it can offer. BUT it MUST NOT offer a lease time shorter than the minimum lease time the client specified, or a start time later than the maximum start time the client specified 💅
When a MADCAP client sends a REQUEST message, it MAY include the 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. It doesn't need to include any of them. If one of these options is missing, the server fills in the default: maximum available for Lease Time, no minimum for Minimum Lease Time, as soon as possible for Start Time, no maximum for Maximum Start Time, one for Number of Addresses Requested, and any addresses available for List of Address Ranges. The Multicast Scope option MUST be included in the REQUEST message so the server knows what scope to use. The Current Time option MUST be included if the Start Time or Maximum Start Time options are included 🕒
If a client sends a REQUEST message and gets no ACK or NAK back, it SHOULD resend its REQUEST message, as described in section 2.3 🔁
If the server responds with a NAK, or doesn't respond within a reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the client MAY try to find another server. It can do that by sending a DISCOVER message with another xid, or by sending a REQUEST message with another xid to another server. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 seconds ⏰
2.2.5. ACK 🥰
The ACK message is used by a MADCAP server to respond affirmatively to a GETINFO, REQUEST, or RELEASE message. The server unicasts the ACK message to the client that sent the message it's responding to 💌
The set of options included with an ACK message depends on what sort of message it's responding to 👀
If the ACK message is responding to a GETINFO message, it SHOULD include any options the client requested using the Option Request List option.
If the ACK message is responding to a REQUEST message, it MUST include the Lease Time, Multicast Scope, and List of Address Ranges options. It 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 option is included, the lease is assumed to start immediately ⚡
If the ACK message is responding to a RENEW message, it MUST include the Lease Time, Multicast Scope, and List of Address Ranges options. It 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 option is included, the lease is assumed to start immediately 🌸
If the ACK message is responding to a RELEASE message, it MUST only include the Server Identifier and Lease Identifier options 🫡
As with all messages sent by the server, the xid field MUST match the xid field included in the client request this message is responding to. The Lease Identifier option MUST be included, with the value matching the one in the client request. The Server Identifier option MUST be included, with the value being the server's IP address. And the packet MUST NOT be retransmitted 🚫
2.2.6. NAK 🙅♀️
The NAK message is used by a MADCAP server to respond negatively to a message. The server unicasts the NAK message to the client that sent the message it's responding to 💔
As with all messages sent by the server, the xid field MUST match the xid field included in the client request this message is responding to. The Lease Identifier option MUST be included, with the value matching the one in the client request. The Server Identifier option MUST be included, with the value being the server's IP address. The Error option MUST be included with an error code indicating what went wrong. And the packet MUST NOT be retransmitted 🚫
2.2.7. RENEW 🔁
okay so RENEW is the message a MADCAP client sends when it wants to renew a multicast address lease, and it can change the lease time or the start time 🦋
The client unicasts the RENEW message to a MADCAP server. If the server can process the request successfully, it SHOULD unicast an ACK message back to the client. Otherwise, it MUST generate and process an error in the manner described in section 2.6. 💅
The lease being renewed is whichever one was allocated with a Lease Identifier option that matches the one in the RENEW message. Main character energy, the lease knows who it is 👑
When a MADCAP client sends a RENEW message, it MAY include the Lease Time, Minimum Lease Time, Start Time, and Maximum Start Time options to describe the new lease it wants. But it doesn't have to include any of them 🫶 If one isn't included, the server fills in the default: the maximum available for Lease Time, no minimum for Minimum Lease Time, as soon as possible for Start Time, and no maximum for Maximum Start Time. The Current Time option MUST be included if the Start Time or Maximum Start Time options are included. No skipping that one, bestie 🙈
If a client sends a RENEW message and doesn't get any ACK or NAK back, the client SHOULD resend its RENEW message, as described in section 2.3. Patience is a virtue 🌸
If the server responds with a NAK, or doesn't respond within a reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the client MAY send a RENEW message with another xid to another server. This only works if the Server Mobility feature was used in the original REQUEST message AND this feature is required for the RENEW message going to the other server. For more on Server Mobility, see section 2.13.1. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 seconds ⏰
2.2.8. RELEASE 🎀
The RELEASE message is what a MADCAP client sends when it wants to give back one or more multicast addresses before the lease expires. Bye bye, addresses 👋
The client unicasts the RELEASE message to the MADCAP server it got the addresses from. If that server can process the request successfully, it MUST unicast an ACK message to the client. Otherwise, it MUST generate and process an error in the manner described in section 2.6. Firm, no cap 💀
The lease being released is whichever one was allocated with a Lease Identifier option matching the one in the RELEASE message. You can't release just some of the addresses in a single lease. It's all or nothing, babe 🚫
If a client sends a RELEASE message and doesn't get any ACK or NAK back, the client SHOULD resend its RELEASE message, as described in section 2.3. ✨
If the server responds with a NAK, or doesn't respond within a reasonable (implementation-dependent) delay [NO-RESPONSE-DELAY], the client MAY send a RELEASE message with another xid to another server. Same deal as RENEW: this only applies if the Server Mobility feature was used in the original REQUEST message AND the feature is required for the RELEASE message going to the new server. For more on Server Mobility, see section 2.13.1. The RECOMMENDED value for [NO-RESPONSE-DELAY] is 60 seconds 🌈
2.3. Retransmission 🔄
MADCAP clients are responsible for ALL the message retransmission (yes, the server isn't doing it for you, periodt 💅). The client MUST adopt a retransmission strategy that uses an exponential backoff algorithm to decide the delay between retransmissions. The delay SHOULD be chosen to leave enough time for the server's replies to actually arrive, based on the characteristics of the internetwork between the client and the server. It's giving patience with a plan 🧚
The RECOMMENDED algorithm is: wait 4 seconds before the first retransmission, then double that delay for each retry after it, with a maximum delay of 16 seconds and a maximum of three retransmissions. So if the first transmission went out at time t (in seconds) and nothing came back, the next sends happen at t+4, t+12, and t+28. If there's still no response by t+60, the client stops retransmitting and goes to plan B, like logging an error or sending a message to another address 🥲
The client MAY show the user some indication of retransmission attempts so they can see the process is still going 🍓 The client MAY also halt retransmission at any point. You're the boss of your own retries 👑
2.4. The Lease Identifier ✨
The Lease Identifier option is included in each MADCAP message. Its value identifies a lease, and it MUST be unique across all leases requested by all clients in a multicast address allocation domain. Unique is the whole vibe 💜
The first octet of the Lease Identifier is the Lease Identifier type. Table 3 lists the Lease Identifier types defined so far, and sections 2.4.1 and 2.4.2 describe them. New MADCAP Lease Identifier types may only be defined by IETF Consensus, as described in section 5. Gatekeeping, but make it a process 🙃
Lease Identifier Type Name
--------------------- ----
0 Random Lease Identifier
1 Address-Specific Lease Identifier
Table 3: MADCAP Lease Identifier TypesThe MADCAP server doesn't need to parse the Lease Identifier. It SHOULD only use the Lease Identifier as an opaque identifier, which must be unique for each lease. Why define different types, you ask? It lets MADCAP clients that already have a globally unique address avoid Lease Identifier collisions by combining that address with a client-specific identifier. MADCAP clients that DON'T have a globally unique address SHOULD use Lease Identifier type 0. Clean 🫶
The Lease Identifier also helps match RENEW or RELEASE requests to the right lease, on top of tying client and server messages together (along with the msgtype and xid fields, which the next section covers). MADCAP servers SHOULD match the Lease Identifier in a RENEW or RELEASE message against the one used in the initial REQUEST message. If they don't match, a MADCAP server MUST generate and process a Lease Identifier Not Recognized error in the manner described in section 2.6. Not the right lease, sis 🚨
For conferencing apps, it may be desirable to let conference participants modify a lease used for the conference. That's what the Shared Lease Identifier feature code is for 🎤 If the client asked for this feature code and the server implemented it when the lease was allocated, the server SHOULD disable any authentication requirements and let any client that knows the Lease Identifier modify the lease. Group project energy 🌈
As described in the Security Considerations section, MADCAP security isn't terribly useful without admission control in the multicast routing infrastructure. Still, if you want MADCAP security while using the Shared Lease Identifier feature, the confidentiality of the Lease Identifier MUST be maintained by encrypting every message that contains it. In this case, a Lease Identifier that includes a long cryptographically random number (at least eight octets in length) MUST be used, so it isn't easy to guess 🔐 Don't make it guessable, bestie 😭
2.4.1. Random Lease Identifier 🎲
The first octet of a Random Lease Identifier is the Lease Identifier type (0, to indicate a Random Lease Identifier). After that comes a sequence of octets, which SHOULD represent a long random number (at least 16 octets) from a decent random number generator. Randomness is a lifestyle 🦋
A Random Lease Identifier doesn't include any indication of its length. It's assumed that the length can be figured out by external means, like a length field before the Lease Identifier.
Lease ID
Type Random Number
+---------+-------------...
| 0 |
+---------+-------------...2.4.2. Address-Specific Lease Identifier 📍
The first octet of an Address-Specific Lease Identifier is the Lease Identifier type (1, to indicate an Address-Specific Lease Identifier). After that comes a two octet IANA-defined address family number (including those defined in [10]), an address from the specified address family, and a client-specific identifier (such as a sequence number or the current time). Layers on layers, iconic 🧁
An Address-Specific Lease Identifier doesn't include any indication of its length either. Again, it's assumed the length can be determined by external means, like a length field before the Lease Identifier 🫠
Lease ID Address Family Address Client-specific
Type Number Identifier
+---------+---------+---------+-----...-----+-----...-----+
| 1 | addrfamily | address | cli-spec id |
+---------+---------+---------+-----...-----+-----...-----+2.5. Associating Client and Server Messages 🤝
Messages between clients and servers get matched up using the Lease Identifier and the xid field. As described in section 2.1.4, the client MUST choose an xid so that the same combination of xid, msgtype, and Lease Identifier is unlikely to be used for two different messages within [XID-REUSE-INTERVAL] (even across multiple clients that don't talk to each other). The Lease Identifier option, msgtype, and xid field MUST be included in every message the client or the server sends. Triple check those fields, babe 👀
The client MUST check the Lease Identifier option and xid field in each incoming message to make sure they match the Lease Identifier and xid of an outstanding transaction. If they don't, the message MUST be ignored. 🙅♀️ The server MUST check the Lease Identifier option and xid field in each incoming message to figure out the right context for the message. If a server can't process a message because it's invalid for its context, the server MUST generate and process an Invalid Request error, as described in section 2.6.
A transaction can be any of these:
- an attempt to allocate a multicast address (DISCOVER, OFFER, REQUEST, ACK, and NAK messages),
- an attempt to renew a lease (RENEW, ACK, and NAK messages),
- an attempt to release a previously allocated multicast address (RELEASE, ACK, and NAK messages), or
- an attempt to acquire configuration parameters (GETINFO, ACK, and NAK messages).
Four flavours of transaction, all needing the same care 🍰
2.6. Processing Errors 🚨
If a MADCAP server hits an error while processing a message, there are two ways to handle it. If it's clear the message is not a NAK, the server SHOULD respond with a NAK containing the appropriate Error option. However, the server MAY decide to totally ignore chronic offenders 😤 If the message is a NAK, or it isn't clear whether it's a NAK (say, the message is garbled or has an incorrect version number), the server SHOULD ignore the message. This avoids NAK loops, so nobody gets stuck in an endless argument 🔁💖
If a MADCAP client hits an error while processing a message, it MUST ignore the message. Simple as that 🌸
2.7. Multicast Scopes ✨
okay so RFC 2365 [3] is the one that lets us slice the multicast address space into a bunch of administrative scopes 🗺️💅 Routers should be configured so that each scope lines up with a particular, separate chunk of the network 🌈 Like, messages sent to a multicast address inside an admin scope should only reach hosts that joined that group and live in the same region as the sender 😭 So packets to an organization-local address only go to hosts in that same organization that joined the group. iconic, right? 🎀
Different sets of scopes can be in effect in different places and at different times 🕰️ Before a MADCAP client tries to grab an address from an administrative scope (global and link-level scope are always in effect, so they don't count), it SHOULD check that the scope is actually in effect where it is right now 👀 A few ways a client can figure out its scope list (the set of scopes in effect) are manual configuration, or configuration via MADCAP using the Multicast Scope List option ✨
If a MADCAP client can't figure out its scope list with any of those techniques, it MAY temporarily assume a scope list with just a single scope 🧚 If it's using IPv4, it SHOULD use IPv4 Local Scope (239.255.0.0/16), with a maximum TTL of 16. If it's using IPv6, it SHOULD use SCOP 3, with a maximum hop count of 16. With that temporary scope list, it MAY try to contact a MADCAP server that can give it a real scope list 💖
Now the important bit 🫶 When a MADCAP client requests an address with a DISCOVER or REQUEST message, it MUST specify the administrative scope the address should be allocated from. That scope is indicated with the Multicast Scope option. Likewise, the server MUST include the Multicast Scope option in all OFFER messages and all ACK messages sent in response to REQUEST messages 🔥
2.8. Multicast TTL 🦋
Another way to limit how far multicast messages travel is TTL scoping 💅 It has several disadvantages compared to administratively scoped multicast addresses (as described in [3]), but it's still in widespread usage rn, so we gotta know about it 😭
With TTL scoping, areas of the network are designated as scopes 🌸 Routers on the edges of these areas get configured with TTL thresholds, so multicast packets aren't forwarded unless their remaining TTL is bigger than that threshold. A packet that should be restricted to a given TTL scope needs an initial TTL less than that scope's TTL threshold. Similar techniques can be used with IPv6, except it uses the Hop Count field instead of the TTL field 🧚
MADCAP can be used in an environment where administrative scoping isn't in use but TTL scoping is 🌈 In that case, a MADCAP server MAY return a scope list that includes scopes with TTLs less than 255. The MADCAP client MAY then allocate addresses from those scopes, but it MUST NOT set the TTL field of any packet sent to such an address to a value greater than the maximum TTL indicated in the scope list 🙈 In that kind of environment, it is recommended that the MADCAP Server Multicast Addresses associated with the IPv4 Local Scope (or SCOP 3 for IPv6) get configured with TTL thresholds, so packets sent to those addresses with a TTL of 16 don't go outside an appropriate boundary. That way, MADCAP clients can use their default behavior for finding MADCAP servers ✨
In an environment where administrative scoping is in use, the maximum TTLs in the scope list SHOULD be 255 💅 The admin scope zone boundary routers will stop MADCAP packets from leaking beyond appropriate limits 🛡️
2.9. Locating MADCAP Servers 🔍
There are several ways for a MADCAP client to find a MADCAP server 🗝️ For instance, the client might be configured with an IP address.
The RECOMMENDED technique is for the client to send a GETINFO message to a MADCAP Server Multicast Address and then wait for ACK responses 💖 We'll get into this a bit more in the next section 🎀
2.10. MADCAP Server Multicast Address 💜
Each multicast scope has an associated MADCAP Server Multicast Address 🫧 IANA reserved this address as the one with a relative offset of -1 from the last address of a multicast scope. Literally a tiny detail that makes everything work 😭
A MADCAP client looking for servers that can provide multicast allocation services MAY send a GETINFO message to a MADCAP Server Multicast Address 📣 Any MADCAP servers listening on this address SHOULD respond with a unicast ACK message to the client if they want to offer a response 💌
The MADCAP Server Multicast Address a client uses MAY be set by configuration 🍓 If a client has no such configuration, it SHOULD use the MADCAP Server Multicast Address associated with IPv4 Local Scope (or SCOP 3 for IPv6), with a maximum TTL of 16, unless otherwise configured 🌸
2.11. Going Beyond the Local Scope 🚀
If a client gets no response to a message sent to a MADCAP Server Multicast Address (even after retransmission), it MAY send the message to a larger scope and repeat this process as necessary. Still, the client MUST NOT send a MADCAP message to the MADCAP Server Multicast Address associated with the global scope 🙅♀️
This technique lets MADCAP servers provide services for scopes they don't actually live in. But it's a dangerous and complicated technique, so it is NOT RECOMMENDED at this time ⚠️ So MADCAP clients SHOULD only send multicast messages to the MADCAP Server Multicast Address for IPv4 Local Scope (or SCOP 3 if using IPv6), unless they're configured otherwise 🔥
MADCAP servers that want to provide services for scopes they don't reside in MUST make special efforts to make sure their services meet clients' needs for largely conflict-free allocation and accurate scope list information. Coordinating with other servers that serve that scope can be tricky, and figuring out which scope the client is in can be tricky too 😵💫
If a MADCAP server isn't prepared to serve scopes it doesn't reside in, it SHOULD ignore DISCOVER and REQUEST messages whose scope doesn't match or enclose the scope of the MADCAP Server Multicast Address the request came in on 🙅♀️ It SHOULD also ignore GETINFO messages that aren't 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 (like the Start Time option). It MAY be included in any DISCOVER, OFFER, REQUEST, RENEW, or ACK message 🎀
Clock skew is when two systems have clocks that aren't synchronized 🙃 Lots of protocols (like DHCP) ignore clock skew by using relative times. MADCAP could use a similar technique, but that leads to nasty situations because of the way multicast addresses get used 💀
Let's walk through an example 🧁 Say at 1 PM UTC, a client whose clock is one hour fast requests a lease for one hour starting in one hour. If MADCAP used relative times, 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 fine. The client would start using the lease in one hour and keep going for one hour. That would line up with the time the server reserved (although the client would think it was 3 to 4 PM UTC) 🥹
But multicast addresses usually get 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 it just leased. SDP uses absolute times, since it might get 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 that interval. Since the server only reserved the address from 2 to 3 PM UTC, the address could end up being used for multiple sessions at the same time 💥
MADCAP can't solve every clock skew problem 🙅♀️ That's the domain of NTP [4]. What MADCAP does do is try to detect substantial clock skew between MADCAP clients and servers, so the skew doesn't cause massive collisions in multicast address usage later on 🛟
The Current Time option holds 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 when the receiver processes the option. Still, a difference greater than a minute or two probably indicates clock skew between the sender and the receiver 👀
MADCAP servers SHOULD expect and tolerate a small amount of clock skew with their clients by making sure multicast addresses are allocated for an extra period of time [EXTRA-ALLOCATION-TIME] on either side of the lease given to the client 🫧 Large amounts of clock skew need special handling though. The value of [EXTRA-ALLOCATION-TIME] MUST be a configurable parameter, since local circumstances may vary 🎛️ The RECOMMENDED default is one hour ⭐
Large amounts of clock skew cause problems later on when sessions get 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, check out 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 explain 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 Codes2.13.1. Server Mobility ✨
Okay so Server Mobility lets an address that was allocated on one MADCAP server get renewed or released on a totally different MADCAP server 🧚. That takes real teamwork between the MADCAP servers, bestie. The big perks are being immune to one MADCAP server failing and maybe better performance through load balancing 💅.
To use Server Mobility, the MADCAP client has to make sure the feature is implemented by both the server used for the original allocation and the server used for the renewal or release 🫶. The best way to lock that in is to put Server Mobility in the required list of a Feature List option on the REQUEST message used to allocate the address (and on the DISCOVER message too, if one is used). When it's time to renew or release, the client SHOULD send a unicast RENEW or RELEASE message to the server it got the address from. But if that server is unavailable, the client MAY send the RENEW or RELEASE to any other server that lists Server Mobility in its list of supported features 🦋. To find one, the client can (for instance) send a GETINFO message with an Option Request List option that includes the Feature List option code 🔍.
If the client doesn't want to require this feature when allocating addresses, it may include the feature in the requested list of a Feature List option and then check whether the server puts the feature in the required list of a Feature List option in the ACK message 👀.
Even if Server Mobility is used, there's no guarantee a server will be available to do the renewal or release, or that the renewal or release will succeed. Server connectivity may have failed, for instance 💀.
2.13.2. Retry After 🍓
Retry After lets a MADCAP server ask the client to retry its request later. This comes up when allocating large numbers of addresses or allocating addresses for a long period of time 🌸.
For instance, if a client requests 1000 addresses, administrative approval may be required, or more addresses may need to come from another MASC domain. That can take several hours or several days 😭. If the client and server both support Retry After, the 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 client includes Retry After in the supported list of a Feature List option in a REQUEST message, a server that supports Retry After MAY decide to begin a lengthy allocation process. In this case, the server will include an empty List of Address Ranges option in its ACK message, a Feature List option that includes Retry After 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 Retry After 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. Not your call, bestie 🙅.
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 Retry After 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 a RELEASE message to the server performing the allocation (or to another server if Server Mobility is also in effect), with the Lease Identifier included in the original REQUEST message 🛑.
Retry After may also be used when renewing a lease. In that 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 currently undergoing allocation with Retry After 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 currently undergoing allocation with Retry After 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 Retry After may complicate the application API 🤓. For this reason, a MADCAP client may request Retry After 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 apps, it can be super useful to let conference participants modify a lease used for the conference. The Shared Lease Identifier feature code is how that gets done 🎤.
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 that wants the Shared Lease Identifier feature should include it 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 cannot 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 it 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 ✨
okay so every MADCAP message has an options field, right? 🎀 it's a list of tagged parameters, and each one is called an "option". every option starts with a two octet option code and a two octet option length, followed by however many octets that length says. that's the whole vibe 💅
this section defines a set of option codes for MADCAP messages. new options can be defined using the process in section 5, and the options are listed in numerical order 🌸
Table 5 is basically the cheat sheet for which options are allowed with each message type 📋 it's giving organized chaos but make it readable 🦋
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 messages3.1. End
the End option marks where the valid information in the options field stops 🛑 it MUST be included at the end of the options field in each MADCAP message, no exceptions bestie 🫶
the code for this option is 0, and its length is 0 ✨
Code Len
+-----+-----+-----+-----+
| 0 | 0 |
+-----+-----+-----+-----+3.2. Lease Time
this one is for asking for (or offering) a lease time on the multicast address ⏰ a client uses it in a DISCOVER, REQUEST, or RENEW to request a lease time. then the MADCAP server uses it in an OFFER or ACK to say how long it's willing to give 💜
the time is in seconds, stored 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 carries the IP address of a MADCAP server 🖥️✨ first comes a two octet address family number (as defined by IANA, including those defined in [10]), and then the address itself. the address family here is NOT set by the addrfamily field in the fixed header, so addresses from one family can be allocated while you're talking to a server over an address from a different family. it's lowkey genius 🧚
every message a MADCAP server sends MUST include a Server Identifier option with the IP address of the server that's sending it 👑
MADCAP clients MUST include a Server Identifier option in multicast REQUEST messages so the server knows which OFFER message got 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
clients use this option to give a unique lease identifier 🔑 for more on what it's for and how it works, check section 2.4 (you know the drill 🙈)
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 how a client asks for a scope in a DISCOVER or REQUEST 🌐 and it's also how the MADCAP server says what scope an assigned address belongs to 🦋
the client can get the scope list from the Multicast Scope List option, or some other way. the Scope ID is the first multicast address in the scope, and its address family is set 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
a MADCAP client uses this option in a GETINFO message to ask that certain options show up in the server's ACK response 📝 the server SHOULD try to include the options you asked for, but it's not required to do so, so don't be shook if it skips one 🙈
the format is just 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 sets the starting time for a multicast address lease 🕰️💫
a client can put this in a DISCOVER, RENEW, or REQUEST to ask for an address that's going to be used later 🔮 and a server can include it in an OFFER, or in an ACK answering a REQUEST or RENEW, to say that the lease was granted but starts in the future 🌅
if the Start Time option is there, the IP Address Lease Time option gives the length of the lease, counting from the Start Time 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, counting the seconds since 00:00 UTC, 1st January 1970 🌍 you can turn it into an NTP timestamp by adding decimal 2208988800 ✨ and this format won't wrap until the year 2106, so we're set for a while 🥹💖
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 ✨
okay so this option is how the client says "hey, here's the minimum number of addresses I need, and here's how many I'd love to get" 💖 It only shows up in DISCOVER and REQUEST messages, and only the client ever sends it 🎀
The minimum and desired numbers are unsigned 16 bit integers in network byte order. The minimum MUST be less than or equal to the desired number. If a message comes in where that isn't true, the MADCAP server MUST generate and process an Invalid Request error the way section 2.6 describes 💅
The client MAY obtain more than one address. It can either repeat the protocol once for every address, or ask for several at the same time with this option 🦋 When the client only wants one address, this option SHOULD NOT be included. A MADCAP server that gets a DISCOVER or REQUEST with 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 is how the MADCAP client says which language it would like strings, like zone names, to come back in 🌸 It only goes in a GETINFO message sent by the client. The value is an RFC 1766 [6] language tag, and the proper way to handle that tag for zone names is covered in the Multicast Scope List option, so keep an eye out for it 👀
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 one is sent by the server in an ACK message, in response to a GETINFO message from the client 💜
Here's the vibe check on what comes back. If the client did NOT include a Requested Language option, the MADCAP server SHOULD return all zone names for each zone. If the client DID include one, the MADCAP server MUST return no more than one zone name for each zone. For each zone, the 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 |
+---+--...--+---+---+--...--+---+-----+-----+-----+-...-+-----+Okay so the Scope ID is the first multicast address in the scope, and the Last Address is the last one. 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 can be zero, no cap) 🔥 The address family of the Scope ID and Last Address comes from the addrfamily field in the fixed header. Also, a particular MADCAP server might only be allocating addresses out of some subset of the scope. For example, the addresses in the scope could be split up among several servers in some way 🙈
Each encoded name looks like this:
Name Lang Language Tag Name Name
Flags Length Length
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+
| F | q | L1 | | Lq | r | N1 | | Nr |
+-----+-----+-----+-...-+-----+-----+-----+-...-+-----+Name Flags is a flags field, with the flags defined below. Lang Length is the length of the Language Tag in octets, and it MUST NOT be zero. Language Tag is a language tag saying what language the zone name is in (as described in [6]). Name Length is the length of the Name in octets, and it MUST NOT be zero too. Name is a UTF-8 [5] string with the name given to the scope zone ✨
The high bit of the Name Flags field is set if the following name should be used when no name is available in a desired language. Otherwise, that bit is cleared. All the 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 way easier to display a consistent user interface, with scopes usually keeping the same order. However, scopes may not be strictly nested. When that happens, there's no strict ordering from smallest to largest, and the server must use another technique for ordering the scope list 💅
Example time! 📣 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 🦋
the server uses this option to send over the list of every address range that's been allocated to the client 🧚 The client can also use it when it wants a lease for a specific set of addresses. That should only be needed rarely, like when a lease accidentally expires and needs to be reallocated 🥺
The address family of the addresses is decided 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 follows this format:
StartAddress1 BlockSize1 StartAddress2 BlockSize2 ...
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+
| ... S1 ... |B11|B12| ... S2 ... |B21|B22| |
+---+---+---+---+---+---+---+---+---+---+---+---+--...--+3.12. Current Time ⏰
this option is how the sender shares what it thinks the current time is 🕰️ It's super useful for spotting 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. It counts the seconds since 00:00 UTC, 1st January 1970. You can turn it into an NTP [4] timestamp by adding the decimal number 2208988800. Also, this time format won't wrap until the year 2106, so we're basically set 🌟
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 the optional MADCAP features that the sender supports, requests, or requires 👑 This option MAY be included in any message sent by a MADCAP server or client 🌈
Optional MADCAP features 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 has three separate lists: supported features, requested features, and required features. Each list is an unordered list of feature codes. The supported list is used by MADCAP clients or servers to show which features the sender supports. The requested and required lists are used by MADCAP clients to show which features they want from a MADCAP server or need from it. The required list is used by MADCAP servers to show which features the server implemented while 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 with the Feature List option and it doesn't support all of the features in the required list, it MUST generate and process a Required Feature Not Supported error the way section 2.6 describes. 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) isn't included in any part of the Feature List option in the client's message (or if the client doesn't include a Feature List option at all), 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. That option has a supported features list with the features the server supports, a required features list with the features it implemented while responding to this message (these must also be 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 follows this format:
Feature Feature Feature
Count Code 1 Code m
+-----+-----+-----+-----+-...-+-----+-----+
| m | FC1 | | FCm |
+-----+-----+-----+-----+-...-+-----+-----+3.14. Retry Time ⏰
okay so the Retry Time option tells the client when it should try its REQUEST or RENEW message again 🔁 It's part of the Retry After feature, bestie.
This option should only be sent by a MADCAP server in an ACK, and only when it's responding to a REQUEST or RENEW that has the Retry After feature in the supported, requested, or required list. If you want the full tea on Retry After, check out section 2.13.2 💅
If the Retry Time option is present, the Current Time option MUST also be present. No skipping it! 🫶
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. Want it as an NTP timestamp? Just add decimal 2208988800 ✨ This time format won't wrap until the year 2106, so we're sooo covered 🌈
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 one lets a client in a request (DISCOVER, REQUEST, or RENEW) say "hey, I need a minimum lease time for the multicast address" 🦋 It's giving "I'm not settling for less."
If a server can't meet that minimum lease time, it MUST generate and process a Valid Request Could Not Be Completed error, the way section 2.6 describes 🙈
The time is in units of seconds, and it's 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 is the client's "latest I'm willing to wait" card. It's the latest starting time the client will accept for a multicast address lease 🌸
A client can put this option in a DISCOVER, RENEW, or REQUEST message to say "don't give me a lease that starts later than this." If the server can't meet that maximum start time, it MUST generate and process a Valid Request Could Not Be Completed error, same as section 2.6 says 💀
If the Maximum Start Time option is present, the Current Time option MUST also be present, as described in section 2.12. Again, no ghosting the Current Time option 😭
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. Add decimal 2208988800 to get an NTP timestamp, and this format won't 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 puts this option in a NAK message to explain why the request failed. Every single NAK MUST include an Error option, no exceptions 🙅♀️
The first two octets of an Error option hold a MADCAP error code. Several of those are defined later in this section. New MADCAP error codes may only be defined by IETF Consensus, as described in section 5. Gatekeeping, but make it fashion 👑
Any leftover octets in the Error option hold extra data about the error. What that data looks like depends on the error code, and whoever defines a MADCAP error code MUST also define the extra data that goes with it 📝
A client that gets a NAK with an Error option MAY log or display the error code and extra data it received. The client MUST NOT retransmit a message once it's received a NAK response to that message, so no spamming, babe 🚫 The client MAY adjust the message to fix the error and send the corrected version, or send the 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 means the request was valid, but it couldn't be completed with the addresses available and the current configuration. The extra data is a two octet option code naming the option that caused the problem. A value of 0xFFFF means the problem wasn't with a specific option 🤷♀️
3.17.2. Invalid Request 🙃
MADCAP error code 1 means the request was malformed or invalid in some other way. The extra data is a two octet option code naming the option that caused the problem. A value of 0xFFFF means the problem wasn't with a specific option 💅
3.17.3. Excessive Clock Skew 🕰️
MADCAP error code 2 means there's excessive clock skew (see section 2.12) 😬 The extra data is a four octet time value, which is the server's idea of the current time. It's an unsigned 32 bit integer in network byte order, giving the number of seconds since 00:00 UTC, 1st January 1970. Add decimal 2208988800 to turn it into an NTP timestamp, and this time format won't wrap until the year 2106 ⭐
3.17.4. Lease Identifier Not Recognized 🔍
MADCAP error code 3 means the Lease Identifier wasn't recognized. This usually shows up in response to a RENEW or RELEASE message. There's no extra data 🫠
3.17.5. Required Feature Not Supported 🚫
MADCAP error code 4 means at least one feature in the required list of the Feature List option isn't supported. The extra data is a list of the feature codes from the required list that aren't supported 📋
3.17.6. Experimental Use 🧪
MADCAP error codes 1024-2047 are reserved for experimental use. The format of the extra data for these error codes isn't defined 🌈
4. Security Considerations 🔐
okay bestie, MADCAP has relatively basic security requirements, and I'm not going to pretend otherwise 💀 Right now there's no way to enforce authorized use of multicast addresses in the multicast routing and management protocols. So it's not possible to spot unauthorized use of a multicast address by an adversary. Even worse, a multicast address allocated to one user or system can be used by other systems without breaking the terms of the allocation 😭 For example, a system might reserve an address for a work group session where every member is allowed to send packets to that group address. In other words, the multicast address allocation protocol doesn't dictate how the address gets used. It only dictates the time period it can be used for, and who gets to release or renew it. When an address is allocated to a system or user, it basically means nobody else (most likely) will be given that address for that time period, with no restrictions on how it's used 🦋
To protect against rogue MADCAP servers (both mis-configured and intentional ones), clients in certain situations would like to authenticate the server 🛡️ Similarly, for auditing or book-keeping, the server may want to authenticate clients. The server may also have policies in place to limit how many addresses get allocated to a system or user. This is super valuable when a well behaved but naive user or client requests a huge number of addresses and accidentally impacts other users or systems 🙈 So an administrator may want to exert a limited amount of control based on client identification. That identification could be based on the system or the user. In most practical situations, system identification will do the job, but on multi-user systems, user identification can play an important role at times. So authentication capabilities based on user identification may be desirable. As always, data integrity is a strong requirement, and if it isn't protected, it can lead to lots of problems, including denial of service attacks 💥
In the case of MADCAP, confidentiality isn't a strong requirement. In most cases, at least when a multicast address is in use, an adversary will be able to figure out information contained in the MADCAP messages 👀 In some cases, users or systems may want to protect information in the MADCAP messages so an adversary can't learn relevant details in advance and plan an attack. For example, if an adversary knows in advance (based on MADCAP messages) that a particular user has requested a large number of addresses for a certain time period and scope, they may be able to guess the purpose behind that request and target an attack 🎯 When the Shared Lease Identifier feature is used, keeping MADCAP messages confidential becomes more important. Also, features may be added to the protocol in the future that have stronger confidentiality requirements 🔮
The IPSEC protocol [8] meets the client/server identification and integrity protection requirements stated above, requires no modification to the MADCAP protocol, and leverages extensive work in the IETF and industry 🙌 So when security is a strong requirement, IPSEC SHOULD be used to protect all the unicast messages of the MADCAP protocol. When IPSEC-based security is in use, the MADCAP server MUST drop all multicast packets except GETINFO 🚫 The prevalent IPSEC implementations support client identification in the form of system identification, but they don't support user identification. However, when it's 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, that means they're 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 help with this protocol 💜
Much of this document is based on [1] and [2]. The authors want to express their gratitude to the authors of those earlier works. Any errors in this document are solely the fault of the authors of this document 🙈
7. References 📚
okay bestie, here's the reading list the whole spec is built on 🧚 every one of these is cited by number, so they're all listed exactly as written 💅
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, 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", RFC 1305, 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, RFC 2434, October 1998.
[8] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[10] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 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", RFC 2460, December 1998.
[13] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, 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 🎀
and here are the authors, so you know who to thank (or blame) 🫶
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.comAPPENDIX A: Examples 🦋
this appendix is the fun part, bestie 🧚 it has a few examples of typical MADCAP protocol exchanges, so you can actually see the messages flying around ✨
1. Multicast Scope List Discovery 🔍
okay so in this one, a MADCAP client wants to figure out what scope list is in effect 👀 the client is using IPv4, so it starts by multicasting a GETINFO packet to the MADCAP Server Multicast Address for IPv4 Local Scope 📡 this packet has the Lease Identifier option, an Option Request List that includes the Multicast Scope List option code, and a Requested Language option holding the string "en", since the client is set up to prefer English 🇬🇧
two MADCAP servers reply with ACK messages 💌 these include the Lease Identifier option and the xid the client supplied, 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") 🌸
here's the exchange, visualized 💖
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 example2. Multicast Discovery and Address Allocation 🌈
in this one, the MADCAP client wants to allocate a multicast address from the global scope for the next two hours ⏰
the client kicks things off by multicasting a DISCOVER packet to the MADCAP Server Multicast Address associated with IPv4 Local Scope 📣 this packet has the Lease Time, Lease Identifier, and Multicast Scope options
any servers that get the DISCOVER packet and can satisfy the request temporarily reserve an address for the client, then unicast an OFFER packet back 💕 those 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 has all the options from the DISCOVER packet, plus the Server Identifier option, which says which server the client picked 🧁
the server whose Server Identifier matches the one in the REQUEST replies with an ACK packet. it carries the options from the OFFER packet, plus a List of Address Ranges option listing the address that was allocated 🎉 all the other servers that sent OFFER packets stop reserving an address for the client and forget the whole exchange 🫠
the client now has a two hour "lease" on the multicast address 👑
and if the client never got an ACK, it would keep retransmitting its REQUEST packet for a while 🥺 if it still got no response, it would start over with a fresh DISCOVER message 🔁
here's the exchange, visualized 💖
Server Client Server
(not selected) (selected)
v v v
| | |
|Begin multicast address request|
| | |
| _____________/|\_____________ |
|/ DISCOVER | DISCOVER \|
| | |
Reserves | Reserves
Address | Address
| | |
|\ | ____________/|
| \_________ | / OFFER |
| OFFER \ |/ |
| \ | |
| Collects replies |
| \| |
| Selects Server |
| | |
| _____________/|\_____________ |
|/ REQUEST | REQUEST \|
| | |
| | Commits address
| | |
| | _____________/|
| |/ ACK |
| | |
| assignment complete |
| | |
v v v
Figure 3: Timeline diagram of messages exchanged
in Multicast Address Allocation example3. Lease Extension ⏳
this picks up right where the last example left off ✨ the client already grabbed a multicast address from the global scope for the next two hours. halfway through, it decides it wants another hour, so it asks to extend its lease 🥹
the client unicasts a RENEW packet to the server it got the address from 📨 this packet has the Lease Time and Lease Identifier options. the Lease Identifier matches the one from the original allocation. the Lease Time is two hours, since the client wants the lease to expire two hours from now 🕑
the server replies with an ACK packet saying the extension was granted 🥳 this packet has the Lease Time, Server Identifier, Lease Identifier, Multicast Scope, and List of Address Ranges options
if the server didn't want to grant the extension, it would reply with a NAK packet carrying the Lease Identifier option 🙅♀️
here's the exchange, visualized 💖
Client Server
v v
| |
|\_____________ |
| RENEW \|
| |
| Extends lease
| |
| _____________/|
|/ ACK |
| |
| |
v v
Figure 4: Timeline diagram of messages exchanged
in Lease Extension example4. Address Release 🦋
last one, and it's a continuation too 🎀 the client already has the multicast address and extended its lease for another two hours. half an hour later, it's done using the address and wants to release it so someone else can use it 🫶
the client unicasts a RELEASE packet to the server it got the address from 📬 this packet has the Lease Identifier option, which matches the original allocation. when the server gets it, it cancels the client's lease on the address and sends an ACK packet back to say the lease has been released 🌷 that packet has the Server Identifier and Lease Identifier options
here's the exchange, visualized 💖
Client Server
v v
| |
|\_____________ |
| RELEASE \|
| |
| Cancels lease
| |
| _____________/|
|/ ACK |
| |
v v
Figure 5: Timeline diagram of messages exchanged
in Address Release exampleThis is a continuation of the previous example 💖 At some later time, the client decides to allocate another multicast address. Since it has recently worked with a server, it tries sending a unicast REQUEST to that server first 🦋. If this doesn't work, it can always try a multicast DISCOVER, as illustrated in example 2 ✨
The client unicasts a REQUEST packet to the server it wants to allocate the address from 📮. This packet includes the Lease Time, Lease Identifier, and Multicast Scope options 🎀
The server responds with an ACK packet containing the Lease Time, Lease Identifier, and Multicast Scope options from the REQUEST packet 💅. It also includes the Server Identifier option and a List of Address Ranges option listing the address allocated 🫶
The client now has a lease on the multicast address 🌸✨
If the client had not received an ACK from the server, it would have retransmitted its REQUEST packet for a while 😭. If it still got no response, it would start over with a multicast DISCOVER message 💀
Here's the exchange, drawn out 👇
Client Server
v v
| |
|\_____________ |
| REQUEST \|
| |
| Allocates address
| |
| _____________/|
|/ ACK |
| |
v v
Figure 6: Timeline diagram of messages exchanged
in Unicast Address Allocation exampleAPPENDIX B: Recommended Constant Values 🧚
Table 6 is the cheat sheet 📝 It lists recommended values for constants defined in this specification 💜
Constant Name Recommended Value
------------- -----------------
[CLOCK-SKEW-ALLOWANCE] 30 minutes
[DISCOVER-DELAY] current retransmit delay
[EXTRA-ALLOCATION-TIME] 1 hour
[NO-RESPONSE-DELAY] 60 seconds
[OFFER-HOLD] at least 60 seconds
[RESPONSE-CACHE-INTERVAL] at least 60 seconds (5 minutes maximum)
[XID-REUSE-INTERVAL] 10 minutes (required)
Table 6: Recommended Constant ValuesFull Copyright Statement 🔥
Copyright (C) The Internet Society (1999). All Rights Reserved. 🌈
Okay, legal bit, but it's important 🫶 This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with implementing it, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works 📚 However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's required to translate it into languages other than English 🌍
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️✨
This document and the information in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💅
Acknowledgement 🎀
Funding for the RFC Editor function is currently provided by the Internet Society 💖
📦 where this page comes from
- ietf: rfc2730 1999-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms