lispers.net

San Jose CA USA farinacci@gmail.com

Futurewei

Santa Clara CA USA mmcbride7@gmail.com

This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). GAAP requires no centralized service or coordination for the address-allocation protocol itself, though it depends on ASM-capable multicast routing already being provisioned in the deployment domain, and deployments using encryption or administrative scoping may require additional configuration. The protocol runs among group participants which need a unique group address to send and receive multicast packets. Tailored for IPv4 and IPv6 networks, this design offers a simple, lightweight option rather than extending an existing protocol. This document is Experimental, see for the rationale and the criteria for concluding the experiment.

The Group Address Allocation Protocol (GAAP) is a decentralized multicast protocol used by participating applications which send and receive packets to/from a multicast group. The protocol is relatively lightweight, running with minimized messaging and state, making it feasible even in constrained environments. GAAP is a possible solution to the issues described in . This document specifies an Experimental protocol, see for why, and for the scope of the experiment. Other approaches to multicast group allocation have been proposed in the past; they include SAP , SDP , mDNS , MADCAP , MASC , and IPv6 Allocation Guidelines . However, depending on the specific mechanism, these approaches can require global scope (adding latency), explicit configuration, reliance on a single subnet, or a centralized or semi-centralized service; not every limitation applies to every mechanism listed. This document will describe the protocol operation, protocol message formats, the API definition, and how multicast applications use the API.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. a host, process, or library instance running the GAAP protocol on behalf of one or more local applications. Multiple local applications on the same GAAP node may share a single GAAP node's claiming state for a group name, per . is a UTF-8 string used by applications so they can rendezvous on the same group address. The application is started using this group name parameter. Applications can use multiple group names if they have requirements to use multiple group addresses. is an IPv4 multicast group address not from the Local Network Control Block unless explicitly assigned for GAAP protocol operation, or an IPv6 multicast group address . The application allocation range is a range set aside for expansion of the IPv4 Organization-Local scope and a sub-range of the IPv6 Experimental Use range ; see . is an IANA assigned group address the GAAP protocol itself sends Claim messages to (see , "GAAP Protocol Multicast Addresses"). This is distinct from the GAAP Multicast Group Allocation Range that applications derive their own group addresses from (see ); the GAAP Group Address MUST NOT be allocated from that range. is a cryptographic hash function which takes an octet sequence as input and produces a hash value as output. The GAAP protocol uses SHA-256 . There are 4 hashed values regarded as "acceptable" for a group name. They are calculated using the SHA-256 hash function on 1 of 4 character strings: "<group-name>", "<group-name>+1", "<group-name>+2", or "<group-name>+3". See for the exact hash input construction and for the resulting Hashed Value. These 4 hashes are the only candidate group addresses a GAAP node will ever try for a given group name; a GAAP node MUST NOT run the hash on any other strings for this group name. See also for the behavior when all 4 candidate addresses collide, including the case where two distinct group names produce the same candidate string (for example, a group name that itself ends in "+1"): this is handled by the normal collision procedure like any other hash collision. the output of the SHA-256 hash function on one of the 4 character strings in the Acceptable Group Hash List above, further defined in . The Hashed Value is used to produce a network layer multicast group address that is unique among the group names in use. This network-layer uniqueness is what GAAP's collision detection targets; it is a separate goal from avoiding Layer-2 MAC aliasing, which depends on the address family (23 bits for IPv4 , 32 bits for IPv6 ) and is not itself guaranteed by GAAP for IPv4. a network layer group address where one group address allocated by GAAP is the same as another group address allocated by GAAP for a different group name (the low-order 32 bits for IPv6, or the bits available within the assigned GAAP IPv4 allocation range for IPv4). See the Hashed Value definition above regarding the separate Layer-2 MAC aliasing concern. a GAAP protocol message that allocates a unique group address and claims it among other GAAP nodes on the network.

This section will describe the high-level functionality of the GAAP protocol. Each application runs the GAAP protocol by using the API defined in . An application is started with a group name. The group name is used to create a random allocated group address. A timestamp is taken when the group address is created. A Claim message, see , is sent with group name, group address, and timestamp to determine if the group address has been claimed by any other GAAP nodes. The GAAP node waits one periodic Claim interval (see , roughly 1 minute) after sending its initial Claim message. If no colliding Claim message is received from another GAAP node within that window, the application can start using the group address. If a colliding Claim message is sent in response within that window, a collision has occurred and the GAAP node MUST allocate another group address and send a Claim message for the new group address. Claim messages are sent periodically. They are sent by a single node using a delay-timer suppression mechanism similar to IGMPv2 report suppression . See for details. GAAP nodes are not required to cache information from Claim messages. GAAP is designed to be decentralized and stateless. The nodes that participate in the GAAP protocol are responsible for allocating and claiming group addresses. No other entities are needed.

