Network Working Group D. Farinacci
Internet-Draft lispers.net
Intended status: Experimental M. McBride
Expires: 22 May 2023 Futurewei
18 November 2022
Group Address Allocation Protocol (GAAP)
draft-farinacci-pim-gaap-00
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"). The protocol requires no
configuration setup and no centralized services. The protocol runs
among group participants which need a unique group address to send
and receive multicast packets.
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 22 May 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Farinacci & McBride Expires 22 May 2023 [Page 1]
Internet-Draft Group Address Allocation Protocol (GAAP) November 2022
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Protocol Operation . . . . . . . . . . . . . . . 3
4. GAAP Message Format . . . . . . . . . . . . . . . . . . . . . 4
5. GAAP API . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. gaap.init() . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. gaap.allocate() . . . . . . . . . . . . . . . . . . . . . 6
5.3. gaap.release() . . . . . . . . . . . . . . . . . . . . . 6
6. Detail Protocol Operation . . . . . . . . . . . . . . . . . . 7
6.1. Allocating Group Addresses . . . . . . . . . . . . . . . 7
6.2. Claiming Group Addresses . . . . . . . . . . . . . . . . 8
6.3. Partition Repair . . . . . . . . . . . . . . . . . . . . 8
6.4. Releasing Group Addresses . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10
B.1. Changes to draft-farinacci-pim-gaap-00 . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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.
Other approaches to multicast group allocation have been proposed in
the past, they include mDNS [RFC6762], MADCAP [RFC2730], MASC
[RFC2909], and IPv6 Allocation Guidelines [RFC3307]. However, they
require configuration, used on a single subnet, and are not
decentralized.
Farinacci & McBride Expires 22 May 2023 [Page 2]
Internet-Draft Group Address Allocation Protocol (GAAP) November 2022
This document will describe the protocol operation, protocol message
formats, the API definition, and how multicast applications use the
API.
2. Definition of Terms
Group Name: is an ASCII string used by applications so they can
rendezvous on the same group address. The application is started
using this group name parameter. Applications can use multiple
group names if they have requirements to use multiple group
addresses.
Group Address: is a non-link-local IPv4 multicast group address
[RFC1112] or an IPv6 multicast group address [RFC4291].
GAAP Group Address: is an IANA assigned non-link-local group address
the GAAP protocol sends messages to. This address must not come
from the GAAP multicast address block allocated by IANA.
Hash Function: is a cryptographic hash function which takes the
group name as input and produces a hash value as output. The GAAP
protocol uses SHA-256 [RFC6234].
Hashed Value: is the output of a SHA-256 [RFC6234] hash function
where the low order 32-bits are used to produce a unique network
layer multicast group address. Achieving a unique 32-bits allows
layer-2 switches to not have MAC multicast address collisions when
mapped from multiple network layer multicast group addresses.
Collided Group Address: a network layer group address where the low-
order 32-bits of one group address is the same as the low-order
32-bits of another group address. It is desirable that the the
low-order 32-bits of a mapped IPv6 group address to a MAC group
address not be the same so layer-2 switches do not leak packets to
non-group members. This is also true for IPv4 group addresses
where the low-order 23-bits must be unique.
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.
Farinacci & McBride Expires 22 May 2023 [Page 3]
Internet-Draft Group Address Allocation Protocol (GAAP) November 2022
* 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.
* If no Claim message is sent in response, the application can start
using the group address.
* If a Claim message is returned, a collision has occurred and the
GAAP node must allocate another group address and send a Claim
message for the new group address.
* Claim messages are sent periodically. They are sent by a single
node using a delay-timer suppression mechanism similar to IGMP
[RFC1112]. 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 message called the Claim message with
type value 1. Type value of 0 is reserved. The Claim message is
sent in a UDP checksummed packet where the source port is ephemeral
and chosen by the sender and the destination port is a well-known
port allocated by IANA. GAAP can work behind NAT and firewall
devices as long as the GAAP destination port is permitted through
filters.
Farinacci & McBride Expires 22 May 2023 [Page 4]
Internet-Draft Group Address Allocation Protocol (GAAP) November 2022
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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=1: Claim Message
Reserved: Set to 0 and ignored on receipt.
Record Count: The number of records in this Claim message.
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.
Timestamp: Standard epoch UTC timestamp according to [RFC8536].
Group Name: A variable length group name the multicast
application uses. It is in ASCII format [RFC0020]. The string
is terminated with a null character.
Farinacci & McBride Expires 22 May 2023 [Page 5]
Internet-Draft Group Address Allocation Protocol (GAAP) November 2022
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.
5.1. gaap.init()
gapp.init() is used to initialize the GAAP API with a application
callback function. The callback function is called when a group
address has changed (due to collision) for a group name the
application allocated.
import gapp
status = gapp.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
5.2. gaap.allocate()
gaap.allocate() is used when the application needs a group address to
send or receive on.
import gapp
group_name = "my-audio-group"
group_address = gapp.allocate(group_name)
if (group_address == None):
print("error")
exit(1)
#endif
print("Name {} allocated address {}".format(group_name, group_address))
5.3. gaap.release()
gaap.release() is used when an application is finished using a group
address.
Farinacci & McBride Expires 22 May 2023 [Page 6]
Internet-Draft Group Address Allocation Protocol (GAAP) November 2022
import gapp
group_address = gapp.allocate("my-audio-group")
status = gapp.release(group_address)
if (status == False):
print("error")
exit(1)
#endif
print("Released address {}".format(group_address))
6. Detail 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]. Initially, when no group address collision is
detected the group name is passed as a string to the hash function
and the low-order 32-bits are used for a group address. The
following pseudo-code illustrates the functionality:
hash = sha256(group_name)
low_bits = hash & 0xffffffff
if (v4):
group_address = 0xe0000000 | (low_bits & 0x007fffff)
#endif
if (v6):
group_address = 0xff02...0000 | low_bits
#endif
return(group_address)
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"]:
hash = sha256(group_name + append)
group_address = make_group_from_hash(hash)
collision = send_claim(group_address)
if (collision == False): return
#endfor
print("Collision limit reached")
Farinacci & McBride Expires 22 May 2023 [Page 7]
Internet-Draft Group Address Allocation Protocol (GAAP) November 2022
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.
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 for this 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 rough 1 minute timer. The timer value is set to 1 minute
plus a jitter value. The jitter value is a random number in a 10%
range of 1 minute (60 to 66 seconds). When the timer expires, a
Claim message is sent. Receivers of a Claim message who have their
timer running, reset the timer and thereby suppresses sending their
own Claim message. This allows only a single GAAP node that is using
the group address to keep claiming the group is still in use.
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. All others will have
to rehash a new group address and have the applications start using
the new address (meaning senders will source using the new group
address and receivers will leave the collided group and join the new
group).
Farinacci & McBride Expires 22 May 2023 [Page 8]
Internet-Draft Group Address Allocation Protocol (GAAP) November 2022
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. 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.
7. Security Considerations
There are no security considerations at this time. However,
mechanisms are required to protect the GAAP group from being DoS
attacked. And the privacy of Claim messages need to be maintained to
circumvent man-in-the-middle eavesdropping attempts. This is work in
progress.
8. IANA Considerations
This document makes several requests for IANA. The first is to
allocate a well-known UDP port number for the GAAP protocol. The
second is to allocate IPv4 and IPv6 multicast addresses the GAAP
protocol uses to send messages to. And the third is to allocate a
multicast address block where GAAP allocated group addresses come
from.
9. References
9.1. Normative References
[RFC0020] Cerf, V. and RFC Publisher, "ASCII format for network
interchange", STD 80, RFC 20, DOI 10.17487/RFC0020,
October 1969, <https://www.rfc-editor.org/info/rfc20>.
[RFC1112] Deering, S. and RFC Publisher, "Host extensions for IP
multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112,
August 1989, <https://www.rfc-editor.org/info/rfc1112>.
[RFC4291] Hinden, R., Deering, S., and RFC Publisher, "IP Version 6
Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291,
February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC6234] Eastlake 3rd, D., Hansen, T., and RFC Publisher, "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>.
Farinacci & McBride Expires 22 May 2023 [Page 9]
Internet-Draft Group Address Allocation Protocol (GAAP) November 2022
[RFC8536] Olson, A., Eggert, P., Murchison, K., and RFC Publisher,
"The Time Zone Information Format (TZif)", RFC 8536,
DOI 10.17487/RFC8536, February 2019,
<https://www.rfc-editor.org/info/rfc8536>.
9.2. Informative References
[RFC2730] Hanna, S., Patel, B., Shah, M., and RFC Publisher,
"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., Thaler, D., and RFC Publisher, "The Multicast
Address-Set Claim (MASC) Protocol", RFC 2909,
DOI 10.17487/RFC2909, September 2000,
<https://www.rfc-editor.org/info/rfc2909>.
[RFC3307] Haberman, B. and RFC Publisher, "Allocation Guidelines for
IPv6 Multicast Addresses", RFC 3307, DOI 10.17487/RFC3307,
August 2002, <https://www.rfc-editor.org/info/rfc3307>.
[RFC6762] Cheshire, S., Krochmal, M., and RFC Publisher, "Multicast
DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
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, and Nate Karsens.
Appendix B. Document Change Log
B.1. 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 22 May 2023 [Page 10]
Internet-Draft Group Address Allocation Protocol (GAAP) November 2022
Mike McBride
Futurewei
Santa Clara, CA
United States of America
Email: mmcbride7@gmail.com
Farinacci & McBride Expires 22 May 2023 [Page 11]