The Multicast Application Port
draft-ietf-intarea-multicast-application-port-09

Network Working Group                                        N. Karstens
Internet-Draft                                                    Garmin
Intended status: Standards Track                             S. Cheshire
Expires: 6 May 2027                                           Apple Inc.
                                                              M. McBride
                                                               Futurewei
                                                         2 November 2026

                     The Multicast Application Port
            draft-ietf-intarea-multicast-application-port-09

Abstract

   This document discusses the drawbacks of the current practice of
   assigning a UDP port to each multicast application.  Such assignments
   are redundant because the multicast group address already uniquely
   identifies the data.  This document assigns a UDP port specifically
   for use with multicast applications and lists requirements for using
   this port.  This approach provides immediate compatibility with
   existing protocol stacks, and this document also defines host
   enhancements that help safeguard the ongoing cooperative use of this
   port by multicast applications.

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 6 May 2027.

Copyright Notice

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

Karstens, et al.           Expires 6 May 2027                   [Page 1]
Internet-Draft               Mcast App Port                November 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Multicast Address Assignment  . . . . . . . . . . . . . .   5
   3.  Assignment  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Application Requirements  . . . . . . . . . . . . . . . . . .   5
   5.  Host Requirements . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Firewall Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Terminology

   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.

   This document uses the term "multicast group address" to refer
   collectively to the IP destination address for Any-Source Multicast
   (ASM) [RFC1112], and the (S,G) pair for Source-Specific Multicast
   (SSM) [RFC4607], since they serve the same functional purpose.  Both
   exist to identify a stream of packets related to a particular
   activity.  The network's multicast routing infrastructure uses the
   multicast group address to determine where packets should be
   forwarded, so that they reach all group members that need them,
   without being delivered to hosts or networks that do not.

Karstens, et al.           Expires 6 May 2027                   [Page 2]
Internet-Draft               Mcast App Port                November 2026

   For the purposes of this document, a "multicast packet" is a packet
   addressed to a valid multicast group address.  A "non-multicast
   packet" is a packet with any other destination address, including
   unicast, anycast, and the broadcast address.

   This document describes each separate usage of an application as an
   "instantiation" of that application.  For example, a multicast
   videoconferencing application may be in use all over the world for a
   thousand different videoconference meetings at the same time.  It
   would be terribly inefficient (and would defeat the purpose of
   multicast) if all the meetings were to use the same multicast group,
   and all copies of the application were to receive all the traffic for
   all videoconference meetings taking place at that time.
   Consequently, each instantiation of a multicast application requires
   its own unique multicast group address.  How a unique multicast group
   address is assigned for each instantiation is addressed by other IETF
   documents, such as the guidelines for IPv4 multicast address
   assignment [RFC5771] and for IPv6 multicast address assignment
   [RFC3307] [RFC10028].

2.  Introduction

   The Internet community has recognized the need to be judicious when
   assigning port numbers ([RFC6335]; [RFC7605], Section 6).  With
   unicast applications, the need for explicit port assignment has been
   reduced by techniques such as locally assigning a dynamic port,
   combined with some mechanism for advertising that port ([RFC6763];
   [RFC7605], Section 7.1).  Dynamic assignment does not work with
   multicast applications because it is impossible to guarantee that the
   port remains unused by all hosts that may want to join a given
   multicast group.  The result is that traditionally each multicast
   application-layer protocol has requested its own dedicated port
   assignment.  It might seem that even this is insufficient, and
   perhaps each instantiation of each multicast application-layer
   protocol should be assigned its own unique port.  In fact, this is
   not necessary.

   In the TCP/IP model, the port number in the transport layer
   multiplexes unicast traffic destined for different applications
   within a host ([RFC1122], Section 4.1.1; [RFC7605], Section 5).  With
   multicast, the use of a port number to multiplex applications is
   unnecessary because the multicast group address already provides a
   unique identifier for each application instantiation within a given
   multicast scope.  Techniques like SO_REUSEPORT (details vary
   depending on the specific network API) already exist to allow
   multiple copies of the same multicast application to run on the same
   host and share a single UDP port.  This approach is widely used to
   run multiple independent implementations of Multicast DNS [RFC6762]