At this time, there is a single defined message called the Claim message with Type value 1. Type value 0 is reserved. A receiver that does not recognize the Type value MUST discard the message without further processing. Claim messages are sent to the GAAP Group Address (see ), a well-known multicast address allocated by IANA (see ), distinct from the addresses GAAP allocates for applications. When an IPv6 GAAP Group Address is used, implementations MUST use an admin-local or organization-local IPv6 scope (not link-local scope) for that address, so that Claim messages can be forwarded beyond a single link when the deployment requires it (see for the specific address requested). The Claim message is sent in a UDP checksummed packet where the source port is chosen by the sender and the destination port is a well-known port allocated by IANA specifically for GAAP (see ). GAAP can work behind firewall devices as long as the GAAP destination port is permitted through filters. IPv4 NAT does not translate or forward multicast traffic in any standard way. If a deployment nonetheless places address or port-translating middleboxes on the path, the source-address-dependent mechanisms in this document (Timestamp tie-breaking in this section, and the bad-actor list in ) are not expected to function correctly across that path. A sender MUST NOT send a Claim message whose total UDP payload exceeds 1232 octets, so that it fits within the 1280-octet IPv6 minimum MTU without fragmentation, accounting for typical IPv6/UDP header overhead. A node with more (group name, group address) pairs to claim than fit in one message sends them across successive Claim messages, each within the limit. This bounds the number of records per message well below the maximum Record Count of 255 when Group Names are long. A sender SHOULD keep a multi-record Claim message small enough to avoid IP fragmentation on the path more generally, per . The UDP checksum MUST be enabled and verified. A receiver MUST discard, without further processing, any packet whose UDP payload length (as reported by the UDP header) exceeds 1232 octets. A receiver MUST also validate the Marker before further processing a packet that is within that length, discarding malformed packets as described below.

Claim Message uses value 1; value 0 is reserved. See for the GAAP Message Types registry governing the remaining values. Per above, an unrecognized Type value causes the message to be discarded before the Marker is examined. MUST be set to zero by the sender and ignored by the receiver. The number of records in this Claim message. See "Record field descriptions" below for the maximum permitted value and malformed-message handling. The fixed bit pattern 0xAAAAAAAA. When a Claim message is not encrypted, the sender sets this field to 0xAAAAAAAA in cleartext. When encryption is in use, this field is encrypted along with the rest of the record data (see ), so it will not equal 0xAAAAAAAA on the wire. A receiver that has verified the Type value (above) checks the Marker: if it equals 0xAAAAAAAA, the packet is an unencrypted Claim message: a receiver with no shared key configured processes it, and a receiver with a shared key configured MUST drop it (see ); if it does not, and the receiver has a shared key configured, the receiver attempts decryption of the record data. If that decryption, or the resulting decrypted Marker, does not produce a well-formed result, or the receiver has no shared key configured, the message MUST be dropped. This single check does not by itself distinguish a wrong key, a mismatched encryption mechanism between sender and receiver, and a mutated packet, from one another; all three are handled identically (the packet is dropped). The Type, Reserved and Record Count fields are always sent in cleartext, whether or not encryption is in use. The Marker, together with every Record (the IPv4 and IPv6 Multicast Group Address, Timestamp and Group Name fields), forms the record data that is encrypted as a unit when encryption is in use. This document does not define the structure of that encrypted record data, such as the placement or size of any authentication tag or how a receiver locates the boundary between ciphertext and any trailing tag, because GAAP does not mandate a specific encryption mechanism (see ). Deployments enabling encryption MUST agree out of band on that structure in addition to the key and algorithm already required to be agreed out of band. The 1232-octet UDP payload limit applies to the total packet, encrypted or not, including any authentication tag. The fields below (IPv4 Multicast Group Address, IPv6 Multicast Group Address, Timestamp and Group Name) are the only fields present in a record. The paragraphs that follow the list explain how those fields are used and compared and are not themselves additional fields. a 32-bit multicast address in network byte order . If all bits are set to 0, there is no IPv4 address being allocated and claimed. a 128-bit multicast address in network byte order . If all bits are set to 0, there is no IPv6 address being allocated and claimed. A 32-bit unsigned integer counting seconds since the Unix epoch, 1970-01-01T00:00:00Z, in the sender's clock, ignoring leap seconds. The timestamp is intended to provide a relative ordering between competing claims rather than represent absolute time. A variable length group name the multicast application uses, encoded as UTF-8 . The string is terminated with a null character; a valid UTF-8 encoding never contains a null octet as part of a multi-octet character, so this delimiter remains unambiguous. Since the Group Name is variable length, subsequent records may not occur on a long- or short-word boundary. The string MUST NOT exceed 255 octets in length (not including the null terminator). Address field usage: The IPv4 and IPv6 address fields are fixed length (4 bytes and 16 bytes) and their positions in the message are well known. Either or both address fields may be populated, consistent with the group address types being claimed. If only one address type is used, the unused address field MUST be set to 0 by the sender and ignored by the receiver. If both address fields are set to 0, the message is invalid and MUST be discarded. Timestamp comparison: Timestamps are compared using serial number arithmetic so that a single wraparound of the 32-bit counter (in the year 2106) does not by itself cause incorrect ordering. If, under that comparison, two Timestamps for a Collided Group Address are equal, or are neither less than nor greater than one another (the case noted in Section 3.2 of , reachable here as a difference of exactly 2^31 seconds), the tie is broken by the lower value of the IPv4 or IPv6 source address (as applicable) of the Claim message; the node with the lower source address wins the collision. A Timestamp of 0 is treated as an unset clock and always loses the tie-break against any other Timestamp. GAAP nodes are not required to have synchronized clocks; where a monotonic or NTP-disciplined clock source is available, it is preferable to use it for the Timestamp. A Timestamp that appears to be more than a small, locally configured skew allowance ahead of, or behind, the receiver's own clock SHOULD be treated with the same tie-breaking rule as an equal timestamp rather than assumed to win or lose outright, since it may result from a misconfigured or unsynchronized clock, including a clock that has not yet been set after boot, which typically reads a value far in the past or at zero and would otherwise win every collision it is party to. See for the rationale behind this rule in the context of a bad-faith Timestamp. Multi-record parsing: Each record consists of the fixed-length IPv4 and IPv6 address fields, the fixed-length Timestamp field, followed by the variable-length null-terminated Group Name. A receiver locates the next record, if any, immediately after the null terminator of the current record's Group Name; no padding or alignment is inserted between records. A zero-length Group Name (a single null byte) is syntactically valid but MUST be ignored by the receiver, since GAAP does not define a meaning for an empty group name. Duplicate records for the same group name and group address within one Claim message are valid and MUST be treated as a single claim. The maximum Group Name length is 255 octets, not including the null terminator, and the maximum Record Count is 255. Receivers MUST ensure that a null terminator for each record's Group Name is present within the bounds of the received packet, and that the number of records actually present matches Record Count; otherwise the message is malformed and MUST be discarded without further processing.

