The Multicast Application Port

The Internet community has recognized the need to be judicious when assigning port numbers (see ). 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 ). 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 and ). 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. 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: the Multicast Application Port. Assigning a UDP port for multicast applications (as opposed to other methods) provides immediate compatibility with existing network protocol stacks. contains requirements that facilitate use of the port on a given platform, but incorporating these requirements into existing platforms is expected to be a gradual process. 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 and , or when a firewall blocks a traffic pattern used by the application (see ). An application may use this port in conjunction with a unicast port to balance out deficiencies related to multicast distribution (see , for example).

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 when, and only when, they appear in all capitals, as shown here.

This document requests assignment of UDP port 8738 (0x2222) and gives it the service name "mcast-app-port". The Multicast Application Port SHALL NOT be used as a destination port for any non-multicast messages. It MAY be used as a source port by an application that exclusively uses multicast messages. If any application messages are unicast, then a different port should be used for the source port. This allows receivers to know which port to send replies to. Such arrangements would likely require receivers to use multiple sockets, as the application would need to bind to multiple ports.

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 SO_REUSEADDR and/or SO_REUSEPORT socket options before binding the socket . This ensures that applications developed on a conformant host will also work on a non-conformant host. Hosts SHALL prevent use of the port with the wildcard address (see ) by having the socket bind operation return an error code. Hosts SHALL prevent applications from sending non-multicast packets to this destination port by having the send operation return an error code. Hosts SHALL discard all incoming, non-multicast packets that use this destination port.

Certain host firewalls are designed to accept incoming messages as long as there was first an outgoing message using the same set of ports (see for more discussion). Consider the following sequence of messages:

(Multicast) Host A to group containing Host B
Source Port: 50000 (Dynamic)
Dest Port: 8738
(Unicast) Host B to Host A
Source Port: 60000 (Dynamic)
Dest Port: 50000
(Unicast) Host A to Host B
Source Port: 50000
Dest Port: 60000

The host firewall on Host A may block Message 2 because it uses a different set of ports than Message 1 uses. Host firewalls SHOULD be designed to allow this sequence of messages, but MAY filter traffic based on the multicast address used in Message 1, which identifies the application.

Applications running on non-conformant hosts can ensure compatibility with conformant hosts by meeting the requirements in this section. 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 SO_REUSEADDR and/or SO_REUSEPORT socket options before binding the socket . Applications running on a non-conformant host SHALL discard all datagrams received on the Multicast Application Port that do not have the multicast address used by the application.

Firewall rules referencing ports are typically intended to match specific applications. Because applications using the Multicast Application Port are identified by both port and destination multicast address, rules referencing the Multicast Application Port SHOULD also consider the destination multicast address. Applications running on non-conformant hosts are vulnerable to a denial of service attack if another application claims exclusive access to the 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 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.

IANA is requested to assign the following port: Contact IETF Chair Description Multicast Application Port Reference This document Port Number 8738]]> IANA is requested to update its "Application for Service Names and User Port Numbers" to reference this document, ask if the Multicast Application Port may be used, and require an explanation if not. This document does not prohibit future port assignments for multicast applications; the review team still has discretion to approve requests on a case-by-case basis.

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 INT-AREA working groups for their review of this draft, and to the following individuals specifically:

Dr. 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 OSes
Juliusz Chroboczek for suggestions on the source port used for unicast
Dave Thaler for suggestions related to host firewalls