Karstens, et al.           Expires 6 May 2027                   [Page 3]
Internet-Draft               Mcast App Port                November 2026

   on a single device.  This observation is the inspiration behind this
   specification.  If the destination port number is not needed for
   multicast traffic, and multiple instantiations of the same
   application can share a single port, then, by the same logic, _all_
   multicast applications can share a single port, as long as they
   cooperate and use the appropriate API mechanisms to share that port.
   This specification codifies this existing practice, and assigns a
   single UDP port that may be used by all multicast applications: the
   Multicast Application Port.

   The Multicast Application Port can be used with both IPv6 and IPv4.

   Multicast applications can begin using the Multicast Application Port
   immediately, following the guidance in Section 4, on any platform
   that supports SO_REUSEPORT or an equivalent.  In addition, network
   protocol stacks and APIs can assist in the future development of such
   applications by enforcing special rules to ensure correct use of the
   Multicast Application Port.  This helps detect and prevent
   inadvertent application bugs that would interfere with the correct
   sharing of this port (Section 5).  Deployment of these special
   protections is expected to take place incrementally, but applications
   are free to use the Multicast Application Port without waiting for
   host APIs to begin enforcing the protections.

   In effect, the Multicast Application Port becomes a vestigial
   placeholder value, present only because the UDP packet format
   requires a value in the destination port field.  At most, it
   signifies that this traffic is multicast.  However, even that
   information is redundant, since the fact that the traffic is
   multicast can be inferred by observing that the destination IP
   address is a multicast address.

   Use of this port is optional.  There may be circumstances where there
   are reasons to assign a port via other means, such as when
   participants cannot meet the requirements in Sections 4 and 5, or
   when a firewall blocks a traffic pattern used by the application
   (Section 6).

   An application sending multicast messages using the Multicast
   Application Port as the destination port may also send unicast
   messages using a different destination port.  One possible benefit of
   doing so is to mitigate the limitations of multicast delivery,
   particularly on wireless media [RFC9119].

Karstens, et al.           Expires 6 May 2027                   [Page 4]
Internet-Draft               Mcast App Port                November 2026

2.1.  Multicast Address Assignment

   The ability to identify a multicast application instantiation by its
   multicast group address assumes that a unique multicast group address
   has been assigned to the application instantiation.  These
   assignments are outside the scope of this document.  Additional
   information can be obtained from the overview of the Internet
   multicast addressing architecture [RFC6308] and the following IANA
   registry groups:

   *  IPv4 Multicast Address Space [MCast4]

   *  IPv6 Multicast Address Space [MCast6]

3.  Assignment

   This document _requests_ assignment of UDP port 8738 (0x2222) with
   the service name "multicast-app".

   ASM application instantiations using the Multicast Application Port
   are identified by the destination multicast address.  SSM application
   instantiations using the Multicast Application Port are identified by
   their (S,G) channel, a combination of source unicast address and
   destination multicast address [RFC4607].  Because unicast traffic
   carries no such identifier, the Multicast Application Port MUST NOT
   be used as either a source port or destination port for any non-
   multicast packets.

   The Multicast Application Port MAY be used as a source port by an
   application that sends only multicast messages.

   If any application messages are unicast, then it is RECOMMENDED that
   the source port used for multicast messages be set to the port to
   which receivers can send unicast replies.  Note that such
   arrangements would likely require each participant to use multiple
   sockets, because it must bind to both the Multicast Application Port
   and its unicast port.

4.  Application Requirements

   Applications that use the Multicast Application Port MUST meet the
   requirements in this section.

Karstens, et al.           Expires 6 May 2027                   [Page 5]
Internet-Draft               Mcast App Port                November 2026

   Application instantiations SHALL NOT prevent other application
   instantiations from using this port.  On hosts using POSIX-like
   socket APIs [POSIX], this is typically accomplished by enabling a
   socket option before binding the socket.  Common socket options
   include SO_REUSEADDR, SO_REUSEPORT, and SO_REUSE_MULTICASTPORT, but
   the specific mechanism varies by platform.

   For efficiency, applications SHOULD use networking APIs in such a way
   to minimize reception of unwanted traffic that the application then
   immediately has to discard.  For example, on some platforms it may be
   prudent to bind a socket to the application instantiation's multicast
   group address and the Multicast Application Port, so that it only
   receives the packets it wants.  (Note that with BSD Sockets and
   similar APIs, just binding to the appropriate multicast group address
   alone is insufficient.  After binding, the application then needs to
   use IP_ADD_MEMBERSHIP, IPV6_JOIN_GROUP, MCAST_JOIN_GROUP,
   MCAST_JOIN_SOURCE_GROUP, or equivalent to tell the networking stack
   that it actually wants to receive traffic sent to that multicast
   group address.)  However, this approach limits applications to only
   one multicast group address per socket.  An alternative approach, on
   platforms which deliver only traffic for groups the socket has joined
   (e.g., Linux with IP_MULTICAST_ALL=0 or IPV6_MULTICAST_ALL=0), is to
   bind the socket to the wildcard (zero) address ([RFC3493],
   Section 3.8) and then have that socket join the desired multicast
   group(s).

   Applications SHALL discard all non-multicast packets received that
   use the Multicast Application Port as either a source or destination
   port.

   Furthermore, to guard against operating systems that do not perform
   the inbound traffic filtering described here, application
   instantiations SHALL discard datagrams received on the Multicast
   Application Port unless they are addressed to a multicast group
   address being used by that application instantiation (and received on
   the desired network interface, if specified).  Relevant socket API
   mechanisms such as IP_PKTINFO and IPV6_PKTINFO are described in the
   Advanced Sockets API for IPv6 [RFC3542] and "Socket Interface
   Extensions for Multicast Source Filters" [RFC3678].

   Applications SHALL NOT send any non-multicast packets using the
   Multicast Application Port as either a source port or destination
   port.