GAAP is a protocol, not a library or a Python API. This section is non-normative: it illustrates, using pseudo-Python syntax, the abstract data model a GAAP implementation needs to expose to the application layer above it, i.e., the operations an application needs (initialize, allocate a group address for a group name, release it and shut down), and the data that flows across that boundary (group names, group addresses, and collision notifications). Implementations are free to expose this in any programming interface, or none at all, as long as the on-the-wire protocol defined in is followed.

gaap.init() is used to initialize the GAAP API with an application callback function. The callback function is called when a group address has changed (due to collision) for a group name the application allocated.

import gaap status = gaap.init(app_callback_func) if (status == False): print("error") exit(1) #endif def app_callback_func(group_name, group_address) print("Group name {} changed to group address {}". \ format((group_name, group_address)) #enddef ]]>

gaap.allocate() is used when the application needs a group address to send or receive on.

import gaap group_name = "my-audio-group" group_address = gaap.allocate(group_name) if (group_address == None): print("error") exit(1) #endif print("Name {} allocated address {}".format(group_name, group_address)) ]]>

gaap.release() is used when an application is finished using a group address.

import gaap group_address = gaap.allocate("my-audio-group") status = gaap.release(group_address) if (status == False): print("error") exit(1) #endif print("Released address {}".format(group_address)) ]]>

gaap.close() is used when an application is finished using the GAAP protocol.

import gaap # # Initialize the GAAP API with no callback function. Return if errored. # if (gaap.init() == False): print("error") exit(1) #endif # # Do multicast work by allocating, sending, and receiving group addresses. # ... # # Application shutting down. No longer need to run GAAP on local node. # gaap.close() ]]>

When an application needs a group address it provides the GAAP API with a group name, the group name is used as input to a SHA-256 hash function , hashing the UTF-8 octets of the group name (and, for the collision-fallback candidates below, the literal appended ASCII characters, which are a subset of UTF-8) directly; the null terminator used to mark the end of the Group Name field on the wire (see ) is a wire-format delimiter only and is never itself part of the hash input. Initially, when no group address collision is detected the group name is passed as a string to the hash function and the Hashed Value's low-order bits are used for a group address. The Hashed Value is the 32-bit unsigned integer formed from the last 4 octets of the 32-octet SHA-256 digest, taken in network byte order (that is, the third-to-last digest octet is the most significant octet of the Hashed Value and the last digest octet is the least significant). The address is constructed so that it always falls within the fixed GAAP IPv4 or IPv6 allocation range (see for the specific ranges), and never outside it. The following pseudocode illustrates the functionality, where GAAP_V4_BASE and GAAP_V4_MASK are derived from the fixed GAAP IPv4 allocation, and GAAP_V6_BASE and GAAP_V6_MASK are derived from the fixed GAAP IPv6 allocation: For IPv6, GAAP derives only the group ID. The group ID is formed by placing the low-order bits of the Hashed Value into the host portion of the GAAP group ID range (see for how many bits that range leaves available). The remaining bits of the multicast address - flags, scope, and, where the or formats are in use, the embedded prefix or Rendezvous Point information - are determined by the deployment and are outside the scope of this document, other than the scope constraint in . When the hash function is used to resolve a collision, the following pseudocode will illustrate how 3 more attempts are used to find a unique group address: Two distinct group names can, by construction of the strings above, occasionally produce the same candidate string. For example, a group name that itself ends in the literal characters "+1" produces the same input to the hash function as a different group name's second candidate. This is not treated as a special case as it results in an ordinary collision between the two group names on that candidate address and resolved by the normal collision procedure described in and below, the same as any other hash collision between unrelated group names. If all 4 candidate addresses for a group name collide, the GAAP API returns an error to the application, as shown above. GAAP does not define automatic retry behavior in this case, since retrying with the same group name would deterministically produce the same 4 candidate addresses. This condition is permanent for that group name within the deployment domain until resolved out of band (for example, by every participant independently being reconfigured to use a different group name; this document defines no in-band coordination mechanism for that). Because the failure would otherwise be silent, a GAAP node MUST log this condition and expose it - at minimum, the group name, the four contested addresses, and, where known, the claimants - through the local management interface described in . Note that a GAAP node receiving a Claim message for the same group name and the same group address it is already claiming is not a collision, per the Definition of Terms; two independent partitions using the same group name are therefore expected to converge on the same address once they can communicate. When a group address collision is detected by 2 GAAP nodes, the node with the earliest timestamp for the group address creation wins the collision and keeps using the address. The node with a later timestamp has the responsibility to allocate a new group address to prevent the collision.

