Group Address Allocation Protocol (GAAP)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

2. Definition of Terms

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

GAAP node:

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 Section 6.¶

Group Name:

is a UTF-8 [RFC3629] 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.¶

Group Address:

is an IPv4 multicast group address [RFC1112] not from the Local Network Control Block [RFC5771] unless explicitly assigned for GAAP protocol operation, or an IPv6 multicast group address [RFC4291]. The application allocation range is a range set aside for expansion of the IPv4 Organization-Local scope [RFC2365] and a sub-range of the IPv6 Experimental Use range [RFC10028]; see Section 7.¶

GAAP Group Address:

is an IANA assigned group address the GAAP protocol itself sends Claim messages to (see Section 10, "GAAP Protocol Multicast Addresses"). This is distinct from the GAAP Multicast Group Allocation Range that applications derive their own group addresses from (see Section 7); the GAAP Group Address MUST NOT be allocated from that range.¶

Hash Function:

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 [RFC6234].¶

Acceptable Group Hash List:

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 Section 6 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 Section 6 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.¶

Hashed Value:

the output of the SHA-256 [RFC6234] hash function on one of the 4 character strings in the Acceptable Group Hash List above, further defined in Section 6. 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 [RFC1112], 32 bits for IPv6 [RFC2464]) and is not itself guaranteed by GAAP for IPv4.¶

Collided Group Address:

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.¶

Claim Message:

a GAAP protocol message that allocates a unique group address and claims it among other GAAP nodes on the network.¶

4. GAAP Message Format

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 Section 2), a well-known multicast address allocated by IANA (see Section 10), 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 Section 10 for the specific address requested). The Claim message is sent in a UDP checksummed packet where the source port is ephemeral and chosen by the sender and the destination port is a well-known port allocated by IANA specifically for GAAP (see Section 10). 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 Section 6.5) 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 [RFC8085]. 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.¶

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Type=1 |              Reserved                 | Record Count  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       0xAAAAAAAA Marker                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  IPv4 Multicast Group Address                 | \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  \
    |                                                               |    R
    |                        IPv6 Multicast                         |    e
    |                         Group Address                         |    c
    |                                                               |    o
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    r
    |                          Timestamp                            |    d
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   /
    |                          Group Name ...                       |  /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
    |                             ...                               |/
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Packet field descriptions:

Type (4 bits):

Claim Message uses value 1; value 0 is reserved. See Section 10 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.¶

Reserved (20 bits):

MUST be set to zero by the sender and ignored by the receiver.¶

Record Count (8 bits):

The number of records in this Claim message. See "Record field descriptions" below for the maximum permitted value and malformed-message handling.¶

Marker (32 bits):

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 Section 9), 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 Section 9); 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).¶

Record field descriptions:

IPv4 Multicast Group Address:

a 32-bit multicast address in network byte order [RFC1112]. If all bits are set to 0, there is no IPv4 address being allocated and claimed.¶

IPv6 Multicast Group Address:

a 128-bit multicast address in network byte order [RFC4291]. If all bits are set to 0, there is no IPv6 address being allocated and claimed.¶

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:

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.¶

Timestamp comparison:

Timestamps are compared using serial number arithmetic [RFC1982] 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 [RFC1982], 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 Section 9 for the rationale behind this rule in the context of a bad-faith Timestamp.¶

Group Name:

A variable length group name the multicast application uses, encoded as UTF-8 [RFC3629]. 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).¶

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.¶

5. GAAP API

The GAAP API has the following API calls a multicast application will use. A multicast application imports the library before using it in its code logic. This section documents a python library. The following API is illustrative and shows one possible application interface; it is not a normative part of the GAAP protocol specification. Implementations are free to expose different programming interfaces as long as the on-the-wire protocol defined in Section 4 is followed.¶

<CODE BEGINS>

        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


<CODE ENDS>

<CODE BEGINS>

        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))


<CODE ENDS>

<CODE BEGINS>

        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))


<CODE ENDS>

<CODE BEGINS>

        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()


<CODE ENDS>

6. Detailed Protocol Operation

hashed_value = hashed_value_of(sha256(group_name))
if (v4):
    # GAAP_V4_BASE/GAAP_V4_MASK are derived from the
    # fixed GAAP IPv4 allocation range (239.0.0.0/10).
    group_address = GAAP_V4_BASE | (hashed_value & GAAP_V4_MASK)
#endif
if (v6):
    # GAAP_V6_BASE/GAAP_V6_MASK are derived from the
    # fixed GAAP IPv6 allocation range.
    group_address = GAAP_V6_BASE | (hashed_value & GAAP_V6_MASK)
#endif
return(group_address)

for append in ["+1", "+2", "+3"]:
    hashed_value = hashed_value_of(sha256(group_name + append))
    group_address = make_group_from_hash(hashed_value)
    collision = send_claim(group_address)
    if (collision == False):
        return(group_address)
#endfor
# All 4 candidate addresses (see "Acceptable Group Hash
# List" in Section 2) collided. gaap.allocate() returns
# an error to the calling application; the application
# MAY retry later or select a different group name. This
# condition MUST be logged and exposed via the local
# management interface (see Section 7), including the group
# name, the four contested addresses, and, where known, the
# claimants.
return(None)

7. Operational Considerations

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 Section 6.¶

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 [RFC10019]'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 Section 8.¶

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 Section 10, 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 [RFC2365] records as unassigned and available for expansion of the IPv4 Organization-Local scope, within the Administratively Scoped Block that [RFC5771] 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 Section 2), 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 [RFC10028] 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 Section 6 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 [RFC5496]) or for delivery over a Multicast VPN [RFC6513] [RFC6514]. 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.¶

8. Rationale for Experimental Status

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 Section 7, 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.¶

9. Security Considerations

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 Section 4) 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.¶

ChaCha20 [RFC8439] without a message authentication code has been used to encrypt GAAP messages. Deployments choosing an encryption mechanism SHOULD prefer an Authenticated Encryption with Associated Data (AEAD) construction such as ChaCha20-Poly1305 [RFC8439], which additionally authenticates the message, over ChaCha20 alone. Where a shared key is configured with the application, key management is a deployment responsibility; see below.¶

Deployments enabling encryption MUST use a mechanism that provides both confidentiality and integrity, such as an AEAD construction (e.g., ChaCha20-Poly1305); using ChaCha20 without a message authentication code is NOT RECOMMENDED, since a matching decrypted Marker on its own is not a cryptographic integrity check over the rest of the message. 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 Section 4 and the per-source rate limiting and duplicate-detection guidance in Section 6 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 Section 6; 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 Section 6. 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 Section 4, 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 Section 6.¶

10. IANA Considerations

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

Authors' Addresses