| Internet-Draft | WIT Working Group | July 2025 |
| Li, et al. | Expires 5 January 2026 | [Page] |
This document proposes a dynamic multicast port allocation mechanism using Segment Routing over IPv6 (SRv6). The solution enables decoupling between the destination port carried in multicast packets sent by the source and the actual receiving port used by receivers. This allows multicast receivers to dynamically allocate unused ports as receiving ports, eliminating the requirement for all receivers to use the same port number. The mechanism defines a new SRv6 function End.MTP for automatic multicast port allocation and supports three operational modes to accommodate different deployment scenarios.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .¶
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 5 January 2026.¶
Copyright (c) 2025 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 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.¶
In unicast TCP/IP communication flows, the same TCP connection or UDP "connection" uses identical source and destination IP addresses, with different port numbers distinguishing different services. Examples include HTTP port 80, SSH port 22, Telnet port 23, SMTP port 25, and FTP port 21.¶
IETF RFC 6335 [RFC6335] and RFC 7605 [RFC7605] categorize commonly used ports into three types:¶
Well-Known Ports (0-1023): These are well-known port numbers that are permanently assigned to specific services. The services mentioned above, such as HTTP and FTP, belong to this category.¶
Registered Ports (1024-49151): These ports are not dynamically adjustable and do not have clearly defined services for specific objects. Different programs can define their usage according to their own needs.¶
Dynamic, Private or Ephemeral Ports (49152-65535): These port numbers cannot be registered and are used for private or customized services, as well as for dynamic port services.¶
Port number resources are precious. For unicast services, dynamic port allocation is commonly adopted. However, for multicast services, dynamic allocation becomes challenging because it is difficult to confirm that specific port numbers are not occupied by other applications or services across all multicast receivers that need to join the multicast group.¶
IPTV, real-time data transmission, and multimedia conferencing are typical application scenarios for multicast. According to current multicast interaction procedures, multicast sources need to specify both the multicast IP address and multicast UDP port number when pushing multicast service flows. For multicast services, using both multicast IP addresses and port numbers for service differentiation creates redundancy. Taking IPTV as an example, different TV channels (services) typically use different multicast IP addresses, making port numbers less critical for service identification.¶
This document proposes a multicast port number allocation method that automatically assigns SID End.MTP sid to multicast packets carried by multicast sources or edge entry network nodes. This decouples the destination port carried by the multicast source from the actual receiving port used by the recipient, allowing recipients to dynamically allocate unused ports as multicast receiving ports. Each multicast recipient is not required to use the same receiving port number.¶
3.1 End-to-End Mode¶
In this mode, both the multicast source and multicast receiver servers on the end side must support SRv6 and the multicast port automatic SID allocation proposed by this scheme. Additionally, the multicast receiver servers must maintain a mapping relationship between the destination port numbers carried in the multicast source packets and the dynamically allocated receiving port numbers (e.g., multicast IP: 49155 ~ 50000). Network devices do not require upgrades or modifications.¶
3.2 Network-Only Mode¶
In this mode, end-side multicast source and multicast receiver servers do not require upgrades (end-side compatibility mode). The edge ingress network node near the multicast source, upon receiving multicast packets, inserts the proposed multicast port automatic allocation SID if the packet is an SRv6 packet, or performs IPv4 to IPv6 packet conversion if it is not an SRv6 packet.¶
Intermediate network nodes forward multicast packets according to normal procedures. Edge egress network nodes need to interact with their downstream multicast receivers in advance to obtain dynamically allocated receiving ports for the multicast IP service and construct port mapping tables.¶
When receiving multicast packets carrying End.MTP SID, the egress node refreshes the port mapping table (to prevent aging), modifies the packet's destination receiving port to the dynamic port obtained from the table lookup (e.g., 49155 - 50000), then replicates multicast packets for other downstream receivers with table lookup and receiving port modification, and finally forwards to all downstream receivers.¶
3.3 End-Network Collaboration Mode¶
This mode is designed for multicast sources or multicast receiver servers that support SRv6 and the multicast port automatic SID allocation proposed in this scheme. It can be further divided into two subtypes:¶
1. the multicast source and edge exit network nodes collaborate to complete the interaction process and message parsing and processing actions of this scheme;¶
2. the edge entry network nodes and multicast receivers collaborate to complete the interaction process and message parsing and processing actions of this scheme.¶
TBD.¶