When a group address is allocated by a GAAP node, it will build and send a Claim message. Included in the Claim message is the group name, group address, and timestamp. If the group address collides with other GAAP nodes already using the address, one of the nodes will send a Claim message to notify the colliding node that it needs to allocate a new group address. Collisions can occur two ways, the first is when multiple group names produce the same hash, the second is when different hashes are produced but when truncated to fit into a group address format, those bits are the same. A collision is defined to be the same group address allocated to 2 different group names. So if a GAAP node is claiming a group address for its group name and a Claim is received with the same group name with the same group address, it is not a collision. It is simply a peer group participant claiming the group address you both agree to be using. Each GAAP node will periodically send Claim messages for all group names for the applications running on the node. It will do this in a multi-record Claim message. The periodic Claim message is sent by setting a periodic timer to a random value in the range 60 to 66 seconds (a base of 1 minute, plus jitter of 0 to 10% of 1 minute). When the timer expires, a Claim message is sent. Suppression is per (group name, group address) pair: a receiver of a Claim message that carries both the same group address and the same group name as one the receiver is claiming resets its own timer for that pair, thereby suppressing its own Claim for it; timers for other group addresses the node is claiming are unaffected. This allows only a single GAAP node that is using a given (group name, group address) pair to keep claiming that the pair is still in use. A Claim message that carries the same group address with a different group name is a collision (see above) and MUST NOT suppress the receiver's timer for its own (group name, group address) pair; the receiver instead processes it as described below. On receiving a Claim message carrying a group address it is currently claiming with a different group name (an ordinary collision, as opposed to the new-node case below), a GAAP node MUST send a Claim message for that (group name, group address) pair after a random delay uniformly distributed in [0, 1] second, rather than waiting for its periodic timer, unless it receives an equivalent Claim from another node claiming the same pair during that delay, in which case it suppresses its own per the suppression rule above. A GAAP node MUST NOT send more than one such triggered Claim per (group name, group address) pair per second. A new GAAP node may come up after a group address collision has already been resolved by other nodes using a later entry in the Acceptable Group Hash List. It will send a Claim message for the first group hash from the Acceptable Group Hash List, since it has no way to know a prior collision occurred. For a given group name, a later-list-position address, once established among the group's participants by a prior collision resolution, always prevails over an earlier-list-position address for that same group name. A GAAP node using a later-list address that receives a Claim message carrying its own group name with an earlier-list address continues claiming its own (later) address and MUST send a triggered Claim, per the delay and rate limit above, rather than yielding; a GAAP node using an earlier-list address (such as a newly started node) that receives a Claim message carrying its own group name with a later-list address MUST yield and switch to that later address, rather than continuing to use, or allocating, an earlier one. Timestamps are not used for this comparison, only position in the Acceptable Group Hash List. If more than one existing node responds, the new node processes the first valid response it receives and MAY discard duplicates; the new node's own Claim for the earlier-list address is then withdrawn implicitly by no longer being refreshed. If a triggered Claim is lost in transit, the node still claiming the later-list address continues to periodically re-claim it; the node claiming the earlier-list address will observe the unsuppressed Claim on its own next periodic timer expiry (or trigger again immediately on receipt of the repeated Claim) and retransmit its own Claim, so the state converges without a bound on the number of retries.

There will be network outage situations where all GAAP nodes may not receive Claim messages. During a partition, duplicate group addresses may be allocated and used by nodes on each side of the partition. During this condition, multicast nodes can operate normally and there is no conflict until the partition heals. When the partition heals, duplicate group addresses will be detected and fixed. The group address with the earliest Timestamp is used to determine who keeps the collided group address, using the same comparison and tie-breaking rule defined in for equal or skewed Timestamps. All others will have to rehash a new group address and have the applications start using the new address (meaning senders will send to the new group address and receivers will leave the collided group and join the new group). This repair mechanism detects and resolves the case where both sides of a partition end up using the same address for a group name (a same-address collision, per the Definition of Terms). It does not detect the case where the two sides independently fall back to different candidate addresses for the same group name (for example, one side falls back to the "+1" candidate and the other to "+2", each due to an unrelated local collision on its own side): since the two sides are then using different addresses, nothing collides, and the group remains split on healing. Resolving this case is an open question for the experiment described in .

When applications are no longer sending to a group address or not joined to a group address, they can inform the GAAP API to release the group. Release is purely a local action: no GAAP release message is sent on the wire. When this happens, the GAAP protocol stops claiming the group address in periodic messages and will not respond to a Claim for this address for a different group name. It is important for receiver applications to leave the group before releasing the group address. If more than one local application on the same node uses the same group name (and therefore the same group address), the GAAP implementation MUST track this locally and continue claiming the group address on behalf of the remaining applications until the last local application using that group name has released it.

