idnits 2.17.1 draft-ietf-tsvwg-iana-ports-09.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], [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 == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (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 (December 2, 2010) is 4894 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 1145, 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-07 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 -- Obsolete informational reference (is this intentional?): RFC 1078 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- 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 (==), 11 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 (if approved) Nokia 6 Intended status: BCP J. Touch 7 Expires: June 5, 2011 USC/ISI 8 M. Westerlund 9 Ericsson 10 S. Cheshire 11 Apple 12 December 2, 2010 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-09 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] and SCTP [RFC4960]. It also updates the DNS SRV 32 specification [RFC2782] to clarify what a service name is and how it 33 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 June 5, 2011. 51 Copyright Notice 53 Copyright (c) 2010 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 . . . . . . . . . . . . . . 7 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 . . . . 11 89 7. Principles for Service Name and Transport Protocol Port 90 Number Registry Management . . . . . . . . . . . . . . . . . . 12 91 7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . 20 98 8.4. Service Name and Port Number Revocation . . . . . . . . . 21 99 8.5. Service Name and Port Number Transfers . . . . . . . . . . 21 100 8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 22 101 8.7. Disagreements . . . . . . . . . . . . . . . . . . . . . . 22 102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 103 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 104 10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 23 105 10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 24 106 10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 25 107 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 109 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 110 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 111 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 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 header, 155 were also updated in February 2008 [RFC5237].) This document also 156 updates the IANA assignment procedures for DCCP [RFC4340] and SCTP 157 [RFC4960]. 159 The Lightweight User Datagram Protocol (UDP-Lite) shares the port 160 space with UDP. The UDP-Lite specification [RFC5237] says: "UDP-Lite 161 uses the same set of port number values assigned by the IANA for use 162 by UDP". Thus the update of UDP procedures result in an update also 163 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" is now obsolete 174 [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 ports assigned for their use, and there is every reason to believe 230 that this trend will continue into the future. It is hence extremely 231 important that management of the registry follow principles that 232 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. Alternatively, application designers may 294 also ask for only an assigned service name, if their application does 295 not require a fixed port number. The latter alternative is 296 encouraged when possible, in order to conserve the more limited port 297 number space. This is applicable, for example, to applications that 298 use DNS SRV records to look up port numbers at runtime. 300 4. Conventions Used in this Document 302 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 303 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 304 document are to be interpreted as described in "Key words for use in 305 RFCs to Indicate Requirement Levels" [RFC2119]. 307 This document uses the term "assignment" to refer to the procedure by 308 which IANA provides service names and/or port numbers to requesting 309 parties; other RFCs refer to this as "allocation" or "registration". 310 This document assumes that all these terms have the same meaning, and 311 will use terms other than "assignment" when quoting from or referring 312 to text in these other documents. 314 5. Service Names 316 Service names are the unique key in the Service Name and Transport 317 Protocol Port Number Registry. This unique symbolic name for a 318 service may also be used for other purposes, such as in DNS SRV 319 records [RFC2782]. Within the registry, this unique key ensures that 320 different services can be unambiguously distinguished, thus 321 preventing name collisions and avoiding confusion about who is the 322 Assignee for a particular entry. 324 There may be more than one service name associated with a particular 325 transport protocol and port. There are three ways that such port 326 number overloading can occur: 328 o Overloading occurs when one service is an extension of another 329 service, and an in-band mechanism exists for determining if the 330 extension is present or not. One example is port 3478, which has 331 the service name aliases "stun" and "turn". TURN [RFC5766] is an 332 extension to the STUN [RFC5389] service. TURN-enabled clients 333 wishing to locate TURN servers could attempt to discover "stun" 334 services and then check in-band if the server also supports TURN, 335 but this would be inefficient. Enabling them to directly query 336 for "turn" servers by name is a better approach. (Note that TURN 337 servers in this case should also be locatable via a "stun" 338 discovery, because every TURN server is also a STUN server.) 340 o By historical accident, the service name "http" has two synonyms 341 "www" and "www-http". When used in SRV records [RFC2782] and 342 similar service discovery mechanisms, only the service name "http" 343 should be used, not these additional names. If a server were to 344 advertise "www", it would not be discovered by clients browsing 345 for "http". Advertising or browsing for the aliases as well as 346 the primary service name is inefficient, and achieves nothing that 347 is not already achieved by using the service name "http" 348 exclusively. 350 o As indicated in this document in Section 10.1, overloading has 351 been used to create replacement names that are consistent with the 352 syntax this document prescribes for legacy names that do not 353 conform to this syntax already. For such cases, only the new name 354 should be used in SRV records, to avoid the same issues as with 355 historical cases of multiple names, and also because the legacy 356 names are incompatible with SRV record use. 358 For future assignments, applications will not be permitted that 359 merely request a new name exactly duplicating an existing service. 360 Having multiple names for the same service serves no purpose. 361 Implementers are requested to inform IANA if they discover other 362 cases where a single service has multiple names, so that one name may 363 be recorded as the primary name for service discovery purposes. 365 Service names are assigned on a "first come, first served" basis, as 366 described in Section 8.1. Names should be brief and informative, 367 avoiding words or abbreviations that are redundant in the context of 368 the registry (e.g., "port", "service", "protocol", etc.) Names 369 referring to discovery services, e.g., using multicast or broadcast 370 to identify endpoints capable of a given service, SHOULD use an 371 easily identifiable suffix (e.g., "-disc"). 373 5.1. Service Name Syntax 375 Valid service names are hereby normatively defined as follows: 377 o MUST be at least 1 character and no more than 15 characters long 379 o MUST contain only US-ASCII [ANSI.X3-4.1986] letters 'A' - 'Z' and 380 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or 381 decimal 45) 383 o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z') 385 o MUST NOT begin or end with a hyphen 387 o hyphens MUST NOT be adjacent to other hyphens 389 The reason for requiring at least one letter is to avoid service 390 names like "23" (could be confused with a numeric port) or "6000- 391 6063" (could be confused with a numeric port range). Although 392 service names may contain both upper-case and lower-case letters, 393 case is ignored for comparison purposes, so both "http" and "HTTP" 394 denote the same service. 396 Service names are purely opaque identifiers, and no semantics are 397 implied by any superficial structure that a given service name may 398 appear to have. For example, a company called "Example" may choose 399 to register service names "Example-Foo" and "Example-Bar" for its 400 "Foo" and "Bar" products, but the "Example" company cannot claim to 401 "own" all service names beginning with "Example-"; they cannot 402 prevent someone else from registering "Example-Baz" for a different 403 service, and they cannot prevent other developers from using the 404 "Example-Foo" and "Example-Bar" service types in order to 405 interoperate with the "Foo" and "Bar" products. Technically 406 speaking, in service discovery protocols, service names are merely a 407 series of byte values on the wire; for the mnemonic convenience of 408 human developers it can be convenient to interpret those byte values 409 as human-readable ASCII characters, but software should treat them as 410 purely opaque identifiers and not attempt to parse them for any 411 additional embedded meaning. 413 In approximately 98% of cases, the new "service name" is exactly the 414 same as the old historic "short name" from the IANA web forms 415 [SYSFORM] [USRFORM]. In approximately 2% of cases, the new "service 416 name" is derived from the old historic "short name" as described 417 below in Section 10.1. 419 The rules for valid service names, excepting the limit of 15 420 characters maximum, are also expressed below (as a non-normative 421 convenience) using ABNF [RFC5234]. 423 SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM) 424 ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 425 HYPHEN = %x2d ; "-" 426 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] 427 DIGIT = %x30-39 ; 0-9 [RFC5234] 429 5.2. Service Name Usage in DNS SRV Records 431 The DNS SRV specification [RFC2782] states that the Service Label 432 part of the owner name of a DNS SRV record includes a "Service" 433 element, described as "the symbolic name of the desired service", but 434 as discussed above, it is not clear precisely what this means. 436 This document clarifies that the Service Label MUST be a service name 437 as defined herein with an underscore prepended. The service name 438 SHOULD be registered with IANA and recorded in the Service Name and 439 Transport Protocol Port Number Registry [PORTREG]. 441 The details of using Service Names in SRV Service Labels are 442 specified in the DNS SRV specification [RFC2782]. This document does 443 not change that specification. 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 these transport 449 protocols are subdivided into three ranges of numbers, and 450 Section 8.1.1 describes the IANA procedures for each range in detail: 452 o the System Ports, also known as the Well Known Ports, from 0-1023 453 (assigned by IANA) 455 o the User Ports, also known as the Registered Ports, from 1024- 456 49151 (assigned by IANA) 458 o the Dynamic Ports, also known as the Private Ports, from 49152- 459 65535 (never assigned) 461 Of the assignable port ranges (System Ports and User Ports, i.e., 462 port numbers 0-49151), individual port numbers are in one of three 463 states at any given time: 465 o Assigned: Assigned port numbers are currently assigned to the 466 service indicated in the registry. 468 o Unassigned: Unassigned port numbers are currently available for 469 assignment upon request, as per the procedures outlined in this 470 document. 472 o Reserved: Reserved port numbers are not available for regular 473 assignment; they are "assigned to IANA" for special purposes. 474 Reserved port numbers include values at the edges of each range, 475 e.g., 0, 1023, 1024, etc., which may be used to extend these 476 ranges or the overall port number space in the future. 478 In order to keep the size of the registry manageable, IANA typically 479 only records the Assigned and Reserved service names and port numbers 480 in the registry. Unassigned values are typically not explicitly 481 listed. (There are a near-infinite number of Unassigned service 482 names and enumerating them all would not be practical.) 484 As a data point, when this document was written, approximately 76% of 485 the TCP and UDP System Ports were assigned, and approximately 9% of 486 the User Ports were assigned. (As noted, Dynamic Ports are never 487 assigned.) 489 6.1. Service names and Port Numbers for Experimentation 491 Of the System Ports, two TCP and UDP port numbers (1021 and 1022), 492 together with their respective service names ("exp1" and "exp2"), 493 have been assigned for experimentation with new applications and 494 application-layer protocols that require a port number in the 495 assigned ports ranges [RFC4727]. 497 Please refer to Sections 1 and 1.1 of "Assigning Experimental and 498 Testing Numbers Considered Useful" [RFC3692] for how these 499 experimental port numbers are to be used. 501 This document assigns the same two service names and port numbers for 502 experimentation with new application-layer protocols over SCTP and 503 DCCP in Section 10.2. 505 Unfortunately, it can be difficult to limit access to these ports. 506 Users SHOULD take measures to ensure that experimental ports are 507 connecting to the intended process. For example, users of these 508 experimental ports might include a 64-bit nonce, once on each segment 509 of a message-oriented channel (e.g., UDP), or once at the beginning 510 of a byte-stream (e.g., TCP), which is used to confirm that the port 511 is being used as intended. Such confirmation of intended use is 512 especially important when these ports are associated with privileged 513 (e.g., system or administrator) processes. 515 7. Principles for Service Name and Transport Protocol Port Number 516 Registry Management 518 Management procedures for the service name and transport protocol 519 port number registry include assignment of service names and port 520 numbers upon request, as well as management of information about 521 existing assignments. The latter includes maintaining contact and 522 description information about assignments, revoking abandoned 523 assignments, and redefining assignments when needed. Of these 524 procedures, careful port number assignment is most critical, in order 525 to continue to conserve the remaining port numbers. 527 As noted earlier, only about 9% of the User Port space is currently 528 assigned. The current rate of assignment is approximately 400 ports 529 per year, and has remained steady for the past 8 years. At that 530 rate, if similar conservation continues, this resource will sustain 531 another 85 years of assignment - without the need to resort to 532 reassignment of released values or revocation. The namespace 533 available for service names is much larger, which allows for simpler 534 management procedures. 536 7.1. Past Principles 538 The principles for service name and port number management are based 539 on the recommendations of the IANA "Expert Review" team. Until 540 recently, that team followed a set of informal guidelines developed 541 based on the review experience from previous assignment requests. 542 These original guidelines, although informal, had never been publicly 543 documented. They are recorded here for historical purposes only; the 544 current guidelines are described in Section 7.2. These guidelines 545 previously were: 547 o TCP and UDP ports were simultaneously assigned when either was 548 requested 550 o Port numbers were the primary assignment; service names were 551 informative only, and did not have a well-defined syntax 553 o Port numbers were conserved informally, and sometimes 554 inconsistently (e.g., some services were assigned ranges of many 555 port numbers even where not strictly necessary) 557 o SCTP and DCCP service name and port number registries were managed 558 separately from the TCP/UDP registries 560 o Service names could not be assigned in the old ports registry 561 without assigning an associated port number at the same time 563 7.2. Updated Principles 565 This section summarizes the current principles by which IANA handles 566 the Service Name and Transport Protocol Port Number Registry and 567 attempts to conserve the port number space. This description is 568 intended to inform applicants requesting service names and port 569 numbers. IANA has flexibility beyond these principles when handling 570 assignment requests; other factors may come into play, and exceptions 571 may be made to best serve the needs of the Internet. 573 IANA strives to assign service names that do not request an 574 associated port number assignment under a simple "First Come, First 575 Served" policy [RFC5226]. IANA MAY, at its discretion, refer service 576 name requests to "Expert Review" in cases of mass assignment requests 577 or other situations where IANA believes expert review is advisable. 579 The basic principle of service name and port number registry 580 management is to conserve use of the port space where possible. 581 Extensions to support larger port number spaces would require 582 changing many core protocols of the current Internet in a way that 583 would not be backward compatible and interfere with both current and 584 legacy applications. To help ensure this conservation the policy for 585 any assignment request for port number assignments uses the "Expert 586 Review" policy [RFC5226]. 588 Conservation of the port number space is required because this space 589 is a limited resource, so applications are expected to participate in 590 the traffic demultiplexing process where feasible. The port numbers 591 are expected to encode as little information as possible that will 592 still enable an application to perform further demultiplexing by 593 itself. In particular, the principles form a goal that IANA strives 594 to achieve for new applications (with exceptions as deemed 595 appropriate, especially as for extensions to legacy services) as 596 follows: 598 o IANA strives to assign only one assigned port number per service 599 or application 601 o IANA strives to assign only one assigned port number for all 602 variants of a service (e.g., for updated versions of a service) 604 o IANA strives to encourage the deployment of secure protocols, and 605 so strives to avoid separate assignments for non-secure variants 607 o IANA strives to assign only one assigned port number for all 608 different types of device using or participating in the same 609 service 611 o IANA strives to assign port numbers only for the transport 612 protocol(s) explicitly named in an assignment request 614 o IANA may recover unused port numbers, via the new procedures of 615 de-assignment, revocation, and transfer 617 Where possible, a given service is expected to demultiplex messages 618 if necessary. For example, applications and protocols are expected 619 to include in-band version information, so that future versions of 620 the application or protocol can share the same assigned port. 621 Applications and protocols are also expected to be able to 622 efficiently use a single assigned port for multiple sessions, either 623 by demultiplexing multiple streams within one port, or using the 624 assigned port to coordinate using dynamic ports for subsequent 625 exchanges (e.g., in the spirit of FTP [RFC0959]). 627 Ports are used in various ways, notably: 629 o as endpoint process identifiers 631 o as application protocol identifiers 633 o for firewall filtering purposes 635 Both the process identifier and the protocol identifier uses suggest 636 that anything a single process can demultiplex, or that can be 637 encoded into a single protocol, should be. The firewall filtering 638 use suggests that some uses that could be multiplexed or encoded 639 could instead be separated to allow for easier firewall management. 640 Note that this latter use is much less sound, because port numbers 641 have meaning only for the two endpoints involved in a connection, and 642 drawing conclusions about the service that generated a given flow 643 based on observed port numbers is not always reliable. Further, the 644 previous practice of separating protocol variants based on security 645 capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is 646 not recommended for new protocols, because all new protocols should 647 be security-capable. 649 IANA will begin assigning port numbers for only those transport 650 protocols explicitly included in an assignment request. This ends 651 the long-standing practice of automatically assigning a port number 652 to an application for both TCP and a UDP, even if the request is for 653 only one of these transport protocols. The new assignment procedure 654 conserves resources by assigning a port number to an application for 655 only those transport protocols (TCP, UDP, SCTP and/or DCCP) it 656 actually uses. The port number will be marked as Reserved - instead 657 of Assigned - in the port number registries of the other transport 658 protocols. When applications start supporting the use of some of 659 those additional transport protocols, the Assignee for the assignment 660 MUST request IANA convert these reserved ports into assignments. An 661 application MUST NOT assume that it can use a port number assigned to 662 it for use with one transport protocol with another transport 663 protocol without asking IANA to convert the reserved ports into an 664 assignment. 666 When the available pool of unassigned numbers has run out in a ports 667 range, it will be necessary for IANA to consider the Reserved ports 668 for assignment. This is part of the motivation for not automatically 669 assigning ports for transport protocols other than the requested 670 one(s). This will allow more ports to be available for assignment 671 when that time comes. To help conserve ports, application developers 672 should request assignment of only the transport protocols that their 673 application currently uses. 675 Conservation of port numbers is improved by procedures that allow 676 previously allocated port numbers to become Unassigned, either 677 through de-assignment or through revocation, and by a procedure that 678 lets application designers transfer an assigned but unused port 679 number to a new application. Section 8 describes these procedures, 680 which until now were undocumented. Port number conservation is also 681 improved by recommending that applications that do not require an 682 assigned port should register only a service name without an 683 associated port number. 685 8. IANA Procedures for Managing the Service Name and Transport Protocol 686 Port Number Registry 688 This section describes the process for handling requests associated 689 with IANA's management of the Service Name and Transport Protocol 690 Port Number Registry. Such requests include initial assignment, de- 691 assignment, reuse, changes to the service name, and updates to the 692 contact information or description associated with an assignment. 693 Revocation is as additional process, initiated by IANA. 695 8.1. Service Name and Port Number Assignment 697 Assignment refers to the process of providing service names or port 698 numbers to applicants. All such assignments are made from service 699 names or port numbers that are Unassigned or Reserved at the time of 700 the assignment. Unassigned names and numbers are allocated according 701 to the rules described in Section 8.1.1 below. Except as described 702 below, Reserved numbers and names are assigned only by a Standards 703 Action or an IESG Approval, and MUST accompanied by a statement 704 explaining the reason a Reserved number or name is appropriate for 705 this action. 707 When an assignment for one or more transport protocols is approved, 708 the port number for any non-requested transport protocol(s) will be 709 marked as Reserved. IANA SHOULD NOT assign that port number to any 710 other application or service until no other port numbers remain 711 Unassigned in the requested range. The current Assignee for a port 712 number MAY request assignment of these Reserved port numbers for 713 other transport protocols when needed. 715 A service name or port number assignment request contains the 716 following information. The service name is the unique identifier of 717 a given service: 719 Service Name (REQUIRED) 720 Transport Protocol(s) (REQUIRED) 721 Assignee (REQUIRED) 722 Contact (REQUIRED) 723 Description (REQUIRED) 724 Reference (REQUIRED) 725 Port Number (OPTIONAL) 726 Service Code (REQUIRED for DCCP only) 727 Known Unauthorized Uses (OPTIONAL) 728 Assignment Notes (OPTIONAL) 730 o Service Name: A desired unique service name for the service 731 associated with the assignment request MUST be provided, for use 732 in various service selection and discovery mechanisms (including, 733 but not limited to, DNS SRV records [RFC2782]). The name MUST be 734 compliant with the syntax defined in Section 5.1. In order to be 735 unique, they MUST NOT be identical to any currently assigned 736 service name in the IANA registry [PORTREG]. Service names are 737 case-insensitive; they may be provided and entered into the 738 registry with mixed case for clarity, but for the comparison 739 purposes the case is ignored. 741 o Transport Protocol(s): The transport protocol(s) for which an 742 assignment is requested MUST be provided. This field is currently 743 limited to one or more of TCP, UDP, SCTP, and DCCP. Requests 744 without any port assignment and only a service name are still 745 required to indicate which protocol the service uses. 747 o Assignee: Name and email address of the party to whom the 748 assignment is made. This is REQUIRED. The Assignee is the 749 Organization or Company responsible for the initial assignment. 750 For assignments done through IETF-published RFCs, the Assignee 751 will be the IETF, with the IESG as the point of 752 contact. 754 o Contact: Name and email address of the Contact person for the 755 assignment. This is REQUIRED. The Contact person is the 756 responsible person for the Internet community to send questions 757 to. This person is also authorized to submit changes on behalf of 758 the Assignee; in cases of conflict between the Assignee and the 759 Contact, the Assignee decisions take precedence. Additional 760 address information MAY be provided. For assignments done through 761 IETF-published RFCs, the Contact will be the IESG. 763 o Description: A short description of the service associated with 764 the assignment request is REQUIRED. It should avoid all but the 765 most well-known acronyms. 767 o Reference: A description of (or a reference to a document 768 describing) the protocol or application using this port. The 769 description must state whether the protocol uses broadcast, 770 multicast, or anycast communication. 772 For assignments requesting only a Service Name, or a Service Name 773 and User Port, a statement that the protocol is proprietary and 774 not publicly documented is also acceptable provided that the 775 required information regarding use of broadcast, multicast, or 776 anycast is given. 778 For assignment requests for a User Port, the assignment request 779 MUST explain why a port number in the Dynamic Ports range is 780 unsuitable for the given application. 782 For assignment requests for a System Port, the assignment request 783 MUST explain why a port number in the User Ports or Dynamic Ports 784 ranges is unsuitable, and a reference to a stable protocol 785 specification document MUST be provided. For requests from IETF 786 Working Groups, IANA MAY accept early assignment [RFC4020] 787 requests (known as "early allocation" therein) referencing a 788 sufficiently stable Internet Draft instead of a published 789 Standards-Track RFC. 791 o Port Number: If assignment of a port number is desired, either the 792 port number the requester suggests for assignment or indication of 793 port range (user or system) MUST be provided. If only a service 794 name is to be assigned, this field is left empty. If a specific 795 port number is requested, IANA is encouraged to assign the 796 requested number. If a range is specified, IANA will choose a 797 suitable number from the User or System Ports ranges. Note that 798 the applicant MUST NOT use the requested port prior to the 799 completion of the assignment. 801 o Service Code: If the assignment request includes DCCP as a 802 transport protocol then the request MUST include a desired unique 803 DCCP service code [RFC5595], and MUST NOT include a requested DCCP 804 service code otherwise. Section 19.8 of the DCCP specification 805 [RFC4340] defines requirements and rules for assignment, updated 806 by this document. 808 o Known Unauthorized Uses: A list of uses by applications or 809 organizations who are not the Assignee. This list may be 810 augmented by IANA after assignment when unauthorized uses are 811 reported. 813 o Assignment Notes: Indications of owner/name change, or any other 814 assignment process issue. This list may be updated by IANA after 815 assignment to help track changes to an assignment, e.g., de- 816 assignment, owner/name changes, etc. 818 If the assignment request is for the addition of a new transport 819 protocol to an already-assigned service name and the requester is not 820 the Assignee or Contact for the already-assigned service name, IANA 821 needs to confirm with the Assignee for the existing assignment 822 whether this addition is appropriate. 824 If the assignment request is for a new service name sharing the same 825 port as an already-assigned service name (see port number overloading 826 in Section 5), IANA needs to confirm with the Assignee for the 827 existing service name and other appropriate experts whether the 828 overloading is appropriate. 830 When IANA receives an assignment request - containing the above 831 information - that is requesting a port number, IANA SHALL initiate 832 an "Expert Review" [RFC5226] in order to determine whether an 833 assignment should be made. For requests that are not seeking a port 834 number, IANA SHOULD assign the service name under a simple "First 835 Come First Served" policy [RFC5226]. 837 8.1.1. Variances for Specific Port Number Ranges 839 Section 6 describes the different port number ranges. It is 840 important to note that IANA applies slightly different procedures 841 when managing the different port ranges of the service name and port 842 number registry: 844 o Ports in the Dynamic Ports range (49152-65535) have been 845 specifically set aside for local and dynamic use and cannot be 846 assigned through IANA. Application software may simply use any 847 dynamic port that is available on the local host, without any sort 848 of assignment. On the other hand, application software MUST NOT 849 assume that a specific port number in the Dynamic Ports range will 850 always be available for communication at all times, and a port 851 number in that range hence MUST NOT be used as a service 852 identifier. 854 o Ports in the User Ports range (1024-49151) are available for 855 assignment through IANA, and MAY be used as service identifiers 856 upon successful assignment. Because assigning a port number for a 857 specific application consumes a fraction of the shared resource 858 that is the port number registry, IANA will require the requester 859 to document the intended use of the port number. This 860 documentation will be input to the "Expert Review" procedure 861 [RFC5226], by which IANA will have a technical expert review the 862 request to determine whether to grant the assignment. The 863 submitted documentation MUST explain why using a port number in 864 the Dynamic Ports range is unsuitable for the given application. 865 Ports in the User Ports range may also be assigned under the "IETF 866 Review" or "IESG Approval" procedures [RFC5226], which is how most 867 assignments for IETF protocols are handled. 869 o Ports in the System Ports range (0-1023) are also available for 870 assignment through IANA. Because the System Ports range is both 871 the smallest and the most densely allocated, the requirements for 872 new assignments are more strict than those for the User Ports 873 range, and will only be granted under the "IETF Review" or "IESG 874 Approval" procedures [RFC5226]. A request for a System Port 875 number MUST document *both* why using a port number from the 876 Dynamic Ports range is unsuitable *and* why using a port number 877 from the User Ports range is unsuitable for that application. 879 8.2. Service Name and Port Number De-Assignment 881 The Assignee of a granted port number assignment can return the port 882 number to IANA at any time if they no longer have a need for it. The 883 port number will be de-assigned and will be marked as Reserved. IANA 884 should not re-assign port numbers that have been de-assigned until 885 all unassigned port numbers in the specific range have been assigned. 887 Before proceeding with a port number de-assignment, IANA needs to 888 reasonably establish that the value is actually no longer in use. 890 Because there is much less danger of exhausting the service name 891 space compared to the port number space, it is RECOMMENDED that a 892 given service name remain assigned even after all associated port 893 number assignments have become de-assigned. Under this policy, it 894 will appear in the registry as if it had been created through a 895 service name assignment request that did not include any port 896 numbers. 898 On rare occasions, it may still be useful to de-assign a service 899 name. In such cases, IANA will mark the service name as Reserved. 900 IANA will involve their IESG-appointed expert in such cases. 902 IANA will include a comment in the registry when de-assignment 903 happens to indicate its historic usage. 905 8.3. Service Name and Port Number Reuse 907 If the Assignee of a granted port number assignment no longer has a 908 need for the assigned number, but would like to reuse it for a 909 different application, they can submit a request to IANA to do so. 911 Logically, port number reuse is to be thought of as a de-assignment 912 (Section 8.2) followed by an immediate (re-)assignment (Section 8.1) 913 of the same port number for a new application. Consequently, the 914 information that needs to be provided about the proposed new use of 915 the port number is identical to what would need to be provided for a 916 new port number assignment for the specific ports range. 918 Because there is much less danger of exhausting the service name 919 space compared to the port number space, it is RECOMMENDED that the 920 original service name associated with the prior use of the port 921 number remains assigned, and a new service name be created and 922 associated with the port number. This is again consistent with 923 viewing a reuse request as a de-assignment followed by an immediate 924 (re-)assignment. Re-using an assigned service name for a different 925 application is NOT RECOMMENDED. 927 IANA needs to carefully review such requests before approving them. 928 In some instances, the Expert Reviewer will determine that the 929 application the port number was assigned to has found usage beyond 930 the original Assignee, or that there is a concern that it may have 931 such users. This determination MUST be made quickly. A community 932 call concerning revocation of a port number (see below) MAY be 933 considered, if a broader use of the port number is suspected. 935 8.4. Service Name and Port Number Revocation 937 A port number revocation can be thought of as an IANA-initiated de- 938 assignment (Section 8.2), and has exactly the same effect on the 939 registry. 941 Sometimes, it will be clear that a specific port number is no longer 942 in use and that IANA can revoke it and mark it as Reserved. At other 943 times, it may be unclear whether a given assigned port number is 944 still in use somewhere in the Internet. In those cases, IANA must 945 carefully consider the consequences of revoking the port number, and 946 SHOULD only do so if there is an overwhelming need. 948 With the help of their IESG-appointed Expert Reviewer, IANA SHALL 949 formulate a request to the IESG to issue a four-week community call 950 concerning the pending port number revocation. The IESG and IANA, 951 with the Expert Reviewer's support, SHALL determine promptly after 952 the end of the community call whether revocation should proceed and 953 then communicate their decision to the community. This procedure 954 typically involves similar steps to de-assignment except that it is 955 initiated by IANA. 957 Because there is much less danger of exhausting the service name 958 space compared to the port number space, revoking service names is 959 NOT RECOMMENDED. 961 8.5. Service Name and Port Number Transfers 963 The value of service names and port numbers is defined by their 964 careful management as a shared Internet resource, whereas enabling 965 transfer allows the potential for associated monetary exchanges. As 966 a result, the IETF does not permit service name or port number 967 assignments to be transferred between parties, even when they are 968 mutually consenting. 970 The appropriate alternate procedure is a coordinated de-assignment 971 and assignment: The new party requests the service name or port 972 number via an assignment and the previous party releases its 973 assignment via the de-assignment procedure outlined above. 975 With the help of their IESG-appointed Expert Reviewer, IANA SHALL 976 carefully determine if there is a valid technical, operational or 977 managerial reason to grant the requested new assignment. 979 8.6. Maintenance Issues 981 In addition to the formal procedures described above, updates to the 982 Description and Contact information are coordinated by IANA in an 983 informal manner, and may be initiated by either the Assignee or by 984 IANA, e.g., by the latter requesting an update to current Contact 985 information. (Note that the Assignee cannot be changed as a separate 986 procedure; see instead Section 8.5 above.) 988 8.7. Disagreements 990 In the case of disagreements around any request there is the 991 possibility of appeal following the normal appeals process for IANA 992 assignments as defined by Section 7 of "Guidelines for Writing an 993 IANA Considerations Section in RFCs" [RFC5226]. 995 9. Security Considerations 997 The IANA guidelines described in this document do not change the 998 security properties of UDP, TCP, SCTP, or DCCP. 1000 Assignment of a service name or port number does not in any way imply 1001 an endorsement of an application or product, and the fact that 1002 network traffic is flowing to or from an assigned port number does 1003 not mean that it is "good" traffic, or even that it is used by the 1004 assigned service. Firewall and system administrators should choose 1005 how to configure their systems based on their knowledge of the 1006 traffic in question, not based on whether or not there is an assigned 1007 service name or port number. 1009 Services are expected to include support for security, either as 1010 default or dynamically negotiated in-band. The use of separate 1011 service name or port number assignments for secure and insecure 1012 variants of the same service is to be avoided in order to discourage 1013 the deployment of insecure services. 1015 10. IANA Considerations 1017 This document obsoletes Sections 8 and 9.1 of the March 2000 IANA 1018 Allocation Guidelines [RFC2780]. 1020 Upon approval of this document, IANA is requested to contact Stuart 1021 Cheshire, maintainer of the independent service name registry 1022 [SRVREG], in order to merge the contents of that private registry 1023 into the official IANA registry. It is expected that the independent 1024 registry web page will be updated with pointers to the IANA registry 1025 and to this RFC. 1027 IANA is instructed to create a new service name entry in the service 1028 name and port number registry [PORTREG] for any entry in the 1029 "Protocol and Service Names" registry [PROTSERVREG] that does not 1030 already have one assigned. 1032 IANA is also instructed to indicate in the Assignment Notes for "www" 1033 and "www-http" that they are duplicate terms that refer to the "http" 1034 service, and should not be used for discovery purposes. For this 1035 conceptual service (human-readable web pages served over HTTP) the 1036 correct service name to use for service discovery purposes is "http" 1037 (see Section 5). 1039 10.1. Service Name Consistency 1041 Section 8.1 defines which character strings are well-formed service 1042 names, which until now had not been clearly defined. The definition 1043 in Section 8.1 was chosen to allow maximum compatibility of service 1044 names with current and future service discovery mechanisms. 1046 As of August 5, 2009 approximately 98% of the so-called "Short Names" 1047 from existing port number assignments [PORTREG] meet the rules for 1048 legal service names stated in Section 8.1, and hence for these 1049 services their service name will be exactly the same as their "Short 1050 Name". 1052 The remaining approximately 2% of the exiting "Short Names" are not 1053 suitable to be used directly as well-formed service names because 1054 they contain illegal characters such as asterisks, dots, pluses, 1055 slashes, or underscores. All existing "Short Names" conform to the 1056 length requirement of 15 characters or fewer. For these unsuitable 1057 "Short Names", listed in the table below, the service name will be 1058 the Short Name with any illegal characters replaced by hyphens. IANA 1059 SHALL add an entry to the registry giving the new well-formed primary 1060 service name for the existing service, that otherwise duplicates the 1061 original assignment information. In the description field of this 1062 new entry giving the primary service name, IANA SHALL record that it 1063 assigns a well-formed service name for the previous service and 1064 reference the original assignment. In the Assignment Notes field of 1065 the original assignment, IANA SHALL add a note that this entry is an 1066 alias to the new well-formed service name, and that the old service 1067 name is historic, not usable for use with many common service 1068 discovery mechanisms. 1070 Names containing illegal characters to be replaced by hyphens: 1072 +----------------+-----------------+-----------------+ 1073 | 914c/g | acmaint_dbd | acmaint_transd | 1074 | atex_elmd | avanti_cdp | badm_priv | 1075 | badm_pub | bdir_priv | bdir_pub | 1076 | bmc_ctd_ldap | bmc_patroldb | boks_clntd | 1077 | boks_servc | boks_servm | broker_service | 1078 | bues_service | canit_store | cedros_fds | 1079 | cl/1 | contamac_icm | corel_vncadmin | 1080 | csc_proxy | cvc_hostd | dbcontrol_agent | 1081 | dec_dlm | dl_agent | documentum_s | 1082 | dsmeter_iatc | dsx_monitor | elpro_tunnel | 1083 | elvin_client | elvin_server | encrypted_admin | 1084 | erunbook_agent | erunbook_server | esri_sde | 1085 | EtherNet/IP-1 | EtherNet/IP-2 | event_listener | 1086 | flr_agent | gds_db | ibm_wrless_lan | 1087 | iceedcp_rx | iceedcp_tx | iclcnet_svinfo | 1088 | idig_mux | ife_icorp | instl_bootc | 1089 | instl_boots | intel_rci | interhdl_elmd | 1090 | lan900_remote | LiebDevMgmt_A | LiebDevMgmt_C | 1091 | LiebDevMgmt_DM | mapper-ws_ethd | matrix_vnet | 1092 | mdbs_daemon | menandmice_noh | msl_lmd | 1093 | nburn_id | ncr_ccl | nds_sso | 1094 | netmap_lm | nms_topo_serv | notify_srvr | 1095 | novell-lu6.2 | nuts_bootp | nuts_dem | 1096 | ocs_amu | ocs_cmu | pipe_server | 1097 | pra_elmd | printer_agent | redstorm_diag | 1098 | redstorm_find | redstorm_info | redstorm_join | 1099 | resource_mgr | rmonitor_secure | rsvp_tunnel | 1100 | sai_sentlm | sge_execd | sge_qmaster | 1101 | shiva_confsrvr | sql*net | srvc_registry | 1102 | stm_pproc | subntbcst_tftp | udt_os | 1103 | universe_suite | veritas_pbx | vision_elmd | 1104 | vision_server | wrs_registry | z39.50 | 1105 +----------------+-----------------+-----------------+ 1107 Following the example set by the "application/whoispp-query" MIME 1108 Content-Type [RFC2957], the service name for "whois++" will be 1109 "whoispp". 1111 10.2. Port Numbers for SCTP and DCCP Experimentation 1113 Two System UDP and TCP ports, 1021 and 1022, have been reserved for 1114 experimental use [RFC4727]. This document assigns the same port 1115 numbers for SCTP and DCCP, updates the TCP and UDP assignments, and 1116 also instructs IANA to automatically assign these two port numbers 1117 for any future transport protocol with a similar 16-bit port number 1118 namespace. 1120 Note that these port numbers are meant for temporary experimentation 1121 and development in controlled environments. Before using these port 1122 numbers, carefully consider the advice in Section 6.1 in this 1123 document, as well as in Sections 1 and 1.1 of "Assigning Experimental 1124 and Testing Numbers Considered Useful" [RFC3692]. Most importantly, 1125 application developers must request a permanent port number 1126 assignment from IANA as described in Section 8.1 before any kind of 1127 non-experimental deployment. 1129 +--------------------+----------------------------+ 1130 | Service Name | exp1 | 1131 | Transport Protocol | DCCP, SCTP, TCP, UDP | 1132 | Assignee | IETF | 1133 | Contact | IESG | 1134 | Description | RFC3692-style Experiment 1 | 1135 | Reference | [RFC4727] [RFCyyyy] | 1136 | Port Number | 1021 | 1137 +--------------------+----------------------------+ 1139 +--------------------+----------------------------+ 1140 | Service Name | exp2 | 1141 | Transport Protocol | DCCP, SCTP, TCP, UDP | 1142 | Assignee | IETF | 1143 | Contact | IESG | 1144 | Description | RFC3692-style Experiment 2 | 1145 | Reference | [RFC4727] [RFCyyyy] | 1146 | Port Number | 1022 | 1147 +--------------------+----------------------------+ 1149 [RFC Editor Note: Please change "yyyy" to the RFC number allocated to 1150 this document before publication.] 1152 10.3. Updates to DCCP Registries 1154 This document updates the IANA assignment procedures for the DCCP 1155 Port Number and DCCP Service Codes Registries [RFC4340]. 1157 10.3.1. DCCP Service Code Registry 1159 Service Codes are assigned first-come-first-served according to 1160 Section 19.8 of the DCCP specification [RFC4340]. This document 1161 updates that section by extending the guidelines given there in the 1162 following ways: 1164 o IANA MAY assign new Service Codes without seeking Expert Review 1165 using their discretion, but SHOULD seek expert review if a request 1166 asks for more than five Service Codes. 1168 o IANA should feel free to contact the DCCP Expert Reviewer with 1169 questions on any registry, regardless of the registry policy, for 1170 clarification or if there is a problem with a request [RFC4340]. 1172 10.3.2. DCCP Port Numbers Registry 1174 The DCCP ports registry is defined by Section 19.9 of the DCCP 1175 specification [RFC4340]. Assignments in this registry require prior 1176 assignment of a Service Code. Not all Service Codes require IANA- 1177 assigned ports. This document updates that section by extending the 1178 guidelines given there in the following way: 1180 o IANA should normally assign a value in the range 1024-49151 to a 1181 DCCP server port. IANA requests to assign port numbers in the 1182 System Ports range (0 through 1023), require an "IETF Review" 1183 [RFC5226] prior to assignment by IANA [RFC4340]. 1185 o IANA MUST NOT assign more than one DCCP server port to a single 1186 service code value. 1188 o The assignment of multiple service codes to the same DCCP port is 1189 allowed, but subject to expert review. 1191 o The set of Service Code values associated with a DCCP server port 1192 should be recorded in the service name and port number registry. 1194 o A request for additional Service Codes to be associated with an 1195 already-allocated Port Number requires Expert Review. These 1196 requests will normally be accepted when they originate from the 1197 contact associated with the port assignment. In other cases, 1198 these applications will be expected to use an unallocated port, 1199 when this is available. 1201 The DCCP specification [RFC4340] notes that a short port name MUST be 1202 associated with each DCCP server port that has been assigned. This 1203 document clarifies that this short port name is the Service Name as 1204 defined here, and this name MUST be unique. 1206 11. Contributors 1208 Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have 1209 contributed text and ideas to this document. 1211 12. Acknowledgments 1213 The text in Section 10.3 is based on a suggestion originally proposed 1214 as a part of the DCCP Service Codes document [RFC5595] by Gorry 1215 Fairhurst. 1217 Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a 1218 research project supported by the European Commission under its 1219 Seventh Framework Program. 1221 13. References 1223 13.1. Normative References 1225 [ANSI.X3-4.1986] 1226 American National Standards Institute, "Coded Character 1227 Set - 7-bit American Standard Code for Information 1228 Interchange", ANSI X3.4, 1986. 1230 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1231 August 1980. 1233 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1234 RFC 793, September 1981. 1236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1237 Requirement Levels", BCP 14, RFC 2119, March 1997. 1239 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1240 Values In the Internet Protocol and Related Headers", 1241 BCP 37, RFC 2780, March 2000. 1243 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1244 G. Fairhurst, "The Lightweight User Datagram Protocol 1245 (UDP-Lite)", RFC 3828, July 2004. 1247 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 1248 Standards Track Code Points", BCP 100, RFC 4020, 1249 February 2005. 1251 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1252 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1254 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1255 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1257 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1258 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1259 May 2008. 1261 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1262 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1264 13.2. Informative References 1266 [I-D.cheshire-dnsext-dns-sd] 1267 Cheshire, S. and M. Krochmal, "DNS-Based Service 1268 Discovery", draft-cheshire-dnsext-dns-sd-07 (work in 1269 progress), October 2010. 1271 [I-D.cheshire-nat-pmp] 1272 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1273 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 1275 [IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0", 1276 November 2001. 1278 [PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name 1279 and Transport Protocol Port Number Registry", 1280 http://www.iana.org/assignments/port-numbers. 1282 [PROTSERVREG] 1283 Internet Assigned Numbers Authority (IANA), "Protocol and 1284 Service Names Registry", 1285 http://www.iana.org/assignments/service-names. 1287 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 1288 STD 9, RFC 959, October 1985. 1290 [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", 1291 RFC 1078, November 1988. 1293 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1294 October 1994. 1296 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1297 specifying the location of services (DNS SRV)", RFC 2782, 1298 February 2000. 1300 [RFC2957] Daigle, L. and P. Faltstrom, "The application/ 1301 whoispp-query Content-Type", RFC 2957, October 2000. 1303 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1304 an On-line Database", RFC 3232, January 2002. 1306 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1307 Considered Useful", BCP 82, RFC 3692, January 2004. 1309 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 1310 Datagram Congestion Control Protocol (DCCP) Congestion 1311 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 1312 March 2006. 1314 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1315 RFC 4960, September 2007. 1317 [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for 1318 the Protocol Field", BCP 37, RFC 5237, February 2008. 1320 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1321 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1322 October 2008. 1324 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 1325 (DCCP) Service Codes", RFC 5595, September 2009. 1327 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1328 Relays around NAT (TURN): Relay Extensions to Session 1329 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1331 [SRVREG] "DNS SRV Service Types Registry", 1332 http://www.dns-sd.org/ServiceTypes.html. 1334 [SYSFORM] Internet Assigned Numbers Authority (IANA), "Application 1335 for System (Well Known) Port Number", 1336 http://www.iana.org/. 1338 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 1340 [USRFORM] Internet Assigned Numbers Authority (IANA), "Application 1341 for User (Registered) Port Number", http://www.iana.org/. 1343 Authors' Addresses 1345 Michelle Cotton 1346 Internet Corporation for Assigned Names and Numbers 1347 4676 Admiralty Way, Suite 330 1348 Marina del Rey, CA 90292 1349 USA 1351 Phone: +1 310 823 9358 1352 Email: michelle.cotton@icann.org 1353 URI: http://www.iana.org/ 1355 Lars Eggert 1356 Nokia Research Center 1357 P.O. Box 407 1358 Nokia Group 00045 1359 Finland 1361 Phone: +358 50 48 24461 1362 Email: lars.eggert@nokia.com 1363 URI: http://research.nokia.com/people/lars_eggert/ 1365 Joe Touch 1366 USC/ISI 1367 4676 Admiralty Way 1368 Marina del Rey, CA 90292 1369 USA 1371 Phone: +1 310 448 9151 1372 Email: touch@isi.edu 1373 URI: http://www.isi.edu/touch 1375 Magnus Westerlund 1376 Ericsson 1377 Farogatan 6 1378 Stockholm 164 80 1379 Sweden 1381 Phone: +46 8 719 0000 1382 Email: magnus.westerlund@ericsson.com 1383 Stuart Cheshire 1384 Apple Inc. 1385 1 Infinite Loop 1386 Cupertino, CA 95014 1387 USA 1389 Phone: +1 408 974 3207 1390 Email: cheshire@apple.com