idnits 2.17.1 draft-ietf-tsvwg-port-use-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2013) is 3819 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) -- Obsolete informational reference (is this intentional?): RFC 61 (Obsoleted by RFC 62) -- Obsolete informational reference (is this intentional?): RFC 739 (Obsoleted by RFC 750) -- Obsolete informational reference (is this intentional?): RFC 758 (Obsoleted by RFC 762) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 820 (Obsoleted by RFC 870) -- Obsolete informational reference (is this intentional?): RFC 900 (Obsoleted by RFC 923) -- Obsolete informational reference (is this intentional?): RFC 1340 (Obsoleted by RFC 1700) -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TSVWG J. Touch 2 Internet Draft USC/ISI 3 Intended status: Best Current Practice November 4, 2013 4 Expires: May 2014 6 Recommendations for Transport Port Uses 7 draft-ietf-tsvwg-port-use-03.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on May 4, 2014. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 This document provides recommendations to application and service 50 designers on how to use the transport protocol port number space to 51 help in its preservation. 53 Table of Contents 55 1. Introduction...................................................2 56 2. Conventions used in this document..............................3 57 3. History........................................................3 58 4. Current Port Use...............................................4 59 5. What is a Port?................................................5 60 6. Conservation...................................................6 61 6.1. Firewall and NAT Considerations...........................7 62 7. How to Use Assigned Ports......................................8 63 7.1. Do You Need a Port?.......................................8 64 7.2. How Many Ports?..........................................10 65 7.3. Picking a Port Number....................................10 66 7.4. Support for Security.....................................11 67 7.5. Support for Future Versions..............................12 68 7.6. Transport Protocols......................................12 69 7.7. When to Request an Assignment............................14 70 7.8. Squatting................................................15 71 7.9. Other Considerations.....................................15 72 8. Security Considerations.......................................15 73 9. IANA Considerations...........................................16 74 10. References...................................................16 75 10.1. Normative References....................................16 76 10.2. Informative References..................................16 77 11. Acknowledgments..............................................18 79 1. Introduction 81 This document provides information and advice to system designers on 82 the use of transport port numbers and services. It provides a 83 detailed historical background of the evolution of transport port 84 numbers and their multiple meanings. It also provides specific 85 recommendations on how to use assigned ports. 87 2. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC-2119 [RFC2119]. 93 In this document, these words will appear with that interpretation 94 only when in ALL CAPS. Lower case uses of these words are not to be 95 interpreted as carrying RFC-2119 significance. 97 In this document, the characters ">>" preceding an indented line(s) 98 indicates a compliance requirement statement using the key words 99 listed above. This convention aids reviewers in quickly identifying 100 or finding the explicit compliance requirements of this RFC. 102 3. History 104 The term 'port' was first used in RFC33 to describe a simplex 105 communication path from a process [RFC33]. At a meeting described in 106 [RFC37], an idea was presented to decouple connections between 107 processes and links that they use as paths, and thus to include 108 source and destination socket identifiers in packets. RFC38 explains 109 this in detail, in which processes might have more than one of these 110 paths, and that more than one may be active at a time [RFC38]. As a 111 result, there was the need to add a process identifier to the header 112 of each message, so that the incoming data could be demultiplexed to 113 the appropriate process. RFC38 further suggested that 32 bits would 114 be used for these identifiers. RFC48 discusses the current notion of 115 listening on a given port, but does not discuss the issue of port 116 determination [RFC48]. RFC61 notes that the challenge of knowing the 117 appropriate port numbers is "left to the processes" in general, but 118 introduces the concept of a "well-known" port for common services 119 [RFC61]. 121 RFC76 addresses this issue more constructively, proposing a 122 "telephone book" by which an index would allow ports to be used by 123 name, but still assumes that both source and destination ports are 124 fixed by such a system [RFC76]. RFC333 suggests that the port pair, 125 rather than an individual port, would be used on both sides of the 126 connection for demultiplexing messages [RFC333]. This is the final 127 view in RFC793 (and its predecessors, including IEN 112 [IEN112]), 128 and brings us to their current meaning. RFC739 introduces the notion 129 of generic reserved ports, used for groups of protocols, such as 130 "any private RJE server" [RFC739]. Although the overall range of 131 such ports was (and remains) 16 bits, only the first 256 (high 8 132 bits cleared) in the range were considered assigned. 134 RFC758 is the first to describe a list of such well-known ports, as 135 well as describing ranges used for different purposes [RFC758]: 137 Binary Octal 139 ----------------------------------------------------------- 141 0-63 0-77 Network Wide Standard Function 143 64-127 100-177 Hosts Specific Functions 145 128-223 200-337 Reserved for Future Use 147 224-255 340-377 Any Experimental Function 149 In RFC820, those range meanings disappeared, and a single list of 150 assignments is presented [RFC820]. By RFC900, they appeared as 151 decimal numbers rather than the octal ranges used previously 152 [RFC900]. RFC1340 increased this range from 0..255 to 0..1023, and 153 began to list TCP and UDP port assignments individually (although 154 the assumption was, and remains, that once assigned a port applies 155 to all transport protocols, including TCP, UDP, recently SCTP and 156 DCCP, as well as ISO-TP4 for a brief period in the early 1990s) 157 [RFC1340]. RFC1340 also established the Registered space of 1024- 158 59151, though it notes that it is not controlled by the IANA at that 159 point. The list provided by RFC1700 in 1994 remained the standard 160 until it was declared replaced by an on-line version, as of RFC3232 161 in 2002 [RFC1700] [RFC3232]. 163 4. Current Port Use 165 The current IANA website (www.iana.org) indicates three ranges of 166 port assignments: 168 Binary Hex 170 ----------------------------------------------------------- 172 0-1023 0x03FF Well-Known (a.k.a. 'system') 174 1024-49151 0x0400-0xBFFF Registered (a.k.a. 'user') 176 49152-65535 0xC000-0xFFFF Dynamic/Private 178 Well-known encompasses the range 0..1023. On some systems, use of 179 these ports requires privileged access, e.g., that the process run 180 as 'root', which is why these are referred to as 'system' ports. The 181 ports from 1024..49151 denotes non-privileged services, known as 182 'registered'; because these ports do not run with special 183 privileges, they are often referred to as 'user' ports. Dynamic or 184 Private ports are not assigned through IANA. 186 Both Well-Known and Registered ports are assigned through IANA, so 187 both are sometimes called "registered ports". As a result, the term 188 'registered' is ambiguous, referring either to the entire range 0- 189 49151 or to the user ports. Complicating matters further, 'system' 190 ports do not always require special (i.e., 'root') privilege. 191 Regardless, for clarity, throughout the remainder of this document 192 we will refer to the port ranges as 'system', 'user', and 'private'. 194 5. What is a Port? 196 A port is a 16-bit number used for two distinct purposes: 198 o Demultiplexing transport connections within an end host 200 o Identifying a service 202 The first reason requires that each transport connection between a 203 given pair of IP addresses use a different pair of ports, but does 204 not require either coordination or registration of port use. It is 205 the second reason that drives the need for a common registry. 207 Consider a user wanting to run a web server. That service could run 208 on any port, provided that all clients knew what port to use to 209 access that service at that host. Such information can be 210 distributed out of band, e.g., in the URL, such as: 212 http://www.example.com:51509/ 214 Ultimately, it's important to keep in mind that the correlation of a 215 service with a port number is an agreement between the two endpoints 216 of the connection only. The rest of the world might think that 217 you're sending DNS packets on port 53, but you can run a web server 218 on that port just fine, provided the server and client both decide 219 that port 53 is for HTTP web server traffic. 221 Which brings us to the concept of a service. A service is the 222 combination of ISO Layers 5-7 that represent an application protocol 223 capability. For example www (port 80) is a service that uses HTTP as 224 an application protocol, and provides a common web server [RFC2616]. 225 However, it is possible to use HTTP for other purposes, such as 226 command and control. This is why some current service names (HTTP, 227 e.g.) are a bit overloaded - they describe not only the application 228 protocol, but a particular service. 230 IANA assigns ports so that endpoints on the Internet do not need to 231 pairwise, explicitly coordinate the meaning of their port numbers. 232 This is the primary reason for requesting assigned ports with IANA - 233 to have a common agreement between all endpoints on the Internet as 234 to the meaning of a port. 236 Ports are sometimes used by intermediate devices on a network path, 237 either to monitor available services, to monitor traffic (e.g., to 238 indicate the data contents), or to intercept traffic (to block, 239 proxy, relay, aggregate, or otherwise process it). In each case, the 240 intermediate device interprets traffic based on the port number. It 241 is again important to recognize that any interpretation of ports 242 except at the endpoints may be incorrect, because ports are 243 meaningful only at the endpoints. Further, the ports may not be 244 visible to these intermediate devices, such as when the transport 245 protocol is encrypted (as in network- or link-layer tunnels), or 246 when a packet is fragmented (in which only the first fragment has 247 the port information). Such port invisibility may interfere with 248 these in-network port-based capabilities. 250 Ports are used for other purposes as well. The other primary reason 251 for requesting assigned ports with IANA is to simplify end system 252 configuration, so individual installations do not need to coordinate 253 their use of arbitrary ports. A similar reason is to simplify 254 firewall management, so that a single, fixed firewall configuration 255 can either permit or deny a service. 257 6. Conservation 259 Ports are a scarce resource that is globally shared by the entire 260 Internet community. As a result, every attempt should be made to 261 conserve ports and request only those that are absolutely necessary. 263 There are a variety of ways that systems can conserve port numbers: 265 o A single assigned port number can provide access to different 266 capabilities over different connections (or equivalent, e.g., 267 for UDP [RFC768]), using in-band information. 269 o A single assigned port can indicate the dynamic port(s) on 270 which different capabilities are supported, as is done for 271 FTP. 273 o An existing service can indicate the dynamic port(s) on which 274 services are supported, such as with mDNS and portmapper 275 [RFC6762] [RFC6763]. 277 o Copies of an existing service can be differentiated by using 278 different IP addresses (even on the same host). 280 o Copies of some existing services can be differentiated using 281 in-band information (e.g., HTTP). 283 o Different performance requirements or capabilities can already 284 be supported using different connections or endpoint 285 associations. 287 The key observation is that port numbers are intended to 288 differentiate services, not performance, replicas, connections, or 289 payload types. Port numbers are a very small space, so it is never 290 appropriate to consume port numbers to save larger spaces, such as 291 IP addresses. 293 Others have noted "think twice about modifying TCP, then don't" 294 [RFC1263]. In this case, similar advice might be: 296 o Think twice before asking for a port, then try not to. 298 o If you need more than one port assignment, revise your 299 architecture until you can get by with only one, or, 300 preferably, none. 302 6.1. Firewall and NAT Considerations 304 Assigned numbers are useful for configuring firewalls and other 305 port-based systems for access control. Ultimately, these ports 306 indicate services only to the endpoints, and any intermediate device 307 that assigns meaning to a value can be incorrect. End systems might 308 agree to run web services (HTTP) over port 53 (typically used for 309 DNS) rather than port 80, at which point a firewall that blocks port 310 80 would have no effect. However, assigned values often are 311 important in helping configure firewalls to known values. 313 Using dynamic ports, or dynamically-indicated ports over known ports 314 (such as with FTP) often complicates firewall and NAT interactions. 315 FTP over firewalls often requires direct support for deep-packet 316 inspection (to snoop for the dynamic port to open) and "passive 317 mode" FTP, in which both FTP connections are opened from the client 318 to the server (useful for NAT traversal). 320 7. How to Use Assigned Ports 322 Ports are assigned by IANA by a set of documented procedures [RFC 323 6335]. The following section describes the steps users can take to 324 help assist with the use of assigned ports, and with preparing an 325 application for a port. 327 7.1. Do You Need a Port? 329 First, ask whether you really need a port assignment. In many cases, 330 a new assignment may not be needed, for example: 332 o Is this really a new service, or can you use an existing 333 service? 335 o Is this an experimental service [RFC3692]? If so, consider 336 using the current experimental ports [RFC2780]. 338 o Is this service independently useful? If not, then the entire 339 group should share a port. Different service uses or 340 properties can be provided in separate connections after an 341 initial negotiation. 343 o Can this service use a dynamic port that is coordinated out- 344 of-band, e.g.: 346 o By explicit configuration of both endpoints. 348 o By shared information within the same host (e.g., a 349 configuration file). 351 o Using an existing port discovery service: portmapper, mDNS, 352 etc. [RFC6762] [RFC6763]. 354 There are a few good examples of reasons that more directly suggest 355 that not only is a port not necessary, but it is directly 356 counterindicated: 358 o Ports are not for performance. Performance enhancement can 359 occur within separate connections. 361 o Additional ports are not to replicate an existing service. For 362 example, if you have a device that is configured using a web 363 browser, that is a copy of HTTP port 80, and does not warrant 364 a new assignment. However, if you develop an automated system 365 that happens to use HTTP framing, that could be a new service. 366 A good way to tell is "can an unmodified client of the 367 existing service interact with your service"? If so, that 368 would be a copy, and should not request a new assignment. 370 o Separate ports are not for insecure versions of existing (or 371 new) secure services. Consider that a service that includes 372 required security would be made vulnerable by having the same 373 capability accessible without security. 375 Note that the converse is different, i.e., it can be useful to 376 create a new, secure service that replicates an existing 377 insecure service on a new port assignment. This can be 378 necessary when the existing service is not backward-compatible 379 with security enhancements, such as the use of TLS or SSL 380 [Hi95] [RFC5246]. 382 New services should support security or should consider 383 optional security. A new service should not need a port for an 384 insecure version; at best, this would be a performance issue 385 (see the first bullet), and at worst this presents a new 386 vulnerability. 388 o Ports are not for versioning. Versioning should be handled in- 389 band. This may not be possible with legacy assignments, but 390 all new assignments should incorporate versioning support. 392 Some users may not need assigned port numbers at all. Some systems 393 can register services in the DNS, using SRV entries. These services 394 can be discovered by a variety of means, including mDNS, or via 395 direct query. In such cases, users can more easily request a SRV 396 name, which are assigned first-come, first-served from a much larger 397 namespace. 399 IANA assigns port numbers, but this assignment is typically used 400 only for servers, i.e., the host that listens for incoming 401 connections. Clients, i.e., hosts that initiate connections, 402 typically refer to those assigned ports but do not need port 403 assignments for their endpoint. 405 7.2. How Many Ports? 407 As noted earlier, systems might require a single port assignment, 408 but rarely require multiple ports. There are a variety of known ways 409 to reduce port use. Although some may be cumbersome or inefficient, 410 they are always preferable to consuming additional ports. 412 Such techniques include: 414 o Use of a discovery service, either a shared service (mDNS), or 415 a discovery service for a given system. 417 o Multiplex packet types using in-band information, either on a 418 per-message or per-connection basis. Such demultiplexing can 419 even hand-off connections among different processes. 421 There are some cases where it is still important to have assigned 422 port numbers, largely to traverse either NATs or firewalls. Although 423 automatic configuration protocols have been proposed and developed, 424 system designers cannot yet rely on their presence. 426 In the past, some services were assigned multiple ports, or even 427 fairly large port ranges (e.g., X11). This occurred for a variety of 428 reasons - port conservation was not widely understood, assignments 429 were not as ardently reviewed, etc. This no longer reflects current 430 practice, and such assignments are not considered to constitute a 431 precedent for future assignments. 433 7.3. Picking a Port Number 435 Given a demonstrated need for a port number assignment, the next 436 question is how to pick the desired port number. An application for 437 a port assignment does not need to include a desired port number; in 438 that case, IANA will select from those currently available. 440 Users should consider whether the requested port number is 441 important. For example, would you accept an assignment if IANA 442 picked the value? Would you want a TCP port number assignment if the 443 corresponding UDP one were unavailable (assuming your service needed 444 only a TCP port) [RFC793]? 446 The most critical issue in picking a number is selecting the desired 447 range, i.e.., system vs. user ports. The distinction was intended to 448 indicate a difference in privilege; system ports required privileged 449 ('root') access, while user ports did not. That distinction has 450 blurred because some current systems do not limit access control to 451 system ports, and because some system services have been replicated 452 on user numbers (e.g., IRC). Even so, system port assignments have 453 continued at an average rate of 3-4 per year over the past 6 years 454 (2007-2012), indicating that the desire to keep this distinction 455 continues. 457 As a result, we recommend that the difference between user and 458 system ports be treated with caution. Developers are advised to 459 treat services as if they are always run without privilege. As a 460 result: 462 >> Developers SHOULD NOT apply for system ports because the 463 increased privilege they provide is not always enforced. 465 Even when developers seek a system port, it may be very difficult to 466 obtain. System port assignment requires IETF Review or IESG Approval 467 and justification that both user and dynamic port ranges are 468 insufficient [RFC6335]. 470 >> System implementers SHOULD enforce the need for privilege for 471 processes to listen on system ports. 473 At some future date, it might be useful to deprecate the distinction 474 between system and user ports altogether. Services typically require 475 elevated ('root') privileges to bind to a system port, but many such 476 services go to great lengths to immediately drop those privileges to 477 reduce the impact of an attack using their capabilities. As a result 478 it can be more secure to run such services on user ports than on 479 system ports. Further, avoiding system ports would potentially waste 480 only approximately 180 of the 1024 system values (17%), or 180 of 481 the overall 49152 assigned values (<0.04%). 483 7.4. Support for Security 485 Services represent a potential system vulnerability. Given the 486 current state of cybersecurity in the Internet, we recommend that: 488 >> New services SHOULD support security, either directly or via a 489 secure transport such as TLS [RFC5246]. 491 >> Insecure versions of new secure services SHOULD be avoided 492 because of the vulnerability they create. 494 >> Security SHOULD NOT rely on port number distinctions alone; every 495 service, whether secure or not, SHOULD expect to be attacked. 497 There is debate as to how to secure legacy insecure services 498 [RFC6335]. Some argue that secure variants should share the existing 499 port assignment, such that security is enabled on a per-connection 500 basis [RFC2817]. Others argue that security should be supported on a 501 new port assignment and be enabled by default. IANA currently 502 permits either approach. 504 Optional security can penalize performance, requiring additional 505 round-trip exchanges before a connection can be established. As we 506 discussed earlier, ports are a critical resource and it is 507 inappropriate to consume assignments to increase performance. 509 Note however that a new service might not be eligible for IANA 510 assignment of both an insecure and a secure variant of the same 511 service, and similarly IANA might be skeptical of an assignment for 512 an insecure port for a secure service. In both cases, security of 513 the service is compromised by adding the insecure port assignment. 515 7.5. Support for Future Versions 517 Current IANA assignments are expected to support versioning 518 [RFC6335]. Versions are typically indicated in-band, either at the 519 beginning of a connection or association, or in each protocol 520 message. 522 >> Version support SHOULD be included in new services. 524 >> Version numbers SHOULD NOT be included in either the service name 525 or service description. 527 Again, the port number space is far too limited to be used as an 528 indicator of protocol version or message type. Although this has 529 happened in the past (e.g., for NFS), it should be avoided. 531 7.6. Transport Protocols 533 IANA assigns port numbers specific to one or more transport 534 protocols, typically UDP and TCP, but also SCTP, DCCP, and any other 535 standard transport protocol [RFC4340] [RFC4960]. Originally, IANA 536 port assignments were made for both UDP and TCP together; other 537 transports were not indicated. However, to conserve space, and to 538 reflect increasing use of other transports, assignments are now 539 specific only to the transport requested. 541 In general, a service should request assignments for multiple 542 transports using the same service name and description on the same 543 port number only when they all reflect essentially the same service. 544 Good examples of such use are DNS and NFS, where the difference 545 between the UDP and TCP services are specific to supporting each 546 transport. E.g., the UDP variant of a service might add sequence 547 numbers, and the TCP variant of the same service might add in-band 548 message delimiters. 550 >> Service names and descriptions for multiple transport port 551 assignments SHOULD match only when they describe the same service, 552 with the exception of enhancements for each supported transport. 554 When the services differ, their service names and descriptions 555 should reflect that difference. E.g., if TCP is used for the basic 556 control protocol and UDP for an alarm protocol, then the services 557 might be "name-ctl" and "name-alarm". A common example is when TCP 558 is used for a service, and UDP is used to determine whether that 559 service is active (via a multicast test message) [RFC1122]. The 560 following convention has been used by IANA for several years to 561 indicate this case: 563 >> When UDP is used for multicast discovery of an active TCP 564 service, the UDP service name SHOULD end in "-disc". 566 Some services are used for discovery, either in conjunction with a 567 TCP service, or as a stand-alone capability. Such services will be 568 more reliable when using multicast rather than broadcast (over 569 IPv4), because IP routers do not forward "all nodes" (all 1's, i.e., 570 255.255.255.255 for IPv4) broadcasts, and have not been required to 571 support subnet-directed broadcasts since 1999 [RFC1812] [RFC2644]. 572 This issue is relevant only for IPv4 because IPv6 does not support 573 broadcast. 575 >> UDP over IPv4 multi-host services SHOULD use multicast rather 576 than broadcast. 578 Designers should be very careful in creating services over 579 transports that do not support congestion control or error recovery, 580 notably UDP. There are several issues that should be considered in 581 such cases [RFC5405]: 583 >> UDP services SHOULD be bandwidth limited, using only nominal 584 network capacity. Users should keep in mind that "nominal" may vary 585 depending on the deployment environment, and may be very low. 587 >> UDP services that use multipoint communication SHOULD be 588 scalable, and SHOULD NOT rely solely on the efficiency of multicast 589 transmission for scalability. 591 >> UDP services SHOULD include congestion detection and backoff. 593 >> UDP SHOULD NOT be used as a performance enhancement over TCP, 594 i.e., to circumnavigate TCP's congestion control. 596 7.7. When to Request an Assignment 598 Assignments are typically requested when a user has enough 599 information to reasonably answer the questions in the IANA 600 application. IANA applications typically take up to a few weeks to 601 process, with some complex cases taking up to a month. The process 602 typically involves a few exchanges between the IANA Ports Expert 603 Review team and the applicant. 605 An application needs to include a description of the service, as 606 well as to address key questions designed to help IANA determine 607 whether the assignment is justified. 609 Services that are independently developed can be requested at any 610 time, but are typically best requested in the last stages of design 611 and initial experimentation, before any deployment has occurred that 612 cannot easily be updated. 614 >> Users MUST NOT deploy implementations that use ports prior their 615 assignment by IANA. 617 Deployments that use ports before deployment complicate IANA 618 management of the port space. Keep in mind that this recommendation 619 protects both other parties and you; it helps ensure that your 620 desired number and service name are available when assigned. The 621 list of currently unassigned numbers is just that - *currently* 622 unassigned. It does not reflect pending applications, nor 623 applications that might arrive before yours. Waiting for an official 624 IANA assignment reduces the chance that your assignment will 625 conflict with another deployed service. 627 Applications made through Internet Draft / RFC publication typically 628 use a placeholder ("PORTNUM") in the text, and use an experimental 629 port number until a final assignment has been made [RFC6335]. That 630 assignment is initially indicated in the IANA Considerations section 631 of the document, and is tracked by the RFC Editor. When the RFC 632 reaches the last stages of publication, that request is forwarded to 633 IANA for handling. At that time, IANA typically requests that the 634 applicant fill out the application form on their website, because 635 not every protocol document addresses the information required. 636 Using this single application process also ensures that IANA has 637 complete information even if the RFC publication is interrupted. For 638 this reason as well, the application should be complete and not 639 refer solely to the Internet Draft, RFC, a website, or any other 640 external documentation. 642 >> Users writing specifications SHOULD use symbolic names for port 643 numbers and service names until an IANA assignment has been 644 completed. 646 7.8. Squatting 648 "Squatting" describes the use of a number from the assigned range in 649 deployed software without IANA assignment. It is hazardous because 650 IANA cannot track such usage, and thus cannot avoid making 651 legitimate assignments that conflict with such unauthorized usage. 653 Note that there are numerous services that have squatted on such 654 numbers that are in widespread use. Even such widespread de-facto 655 use may not justify a later IANA assignment of that value, 656 especially if either the value has already been assigned to a 657 legitimate applicant or if the service would not qualify for an 658 assignment of its own accord. 660 7.9. Other Considerations 662 There are a few other points worth mentioning, which are summarized 663 in this section. 665 As noted earlier, system ports should be used sparingly, and it is 666 better to avoid them altogether. This avoids the potentially 667 incorrect assumption that the service on such ports run in a 668 privileged mode. 670 Port names and numbers are not intended to be changed. Once 671 deployed, it can be very difficult to recall every implementation, 672 so the assignment should be retained. However, in cases where the 673 current assignee of a name or number has reasonable knowledge of the 674 impact on such uses, and is willing to accept that impact, the name 675 or number of an assignment can be changed [RFC6335] 677 Aliases, or multiple service names for the same port number, are no 678 longer considered appropriate [RFC6335]. 680 8. Security Considerations 682 This document discusses ways to conserve port numbers, notably 683 through encouraging demultiplexing within a single port. As such, 684 there may be cases where two variants of a protocol - insecure and 685 secure (such as using optional TLS) or different versions - are 686 suggested to share the same port. 688 This document reminds protocol designers that port numbers are not a 689 substitute for security, and should not alone be used to avoid 690 denial of service or firewall traffic, notably because their use is 691 not regulated or authenticated. 693 9. IANA Considerations 695 The entirety of this document focuses on IANA issues, notably 696 suggestions that help ensure the conservation of port numbers and 697 provide useful hints for issuing informative requests thereof. 699 10. References 701 10.1. Normative References 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, March 1997. 706 10.2. Informative References 708 [Hi95] Hickman, K., "The SSL Protocol", February 1995. 710 [IEN112] Postel, J., "Transmission Control Protocol", IEN 112, 711 August 1979. 713 [RFC33] Crocker, S., "New Host-Host Protocol", RFC 33 February 714 1970. 716 [RFC37] Crocker, S., "Network Meeting Epilogue", RFC 37, March 717 1970. 719 [RFC38] Wolfe, S., "Comments on Network Protocol from NWG/RFC 720 #36", RFC 38, March 1970. 722 [RFC48] Postel, J., S. Crocker, "Possible protocol plateau", RFC 723 48, April 1970. 725 [RFC61] Walden, D., "Note on Interprocess Communication in a 726 Resource Sharing Computer Network", RFC 61, July 1970. 728 [RFC76] Bouknight, J., J. Madden, G. Grossman, "Connection by 729 name: User oriented protocol", RFC 76, October 1970. 731 [RFC333] Bressler, R., D. Murphy, D. Walden. "Proposed experiment 732 with a Message Switching Protocol", RFC 333, May 1972. 734 [RFC739] Postel, J., "Assigned numbers", RFC 739, November 1977. 736 [RFC758] Postel, J., "Assigned numbers", RFC 758, August 1979. 738 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 739 1980. 741 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 742 September 1981 744 [RFC820] Postel, J., "Assigned numbers", RFC 820, August 1982. 746 [RFC900] Reynolds, J., J. Postel, "Assigned numbers", RFC 900, June 747 1984. 749 [RFC1122] Deering, S., "Host extensions for IP multicasting", RFC 750 1122, August 1989. 752 [RFC1263] O'Malley, S., L. Peterson, "TCP Extensions Considered 753 Harmful", RFC 1263, October 1991. 755 [RFC1340] Reynolds, J., J. Postel, "Assigned numbers", RFC 1340, 756 July 1992. 758 [RFC1700] Reynolds, J., J. Postel, "Assigned numbers", RFC 1700, 759 October 1994. 761 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", 762 RFC 1812, June 1995. 764 [RFC2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. 765 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 766 Protocol -- HTTP/1.1", RFC 2616, June 1999. 768 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 769 in Routers", RFC 2644, August 1999. 771 [RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For 772 Values In the Internet Protocol and Related Headers", RFC 773 2780, March 2000. 775 [RFC2817] Khare, R., S. Lawrence, "Upgrading to TLS Within 776 HTTP/1.1", RFC 2817, May 2000. 778 [RFC3232] Reynolds, J. (Ed.), "Assigned Numbers: RFC 1700 is 779 Replaced by an On-line Database", RFC 3232, January 2002. 781 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 782 Considered Useful", BCP 82, RFC 3962, Jan. 2004. 784 [RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion 785 Control Protocol (DCCP)", RFC 4340, March 2006. 787 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 788 RFC 4960, September 2007. 790 [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security 791 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 793 [RFC5405] Eggert, L., G. Fairhurst, "Unicast UDP Usage Guidelines 794 for Application Designers," RFC 5405, Nov. 2008. 796 [RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, S. 797 Cheshire, "Internet Assigned Numbers Authority (IANA) 798 Procedures for the Management of the Service Name and 799 Transport Protocol Port Number Registry", RFC 6335, August 800 2011. 802 [RFC6762] Cheshire, S., M. Krochmal, "Multicast DNS", RFC 6762, 803 February 2013. 805 [RFC6763] Cheshire, S., M. Krochmal, "DNS-Based Service Discovery", 806 RFC 6763, February 2013. 808 11. Acknowledgments 810 TBD 812 This document was prepared using 2-Word-v2.0.template.dot. 814 Authors' Addresses 816 Joe Touch 817 USC/ISI 818 4676 Admiralty Way 819 Marina del Rey, CA 90292-6695 820 U.S.A. 822 Phone: +1 (310) 448-9151 823 EMail: touch@isi.edu