The periodic and jittered Claim timer described above already bounds the sending rate of a well-behaved node; implementations SHOULD additionally rate-limit processing of received Claim messages per source to bound the cost of handling a misbehaving or malicious sender. A cooperating node that identifies a Claim message as misbehaving under either of the two cases below SHOULD place the apparent source of that message on a local bad-actor list and ignore further messages from it: (1) a Claim message claiming a group address not derived from one of the group name inputs used for the Acceptable Group Hash List (); or (2) a source sending Claim messages more often than the periodic and triggered-Claim procedures in this document permit. Losing a Timestamp comparison is not itself grounds for bad-actor listing: exactly one side of every ordinary, honest collision loses that comparison, and the skew-tolerant treatment of an implausible Timestamp in already prevents a fabricated or skewed Timestamp from winning a collision it should not, without needing to separately flag the sender. A node on the bad-actor list MUST NOT have its Claim messages trigger a Claim response, reset a periodic timer, or otherwise be treated as suppressing traffic from other nodes. Because Claim message source addresses can be spoofed, implementations SHOULD bound the size of the bad-actor list and treat its entries as advisory hints rather than authoritative state; see for the rationale behind each case. GAAP Claim messages, whether for the well-known GAAP Group Address or for application group addresses, are intended for delivery within the scope implied by the multicast group address used (see ), and implementations SHOULD set the IPv4 TTL or IPv6 Hop Limit consistently with that scope rather than defaulting to a large value.

This section summarizes operational considerations for GAAP deployment. Implementations should provide a local management interface through which operators can observe GAAP's local active-claim state (see below) and the exhausted-candidate-address condition described in . Group name selection is application deployment specific and may be driven by configuration, applications, or provisioning systems. Operators should define policies to avoid administrative conflicts. GAAP is expected to co-exist with other multicast address allocation mechanisms. Deployments should ensure that GAAP operates within defined address ranges to avoid conflicts with non-GAAP assigned multicast addresses. Operators should also be aware that, due to Layer-2 multicast address mapping, multiple IPv4 multicast addresses, allocated by different multicast allocation procedures, may map to the same ethernet multicast MAC address, which may result in hosts receiving multicast traffic for groups to which they did not explicitly subscribe. GAAP is intended for deployment within a single routed multicast administrative domain that already provides ASM-capable multicast routing and forwarding (see below); it is not intended for deployment on a single link or IP subnet without such infrastructure, and this document does not define behavior for GAAP Claim messages crossing administrative domain boundaries. What GAAP removes, relative to 's zeroconf goals, is centralized coordination and configuration of the application-level group-address-allocation function itself: within a domain with multicast routing already provisioned, applications obtain and defend unique group addresses without a centralized allocation service, explicit per-application configuration, or reliance on a single subnet. GAAP's decentralized, periodic Claim-based model is not intended as a general replacement for existing address allocation mechanisms in traditionally managed networks, and networks that already have a centralized or administratively assigned multicast address allocation scheme in place do not need to deploy GAAP alongside it. A narrower first experiment confined to a single link or subnet, exercising the derivation, collision detection, and suppression mechanisms without requiring ASM/RP infrastructure across the whole domain, is also a reasonable deployment for early experimentation; see . GAAP does not require receivers to be GAAP aware. However, all nodes allocating multicast addresses for the same application or group name are expected to use GAAP in order for collision detection to operate correctly. GAAP allocated groups and non GAAP allocated groups may co-exist in the same network when used by different applications or services. Deployment within a coordinated administrative domain is recommended to avoid conflicts between allocation methods. GAAP defines a method for deriving multicast addresses from group names and detecting address allocation conflicts. Applications use the derived multicast addresses for communication. A group name is intended to be shared by, and only by, the participants of a single application or session that need to rendezvous on the same group address; deployments are responsible for keeping group names unique across unrelated applications within their administrative domain, for example through a naming convention. GAAP's collision detection mechanism handles the case where two unrelated group names happen to hash to the same address, but it cannot detect or prevent two unrelated applications from being deliberately or accidentally configured with the same group name. The creation, distribution and discovery of group names are application specific functions and are outside the scope of this document. GAAP is stateless in the sense that no node is required to persist claim information across restarts, and no node needs to keep a complete table of every group name and address in use by other nodes in order for the protocol to function; each node only needs to track the group names and addresses its own local applications have allocated. The soft state a GAAP node does keep locally (its own allocations and their periodic timers) is rebuilt from scratch on restart via a new round of Claim messages. The local management interface referenced above should also allow operators to clear or reset this state for operational purposes. Deployments should include protections against spoofed claims using appropriate authentication mechanisms, though specific methods are outside the scope of this document. Implementations may limit the number of records per message and should perform basic validation, including detection of duplicate multicast address claims. While strict time synchronization is not required, loosely synchronized clocks are recommended to ensure consistent timer behavior. GAAP requires the underlying network to support IP multicast group membership (IGMP/MLD) and ASM-capable multicast routing/forwarding (e.g., PIM-SM) for delivery of Claim messages, consistent with the routed-administrative-domain scope described above. Applications using GAAP-allocated addresses will typically also rely on ASM delivery for their own traffic, though an application with a single known source could in principle use PIM-SSM for its own data plane once its address has been allocated and claimed via GAAP. In IPv4 deployments using PIM-SM, the Rendezvous Point(s) serving the GAAP Group Address and the GAAP IPv4 allocation range need to be configured to support the full range described in , since a GAAP node may allocate any address within it. In practice, native multicast routing/forwarding support across underlay networks remains inconsistent enough that GAAP is expected most often to be deployed with Claim messages, and the application traffic using GAAP-allocated addresses, carried over an overlay network rather than relying directly on the underlay's multicast capability. Running over an overlay also allows GAAP to work across NAT and other underlay level connectivity restrictions between participants, since the overlay is what actually delivers the multicast packets between GAAP nodes. This document does not mandate an overlay and describes GAAP's requirements in terms of the multicast service it needs, which an overlay or a natively multicast capable underlay can both provide. GAAP's application use address ranges are drawn from space that requires no per user IANA assignment. Because two independently implemented GAAP nodes must still interoperate for GAAP to be genuinely decentralized, each address family's range is a single value fixed by this document, not an operator-configurable setting. An operator can control which applications run in a domain, but not which independently written GAAP implementations those applications might use, so a configurable range would only be reliably compatible with itself. For IPv4, GAAP implementations MUST use 239.0.0.0/10 as the application-use range. This is one of the three ranges (239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10) that Section 6.2.1 of records as unassigned and available for expansion of the IPv4 Organization-Local scope, within the Administratively Scoped Block that records as requiring no IANA assignment policy. A /10 keeps collisions infrequent enough, combined with the up to 4 candidate addresses per group name (see "Acceptable Group Hash List" in ), that a GAAP node rarely needs to fall back past its first candidate address. For IPv6, GAAP implementations MUST use the Experimental Use range 0xFE000000-0xFEFFFFFF of the 32-bit Group ID space defined by as the application-use range, which states that range "may be used for experimentation with new dynamic allocation protocols" without IANA action. Other experimental protocols may also draw on this same range; GAAP does not have it exclusively, which is an inherent property of Experimental status rather than something this document can change. The GAAP_V4_MASK and GAAP_V6_MASK referenced in are derived from the fixed ranges above. Transitioning any part of the IPv6 range to a permanent Standards Action assignment, should GAAP or a successor advance beyond Experimental, is a topic for that future document rather than this one. This document does not define GAAP-specific behavior for inter-AS multicast delivery (e.g., use of the RPF Vector ) or for delivery over a Multicast VPN . GAAP relies entirely on the underlying multicast routing and forwarding infrastructure for delivery of both Claim messages and application traffic. No GAAP-specific considerations beyond normal multicast deployment practice are known for these environments.

