Summary

  • The multicast application port draft requests UDP port 8738 as a shared rendezvous; it identifies an ASM application by destination group and an SSM application by source address plus destination group.
  • A port-only firewall, QoS rule or approval record therefore admits an unnamed class of traffic. A local multicast admission receipt can bind the exact traffic identity without putting organisational policy into the port registry.

Port numbers usually perform a convenient act of compression. A rule naming a familiar destination port appears to name the service behind it. The proposed Multicast Application Port deliberately breaks that shortcut. Revision 08 of the IETF draft requests UDP port 8738 and the service name multicast-app, but the draft does not claim that every application using it becomes one application. It says the identifier is the destination multicast address for Any-Source Multicast, and the combination of source unicast address and destination multicast address for Source-Specific Multicast.

That is the design’s point. Giving every multicast application, and sometimes every use of a multicast protocol, a dedicated port consumes a scarce registry and duplicates information already present in the multicast channel. A shared port remains compatible with existing transport stacks and socket APIs while allowing the group—or source and group—to do the demultiplexing.

It is also a governance handoff. The IANA entry can name a common transport rendezvous. It cannot tell an operator which group was approved, which source is trusted, which scope is permitted, which application owns the flow, or when the permission expires. Those facts must survive somewhere else.

The identifier has moved, not disappeared

In ASM, receivers join a destination multicast group and may receive traffic from different sources. The draft treats that destination address as the application identifier. In SSM, the channel is source-qualified: source and group are taken together. A policy that records only UDP/8738 has discarded precisely the information that separates one application from another.

This is not merely a naming nicety. Consider three controls that commonly borrow meaning from a port. A firewall uses a port to decide which traffic may enter. A QoS classifier uses it to choose a queue or rate policy. An asset inventory uses it to describe what a host is running. Under a shared multicast port, all three controls become broader than their labels unless they retain the multicast identity too.

The draft’s security section recognizes the firewall problem. A rule that references the Multicast Application Port without also considering the destination group matches every application using that port and is too broad. The current IESG review exposes a further precision problem: the document defines SSM identity as source plus destination group, yet parts of the filtering guidance refer only to the destination address. One ballot position asks that source-specific application and firewall filtering include the source as well. The same review notes that network classifiers such as QoS need criteria beyond the port.

That review is not a final protocol outcome. The document remains an Internet-Draft in IESG evaluation, with a revised draft requested. It is evidence that the operational question is real and still being sharpened, not evidence that the issue has already been resolved.

Shared sockets make host behavior part of admission

Sharing the number also changes the host contract. A conformant host requires applications to use port 8738 non-exclusively. On POSIX-like systems that means facilities such as SO_REUSEADDR or SO_REUSEPORT. The host prevents wildcard binding for this port, prevents non-multicast sends that use it, and discards incoming non-multicast traffic involving it.

Existing operating systems may not yet enforce that complete behavior. The draft therefore assigns duties to applications running on non-conformant hosts. They must not block other applications from using the port, and they must discard datagrams that do not carry the multicast address their application uses. For SSM, the review question makes the source filter equally important to the actual identity.

An admission decision cannot safely assume that every endpoint supplies the same boundary. On one host, the operating system may reject wildcard and unicast misuse. On another, the application itself may carry the filtering burden. The packet tuple can be identical at the network edge while the host-level isolation is materially different.

The draft lists prototype receivers for Linux, macOS and Windows. They demonstrate group filtering on unmodified systems. The implementation-status text is careful: the information is contributor-supplied, unverified and not a catalogue of available implementations. It cannot support a claim that production hosts already enforce the proposed contract or that deployments interoperate.

A shared port is not a universal replacement

The proposal is optional, and the firewall discussion explains why. A multicast application may send a discovery or distribution message and then exchange unicast replies on dynamically selected ports. A stateful firewall that sees the multicast message may not have enough information to permit the reply. Automatically opening arbitrary source ports in response can create unacceptable holes.

For applications that mix multicast and unicast in firewall-constrained environments, the draft says the existing practice of a dedicated port can be more practical. That limitation is important. The choice is not “modern shared port” versus “wasteful legacy port.” It is a choice between two operational contracts. The shared port conserves assignments and reuses channel identity; a dedicated port can make certain firewall rules and reply patterns easier to express.

Governance should preserve that choice rather than silently standardize one deployment model. An approval for port 8738 should state why the application is suitable for the shared contract, whether it is ASM or SSM, whether it sends any unicast messages, and whether the surrounding firewalls can express the required return path without dynamic overreach.

Local eavesdropping changes the security claim

Traditional exclusive socket binding can provide a rudimentary local barrier: another process may be unable to bind the same port and receive the stream. Shared use removes reliance on that behavior. The draft does not call the port inherently insecure. It says applications may need additional security and observes that local and in-flight eavesdropping may often be addressed by the same mechanism.

The useful policy consequence is not “encrypt everything because the port is shared.” It is that transport binding is no longer evidence of application exclusivity. Authentication, integrity, confidentiality and key scope must be evaluated against the group or source/group channel and its threat model. If two local processes can receive the same stream, the application’s own security—not the port reservation—must distinguish an authorized participant from an observer.

Nor should the multicast address be inflated into a global identity. Groups can have limited scope, be reused in different domains or interfaces, and acquire meaning through local configuration. An SSM source address narrows a channel but does not name an organization or prove control of an application. The address tuple is the traffic selector; ownership and authority are separate evidence.

The missing object is a multicast admission receipt

A useful approval record begins with the actual selector. For ASM it binds destination group, UDP 8738, address family, scope, ingress or egress interface and VRF. For SSM it adds the exact source address or allowed source set. It also names the application and protocol version that the operator intends that selector to represent.

The receipt records which host contract applies. Does the operating system enforce the draft’s wildcard, non-multicast and non-exclusive-use rules, or does the application filter on a non-conformant host? Which socket options and group/source filters were tested? Which firewall and QoS rules were generated from the receipt, and can their deployed forms be traced back to it?

Security belongs in the same evidence chain without being confused with transport identity. The record identifies application authentication, keying and confidentiality expectations; the owner of the keys; the rotation event that invalidates the approval; and whether a local process receiving the datagram would still lack the credentials to use it.

Finally, the receipt has a lifecycle: requester, reviewer, purpose, activation, expiry, revocation and rollback. A group change, new source, VRF move, host downgrade, firewall migration or application-version change creates a new decision. Revoking the receipt withdraws its firewall and QoS projections together rather than leaving an orphaned port rule.

This is not a proposed IETF option or IANA field. It is the local control object made necessary when a deliberately minimal shared port stops pretending to carry application meaning.

Sources

  1. Current draft, history and Datatracker API record
  2. Revision 08 HTML, plain text, XML and revision comparison
  3. IESG ballot, shepherd write-up and INTAREA Working Group
  4. Prototype repository and IANA service-name and port registry
  5. RFC 7605, RFC 6335, RFC 1122 and RFC 1112
  6. RFC 4607, RFC 3493, RFC 3678, RFC 7288 and RFC 7942
  7. Minimum Initial Specification and The Policy Mirror