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