GAAP is published as Experimental because decentralized hash-based multicast group address allocation has not been deployed. The experiment aims to determine whether the collision detection and resolution mechanisms defined in this document are sufficient for practical deployments and what collision rates occur in networks of varying scale. The experiment is considered complete when operational experience demonstrates the protocol is suitable for Standards Track or when fundamental limitations are identified that require a revision. The scalability of periodic Claim traffic has not yet been measured for deployments with large numbers of GAAP nodes claiming the same group name. Operators of such deployments should monitor Claim traffic volume and tune deployment-specific parameters as needed; this is expected to be an area of active investigation as operational experience with this experimental protocol accumulates. A narrower first experiment confined to a single link or subnet, per , would exercise the derivation, collision detection, and suppression mechanisms - where every open question in this document lies - without requiring ASM/RP infrastructure across a full administrative domain.

It is suggested that the GAAP protocol run over an encrypted multicast channel, particularly on networks where GAAP traffic could be observed or injected by untrusted parties. This document does not define a mandatory-to-implement encryption mechanism. Deployments that enable encryption need to agree out of band on a common mechanism and key management procedure, which could be difficult in embedded devices with different configurations. The message Marker (see ) provides an implicit signal of whether a received Claim message is encrypted: an unencrypted Claim carries the Marker as cleartext 0xAAAAAAAA, while an encrypted Claim has the Marker encrypted along with the rest of the record data and so will not match 0xAAAAAAAA on the wire. A receiver that sees a non-matching Marker and has a shared key configured attempts decryption. If that fails, or the receiver has no shared key configured, the message MUST be dropped. Note that this single mismatch-triggered check does not distinguish, from the receiver's perspective, between a wrong or missing key, a mismatched encryption mechanism between sender and receiver, and a mutated packet. All three result in the message being dropped, without a diagnostic distinction between them. Because whether a given Claim message is encrypted is signaled only implicitly via the Marker rather than declared in cleartext, a deployment where some nodes are configured with a shared key and others are not does not fail outright. Unkeyed nodes can still exchange unencrypted Claims with each other, and keyed nodes can exchange encrypted Claims with each other, but a keyed node's encrypted Claims are indistinguishable from noise to an unkeyed node and vice versa. For a single group name split across both populations, this results in two collision-detection sub-groups that function correctly within themselves but are mutually invisible to one another, rather than a single interoperable group. This is a consequence of misconfiguration that this document does not attempt to prevent or detect. Deployments choosing an encryption mechanism MUST use one that provides both confidentiality and integrity such as an Authenticated Encryption with Associated Data (AEAD) construction. ChaCha20-Poly1305 is one example. ChaCha20 without a message authentication code does not satisfy this requirement and MUST NOT be used alone since a matching decrypted Marker on its own is not a cryptographic integrity check over the rest of the message. A stream cipher without integrity protection is malleable: an on-path attacker can flip bits in the ciphertext to alter the decrypted group address, Timestamp or Group Name in a chosen way, without detection. This is a more dangerous outcome than the base unencrypted mode where a receiver has no false expectation of protection to begin with. Where a shared key is configured with the application, key management is a deployment responsibility. Implementations MUST ensure nonce uniqueness per key across all senders sharing that key. A receiver configured with a shared key MUST reject an unencrypted Claim message rather than process it, to prevent downgrade to the unauthenticated base mode. This document does not specify a nonce construction or associated data binding scheme, these are implementation and deployment responsibilities when encryption is enabled. Dynamic rekeying mechanisms are outside the scope of this document. However, GAAP can operate with external key management systems, including automated or Dynamic Key Management (DKM) solutions. In the absence of such mechanisms, keys may be provisioned manually. The base (unauthenticated, unencrypted) mode of GAAP offers no protection against an on-network attacker and is suitable only for deployment within a trusted domain where all participants are assumed non-malicious. When GAAP is deployed with out-of-band pre-shared keys and encryption, an attacker without the shared key cannot forge, replay-with-modification or selectively spoof Claim messages. This substantially mitigates the denial-of-allocation, timestamp-spoofing and bad-actor-list-poisoning threats. This does not protect against an authorized, keyed participant that behaves maliciously. Encryption alone does not protect against a legitimate, keyed GAAP node behaving badly. The message validation guidance in and the per-source rate limiting and duplicate-detection guidance in apply regardless of whether encryption is in use. Rationale for three specific threats, with pointers to the normative mitigations defined elsewhere in this document, follows: Even when an encrypted channel is used, a bad actor could be claiming a group address not derived from one of the group name inputs used for the Acceptable Group Hash List (see Definition of Terms section). This is why cooperating nodes ignore such messages rather than send Claim messages to correct the bad actor node, and why the bad-actor list is bounded and advisory rather than authoritative, per ; a bad actor can spoof the source address of another node's Claim message, so source-address based mitigations are best-effort in any case. A bad actor could send a fabricated or artificially early Timestamp giving it tie-breaking priority when a group address collision occurs. This is not mitigated by placing the sender on the bad-actor list, since losing a Timestamp comparison is the expected, honest behavior of one side of any ordinary collision and is not on its own evidence of bad faith - see . Instead, this is why a Timestamp that appears more than a small, locally configured skew allowance ahead of, or behind, the receiver's own clock is treated as an equal timestamp for tie-breaking purposes, per , rather than assumed to win or lose outright - since it may equally result from a misconfigured or unsynchronized clock rather than bad faith, and this comparison rule denies a fabricated Timestamp the outright win it was sent to obtain regardless of intent. A bad actor could send messages too often and is not adhering to the random delay or periodic timer procedures in this document. This is why cooperating nodes ignore messages from a node on the bad-actor list rather than reset or cancel timers, or send triggered Claims, in response to them, per .