Karstens, et al.           Expires 6 May 2027                   [Page 6]
Internet-Draft               Mcast App Port                November 2026

5.  Host Requirements

   Hosts implementing this specification SHALL require applications
   using this port to use it non-exclusively.  On hosts using POSIX-like
   socket APIs [POSIX], this is typically accomplished by enabling a
   socket option before binding the socket.  Common socket options
   include SO_REUSEADDR, SO_REUSEPORT, and SO_REUSE_MULTICASTPORT, but
   each platform provides its own method.  This requirement ensures that
   applications developed on a conformant host will follow the correct
   rules, and therefore also work correctly on older hosts that do not
   enforce the protections on the Multicast Application Port.

   If the application fails to follow the correct steps to share the
   Multicast Application Port, then the networking API SHALL return an
   error code, throw an exception, or otherwise fail the application's
   attempt to bind to the Multicast Application Port.  This helps the
   application developer discover their mistake and correct it.  The
   networking API MUST NOT try to be "helpful" by silently correcting
   the misbehaving application and automatically granting it shared
   access to the Multicast Application Port.  Doing so would defeat the
   goal of ensuring that a properly written application will work both
   on platforms that implement these protections and on older platforms
   that do not.

   For efficiency, hosts SHOULD deliver to an application endpoint
   (e.g., socket) only packets addressed to the multicast group
   address(es) that the application endpoint has joined.  Technically,
   this is not essential, since applications are required to discard
   datagrams received on the Multicast Application Port if they are not
   addressed to the multicast group address the application endpoint has
   joined (and received on the desired network interface, if specified).
   However, it is advisable to perform this filtering for efficiency,
   since it is wasteful to deliver packets to an application endpoint
   only to have that application promptly discard them.

   Hosts SHALL discard all incoming non-multicast packets that use the
   Multicast Application Port as either a source or destination port.

   Hosts SHALL prevent applications from sending non-multicast packets
   using the Multicast Application Port as either a source or
   destination port by having the send operation return an error code.

   Some networking APIs provide a mechanism to allow client software to
   disable generation and checking of checksums for UDP packets
   [RFC6935] [RFC6936] (e.g., the Linux SO_NO_CHECK socket option).
   Where networking APIs support disabling UDP checksums, this MUST be
   implemented per endpoint (socket), as Linux does, not as a system-
   wide default or per-port option.  With different multicast protocols

Karstens, et al.           Expires 6 May 2027                   [Page 7]
Internet-Draft               Mcast App Port                November 2026

   sharing the Multicast Application Port, the UDP port cannot be used
   to identify a traffic flow to determine what UDP checksum policy to
   apply.

6.  Firewall Considerations

   Many network firewalls, which operate on network infrastructure, and
   host firewalls, which operate on individual hosts, are configured to
   accept incoming messages as long as there was first an outgoing
   message using the same set of ports [RFC7288].  Consider the
   following sequence of messages:

   1.  (Multicast) Host A to group containing Host B
       Source Port: 50000 (Dynamic)
       Dest Port: 8738 (0x2222)

   2.  (Unicast) Host B to Host A
       Source Port: 60000 (Dynamic)
       Dest Port: 50000

   3.  (Unicast) Host A to Host B
       Source Port: 50000
       Dest Port: 60000

   A host firewall running on Host A (or a network firewall between Host
   A and Host B) may block Message 2 because Message 1 has port 8738 as
   its destination port but Message 2 does not have (and is not allowed
   to have) port 8738 as its source port.

   While a firewall could be configured to accept Message 2, this
   configuration would have to be automated because the use of dynamic
   ports makes manual configuration too costly even in small
   deployments.  However, this automation leads to unacceptable security
   risks.  For example, if a firewall were to respond to Message 1 by
   opening up the source port used in the message, a malicious
   application running on the host could open large holes in the
   firewall by repeatedly sending variations of Message 1 using
   different source ports.

   Host firewalls could be configured to allow messages associated with
   a given application instantiation (instead of specific ports), but
   this approach would not work with a network firewall.

   Ultimately, the current practice of assigning each multicast
   application its own port is more practical for any application that
   uses both multicast and unicast messages and could be deployed in an
   environment using firewalls.  Firewall configuration with an assigned
   port is straightforward: allow all messages using that port.

