Service Name and Transport Protocol Port Number Registry
Last Updated
- 2026-10-15
Expert(s)
- TCP/UDP: Joe Touch; Eliot Lear, Kumiko Ono, Wes Eddy, Brian Trammell, and Michael Scharf
- SCTP: Michael Tuexen
- DCCP: Eddie Kohler and Yoshifumi Nishida
Reference
- RFC 6335: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
Note
Service names and port numbers are used to distinguish between different services that run over transport protocols such as TCP, UDP, DCCP, and SCTP.
Service names are assigned on a First Come First Served basis, as described in RFC 6335.
Port numbers are divided into three ranges, with their uses and assignment procedures specified in Section 8.1.2 of RFC 6335:
- System Ports (0-1023) are assigned using the IETF Review or IESG Approval procedures.
- User Ports (1024-49151) are assigned using the IETF Review, IESG Approval, or Expert Review procedures.
- Dynamic and/or Private Ports (49152-65535) are not assigned.
The registration procedures for service names and port numbers are specified in RFC 6335, while the registration policies referenced above are defined in RFC 8126.
Assigned ports both System and User ports SHOULD NOT be used without or prior to IANA registration.
Assignment of a port number does not in any way imply an endorsement of an application or product, and the fact that network traffic is flowing to or from a registered port does not mean that it is "good" traffic, nor that it necessarily corresponds to the assigned service. Firewall and system administrators should choose how to configure their systems based on their knowledge of the traffic in question, not whether there is a port number registered or not.
Registration Forms
- To request a new assignment, please use the Application for Service Names and User Port Numbers form.
- To modify an existing assignment, please use the Modify a Port Number Assignment form.
Available Formats
| Service Name | Port Number | Transport Protocol | Description | Assignee | Contact | Registration Date | Modification Date | Reference | Service Code | Unauthorized Use Reported | Assignment Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|
| groupthink | tcp | Mobile device cluster | altmobile.ai | Zaid Al-Timimi | 2025-06-18 | Defined TXT keys: None | |||||
| guid | Special service type for resolving by GUID (Globally Unique Identifier) | Defined TXT keys: Varies; Depends on type of service being offered/resolved Although DNS-SD does not recommend or advocate using GUIDs as the primary name of an offered service why not?, it does support use of GUIDs as service names where developers want to use them that way. Typically users do not browse for GUIDs. They are not user-friendly and not very informative. Typically, the service is advertised as usual, using a user-friendly name. One of the TXT record attributes is a GUID for the service instance. Once the user has browsed and chosen the desired service instance via its user-friendly name, the service is resolved, the TXT record is retrieved, and the GUID is stored. A given network service instance is therefore being advertised two ways, for example: <User-Friendly-Name>._ptp._tcp.local <GUID>._guid._tcp.local On subsequent accesses to the service, the GUID-based name is resolved, and that particular service instance is discovered, even if the user has subsequently changed the user-friendly name to something else. Note: Although each different logical service type needs to have its own different DNS-SD service type, all GUID-based names use the same pseudo-type: "_guid._tcp". There is no possibility of name conflict because (by definition) GUIDs are globally unique. | |||||||||
| hue | tcp | Philips hue protocol | Signify | Walter Slegers | 2017-11-01 | 2019-08-09 | Defined TXT keys: bridgeid, modelid | ||||
| jnx-kcsync | tcp | jollys keychain cloud sync protocol | Patrick Stein | Patrick Stein | 2011-10-24 | Defined TXT keys: hash=<40hex characters> salt=<40hex characters> uuid=<40hex characters> Example: hash=5e7580598c0d7064d4fc79faaeb42585e1a675f8 salt=f0164cb3a0c3d7efe75abea8fda86d2d56c8dda9 uuid=db61dc092922252e45bbb264f59147138c7fd5fa | |||||
| macfoh-data | udp | MacFOH realtime data | Shaun Wexler | Shaun Wexler | Defined TXT keys: None | ||||||
| shippairing | tcp | Authenticated SHIP pairing request | EEBus Initiative | Marc Walter | 2025-07-17 | Defined TXT Keys: txtvers, parType, forId, forPar, trustId, trustPar, trustCurve, type, trustNonce, alg, digest | |||||
| socketcloud | Socketcloud distributed application framework | Robert Goodyear | Robert Goodyear | Defined TXT keys: system, service, process, context, direction, status, progress, health, directive, flags | |||||||
| thing | tcp | Internet of things service discovery | Aaltronav | ICT Manager | 2019-10-02 | Defined TXT keys: version, url, location, privacy, support, vendor, about | |||||
| thing | udp | Internet of things service discovery | Aaltronav | ICT Manager | 2019-10-02 | Defined TXT keys: version, url, location, privacy, support, vendor, about | |||||
| voalte2 | tcp | Server location via DNS-SD | Voalte, Inc. | John Simpson | 2019-01-22 | Defined TXT keys: txtvers, name, (others not publicly documented) | |||||
| voalte3 | tcp | Server location via DNS-SD | Voalte, Inc. | John Simpson | 2019-01-22 | Defined TXT keys: txtvers, name, (others not publicly documented) |
Contact Information
| Name | Organization | Contact URI | Last Updated |
|---|---|---|---|
| Aaltronav | hostmaster&aaltronav.eu | 2019-10-02 | |
| altmobile.ai | admin&altmobile.ai | 2025-06-18 | |
| EEBus Initiative | info&eebus.org | 2014-11-10 | |
| ICT Manager | Aaltronav | hostmaster&aaltronav.eu | 2019-10-02 |
| John Simpson | Voalte, Inc. | jms1&voalte.com | 2019-01-22 |
| Marc Walter | EEBus Initiative | walter&eebus.org | 2025-07-17 |
| Patrick Stein | Patrick.Stein&jinx.eu | 2011-10-24 | |
| Robert Goodyear | robg&brand-up.com | ||
| Shaun Wexler | dev&macfoh.com | ||
| Signify | leon.bouwmeester&signify.com | 2019-08-09 | |
| Voalte, Inc. | engops&voalte.com | 2019-01-22 | |
| Walter Slegers | walter.slegers&signify.com | 2019-08-09 | |
| Zaid Al-Timimi | altmobile.ai | admin&altmobile.ai | 2025-06-18 |