ETSI TR 129 941 V17.2.0 (2022-07)

5G ; Guidelines on Port Allocation for New 3GPP Interfaces (3GPP TR 29.941 version 17.2.0 Release 17)

RTR/TSGC-0429941vh20

General Information

• Status: Not Published
• Technical Committee: 3GPP CT 4 - MAP/CAMEL/GTP/BCH/SS/TrFO/IMS/GUP/WLAN (formely CN4)
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Completion Date: 18-Jul-2022

Standards Content (Sample)

ETSI TR 129 941 V17.2.0 (2022-07)






TECHNICAL REPORT
5G ;
Guidelines on Port Allocation for New 3GPP Interfaces
(3GPP TR 29.941 version 17.2.0 Release 17)

---------------------- Page: 1 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 1 ETSI TR 129 941 V17.2.0 (2022-07)

Reference
RTR/TSGC-0429941vh20
Keywords
5G
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.

ETSI

---------------------- Page: 2 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 2 ETSI TR 129 941 V17.2.0 (2022-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the
®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Legal Notice
This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI

---------------------- Page: 3 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 3 ETSI TR 129 941 V17.2.0 (2022-07)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
Introduction . 6
1 Scope . 7
2 References . 7
3 Definitions of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Selected Solutions . 8
4.1 General . 8
4.2 DNS based solutions#1-4 . 12
4.2.1 General . 12
4.2.2 Solution#1: DNS-SD based solution. 13
4.2.2.1 General . 13
4.2.2.2 Detailed description . 14
4.2.2.3 Pros and cons . 14
4.2.3 Solution#2: Service discovery using DNS SRV records . 15
4.2.3.1 General . 15
4.2.3.2 Detailed description . 15
4.2.3.3 Pros and cons . 16
4.2.4 Solution#3: Use of multicast address on local link (mDNS) . 16
4.2.4.1 General . 16
4.2.4.2 Detailed description . 16
4.2.4.3 Pros and cons . 17
4.2.5 Solution#4: Direct unicast DNS queries to the target node (uDNS) . 17
4.2.5.1 General . 17
4.2.5.2 Detailed description . 18
4.2.5.3 Pros and cons . 18
4.2.6 Guidelines for DNS based solutions#1-4 . 19
4.3 SCTP based solution#5 – SCTP Multiplexer (SCTP MUX) . 19
4.3.1 General . 19
4.3.2 Detailed description . 21
4.3.3 Pros and cons . 22
4.3.4 Guidelines for SCTP based solution#5 . 22
4.4 3GPP allocated port number solution#6 . 22
4.4.1 General . 22
4.4.2 Detailed description . 23
4.4.3 Pros and cons . 24
4.4.4 Guidelines for 3GPP allocated port number solution#6. 24
4.5 OAM allocated port number solution#7 . 24
4.5.1 General . 24
4.5.2 Detailed description . 24
4.5.3 Pros and cons . 25
4.5.4 Guidelines for OAM allocated port number solution7 . 25
4.6 Port Registration and Retrieval via NRF solution#8 . 25
4.6.1 General . 25
4.6.2 Detailed description . 26
4.6.3 Pros and cons . 26
4.6.4 Guidelines for Port Registration and Retrieval via NRF solution#8 . 26
ETSI

---------------------- Page: 4 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 4 ETSI TR 129 941 V17.2.0 (2022-07)
5 Summary . 26
5.1 General . 26
5.2 3GPP allocated Service Name and Port Number registry . 26
Annex A: IANA port allocation policy . . 27
Annex B: Port number use . 28
B.1 General . 28
B.2 Port number ranges . 28
B.3 Service identified by port number not assigned by IANA . 29
Annex C: IANA procedures for Service Name and Port Number registry management . 31
C.1 General principles . 31
C.2 Assignment Procedure . 31
C.3 IANA Policies for Port Number assignment . 31
C.4 Recommendations to designers of application and service protocols . 32
C.5 3GPP port assignment applications since 2009 . 33
Annex D: Change history . 36
History . 37

ETSI

---------------------- Page: 5 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 5 ETSI TR 129 941 V17.2.0 (2022-07)
Foreword
This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
In the present document, modal verbs have the following meanings:
shall indicates a mandatory requirement to do something
shall not indicates an interdiction (prohibition) to do something
The constructions "shall" and "shall not" are confined to the context of normative provisions, and do not appear in
Technical Reports.
The constructions "must" and "must not" are not used as substitutes for "shall" and "shall not". Their use is avoided
insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced,
non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a
referenced document.
should indicates a recommendation to do something
should not indicates a recommendation not to do something
may indicates permission to do something
need not indicates permission not to do something
The construction "may not" is ambiguous and is not used in normative elements. The unambiguous constructions
"might not" or "shall not" are used instead, depending upon the meaning intended.
can indicates that something is possible
cannot indicates that something is impossible
The constructions "can" and "cannot" are not substitutes for "may" and "need not".
will indicates that something is certain or expected to happen as a result of action taken by an agency
the behaviour of which is outside the scope of the present document
will not indicates that something is certain or expected not to happen as a result of action taken by an
agency the behaviour of which is outside the scope of the present document
might indicates a likelihood that something will happen as a result of action taken by some agency the
behaviour of which is outside the scope of the present document
ETSI

---------------------- Page: 6 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 6 ETSI TR 129 941 V17.2.0 (2022-07)
might not indicates a likelihood that something will not happen as a result of action taken by some agency
the behaviour of which is outside the scope of the present document
In addition:
is (or any other verb in the indicative mood) indicates a statement of fact
is not (or any other negative verb in the indicative mood) indicates a statement of fact
The constructions "is" and "is not" do not indicate requirements.
Introduction
3GPP TR 29.835 [2] studies Port Number Allocation Alternatives for New 3GPP Interfaces. This specification
documents the outcome of the study by providing the guidelines for addressing the problem.
ETSI

---------------------- Page: 7 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 7 ETSI TR 129 941 V17.2.0 (2022-07)
1 Scope
IETF has indicated to 3GPP that future IANA port number assignment requests for protocol only used inside 3GPP
networks will be likely rejected except if there is a strong justification for it. The present document provides guidelines
for resolving the problem with allocating port numbers for new 3GPP interfaces, as an alternative to IANA assigned
port numbers.
Starting from 3GPP Rel-17, any 3GPP working group can rely on these guidelines when defining new interfaces, which
require new default port number allocation.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TR 29.835: "Study on Port Number Allocation Alternatives for New 3GPP Interfaces".
[3] IETF RFC 793: "Transmission Control Protocol".
[4] IETF RFC 1078: "TCP Port Service Multiplexer (TCPMUX)"
[5] IETF RFC 2782: "A DNS RR for specifying the location of services (DNS SRV)".
[6] IETF RFC 4960: "Stream Control Transmission Protocol".
[7] IETF RFC 5226: "Guidelines for Writing an IANA Considerations clause in RFCs".
[8] IETF RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions".
[9] IETF RFC 6083: "Datagram Transport Layer Security (DTLS) for Stream Control Transmission
Protocol (SCTP)".
[10] IETF RFC 6335: "Internet Assigned Numbers Authority (IANA) Procedures for the Management
of the Service Name and Transport Protocol Port Number Registry".
[11] IETF RFC 6347: "Datagram Transport Layer Security Version 1.2".
[12] IETF RFC 6762: "Multicast DNS".
[13] IETF RFC 6763: "DNS-Based Service Discovery".
[14] IETF RFC 7301: "Transport Layer Security (TLS) Application-Layer Protocol Negotiation
Extension".
[15] IETF RFC 7605: "Recommendations on Using Assigned Transport Port Numbers".
[16] IETF RFC 7805: "Moving Outdated TCP Extensions and TCP-Related Documents to Historic or
Informational Status".
[17] IETF RFC 8126: "Guidelines for Writing an IANA Considerations Clause in RFCs".
[18] IETF RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
ETSI

---------------------- Page: 8 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 8 ETSI TR 129 941 V17.2.0 (2022-07)
[19] IETF RFC 1035: "Domain Names – Implementation and specification".
[20] 3GPP TS 29.641: "3GPP registry for Service Names and Port Numbers".
3 Definitions of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in 3GPP TR 21.905 [1] and the following apply. A term
defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905 [1].
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
3GPP TR 21.905 [1].
4 Selected Solutions
4.1 General
Since 2015, IANA had gradually warned 3GPP that a solution should be found to avoid port assignments for protocols
only used in 3GPP networks (and not on the public Internet). The last requests were exceptionally granted by the
Internet Engineering Steering Group (IESG) only at the conditions that it was the last one(s). Now, it is clear that
application for a new port will not be granted without a strong justification and only if:
- The recommendations given in IETF RFC 7605 [3] have been carefully followed (see Annex C.4);
- It is proved that there is no other solution than port assignment for service port discovery.
The IETF RFC 7605 [3] provides recommendations to designers of application and service protocols on how to use the
transport protocol port number space and when to request a port assignment from IANA. In this document, it is
reminded that:
IANA assigns port numbers so that Internet endpoints do not need pairwise, explicit coordination of the meaning
of their port numbers. This is the primary reason for requesting port number assignment by IANA: to have a
common agreement between all endpoints on the Internet as to the default meaning of a port number, which
provides the endpoints with a default port number for a particular protocol or service.
It is also clarified that:
Port numbers can also be used for other purposes. Assigned port numbers can simplify end-system configuration,
so that individual installations do not need to coordinate their use of arbitrary port numbers. Such assignments
may also have the effect of simplifying firewall management, so that a single, fixed firewall configuration can
either permit or deny a service that uses the assigned ports.
In typical roaming scenarios, three or more administrative domains can be crossed: visited and home PLMN, one or
more IPX providers connecting together via an IPX peering point for traffic exchange between PLMNs. Operators and
service providers may even decide to rely on the global connectivity provided by the public Internet for interconnection.
ETSI

---------------------- Page: 9 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 9 ETSI TR 129 941 V17.2.0 (2022-07)
As roaming implies the need for a global configuration of the port to use for a particular protocol, it is strongly
recommended for 3GPP to apply to IANA for assigned service name and port number for any protocol potentially
supported by roaming interfaces when no other service port discovery (e.g. DNS-based solutions) is applicable.
In non-roaming scenarios, a given interface can still cross multiple domains. For instance, RAN can be supported by an
IP-based network distinct from the one supporting the core network even if both are under the same PLMN Another
example is the RAN sharing case (i.e. same RAN is used by multiple PLMN's CN) in which the interface between RAN
and CN also crosses multiple administrative domains. In such a case, it is also strongly recommended for 3GPP to apply
to IANA for assigned service name and port number for any protocol potentially supported by inter-domain interfaces
when no other service port discovery (e.g. DNS-based solutions) is applicable.
For 3GPP interfaces that would be used only in intra-domain scenarios, alternative solutions to IANA assigned port
numbers are required.
Table 4.1-1 provides brief summary of the identified alternative solutions.
ETSI

---------------------- Page: 10 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 10 ETSI TR 129 941 V17.2.0 (2022-07)
Table 4.1-1: Solution summary
ETSI

---------------------- Page: 11 ----------------------
3GPP TR 29.941 version 17.2.0 Release 17 11 ETSI TR 129 941 V17.2.0 (2022-07)
Solution Port Applicable Suitable (NOTE) Comments
allocation transport
method layer Inter- Intra-
protocol
domain domain
#1 Un- UDP, TCP, Part Yes DNS infrastructure based solution (DNS-SD)
assigned SCTP The port number is selected dynamically by the interface
application locally. DNS server is kept up-to-date with the
records like hostnames, IP addresses, locally assigned
port numbers, service names supported, etc. for
application clients to discover using DNS PTR query.
This solution is suitable for inter-domain scenario with
certain limitations.
Inter-PLMN service discovery can be provided using
operator DNS servers connected to the IPX, the private,
inter-operator IP backbone network. But if the traffic
related to the discovered application/interface needs to be
controlled, this will not work as the destination port is
unknown to security gateway/firewall.
#2 Un- UDP, TCP, Part Yes DNS infrastructure based solution (DNS SRV)
assigned SCTP This is an alternative to solution#1 in which there is only
one logical instance of service and all clients
are expected to use that one logical instance. Application
clients can discover the server end point details using
DNS SRV query.
Requires DNS infrastructure application clients that
support DNS queries.
This solution is suitable for inter-domain scenario with
certain limitations.
Inter-PLMN service discovery can be provided using
operator DNS servers connected to the IPX, the private,
inter-operator IP backbone network operator DNS servers
connected to the IPX, the private, inter-operator IP
backbone network. But if the traffic related to the
discovered application/interfac
...