This section lists the IANA actions requested for GAAP, one per subsection.

IANA is requested to assign one UDP port number for the GAAP protocol from the User Ports range, registered per the Service Name and Transport Protocol Port Number Registry guidance in . A User Ports assignment, rather than use of the Dynamic Ports range, is requested because GAAP Claim messages are sent to a well-known, IANA-assigned multicast group address by design (see and "GAAP Protocol Multicast Addresses" below); a GAAP node cannot negotiate or discover a dynamically-chosen port for this traffic out of band the way an application-layer protocol with an existing rendezvous mechanism could, since GAAP itself is that rendezvous mechanism, so a fixed, documented port is necessary for interoperability among independently implemented GAAP nodes that have never communicated before. A System Ports assignment is not requested, since GAAP does not require privileged-port semantics and a User Ports assignment is sufficient.

Service Name	Port Number	Transport Protocol	Description	Assignee	Contact	Reference
gaap	TBD (User Ports)	udp	GAAP Control Packets	IESG	IETF Chair	RFCXXXX

IANA is requested to assign one multicast address from the IPv4 Internetwork Control Block 224.0.1.0/24 , and one multicast address from the IPv6 Variable Scope Multicast Addresses Block FF0X::/16, for the operation of the GAAP protocol. The registry description field for each entry should indicate "GAAP". GAAP control messages sent to these addresses are intended to reach all GAAP nodes within an administrative domain rather than being confined to a single link; consistent with that, the IPv4 address is requested from the Internetwork Control Block rather than the Local Network Control Block. The scope value X selected for the IPv6 address is expected to be admin-local or organization-local (not link-local), so that control messages can be forwarded beyond a single link when the deployment requires it; this requirement on implementations is stated normatively in .

Address	Description	Reference
TBD1 (from 224.0.1.0/24)	GAAP	RFCXXXX
TBD2 (from FF0X::/16)	GAAP	RFCXXXX

IANA is requested to create the "GAAP Message Types" registry in a new "Group Address Allocation Protocol (GAAP)" registry group. The registration policy is IETF Review. Each entry contains a Value (a 4-bit unsigned integer), a Name, and a Reference. The initial contents are:

