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"). The base allocation protocol requires no centralized service and minimal configuration, although deployments using encryption or administrative scoping may require 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.

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, runs with minimized messaging and state so that it can run within a library a multicast application compiles into its executable binary. GAAP is a possible solution to the issues described in problem statement draft . 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. is an ASCII 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 . 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 IANA assigns for applications to derive their own group addresses from (see , "GAAP Multicast Group Allocation Ranges"); the GAAP Group Address MUST NOT be allocated from that range. For IPv4, the application allocation range is TBD1/10. For IPv6, the application allocation range is TBD2/32. is a cryptographic hash function which takes the group name 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". 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 for the behavior when all 4 candidate addresses collide. is the output of a SHA-256 hash function where the low order 32-bits are 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 IGMP . 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 message called the Claim message with type value 1. Type value of 0 is reserved. 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. GAAP can work behind NAT and firewall devices as long as the GAAP destination port is permitted through filters.

Claim Message 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 of 0xAAAAAAAA is required to be set by the sender. The receiver verifies the marker to be 0xAAAAAAAA. If it is not, the packet is dropped. The Marker field is used to indicate to a receiver that the packet may be encrypted. See for details on encrypting GAAP messages. When encryption is used, the Type, Reserved, and Record Count fields, together with the Marker field itself, remain in cleartext so the receiver can identify the packet as GAAP and detect the encrypted condition before attempting decryption; the record data that follows the Marker (addresses, Timestamp, and Group Name) is encrypted. 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. 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. 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. 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 two competing Claim messages for a Collided Group Address carry the same Timestamp value, 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. GAAP nodes are not required to have synchronized clocks, but SHOULD use a monotonic or NTP-disciplined source for the Timestamp where available. A Timestamp that appears to be more than a small, locally configured skew allowance ahead of the receiver's own clock SHOULD be treated with the same tie-breaking rule as an equal timestamp rather than assumed to win 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). See for how a Timestamp used to gain tie-breaking priority in bad faith is handled. A variable length group name the multicast application uses. It is in ASCII format . The string is terminated with a null character. Since the Group Name is variable length, subsequent records may not occur on a long- or short-word boundary. 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.

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 is followed.

gaap.init() is used to initialize the GAAP API with a 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 . Initially, when no group address collision is detected the group name is passed as a string to the hash function and the low-order bits are used for a group address. The address is constructed so that it always falls within the GAAP IPv4 or IPv6 allocation range assigned by IANA (see , "GAAP Multicast Group Allocation Ranges"), and never outside it. The following pseudo-code illustrates the functionality, where GAAP_V4_BASE and GAAP_V4_MASK are derived from the IANA-assigned GAAP IPv4 /10 allocation (GAAP_V4_MASK selects the 22 host bits within that /10), and GAAP_V6_BASE and GAAP_V6_MASK are derived from the IANA-assigned GAAP IPv6 /32 allocation:

