idnits 2.17.1 draft-ietf-tsvwg-port-use-02.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 (July 15, 2013) is 3936 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 2818 (Obsoleted by RFC 9110) -- 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 (==), 14 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 July 15, 2013 4 Expires: January 2014 6 Recommendations for Transport Port Uses 7 draft-ietf-tsvwg-port-use-02.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 January 15, 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......................................7 63 7.1. Do You Need a Port?.......................................7 64 7.2. How Many Ports?...........................................9 65 7.3. Picking a Port Number.....................................9 66 7.4. Support for Security.....................................10 67 7.5. Support for Future Versions..............................11 68 7.6. Transport Protocols......................................11 69 7.7. When to Request an Assignment............................13 70 7.8. Squatting................................................14 71 7.9. Other Considerations.....................................14 72 8. Security Considerations.......................................15 73 9. IANA Considerations...........................................15 74 10. References...................................................15 75 10.1. Normative References....................................15 76 10.2. Informative References..................................15 77 11. Acknowledgments..............................................17 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 how the issue of 116 port determination [RFC48]. RFC61 notes that the challenge of 117 knowing the appropriate port numbers is "left to the processes" in 118 general, but introduces the concept of a "well-known" port for 119 common services [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 used for other purposes as well, however. The other 237 primary reason for requesting assigned ports with IANA is to 238 simplify end system configuration, so individual installations do 239 not need to coordinate their use of arbitrary ports. A similar 240 reason is to simplify firewall management, so that a single, fixed 241 firewall configuration can either permit or deny a service. 243 6. Conservation 245 Ports are a scarce resource that are globally shared by the entire 246 Internet community. As a result, every attempt should be made to 247 conserve ports and request only those that are absolutely necessary. 249 There are a variety of ways that systems can conserve port numbers: 251 o A single assigned port number can provide access to different 252 capabilities over different connections (or equivalent, e.g., 253 for UDP [RFC768]), using in-band information. 255 o A single assigned port can indicate the dynamic port(s) on 256 which different capabilities are supported, as is done for 257 FTP. 259 o An existing service can indicate the dynamic port(s) on which 260 services are supported, such as with mDNS and portmapper 261 [RFC6762] [RFC6763]. 263 o Copies of an existing service can be differentiated by using 264 different IP addresses (even on the same host). 266 o Copies of some existing services can be differentiated using 267 in-band information (e.g., HTTP). 269 o Different performance requirements or capabilities can already 270 be supported using different connections or endpoint 271 associations. 273 The key observation is that port numbers are intended to 274 differentiate services, not performance, replicas, connections, or 275 payload types. Port numbers are a very small space, so it is never 276 appropriate to consume port numbers to save larger spaces, such as 277 IP addresses. 279 Others have noted "think twice about modifying TCP, then don't" 280 [RFC1263]. In this case, similar advice might be: 282 o Think twice before asking for a port, then try not to. 284 o If you need more than one port assignment, revise your 285 architecture until you can get by with only one, or, 286 preferably, none. 288 6.1. Firewall and NAT Considerations 290 Assigned numbers are useful for configuring firewalls and other 291 port-based systems for access control. Ultimately, these ports 292 indicate services only to the endpoints, and any intermediate device 293 that assigns meaning to a value can be incorrect. End systems might 294 agree to run web services (HTTP) over port 53 (typically used for 295 DNS) rather than port 80, at which point a firewall that blocks port 296 80 would have no effect. However, assigned values often are 297 important in helping configure firewalls to known values. 299 Using dynamic ports, or dynamically-indicated ports over known ports 300 (such as with FTP) often complicates firewall and NAT interactions. 301 FTP over firewalls often requires direct support for deep-packet 302 inspection (to snoop for the dynamic port to open) and "passive 303 mode" FTP, in which both FTP connections are opened from the client 304 to the server (useful for NAT traversal). 306 7. How to Use Assigned Ports 308 The following section describes the steps users can take to help 309 assist with the use of assigned ports. 311 7.1. Do You Need a Port? 313 First, ask whether you really need a port assignment. In many cases, 314 a new assignment may not be needed, for example: 316 o Is this really a new service, or can you use an existing 317 service? 319 o Is this an experimental service [RFC3692]? If so, consider 320 using the current experimental ports [RFC2780] 322 o Can this service use a dynamic port that is coordinated out- 323 of-band, e.g.: 325 o By explicit configuration of both endpoints. 327 o By shared information within the same host (e.g., a 328 configuration file). 330 o Using an existing port discovery service: portmapper, mDNS, 331 etc. [RFC6762] [RFC6763] 333 There are a few good examples of reasons that more directly suggest 334 that not only is a port not necessary, but it is directly 335 counterindicated: 337 o Ports are not for performance. Performance enhancement can 338 occur within separate connections. 340 o Additional ports are not to replicate an existing service. For 341 example, if you have a device that is configured using a web 342 browser, that is a copy of HTTP port 80, and does not warrant 343 a new assignment. However, if you develop an automated system 344 that happens to use HTTP framing, that could be a new service. 345 A good way to tell is "can an unmodified client of the 346 existing service interact with your service"? If so, that 347 would be a copy, and should not request a new assignment. 349 o Ports are not for insecure versions of existing secure 350 services. Consider that a service that includes required 351 security would be made vulnerable by having the same 352 capability accessible without security. 354 Note that the converse is different, i.e., it can be useful to 355 create a new, secure service that replicates an existing 356 insecure service on a new port assignment. This can be 357 necessary when the existing service is not backward-compatible 358 with security enhancements, such as the use of TLS or SSL 359 [Hi95] [RFC5246]. 361 Some users may not need assigned port numbers at all. Some systems 362 can register services in the DNS, using SRV entries. These services 363 can be discovered by a variety of means, including mDNS, or via 364 direct query. In such cases, users can more easily request a SRV 365 name, which are assigned first-come, first-served from a much larger 366 namespace. 368 IANA assigns port numbers, but this assignment is typically used 369 only for servers, i.e., the host that listens for incoming 370 connections. Clients, i.e., hosts that initiate connections, 371 typically refer to those assigned ports but do not need port 372 assignments for their endpoint. 374 7.2. How Many Ports? 376 As noted earlier, systems might require a single port assignment, 377 but rarely require multiple ports. There are a variety of known ways 378 to reduce port use. Although some may be cumbersome or inefficient, 379 they are always preferable to consuming additional ports. 381 Such techniques include: 383 o Use of a discovery service, either a shared service (mDNS), or 384 a discovery service for a given system 386 o Multiplex packet types using in-band information, either on a 387 per-message or per-connection basis. Such demultiplexing can 388 even hand-off connections among different processes. 390 There are some cases where it is still important to have assigned 391 port numbers, largely to traverse either NATs or firewalls. Although 392 automatic configuration protocols have been proposed and developed, 393 system designers cannot yet their presence. 395 In the past, some services were assigned multiple ports, or even 396 fairly large port ranges (e.g., X11). This occurred for a variety of 397 reasons - port conservation was not widely understood, assignments 398 were not as ardently reviewed, etc. This no longer reflects current 399 practice, and such assignments are not considered to constitute a 400 precedent for future assignments. 402 7.3. Picking a Port Number 404 Given a demonstrated need for a port number assignment, the next 405 question is how to pick the desired port number. An application for 406 a port assignment does not need to include a desired port number; in 407 that case, IANA will select from those currently available. 409 Users should consider whether the requested port number is 410 important. For example, would you accept an assignment if IANA 411 picked the value? Would you want a TCP port number assignment if the 412 corresponding UDP one were unavailable (assuming your service needed 413 only a TCP port) [RFC793]? 415 The most critical issue in picking a number is selecting the desired 416 range, i.e.., system vs. user ports. The distinction was intended to 417 indicate a difference in privilege; system ports required privileged 418 ('root') access, while user ports did not. That distinction has 419 blurred because some current systems do not limit access control to 420 system ports, and because some system services have been replicated 421 on user numbers (e.g., IRC). Even so, system port assignments have 422 continued at an average rate of 3-4 per year over the past 6 years 423 (2007-2012), indicating that the desire to keep this distinction 424 continues. 426 As a result, we recommend that the different between user and system 427 ports be treated with caution. Developers are advised to treat 428 services as if they are always run without privilege. As a result: 430 >> Developers SHOULD NOT apply for system ports because the 431 increased privilege they provide is not always enforced. 433 Even when developers seek a system port, it may be very difficult to 434 obtain. System port assignment requires IETF Review or IESG Approval 435 and justification that both user and dynamic port ranges are 436 insufficient [RFC6335]. 438 >> System implementers SHOULD enforce the need for privilege for 439 processes to listen on system ports. 441 At some future date, it might be useful to deprecate the distinction 442 between system and user ports altogether. Services typically require 443 elevated ('root') privileges to bind to a system port, but many such 444 services go to great lengths to immediately drop those privileges to 445 reduce the impact of an attack using their capabilities. As a result 446 it can be more secure to run such services on user ports than on 447 system ports. Further, avoiding system ports would potentially waste 448 only approximately 180 of 1024 values (17%). 450 7.4. Support for Security 452 Services represent a potential system vulnerability. Given the 453 current state of cybersecurity in the Internet, we recommend that: 455 >> New services SHOULD support security, either directly or via a 456 secure transport such as TLS [RFC5246]. 458 >> Insecure versions of new secure services SHOULD be avoided 459 because of the vulnerability they create. 461 >> Security SHOULD NOT rely on port number distinctions alone; every 462 service, whether secure or not, SHOULD expect to be attacked. 464 There is debate as to how to secure legacy insecure services 465 [RFC6335]. Some argue that secure variants should share the existing 466 port assignment, such that security is enabled on a per-connection 467 basis [RFC2817]. Others argue that security should be supported on a 468 new port assignment and be enabled by default. IANA currently 469 permits either approach. 471 Optional security can penalize performance, requiring additional 472 round-trip exchanges before a connection can be established. As we 473 discussed earlier, ports are a critical resource and it is 474 inappropriate to consume assignments to increase performance. 476 Note however that a new service might not be eligible for IANA 477 assignment of both an insecure and a secure variant of the same 478 service, and similarly IANA might be skeptical of an assignment for 479 an insecure port for a secure service. In both cases, security of 480 the service is compromised by adding the insecure port assignment. 482 7.5. Support for Future Versions 484 Current IANA assignments are expected to support versioning 485 [RFC6335]. Versions are typically indicated in-band, either at the 486 beginning of a connection or association, or in each protocol 487 message. 489 >> Version support SHOULD be included in new services. 491 >> Version numbers SHOULD NOT be included in either the service name 492 or service description. 494 Again, the port number space is far too limited to be used as an 495 indicator of protocol version or message type. Although this has 496 happened in the past (e.g., for NFS), it should be avoided. 498 7.6. Transport Protocols 500 IANA assigns port numbers specific to one or more transport 501 protocols, typically UDP and TCP, but also SCTP, DCCP, and any other 502 standard transport protocol [RFC4340] [RFC4960]. Originally, IANA 503 port assignments were made for both UDP and TCP together; other 504 transports were not indicated. However, to conserve space, and to 505 reflect increasing use of other transports, assignments are now 506 specific only to the transport requested. 508 In general, a service should request assignments for multiple 509 transports the same service name and description on the same port 510 number only when they all reflect essentially the same service. Good 511 examples of such use are DNS and NFS, where the difference between 512 the UDP and TCP services are specific to supporting each transport. 513 E.g., the UDP variant of a service might add sequence numbers, and 514 the TCP variant of the same service might add in-band message 515 delimiters. 517 >> Service names and descriptions for multiple transport port 518 assignments SHOULD match only when they describe the same service, 519 with the exception of enhancements for each supported transport. 521 When the services differ, their service names and descriptions 522 should reflect that difference. E.g., if TCP is used for the basic 523 control protocol and UDP for an alarm protocol, then the services 524 might be "name-ctl" and "name-alarm". A common example is when TCP 525 is used for a service, and UDP is used to determine whether that 526 service is active (via a multicast test message) [RFC1122]. The 527 following convention has been used by IANA for several years to 528 indicate this case: 530 >> When UDP is used for multicast discovery of an active TCP 531 service, the UDP service name SHOULD end in "-disc". 533 Some services are used for discovery, either in conjunction with a 534 TCP service, or as a stand-alone capability. Such services will be 535 more reliable when using multicast rather than broadcast, because IP 536 routers do not forward "all nodes" (all 1's, i.e., 255.255.255.255 537 for IPv4) broadcasts, and are have not been required to support 538 subnet-directed broadcasts since 1999 [RFC1812] [RFC2644]. 540 >> UDP multi-host services SHOULD use multicast rather than 541 broadcast. 543 Designers should be very careful in creating services over 544 transports that do not support congestion control or error recovery, 545 notably UDP. There are several issues that should be considered in 546 such cases [RFC5405]: 548 >> UDP services SHOULD be bandwidth limited, using only nominal 549 network capacity. Users should keep in mind that "nominal" may vary 550 depending on the deployment environment, and may be very low. 552 >> UDP services that use multipoint communication SHOULD be 553 scalable, and SHOULD NOT rely solely on the efficiency of multicast 554 transmission for scalability. 556 >> UDP services SHOULD include congestion detection and backoff. 558 >> UDP SHOULD NOT be used as a performance enhancement over TCP, 559 i.e., to circumnavigate TCP's congestion control. 561 7.7. When to Request an Assignment 563 Assignments are typically requested when a user has enough 564 information to reasonably answer the questions in the IANA 565 application. IANA applications typically take up to a few weeks to 566 process, with some complex cases taking up to a month. The process 567 typically involves a few exchanges between the IANA Ports Expert 568 Review team and the applicant. 570 An application needs to include a description of the service, as 571 well as to address key questions designed to help IANA determine 572 whether the assignment is justified. 574 Services that are independently developed can be requested at any 575 time, but are typically best requested in the last stages of design 576 and initial experimentation, before any deployment has occurred that 577 cannot easily be updated. 579 >> Users MUST NOT deploy implementations that use ports prior their 580 assignment by IANA. 582 Deployments that use ports before deployment complicate IANA 583 management of the port space. Keep in mind that this recommendation 584 protects both other parties and you; it helps ensure that your 585 desired number and service name are available when assigned. The 586 list of currently unassigned numbers is just that - *currently* 587 unassigned. It does not reflect pending applications, nor 588 applications that might arrive before yours. Waiting for an official 589 IANA assignment reduces the chance that your assignment will 590 conflict with another deployed service. 592 Applications made through Internet Draft / RFC publication typically 593 use a placeholder ("PORTNUM") in the text, and use an experimental 594 port number until a final assignment has been made [RFC6335]. That 595 assignment is initially indicated in the IANA Considerations section 596 of the document, and is tracked by the RFC Editor. When the RFC 597 reaches the last stages of publication, that request is forwarded to 598 IANA for handling. At that time, IANA typically requests that the 599 applicant fill out the application form on their website, because 600 not every protocol document addresses the information required. 601 Using this single application process also ensures that IANA has 602 complete information even if the RFC publication is interrupted. For 603 this reason as well, the application should be complete and not 604 refer solely to the Internet Draft, RFC, a website, or any other 605 external documentation. 607 >> Users writing specifications SHOULD use symbolic names for port 608 numbers and service names until an IANA assignment has been 609 completed. 611 7.8. Squatting 613 "Squatting" describes the use of a number from the assigned range in 614 deployed software without IANA assignment. It is hazardous because 615 IANA cannot track such usage, and thus cannot avoid making 616 legitimate assignments that conflict with such unauthorized usage. 618 Note that there are numerous services that have squatted on such 619 numbers that are in widespread use. Even such widespread de-facto 620 use may not justify a later IANA assignment of that value, 621 especially if either the value has already been assigned to a 622 legitimate applicant or if the service would not qualify for an 623 assignment of its own accord. 625 7.9. Other Considerations 627 There are a few other points worth mentioning, which are summarized 628 in this section. 630 As noted earlier, system ports should be used sparingly, and it is 631 better to avoid them altogether. This avoids the potentially 632 incorrect assumption that the service on such ports run in a 633 privileged mode. 635 Port names and numbers are not intended to be changed. Once 636 deployed, it can be very difficult to recall every implementation, 637 so the assignment should be retained. However, in cases where the 638 current assignee of a name or number has reasonable knowledge of the 639 impact on such uses, and is willing to accept that impact, the name 640 or number of an assignment can be changed [RFC6335] 642 Aliases, or multiple service names for the same port number, are no 643 longer considered appropriate [RFC6335]. 645 8. Security Considerations 647 This document discusses ways to conserve port numbers, notably 648 through encouraging demultiplexing within a single port. As such, 649 there may be cases where two variants of a protocol - insecure and 650 secure, are suggested to share the same port (e.g., HTTP and HTTPS, 651 though currently those are assigned different ports) [RFC2818]. 653 This document reminds protocol designers that port numbers are not a 654 substitute for security, and should not alone be used to avoid 655 denial of service or firewall traffic, notably because their use is 656 not regulated or authenticated. 658 9. IANA Considerations 660 The entirety of this document focuses on IANA issues, notably 661 suggestions that help ensure the conservation of port numbers and 662 provide useful hints for issuing informative requests thereof. 664 10. References 666 10.1. Normative References 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, March 1997. 671 10.2. Informative References 673 [Hi95] Hickman, K., "The SSL Protocol", February 1995. 675 [IEN112] Postel, J., "Transmission Control Protocol", IEN 112, 676 August 1979. 678 [RFC33] Crocker, S., "New Host-Host Protocol", RFC 33 February 679 1970. 681 [RFC37] Crocker, S., "Network Meeting Epilogue", RFC 37, March 682 1970. 684 [RFC38] Wolfe, S., "Comments on Network Protocol from NWG/RFC 685 #36", RFC 38, March 1970. 687 [RFC48] Postel, J., S. Crocker, "Possible protocol plateau", RFC 688 48, April 1970. 690 [RFC61] Walden, D., "Note on Interprocess Communication in a 691 Resource Sharing Computer Network", RFC 61, July 1970. 693 [RFC76] Bouknight, J., J. Madden, G. Grossman, "Connection by 694 name: User oriented protocol", RFC 76, October 1970. 696 [RFC333] Bressler, R., D. Murphy, D. Walden. "Proposed experiment 697 with a Message Switching Protocol", RFC 333, May 1972. 699 [RFC739] Postel, J., "Assigned numbers", RFC 739, November 1977. 701 [RFC758] Postel, J., "Assigned numbers", RFC 758, August 1979. 703 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 704 1980. 706 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 707 September 1981 709 [RFC820] Postel, J., "Assigned numbers", RFC 820, August 1982. 711 [RFC900] Reynolds, J., J. Postel, "Assigned numbers", RFC 900, June 712 1984. 714 [RFC1122] Deering, S., "Host extensions for IP multicasting", RFC 715 1122, August 1989. 717 [RFC1263] O'Malley, S., L. Peterson, "TCP Extensions Considered 718 Harmful", RFC 1263, October 1991. 720 [RFC1340] Reynolds, J., J. Postel, "Assigned numbers", RFC 1340, 721 July 1992. 723 [RFC1700] Reynolds, J., J. Postel, "Assigned numbers", RFC 1700, 724 October 1994. 726 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", 727 RFC 1812, June 1995. 729 [RFC2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. 730 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 731 Protocol -- HTTP/1.1", RFC 2616, June 1999. 733 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 734 in Routers", RFC 2644, August 1999. 736 [RFC2780] Bradner, S., V. Paxson, "IANA Allocation Guidelines For 737 Values In the Internet Protocol and Related Headers", RFC 738 2780, March 2000. 740 [RFC2817] Khare, R., S. Lawrence, "Upgrading to TLS Within 741 HTTP/1.1", RFC 2817, May 2000. 743 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 745 [RFC3232] Reynolds, J. (Ed.), "Assigned Numbers: RFC 1700 is 746 Replaced by an On-line Database", RFC 3232, January 2002. 748 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 749 Considered Useful", BCP 82, RFC 3962, Jan. 2004. 751 [RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion 752 Control Protocol (DCCP)", RFC 4340, March 2006. 754 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 755 RFC 4960, September 2007. 757 [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security 758 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 760 [RFC5405] Eggert, L., G. Fairhurst, "Unicast UDP Usage Guidelines 761 for Application Designers," RFC 5405, Nov. 2008. 763 [RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, S. 764 Cheshire, "Internet Assigned Numbers Authority (IANA) 765 Procedures for the Management of the Service Name and 766 Transport Protocol Port Number Registry", RFC 6335, August 767 2011. 769 [RFC6762] Cheshire, S., M. Krochmal, "Multicast DNS", RFC 6762, 770 February 2013. 772 [RFC6763] Cheshire, S., M. Krochmal, "DNS-Based Service Discovery", 773 RFC 6763, February 2013. 775 11. Acknowledgments 777 TBD 779 This document was prepared using 2-Word-v2.0.template.dot. 781 Authors' Addresses 783 Joe Touch 784 USC/ISI 785 4676 Admiralty Way 786 Marina del Rey, CA 90292-6695 787 U.S.A. 789 Phone: +1 (310) 448-9151 790 EMail: touch@isi.edu