Karstens, et al.           Expires 6 May 2027                   [Page 8]
Internet-Draft               Mcast App Port                November 2026

   However, port-based rules offer limited assurance, because a rogue
   application can use the same port to masquerade as the legitimate
   trusted application.

7.  Implementation Status

   Note to RFC Editor: please remove this entire section before
   publication, as well as the reference to RFC7942.

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on the IETF's guidance on improving
   awareness of running code [RFC7942].  The description of
   implementations in this section is intended to assist the IETF in its
   decision processes in progressing drafts to RFCs.  Please note that
   the listing of any individual implementation here does not imply
   endorsement by the IETF.  Furthermore, no effort has been spent to
   verify the information presented here that was supplied by IETF
   contributors.  This is not intended as, and must not be construed to
   be, a catalog of available implementations or their features.
   Readers are advised to note that other implementations may exist.

   According to that guidance, "this will allow reviewers and working
   groups to assign due consideration to documents that have the benefit
   of running code, which may serve as evidence of valuable
   experimentation and feedback that have made the implemented protocols
   more mature.  It is up to the individual working groups to use this
   information as they see fit".

   Prototypes for Linux, macOS, and Windows are available at
   <https://github.com/ietf-wg-pim/draft-ietf-intarea-multicast-
   application-port/>.  These programs configure a socket to receive
   messages sent to the Multicast Application Port using a specified
   multicast address.  Another program, such as socat, can be used to
   send messages and demonstrate, with an unmodified operating system,
   that the prototype will (1) display messages sent to the Multicast
   Application Port using the specified multicast address, and (2) _not_
   display messages sent to the Multicast Application Port but addressed
   to a different multicast address.

8.  Security Considerations

   Firewall and QoS rules that reference ports are typically intended to
   match specific applications.  Because application instantiations
   using the Multicast Application Port are identified by their
   destination multicast address (ASM) or (S,G) channel (SSM), rules
   referencing the Multicast Application Port SHOULD also consider any
   applicable network-layer address.  A firewall rule that only

Karstens, et al.           Expires 6 May 2027                   [Page 9]
Internet-Draft               Mcast App Port                November 2026

   references the Multicast Application Port would match all
   applications using that port, which is too broadly scoped.

   Applications running on a host that does not protect the Multicast
   Application Port from misuse are vulnerable to a denial-of-service
   attack if another application claims exclusive access to the port.
   This vulnerability is not unique to the Multicast Application Port.
   Regardless of which port an application uses, a malicious application
   could claim exclusive access to that port first, and thereby prevent
   the legitimate application from being able to use its port.

   Systems that use POSIX-like socket APIs typically have restrictions
   on binding multiple sockets to the same port.  This can serve as a
   rudimentary security mechanism in that other local applications
   cannot eavesdrop on the multicast stream.  A necessary side effect of
   using the Multicast Application Port is that applications can no
   longer rely on this protection.  These applications should consider
   incorporating additional security measures into their protocol.  Note
   that the problem of local eavesdropping is typically no worse than
   on-path eavesdropping, so it is likely that both attack vectors can
   be mitigated by the same measure (e.g., encryption).

9.  IANA Considerations

   IANA is _requested_ to assign the following port:

   Service Name        multicast-app
   Transport Protocol  UDP
   Assignee            IESG <iesg@ietf.org>
   Contact             IETF Chair <chair@ietf.org>
   Description         Multicast Application Port
   Reference           This document
   Port Number         8738

   IANA is requested to update its "Application for Service Names and
   User Port Numbers" [IANA-APP] to reference this document and ask
   applicants whether the Multicast Application Port could be used
   instead.  These changes will help applicants understand that a
   dedicated port may be unnecessary for their multicast protocol.

10.  References

10.1.  Normative References

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

