Skip to main content

The Multicast Application Ports
draft-karstens-pim-multicast-application-ports-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Nathan Karstens , Stuart Cheshire , Mike McBride
Last updated 2024-07-07
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-karstens-pim-multicast-application-ports-00
Network Working Group                                        N. Karstens
Internet-Draft                                      Garmin International
Intended status: Standards Track                             S. Cheshire
Expires: 8 January 2025                                       Apple Inc.
                                                              M. McBride
                                                               Futurewei
                                                             7 July 2024

                    The Multicast Application Ports
           draft-karstens-pim-multicast-application-ports-00

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 address already uniquely
   identifies the data.  The document proposes assigning two UDP ports
   specifically for use with multicast applications and lists
   requirements for using these ports.

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 8 January 2025.

Copyright Notice

   Copyright (c) 2024 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

Karstens, et al.         Expires 8 January 2025                 [Page 1]
Internet-Draft               Mcast App Ports                   July 2024

   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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Assignment  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Host Requirements . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Application Requirements  . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The Internet community has recognized the need to be judicious when
   assigning port numbers (see [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 (see [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 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.

   In the TCP/IP model, the port number in the transport layer
   multiplexes applications within a host (see [RFC1122], Section 4.1.1
   and [RFC7605], Section 5).  With 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.

   Because of the desire to conserve port numbers and the fact that a
   port is not necessary to multiplex multicast applications, this
   document assigns two UDP ports that may be used with multicast
   applications.

Karstens, et al.         Expires 8 January 2025                 [Page 2]
Internet-Draft               Mcast App Ports                   July 2024

   Use of these ports is optional because there may be circumstances
   where assigning a port is preferred, such as when participants cannot
   meet the requirements in Section 3 and Section 4.

1.1.  Requirements Language

   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.

2.  Assignment

   This document assigns UDP port 49151 and gives it the service name
   "Multicast Application Port".  It also assigns UDP port 49150 and
   give it the service name "Multicast Application Port (Secondary)".
   These two ports are at the end of the range of User ports [RFC6335],
   Section 6 to differentiate them from other port assignments.

   Two ports are assigned because RTP recommends using a sequential port
   pair: an even port for RTP and the next higher port for RTCP (see
   Section 11 of [RFC3550]).  RTP is a popular protocol for multicast
   video streams and many implementations require this port scheme.

   The assigned ports 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.

3.  Host Requirements

   Hosts shall regard the use of these ports as non-exclusive.  In
   practice, this means hosts using POSIX socket APIs would consider the
   SO_REUSEADDR socket option as having been enabled, regardless of the
   actual state of that flag [POSIX].

   Hosts shall discard all incoming, non-multicast packets that use
   these destination ports.

4.  Application Requirements

   Applications running on non-conformant hosts can successfully use
   these ports if they meet the requirements in this section.

Karstens, et al.         Expires 8 January 2025                 [Page 3]
Internet-Draft               Mcast App Ports                   July 2024

   Applications running on a non-conformant host shall not prevent other
   applications from using these ports.  In practice, this means that
   applications using POSIX socket APIs must enable the SO_REUSEADDR
   and/or SO_REUSEPORT socket options [POSIX].

   Applications running on a non-conformant host shall discard all
   datagrams that do not have the multicast address used by the
   application.

5.  Security Considerations

   Applications running on non-conformant hosts are vulnerable to a
   denial of service attack if another application claims exclusive
   access to the ports.

6.  IANA Considerations

   IANA is requested to assign ports 49150 and 49151 as described in
   Section 2.  Both assignments should reference this document.

   IANA is requested to update its "Application for Service Names and
   User Port Numbers" [IANA-APP] to reference this document, ask if a
   Multicast Application Port may be used, and require an explanation if
   not.

7.  Acknowledgement

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

   Thanks also to the members of the PIM working group for their review
   of this draft.

8.  References

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

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

8.2.  Informative References

Karstens, et al.         Expires 8 January 2025                 [Page 4]
Internet-Draft               Mcast App Ports                   July 2024

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

   [POSIX]    The Open Group, ""The Open Group Base Specifications",
              Issue 7, 2018 edition", December 2001,
              <https://pubs.opengroup.org/onlinepubs/9699919799/>.

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

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

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

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

Authors' Addresses

   Nate Karstens
   Garmin International
   Email: nate.karstens@gmail.com

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

   Mike McBride
   Futurewei
   Email: michael.mcbride@futurewei.com

Karstens, et al.         Expires 8 January 2025                 [Page 5]