idnits 2.17.1 draft-ietf-tsvwg-iana-ports-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4960], [RFC4340], [RFC5595], [RFC3828], [RFC2780], [RFC2782]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC3828, but the abstract doesn't seem to directly say this. It does mention RFC3828 though, so this could be OK. -- The draft header indicates that this document updates RFC2780, but the abstract doesn't seem to directly say this. It does mention RFC2780 though, so this could be OK. -- The draft header indicates that this document updates RFC2782, but the abstract doesn't seem to directly say this. It does mention RFC2782 though, so this could be OK. -- The draft header indicates that this document updates RFC4340, but the abstract doesn't seem to directly say this. It does mention RFC4340 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2780, updated by this document, for RFC5378 checks: 1999-07-19) (Using the creation date from RFC2782, updated by this document, for RFC5378 checks: 1998-09-02) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2011) is 4814 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCyyyy' is mentioned on line 1167, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-08 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 == Outdated reference: A later version (-01) exists of draft-touch-tsvwg-port-use-00 -- Obsolete informational reference (is this intentional?): RFC 1078 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 1340 (Obsoleted by RFC 1700) -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group M. Cotton 3 Internet-Draft ICANN 4 Updates: 2780, 2782, 3828, 4340, L. Eggert 5 4960, 5595 (if approved) Nokia 6 Intended status: BCP J. Touch 7 Expires: August 16, 2011 USC/ISI 8 M. Westerlund 9 Ericsson 10 S. Cheshire 11 Apple 12 February 12, 2011 14 Internet Assigned Numbers Authority (IANA) Procedures for the Management 15 of the Service Name and Transport Protocol Port Number Registry 16 draft-ietf-tsvwg-iana-ports-10 18 Abstract 20 This document defines the procedures that the Internet Assigned 21 Numbers Authority (IANA) uses when handling assignment and other 22 requests related to the Service Name and Transport Protocol Port 23 Number Registry. It also discusses the rationale and principles 24 behind these procedures and how they facilitate the long-term 25 sustainability of the registry. 27 This document updates IANA's procedures by obsoleting the previous 28 UDP and TCP port assignment procedures defined in Sections 8 and 9.1 29 of the IANA allocation guidelines [RFC2780], and it updates the IANA 30 Service Name and Port assignment procedures for UDP-Lite [RFC3828], 31 DCCP [RFC4340] [RFC5595] and SCTP [RFC4960]. It also updates the DNS 32 SRV specification [RFC2782] to clarify what a service name is and how 33 it is registered. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 16, 2011. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 4. Conventions Used in this Document . . . . . . . . . . . . . . 8 84 5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8 85 5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9 86 5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10 87 6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 11 88 6.1. Service names and Port Numbers for Experimentation . . . . 12 89 7. Principles for Service Name and Transport Protocol Port 90 Number Registry Management . . . . . . . . . . . . . . . . . . 12 91 7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 13 92 7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13 93 8. IANA Procedures for Managing the Service Name and 94 Transport Protocol Port Number Registry . . . . . . . . . . . 16 95 8.1. Service Name and Port Number Assignment . . . . . . . . . 16 96 8.2. Service Name and Port Number De-Assignment . . . . . . . . 20 97 8.3. Service Name and Port Number Reuse . . . . . . . . . . . . 21 98 8.4. Service Name and Port Number Revocation . . . . . . . . . 21 99 8.5. Service Name and Port Number Transfers . . . . . . . . . . 22 100 8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 22 101 8.7. Disagreements . . . . . . . . . . . . . . . . . . . . . . 23 102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 103 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 104 10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 24 105 10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 25 106 10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 26 107 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 108 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 111 13.2. Informative References . . . . . . . . . . . . . . . . . . 29 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 114 1. Introduction 116 For many years, the assignment of new service names and port number 117 values for use with the Transmission Control Protocol (TCP) [RFC0793] 118 and the User Datagram Protocol (UDP) [RFC0768] have had less than 119 clear guidelines. New transport protocols have been added - the 120 Stream Control Transmission Protocol (SCTP) [RFC4960] and the 121 Datagram Congestion Control Protocol (DCCP) [RFC4342] - and new 122 mechanisms like DNS SRV records [RFC2782] have been developed, each 123 with separate registries and separate guidelines. The community also 124 recognized the need for additional procedures beyond just assignment; 125 notably modification, revocation, and release. 127 A key element of the procedural streamlining specified in this 128 document is to establish identical assignment procedures for all IETF 129 transport protocols. This document brings the IANA procedures for 130 TCP and UDP in line with those for SCTP and DCCP, resulting in a 131 single process that requesters and IANA follow for all requests for 132 all transport protocols, including future protocols not yet defined. 134 In addition to detailing the IANA procedures for the initial 135 assignment of service names and port numbers, this document also 136 specifies post-assignment procedures that until now have been handled 137 in an ad hoc manner. These include procedures to de-assign a port 138 number that is no longer in use, to take a port number assigned for 139 one service that is no longer in use and reuse it for another 140 service, and the procedure by which IANA can unilaterally revoke a 141 prior port number assignment. Section 8 discusses the specifics of 142 these procedures and processes that requesters and IANA follow for 143 all requests for all current and future transport protocols. 145 IANA is the authority for assigning service names and port numbers. 146 The registries that are created to store these assignments are 147 maintained by IANA. For protocols developed by IETF working groups, 148 IANA now also offers a method for the "early assignment" [RFC4020] of 149 service names and port numbers, as described in Section 8.1. 151 This document updates IANA's procedures for UDP and TCP port numbers 152 by obsoleting Sections 8 and 9.1 of the IANA assignment guidelines 153 [RFC2780]. (Note that other sections of the IANA assignment 154 guidelines, relating to the protocol field values in IPv4 headers, 155 were also updated in February 2008 [RFC5237].) This document also 156 updates the IANA assignment procedures for DCCP [RFC4340] 157 [RFC5595]and SCTP [RFC4960]. 159 The Lightweight User Datagram Protocol (UDP-Lite) shares the port 160 space with UDP. The UDP-Lite specification [RFC3828] says: "UDP-Lite 161 uses the same set of port number values assigned by the IANA for use 162 by UDP". An update of the UDP procedures therefore also results in a 163 corresponding update of the UDP-Lite procedures. 165 This document also clarifies what a service name is and how it is 166 assigned. This will impact the DNS SRV specification [RFC2782], 167 because that specification merely makes a brief mention that the 168 symbolic names of services are defined in "Assigned Numbers" 169 [RFC1700], without stating to which section it refers within that 170 230-page document. The DNS SRV specification may have been referring 171 to the list of Port Assignments (known as /etc/services on Unix), or 172 to the "Protocol And Service Names" section, or to both, or to some 173 other section. Furthermore, "Assigned Numbers" [RFC1700] has been 174 obsoleted [RFC3232] and has been replaced by on-line registries 175 [PORTREG][PROTSERVREG]. 177 The development of new transport protocols is a major effort that the 178 IETF does not undertake very often. If a new transport protocol is 179 standardized in the future, it is expected to follow these guidelines 180 and practices around using service names and port numbers as much as 181 possible, for consistency. 183 2. Motivation 185 Information about the assignment procedures for the port registry has 186 existed in three locations: the forms for requesting port number 187 assignments on the IANA web site [SYSFORM][USRFORM], an introductory 188 text section in the file listing the port number assignments 189 themselves (known as the port numbers registry) [PORTREG], and two 190 brief sections of the IANA Allocation Guidelines [RFC2780]. 192 Similarly, the procedures surrounding service names have been 193 historically unclear. Service names were originally created as 194 mnemonic identifiers for port numbers without a well-defined syntax, 195 apart from the 14-character limit mentioned on the IANA website 196 [SYSFORM][USRFORM]. Even that length limit has not been consistently 197 applied, and some assigned service names are 15 characters long. 198 When service identification via DNS SRV Resource Records (RRs) was 199 introduced [RFC2782], it became useful to start assigning service 200 names alone, and because IANA had no procedure for assigning a 201 service name without an associated port number, this lead to the 202 creation of an informal temporary service name registry outside of 203 the control of IANA, which now contains roughly 500 service names 204 [SRVREG]. 206 This document aggregates all this scattered information into a single 207 reference that aligns and clearly defines the management procedures 208 for both service names and port numbers. It gives more detailed 209 guidance to prospective requesters of service names and ports than 210 the existing documentation, and it streamlines the IANA procedures 211 for the management of the registry, so that requests can be completed 212 in a timely manner. 214 This document defines rules for assignment of service names without 215 associated port numbers, for such usages as DNS SRV records 216 [RFC2782], which was not possible under the previous IANA procedures. 217 The document also merges service name assignments from the non-IANA 218 ad hoc registry [SRVREG] and from the IANA "Protocol and Service 219 Names" registry [PROTSERVREG] into the IANA "Service Name and 220 Transport Protocol Port Number" registry [PORTREG], which from here 221 on is the single authoritative registry for service names and port 222 numbers. 224 An additional purpose of this document is to describe the principles 225 that guide the IETF and IANA in their role as the long-term joint 226 stewards of the service name and port number registry. TCP and UDP 227 have had remarkable success over the last decades. Thousands of 228 applications and application-level protocols have service names and 229 port numbers assigned for their use, and there is every reason to 230 believe that this trend will continue into the future. It is hence 231 extremely important that management of the registry follow principles 232 that ensure its long-term usefulness as a shared resource. Section 7 233 discusses these principles in detail. 235 3. Background 237 The Transmission Control Protocol (TCP) [RFC0793] and the User 238 Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success 239 over the decades as the two most widely used transport protocols on 240 the Internet. They have relied on the concept of "ports" as logical 241 entities for Internet communication. Ports serve two purposes: 242 first, they provide a demultiplexing identifier to differentiate 243 transport sessions between the same pair of endpoints, and second, 244 they may also identify the application protocol and associated 245 service to which processes connect. Newer transport protocols, such 246 as the Stream Control Transmission Protocol (SCTP) [RFC4960] and the 247 Datagram Congestion Control Protocol (DCCP) [RFC4342] have also 248 adopted the concept of ports for their communication sessions and use 249 16-bit port numbers in the same way as TCP and UDP (and UDP-Lite 250 [RFC3828], a variant of UDP). 252 Port numbers are the original and most widely used means for 253 application and service identification on the Internet. Ports are 254 16-bit numbers, and the combination of source and destination port 255 numbers together with the IP addresses of the communicating end 256 systems uniquely identifies a session of a given transport protocol. 257 Port numbers are also known by their associated service names such as 258 "telnet" for port number 23 and "http" (as well as "www" and "www- 259 http") for port number 80. 261 Hosts running services, hosts accessing services on other hosts, and 262 intermediate devices (such as firewalls and NATs) that restrict 263 services need to agree on which service corresponds to a particular 264 destination port. Although this is ultimately a local decision with 265 meaning only between the endpoints of a connection, it is common for 266 many services to have a default port upon which those servers usually 267 listen, when possible, and these ports are recorded by the Internet 268 Assigned Numbers Authority (IANA) through the service name and port 269 number registry [PORTREG]. 271 Over time, the assumption that a particular port number necessarily 272 implies a particular service may become less true. For example, 273 multiple instances of the same service on the same host cannot 274 generally listen on the same port, and multiple hosts behind the same 275 NAT gateway cannot all have a mapping for the same port on the 276 external side of the NAT gateway, whether using static port mappings 277 configured by hand by the user, or dynamic port mappings configured 278 automatically using a port mapping protocol like NAT Port Mapping 279 Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] or Internet Gateway Device 280 (IGD) [IGD]. 282 Applications may use port numbers directly, look up port numbers 283 based on service names via system calls such as getservbyname() on 284 UNIX, look up port numbers by performing queries for DNS SRV records 285 [RFC2782][I-D.cheshire-dnsext-dns-sd], or determine port numbers in a 286 variety of other ways like the TCP Port Service Multiplexer (TCPMUX) 287 [RFC1078]. 289 Designers of applications and application-level protocols may apply 290 to IANA for an assigned service name and port number for a specific 291 application, and may - after assignment - assume that no other 292 application will use that service name or port number for its 293 communication sessions. Application designers also have the option 294 of requesting only an assigned service name without a corresponding 295 fixed port number if their application does not require one, such as 296 applications that use DNS SRV records to look up port numbers 297 dynamically at runtime. Because the port number space is finite (and 298 therefore conservation is an important goal) the alternative of using 299 service names instead of port numbers is RECOMMENDED whenever 300 possible. 302 4. Conventions Used in this Document 304 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 305 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 306 "OPTIONAL" in this document are to be interpreted as described in 307 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 309 This document uses the term "assignment" to refer to the procedure by 310 which IANA provides service names and/or port numbers to requesting 311 parties; other RFCs refer to this as "allocation" or "registration". 312 This document assumes that all these terms have the same meaning, and 313 will use terms other than "assignment" when quoting from or referring 314 to text in these other documents. 316 5. Service Names 318 Service names are the unique key in the Service Name and Transport 319 Protocol Port Number Registry. This unique symbolic name for a 320 service may also be used for other purposes, such as in DNS SRV 321 records [RFC2782]. Within the registry, this unique key ensures that 322 different services can be unambiguously distinguished, thus 323 preventing name collisions and avoiding confusion about who is the 324 Assignee for a particular entry. 326 There may be more than one service name associated with a particular 327 transport protocol and port. There are three ways that such port 328 number overloading can occur: 330 o Overloading occurs when one service is an extension of another 331 service, and an in-band mechanism exists for determining if the 332 extension is present or not. One example is port 3478, which has 333 the service name aliases "stun" and "turn". TURN [RFC5766] is an 334 extension to the STUN [RFC5389] service. TURN-enabled clients 335 wishing to locate TURN servers could attempt to discover "stun" 336 services and then check in-band if the server also supports TURN, 337 but this would be inefficient. Enabling them to directly query 338 for "turn" servers by name is a better approach. (Note that TURN 339 servers in this case should also be locatable via a "stun" 340 discovery, because every TURN server is also a STUN server.) 342 o By historical accident, the service name "http" has two synonyms 343 "www" and "www-http". When used in SRV records [RFC2782] and 344 similar service discovery mechanisms, only the service name "http" 345 should be used, not these additional names. If a server were to 346 advertise "www", it would not be discovered by clients browsing 347 for "http". Advertising or browsing for the aliases as well as 348 the primary service name is inefficient, and achieves nothing that 349 is not already achieved by using the service name "http" 350 exclusively. 352 o As indicated in this document in Section 10.1, overloading has 353 been used to create replacement names that are consistent with the 354 syntax this document prescribes for legacy names that do not 355 conform to this syntax already. For such cases, only the new name 356 should be used in SRV records, to avoid the same issues as with 357 historical cases of multiple names, and also because the legacy 358 names are incompatible with SRV record use. 360 Assignment requests for new names for existing registered services 361 will be rejected, as a result. Implementers are requested to inform 362 IANA if they discover other cases where a single service has multiple 363 names, so that one name may be recorded as the primary name for 364 service discovery purposes. 366 Service names are assigned on a "first come, first served" basis, as 367 described in Section 8.1. Names should be brief and informative, 368 avoiding words or abbreviations that are redundant in the context of 369 the registry (e.g., "port", "service", "protocol", etc.) Names 370 referring to discovery services, e.g., using multicast or broadcast 371 to identify endpoints capable of a given service, SHOULD use an 372 easily identifiable suffix (e.g., "-disc"). 374 5.1. Service Name Syntax 376 Valid service names are hereby normatively defined as follows: 378 o MUST be at least 1 character and no more than 15 characters long 380 o MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and 381 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or 382 decimal 45) 384 o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z') 386 o MUST NOT begin or end with a hyphen 388 o hyphens MUST NOT be adjacent to other hyphens 390 The reason for requiring at least one letter is to avoid service 391 names like "23" (could be confused with a numeric port) or "6000- 392 6063" (could be confused with a numeric port range). Although 393 service names may contain both upper-case and lower-case letters, 394 case is ignored for comparison purposes, so both "http" and "HTTP" 395 denote the same service. 397 Service names are purely opaque identifiers, and no semantics are 398 implied by any superficial structure that a given service name may 399 appear to have. For example, a company called "Example" may choose 400 to register service names "Example-Foo" and "Example-Bar" for its 401 "Foo" and "Bar" products, but the "Example" company cannot claim to 402 "own" all service names beginning with "Example-"; they cannot 403 prevent someone else from registering "Example-Baz" for a different 404 service, and they cannot prevent other developers from using the 405 "Example-Foo" and "Example-Bar" service types in order to 406 interoperate with the "Foo" and "Bar" products. Technically 407 speaking, in service discovery protocols, service names are merely a 408 series of byte values on the wire; for the mnemonic convenience of 409 human developers it can be convenient to interpret those byte values 410 as human-readable ASCII characters, but software should treat them as 411 purely opaque identifiers and not attempt to parse them for any 412 additional embedded meaning. 414 In approximately 98% of cases, the new "service name" is exactly the 415 same as the old historic "short name" from the IANA web forms 416 [SYSFORM] [USRFORM]. In approximately 2% of cases, the new "service 417 name" is derived from the old historic "short name" as described 418 below in Section 10.1. 420 The rules for valid service names, excepting the limit of 15 421 characters maximum, are also expressed below (as a non-normative 422 convenience) using ABNF [RFC5234]. 424 SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM) 425 ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 426 HYPHEN = %x2D ; "-" 427 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] 428 DIGIT = %x30-39 ; 0-9 [RFC5234] 430 5.2. Service Name Usage in DNS SRV Records 432 The DNS SRV specification [RFC2782] states that the Service Label 433 part of the owner name of a DNS SRV record includes a "Service" 434 element, described as "the symbolic name of the desired service", but 435 as discussed above, it is not clear precisely what this means. 437 This document clarifies that the Service Label MUST be a service name 438 as defined herein with an underscore prepended. The service name 439 SHOULD be registered with IANA and recorded in the Service Name and 440 Transport Protocol Port Number Registry [PORTREG]. 442 The details of using Service Names in SRV Service Labels are 443 specified in the DNS SRV specification [RFC2782]. 445 6. Port Number Ranges 447 TCP, UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for their 448 port number registries. The port registries for all of these 449 transport protocols are subdivided into three ranges of numbers 450 [RFC1340], and Section 8.1.2 describes the IANA procedures for each 451 range in detail: 453 o the System Ports, also known as the Well Known Ports, from 0-1023 454 (assigned by IANA) 456 o the User Ports, also known as the Registered Ports, from 1024- 457 49151 (assigned by IANA) 459 o the Dynamic Ports, also known as the Private or Ephemeral Ports, 460 from 49152-65535 (never assigned) 462 Of the assignable port ranges (System Ports and User Ports, i.e., 463 port numbers 0-49151), individual port numbers are in one of three 464 states at any given time: 466 o Assigned: Assigned port numbers are currently assigned to the 467 service indicated in the registry. 469 o Unassigned: Unassigned port numbers are currently available for 470 assignment upon request, as per the procedures outlined in this 471 document. 473 o Reserved: Reserved port numbers are not available for regular 474 assignment; they are "assigned to IANA" for special purposes. 475 Reserved port numbers include values at the edges of each range, 476 e.g., 0, 1023, 1024, etc., which may be used to extend these 477 ranges or the overall port number space in the future. 479 In order to keep the size of the registry manageable, IANA typically 480 only records the Assigned and Reserved service names and port numbers 481 in the registry. Unassigned values are typically not explicitly 482 listed. (There are very many Unassigned service names and 483 enumerating them all would not be practical.) 485 As a data point, when this document was written, approximately 76% of 486 the TCP and UDP System Ports were assigned, and approximately 9% of 487 the User Ports were assigned. (As noted, Dynamic Ports are never 488 assigned.) 490 6.1. Service names and Port Numbers for Experimentation 492 Of the System Ports, two TCP and UDP port numbers (1021 and 1022), 493 together with their respective service names ("exp1" and "exp2"), 494 have been assigned for experimentation with new applications and 495 application-layer protocols that require a port number in the 496 assigned ports range [RFC4727]. 498 Please refer to Sections 1 and 1.1 of "Assigning Experimental and 499 Testing Numbers Considered Useful" [RFC3692] for how these 500 experimental port numbers are to be used. 502 This document assigns the same two service names and port numbers for 503 experimentation with new application-layer protocols over SCTP and 504 DCCP in Section 10.2. 506 Unfortunately, it can be difficult to limit access to these ports. 507 Users SHOULD take measures to ensure that experimental ports are 508 connecting to the intended process. For example, users of these 509 experimental ports might include a 64-bit nonce, once on each segment 510 of a message-oriented channel (e.g., UDP), or once at the beginning 511 of a byte-stream (e.g., TCP), which is used to confirm that the port 512 is being used as intended. Such confirmation of intended use is 513 especially important when these ports are associated with privileged 514 (e.g., system or administrator) processes. 516 7. Principles for Service Name and Transport Protocol Port Number 517 Registry Management 519 Management procedures for the service name and transport protocol 520 port number registry include assignment of service names and port 521 numbers upon request, as well as management of information about 522 existing assignments. The latter includes maintaining contact and 523 description information about assignments, revoking abandoned 524 assignments, and redefining assignments when needed. Of these 525 procedures, careful port number assignment is most critical, in order 526 to continue to conserve the remaining port numbers. 528 As noted earlier, only about 9% of the User Port space is currently 529 assigned. The current rate of assignment is approximately 400 ports 530 per year, and has remained steady for the past 8 years. At that 531 rate, if similar conservation continues, this resource will sustain 532 another 85 years of assignment - without the need to resort to 533 reassignment of released values or revocation. The namespace 534 available for service names is much larger, which allows for simpler 535 management procedures. 537 7.1. Past Principles 539 The principles for service name and port number management are based 540 on the recommendations of the IANA "Expert Review" team. Until 541 recently, that team followed a set of informal guidelines developed 542 based on the review experience from previous assignment requests. 543 These original guidelines, although informal, had never been publicly 544 documented. They are recorded here for historical purposes only; the 545 current guidelines are described in Section 7.2. These guidelines 546 previously were: 548 o TCP and UDP ports were simultaneously assigned when either was 549 requested 551 o Port numbers were the primary assignment; service names were 552 informative only, and did not have a well-defined syntax 554 o Port numbers were conserved informally, and sometimes 555 inconsistently (e.g., some services were assigned ranges of many 556 port numbers even where not strictly necessary) 558 o SCTP and DCCP service name and port number registries were managed 559 separately from the TCP/UDP registries 561 o Service names could not be assigned in the old ports registry 562 without assigning an associated port number at the same time 564 7.2. Updated Principles 566 This section summarizes the current principles by which IANA both 567 handles the Service Name and Transport Protocol Port Number Registry 568 and attempts to conserve the port number space. This description is 569 intended to inform applicants requesting service names and port 570 numbers. IANA has flexibility beyond these principles when handling 571 assignment requests; other factors may come into play, and exceptions 572 may be made to best serve the needs of the Internet. Applicants 573 should be aware that IANA decisions are not required to be bound to 574 these principles. These principles and general advice to users on 575 port use are expected to change over time and are therefore 576 documented separately, please see [I-D.touch-tsvwg-port-use]. 578 IANA strives to assign service names that do not request an 579 associated port number assignment under a simple "First Come, First 580 Served" policy [RFC5226]. IANA MAY, at its discretion, refer service 581 name requests to "Expert Review" in cases of mass assignment requests 582 or other situations where IANA believes expert review is advisable 583 [RFC5226]; use of the "Expert Review" helps advise IANA informally in 584 cases where "IETF Review" or "IESG Review" is used, as with most IETF 585 protocols. 587 The basic principle of service name and port number registry 588 management is to conserve use of the port space where possible. 589 Extensions to support larger port number spaces would require 590 changing many core protocols of the current Internet in a way that 591 would not be backward compatible and interfere with both current and 592 legacy applications. 594 Conservation of the port number space is required because this space 595 is a limited resource, so applications are expected to participate in 596 the traffic demultiplexing process where feasible. The port numbers 597 are expected to encode as little information as possible that will 598 still enable an application to perform further demultiplexing by 599 itself. In particular, the principles form a goal that IANA strives 600 to achieve for new applications (with exceptions as deemed 601 appropriate, especially as for extensions to legacy services) as 602 follows: 604 o IANA strives to assign only one assigned port number per service 605 or application 607 o IANA strives to assign only one assigned port number for all 608 variants of a service (e.g., for updated versions of a service) 610 o IANA strives to encourage the deployment of secure protocols 612 o IANA strives to assign only one assigned port number for all 613 different types of device using or participating in the same 614 service 616 o IANA strives to assign port numbers only for the transport 617 protocol(s) explicitly named in an assignment request 619 o IANA may recover unused port numbers, via the new procedures of 620 de-assignment, revocation, and transfer 622 Where possible, a given service is expected to demultiplex messages 623 if necessary. For example, applications and protocols are expected 624 to include in-band version information, so that future versions of 625 the application or protocol can share the same assigned port. 626 Applications and protocols are also expected to be able to 627 efficiently use a single assigned port for multiple sessions, either 628 by demultiplexing multiple streams within one port, or using the 629 assigned port to coordinate using dynamic ports for subsequent 630 exchanges (e.g., in the spirit of FTP [RFC0959]. 632 These principles of port conservation are explained further in 634 [I-D.touch-tsvwg-port-use]. That document explains in further detail 635 how ports are used in various ways, notably: 637 o as endpoint process identifiers 639 o as application protocol identifiers 641 o for firewall filtering purposes 643 Both the process identifier and the protocol identifier uses suggest 644 that anything a single process can demultiplex, or that can be 645 encoded into a single protocol, should be. The firewall filtering 646 use suggests that some uses that could be multiplexed or encoded 647 could instead be separated to allow for easier firewall management. 648 Note that this latter use is much less sound, because port numbers 649 have meaning only for the two endpoints involved in a connection, and 650 drawing conclusions about the service that generated a given flow 651 based on observed port numbers is not always reliable. 653 IANA will begin assigning port numbers for only those transport 654 protocols explicitly included in an assignment request. This ends 655 the long-standing practice of automatically assigning a port number 656 to an application for both TCP and UDP, even if the request is for 657 only one of these transport protocols. The new assignment procedure 658 conserves resources by assigning a port number to an application for 659 only those transport protocols (TCP, UDP, SCTP and/or DCCP) it 660 actually uses. The port number will be marked as Reserved - instead 661 of Assigned - in the port number registries of the other transport 662 protocols. When applications start supporting the use of some of 663 those additional transport protocols, the Assignee for the assignment 664 MUST request IANA convert these reserved ports into assignments. An 665 application MUST NOT assume that it can use a port number assigned to 666 it for use with one transport protocol with another transport 667 protocol without IANA converting the reservation into an assignment. 669 When the available pool of unassigned numbers has run out in a port 670 range, it will be necessary for IANA to consider the Reserved ports 671 for assignment. This is part of the motivation for not automatically 672 assigning ports for transport protocols other than the requested 673 one(s). This will allow more ports to be available for assignment at 674 that point. To help conserve ports, application developers SHOULD 675 request assignment of only those transport protocols that their 676 application currently uses. 678 Conservation of port numbers is improved by procedures that allow 679 previously allocated port numbers to become Unassigned, either 680 through de-assignment or through revocation, and by a procedure that 681 lets application designers transfer an assigned but unused port 682 number to a new application. Section 8 describes these procedures, 683 which until now were undocumented. Port number conservation is also 684 improved by recommending that applications that do not require an 685 assigned port should register only a service name without an 686 associated port number. 688 8. IANA Procedures for Managing the Service Name and Transport Protocol 689 Port Number Registry 691 This section describes the process for handling requests associated 692 with IANA's management of the Service Name and Transport Protocol 693 Port Number Registry. Such requests include initial assignment, de- 694 assignment, reuse, changes to the service name, and updates to the 695 contact information or description associated with an assignment. 696 Revocation is as additional process, initiated by IANA. 698 8.1. Service Name and Port Number Assignment 700 Assignment refers to the process of providing service names or port 701 numbers to applicants. All such assignments are made from service 702 names or port numbers that are Unassigned or Reserved at the time of 703 the assignment. 705 o Unassigned names and numbers are allocated according to the rules 706 described in Section 8.1.2 below. 708 o Reserved numbers and names are generally only assigned by a 709 Standards Action or an IESG Approval, and MUST be accompanied by a 710 statement explaining the reason a Reserved number or name is 711 appropriate for this action. The only exception to this rule is 712 that the current Assignee of a port number MAY request the 713 assignment of the corresponding Reserved port number for other 714 transport protocols when needed. IANA will initiate an "Expert 715 Review" [RFC5226] for such requests. 717 When an assignment for one or more transport protocols is approved, 718 the port number for any non-requested transport protocol(s) will be 719 marked as Reserved. IANA SHOULD NOT assign that port number to any 720 other application or service until no other port numbers remain 721 Unassigned in the requested range. 723 8.1.1. General Assignment Procedure 724 A service name or port number assignment request contains the 725 following information. The service name is the unique identifier of 726 a given service: 728 Service Name (REQUIRED) 729 Transport Protocol(s) (REQUIRED) 730 Assignee (REQUIRED) 731 Contact (REQUIRED) 732 Description (REQUIRED) 733 Reference (REQUIRED) 734 Port Number (OPTIONAL) 735 Service Code (REQUIRED for DCCP only) 736 Known Unauthorized Uses (OPTIONAL) 737 Assignment Notes (OPTIONAL) 739 o Service Name: A desired unique service name for the service 740 associated with the assignment request MUST be provided. This 741 name may be used with various service selection and discovery 742 mechanisms (including, but not limited to, DNS SRV records 743 [RFC2782]). The name MUST be compliant with the syntax defined in 744 Section 5.1. In order to be unique, they MUST NOT be identical to 745 any currently assigned service name in the IANA registry 746 [PORTREG]. Service names are case-insensitive; they may be 747 provided and entered into the registry with mixed case for 748 clarity, but for the comparison purposes the case is ignored. 750 o Transport Protocol(s): The transport protocol(s) for which an 751 assignment is requested MUST be provided. This field is currently 752 limited to one or more of TCP, UDP, SCTP, and DCCP. Requests 753 without any port assignment and only a service name are still 754 required to indicate which protocol the service uses. 756 o Assignee: Name and email address of the party to whom the 757 assignment is made. This is REQUIRED. The Assignee is the 758 organization, company or individual person responsible for the 759 initial assignment. For assignments done through RFCs published 760 via the "IETF Document Stream" [RFC4844], the Assignee will be the 761 IESG . 763 o Contact: Name and email address of the Contact person for the 764 assignment. This is REQUIRED. The Contact person is the 765 responsible person for the Internet community to send questions 766 to. This person is also authorized to submit changes on behalf of 767 the Assignee; in cases of conflict between the Assignee and the 768 Contact, the Assignee decisions take precedence. Additional 769 address information MAY be provided. For assignments done through 770 RFCs published via the "IETF Document Stream" [RFC4844], the 771 Contact will be the IETF Chair . 773 o Description: A short description of the service associated with 774 the assignment request is REQUIRED. It should avoid all but the 775 most well-known acronyms. 777 o Reference: A description of (or a reference to a document 778 describing) the protocol or application using this port. The 779 description must state whether the protocol uses IP-layer 780 broadcast, multicast, or anycast communication. 782 For assignments requesting only a Service Name, or a Service Name 783 and User Port, a statement that the protocol is proprietary and 784 not publicly documented is also acceptable, provided that the 785 required information regarding the use of IP broadcast, multicast, 786 or anycast is given. 788 For any assignment request that includes a User Port, the 789 assignment request MUST explain why a port number in the Dynamic 790 Ports range is unsuitable for the given application. 792 For any assignment request that includes a System Port, the 793 assignment request MUST explain why a port number in the User 794 Ports or Dynamic Ports ranges is unsuitable, and a reference to a 795 stable protocol specification document MUST be provided. 797 IANA MAY accept early assignment [RFC4020] requests (known as 798 "early allocation" therein) from IETF Working Groups that 799 reference a sufficiently stable Internet Draft instead of a 800 published Standards-Track RFC. 802 o Port Number: If assignment of a port number is desired, either the 803 port number the requester suggests for assignment or indication of 804 port range (user or system) MUST be provided. If only a service 805 name is to be assigned, this field is left empty. If a specific 806 port number is requested, IANA is encouraged to assign the 807 requested number. If a range is specified, IANA will choose a 808 suitable number from the User or System Ports ranges. Note that 809 the applicant MUST NOT use the requested port prior to the 810 completion of the assignment. 812 o Service Code: If the assignment request includes DCCP as a 813 transport protocol then the request MUST include a desired unique 814 DCCP service code [RFC5595], and MUST NOT include a requested DCCP 815 service code otherwise. Section 19.8 of the DCCP specification 816 [RFC4340] defines requirements and rules for assignment, updated 817 by this document. Note that, as per [RFC5595], some service codes 818 are not assigned; zero (absence of a meaningful service code) or 819 4294967295 (invalid service code) are permanently reserved, and 820 the Private service codes 1056964608-1073741823 (i.e., 32-bit 821 values with the high-order byte equal to a value of 63, 822 corresponding to the ASCII character '?') are not centrally 823 assigned. 825 o Known Unauthorized Uses: A list of uses by applications or 826 organizations who are not the Assignee. This list may be 827 augmented by IANA after assignment when unauthorized uses are 828 reported. 830 o Assignment Notes: Indications of owner/name change, or any other 831 assignment process issue. This list may be updated by IANA after 832 assignment to help track changes to an assignment, e.g., de- 833 assignment, owner/name changes, etc. 835 If the assignment request is for the addition of a new transport 836 protocol to an already-assigned service name and the requester is not 837 the Assignee or Contact for the already-assigned service name, IANA 838 needs to confirm with the Assignee for the existing assignment 839 whether this addition is appropriate. 841 If the assignment request is for a new service name sharing the same 842 port as an already-assigned service name (see port number overloading 843 in Section 5), IANA needs to confirm with the Assignee for the 844 existing service name and other appropriate experts whether the 845 overloading is appropriate. 847 When IANA receives an assignment request - containing the above 848 information - that is requesting a port number, IANA SHALL initiate 849 an "Expert Review" [RFC5226] in order to determine whether an 850 assignment should be made. For requests that are not seeking a port 851 number, IANA SHOULD assign the service name under a simple "First 852 Come First Served" policy [RFC5226]. 854 8.1.2. Variances for Specific Port Number Ranges 856 Section 6 describes the different port number ranges. It is 857 important to note that IANA applies slightly different procedures 858 when managing the different port ranges of the service name and port 859 number registry: 861 o Ports in the Dynamic Ports range (49152-65535) have been 862 specifically set aside for local and dynamic use and cannot be 863 assigned through IANA. Application software may simply use any 864 dynamic port that is available on the local host, without any sort 865 of assignment. On the other hand, application software MUST NOT 866 assume that a specific port number in the Dynamic Ports range will 867 always be available for communication at all times, and a port 868 number in that range hence MUST NOT be used as a service 869 identifier. 871 o Ports in the User Ports range (1024-49151) are available for 872 assignment through IANA, and MAY be used as service identifiers 873 upon successful assignment. Because assigning a port number for a 874 specific application consumes a fraction of the shared resource 875 that is the port number registry, IANA will require the requester 876 to document the intended use of the port number. For most IETF 877 protocols, ports in the User Ports range will be assigned under 878 the "IETF Review" or "IESG Approval" procedures [RFC5226] and no 879 further documentation is required. Where these procedures do not 880 apply, then the requester must input the documentation to the 881 "Expert Review" procedure [RFC5226], by which IANA will have a 882 technical expert review the request to determine whether to grant 883 the assignment. Regardless of the path ("IETF Review", "IESG 884 Approval", or "Expert Review"), the submitted documentation is 885 expected to be the same, as described in this section, and MUST 886 explain why using a port number in the Dynamic Ports range is 887 unsuitable for the given application. Further, IANA MAY utilize 888 the Expert Review process informally to inform their position in 889 participating in "IETF Review" and "IESG Review" 891 o Ports in the System Ports range (0-1023) are also available for 892 assignment through IANA. Because the System Ports range is both 893 the smallest and the most densely allocated, the requirements for 894 new assignments are more strict than those for the User Ports 895 range, and will only be granted under the "IETF Review" or "IESG 896 Approval" procedures [RFC5226]. A request for a System Port 897 number MUST document *both* why using a port number from the 898 Dynamic Ports range is unsuitable *and* why using a port number 899 from the User Ports range is unsuitable for that application. 901 8.2. Service Name and Port Number De-Assignment 903 The Assignee of a granted port number assignment can return the port 904 number to IANA at any time if they no longer have a need for it. The 905 port number will be de-assigned and will be marked as Reserved. IANA 906 should not re-assign port numbers that have been de-assigned until 907 all unassigned port numbers in the specific range have been assigned. 909 Before proceeding with a port number de-assignment, IANA needs to 910 reasonably establish that the value is actually no longer in use. 912 Because there is much less danger of exhausting the service name 913 space compared to the port number space, it is RECOMMENDED that a 914 given service name remain assigned even after all associated port 915 number assignments have become de-assigned. Under this policy, it 916 will appear in the registry as if it had been created through a 917 service name assignment request that did not include any port 918 numbers. 920 On rare occasions, it may still be useful to de-assign a service 921 name. In such cases, IANA will mark the service name as Reserved. 922 IANA will involve their IESG-appointed expert in such cases. 924 IANA will include a comment in the registry when de-assignment 925 happens to indicate its historic usage. 927 8.3. Service Name and Port Number Reuse 929 If the Assignee of a granted port number assignment no longer has a 930 need for the assigned number, but would like to reuse it for a 931 different application, they can submit a request to IANA to do so. 933 Logically, port number reuse is to be thought of as a de-assignment 934 (Section 8.2) followed by an immediate (re-)assignment (Section 8.1) 935 of the same port number for a new application. Consequently, the 936 information that needs to be provided about the proposed new use of 937 the port number is identical to what would need to be provided for a 938 new port number assignment for the specific ports range. 940 Because there is much less danger of exhausting the service name 941 space compared to the port number space, it is RECOMMENDED that the 942 original service name associated with the prior use of the port 943 number remains assigned, and a new service name be created and 944 associated with the port number. This is again consistent with 945 viewing a reuse request as a de-assignment followed by an immediate 946 (re-)assignment. Re-using an assigned service name for a different 947 application is NOT RECOMMENDED. 949 IANA needs to carefully review such requests before approving them. 950 In some instances, the Expert Reviewer will determine that the 951 application the port number was assigned to has found usage beyond 952 the original Assignee, or that there is a concern that it may have 953 such users. This determination MUST be made quickly. A community 954 call concerning revocation of a port number (see below) MAY be 955 considered, if a broader use of the port number is suspected. 957 8.4. Service Name and Port Number Revocation 959 A port number revocation can be thought of as an IANA-initiated de- 960 assignment (Section 8.2), and has exactly the same effect on the 961 registry. 963 Sometimes, it will be clear that a specific port number is no longer 964 in use and that IANA can revoke it and mark it as Reserved. At other 965 times, it may be unclear whether a given assigned port number is 966 still in use somewhere in the Internet. In those cases, IANA must 967 carefully consider the consequences of revoking the port number, and 968 SHOULD only do so if there is an overwhelming need. 970 With the help of their IESG-appointed Expert Reviewer, IANA SHALL 971 formulate a request to the IESG to issue a four-week community call 972 concerning the pending port number revocation. The IESG and IANA, 973 with the Expert Reviewer's support, SHALL determine promptly after 974 the end of the community call whether revocation should proceed and 975 then communicate their decision to the community. This procedure 976 typically involves similar steps to de-assignment except that it is 977 initiated by IANA. 979 Because there is much less danger of exhausting the service name 980 space compared to the port number space, revoking service names is 981 NOT RECOMMENDED. 983 8.5. Service Name and Port Number Transfers 985 The value of service names and port numbers is defined by their 986 careful management as a shared Internet resource, whereas enabling 987 transfer allows the potential for associated monetary exchanges. As 988 a result, the IETF does not permit service name or port number 989 assignments to be transferred between parties, even when they are 990 mutually consenting. 992 The appropriate alternate procedure is a coordinated de-assignment 993 and assignment: The new party requests the service name or port 994 number via an assignment and the previous party releases its 995 assignment via the de-assignment procedure outlined above. 997 With the help of their IESG-appointed Expert Reviewer, IANA SHALL 998 carefully determine if there is a valid technical, operational or 999 managerial reason to grant the requested new assignment. 1001 8.6. Maintenance Issues 1003 In addition to the formal procedures described above, updates to the 1004 Description and Contact information are coordinated by IANA in an 1005 informal manner, and may be initiated by either the Assignee or by 1006 IANA, e.g., by the latter requesting an update to current Contact 1007 information. (Note that the Assignee cannot be changed as a separate 1008 procedure; see instead Section 8.5 above.) 1010 8.7. Disagreements 1012 In the case of disagreements around any request there is the 1013 possibility of appeal following the normal appeals process for IANA 1014 assignments as defined by Section 7 of "Guidelines for Writing an 1015 IANA Considerations Section in RFCs" [RFC5226]. 1017 9. Security Considerations 1019 The IANA guidelines described in this document do not change the 1020 security properties of UDP, TCP, SCTP, or DCCP. 1022 Assignment of a service name or port number does not in any way imply 1023 an endorsement of an application or product, and the fact that 1024 network traffic is flowing to or from an assigned port number does 1025 not mean that it is "good" traffic, or even that it is used by the 1026 assigned service. Firewall and system administrators should choose 1027 how to configure their systems based on their knowledge of the 1028 traffic in question, not based on whether or not there is an assigned 1029 service name or port number. 1031 Services are expected to include support for security, either as 1032 default or dynamically negotiated in-band. The use of separate 1033 service name or port number assignments for secure and insecure 1034 variants of the same service is to be avoided in order to discourage 1035 the deployment of insecure services. 1037 10. IANA Considerations 1039 This document obsoletes Sections 8 and 9.1 of the March 2000 IANA 1040 Allocation Guidelines [RFC2780]. 1042 Upon approval of this document, IANA is requested to contact Stuart 1043 Cheshire, maintainer of the independent service name registry 1044 [SRVREG], in order to merge the contents of that private registry 1045 into the official IANA registry. It is expected that the independent 1046 registry web page will be updated with pointers to the IANA registry 1047 and to this RFC. 1049 IANA is instructed to create a new service name entry in the service 1050 name and port number registry [PORTREG] for any entry in the 1051 "Protocol and Service Names" registry [PROTSERVREG] that does not 1052 already have one assigned. 1054 IANA is also instructed to indicate in the Assignment Notes for "www" 1055 and "www-http" that they are duplicate terms that refer to the "http" 1056 service, and should not be used for discovery purposes. For this 1057 conceptual service (human-readable web pages served over HTTP) the 1058 correct service name to use for service discovery purposes is "http" 1059 (see Section 5). 1061 10.1. Service Name Consistency 1063 Section 8.1 defines which character strings are well-formed service 1064 names, which until now had not been clearly defined. The definition 1065 in Section 8.1 was chosen to allow maximum compatibility of service 1066 names with current and future service discovery mechanisms. 1068 As of August 5, 2009 approximately 98% of the so-called "Short Names" 1069 from existing port number assignments [PORTREG] meet the rules for 1070 legal service names stated in Section 8.1, and hence for these 1071 services their service name will be exactly the same as their "Short 1072 Name". 1074 The remaining approximately 2% of the exiting "Short Names" are not 1075 suitable to be used directly as well-formed service names because 1076 they contain illegal characters such as asterisks, dots, pluses, 1077 slashes, or underscores. All existing "Short Names" conform to the 1078 length requirement of 15 characters or fewer. For these unsuitable 1079 "Short Names", listed in the table below, the service name will be 1080 the Short Name with any illegal characters replaced by hyphens. IANA 1081 SHALL add an entry to the registry giving the new well-formed primary 1082 service name for the existing service, that otherwise duplicates the 1083 original assignment information. In the description field of this 1084 new entry giving the primary service name, IANA SHALL record that it 1085 assigns a well-formed service name for the previous service and 1086 reference the original assignment. In the Assignment Notes field of 1087 the original assignment, IANA SHALL add a note that this entry is an 1088 alias to the new well-formed service name, and that the old service 1089 name is historic, not usable for use with many common service 1090 discovery mechanisms. 1092 Names containing illegal characters to be replaced by hyphens: 1094 +----------------+-----------------+-----------------+ 1095 | 914c/g | acmaint_dbd | acmaint_transd | 1096 | atex_elmd | avanti_cdp | badm_priv | 1097 | badm_pub | bdir_priv | bdir_pub | 1098 | bmc_ctd_ldap | bmc_patroldb | boks_clntd | 1099 | boks_servc | boks_servm | broker_service | 1100 | bues_service | canit_store | cedros_fds | 1101 | cl/1 | contamac_icm | corel_vncadmin | 1102 | csc_proxy | cvc_hostd | dbcontrol_agent | 1103 | dec_dlm | dl_agent | documentum_s | 1104 | dsmeter_iatc | dsx_monitor | elpro_tunnel | 1105 | elvin_client | elvin_server | encrypted_admin | 1106 | erunbook_agent | erunbook_server | esri_sde | 1107 | EtherNet/IP-1 | EtherNet/IP-2 | event_listener | 1108 | flr_agent | gds_db | ibm_wrless_lan | 1109 | iceedcp_rx | iceedcp_tx | iclcnet_svinfo | 1110 | idig_mux | ife_icorp | instl_bootc | 1111 | instl_boots | intel_rci | interhdl_elmd | 1112 | lan900_remote | LiebDevMgmt_A | LiebDevMgmt_C | 1113 | LiebDevMgmt_DM | mapper-ws_ethd | matrix_vnet | 1114 | mdbs_daemon | menandmice_noh | msl_lmd | 1115 | nburn_id | ncr_ccl | nds_sso | 1116 | netmap_lm | nms_topo_serv | notify_srvr | 1117 | novell-lu6.2 | nuts_bootp | nuts_dem | 1118 | ocs_amu | ocs_cmu | pipe_server | 1119 | pra_elmd | printer_agent | redstorm_diag | 1120 | redstorm_find | redstorm_info | redstorm_join | 1121 | resource_mgr | rmonitor_secure | rsvp_tunnel | 1122 | sai_sentlm | sge_execd | sge_qmaster | 1123 | shiva_confsrvr | sql*net | srvc_registry | 1124 | stm_pproc | subntbcst_tftp | udt_os | 1125 | universe_suite | veritas_pbx | vision_elmd | 1126 | vision_server | wrs_registry | z39.50 | 1127 +----------------+-----------------+-----------------+ 1129 Following the example set by the "application/whoispp-query" MIME 1130 Content-Type [RFC2957], the service name for "whois++" will be 1131 "whoispp". 1133 10.2. Port Numbers for SCTP and DCCP Experimentation 1135 Two System UDP and TCP ports, 1021 and 1022, have been reserved for 1136 experimental use [RFC4727]. This document assigns the same port 1137 numbers for SCTP and DCCP, updates the TCP and UDP assignments, and 1138 also instructs IANA to automatically assign these two port numbers 1139 for any future transport protocol with a similar 16-bit port number 1140 namespace. 1142 Note that these port numbers are meant for temporary experimentation 1143 and development in controlled environments. Before using these port 1144 numbers, carefully consider the advice in Section 6.1 in this 1145 document, as well as in Sections 1 and 1.1 of "Assigning Experimental 1146 and Testing Numbers Considered Useful" [RFC3692]. Most importantly, 1147 application developers must request a permanent port number 1148 assignment from IANA as described in Section 8.1 before any kind of 1149 non-experimental deployment. 1151 +--------------------+-----------------------------+ 1152 | Service Name | exp1 | 1153 | Transport Protocol | DCCP, SCTP, TCP, UDP | 1154 | Assignee | IESG | 1155 | Contact | IETF Chair | 1156 | Description | RFC3692-style Experiment 1 | 1157 | Reference | [RFC4727] [RFCyyyy] | 1158 | Port Number | 1021 | 1159 +--------------------+-----------------------------+ 1161 +--------------------+-----------------------------+ 1162 | Service Name | exp2 | 1163 | Transport Protocol | DCCP, SCTP, TCP, UDP | 1164 | Assignee | IESG | 1165 | Contact | IETF Chair | 1166 | Description | RFC3692-style Experiment 2 | 1167 | Reference | [RFC4727] [RFCyyyy] | 1168 | Port Number | 1022 | 1169 +--------------------+-----------------------------+ 1171 [RFC Editor Note: Please change "yyyy" to the RFC number allocated to 1172 this document before publication.] 1174 10.3. Updates to DCCP Registries 1176 This document updates the IANA assignment procedures for the DCCP 1177 Port Number and DCCP Service Codes Registries [RFC4340]. 1179 10.3.1. DCCP Service Code Registry 1181 Service Codes are assigned first-come-first-served according to 1182 Section 19.8 of the DCCP specification [RFC4340]. This document 1183 updates that section by extending the guidelines given there in the 1184 following ways: 1186 o IANA MAY assign new Service Codes without seeking Expert Review 1187 using their discretion, but SHOULD seek expert review if a request 1188 asks for more than five Service Codes. 1190 o IANA should feel free to contact the DCCP Expert Reviewer with any 1191 questions related to requests for DCCP-related codepoints. 1193 10.3.2. DCCP Port Numbers Registry 1195 The DCCP ports registry is defined by Section 19.9 of the DCCP 1196 specification [RFC4340]. Assignments in this registry require prior 1197 assignment of a Service Code. Not all Service Codes require IANA- 1198 assigned ports. This document updates that section by extending the 1199 guidelines given there in the following way: 1201 o IANA should normally assign a value in the range 1024-49151 to a 1202 DCCP server port. IANA requests to assign port numbers in the 1203 System Ports range (0 through 1023), require an "IETF Review" 1204 [RFC5226] prior to assignment by IANA [RFC4340]. 1206 o IANA MUST NOT assign more than one DCCP server port to a single 1207 service code value. 1209 o The assignment of multiple service codes to the same DCCP port is 1210 allowed, but subject to expert review. 1212 o The set of Service Code values associated with a DCCP server port 1213 should be recorded in the service name and port number registry. 1215 o A request for additional Service Codes to be associated with an 1216 already-allocated Port Number requires Expert Review. These 1217 requests will normally be accepted when they originate from the 1218 contact associated with the port assignment. In other cases, 1219 these applications will be expected to use an unallocated port, 1220 when this is available. 1222 The DCCP specification [RFC4340] notes that a short port name MUST be 1223 associated with each DCCP server port that has been assigned. This 1224 document clarifies that this short port name is the Service Name as 1225 defined here, and this name MUST be unique. 1227 11. Contributors 1229 Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have 1230 contributed text and ideas to this document. 1232 12. Acknowledgments 1234 The text in Section 10.3 is based on a suggestion originally proposed 1235 as a part of the DCCP Service Codes document [RFC5595] by Gorry 1236 Fairhurst. 1238 Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a 1239 research project supported by the European Commission under its 1240 Seventh Framework Program. 1242 13. References 1244 13.1. Normative References 1246 [ANSI.X3-4.1986] 1247 American National Standards Institute, "Coded Character 1248 Set - 7-bit American Standard Code for Information 1249 Interchange", ANSI X3.4, 1986. 1251 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1252 August 1980. 1254 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1255 RFC 793, September 1981. 1257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1258 Requirement Levels", BCP 14, RFC 2119, March 1997. 1260 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1261 Values In the Internet Protocol and Related Headers", 1262 BCP 37, RFC 2780, March 2000. 1264 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1265 specifying the location of services (DNS SRV)", RFC 2782, 1266 February 2000. 1268 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1269 G. Fairhurst, "The Lightweight User Datagram Protocol 1270 (UDP-Lite)", RFC 3828, July 2004. 1272 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 1273 Standards Track Code Points", BCP 100, RFC 4020, 1274 February 2005. 1276 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1277 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1279 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1280 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1282 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1283 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1284 May 2008. 1286 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1287 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1289 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 1290 (DCCP) Service Codes", RFC 5595, September 2009. 1292 13.2. Informative References 1294 [I-D.cheshire-dnsext-dns-sd] 1295 Cheshire, S. and M. Krochmal, "DNS-Based Service 1296 Discovery", draft-cheshire-dnsext-dns-sd-08 (work in 1297 progress), January 2011. 1299 [I-D.cheshire-nat-pmp] 1300 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1301 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 1303 [I-D.touch-tsvwg-port-use] 1304 Touch, J., "Recommendations for Transport Port Uses", 1305 draft-touch-tsvwg-port-use-00 (work in progress), 1306 December 2010. 1308 [IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0", 1309 November 2001. 1311 [PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name 1312 and Transport Protocol Port Number Registry", 1313 http://www.iana.org/assignments/port-numbers. 1315 [PROTSERVREG] 1316 Internet Assigned Numbers Authority (IANA), "Protocol and 1317 Service Names Registry", 1318 http://www.iana.org/assignments/service-names. 1320 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 1321 STD 9, RFC 959, October 1985. 1323 [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", 1324 RFC 1078, November 1988. 1326 [RFC1340] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340, 1327 July 1992. 1329 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1330 October 1994. 1332 [RFC2957] Daigle, L. and P. Faltstrom, "The application/ 1333 whoispp-query Content-Type", RFC 2957, October 2000. 1335 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1336 an On-line Database", RFC 3232, January 2002. 1338 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1339 Considered Useful", BCP 82, RFC 3692, January 2004. 1341 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 1342 Datagram Congestion Control Protocol (DCCP) Congestion 1343 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 1344 March 2006. 1346 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 1347 Series and RFC Editor", RFC 4844, July 2007. 1349 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1350 RFC 4960, September 2007. 1352 [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for 1353 the Protocol Field", BCP 37, RFC 5237, February 2008. 1355 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1356 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1357 October 2008. 1359 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1360 Relays around NAT (TURN): Relay Extensions to Session 1361 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1363 [SRVREG] "DNS SRV Service Types Registry", 1364 http://www.dns-sd.org/ServiceTypes.html. 1366 [SYSFORM] Internet Assigned Numbers Authority (IANA), "Application 1367 for System (Well Known) Port Number", 1368 http://www.iana.org/. 1370 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 1372 [USRFORM] Internet Assigned Numbers Authority (IANA), "Application 1373 for User (Registered) Port Number", http://www.iana.org/. 1375 Authors' Addresses 1377 Michelle Cotton 1378 Internet Corporation for Assigned Names and Numbers 1379 4676 Admiralty Way, Suite 330 1380 Marina del Rey, CA 90292 1381 USA 1383 Phone: +1 310 823 9358 1384 Email: michelle.cotton@icann.org 1385 URI: http://www.iana.org/ 1387 Lars Eggert 1388 Nokia Research Center 1389 P.O. Box 407 1390 Nokia Group 00045 1391 Finland 1393 Phone: +358 50 48 24461 1394 Email: lars.eggert@nokia.com 1395 URI: http://research.nokia.com/people/lars_eggert/ 1397 Joe Touch 1398 USC/ISI 1399 4676 Admiralty Way 1400 Marina del Rey, CA 90292 1401 USA 1403 Phone: +1 310 448 9151 1404 Email: touch@isi.edu 1405 URI: http://www.isi.edu/touch 1407 Magnus Westerlund 1408 Ericsson 1409 Farogatan 6 1410 Stockholm 164 80 1411 Sweden 1413 Phone: +46 8 719 0000 1414 Email: magnus.westerlund@ericsson.com 1415 Stuart Cheshire 1416 Apple Inc. 1417 1 Infinite Loop 1418 Cupertino, CA 95014 1419 USA 1421 Phone: +1 408 974 3207 1422 Email: cheshire@apple.com