idnits 2.17.1 draft-ietf-tsvwg-port-use-04.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 (May 14, 2014) is 3606 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 normative reference: RFC 5405 (Obsoleted by RFC 8085) -- 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 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- 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 3546 (Obsoleted by RFC 4366) -- Obsolete informational reference (is this intentional?): RFC 4020 (Obsoleted by RFC 7120) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 15 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 May 14, 2014 4 Expires: November 2014 6 Recommendations for Transport Port Uses 7 draft-ietf-tsvwg-port-use-04.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 November 14, 2014. 32 Copyright Notice 34 Copyright (c) 2014 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..............................2 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. Is a port assignment necessary?...........................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......................................13 69 7.7. When to Request an Assignment............................14 70 7.8. Squatting................................................15 71 7.9. Other Considerations.....................................16 72 8. Security Considerations.......................................16 73 9. IANA Considerations...........................................16 74 10. References...................................................16 75 10.1. Normative References....................................16 76 10.2. Informative References..................................17 77 11. Acknowledgments..............................................19 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 indicate a simplex 105 communication path from an individual process. At a meeting 106 described in [RFC37], an idea was presented to decouple connections 107 between processes and links that they use as paths, and thus to 108 include source and destination socket identifiers in packets. 109 [RFC38] provides further detail, describing how processes might have 110 more than one of these paths and that more than one path may be 111 active at a time. As a result, there was the need to add a process 112 identifier to the header of each message so that incoming messages 113 could be demultiplexed to the appropriate process. [RFC38] further 114 suggested that 32 bits would be used for these identifiers. [RFC48] 115 discusses the current notion of listening on a specific port, but 116 does not discuss the issue of port determination. [RFC61] notes that 117 the challenge of knowing the appropriate port numbers is "left to 118 the processes" in general, but introduces the concept of a "well- 119 known" port for common services. 121 [RFC76] proposed a "telephone book" by which an index would allow 122 ports to be used by name, but still assumed that both source and 123 destination ports are fixed by such a system. [RFC333] proposed that 124 a port pair, rather than an individual port, would be used on both 125 sides of the connection for demultiplexing messages. This is the 126 final view in [RFC793] (and its predecessors, including [IEN112]), 127 and brings us to their current meaning. [RFC739] introduced the 128 notion of generic reserved ports for groups of protocols, such as 129 "any private RJE server" [RFC739]. Although the overall range of 130 such ports was (and remains) 16 bits, only the first 256 (high 8 131 bits cleared) in the range were considered assigned. 133 [RFC758] is the first to describe a list of such well-known ports, 134 as well as describing ranges used for different purposes: 136 Binary Octal 138 ----------------------------------------------------------- 140 0-63 0-77 Network Wide Standard Function 142 64-127 100-177 Hosts Specific Functions 144 128-223 200-337 Reserved for Future Use 146 224-255 340-377 Any Experimental Function 148 In [RFC820] those range meanings disappeared, and a single list of 149 assignments is presented. By [RFC900] the ranges appeared as decimal 150 numbers rather than the octal ranges used previously. [RFC1340] 151 increased this range from 0..255 to 0..1023, and began to list TCP 152 and UDP port assignments individually (although the assumption was, 153 and remains, that once assigned a port applies to all transport 154 protocols, including TCP, UDP, recently SCTP and DCCP, as well as 155 ISO-TP4 for a brief period in the early 1990s). [RFC1340] also 156 established the Registered range of 1024-59151, though it notes that 157 it is not controlled by the IANA at that point. The list provided by 158 [RFC1700] in 1994 remained the standard until it was declared 159 replaced by an on-line version, as of [RFC3232] in 2002. 161 4. Current Port Use 163 The current IANA website (www.iana.org) indicates three ranges of 164 port assignments: 166 Binary Hex 168 ----------------------------------------------------------- 170 0-1023 0x03FF Well-Known (also System) 172 1024-49151 0x0400-0xBFFF Registered (also User) 174 49152-65535 0xC000-0xFFFF Dynamic (also Private) 176 Well-known encompasses the range 0..1023. On some systems, use of 177 these ports requires privileged access, e.g., that the process run 178 as 'root', which is why these are referred to as System ports. The 179 ports from 1024..49151 denotes non-privileged services, known as 180 Registered; because these ports do not run with special privileges, 181 they are often referred to as User ports. Dynamic (also known as 182 Private) ports are not assigned. 184 Both Well-Known and Registered ports are assigned through IANA, so 185 both are sometimes called 'registered ports'. As a result, the term 186 'registered' is ambiguous, referring either to the entire range 0- 187 49151 or to the User ports. Complicating matters further, System 188 ports do not always require special (i.e., 'root') privilege. For 189 clarity, the remainder of this document refers to the port ranges as 190 System, User, and Dynamic. 192 5. What is a Port? 194 A port is a 16-bit number used for two distinct purposes: 196 o Demultiplexing transport connections within an end host 198 o Identifying a service 200 The first purpose requires that each transport connection between a 201 given pair of IP addresses use a different pair of ports, but does 202 not require either coordination or registration of port use. It is 203 the second purpose that drives the need for a common registry. 205 Consider a user wanting to run a web server. That service could run 206 on any port, provided that all clients knew what port to use to 207 access that service at that host. Such information can be 208 distributed out-of-band, e.g., in the URI: 210 http://www.example.com:51509/ 212 Ultimately, the correlation of a service with a port number is an 213 agreement between just the two endpoints of the connection. A web 214 server can run on port 53, which might appear as DNS traffic to 215 others but will connect to browsers that know to use port 53 rather 216 than 80. 218 As a concept, a service is the combination of ISO Layers 5-7 that 219 represents an application protocol capability. For example www (port 220 80) is a service that uses HTTP as an application protocol and 221 provides access to a web server [RFC2616]. However, it is possible 222 to use HTTP for other purposes, such as command and control. This is 223 why some current service names (HTTP, e.g.) are a bit overloaded - 224 they describe not only the application protocol, but a particular 225 service. 227 IANA assigns ports so that Internet endpoints do not need pairwise, 228 explicit coordination of the meaning of their port numbers. This is 229 the primary reason for requesting assigned ports with IANA - to have 230 a common agreement between all endpoints on the Internet as to the 231 meaning of a port. 233 Ports are sometimes used by intermediate devices on a network path, 234 either to monitor available services, to monitor traffic (e.g., to 235 indicate the data contents), or to intercept traffic (to block, 236 proxy, relay, aggregate, or otherwise process it). In each case, the 237 intermediate device interprets traffic based on the port number. It 238 is important to recognize that any interpretation of ports - except 239 at the endpoints - may be incorrect, because ports are meaningful 240 only at the endpoints. Further, ports may not be visible to these 241 intermediate devices, such as when the transport protocol is 242 encrypted (as in network- or link-layer tunnels), or when a packet 243 is fragmented (in which case only the first fragment has the port 244 information). Such port invisibility may interfere with these in- 245 network port-based capabilities. 247 Ports can also be useful for other purposes. Assigned ports can 248 simplify end system configuration, so that individual installations 249 do not need to coordinate their use of arbitrary ports. Such 250 assignments can also simplify firewall management, so that a single, 251 fixed firewall configuration can either permit or deny a service. 253 6. Conservation 255 Assigned ports are a scarce resource that is globally shared by the 256 entire Internet community. As a result, every attempt should be made 257 to conserve ports and request assignments only for those that are 258 absolutely necessary. 260 There are a variety of ways that systems can conserve port numbers: 262 o A single assigned port number can support different functions 263 over separate connections, determined using in-band 264 information. FTP data connection can transfer binary or text 265 files, the latter translating line-terminators, as indicated 266 in-band over the control port [RFC959]. 268 o A single assigned port can indicate the Dynamic port(s) on 269 which different capabilities are supported, as with passive- 270 mode FTP [RFC959]. 272 o Several existing services can indicate the Dynamic port(s) on 273 which other services are supported, such as with mDNS and 274 portmapper [RFC1833] [RFC6762] [RFC6763]. 276 o Copies of an existing service can be differentiated by using 277 different IP addresses, either on different hosts or as 278 different real or virtual interfaces (or even operating 279 systems) on the same host. 281 o Copies of some existing services can be differentiated using 282 in-band information (e.g., URIs in HTTP Host field and TLS 283 Server Name Indication extension) [RFC2616] [RFC3546]. 285 o Different performance requirements can already be supported 286 using separate connections or endpoints with different 287 capabilities or configurations. 289 Port numbers are intended to differentiate services, not 290 performance, replicas, connections, or payload types. Port numbers 291 are also a very small space, so it is never appropriate to consume 292 port numbers to save larger spaces, such as IP addresses. 294 Others have noted "think twice about modifying TCP, then don't" 295 [RFC1263]. In this case, similar advice might be: 297 o Think twice before asking for an assigned port, then try not 298 to. 300 o If more than one port is desired, consider revising the 301 architecture until only one is needed, or, preferably, none. 303 6.1. Firewall and NAT Considerations 305 Assigned ports are useful for configuring firewalls and other port- 306 based systems for access control. Ultimately, these ports indicate 307 services only to the endpoints, and any intermediate device that 308 assigns meaning to a value can be incorrect. End systems might agree 309 to run web services (HTTP) over port 53 (typically used for DNS) 310 rather than port 80, at which point a firewall that blocks port 80 311 but permits port 53 would not have the desired effect. However, 312 assigned ports often are important in helping configure firewalls. 314 Using Dynamic ports, or explicitly-indicated ports indicated in-band 315 over another service (such as with FTP) often complicates firewall 316 and NAT interactions [RFC959]. FTP over firewalls often requires 317 direct support for deep-packet inspection (to snoop for the Dynamic 318 port for the NAT to correctly map) or passive-mode FTP (in which 319 both connections are opened from the client side). 321 7. How to Use Assigned Ports 323 Ports are assigned by IANA by a set of documented procedures [RFC 324 6335]. The following section describes the steps users can take to 325 help assist with the use of assigned ports, and with preparing an 326 application for a port assignment. 328 7.1. Is a port assignment necessary? 330 First, it is useful to consider whether a port assignment is 331 required. In many cases, a new assignment may not be needed, for 332 example: 334 o Is this really a new service, or can an existing service 335 suffice? 337 o Is this an experimental service [RFC3692]? If so, consider 338 using the current experimental ports [RFC2780]. 340 o Is this service independently useful? Some systems are 341 composed from collections of different service capabilities, 342 but not all component functions are useful as independent 343 services. Ports are typically shared among the smallest 344 independently-useful set of functions. Different service uses 345 or properties can be supported in separate connections after 346 an initial negotiation, e.g., to support software 347 decomposition. 349 o Can this service use a Dynamic port that is coordinated out- 350 of-band, e.g.: 352 o By explicit configuration of both endpoints. 354 o By shared information within the same host (e.g., a 355 configuration file or indicated within a URI). 357 o Using information exchanged on a related service: FTP, SIP, 358 etc. [RFC959] [RFC2543]. 360 o Using an existing port discovery service: portmapper, mDNS, 361 etc. [RFC1833] [RFC6762] [RFC6763]. 363 There are a few good examples of reasons that more directly suggest 364 that not only is a port not necessary, but it is directly counter- 365 indicated: 367 o Ports are not for performance. Performance enhancement can 368 occur within separate connections. 370 o Additional ports are not to replicate an existing service. For 371 example, a device is configured using a typical web browser 372 then it is a copy of HTTP port 80 and does not warrant a new 373 assignment. However, an automated system that happens to use 374 HTTP framing - but cannot be accessed by a browser - might be 375 a new service. A good way to tell is "can an unmodified client 376 of the existing service interact with the proposed service"? 377 If so, that service would be a copy of an existing service and 378 does not merit a new assignment. 380 o Separate ports are not for insecure versions of existing (or 381 new) secure services. Consider that a service that includes 382 required security would be made vulnerable by having the same 383 capability accessible without security. 385 Note that the converse is different, i.e., it can be useful to 386 create a new, secure service that replicates an existing 387 insecure service on a new port assignment. This can be 388 necessary when the existing service is not backward-compatible 389 with security enhancements, such as the use of TLS or SSL 390 [Hi95] [RFC5246]. 392 New services should support security or should consider 393 optional security. A new service should not need a port for an 394 insecure version; at best, this would be a performance issue 395 (see the first bullet), and at worst this presents a new 396 vulnerability. 398 o Ports are not for indicating different service versions. 399 Version differentiation should be handled in-band, e.g., using 400 a version number at the beginning of a connection or 401 transaction. This may not be possible with legacy assignments, 402 but all new assignments should incorporate support for version 403 indication. 405 Some users may not need assigned port numbers at all, e.g., SIP 406 allows voice calls to use Dynamic ports [RFC2543]. Some systems can 407 register services in the DNS, using SRV entries. These services can 408 be discovered by a variety of means, including mDNS, or via direct 409 query [RFC6762] [RFC6763]. In such cases, users can more easily 410 request a SRV name, which are assigned first-come, first-served from 411 a much larger namespace. 413 IANA assigns port numbers, but this assignment is typically used 414 only for servers, i.e., the host that listens for incoming 415 connections. Clients, i.e., hosts that initiate connections, 416 typically refer to those assigned ports but do not need port 417 assignments for their endpoint. 419 7.2. How Many Ports? 421 As noted earlier, systems might require a single port assignment, 422 but rarely require multiple ports. There are a variety of known ways 423 to reduce port use. Although some may be cumbersome or inefficient, 424 they are always preferable to consuming additional ports. 426 Such techniques include: 428 o Use of a discovery service, either a shared service (mDNS), or 429 a discovery service for a given system [RFC6762] [RFC6763]. 431 o Multiplex packet types using in-band information, either on a 432 per-message or per-connection basis. Such demultiplexing can 433 even hand-off different connections and types of connections 434 among different processes, such as is done with FTP [RFC959]. 436 There are some cases where it is still important to have assigned 437 port numbers, largely to traverse either NATs or firewalls. Although 438 automatic configuration protocols have been proposed and developed, 439 system designers cannot yet rely on their presence. 441 In the past, some services were assigned multiple ports or sometimes 442 fairly large port ranges (e.g., X11). This occurred for a variety of 443 reasons: port conservation was not widely understood, assignments 444 were not as ardently reviewed, etc. This no longer reflects current 445 practice and such assignments are not considered to constitute a 446 precedent for future assignments. 448 7.3. Picking a Port Number 450 Given a demonstrated need for a port number assignment, the next 451 question is how to pick the desired port number. An application for 452 a port assignment does not need to include a desired port number; in 453 that case, IANA will select from those currently available. 455 Users should consider whether the requested port number is 456 important. For example, would an assignment be acceptable if IANA 457 picked the port number value? Would a TCP port number assignment be 458 needed useful if the corresponding UDP one were unavailable 459 (assuming the proposed service needed only a TCP port)? 460 The most critical issue in picking a number is selecting the desired 461 range, i.e., System vs. User ports. The distinction was intended to 462 indicate a difference in privilege; originally, System ports 463 required privileged ('root') access, while User ports did not. That 464 distinction has since blurred because some current systems do not 465 limit access control to System ports and because some System 466 services have been replicated on User numbers (e.g., IRC). Even so, 467 System port assignments have continued at an average rate of 3-4 per 468 year over the past 7 years (2007-2013), indicating that the desire 469 to keep this distinction continues. 471 As a result, the difference between System and User ports needs to 472 be treated with caution. Developers are advised to treat services as 473 if they are always run without privilege. As a result: 475 >> Developers SHOULD NOT apply for System ports because the 476 increased privilege they provide is not always enforced. 478 Even when developers seek a System port, it may be very difficult to 479 obtain. System port assignment requires IETF Review or IESG Approval 480 and justification that both User and Dynamic port ranges are 481 insufficient [RFC6335]. 483 >> System implementers SHOULD enforce the need for privilege for 484 processes to listen on System ports. 486 At some future date, it might be useful to deprecate the distinction 487 between System and User ports altogether. Services typically require 488 elevated ('root') privileges to bind to a System port, but many such 489 services go to great lengths to immediately drop those privileges 490 just after connection establishment to reduce the impact of an 491 attack using their capabilities. Such services might be more 492 securely operated on User ports than on System ports. Further, if 493 System ports were no longer assigned, it would cost only 180 of the 494 1024 system values (17%), or 180 of the overall 49152 assigned 495 values (<0.04%). 497 7.4. Support for Security 499 Just as a service is a way to obtain information or processing from 500 a host over a network, an service can also be the opening through 501 which to attack that host. Given the current state of cybersecurity 502 in the Internet, the following advice is prudent: 504 >> New services SHOULD support security, either directly or via a 505 secure transport such as TLS [RFC5246]. 507 >> Insecure versions of new secure services SHOULD be avoided 508 because of the new vulnerability they create. 510 >> Security SHOULD NOT rely on port number distinctions alone; every 511 service, whether secure or not, SHOULD expect to be attacked. 513 There is debate as to how to secure legacy insecure services 514 [RFC6335]. Some argue that secure variants should share the existing 515 port assignment, such that security is enabled on a per-connection 516 basis [RFC2817]. Others argue that security should be supported on a 517 new port assignment and be enabled by default. IANA currently 518 permits either approach, although use of a single port is consistent 519 with port conservation. A separate port might be important for 520 security coordination (e.g., firewall management), but this might 521 further argue for deprecation of the insecure variant. 523 Optional security can penalize performance, requiring additional 524 round-trip exchanges before a connection can be established. As 525 discussed earlier, ports are a critical resource and it is 526 inappropriate to consume assignments to increase performance. 528 Note however that a new service might not be eligible for IANA 529 assignment of both an insecure and a secure variant of the same 530 service, and similarly IANA might be skeptical of an assignment for 531 an insecure port for a secure service. In both cases, security of 532 the service is compromised by adding the insecure port assignment. 534 7.5. Support for Future Versions 536 Current IANA assignments are expected to support the multiple 537 versions on the same assigned port [RFC6335]. Versions are typically 538 indicated in-band, either at the beginning of a connection or 539 association, or in each protocol message. 541 >> Version support SHOULD be included in new services. 543 >> Version numbers SHOULD NOT be included in either the service name 544 or service description. 546 Again, the port number space is far too limited to be used as an 547 indicator of protocol version or message type. Although this has 548 happened in the past (e.g., for NFS), it should be avoided in new 549 requests. 551 7.6. Transport Protocols 553 IANA assigns port numbers specific to one or more transport 554 protocols, typically UDP and TCP, but also SCTP, DCCP, and any other 555 standard transport protocol [RFC768] [RFC793] [RFC4340] [RFC4960]. 556 Originally, IANA port assignments were concurrent for both UDP and 557 TCP; other transports were not indicated. However, to conserve space 558 and to reflect increasing use of other transports, assignments are 559 now specific only to the transport being used. 561 In general, a service should request assignments for multiple 562 transports using the same service name and description on the same 563 port number only when they all reflect essentially the same service. 564 Good examples of such use are DNS and NFS, where the difference 565 between the UDP and TCP services are specific to supporting each 566 transport. E.g., the UDP variant of a service might add sequence 567 numbers and the TCP variant of the same service might add in-band 568 message delimiters. 570 >> Service names and descriptions for multiple transport port 571 assignments SHOULD match only when they describe the same service, 572 excepting only enhancements for each supported transport. 574 When the services differ, their service names and descriptions 575 should reflect that difference. E.g., if TCP is used for the basic 576 control protocol and UDP for an alarm protocol, then the services 577 might be "name-ctl" and "name-alarm". A common example is when TCP 578 is used for a service and UDP is used to determine whether that 579 service is active (e.g., via a unicast, broadcast, or multicast test 580 message) [RFC1122]. The following convention has been used by IANA 581 for several years to indicate this case: 583 >> When UDP is used for discovery of an active TCP service, the UDP 584 service name SHOULD end in "-disc". 586 Some services are used for discovery, either in conjunction with a 587 TCP service or as a stand-alone capability. Such services will be 588 more reliable when using multicast rather than broadcast (over IPv4) 589 because IP routers do not forward "all nodes" (all 1's, i.e., 590 255.255.255.255 for IPv4) broadcasts and have not been required to 591 support subnet-directed broadcasts since 1999 [RFC1812] [RFC2644]. 592 This issue is relevant only for IPv4 because IPv6 does not support 593 broadcast. 595 >> UDP over IPv4 multi-host services SHOULD use multicast rather 596 than broadcast. 598 Designers should be very careful in creating services over 599 transports that do not support congestion control or error recovery, 600 notably UDP. There are several issues that should be considered in 601 such cases, each summarized from [RFC5405]: 603 >> UDP services SHOULD be rate limited so that they use only nominal 604 network capacity. Users should keep in mind that "nominal" may vary 605 depending on the deployment environment and may be very low. 607 >> UDP services that use multipoint communication SHOULD be 608 scalable, and SHOULD NOT rely solely on the efficiency of multicast 609 transmission for scalability. 611 >> UDP services SHOULD include congestion detection and back-off. 613 >> UDP SHOULD NOT be used as a performance enhancement over TCP, 614 i.e., to circumnavigate TCP's congestion control. 616 7.7. When to Request an Assignment 618 Assignments are typically requested when a user has enough 619 information to reasonably answer the questions in the IANA 620 application. IANA applications typically take up to a few weeks to 621 process, with some complex cases taking up to a month. The process 622 typically involves a few exchanges between the IANA Ports Expert 623 Review team and the applicant. 625 An application needs to include a description of the service, as 626 well as to address key questions designed to help IANA determine 627 whether the assignment is justified. 629 Services that are independently developed can be requested at any 630 time, but are typically best requested in the last stages of design 631 and initial experimentation, before any deployment has occurred that 632 cannot easily be updated. 634 >> Users MUST NOT deploy implementations that use assigned ports 635 prior their assignment by IANA. 637 >> Users MUST NOT deploy implementations that default to using the 638 experimental System ports (1021 and 1022 [RFC4727]) outside a 639 controlled environment where they can be updated with a subsequent 640 assigned port [RFC3692]. 642 Deployments that use ports before deployment complicate IANA 643 management of the port space. Keep in mind that this recommendation 644 protects existing assignees, users of current services, and 645 applicants for new assignments; it helps ensure that a desired 646 number and service name are available when assigned. The list of 647 currently unassigned numbers is just that - *currently* unassigned. 648 It does not reflect pending applications. Waiting for an official 649 IANA assignment reduces the chance that an assignment request will 650 conflict with another deployed service. 652 Applications made through Internet Draft / RFC publication typically 653 use a placeholder ("PORTNUM") in the text, and use an experimental 654 port number until a final assignment has been made [RFC6335]. That 655 assignment is initially indicated in the IANA Considerations section 656 of the document, and is tracked by the RFC Editor. When the RFC 657 reaches the last stages of publication, that request is forwarded to 658 IANA for handling. At that time, IANA typically requests that the 659 applicant fill out the application form on their website, because 660 not every protocol document addresses the information required. 661 "Early" assignments can be made when justified, e.g., for early 662 interoperability testing, according to existing process [RFC4020] 663 [RFC6335]. 665 Using this single application process also ensures that IANA has 666 complete information even if the RFC publication is interrupted. For 667 this reason as well, the application should be complete and not 668 refer solely to the Internet Draft, RFC, a website, or any other 669 external documentation. 671 >> Users writing specifications SHOULD use symbolic names for port 672 numbers and service names until an IANA assignment has been 673 completed. 675 7.8. Squatting 677 "Squatting" describes the use of a number from the assigned range in 678 deployed software without IANA assignment. It is hazardous because 679 IANA cannot track such usage and thus cannot avoid making legitimate 680 assignments that conflict with such unauthorized usage. 682 Note that there are numerous services that have squatted on such 683 numbers that are in widespread use. Even such widespread de-facto 684 use may not justify a later IANA assignment of that value, 685 especially if either the value has already been assigned to a 686 legitimate applicant or if the service would not qualify for an 687 assignment of its own accord. 689 7.9. Other Considerations 691 As noted earlier, System ports should be used sparingly, and it is 692 better to avoid them altogether. This avoids the potentially 693 incorrect assumption that the service on such ports run in a 694 privileged mode. 696 Port names and numbers are not intended to be changed. Once 697 deployed, it can be very difficult to recall every implementation, 698 so the assignment should be retained. However, in cases where the 699 current assignee of a name or number has reasonable knowledge of the 700 impact on such uses, and is willing to accept that impact, the name 701 or number of an assignment can be changed [RFC6335] 703 Aliases, or multiple service names for the same port number, are no 704 longer considered appropriate [RFC6335]. 706 8. Security Considerations 708 This document discusses ways to conserve port numbers, notably 709 through encouraging demultiplexing within a single port. As such, 710 there may be cases where two variants of a protocol - insecure and 711 secure (such as using optional TLS) or different versions - are 712 suggested to share the same port. 714 This document reminds protocol designers that port numbers are not a 715 substitute for security, and should not alone be used to avoid 716 denial of service or firewall traffic, notably because their use is 717 not regulated or validated. 719 9. IANA Considerations 721 The entirety of this document focuses on IANA issues, notably 722 suggestions that help ensure the conservation of port numbers and 723 provide useful hints for issuing informative requests thereof. 725 10. References 727 10.1. Normative References 729 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 730 Requirement Levels", BCP 14, RFC 2119, March 1997. 732 [RFC2780] Bradner, S., and V. Paxson, "IANA Allocation Guidelines 733 For Values In the Internet Protocol and Related Headers", 734 BCP 37, RFC 2780, March 2000. 736 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 737 Considered Useful", BCP 82, RFC 3962, Jan. 2004. 739 [RFC4727] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, 740 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 742 [RFC5405] Eggert, L., and G. Fairhurst, "Unicast UDP Usage 743 Guidelines for Application Designers", BCP 145, RFC 5405, 744 Nov. 2008. 746 [RFC6335] Cotton, M., L. Eggert, J. Touch, M. Westerlund, and S. 747 Cheshire, "Internet Assigned Numbers Authority (IANA) 748 Procedures for the Management of the Service Name and 749 Transport Protocol Port Number Registry", BCP 165, RFC 750 6335, August 2011. 752 10.2. Informative References 754 [Hi95] Hickman, K., "The SSL Protocol", February 1995. 756 [IEN112] Postel, J., "Transmission Control Protocol", IEN 112, 757 August 1979. 759 [RFC33] Crocker, S., "New Host-Host Protocol", RFC 33 February 760 1970. 762 [RFC37] Crocker, S., "Network Meeting Epilogue", RFC 37, March 763 1970. 765 [RFC38] Wolfe, S., "Comments on Network Protocol from NWG/RFC 766 #36", RFC 38, March 1970. 768 [RFC48] Postel, J., and S. Crocker, "Possible protocol plateau", 769 RFC 48, April 1970. 771 [RFC61] Walden, D., "Note on Interprocess Communication in a 772 Resource Sharing Computer Network", RFC 61, July 1970. 774 [RFC76] Bouknight, J., J. Madden, and G. Grossman, "Connection by 775 name: User oriented protocol", RFC 76, October 1970. 777 [RFC333] Bressler, R., D. Murphy, and D. Walden. "Proposed 778 experiment with a Message Switching Protocol", RFC 333, 779 May 1972. 781 [RFC739] Postel, J., "Assigned numbers", RFC 739, November 1977. 783 [RFC758] Postel, J., "Assigned numbers", RFC 758, August 1979. 785 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 786 1980. 788 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 789 September 1981 791 [RFC820] Postel, J., "Assigned numbers", RFC 820, August 1982. 793 [RFC900] Reynolds, J., and J. Postel, "Assigned numbers", RFC 900, 794 June 1984. 796 [RFC959] Postel, J., and J. Reynolds, "FILE TRANSFER PROTOCOL 797 (FTP)", RFC 959, October 1985. 799 [RFC1122] Braden, B. (Ed.), "Requirements for Internet Hosts -- 800 Communication Layers", RFC 1122, October 1989. 802 [RFC1263] O'Malley, S., and L. Peterson, "TCP Extensions Considered 803 Harmful", RFC 1263, October 1991. 805 [RFC1340] Reynolds, J., and J. Postel, "Assigned numbers", RFC 1340, 806 July 1992. 808 [RFC1700] Reynolds, J., and J. Postel, "Assigned numbers", RFC 1700, 809 October 1994. 811 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", 812 RFC 1812, June 1995. 814 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 815 RFC 1833, August 1995. 817 [RFC2543] Handley, M., H. Schulzrinne, E. Schooler, and J. 818 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 819 March 1999. 821 [RFC2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. 822 Masinter, P. Leach, and T. Berners-Lee, "Hypertext 823 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 825 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 826 in Routers", RFC 2644, August 1999. 828 [RFC2817] Khare, R., and S. Lawrence, "Upgrading to TLS Within 829 HTTP/1.1", RFC 2817, May 2000. 831 [RFC3232] Reynolds, J. (Ed.), "Assigned Numbers: RFC 1700 is 832 Replaced by an On-line Database", RFC 3232, January 2002. 834 [RFC3546] Blake-Wilson, S., D. Hopwood, and T. Wright, "Transport 835 Layer Security (TLS) Extensions", RFC 3546, June 2003. 837 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 838 Standards Track Code Points", BCP 100, RFC 4020, February 839 2005. 841 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 842 Control Protocol (DCCP)", RFC 4340, March 2006. 844 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 845 RFC 4960, September 2007. 847 [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security 848 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 850 [RFC6762] Cheshire, S., and M. Krochmal, "Multicast DNS", RFC 6762, 851 February 2013. 853 [RFC6763] Cheshire, S., and M. Krochmal, "DNS-Based Service 854 Discovery", RFC 6763, February 2013. 856 11. Acknowledgments 858 This work benefitted from the feedback from Lars Eggert, Gorry 859 Fairhurst, and Eliot Lear, as well as discussions of the IETF TSVWG 860 WG. 862 This document was prepared using 2-Word-v2.0.template.dot. 864 Authors' Addresses 866 Joe Touch 867 USC/ISI 868 4676 Admiralty Way 869 Marina del Rey, CA 90292-6695 870 U.S.A. 872 Phone: +1 (310) 448-9151 873 EMail: touch@isi.edu