| Internet-Draft | Mcast App Port | November 2026 |
| Karstens, et al. | Expires 6 May 2027 | [Page] |
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.¶
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 (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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.¶
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].¶
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] 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].¶
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:¶
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.¶
Applications that use the Multicast Application Port MUST meet the requirements in this section.¶
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.¶
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 sharing the Multicast
Application Port, the UDP port cannot be used to identify a
traffic flow to determine what UDP checksum policy to apply.¶
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:¶
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. However, port-based rules offer limited assurance, because a rogue application can use the same port to masquerade as the legitimate trusted application.¶
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.¶
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 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).¶
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.¶
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:¶