Value	Name	Reference
0	Reserved	RFCXXXX
1	Claim	RFCXXXX
2-15	Unassigned

The authors would like to thank the following people for their motivation to start this draft. They include Chris Hopps, Acee Lindem, David Lamparter, Jeff Tantsura, Nate Karstens, and Lenny Giuliano. And thank you to Gunter Van de Velde for the extensive review prior to publication.

Note to the RFC Editor: please remove this appendix before publication as an RFC.

Submitted September 2026. Addressed Mike Bishop's IESG DISCUSS and COMMENT ballot. Changes made by Mike.

Submitted September 2026. Addressed Eric Vyncke's IESG DISCUSS and COMMENT ballot. Changes made by Mike.

Submitted September 2026. Follow-up round on the Ketan Talaulikar IESG review. Changes made by Mike.

Submitted August 2026. Addressed the IESG DISCUSS and COMMENT ballot from Ketan Talaulikar. Changes made by Mike.

Submitted August 2026. Rewrote parts of the Security Considerations section per secdir by Tim Hollebeek. Also included a new deployment paragraph per Bo Wu's review. Changes made by Mike.

Submitted August 2026. Addressed many comments from Tommy, Sasha and Bo Wu as part of the tsvart, rtgdir and opsdir last call reviews. Changes made by Mike.

Submitted July 2026. Addressed review comments from Gunter Van de Velde. Major changes: aligned the IPv4 address pseudocode with the requested /10 allocation; clarified that GAAP's collision detection is network-layer only; softened the encryption interoperability claim and recommended ChaCha20-Poly1305 [RFC8439] as a stronger alternative; made the dependency on draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id normative; added UDP usage guidance per RFC8085. Minor clarifications: distinguished the GAAP protocol address from the application allocation range; defined multi-record parsing rules and a Timestamp comparison/tie-breaking rule; removed the RFC8536 timestamp reference; marked the GAAP API as illustrative; fully specified the IPv6 address format; clarified the claim/response wait window, per-group-address suppression, and the new-node collision state machine; clarified that address release is local-only; clarified group-name uniqueness scope and GAAP's soft-state model; and aligned the IANA UDP port and multicast address requests with RFC6335 and RFC5771 guidance. Changes made by Mike.

Submitted June 2026. Addressed comments from Stig clarifying IANA requests, adding a paragraph on why GAAP is Experimental and wrapping code in CODE BEGINS/ENDS. Changes made by Mike.

Submitted June 2026. Addressed comments from Stig involving adding a boilerplate, new normative references and changing a few musts to MUST. Changes made by Mike.

Submitted April 2026. Addressed comments from the IntDir review by Sheng Jiang. Changes made by Mike.

Submitted April 2026. Clarified statements in the Operational Considerations section. Changes made by Mike.

Submitted April 2026. Created a new Operational Considerations section to reflect comments from Med. Changes made by Mike.

Submitted March 2026. Made changes to reflect Sandy comments about clarifying how multiple group names could cause collisions as well as clarifying text about encryption. Changes made by Dino.

Submitted March 2026. Change IANA request for an IPv4 multicast block from /8 to /10. Changes made by Dino.

Submitted February 2026. Incorporated suggestion from Toerless Eckert to add paragraph discussing SAP and SDP approaches to multicast group allocation in the Introduction section. Added references to RFC2974 (SAP) and RFC4566 (SDP). Changes made by Dino.

Submitted February 2026. Be more clear about variable length group names and how subsequent records may not be aligned. Changes made by Dino.

Submitted February 2026. Incorporated WG review comments from Stig Venaas on GAAP Group Address definition, Timestamp field documentation, encryption interoperability requirements, and IANA allocation discussion. Changes made by Dino.

Submitted January 2026. Change draft name in IANA considerations section to point to the IETF draft name and not the individual contribution draft name. Changes made by Dino.

Submitted September 2025. Dino fixes Kasten reference.

Submitted September 2025. Mike adds one-liner to abstract.

Submitted August 2025. Fix some typos in the GAAP API section.

Submitted February 2025. Fix some typos in the GAAP API section. Update references and docuemnt timer.

Submitted September 2024. Update references and docuemnt timer.

Submitted April 2024. Update references and docuemnt timer.

Submitted October 2023. Made draft-farinacci-pim-gaap-06 into WG document per PIM WG consensus.

Submitted September 2023. Fix Nate last name misspelling. Add reference to draft-ietf-pim-zeroconf-mcast-addr-alloc-ps (published as ) to intro section. In the IANA Considerations, add IPv6 allocation for GAAP in the 0xA0000000-0xAFFFFFFF range, as suggested by Nate.

Submitted August 2023. Update IANA Considerations section to have IPv6 GAAP application allocations come from the registry that draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id (published as ) is creating.

Submitted April 2023. Added specific text recommended by IANA in the IANA Considerations section.

Submitted April 2023. Changes to reflect comments from PIM and MBONED WG meetings. Put IANA Considerations requests in standard request format.

Submitted March 2023. Fix typos and grammer.

Submitted February 2023. Updated spec to reflect implementation. Add Marker in message format. Add definition for the Acceptable Group Hash List. Discuss security threats and possible mitigation methods.

Initial posting November 2022.