<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp "&#160;">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  docName="draft-karstens-multicast-application-port-00"
  ipr="trust200902"
  submissionType="IETF"
  consensus="true">

  <front>
    <title abbrev="Mcast App Port">The Multicast Application Port</title>

    <author fullname="Nate Karstens" initials="N" surname="Karstens">
      <organization>Garmin International</organization>

      <address>
        <email>nate.karstens@gmail.com</email>
      </address>
    </author>

    <author fullname="Stuart Cheshire" initials="S" surname="Cheshire">
      <organization>Apple Inc.</organization>

      <address>
        <email>cheshire@apple.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Futurewei</organization>

      <address>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>

    <date day="14" month="January" year="2025"/>

    <abstract>
      <t>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 address already uniquely identifies the data. The document proposes assigning a UDP port specifically for use with multicast applications and lists requirements for using this port.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Internet community has recognized the need to be judicious when assigning port numbers (see <xref target="RFC7605" sectionFormat="comma" 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 (see <xref target="RFC7605" sectionFormat="comma" 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 each multicast application-layer protocol has had to have its own dedicated port assignment. Even worse, each different use of that multicast application-layer protocol has had to have a different unique port assigned.</t>

      <t>In the TCP/IP model, the port number in the transport layer multiplexes applications within a host (see <xref target="RFC1122" sectionFormat="comma" section="4.1.1"/> and <xref target="RFC7605" sectionFormat="comma" section="5"/>). With Any-Source Multicast, the use of a port number to multiplex applications is unnecessary because the destination multicast address already provides a unique identifier for the application. The same applies to Source-Specific Multicast if both source address and destination multicast address are considered.</t>

      <t>Because of the desire to conserve port numbers and the fact that a port is not necessary to multiplex multicast applications, this document assigns a UDP port that may be used with multicast applications.</t>

      <t>Use of this port is optional because there may be circumstances where assigning a port is preferred, such as when participants cannot meet the requirements in <xref target="host"/> and <xref target="application"/>.</t>

      <section title="Requirements Language" anchor="requirements">
        <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>

    <section title="Assignment">
      <t>This document REQUESTS assignment of UDP port 49149 and gives it the service name "Multicast Application Port". This port is near the end of the range of User ports <xref target="RFC6335" sectionFormat="comma" section="6"/> to differentiate it from other port assignments.</t>

      <t>The REQUESTED port may be used as a source port if the application exclusively uses multicast messages. If any application messages are unicast, then a dynamic port should be used as the source port. This allows receivers to know which port to send replies to.</t>
    </section>

    <section title="Host Requirements" anchor="host">
      <t>Hosts shall require applications using this port to use it non-exclusively. In practice, this means hosts using POSIX-like socket APIs would require applications to set the <tt>SO_REUSEADDR</tt> and/or <tt>SO_REUSEPORT</tt> socket options before binding the socket <xref target="POSIX"/>. This ensures that applications developed on a conformant host will also work on a non-conformant host.</t>

      <t>Hosts shall discard all incoming, non-multicast packets that use this destination port.</t>
    </section>

    <section title="Application Requirements" anchor="application">
      <t>Applications running on non-conformant hosts can ensure compatibility with conformant hosts by meeting the requirements in this section.</t>

      <t>Applications running on a non-conformant host shall not prevent other applications from using this port. In practice, this means that applications using POSIX-like socket APIs would enable the <tt>SO_REUSEADDR</tt> and/or <tt>SO_REUSEPORT</tt> socket options before binding the socket <xref target="POSIX"/>.</t>

      <t>Applications running on a non-conformant host shall discard all datagrams that do not have the multicast address used by the application.</t>
    </section>

    <section title="Security Considerations">
      <t>Applications running on non-conformant hosts are vulnerable to a denial of service attack if another application claims exclusive access to the port.</t>

      <t>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 these security mechanisms. These applications may want to incorporate additional security measures into their protocol. Note that the problem of local eavesdropping is typically no worse than eavesdropping in-flight, so it is likely that both attack vectors can be resolved by the same security measure.</t>
    </section>

    <section title="IANA Considerations">
      <t>IANA is REQUESTED to assign the following port:</t>

      <artwork><![CDATA[
Service Name        Multicast Application Port
Transport Protocol  UDP
Assignee            IESG <iesg@ietf.org>
Contact             IETF Chair <chair@ietf.org>
Description         Multicast data where the application is identified
                    by the multicast address
Reference           This document
Port Number         49149]]>
      </artwork>

      <t>IANA is requested to update its "Application for Service Names and User Port Numbers" <xref target="IANA-APP"/> to reference this document, ask if a Multicast Application Port may be used, and require an explanation if not.</t>
    </section>

    <section title="Acknowledgement">
      <t>Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this research.</t>

      <t>Thanks also to the members of the PIM and INT-AREA working groups for their review of this draft and to Dr. Joe Touch for consulting on port assignment.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
    </references>
    <references title="Informative References">
      <reference anchor="IANA-APP" target="https://www.iana.org/form/ports-services">
        <front>
          <title>Application for Service Names and User Port Numbers</title>
          <author>
            <organization>Internet Assigned Numbers Authority</organization>
          </author>
        </front>
      </reference>
      <reference anchor="POSIX" target="https://pubs.opengroup.org/onlinepubs/9699919799/">
        <front>
          <title>"The Open Group Base Specifications", Issue 7, 2018 edition</title>
          <author>
            <organization>The Open Group</organization>
          </author>
          <date month="December" year="2001" />
        </front>
      </reference>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7605.xml"/>
    </references>
  </back>
</rfc>
