Internet-Draft Mcast App Ports July 2024
Karstens, et al. Expires 24 January 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-karstens-pim-multicast-application-ports-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
N. Karstens
Garmin International
S. Cheshire
Apple Inc.
M. McBride
Futurewei

The Multicast Application Ports

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

Table of Contents

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.

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.

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 the following ports:

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         49151
Service Name        Multicast Application Port (Secondary)
Transport Protocol  UDP
Assignee            IESG <iesg@ietf.org>
Contact             IETF Chair <chair@ietf.org>
Description         A secondary port for multicast data identified
                    by the multicast address. Used when the protocol
                    requires consecutive ports.
Reference           This document
Port Number         49150

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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

[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", , <https://pubs.opengroup.org/onlinepubs/9699919799/>.
[RFC1122]
Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc7605>.

Authors' Addresses

Nate Karstens
Garmin International
Stuart Cheshire
Apple Inc.
Mike McBride
Futurewei