Karstens, et al.           Expires 6 May 2027                  [Page 10]
Internet-Draft               Mcast App Port                November 2026

   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6",
              RFC 3493, DOI 10.17487/RFC3493, March 2003,
              <https://www.rfc-editor.org/info/rfc3493>.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
              <https://www.rfc-editor.org/info/rfc4607>.

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

10.2.  Informative References

   [IANA-APP] Internet Assigned Numbers Authority, "Application for
              Service Names and User Port Numbers",
              <https://www.iana.org/form/ports-services>.

   [MCast4]   Internet Assigned Numbers Authority, "IPv4 Multicast
              Address Space",
              <https://www.iana.org/assignments/multicast-addresses>.

   [MCast6]   Internet Assigned Numbers Authority, "IPv6 Multicast
              Address Space", <https://www.iana.org/assignments/ipv6-
              multicast-addresses>.

   [POSIX]    The Open Group, "Portable Operating System Interface Base
              Specifications, Issue 7", January 2018,
              <https://pubs.opengroup.org/onlinepubs/9699919799/>.

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

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.

   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, DOI 10.17487/RFC3307, September
              2002, <https://www.rfc-editor.org/info/rfc3307>.

   [RFC3542]  Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
              "Advanced Sockets Application Program Interface (API) for
              IPv6", RFC 3542, DOI 10.17487/RFC3542, June 2003,
              <https://www.rfc-editor.org/info/rfc3542>.

Karstens, et al.           Expires 6 May 2027                  [Page 11]
Internet-Draft               Mcast App Port                November 2026

   [RFC3678]  Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
              Extensions for Multicast Source Filters", RFC 3678,
              DOI 10.17487/RFC3678, January 2004,
              <https://www.rfc-editor.org/info/rfc3678>.

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

   [RFC6308]  Savola, P., "Overview of the Internet Multicast Addressing
              Architecture", RFC 6308, DOI 10.17487/RFC6308, June 2011,
              <https://www.rfc-editor.org/info/rfc6308>.

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

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

   [RFC6935]  Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
              UDP Checksums for Tunneled Packets", RFC 6935,
              DOI 10.17487/RFC6935, April 2013,
              <https://www.rfc-editor.org/info/rfc6935>.

   [RFC6936]  Fairhurst, G. and M. Westerlund, "Applicability Statement
              for the Use of IPv6 UDP Datagrams with Zero Checksums",
              RFC 6936, DOI 10.17487/RFC6936, April 2013,
              <https://www.rfc-editor.org/info/rfc6936>.

   [RFC7288]  Thaler, D., "Reflections on Host Firewalls", RFC 7288,
              DOI 10.17487/RFC7288, June 2014,
              <https://www.rfc-editor.org/info/rfc7288>.

   [RFC7605]  Touch, J., "Recommendations on Using Assigned Transport
              Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
              August 2015, <https://www.rfc-editor.org/info/rfc7605>.

Karstens, et al.           Expires 6 May 2027                  [Page 12]
Internet-Draft               Mcast App Port                November 2026

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [RFC9119]  Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC.
              Zúñiga, "Multicast Considerations over IEEE 802 Wireless
              Media", RFC 9119, DOI 10.17487/RFC9119, October 2021,
              <https://www.rfc-editor.org/info/rfc9119>.

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

Appendix A.  Acknowledgements

   Special thanks to the National Marine Electronics Association for
   their contributions in developing marine industry standards and their
   support for this research.

   The authors are grateful to the members of the PIM and INTAREA
   working groups for their review of this document, and to the
   following individuals specifically:

   *  Joe Touch for consulting on port assignment

   *  Lorenzo Colitti for his suggestions for host requirements

   *  David Schinazi for pointing out likely port conflicts with several
      major operating systems

   *  Juliusz Chroboczek for suggestions on the source port to use for
      multicast messages when unicast replies are expected

   *  Dave Thaler for insightful discussion on how the Multicast
      Application Port would operate in the presence of a firewall

Authors' Addresses

   Nate Karstens
   Garmin International, Inc.
   1200 E. 151st St.
   Olathe, KS 66062-3426
   United States of America
   Email: nate.karstens@gmail.com

Karstens, et al.           Expires 6 May 2027                  [Page 13]
Internet-Draft               Mcast App Port                November 2026

   Stuart Cheshire
   Apple Inc.
   Email: cheshire@apple.com

   Mike McBride
   Futurewei
   United States of America
   Email: michael.mcbride@futurewei.com

Karstens, et al.           Expires 6 May 2027                  [Page 14]