For IPv6, the resulting 128-bit group address is a multicast address per with the flags and scope bits fixed by the IANA-assigned GAAP_V6_BASE (see ) and the 32-bit Group ID placed in the low-order 32 bits, matching the low-order 32 bits produced by the hash. No other bits of the address vary. When the hash function is used to resolve a collision, the following pseudo-code will illustrate how 3 more attempts are used to find a unique group address:

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. 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 address: receivers of a Claim message for a given group address who have their own timer running for that same group address reset that timer, thereby suppressing sending their own Claim message for it; timers for other group addresses the node is claiming are unaffected. This allows only a single GAAP node that is using the group address to keep claiming the group is still in use. 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. Any one existing node already using a later hash in the list for that group name responds with its own Claim message, sent immediately rather than waiting for its periodic timer, carrying the group address it is already using and its (earlier) Timestamp; if more than one existing node responds, the new node processes the first valid response it receives and MAY discard duplicates. On receiving that triggered Claim, the new GAAP node MUST yield, since the existing node's Timestamp is earlier, and switch to using the same group address the existing node is claiming rather than allocating a new one; the new node's own Claim for the first hash is then withdrawn implicitly by no longer being refreshed. If the triggered Claim is lost in transit, the new node continues to periodically re-claim the first hash; the existing node will observe the unsuppressed Claim on its own next periodic timer expiry (or trigger again immediately on receipt of the new node's repeated Claim) and retransmit its response, 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).

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.

This section summarizes operational considerations for GAAP deployment. 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. 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 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. Implementations should provide mechanisms for operators to observe this local active-claim state and to clear or reset it 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 implementations are expected to follow the UDP usage guidelines in . In particular: a sender SHOULD keep a multi-record Claim message small enough to avoid IP fragmentation on the path (for example, by bounding the number of records per message well below the maximum Record Count of 255 when Group Names are long); the UDP checksum MUST be enabled and verified, and a receiver MUST validate the Marker and message length before further processing a packet, discarding malformed packets as described in . The periodic and jittered Claim timer described in 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 (see also ). Because GAAP messages are small requests that do not trigger a disproportionately large response, and Claim messages are sent to a multicast group rather than reflected to a spoofed unicast target, GAAP is not expected to be useful as a reflection or amplification vector; implementations SHOULD nonetheless avoid generating a response larger than the triggering message. 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.

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 is used to indicate if the packet is sent in plaintext or ciphertext. If the Marker is not set to 0xAAAAAAAA and the receiver does not have a shared-key configured or has the wrong shared-key, the receiver cannot decrypt the message or decrypts the message and no 0xAAAAAAAA results. In this case the message MUST be dropped. An open-source GAAP implementation exists where ChaCha20 is used to encrypt GAAP messages. Deployments choosing an encryption mechanism SHOULD prefer an AEAD construction such as ChaCha20-Poly1305 , which additionally authenticates the message, over ChaCha20 alone. The implementation's key management procedure is a simple shared key that is configured with the application. 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. Encryption alone does not protect against a legitimate, keyed GAAP node behaving badly. The message validation, per-source rate limiting, and duplicate-detection guidance in apply regardless of whether encryption is in use, and the following attack threats may exist with possible mitigation techniques: 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). Cooperating nodes should ignore such messages and not try to send Claim messages to correct the bad actor node. Note that a bad actor can spoof the source address of another node's Claim message, so source-address based mitigations such as the bad-actor list below are best-effort. A bad actor could send an invalid timestamp giving it tie-breaking priority when a group address collision occurs. If the group address has been prior claimed by another node with a timestamp earlier than the invalid timestamp, cooperating nodes should put the bad actor node on a bad-actor list and ignore future messages from it. If the group name has not been claimed yet, the timestamp will be accepted only if it is not implausibly far in the future relative to the receiving node's own clock (see for the Timestamp comparison rule). A bad actor could send messages too often and is not adhering to the random delay or periodic timer procedures in this document. When this occurs, cooperating nodes should start ignoring messages from the bad actor node and not reset or cancel timers, or send triggered Claim messages

IANA is requested to make the following assignments in existing registries:

IANA will create one UDP port number for the GAAP protocol, registered per the Service Name and Transport Protocol Port Number Registry guidance in :

Service Name	Port Number	Transport Protocol	Description	Assignee	Contact	Reference
gaap	TBD	udp	GAAP Control Packets	IESG	IETF Chair	draft-ietf-pim-gaap

IANA will create one multicast address from the IPv4 Internetwork Control Block 224.0.1.x and one multicast address from the IPv6 Variable Scope Multicast Addresses Block FF0X::TBD for the operation of the GAAP protocol. The registry description field 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 comes from the Internetwork Control Block rather than the Local Network Control Block, and implementations MUST use an admin-local or organization-local IPv6 scope (not link-local scope) when selecting the scope value X for the IPv6 address, so that control messages can be forwarded beyond a single link when the deployment requires it.

IANA will create two multicast address ranges for the GAAP protocol to allocate application-use addresses from. For IPv4, a /10 block in a new registry range is requested. The size follows from the hash-based allocation model in : a larger host portion within the block, combined with the up to 4 candidate addresses per group name (see "Acceptable Group Hash List" in ), keeps collisions infrequent enough that a GAAP node rarely needs to fall back past its first candidate address. As the draft has previously noted, because a /10 is nonetheless a large portion of the IPv4 multicast space, this size warrants specific attention from IETF and IANA before allocation, and the WG welcomes further discussion of the appropriate block size, including analysis of collision probability at expected deployment scales. For IPv6, a /32 block in a new registry range is being requested, sized to match the 32-bit Group ID used directly in the hash-based derivation in ; the larger IPv6 multicast address space makes collision probability far less of a concern than for IPv4. This allocation MUST come from the Dynamic Multicast Group IDs registry defined in , and publication of this document as an RFC is dependent on that registry existing; see the Normative References. Registry Name: GAAP IPv4 Allocation Range Registration Procedure: IETF Review Registry Name: GAAP IPv6 Allocation Range Registration Procedure: IETF Review For IPv6 multicast addresses, the GAAP application allocation range should be in the new "Dynamic Multicast Group IDs" registry requested by . This new registry requests the division of the 32-bit group ID range 0xA0000000 through 0xAFFFFFFF. The GAAP allocation range should come out of this 32-bit range.

--> -->

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