draft-ietf-pim-gaap-19.txt   draft-ietf-pim-gaap-20.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Intended status: Experimental M. McBride Intended status: Experimental M. McBride
Expires: 13 February 2027 Futurewei Expires: 15 February 2027 Futurewei
12 August 2026 14 August 2026
Group Address Allocation Protocol (GAAP) Group Address Allocation Protocol (GAAP)
draft-ietf-pim-gaap-19 draft-ietf-pim-gaap-20
Abstract Abstract
This document describes a design for a lightweight decentralized This document describes a design for a lightweight decentralized
multicast group address allocation protocol (named GAAP and multicast group address allocation protocol (named GAAP and
pronounced "gap" as in "mind the gap"). The base allocation protocol pronounced "gap" as in "mind the gap"). The base allocation protocol
requires no centralized service and minimal configuration, although requires no centralized service and minimal configuration, although
deployments using encryption or administrative scoping may require deployments using encryption or administrative scoping may require
configuration. The protocol runs among group participants which need configuration. The protocol runs among group participants which need
a unique group address to send and receive multicast packets. a unique group address to send and receive multicast packets.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 February 2027. This Internet-Draft will expire on 15 February 2027.
Copyright Notice Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Protocol Operation . . . . . . . . . . . . . . . 5 3. Overview of Protocol Operation . . . . . . . . . . . . . . . 5
4. GAAP Message Format . . . . . . . . . . . . . . . . . . . . . 6 4. GAAP Message Format . . . . . . . . . . . . . . . . . . . . . 6
5. GAAP API . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. GAAP API . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. gaap.init() . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. gaap.init() . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. gaap.allocate() . . . . . . . . . . . . . . . . . . . . . 9 5.2. gaap.allocate() . . . . . . . . . . . . . . . . . . . . . 9
5.3. gaap.release() . . . . . . . . . . . . . . . . . . . . . 9 5.3. gaap.release() . . . . . . . . . . . . . . . . . . . . . 9
5.4. gaap.close() . . . . . . . . . . . . . . . . . . . . . . 10 5.4. gaap.close() . . . . . . . . . . . . . . . . . . . . . . 10
6. Detail Protocol Operation . . . . . . . . . . . . . . . . . . 10 6. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 10
6.1. Allocating Group Addresses . . . . . . . . . . . . . . . 11 6.1. Allocating Group Addresses . . . . . . . . . . . . . . . 11
6.2. Claiming Group Addresses . . . . . . . . . . . . . . . . 12 6.2. Claiming Group Addresses . . . . . . . . . . . . . . . . 12
6.3. Partition Repair . . . . . . . . . . . . . . . . . . . . 13 6.3. Partition Repair . . . . . . . . . . . . . . . . . . . . 13
6.4. Releasing Group Addresses . . . . . . . . . . . . . . . . 14 6.4. Releasing Group Addresses . . . . . . . . . . . . . . . . 14
7. Operational Considerations . . . . . . . . . . . . . . . . . 14 7. Operational Considerations . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. GAAP UDP Port Numbers . . . . . . . . . . . . . . . . . . 18 9.1. GAAP UDP Port Numbers . . . . . . . . . . . . . . . . . . 19
9.2. GAAP Protocol Multicast Addresses . . . . . . . . . . . . 19 9.2. GAAP Protocol Multicast Addresses . . . . . . . . . . . . 19
9.3. GAAP Multicast Group Allocation Ranges . . . . . . . . . 19 9.3. GAAP Multicast Group Allocation Ranges . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 22 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 23
B.1. Changes to draft-ietf-pim-gaap-19 . . . . . . . . . . . . 23 B.1. Changes to draft-ietf-pim-gaap-20 . . . . . . . . . . . . 23
B.2. Changes to draft-ietf-pim-gaap-18 . . . . . . . . . . . . 23 B.2. Changes to draft-ietf-pim-gaap-19 . . . . . . . . . . . . 24
B.3. Changes to draft-ietf-pim-gaap-17 . . . . . . . . . . . . 23 B.3. Changes to draft-ietf-pim-gaap-18 . . . . . . . . . . . . 24
B.4. Changes to draft-ietf-pim-gaap-16 . . . . . . . . . . . . 23 B.4. Changes to draft-ietf-pim-gaap-17 . . . . . . . . . . . . 24
B.5. Changes to draft-ietf-pim-gaap-15 . . . . . . . . . . . . 24 B.5. Changes to draft-ietf-pim-gaap-16 . . . . . . . . . . . . 24
B.6. Changes to draft-ietf-pim-gaap-14 . . . . . . . . . . . . 24 B.6. Changes to draft-ietf-pim-gaap-15 . . . . . . . . . . . . 25
B.7. Changes to draft-ietf-pim-gaap-13 . . . . . . . . . . . . 24 B.7. Changes to draft-ietf-pim-gaap-14 . . . . . . . . . . . . 25
B.8. Changes to draft-ietf-pim-gaap-12 . . . . . . . . . . . . 24 B.8. Changes to draft-ietf-pim-gaap-13 . . . . . . . . . . . . 25
B.9. Changes to draft-ietf-pim-gaap-11 . . . . . . . . . . . . 24 B.9. Changes to draft-ietf-pim-gaap-12 . . . . . . . . . . . . 25
B.10. Changes to draft-ietf-pim-gaap-10 . . . . . . . . . . . . 25 B.10. Changes to draft-ietf-pim-gaap-11 . . . . . . . . . . . . 25
B.11. Changes to draft-ietf-pim-gaap-09 . . . . . . . . . . . . 25 B.11. Changes to draft-ietf-pim-gaap-10 . . . . . . . . . . . . 26
B.12. Changes to draft-ietf-pim-gaap-08 . . . . . . . . . . . . 25 B.12. Changes to draft-ietf-pim-gaap-09 . . . . . . . . . . . . 26
B.13. Changes to draft-ietf-pim-gaap-07 . . . . . . . . . . . . 25 B.13. Changes to draft-ietf-pim-gaap-08 . . . . . . . . . . . . 26
B.14. Changes to draft-ietf-pim-gaap-06 . . . . . . . . . . . . 25 B.14. Changes to draft-ietf-pim-gaap-07 . . . . . . . . . . . . 26
B.15. Changes to draft-ietf-pim-gaap-05 . . . . . . . . . . . . 26 B.15. Changes to draft-ietf-pim-gaap-06 . . . . . . . . . . . . 26
B.16. Changes to draft-ietf-pim-gaap-04 . . . . . . . . . . . . 26 B.16. Changes to draft-ietf-pim-gaap-05 . . . . . . . . . . . . 27
B.17. Changes to draft-ietf-pim-gaap-03 . . . . . . . . . . . . 26 B.17. Changes to draft-ietf-pim-gaap-04 . . . . . . . . . . . . 27
B.18. Changes to draft-ietf-pim-gaap-02 . . . . . . . . . . . . 26 B.18. Changes to draft-ietf-pim-gaap-03 . . . . . . . . . . . . 27
B.19. Changes to draft-ietf-pim-gaap-01 . . . . . . . . . . . . 26 B.19. Changes to draft-ietf-pim-gaap-02 . . . . . . . . . . . . 27
B.20. Changes to draft-ietf-pim-gaap-00 . . . . . . . . . . . . 26 B.20. Changes to draft-ietf-pim-gaap-01 . . . . . . . . . . . . 27
B.21. Changes to draft-farinacci-pim-gaap-06 . . . . . . . . . 26 B.21. Changes to draft-ietf-pim-gaap-00 . . . . . . . . . . . . 27
B.22. Changes to draft-farinacci-pim-gaap-05 . . . . . . . . . 27 B.22. Changes to draft-farinacci-pim-gaap-06 . . . . . . . . . 27
B.23. Changes to draft-farinacci-pim-gaap-04 . . . . . . . . . 27 B.23. Changes to draft-farinacci-pim-gaap-05 . . . . . . . . . 28
B.24. Changes to draft-farinacci-pim-gaap-03 . . . . . . . . . 27 B.24. Changes to draft-farinacci-pim-gaap-04 . . . . . . . . . 28
B.25. Changes to draft-farinacci-pim-gaap-02 . . . . . . . . . 27 B.25. Changes to draft-farinacci-pim-gaap-03 . . . . . . . . . 28
B.26. Changes to draft-farinacci-pim-gaap-01 . . . . . . . . . 27 B.26. Changes to draft-farinacci-pim-gaap-02 . . . . . . . . . 28
B.27. Changes to draft-farinacci-pim-gaap-00 . . . . . . . . . 27 B.27. Changes to draft-farinacci-pim-gaap-01 . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 B.28. Changes to draft-farinacci-pim-gaap-00 . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The Group Address Allocation Protocol (GAAP) is a decentralized The Group Address Allocation Protocol (GAAP) is a decentralized
multicast protocol used by participating applications which send and multicast protocol used by participating applications which send and
receive packets to/from a multicast group. The protocol is receive packets to/from a multicast group. The protocol is
relatively lightweight, runs with minimized messaging and state so relatively lightweight, runs with minimized messaging and state so
that it can run within a library a multicast application compiles that it can run within a library a multicast application compiles
into its executable binary. into its executable binary.
GAAP is a possible solution to the issues described in problem GAAP is a possible solution to the issues described in problem
statement draft [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps]. statement [RFC10019].
Other approaches to multicast group allocation have been proposed in Other approaches to multicast group allocation have been proposed in
the past, they include SAP [RFC2974], SDP [RFC4566], mDNS [RFC6762], the past, they include SAP [RFC2974], SDP [RFC4566], mDNS [RFC6762],
MADCAP [RFC2730], MASC [RFC2909], and IPv6 Allocation Guidelines MADCAP [RFC2730], MASC [RFC2909], and IPv6 Allocation Guidelines
[RFC3307]. However, depending on the specific mechanism, these [RFC3307]. However, depending on the specific mechanism, these
approaches can require global scope (adding latency), explicit approaches can require global scope (adding latency), explicit
configuration, reliance on a single subnet, or a centralized or semi- configuration, reliance on a single subnet, or a centralized or semi-
centralized service; not every limitation applies to every mechanism centralized service; not every limitation applies to every mechanism
listed. listed.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
# Do multicast work by allocating, sending, and receiving group addresses. # Do multicast work by allocating, sending, and receiving group addresses.
# #
... ...
# #
# Application shutting down. No longer need to run GAAP on local node. # Application shutting down. No longer need to run GAAP on local node.
# #
gaap.close() gaap.close()
<CODE ENDS> <CODE ENDS>
6. Detail Protocol Operation 6. Detailed Protocol Operation
6.1. Allocating Group Addresses 6.1. Allocating Group Addresses
When an application needs a group address it provides the GAAP API 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 with a group name, the group name is used as input to a SHA-256 hash
function [RFC6234]. Initially, when no group address collision is function [RFC6234]. Initially, when no group address collision is
detected the group name is passed as a string to the hash function 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 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 constructed so that it always falls within the GAAP IPv4 or IPv6
allocation range assigned by IANA (see Section 9, "GAAP Multicast allocation range assigned by IANA (see Section 9, "GAAP Multicast
Group Allocation Ranges"), and never outside it. The following Group Allocation Ranges"), and never outside it. The following
skipping to change at page 15, line 5 skipping to change at page 15, line 5
GAAP is expected to co-exist with other multicast address allocation GAAP is expected to co-exist with other multicast address allocation
mechanisms. Deployments should ensure that GAAP operates within mechanisms. Deployments should ensure that GAAP operates within
defined address ranges to avoid conflicts with non-GAAP assigned defined address ranges to avoid conflicts with non-GAAP assigned
multicast addresses. Operators should also be aware that, due to multicast addresses. Operators should also be aware that, due to
Layer-2 multicast address mapping, multiple IPv4 multicast addresses, Layer-2 multicast address mapping, multiple IPv4 multicast addresses,
allocated by different multicast allocation procedures, may map to allocated by different multicast allocation procedures, may map to
the same ethernet multicast MAC address, which may result in hosts the same ethernet multicast MAC address, which may result in hosts
receiving multicast traffic for groups to which they did not receiving multicast traffic for groups to which they did not
explicitly subscribe. explicitly subscribe.
GAAP is intended for zeroconf and unmanaged or loosely managed
deployment scenarios, such as those described in [RFC10019], where
applications need a group address without relying on centralized
configuration or provisioning. GAAP's decentralized, periodic Claim-
based model is not intended as a general replacement for existing
address allocation mechanisms in traditionally managed networks.
Networks that already have a centralized or administratively assigned
multicast address allocation scheme in place do not need to deploy
GAAP alongside it. GAAP is expected to operate within a single
administrative domain and this document does not define behavior for
GAAP Claim messages crossing administrative domain boundaries.
GAAP does not require receivers to be GAAP aware. However, all nodes GAAP does not require receivers to be GAAP aware. However, all nodes
allocating multicast addresses for the same application or group name allocating multicast addresses for the same application or group name
are expected to use GAAP in order for collision detection to operate are expected to use GAAP in order for collision detection to operate
correctly. GAAP allocated groups and non GAAP allocated groups may correctly. GAAP allocated groups and non GAAP allocated groups may
co-exist in the same network when used by different applications or co-exist in the same network when used by different applications or
services. Deployment within a coordinated administrative domain is services. Deployment within a coordinated administrative domain is
recommended to avoid conflicts between allocation methods. recommended to avoid conflicts between allocation methods.
GAAP defines a method for deriving multicast addresses from group GAAP defines a method for deriving multicast addresses from group
names and detecting address allocation conflicts. Applications use names and detecting address allocation conflicts. Applications use
skipping to change at page 17, line 18 skipping to change at page 17, line 30
entirely on the underlying multicast routing and forwarding entirely on the underlying multicast routing and forwarding
infrastructure for delivery of both Claim messages and application infrastructure for delivery of both Claim messages and application
traffic. No GAAP-specific considerations beyond normal multicast traffic. No GAAP-specific considerations beyond normal multicast
deployment practice are known for these environments. deployment practice are known for these environments.
8. Security Considerations 8. Security Considerations
It is suggested that the GAAP protocol run over an encrypted It is suggested that the GAAP protocol run over an encrypted
multicast channel, particularly on networks where GAAP traffic could multicast channel, particularly on networks where GAAP traffic could
be observed or injected by untrusted parties. This document does not be observed or injected by untrusted parties. This document does not
define a mandatory-to-implement encryption mechanism; deployments define a mandatory-to-implement encryption mechanism. Deployments
that enable encryption need to agree out of band on a common that enable encryption need to agree out of band on a common
mechanism and key management procedure, which could be difficult in mechanism and key management procedure, which could be difficult in
embedded devices with different configurations. The message Marker embedded devices with different configurations. The message Marker
is used to indicate if the packet is sent in plaintext or ciphertext. is always sent in cleartext as 0xAAAAAAAA (see Section 4) and is used
If the Marker is not set to 0xAAAAAAAA and the receiver does not have by the receiver to identify the packet as GAAP before determining
a shared-key configured or has the wrong shared-key, the receiver whether the following record data is encrypted. If the receiver has
cannot decrypt the message or decrypts the message and no 0xAAAAAAAA a shared key configured and the decrypted record data is not well-
results. In this case the message MUST be dropped. formed, or the receiver has no shared key or the wrong shared key for
an encrypted message, the message MUST be dropped.
An open-source GAAP implementation exists where ChaCha20 [RFC7539] is An open-source GAAP implementation exists where ChaCha20 [RFC7539] is
used to encrypt GAAP messages. Deployments choosing an encryption used to encrypt GAAP messages. Deployments choosing an encryption
mechanism SHOULD prefer an Authenticated Encryption with Associated mechanism SHOULD prefer an Authenticated Encryption with Associated
Data (AEAD) construction such as ChaCha20-Poly1305 [RFC8439], which Data (AEAD) construction such as ChaCha20-Poly1305 [RFC8439], which
additionally authenticates the message, over ChaCha20 alone. The additionally authenticates the message, over ChaCha20 alone. The
implementation's key management procedure is a simple shared key that implementation's key management procedure is a simple shared key that
is configured with the application. is configured with the application.
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 the Marker functions
only as a format check and not as an integrity check.
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. Dynamic rekeying mechanisms are outside the scope of this document.
However, GAAP can operate with external key management systems, However, GAAP can operate with external key management systems,
including automated or Dynamic Key Management (DKM) solutions. In including automated or Dynamic Key Management (DKM) solutions. In
the absence of such mechanisms, keys may be provisioned manually. 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 Encryption alone does not protect against a legitimate, keyed GAAP
node behaving badly. The message validation, per-source rate node behaving badly. The message validation, per-source rate
limiting, and duplicate-detection guidance in Section 7 apply limiting, and duplicate-detection guidance in Section 7 apply
regardless of whether encryption is in use, and the following attack regardless of whether encryption is in use, and the following attack
threats may exist with possible mitigation techniques: threats may exist with possible mitigation techniques:
* Even when an encrypted channel is used, a bad actor could be * Even when an encrypted channel is used, a bad actor could be
claiming a group address not derived from one of the group name claiming a group address not derived from one of the group name
inputs used for the Acceptable Group Hash List (see Definition of inputs used for the Acceptable Group Hash List (see Definition of
Terms section). Cooperating nodes should ignore such messages and Terms section). Cooperating nodes should ignore such messages and
not try to send Claim messages to correct the bad actor node. not try to send Claim messages to correct the bad actor node.
Note that a bad actor can spoof the source address of another Note that a bad actor can spoof the source address of another
node's Claim message, so source-address based mitigations such as node's Claim message, so source-address based mitigations are
the bad-actor list below are best-effort. best-effort. Implementations SHOULD bound the size of the bad-
actor list and treat entries as advisory hints rather than
authoritative state, since source addresses in Claim messages can
be spoofed.
* A bad actor could send an invalid timestamp giving it tie-breaking * A bad actor could send an invalid timestamp giving it tie-breaking
priority when a group address collision occurs. If the group priority when a group address collision occurs. If the group
address has been prior claimed by another node with a timestamp address has been prior claimed by another node with a timestamp
earlier than the invalid timestamp, cooperating nodes should put earlier than the invalid timestamp, cooperating nodes should put
the bad actor node on a bad-actor list and ignore future messages 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 from it. A Timestamp that appears to be more than a small,
timestamp will be accepted only if it is not implausibly far in locally configured skew allowance ahead of, or behind, the
the future relative to the receiving node's own clock (see receiver's own clock SHOULD be treated with the same tie-breaking
Section 4 for the Timestamp comparison rule). 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.
* A bad actor could send messages too often and is not adhering to * A bad actor could send messages too often and is not adhering to
the random delay or periodic timer procedures in this document. the random delay or periodic timer procedures in this document.
When this occurs, cooperating nodes should start ignoring messages When this occurs, cooperating nodes should start ignoring messages
from the bad actor node and not reset or cancel timers, or send from the bad actor node and not reset or cancel timers, or send
triggered Claim messages triggered Claim messages
9. IANA Considerations 9. IANA Considerations
IANA is requested to make the following assignments in existing IANA is requested to make the following assignments in existing
skipping to change at page 22, line 39 skipping to change at page 23, line 22
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<https://www.rfc-editor.org/info/rfc7539>. <https://www.rfc-editor.org/info/rfc7539>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[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 Appendix A. Acknowledgments
The authors would like to thank the following people for their The authors would like to thank the following people for their
motivation to start this draft. They include Chris Hopps, Acee motivation to start this draft. They include Chris Hopps, Acee
Lindem, David Lamparter, Jeff Tantsura, Nate Karstens, and Lenny Lindem, David Lamparter, Jeff Tantsura, Nate Karstens, and Lenny
Giuliano. And thank you to Gunter Van de Velde for the extensive Giuliano. And thank you to Gunter Van de Velde for the extensive
review prior to publication. review prior to publication.
Appendix B. Document Change Log Appendix B. Document Change Log
Note to the RFC Editor: please remove this appendix before Note to the RFC Editor: please remove this appendix before
publication as an RFC. publication as an RFC.
B.1. Changes to draft-ietf-pim-gaap-19 B.1. 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.2. Changes to draft-ietf-pim-gaap-19
* Submitted August 2026. * Submitted August 2026.
* Addressed many comments from Tommy, Sasha and Bo Wu as part of the * Addressed many comments from Tommy, Sasha and Bo Wu as part of the
tsvart, rtgdir and opsdir last call reviews. tsvart, rtgdir and opsdir last call reviews.
* Changes made by Mike. * Changes made by Mike.
B.2. Changes to draft-ietf-pim-gaap-18 B.3. Changes to draft-ietf-pim-gaap-18
* Submitted July 2026. * Submitted July 2026.
* Addressed review comments from Gunter Van de Velde. Major * Addressed review comments from Gunter Van de Velde. Major
changes: aligned the IPv4 address pseudocode with the requested changes: aligned the IPv4 address pseudocode with the requested
/10 allocation; clarified that GAAP's collision detection is /10 allocation; clarified that GAAP's collision detection is
network-layer only; softened the encryption interoperability claim network-layer only; softened the encryption interoperability claim
and recommended ChaCha20-Poly1305 [RFC8439] as a stronger and recommended ChaCha20-Poly1305 [RFC8439] as a stronger
alternative; made the dependency on draft-ietf-pim-updt-ipv6-dyn- alternative; made the dependency on draft-ietf-pim-updt-ipv6-dyn-
mcast-addr-grp-id normative; added UDP usage guidance per RFC8085. mcast-addr-grp-id normative; added UDP usage guidance per RFC8085.
skipping to change at page 23, line 38 skipping to change at page 24, line 38
RFC8536 timestamp reference; marked the GAAP API as illustrative; RFC8536 timestamp reference; marked the GAAP API as illustrative;
fully specified the IPv6 address format; clarified the claim/ fully specified the IPv6 address format; clarified the claim/
response wait window, per-group-address suppression, and the new- response wait window, per-group-address suppression, and the new-
node collision state machine; clarified that address release is node collision state machine; clarified that address release is
local-only; clarified group-name uniqueness scope and GAAP's soft- local-only; clarified group-name uniqueness scope and GAAP's soft-
state model; and aligned the IANA UDP port and multicast address state model; and aligned the IANA UDP port and multicast address
requests with RFC6335 and RFC5771 guidance. requests with RFC6335 and RFC5771 guidance.
* Changes made by Mike. * Changes made by Mike.
B.3. Changes to draft-ietf-pim-gaap-17 B.4. Changes to draft-ietf-pim-gaap-17
* Submitted June 2026. * Submitted June 2026.
* Addressed comments from Stig clarifying IANA requests, adding a * Addressed comments from Stig clarifying IANA requests, adding a
paragraph on why GAAP is Experimental and wrapping code in CODE paragraph on why GAAP is Experimental and wrapping code in CODE
BEGINS/ENDS. BEGINS/ENDS.
* Changes made by Mike. * Changes made by Mike.
B.4. Changes to draft-ietf-pim-gaap-16 B.5. Changes to draft-ietf-pim-gaap-16
* Submitted June 2026. * Submitted June 2026.
* Addressed comments from Stig involving adding a boilerplate, new * Addressed comments from Stig involving adding a boilerplate, new
normative references and changing a few musts to MUST. normative references and changing a few musts to MUST.
* Changes made by Mike. * Changes made by Mike.
B.5. Changes to draft-ietf-pim-gaap-15 B.6. Changes to draft-ietf-pim-gaap-15
* Submitted April 2026. * Submitted April 2026.
* Addressed comments from the IntDir review by Sheng Jiang. * Addressed comments from the IntDir review by Sheng Jiang.
* Changes made by Mike. * Changes made by Mike.
B.6. Changes to draft-ietf-pim-gaap-14 B.7. Changes to draft-ietf-pim-gaap-14
* Submitted April 2026. * Submitted April 2026.
* Clarified statements in the Operational Considerations section. * Clarified statements in the Operational Considerations section.
* Changes made by Mike. * Changes made by Mike.
B.7. Changes to draft-ietf-pim-gaap-13 B.8. Changes to draft-ietf-pim-gaap-13
* Submitted April 2026. * Submitted April 2026.
* Created a new Operational Considerations section to reflect * Created a new Operational Considerations section to reflect
comments from Med. comments from Med.
* Changes made by Mike. * Changes made by Mike.
B.8. Changes to draft-ietf-pim-gaap-12 B.9. Changes to draft-ietf-pim-gaap-12
* Submitted March 2026. * Submitted March 2026.
* Made changes to reflect Sandy comments about clarifying how * Made changes to reflect Sandy comments about clarifying how
multiple group names could cause collisions as well as clarifying multiple group names could cause collisions as well as clarifying
text about encryption. text about encryption.
* Changes made by Dino. * Changes made by Dino.
B.9. Changes to draft-ietf-pim-gaap-11 B.10. Changes to draft-ietf-pim-gaap-11
* Submitted March 2026. * Submitted March 2026.
* Change IANA request for an IPv4 multicast block from /8 to /10. * Change IANA request for an IPv4 multicast block from /8 to /10.
* Changes made by Dino. * Changes made by Dino.
B.10. Changes to draft-ietf-pim-gaap-10 B.11. Changes to draft-ietf-pim-gaap-10
* Submitted February 2026. * Submitted February 2026.
* Incorporated suggestion from Toerless Eckert to add paragraph * Incorporated suggestion from Toerless Eckert to add paragraph
discussing SAP and SDP approaches to multicast group allocation in discussing SAP and SDP approaches to multicast group allocation in
the Introduction section. the Introduction section.
* Added references to RFC2974 (SAP) and RFC4566 (SDP). * Added references to RFC2974 (SAP) and RFC4566 (SDP).
* Changes made by Dino. * Changes made by Dino.
B.11. Changes to draft-ietf-pim-gaap-09 B.12. Changes to draft-ietf-pim-gaap-09
* Submitted February 2026. * Submitted February 2026.
* Be more clear about variable length group names and how subsequent * Be more clear about variable length group names and how subsequent
records may not be aligned. records may not be aligned.
* Changes made by Dino. * Changes made by Dino.
B.12. Changes to draft-ietf-pim-gaap-08 B.13. Changes to draft-ietf-pim-gaap-08
* Submitted February 2026. * Submitted February 2026.
* Incorporated WG review comments from Stig Venaas on GAAP Group * Incorporated WG review comments from Stig Venaas on GAAP Group
Address definition, Timestamp field documentation, encryption Address definition, Timestamp field documentation, encryption
interoperability requirements, and IANA allocation discussion. interoperability requirements, and IANA allocation discussion.
* Changes made by Dino. * Changes made by Dino.
B.13. Changes to draft-ietf-pim-gaap-07 B.14. Changes to draft-ietf-pim-gaap-07
* Submitted January 2026. * Submitted January 2026.
* Change draft name in IANA considerations section to point to the * Change draft name in IANA considerations section to point to the
IETF draft name and not the individual contribution draft name. IETF draft name and not the individual contribution draft name.
* Changes made by Dino. * Changes made by Dino.
B.14. Changes to draft-ietf-pim-gaap-06 B.15. Changes to draft-ietf-pim-gaap-06
* Submitted September 2025. * Submitted September 2025.
* Dino fixes Kasten reference. * Dino fixes Kasten reference.
B.15. Changes to draft-ietf-pim-gaap-05 B.16. Changes to draft-ietf-pim-gaap-05
* Submitted September 2025. * Submitted September 2025.
* Mike adds one-liner to abstract. * Mike adds one-liner to abstract.
B.16. Changes to draft-ietf-pim-gaap-04 B.17. Changes to draft-ietf-pim-gaap-04
* Submitted August 2025. * Submitted August 2025.
* Fix some typos in the GAAP API section. * Fix some typos in the GAAP API section.
B.17. Changes to draft-ietf-pim-gaap-03 B.18. Changes to draft-ietf-pim-gaap-03
* Submitted February 2025. * Submitted February 2025.
* Fix some typos in the GAAP API section. * Fix some typos in the GAAP API section.
* Update references and docuemnt timer. * Update references and docuemnt timer.
B.18. Changes to draft-ietf-pim-gaap-02 B.19. Changes to draft-ietf-pim-gaap-02
* Submitted September 2024. * Submitted September 2024.
* Update references and docuemnt timer. * Update references and docuemnt timer.
B.19. Changes to draft-ietf-pim-gaap-01 B.20. Changes to draft-ietf-pim-gaap-01
* Submitted April 2024. * Submitted April 2024.
* Update references and docuemnt timer. * Update references and docuemnt timer.
B.20. Changes to draft-ietf-pim-gaap-00 B.21. Changes to draft-ietf-pim-gaap-00
* Submitted October 2023. * Submitted October 2023.
* Made draft-farinacci-pim-gaap-06 into WG document per PIM WG * Made draft-farinacci-pim-gaap-06 into WG document per PIM WG
consensus. consensus.
B.21. Changes to draft-farinacci-pim-gaap-06 B.22. Changes to draft-farinacci-pim-gaap-06
* Submitted September 2023. * Submitted September 2023.
* Fix Nate last name misspelling. * Fix Nate last name misspelling.
* Add reference to [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] to * Add reference to [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] to
intro section. intro section.
* In the IANA Considerations, add IPv6 allocation for GAAP in the * In the IANA Considerations, add IPv6 allocation for GAAP in the
0xA0000000-0xAFFFFFFF range, as suggested by Nate. 0xA0000000-0xAFFFFFFF range, as suggested by Nate.
B.22. Changes to draft-farinacci-pim-gaap-05 B.23. Changes to draft-farinacci-pim-gaap-05
* Submitted August 2023. * Submitted August 2023.
* Update IANA Considerations section to have IPv6 GAAP application * Update IANA Considerations section to have IPv6 GAAP application
allocations come from the registry that allocations come from the registry that
[I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id] is creating. [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id] is creating.
B.23. Changes to draft-farinacci-pim-gaap-04 B.24. Changes to draft-farinacci-pim-gaap-04
* Submitted April 2023. * Submitted April 2023.
* Added specific text recommended by IANA in the IANA Considerations * Added specific text recommended by IANA in the IANA Considerations
section. section.
B.24. Changes to draft-farinacci-pim-gaap-03 B.25. Changes to draft-farinacci-pim-gaap-03
* Submitted April 2023. * Submitted April 2023.
* Changes to reflect comments from PIM and MBONED WG meetings. * Changes to reflect comments from PIM and MBONED WG meetings.
* Put IANA Considerations requests in standard request format. * Put IANA Considerations requests in standard request format.
B.25. Changes to draft-farinacci-pim-gaap-02 B.26. Changes to draft-farinacci-pim-gaap-02
* Submitted March 2023. * Submitted March 2023.
* Fix typos and grammer. * Fix typos and grammer.
B.26. Changes to draft-farinacci-pim-gaap-01 B.27. Changes to draft-farinacci-pim-gaap-01
* Submitted February 2023. * Submitted February 2023.
* Updated spec to reflect implementation. * Updated spec to reflect implementation.
* Add Marker in message format. * Add Marker in message format.
* Add definition for the Acceptable Group Hash List. * Add definition for the Acceptable Group Hash List.
* Discuss security threats and possible mitigation methods. * Discuss security threats and possible mitigation methods.
B.27. Changes to draft-farinacci-pim-gaap-00 B.28. Changes to draft-farinacci-pim-gaap-00
* Initial posting November 2022. * Initial posting November 2022.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA San Jose, CA
United States of America United States of America
Email: farinacci@gmail.com Email: farinacci@gmail.com
 End of changes. 44 change blocks. 
80 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff