Group Address Allocation Protocol (GAAP)
draft-ietf-pim-gaap-23
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Dino Farinacci , Mike McBride | ||
| Last updated | 2026-09-03 (Latest revision 2026-09-02) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
ARTART Telechat review
(of
-20)
by Murray Kucherawy
Ready w/issues
TSVART IETF Last Call review
(of
-18)
by Tommy Pauly
Ready w/nits
OPSDIR IETF Last Call review
(of
-18)
by Bo Wu
Clarification Needed
ARTART IETF Last Call review
(of
-18)
by Murray Kucherawy
Ready w/issues
INTDIR Early review
(of
-14)
by Sheng Jiang
Ready w/issues
SECDIR Telechat Review due 2026-09-01
Incomplete
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Associated WG milestone |
|
||
| Document shepherd | Stig Venaas | ||
| Shepherd write-up | Show Last changed 2026-06-26 | ||
| IESG | IESG state | IESG Evaluation::AD Followup | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved. |
||
| Responsible AD | Gunter Van de Velde | ||
| Send notices to | stig@venaas.com | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA expert review state | Issues identified | ||
| IANA expert review comments | I recommend this be revised to use the multicast application port number assigned per draft-ietf-intarea-multicast-application-port. That draft recognizes that multicast services are already sufficiently differentiated by IP address and thus assigning new port numbers for multicast services is not necessary. |
draft-ietf-pim-gaap-23
Network Working Group D. Farinacci
Internet-Draft lispers.net
Intended status: Experimental M. McBride
Expires: 7 March 2027 Futurewei
3 September 2026
Group Address Allocation Protocol (GAAP)
draft-ietf-pim-gaap-23
Abstract
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 Section 8 for the rationale and the
criteria for concluding the experiment.
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.
Farinacci & McBride Expires 7 March 2027 [Page 1]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Protocol Operation . . . . . . . . . . . . . . . 5
4. GAAP Message Format . . . . . . . . . . . . . . . . . . . . . 6
5. GAAP API . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. gaap.init() . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. gaap.allocate() . . . . . . . . . . . . . . . . . . . . . 10
5.3. gaap.release() . . . . . . . . . . . . . . . . . . . . . 11
5.4. gaap.close() . . . . . . . . . . . . . . . . . . . . . . 11
6. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 12
6.1. Allocating Group Addresses . . . . . . . . . . . . . . . 12
6.2. Claiming Group Addresses . . . . . . . . . . . . . . . . 14
6.3. Partition Repair . . . . . . . . . . . . . . . . . . . . 16
6.4. Releasing Group Addresses . . . . . . . . . . . . . . . . 17
6.5. Sending and Receiving Rate Controls . . . . . . . . . . . 17
7. Operational Considerations . . . . . . . . . . . . . . . . . 18
8. Rationale for Experimental Status . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. GAAP UDP Port Numbers . . . . . . . . . . . . . . . . . 24
10.2. GAAP Protocol Multicast Addresses . . . . . . . . . . . 25
10.3. GAAP Message Types . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 28
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 28
B.1. Changes to draft-ietf-pim-gaap-23 . . . . . . . . . . . . 29
B.2. Changes to draft-ietf-pim-gaap-22 . . . . . . . . . . . . 29
B.3. Changes to draft-ietf-pim-gaap-21 . . . . . . . . . . . . 29
B.4. Changes to draft-ietf-pim-gaap-20 . . . . . . . . . . . . 29
B.5. Changes to draft-ietf-pim-gaap-19 . . . . . . . . . . . . 29
B.6. Changes to draft-ietf-pim-gaap-18 . . . . . . . . . . . . 29
B.7. Changes to draft-ietf-pim-gaap-17 . . . . . . . . . . . . 30
B.8. Changes to draft-ietf-pim-gaap-16 . . . . . . . . . . . . 30
B.9. Changes to draft-ietf-pim-gaap-15 . . . . . . . . . . . . 30
B.10. Changes to draft-ietf-pim-gaap-14 . . . . . . . . . . . . 31
Farinacci & McBride Expires 7 March 2027 [Page 2]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
B.11. Changes to draft-ietf-pim-gaap-13 . . . . . . . . . . . . 31
B.12. Changes to draft-ietf-pim-gaap-12 . . . . . . . . . . . . 31
B.13. Changes to draft-ietf-pim-gaap-11 . . . . . . . . . . . . 31
B.14. Changes to draft-ietf-pim-gaap-10 . . . . . . . . . . . . 31
B.15. Changes to draft-ietf-pim-gaap-09 . . . . . . . . . . . . 32
B.16. Changes to draft-ietf-pim-gaap-08 . . . . . . . . . . . . 32
B.17. Changes to draft-ietf-pim-gaap-07 . . . . . . . . . . . . 32
B.18. Changes to draft-ietf-pim-gaap-06 . . . . . . . . . . . . 32
B.19. Changes to draft-ietf-pim-gaap-05 . . . . . . . . . . . . 32
B.20. Changes to draft-ietf-pim-gaap-04 . . . . . . . . . . . . 32
B.21. Changes to draft-ietf-pim-gaap-03 . . . . . . . . . . . . 33
B.22. Changes to draft-ietf-pim-gaap-02 . . . . . . . . . . . . 33
B.23. Changes to draft-ietf-pim-gaap-01 . . . . . . . . . . . . 33
B.24. Changes to draft-ietf-pim-gaap-00 . . . . . . . . . . . . 33
B.25. Changes to draft-farinacci-pim-gaap-06 . . . . . . . . . 33
B.26. Changes to draft-farinacci-pim-gaap-05 . . . . . . . . . 33
B.27. Changes to draft-farinacci-pim-gaap-04 . . . . . . . . . 34
B.28. Changes to draft-farinacci-pim-gaap-03 . . . . . . . . . 34
B.29. Changes to draft-farinacci-pim-gaap-02 . . . . . . . . . 34
B.30. Changes to draft-farinacci-pim-gaap-01 . . . . . . . . . 34
B.31. Changes to draft-farinacci-pim-gaap-00 . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
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 [RFC10019]. This document specifies an Experimental
protocol, see Section 8 for why, and for the scope of the experiment.
Other approaches to multicast group allocation have been proposed in
the past, they include SAP [RFC2974], SDP [RFC8866], mDNS [RFC6762],
MADCAP [RFC2730], MASC [RFC2909], and IPv6 Allocation Guidelines
[RFC3307]. 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.
Farinacci & McBride Expires 7 March 2027 [Page 3]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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
Farinacci & McBride Expires 7 March 2027 [Page 4]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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.
3. Overview of Protocol Operation
This section will describe the high-level functionality of the GAAP
protocol. Each application runs the GAAP protocol by using the API
defined in Section 5.
* 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 Section 4, 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 Section 6,
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.
Farinacci & McBride Expires 7 March 2027 [Page 5]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
* 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 [RFC2236]. See Section 6 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.
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
Farinacci & McBride Expires 7 March 2027 [Page 6]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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 ... | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
| ... |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: GAAP Claim Message
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
Farinacci & McBride Expires 7 March 2027 [Page 7]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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
Farinacci & McBride Expires 7 March 2027 [Page 8]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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.
Farinacci & McBride Expires 7 March 2027 [Page 9]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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.
5.1. gaap.init()
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.
<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>
5.2. gaap.allocate()
gaap.allocate() is used when the application needs a group address to
send or receive on.
Farinacci & McBride Expires 7 March 2027 [Page 10]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
<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>
5.3. gaap.release()
gaap.release() is used when an application is finished using a group
address.
<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>
5.4. gaap.close()
gaap.close() is used when an application is finished using the GAAP
protocol.
Farinacci & McBride Expires 7 March 2027 [Page 11]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
<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
6.1. Allocating Group Addresses
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 [RFC6234], 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 Section 4) 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 Section 7
for the specific ranges), and never outside it. The following
pseudo-code 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:
Farinacci & McBride Expires 7 March 2027 [Page 12]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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 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 Section 10 for how many bits that
range leaves available). The remaining bits of the multicast address
- flags, scope, and, where the [RFC3306] or [RFC3956] 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 Section 10.
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:
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)
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
Farinacci & McBride Expires 7 March 2027 [Page 13]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
ordinary collision between the two group names on that candidate
address and resolved by the normal collision procedure described in
Section 4 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 Section 7. 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.
6.2. Claiming Group Addresses
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.
Farinacci & McBride Expires 7 March 2027 [Page 14]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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
Farinacci & McBride Expires 7 March 2027 [Page 15]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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.
6.3. Partition Repair
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 Section 4 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 Section 8.
Farinacci & McBride Expires 7 March 2027 [Page 16]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
6.4. Releasing Group Addresses
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.
6.5. Sending and Receiving Rate Controls
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 (Section 2); 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 Section 4 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 Section 9 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
Section 10), and implementations SHOULD set the IPv4 TTL or IPv6 Hop
Limit consistently with that scope rather than defaulting to a large
value.
Farinacci & McBride Expires 7 March 2027 [Page 17]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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
Farinacci & McBride Expires 7 March 2027 [Page 18]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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
Farinacci & McBride Expires 7 March 2027 [Page 19]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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.
Farinacci & McBride Expires 7 March 2027 [Page 20]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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.
Farinacci & McBride Expires 7 March 2027 [Page 21]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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
Farinacci & McBride Expires 7 March 2027 [Page 22]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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,
Farinacci & McBride Expires 7 March 2027 [Page 23]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
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.
10.1. GAAP UDP Port Numbers
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 [RFC6335]. 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 Section 4 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|Port |Transport| Description |Assignee|Contact|Reference|
|Name |Number|Protocol | | | | |
+=======+======+=========+=============+========+=======+=========+
|gaap |TBD |udp | GAAP |IESG |IETF |RFCXXXX |
| |(User | | Control | |Chair | |
| |Ports)| | Packets | | | |
+-------+------+---------+-------------+--------+-------+---------+
Table 1
Farinacci & McBride Expires 7 March 2027 [Page 24]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
10.2. GAAP Protocol Multicast Addresses
IANA is requested to assign one multicast address from the IPv4
Internetwork Control Block 224.0.1.0/24 [RFC5771], 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 Section 4.
+==========================+=============+===========+
| Address | Description | Reference |
+==========================+=============+===========+
| TBD1 (from 224.0.1.0/24) | GAAP | RFCXXXX |
+--------------------------+-------------+-----------+
| TBD2 (from FF0X::/16) | GAAP | RFCXXXX |
+--------------------------+-------------+-----------+
Table 2
10.3. GAAP Message Types
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 | |
+-------+------------+-----------+
Table 3
11. References
Farinacci & McBride Expires 7 March 2027 [Page 25]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
11.1. Normative References
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/info/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<https://www.rfc-editor.org/info/rfc2236>.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, DOI 10.17487/RFC2365, July 1998,
<https://www.rfc-editor.org/info/rfc2365>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
DOI 10.17487/RFC5771, March 2010,
<https://www.rfc-editor.org/info/rfc5771>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
Farinacci & McBride Expires 7 March 2027 [Page 26]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>.
[RFC10028] Karstens, N., Farinacci, D., and M. McBride, "Updates to
Dynamic IPv6 Multicast Address Group IDs", RFC 10028,
DOI 10.17487/RFC10028, August 2026,
<https://www.rfc-editor.org/info/rfc10028>.
11.2. Informative References
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>.
[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
DOI 10.17487/RFC2730, December 1999,
<https://www.rfc-editor.org/info/rfc2730>.
[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M.,
Kumar, S., and D. Thaler, "The Multicast Address-Set Claim
(MASC) Protocol", RFC 2909, DOI 10.17487/RFC2909,
September 2000, <https://www.rfc-editor.org/info/rfc2909>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
October 2000, <https://www.rfc-editor.org/info/rfc2974>.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
September 2002, <https://www.rfc-editor.org/info/rfc3306>.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, DOI 10.17487/RFC3307, September
2002, <https://www.rfc-editor.org/info/rfc3307>.
Farinacci & McBride Expires 7 March 2027 [Page 27]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, DOI 10.17487/RFC3956, November 2004,
<https://www.rfc-editor.org/info/rfc3956>.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009,
<https://www.rfc-editor.org/info/rfc5496>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>.
[RFC10019] Karstens, N., Farinacci, D., and M. McBride, "Zeroconf
Multicast Address Allocation Problem Statement and
Requirements", RFC 10019, DOI 10.17487/RFC10019, July
2026, <https://www.rfc-editor.org/info/rfc10019>.
Appendix A. Acknowledgments
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.
Appendix B. Document Change Log
Note to the RFC Editor: please remove this appendix before
publication as an RFC.
Farinacci & McBride Expires 7 March 2027 [Page 28]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
B.1. Changes to draft-ietf-pim-gaap-23
* Submitted September 2026.
* Addressed Eric Vyncke's IESG DISCUSS and COMMENT ballot.
* Changes made by Mike.
B.2. Changes to draft-ietf-pim-gaap-22
* Submitted September 2026.
* Follow-up round on the Ketan Talaulikar IESG review.
* Changes made by Mike.
B.3. Changes to draft-ietf-pim-gaap-21
* Submitted August 2026.
* Addressed the IESG DISCUSS and COMMENT ballot from Ketan
Talaulikar.
* Changes made by Mike.
B.4. Changes to draft-ietf-pim-gaap-20
* 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.
B.5. Changes to draft-ietf-pim-gaap-19
* 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.
B.6. Changes to draft-ietf-pim-gaap-18
* Submitted July 2026.
Farinacci & McBride Expires 7 March 2027 [Page 29]
Internet-Draft Group Address Allocation Protocol (GAAP) September 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.
B.7. Changes to draft-ietf-pim-gaap-17
* 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.
B.8. Changes to draft-ietf-pim-gaap-16
* 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.
B.9. Changes to draft-ietf-pim-gaap-15
* Submitted April 2026.
* Addressed comments from the IntDir review by Sheng Jiang.
* Changes made by Mike.
Farinacci & McBride Expires 7 March 2027 [Page 30]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
B.10. Changes to draft-ietf-pim-gaap-14
* Submitted April 2026.
* Clarified statements in the Operational Considerations section.
* Changes made by Mike.
B.11. Changes to draft-ietf-pim-gaap-13
* Submitted April 2026.
* Created a new Operational Considerations section to reflect
comments from Med.
* Changes made by Mike.
B.12. Changes to draft-ietf-pim-gaap-12
* 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.
B.13. Changes to draft-ietf-pim-gaap-11
* Submitted March 2026.
* Change IANA request for an IPv4 multicast block from /8 to /10.
* Changes made by Dino.
B.14. Changes to draft-ietf-pim-gaap-10
* 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.
Farinacci & McBride Expires 7 March 2027 [Page 31]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
B.15. Changes to draft-ietf-pim-gaap-09
* Submitted February 2026.
* Be more clear about variable length group names and how subsequent
records may not be aligned.
* Changes made by Dino.
B.16. Changes to draft-ietf-pim-gaap-08
* 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.
B.17. Changes to draft-ietf-pim-gaap-07
* 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.
B.18. Changes to draft-ietf-pim-gaap-06
* Submitted September 2025.
* Dino fixes Kasten reference.
B.19. Changes to draft-ietf-pim-gaap-05
* Submitted September 2025.
* Mike adds one-liner to abstract.
B.20. Changes to draft-ietf-pim-gaap-04
* Submitted August 2025.
* Fix some typos in the GAAP API section.
Farinacci & McBride Expires 7 March 2027 [Page 32]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
B.21. Changes to draft-ietf-pim-gaap-03
* Submitted February 2025.
* Fix some typos in the GAAP API section.
* Update references and docuemnt timer.
B.22. Changes to draft-ietf-pim-gaap-02
* Submitted September 2024.
* Update references and docuemnt timer.
B.23. Changes to draft-ietf-pim-gaap-01
* Submitted April 2024.
* Update references and docuemnt timer.
B.24. Changes to draft-ietf-pim-gaap-00
* Submitted October 2023.
* Made draft-farinacci-pim-gaap-06 into WG document per PIM WG
consensus.
B.25. Changes to draft-farinacci-pim-gaap-06
* Submitted September 2023.
* Fix Nate last name misspelling.
* Add reference to draft-ietf-pim-zeroconf-mcast-addr-alloc-ps
(published as [RFC10019]) to intro section.
* In the IANA Considerations, add IPv6 allocation for GAAP in the
0xA0000000-0xAFFFFFFF range, as suggested by Nate.
B.26. Changes to draft-farinacci-pim-gaap-05
* 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 [RFC10028]) is creating.
Farinacci & McBride Expires 7 March 2027 [Page 33]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
B.27. Changes to draft-farinacci-pim-gaap-04
* Submitted April 2023.
* Added specific text recommended by IANA in the IANA Considerations
section.
B.28. Changes to draft-farinacci-pim-gaap-03
* Submitted April 2023.
* Changes to reflect comments from PIM and MBONED WG meetings.
* Put IANA Considerations requests in standard request format.
B.29. Changes to draft-farinacci-pim-gaap-02
* Submitted March 2023.
* Fix typos and grammer.
B.30. Changes to draft-farinacci-pim-gaap-01
* 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.
B.31. Changes to draft-farinacci-pim-gaap-00
* Initial posting November 2022.
Authors' Addresses
Dino Farinacci
lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com
Farinacci & McBride Expires 7 March 2027 [Page 34]
Internet-Draft Group Address Allocation Protocol (GAAP) September 2026
Mike McBride
Futurewei
Santa Clara, CA
United States of America
Email: mmcbride7@gmail.com
Farinacci & McBride Expires 7 March 2027 [Page 35]