Internet Engineering Task Force (IETF) M. Cotton
Request for Comments: 6335 ICANN
BCP: 165 L. Eggert
Updates: 2780, 2782, 3828, 4340, 4960, 5595 Nokia
Category: Best Current Practice J. Touch
ISSN: 2070-1721 USC/ISI
M. Westerlund
Ericsson
S. Cheshire
Apple
August 2011
Internet Engineering Task Force (IETF) M. Cotton
Request for Comments: 6335 ICANN
BCP: 165 L. Eggert
Updates: 2780, 2782, 3828, 4340, 4960, 5595 Nokia
Category: Best Current Practice J. Touch
ISSN: 2070-1721 USC/ISI
M. Westerlund
Ericsson
S. Cheshire
Apple
August 2011
Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
Internet分配号码管理局（IANA）管理服务名称和传输协议端口号注册表的程序
Abstract
摘要
This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.
本文档定义了Internet分配号码管理局（IANA）在处理与服务名称和传输协议端口号注册表相关的分配和其他请求时使用的程序。报告还讨论了这些程序背后的理由和原则，以及它们如何促进登记处的长期可持续性。
This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered.
本文件通过废除IANA分配指南第8节和第9.1节中定义的先前UDP和TCP端口分配程序来更新IANA程序，并更新UDP Lite、数据报拥塞控制协议（DCCP）和流控制传输协议的IANA服务名称和端口分配程序（SCTP）。它还更新了DNS SRV规范，以澄清什么是服务名称以及如何注册。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6335.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6335.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Conventions Used in This Document . . . . . . . . . . . . . . 8
5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9
5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10
6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Names and Port Numbers for Experimentation . . . . 12
7. Principles for Service Name and Transport Protocol Port
Number Registry Management . . . . . . . . . . . . . . . . . . 12
7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 13
7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13
8. IANA Procedures for Managing the Service Name and
Transport Protocol Port Number Registry . . . . . . . . . . . 16
8.1. Service Name and Port Number Assignment . . . . . . . . . 16
8.2. Service Name and Port Number De-Assignment . . . . . . . . 21
8.3. Service Name and Port Number Reuse . . . . . . . . . . . . 21
8.4. Service Name and Port Number Revocation . . . . . . . . . 22
8.5. Service Name and Port Number Transfers . . . . . . . . . . 22
8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 23
8.7. Disagreements . . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 24
10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 26
10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Conventions Used in This Document . . . . . . . . . . . . . . 8
5. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Service Name Syntax . . . . . . . . . . . . . . . . . . . 9
5.2. Service Name Usage in DNS SRV Records . . . . . . . . . . 10
6. Port Number Ranges . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Names and Port Numbers for Experimentation . . . . 12
7. Principles for Service Name and Transport Protocol Port
Number Registry Management . . . . . . . . . . . . . . . . . . 12
7.1. Past Principles . . . . . . . . . . . . . . . . . . . . . 13
7.2. Updated Principles . . . . . . . . . . . . . . . . . . . . 13
8. IANA Procedures for Managing the Service Name and
Transport Protocol Port Number Registry . . . . . . . . . . . 16
8.1. Service Name and Port Number Assignment . . . . . . . . . 16
8.2. Service Name and Port Number De-Assignment . . . . . . . . 21
8.3. Service Name and Port Number Reuse . . . . . . . . . . . . 21
8.4. Service Name and Port Number Revocation . . . . . . . . . 22
8.5. Service Name and Port Number Transfers . . . . . . . . . . 22
8.6. Maintenance Issues . . . . . . . . . . . . . . . . . . . . 23
8.7. Disagreements . . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. Service Name Consistency . . . . . . . . . . . . . . . . . 24
10.2. Port Numbers for SCTP and DCCP Experimentation . . . . . . 26
10.3. Updates to DCCP Registries . . . . . . . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . . 30
For many years, the assignment of new service names and port number values for use with the Transmission Control Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) [RFC0768] has had less than clear guidelines. New transport protocols have been added -- the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342] -- and new mechanisms like DNS SRV records [RFC2782] have been developed, each with separate registries and separate guidelines. The community also recognized the need for additional procedures beyond just assignment; notably modification, revocation, and release.
多年来，传输控制协议（TCP）[RFC0793]和用户数据报协议（UDP）[RFC0768]使用的新服务名称和端口号值的分配没有明确的指导原则。添加了新的传输协议——流控制传输协议（SCTP）[RFC4960]和数据报拥塞控制协议（DCCP）[RFC4342]——并开发了DNS SRV记录[RFC2782]等新机制，每个机制都有单独的注册表和单独的指南。社区还认识到，除了分配外，还需要额外的程序；特别是修改、撤销和发布。
A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. This document brings the IANA procedures for TCP and UDP in line with those for SCTP and DCCP, resulting in a single process that requesters and IANA follow for all requests for all transport protocols, including future protocols not yet defined.
本文件中规定的程序简化的一个关键要素是为所有IETF传输协议建立相同的分配程序。本文档使TCP和UDP的IANA程序与SCTP和DCCP的程序一致，从而使请求者和IANA对所有传输协议（包括尚未定义的未来协议）的所有请求都遵循一个流程。
In addition to detailing the IANA procedures for the initial assignment of service names and port numbers, this document also specifies post-assignment procedures that until now have been handled in an ad hoc manner. These include procedures to de-assign a port number that is no longer in use, to take a port number assigned for one service that is no longer in use and reuse it for another service, and the procedure by which IANA can unilaterally revoke a prior port number assignment. Section 8 discusses the specifics of these procedures and processes that requesters and IANA follow for all requests for all current and future transport protocols.
除了详细说明初始分配服务名称和端口号的IANA程序外，本文件还规定了迄今为止以特别方式处理的分配后程序。其中包括取消分配不再使用的端口号的程序、获取为一个不再使用的服务分配的端口号并将其重新用于另一个服务的程序，以及IANA可以单方面撤销先前的端口号分配的程序。第8节讨论了请求者和IANA对所有当前和未来传输协议的所有请求所遵循的这些程序和流程的细节。
IANA is the authority for assigning service names and port numbers. The registries that are created to store these assignments are maintained by IANA. For protocols developed by IETF working groups, IANA now also offers a method for the "early assignment" [RFC4020] of service names and port numbers, as described in Section 8.1.
IANA是分配服务名称和端口号的权威机构。为存储这些分配而创建的注册表由IANA维护。对于IETF工作组开发的协议，IANA现在还提供了服务名称和端口号的“早期分配”[RFC4020]方法，如第8.1节所述。
This document updates IANA's procedures for UDP and TCP port numbers by obsoleting Sections 8 and 9.1 of the IANA Allocation Guidelines [RFC2780]. (Note that other sections of the IANA Allocation Guidelines, relating to the protocol field values in IPv4 headers, were also updated in February 2008 [RFC5237].) This document also updates the IANA assignment procedures for DCCP [RFC4340] [RFC5595] and SCTP [RFC4960].
本文件通过废除IANA分配指南[RFC2780]第8节和第9.1节，更新了IANA的UDP和TCP端口号程序。（请注意，IANA分配指南中与IPv4标头中的协议字段值相关的其他章节也于2008年2月更新[RFC5237]）。本文档还更新了DCCP[RFC4340][RFC5595]和SCTP[RFC4960]的IANA分配程序。
The Lightweight User Datagram Protocol (UDP-Lite) shares the port space with UDP. The UDP-Lite specification [RFC3828] says: "UDP-Lite uses the same set of port number values assigned by the IANA for use by UDP". An update of the UDP procedures therefore also results in a corresponding update of the UDP-Lite procedures.
轻量级用户数据报协议（UDP Lite）与UDP共享端口空间。UDP Lite规范[RFC3828]说：“UDP Lite使用IANA分配给UDP使用的同一组端口号值”。因此，UDP过程的更新也会导致UDP Lite过程的相应更新。
This document also clarifies what a service name is and how it is assigned. This will impact the DNS SRV specification [RFC2782], because that specification merely makes a brief mention that the symbolic names of services are defined in "Assigned Numbers" [RFC1700], without stating to which section it refers within that 230-page document. The DNS SRV specification may have been referring to the list of Port Assignments (known as /etc/services on Unix), or to the "Protocol And Service Names" section, or to both, or to some other section. Furthermore, "Assigned Numbers" [RFC1700] has been obsoleted [RFC3232] and has been replaced by on-line registries [PORTREG] [PROTSERVREG].
本文档还阐明了什么是服务名称以及如何分配服务名称。这将影响DNS SRV规范[RFC2782]，因为该规范仅简要提及服务的符号名称在“已分配编号”[RFC1700]中定义，而没有说明它在230页文档中引用的部分。DNS SRV规范可能引用了端口分配列表（在Unix上称为/etc/services），或者引用了“协议和服务名称”部分，或者引用了两者，或者引用了其他部分。此外，“分配号码”[RFC1700]已被淘汰[RFC3232]，并已被在线注册表[PORTREG][PROTSERVREG]取代。
The development of new transport protocols is a major effort that the IETF does not undertake very often. If a new transport protocol is standardized in the future, it is expected to follow these guidelines and practices around using service names and port numbers as much as possible, for consistency.
新传输协议的开发是IETF不经常进行的主要工作。如果一个新的传输协议在将来被标准化，那么为了保持一致性，它将尽可能多地使用服务名称和端口号，并遵循这些指导原则和实践。
At the time of writing of this document, the internal procedures of "Expert Review" teams, including that of IANA's port review team, are not documented in any RFC and this document doesn't change that.
在编写本文件时，“专家评审”小组的内部程序，包括IANA的港口评审小组的内部程序，没有记录在任何RFC中，本文件也没有改变这一点。
Information about the assignment procedures for the port registry has existed in three locations: the forms for requesting port number assignments on the IANA web site [SYSFORM] [USRFORM], an introductory text section in the file listing the port number assignments themselves (known as the port numbers registry) [PORTREG], and two brief sections of the IANA Allocation Guidelines [RFC2780].
关于端口注册分配程序的信息存在于三个位置：IANA网站[SYSFORM][USRFORM]上的请求端口号分配的表格，文件中的介绍性文本部分列出了端口号分配本身（称为端口号注册）[PORTREG]，以及IANA分配指南[RFC2780]的两个简要章节。
Similarly, the procedures surrounding service names have been historically unclear. Service names were originally created as mnemonic identifiers for port numbers without a well-defined syntax, apart from the 14-character limit mentioned on the IANA website [SYSFORM] [USRFORM]. Even that length limit has not been consistently applied, and some assigned service names are 15 characters long. When service identification via DNS SRV Resource Records (RRs) was introduced [RFC2782], it became useful to start assigning service names alone, and because IANA had no procedure for assigning a service name without an associated port number, this led
类似地，围绕服务名称的程序在历史上一直不清楚。除了IANA网站[SYSFORM][USRFORM]上提到的14个字符的限制外，服务名称最初是作为端口号的助记标识符创建的，没有定义良好的语法。甚至这个长度限制也没有得到一致的应用，一些分配的服务名称有15个字符长。当引入通过DNS SRV资源记录（RRs）进行服务识别[RFC2782]时，开始单独分配服务名称变得非常有用，并且由于IANA没有分配没有相关端口号的服务名称的程序，这导致
to the creation of an informal temporary service name registry outside of the control of IANA, which now contains roughly 500 service names [SRVREG].
创建一个不受IANA控制的非正式临时服务名称注册表，该注册表现在包含大约500个服务名称[SRVREG]。
This document aggregates all this scattered information into a single reference that aligns and clearly defines the management procedures for both service names and port numbers. It gives more detailed guidance to prospective requesters of service names and ports than the existing documentation, and it streamlines the IANA procedures for the management of the registry, so that requests can be completed in a timely manner.
本文档将所有这些分散的信息聚合到一个参考中，该参考对齐并明确定义了服务名称和端口号的管理过程。它为服务名称和端口的潜在请求者提供了比现有文件更详细的指导，并简化了IANA注册管理程序，以便能够及时完成请求。
This document defines rules for assignment of service names without associated port numbers, for such usages as DNS SRV records [RFC2782], which was not possible under the previous IANA procedures. The document also merges service name assignments from the non-IANA ad hoc registry [SRVREG] and from the IANA Protocol and Service Names registry [PROTSERVREG] into the IANA Service Name and Transport Protocol Port Number registry [PORTREG], which from here on is the single authoritative registry for service names and port numbers.
本文档定义了不带相关端口号的服务名称分配规则，用于DNS SRV记录[RFC2782]等用途，这在以前的IANA程序中是不可能的。该文件还将来自非IANA特设注册表[SRVREG]和IANA协议和服务名称注册表[PROTSERVREG]的服务名称分配合并到IANA服务名称和传输协议端口号注册表[PORTREG]，从这里开始，它是服务名称和端口号的单一权威注册表。
An additional purpose of this document is to describe the principles that guide the IETF and IANA in their role as the long-term joint stewards of the service name and port number registry. TCP and UDP have had remarkable success over the last decades. Thousands of applications and application-level protocols have service names and port numbers assigned for their use, and there is every reason to believe that this trend will continue into the future. It is hence extremely important that management of the registry follow principles that ensure its long-term usefulness as a shared resource. Section 7 discusses these principles in detail.
本文件的另一个目的是描述指导IETF和IANA作为服务名称和端口号注册处长期联合管理人的原则。TCP和UDP在过去几十年中取得了显著的成功。数以千计的应用程序和应用程序级协议都指定了服务名称和端口号供其使用，我们完全有理由相信这种趋势将在未来继续下去。因此，极其重要的是，书记官处的管理应遵循确保其作为共享资源长期有用的原则。第7节详细讨论了这些原则。
The Transmission Control Protocol (TCP) [RFC0793] and the User Datagram Protocol (UDP) [RFC0768] have enjoyed a remarkable success over the decades as the two most widely used transport protocols on the Internet. They have relied on the concept of "ports" as logical entities for Internet communication. Ports serve two purposes: first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes connect. Newer transport protocols, such as the Stream Control Transmission Protocol (SCTP) [RFC4960] and the Datagram Congestion Control Protocol (DCCP) [RFC4342], have also adopted the concept of ports for their communication sessions and use 16-bit port numbers in the same way as TCP and UDP (and UDP-Lite [RFC3828], a variant of UDP).
传输控制协议（TCP）[RFC0793]和用户数据报协议（UDP）[RFC0768]作为互联网上使用最广泛的两种传输协议，在过去几十年中取得了显著的成功。他们依靠“端口”的概念作为互联网通信的逻辑实体。端口有两个用途：第一，它们提供一个解复用标识符来区分同一对端点之间的传输会话；第二，它们还可以标识进程连接到的应用程序协议和相关服务。较新的传输协议，如流控制传输协议（SCTP）[RFC4960]和数据报拥塞控制协议（DCCP）[RFC4342]，也为其通信会话采用了端口概念，并以与TCP和UDP相同的方式使用16位端口号（以及UDP的变体UDP Lite[RFC3828]）。
Port numbers are the original and most widely used means for application and service identification on the Internet. Ports are 16-bit numbers, and the combination of source and destination port numbers together with the IP addresses of the communicating end systems uniquely identifies a session of a given transport protocol. Port numbers are also known by their associated service names such as "telnet" for port number 23 and "http" (as well as "www" and "www-http") for port number 80.
端口号是互联网上应用和服务识别的原始和最广泛使用的手段。端口是16位的数字，并且源端口号和目标端口号以及通信终端系统的IP地址的组合唯一地标识给定传输协议的会话。端口号也可以通过其相关的服务名称来识别，例如端口号23的“telnet”和端口号80的“http”（以及“www”和“www-http”）。
All involved parties -- hosts running services, hosts accessing services on other hosts, and intermediate devices (such as firewalls and NATs) that restrict services -- need to agree on which service corresponds to a particular destination port. Although this is ultimately a local decision with meaning only between the endpoints of a connection, it is common for many services to have a default port upon which those servers usually listen, when possible, and these ports are recorded by the Internet Assigned Numbers Authority (IANA) through the service name and port number registry [PORTREG].
所有相关方——运行服务的主机、访问其他主机上的服务的主机以及限制服务的中间设备（如防火墙和NAT）——都需要就哪个服务对应于特定的目标端口达成一致。尽管这最终是一个本地决定，仅在连接的端点之间有意义，但许多服务通常都有一个默认端口，在可能的情况下，这些服务器通常在该端口上侦听，并且这些端口由Internet Assigned Numbers Authority（IANA）通过服务名称和端口号注册表[PORTREG]记录.
Over time, the assumption that a particular port number necessarily implies a particular service may become less true. For example, multiple instances of the same service on the same host cannot generally listen on the same port, and multiple hosts behind the same NAT gateway cannot all have a mapping for the same port on the external side of the NAT gateway, whether using static port mappings configured by hand by the user, or dynamic port mappings configured automatically using a port mapping protocol like the NAT Port Mapping Protocol [NAT-PMP] or Internet Gateway Device [IGD].
随着时间的推移，特定端口号必然意味着特定服务的假设可能变得不那么真实。例如，同一主机上同一服务的多个实例通常不能在同一端口上侦听，同一NAT网关后面的多个主机不能在NAT网关的外部都有同一端口的映射，无论是否使用用户手动配置的静态端口映射，或使用端口映射协议（如NAT端口映射协议[NAT-PMP]或Internet网关设备[IGD]）自动配置的动态端口映射。
Applications may use port numbers directly, look up port numbers based on service names via system calls such as getservbyname() on UNIX, look up port numbers by performing queries for DNS SRV records [RFC2782] [DNS-SD], or determine port numbers in a variety of other ways like the TCP Port Service Multiplexer (TCPMUX) [RFC1078].
应用程序可以直接使用端口号，通过系统调用（如UNIX上的getservbyname（））根据服务名称查找端口号，通过查询DNS SRV记录[RFC2782][DNS-SD]查找端口号，或者通过TCP端口服务多路复用器（TCPMUX）[RFC1078]等多种其他方式确定端口号。
Designers of applications and application-level protocols may apply to IANA for an assigned service name and port number for a specific application, and may -- after assignment -- assume that no other application will use that service name or port number for its communication sessions. Application designers also have the option of requesting only an assigned service name without a corresponding fixed port number if their application does not require one, such as applications that use DNS SRV records to look up port numbers dynamically at run-time. Because the port number space is finite (and therefore conservation is an important goal), the alternative of using service names instead of port numbers is RECOMMENDED whenever possible.
应用程序和应用程序级协议的设计者可以向IANA申请为特定应用程序分配的服务名称和端口号，并且在分配后，可以假设没有其他应用程序将该服务名称或端口号用于其通信会话。如果应用程序不需要固定端口号，则应用程序设计者还可以选择仅请求分配的服务名称而不请求相应的固定端口号，例如在运行时使用DNS SRV记录动态查找端口号的应用程序。由于端口号空间是有限的（因此保护是一个重要目标），因此建议尽可能使用服务名称而不是端口号。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照“RFC中用于表示要求水平的关键词”[RFC2119]中的描述进行解释。
This document uses the term "assignment" to refer to the procedure by which IANA provides service names and/or port numbers to requesting parties; other RFCs refer to this as "allocation" or "registration". This document assumes that all these terms have the same meaning, and will use terms other than "assignment" only when quoting from or referring to text in these other documents.
本文件使用术语“分配”指IANA向请求方提供服务名称和/或端口号的程序；其他RFC将其称为“分配”或“注册”。本文件假设所有这些术语具有相同的含义，仅当引用或引用这些其他文件中的文本时，才会使用“转让”以外的术语。
Service names are the unique key in the Service Name and Transport Protocol Port Number registry. This unique symbolic name for a service may also be used for other purposes, such as in DNS SRV records [RFC2782]. Within the registry, this unique key ensures that different services can be unambiguously distinguished, thus preventing name collisions and avoiding confusion about who is the Assignee for a particular entry.
服务名称是服务名称和传输协议端口号注册表中的唯一项。服务的此唯一符号名也可用于其他目的，例如在DNS SRV记录[RFC2782]中。在注册表中，此唯一键确保可以明确区分不同的服务，从而防止名称冲突，避免混淆特定条目的受让人。
There may be more than one service name associated with a particular transport protocol and port. There are three ways that such port number overloading can occur:
可能有多个服务名称与特定传输协议和端口关联。有三种方式可以发生此类端口号过载：
o Overloading occurs when one service is an extension of another service, and an in-band mechanism exists for determining if the extension is present or not. One example is port 3478, which has the service name aliases "stun" and "turn". Traversal Using Relays around NAT (TURN) [RFC5766] is an extension to the Session Traversal Utilities for NAT (STUN) [RFC5389] service. TURN-enabled clients wishing to locate TURN servers could attempt to discover "stun" services and then check in-band if the server also supports TURN, but this would be inefficient. Enabling them to directly query for "turn" servers by name is a better approach. (Note that TURN servers in this case should also be locatable via a "stun" discovery, because every TURN server is also a STUN server.)
o 当一个服务是另一个服务的扩展，并且存在带内机制来确定扩展是否存在时，就会发生重载。一个例子是端口3478，它的服务名称别名为“stun”和“turn”。使用NAT（TURN）周围的中继进行遍历[RFC5766]是NAT（STUN）[RFC5389]服务会话遍历实用程序的扩展。希望定位TURN服务器的启用TURN的客户端可以尝试发现“stun”服务，然后检查带内服务器是否也支持TURN，但这将是低效的。让他们能够直接按名称查询“turn”服务器是一种更好的方法。（注意，在这种情况下，回合服务器也应该通过“stun”发现进行定位，因为每个回合服务器也是一个stun服务器。）
o By historical accident, the service name "http" has two synonyms "www" and "www-http". When used in SRV records [RFC2782] and similar service discovery mechanisms, only the service name "http" should be used, not these additional names. If a server were to advertise "www", it would not be discovered by clients browsing for "http". Advertising or browsing for the aliases as well as
o 由于历史的偶然，服务名称“http”有两个同义词“www”和“www-http”。在SRV记录[RFC2782]和类似的服务发现机制中使用时，只应使用服务名称“http”，而不应使用这些附加名称。如果服务器要发布“www”，则浏览“http”的客户端不会发现它。广告或浏览别名以及
the primary service name is inefficient, and achieves nothing that is not already achieved by using the service name "http" exclusively.
主服务名称效率低下，并且无法实现通过独占使用服务名称“http”尚未实现的任何功能。
o As indicated in this document in Section 10.1, overloading has been used to create replacement names that are consistent with the syntax this document prescribes for legacy names that do not conform to this syntax already. For such cases, only the new name should be used in SRV records, to avoid the same issues as with historical cases of multiple names, and also because the legacy names are incompatible with SRV record use.
o 如本文件第10.1节所述，重载用于创建替换名称，替换名称与本文件为已不符合此语法的旧名称规定的语法一致。在这种情况下，SRV记录中只应使用新名称，以避免与多个名称的历史案例相同的问题，并且还因为旧名称与SRV记录的使用不兼容。
Assignment requests for new names for existing registered services will be rejected, as a result. Implementers are requested to inform IANA if they discover other cases where a single service has multiple names, so that one name may be recorded as the primary name for service discovery purposes.
因此，现有注册服务的新名称分配请求将被拒绝。如果发现单个服务具有多个名称的其他情况，则要求实施者通知IANA，以便将一个名称记录为服务发现的主要名称。
Service names are assigned on a "first come, first served" basis, as described in Section 8.1. Names should be brief and informative, avoiding words or abbreviations that are redundant in the context of the registry (e.g., "port", "service", "protocol", etc.) Names referring to discovery services, e.g., using multicast or broadcast to identify endpoints capable of a given service, SHOULD use an easily identifiable suffix (e.g., "-disc").
如第8.1节所述，按照“先到先得”的原则分配服务名称。名称应简短且信息丰富，避免在注册表上下文中出现冗余的单词或缩写（例如，“端口”、“服务”、“协议”等）。涉及发现服务的名称（例如，使用多播或广播来标识能够提供给定服务的端点）应使用易于识别的后缀（例如“-disc”）。
Valid service names are hereby normatively defined as follows:
有效服务名称的规范定义如下：
o MUST be at least 1 character and no more than 15 characters long
o 必须至少为1个字符且长度不超过15个字符
o MUST contain only US-ASCII [ANSI.X3.4-1986] letters 'A' - 'Z' and 'a' - 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45)
o 必须仅包含US-ASCII[ANSI.X3.4-1986]字母“A”-“Z”和“A”-“Z”、数字“0”-“9”和连字符（“-”、ASCII 0x2D或十进制45）
o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z')
o 必须至少包含一个字母（'A'-'Z'或'A'-'Z'）
o MUST NOT begin or end with a hyphen
o 不能以连字符开头或结尾
o hyphens MUST NOT be adjacent to other hyphens
o 连字符不能与其他连字符相邻
The reason for requiring at least one letter is to avoid service names like "23" (could be confused with a numeric port) or "6000- 6063" (could be confused with a numeric port range). Although service names may contain both upper-case and lower-case letters, case is ignored for comparison purposes, so both "http" and "HTTP" denote the same service.
需要至少一个字母的原因是为了避免服务名称，如“23”（可能与数字端口混淆）或“6000-6063”（可能与数字端口范围混淆）。尽管服务名称可能包含大写和小写字母，但出于比较目的，大小写被忽略，因此“http”和“http”都表示相同的服务。
Service names are purely opaque identifiers, and no semantics are implied by any superficial structure that a given service name may appear to have. For example, a company called "Example" may choose to register service names "Example-Foo" and "Example-Bar" for its "Foo" and "Bar" products, but the "Example" company cannot claim to "own" all service names beginning with "Example-"; they cannot prevent someone else from registering "Example-Baz" for a different service, and they cannot prevent other developers from using the "Example-Foo" and "Example-Bar" service types in order to interoperate with the "Foo" and "Bar" products. Technically speaking, in service discovery protocols, service names are merely a series of byte values on the wire; for the mnemonic convenience of human developers, it can be convenient to interpret those byte values as human-readable ASCII characters, but software should treat them as purely opaque identifiers and not attempt to parse them for any additional embedded meaning.
服务名称是纯粹不透明的标识符，给定服务名称可能具有的任何表面结构都不会隐含任何语义。例如，一家名为“example”的公司可能会选择为其“Foo”和“Bar”产品注册服务名称“example Foo”和“example Bar”，但“example”公司不能声称“拥有”所有以“example-”开头的服务名称；它们不能阻止其他人为不同的服务注册“Example Baz”，也不能阻止其他开发人员使用“Example Foo”和“Example Bar”服务类型来与“Foo”和“Bar”产品进行互操作。从技术上讲，在服务发现协议中，服务名称只是线路上的一系列字节值；为了便于开发人员记忆，可以方便地将这些字节值解释为人类可读的ASCII字符，但软件应将它们视为纯粹不透明的标识符，而不尝试解析它们以获得任何附加的嵌入含义。
As of August 5, 2009, approximately 98% of the so-called "Short Names" [SYSFORM] [USRFORM] for existing port number assignments [PORTREG] already met the rules for legal service names stated in Section 8.1, and hence for these services their service name is exactly the same as their historical "Short Name". In approximately 2% of cases, the new "service name" is derived based on the old "Short Name" as described below in Section 10.1.
截至2009年8月5日，现有端口号分配[PORTREG]中约98%的所谓“短名称”[SYSFORM][USRFORM]已符合第8.1节中规定的法律服务名称规则，因此这些服务的服务名称与其历史“短名称”完全相同。在大约2%的情况下，新的“服务名称”是根据第10.1节中所述的旧“短名称”派生的。
The rules for valid service names, excepting the limit of 15 characters maximum, are also expressed below (as a non-normative convenience) using ABNF [RFC5234].
以下使用ABNF[RFC5234]表达了有效服务名称的规则（最多15个字符的限制除外）（作为非规范性方便）。
SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM)
ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9
HYPHEN = %x2D ; "-"
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234]
DIGIT = %x30-39 ; 0-9 [RFC5234]
SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM)
ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9
HYPHEN = %x2D ; "-"
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234]
DIGIT = %x30-39 ; 0-9 [RFC5234]
The DNS SRV specification [RFC2782] states that the Service Label part of the owner name of a DNS SRV record includes a "Service" element, described as "the symbolic name of the desired service", but as discussed above, it is not clear precisely what this means.
DNS SRV规范[RFC2782]指出，DNS SRV记录的所有者名称的服务标签部分包括“服务”元素，描述为“所需服务的符号名称”，但如上所述，尚不清楚这到底意味着什么。
This document clarifies that the Service Label MUST be a service name as defined herein with an underscore prepended. The service name SHOULD be registered with IANA and recorded in the Service Name and Transport Protocol Port Number registry [PORTREG].
本文档澄清了服务标签必须是本文定义的服务名称，并带有下划线。服务名称应向IANA注册，并记录在服务名称和传输协议端口号注册表[PORTREG]中。
The details of using Service Names in SRV Service Labels are specified in the DNS SRV specification [RFC2782].
DNS SRV规范[RFC2782]中规定了在SRV服务标签中使用服务名称的详细信息。
TCP, UDP, UDP-Lite, SCTP, and DCCP use 16-bit namespaces for their port number registries. The port registries for all of these transport protocols are subdivided into three ranges of numbers [RFC1340], and Section 8.1.2 describes the IANA procedures for each range in detail:
TCP、UDP、UDP Lite、SCTP和DCCP使用16位名称空间作为其端口号注册表。所有这些传输协议的端口注册被细分为三个编号范围[RFC1340]，第8.1.2节详细描述了每个范围的IANA程序：
o the System Ports, also known as the Well Known Ports, from 0-1023 (assigned by IANA)
o 系统端口，也称为已知端口，从0-1023（由IANA分配）
o the User Ports, also known as the Registered Ports, from 1024- 49151 (assigned by IANA)
o 用户端口，也称为注册端口，从1024到49151（由IANA分配）
o the Dynamic Ports, also known as the Private or Ephemeral Ports, from 49152-65535 (never assigned)
o 动态端口，也称为专用或临时端口，来自49152-65535（从未分配）
Of the assignable port ranges (System Ports and User Ports, i.e., port numbers 0-49151), individual port numbers are in one of three states at any given time:
在可分配的端口范围（系统端口和用户端口，即端口号0-49151）中，单个端口号在任何给定时间处于三种状态之一：
o Assigned: Assigned port numbers are currently assigned to the service indicated in the registry.
o 已分配：已分配的端口号当前分配给注册表中指示的服务。
o Unassigned: Unassigned port numbers are currently available for assignment upon request, as per the procedures outlined in this document.
o 未分配：根据本文档中概述的程序，当前可根据请求分配未分配的端口号。
o Reserved: Reserved port numbers are not available for regular assignment; they are "assigned to IANA" for special purposes. Reserved port numbers include values at the edges of each range, e.g., 0, 1023, 1024, etc., which may be used to extend these ranges or the overall port number space in the future.
o 预留：预留端口号不可用于常规分配；它们被“分配给IANA”用于特殊目的。保留端口号包括每个范围边缘的值，例如，0、1023、1024等，这些值可用于在将来扩展这些范围或整个端口号空间。
In order to keep the size of the registry manageable, IANA typically only records the Assigned and Reserved service names and port numbers in the registry. Unassigned values are typically not explicitly listed. (There are very many Unassigned service names and enumerating them all would not be practical.)
为了保持注册表的可管理性，IANA通常只在注册表中记录分配和保留的服务名称和端口号。未指定的值通常不会显式列出。（有很多未分配的服务名称，将它们全部枚举是不切实际的。）
As a data point, when this document was written, approximately 76% of the TCP and UDP System Ports were assigned, and approximately 9% of the User Ports were assigned. (As noted, Dynamic Ports are never assigned.)
作为数据点，在编写本文档时，大约76%的TCP和UDP系统端口已分配，大约9%的用户端口已分配。（如前所述，从不分配动态端口。）
Of the System Ports, two TCP and UDP port numbers (1021 and 1022), together with their respective service names ("exp1" and "exp2"), have been assigned for experimentation with new applications and application-layer protocols that require a port number in the assigned ports range [RFC4727].
在系统端口中，分配了两个TCP和UDP端口号（1021和1022）及其各自的服务名称（“exp1”和“exp2”），用于试验新的应用程序和应用层协议，这些应用程序和应用层协议要求在分配的端口范围内提供端口号[RFC4727]。
Please refer to Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] for how these experimental port numbers are to be used.
有关如何使用这些实验端口号，请参阅“分配被认为有用的实验和测试编号”[RFC3692]的第1节和第1.1节。
This document assigns the same two service names and port numbers for experimentation with new application-layer protocols over SCTP and DCCP in Section 10.2.
本文档指定了相同的两个服务名称和端口号，以便在第10.2节中通过SCTP和DCCP试验新的应用层协议。
Unfortunately, it can be difficult to limit access to these ports. Users SHOULD take measures to ensure that experimental ports are connecting to the intended process. For example, users of these experimental ports might include a 64-bit nonce, once on each segment of a message-oriented channel (e.g., UDP), or once at the beginning of a byte-stream (e.g., TCP), which is used to confirm that the port is being used as intended. Such confirmation of intended use is especially important when these ports are associated with privileged (e.g., system or administrator) processes.
不幸的是，很难限制对这些端口的访问。用户应采取措施确保实验端口连接到预期流程。例如，这些实验端口的用户可能包括64位nonce，一次在面向消息的通道（例如UDP）的每个段上，或者一次在字节流（例如TCP）的开头，用于确认端口正在按预期使用。当这些端口与特权（如系统或管理员）进程关联时，对预期用途的确认尤为重要。
7. Principles for Service Name and Transport Protocol Port Number Registry Management
7. 服务名称和传输协议端口号注册表管理原则
Management procedures for the Service Name and Transport Protocol Port Number registry include assignment of service names and port numbers upon request, as well as management of information about existing assignments. The latter includes maintaining contact and description information about assignments, revoking abandoned assignments, and redefining assignments when needed. Of these procedures, careful port number assignment is most critical, in order to continue to conserve the remaining port numbers.
服务名称和传输协议端口号注册表的管理程序包括根据请求分配服务名称和端口号，以及管理有关现有分配的信息。后者包括维护有关工作分配的联系人和描述信息、撤销放弃的工作分配以及在需要时重新定义工作分配。在这些过程中，仔细分配端口号是最关键的，以便继续保留剩余的端口号。
As noted earlier, only about 9% of the User Port space is currently assigned. The current rate of assignment is approximately 400 ports per year, and has remained steady for the past 8 years. At that rate, if similar conservation continues, this resource will sustain another 85 years of assignment - without the need to resort to reassignment of released values or revocation. The namespace available for service names is much larger, which allows for simpler management procedures.
如前所述，当前仅分配了约9%的用户端口空间。目前的分配率约为每年400个港口，在过去8年中一直保持稳定。按照这个速度，如果类似的保护继续下去，这一资源将再维持85年的分配——而无需重新分配释放的价值或撤销。可用于服务名称的命名空间要大得多，这允许更简单的管理过程。
The principles for service name and port number management are based on the recommendations of the IANA "Expert Review" team. Until recently, that team followed a set of informal guidelines developed based on the review experience from previous assignment requests. These original guidelines, although informal, had never been publicly documented. They are recorded here for historical purposes only; the current guidelines are described in Section 7.2. These guidelines previously were:
服务名称和端口号管理原则基于IANA“专家评审”小组的建议。直到最近，该团队还遵循了一套非正式的指导原则，这些指导原则是根据以前任务请求的审查经验制定的。这些最初的指导方针虽然是非正式的，但从未公开记录。这些记录仅用于历史目的；第7.2节描述了当前指南。这些准则以前是：
o TCP and UDP ports were simultaneously assigned when either was requested
o TCP和UDP端口在请求时同时分配
o Port numbers were the primary assignment; service names were informative only, and did not have a well-defined syntax
o 港口编号是主要的任务；服务名称仅提供信息，没有定义良好的语法
o Port numbers were conserved informally, and sometimes inconsistently (e.g., some services were assigned ranges of many port numbers even where not strictly necessary)
o 端口号非正式保存，有时不一致（例如，一些服务被分配了许多端口号的范围，即使在没有严格必要的情况下）
o SCTP and DCCP service name and port number registries were managed separately from the TCP/UDP registries
o SCTP和DCCP服务名称和端口号注册表与TCP/UDP注册表分开管理
o Service names could not be assigned in the old ports registry without assigning an associated port number at the same time
o 如果不同时分配关联的端口号，则无法在旧端口注册表中分配服务名称
This section summarizes the current principles by which IANA both handles the Service Name and Transport Protocol Port Number registry and attempts to conserve the port number space. This description is intended to inform applicants requesting service names and port numbers. IANA has flexibility beyond these principles when handling assignment requests; other factors may come into play, and exceptions may be made to best serve the needs of the Internet. Applicants should be aware that IANA decisions are not required to be bound to these principles. These principles and general advice to users on port use are expected to change over time.
本节总结了IANA处理服务名称和传输协议端口号注册表并试图节省端口号空间的当前原则。本说明旨在通知申请服务名称和端口号的申请人。IANA在处理任务请求时具有超出这些原则的灵活性；其他因素可能会起作用，例外情况可能会最好地满足互联网的需求。申请人应意识到IANA的决定不受这些原则的约束。预计这些原则和向用户提供的关于港口使用的一般建议将随着时间的推移而改变。
IANA strives to assign service names that do not request an associated port number assignment under a simple "First Come First Served" policy [RFC5226]. IANA MAY, at its discretion, refer service name requests to "Expert Review" in cases of mass assignment requests or other situations where IANA believes "Expert Review" is advisable [RFC5226]; use of the "Expert Review" helps advise IANA informally in cases where "IETF Review" or "IESG Approval" is used, as with most IETF protocols.
IANA努力按照简单的“先到先得”策略分配不请求关联端口号分配的服务名称[RFC5226]。IANA可自行决定，在批量分配请求或IANA认为“专家评审”可取的其他情况下，将服务名称请求提交给“专家评审”[RFC5226]；在使用“IETF审查”或“IESG批准”的情况下，使用“专家审查”有助于非正式地向IANA提供建议，就像大多数IETF协议一样。
The basic principle of service name and port number registry management is to conserve use of the port space where possible. Extensions to support larger port number spaces would require changing many core protocols of the current Internet in a way that would not be backward compatible and interfere with both current and legacy applications.
服务名称和端口号注册表管理的基本原则是尽可能节省端口空间的使用。扩展以支持更大的端口号空间将需要以一种不会向后兼容并干扰当前和遗留应用程序的方式更改当前Internet的许多核心协议。
Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little information as possible that will still enable an application to perform further demultiplexing by itself. In particular, the principles form a goal that IANA strives to achieve for new applications (with exceptions as deemed appropriate, especially as for extensions to legacy services) as follows:
需要保护端口号空间，因为该空间是有限的资源，因此在可行的情况下，应用程序应参与流量解复用过程。端口号被期望编码尽可能少的信息，这仍将使应用程序能够自己执行进一步的解复用。特别是，这些原则构成了IANA为新应用程序（视情况而定的例外情况，尤其是对遗留服务的扩展）努力实现的目标，如下所示：
o IANA strives to assign only one assigned port number per service or application.
o IANA力求为每个服务或应用程序只分配一个分配的端口号。
Note: At the time of writing of this document, there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol.
注：在编写本文件时，IETF并未就何时适合将第二个端口用于协议的不安全版本达成一致意见。
o IANA strives to assign only one assigned port number for all variants of a service (e.g., for updated versions of a service).
o IANA努力为服务的所有变体（例如，服务的更新版本）只分配一个分配的端口号。
o IANA strives to encourage the deployment of secure protocols.
o IANA努力鼓励部署安全协议。
o IANA strives to assign only one assigned port number for all different types of devices using or participating in the same service.
o IANA努力只为使用或参与同一服务的所有不同类型的设备分配一个分配的端口号。
o IANA strives to assign port numbers only for the transport protocol(s) explicitly named in an assignment request.
o IANA努力只为分配请求中明确指定的传输协议分配端口号。
o IANA may recover unused port numbers, via the new procedures of de-assignment, revocation, and transfer.
o IANA可以通过取消分配、撤销和传输的新程序恢复未使用的端口号。
Where possible, a given service is expected to demultiplex messages if necessary. For example, applications and protocols are expected to include in-band version information, so that future versions of the application or protocol can share the same assigned port. Applications and protocols are also expected to be able to efficiently use a single assigned port for multiple sessions, either by demultiplexing multiple streams within one port or by using the assigned port to coordinate using dynamic ports for subsequent exchanges (e.g., in the spirit of FTP [RFC0959]).
在可能的情况下，一个给定的服务在必要时被期望解复用消息。例如，应用程序和协议应包括带内版本信息，以便应用程序或协议的未来版本可以共享相同的分配端口。通过在一个端口内解复用多个流，或者通过使用分配的端口为后续交换协调使用动态端口（例如，本着FTP[RFC0959]的精神），应用程序和协议还应能够有效地将单个分配的端口用于多个会话。
Ports are used in various ways, notably:
端口的使用方式多种多样，尤其是：
o as endpoint process identifiers
o 作为端点进程标识符
o as application protocol identifiers
o 作为应用程序协议标识符
o for firewall-filtering purposes
o 用于防火墙过滤目的
Both the process-identifier and the protocol-identifier uses suggest that anything a single process can demultiplex, or that can be encoded into a single protocol, should be. The firewall-filtering use suggests that some uses that could be multiplexed or encoded could instead be separated to allow for easier firewall management. Note that this latter use is much less sound, because port numbers have meaning only for the two endpoints involved in a connection, and drawing conclusions about the service that generated a given flow based on observed port numbers is not always reliable.
进程标识符和协议标识符的使用都表明，单个进程可以解复用的任何内容，或者可以编码到单个协议中的任何内容，都应该被删除。防火墙过滤的使用表明，一些可以复用或编码的使用可以被分离，以便于防火墙管理。请注意，后一种用法不太合理，因为端口号仅对连接中涉及的两个端点有意义，并且根据观察到的端口号得出关于生成给定流的服务的结论并不总是可靠的。
Effective with the publication of this document, IANA will begin assigning port numbers for only those transport protocols explicitly included in an assignment request. This ends the long-standing practice of automatically assigning a port number to an application for both TCP and UDP, even if the request is for only one of these transport protocols. The new assignment procedure conserves resources by assigning a port number to an application for only those transport protocols (TCP, UDP, SCTP, and/or DCCP) it actually uses. The port number will be marked as Reserved -- instead of Assigned -- in the port number registries of the other transport protocols. When applications start supporting the use of some of those additional transport protocols, the Assignee for the assignment MUST request that IANA convert these reserved ports into assignments. An application MUST NOT assume that it can use a port number assigned to it for use with one transport protocol with another transport protocol without IANA converting the reservation into an assignment.
本文件发布后生效，IANA将开始仅为分配请求中明确包含的传输协议分配端口号。这结束了长期以来自动为TCP和UDP应用程序分配端口号的做法，即使请求仅针对其中一种传输协议。新的分配过程通过只为应用程序实际使用的传输协议（TCP、UDP、SCTP和/或DCCP）分配端口号来节省资源。在其他传输协议的端口号注册表中，端口号将标记为保留（而不是分配）。当应用程序开始支持使用某些附加传输协议时，分配的受让人必须请求IANA将这些保留端口转换为分配。应用程序不得假设在IANA未将保留转换为分配的情况下，它可以将分配给它的端口号用于一个传输协议和另一个传输协议。
When the available pool of unassigned numbers has run out in a port range, it will be necessary for IANA to consider the Reserved ports for assignment. This is part of the motivation for not automatically assigning ports for transport protocols other than the requested one(s). This will allow more ports to be available for assignment at that point. To help conserve ports, application developers SHOULD request assignment of only those transport protocols that their application currently uses.
当可用的未分配号码池在端口范围内用完时，IANA必须考虑保留端口进行分配。这是不自动为除请求的传输协议以外的传输协议分配端口的动机的一部分。这将允许在该点分配更多端口。为了帮助节省端口，应用程序开发人员应该只请求分配其应用程序当前使用的那些传输协议。
Conservation of port numbers is improved by procedures that allow previously assigned port numbers to become Unassigned, either through de-assignment or through revocation, and by a procedure that lets application designers transfer an assigned but unused port number to
通过允许以前分配的端口号通过取消分配或撤销而变为未分配的过程，以及允许应用程序设计人员将已分配但未使用的端口号传输到服务器的过程，可以改进端口号的保护
a new application. Section 8 describes these procedures, which until now were undocumented. Port number conservation is also improved by recommending that applications that do not require an assigned port should register only a service name without an associated port number.
一个新的应用程序。第8节描述了这些程序，这些程序到目前为止都没有记录在案。通过建议不需要指定端口的应用程序只注册服务名称，而不注册相关的端口号，端口号保护也得到了改进。
8. IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry
8. IANA管理服务名称和传输协议端口号注册表的过程
This section describes the process for handling requests associated with IANA's management of the Service Name and Transport Protocol Port Number registry. Such requests include initial assignment, de-assignment, reuse, and updates to the contact information or description associated with an assignment. Revocation is an additional process, initiated by IANA.
本节描述处理与IANA管理服务名称和传输协议端口号注册表相关的请求的过程。此类请求包括初始分配、取消分配、重用和更新与分配相关的联系信息或描述。撤销是由IANA发起的附加过程。
Assignment refers to the process of providing service names or port numbers to applicants. All such assignments are made from service names or port numbers that are Unassigned or Reserved at the time of the assignment.
分配是指向申请人提供服务名称或端口号的过程。所有此类分配都是根据分配时未分配或保留的服务名称或端口号进行的。
o Unassigned names and numbers are assigned according to the rules described in Section 8.1.2 below.
o 未分配的名称和编号根据下文第8.1.2节所述规则进行分配。
o Reserved numbers and names are generally only assigned by a "Standards Action" or "IESG Approval", and MUST be accompanied by a statement explaining the reason a Reserved number or name is appropriate for this action. The only exception to this rule is that the current Assignee of a port number MAY request the assignment of the corresponding Reserved port number for other transport protocols when needed. IANA will initiate an "Expert Review" [RFC5226] for such requests.
o 保留编号和名称通常仅由“标准行动”或“IESG批准”指定，并且必须随附一份声明，解释保留编号或名称适用于该行动的原因。此规则的唯一例外是，端口号的当前受让人可在需要时请求为其他传输协议分配相应的保留端口号。IANA将对此类请求发起“专家评审”[RFC5226]。
When an assignment for one or more transport protocols is approved, the port number for any non-requested transport protocol(s) will be marked as Reserved. IANA SHOULD NOT assign that port number to any other application or service until no other port numbers remain Unassigned in the requested range. It is anticipated that at such time a new document will be published specifying IANA procedures for assignment of such ports.
当一个或多个传输协议的分配获得批准时，任何未请求的传输协议的端口号都将标记为保留。IANA不应将该端口号分配给任何其他应用程序或服务，除非在请求的范围内没有其他未分配的端口号。预计届时将发布一份新文件，详细说明IANA分配此类港口的程序。
A service name or port number assignment request contains the following information. The service name is the unique identifier of a given service:
服务名称或端口号分配请求包含以下信息。服务名称是给定服务的唯一标识符：
Service Name (REQUIRED) Transport Protocol(s) (REQUIRED) Assignee (REQUIRED) Contact (REQUIRED) Description (REQUIRED) Reference (REQUIRED) Port Number (OPTIONAL) Service Code (REQUIRED for DCCP only) Known Unauthorized Uses (OPTIONAL) Assignment Notes (OPTIONAL)
服务名称（必需）传输协议（必需）受让人（必需）联系人（必需）说明（必需）参考（必需）端口号（可选）服务代码（仅DCCP必需）已知未授权使用（可选）分配说明（可选）
o Service Name: A desired unique service name for the service associated with the assignment request MUST be provided. This name may be used with various service selection and discovery mechanisms (including, but not limited to, DNS SRV records [RFC2782]). The name MUST be compliant with the syntax defined in Section 5.1. In order to be unique, they MUST NOT be identical to any currently assigned service name in the IANA registry [PORTREG]. Service names are case-insensitive; they may be provided and entered into the registry with mixed case for clarity, but case is ignored otherwise.
o 服务名称：必须为与分配请求关联的服务提供所需的唯一服务名称。此名称可用于各种服务选择和发现机制（包括但不限于DNS SRV记录[RFC2782]）。名称必须符合第5.1节中定义的语法。为了唯一，它们不能与IANA注册表[PORTREG]中当前分配的任何服务名称相同。服务名称不区分大小写；为清楚起见，可提供这些文件并将其输入注册表，但在其他情况下，则忽略该文件。
o Transport Protocol(s): The transport protocol(s) for which an assignment is requested MUST be provided. This field is currently limited to one or more of TCP, UDP, SCTP, and DCCP. Requests without any port assignment and only a service name are still required to indicate which protocol the service uses.
o 传输协议：必须提供请求分配的传输协议。此字段当前仅限于TCP、UDP、SCTP和DCCP中的一个或多个。仍然需要没有任何端口分配且只有服务名称的请求来指示服务使用的协议。
o Assignee: Name and email address of the party to whom the assignment is made. This is REQUIRED. The Assignee is the organization, company or individual person responsible for the initial assignment. For assignments done through RFCs published via the "IETF Document Stream" [RFC4844], the Assignee will be the IESG <iesg@ietf.org>.
o 受让人：接受转让一方的姓名和电子邮件地址。这是必需的。受让人是指负责初始转让的组织、公司或个人。对于通过“IETF文件流”[RFC4844]发布的RFC完成的任务，受让人将是IESG<iesg@ietf.org>.
o Contact: Name and email address of the Contact person for the assignment. This is REQUIRED. The Contact person is the responsible person for the Internet community to send questions to. This person is also authorized to submit changes on behalf of the Assignee; in cases of conflict between the Assignee and the Contact, the Assignee decisions take precedence. Additional
o 联系人：任务联系人的姓名和电子邮件地址。这是必需的。联系人是向互联网社区发送问题的负责人。该人员也有权代表受让人提交变更；如果受让人与联系人之间存在冲突，则以受让人的决定为准。附加的
address information MAY be provided. For assignments done through RFCs published via the "IETF Document Stream" [RFC4844], the Contact will be the IETF Chair <chair@ietf.org>.
可以提供地址信息。对于通过“IETF文件流”[RFC4844]发布的RFC完成的任务，联系人将是IETF主席<chair@ietf.org>.
o Description: A short description of the service associated with the assignment request is REQUIRED. It should avoid all but the most well-known acronyms.
o 描述：需要与分配请求关联的服务的简短描述。它应该避免使用除最著名的首字母缩略词以外的所有词。
o Reference: A description of (or a reference to a document describing) the protocol or application using this port. This is REQUIRED. The description must state whether the protocol uses IP-layer broadcast, multicast, or anycast communication.
o 引用：对使用此端口的协议或应用程序的描述（或对文档的引用）。这是必需的。说明必须说明协议是否使用IP层广播、多播或选播通信。
For assignments requesting only a Service Name, or a Service Name and User Port, a statement that the protocol is proprietary and not publicly documented is also acceptable, provided that the required information regarding the use of IP broadcast, multicast, or anycast is given.
对于仅要求服务名称或服务名称和用户端口的分配，也可接受协议为专有且未公开记录的声明，前提是提供了有关IP广播、多播或选播使用的必要信息。
For any assignment request that includes a User Port, the assignment request MUST explain why a port number in the Dynamic Ports range (discovered by clients dynamically at run-time) is unsuitable for the given application.
对于包含用户端口的任何分配请求，分配请求必须解释动态端口范围（由客户端在运行时动态发现）中的端口号不适合给定应用程序的原因。
For any assignment request that includes a System Port, the assignment request MUST explain why a port number in the User Ports or Dynamic Ports ranges is unsuitable, and a reference to a stable protocol specification document MUST be provided.
对于包含系统端口的任何分配请求，分配请求必须解释为什么用户端口或动态端口范围中的端口号不合适，并且必须提供对稳定协议规范文档的参考。
IANA MAY accept early assignment [RFC4020] requests (known as "early allocation" therein) from IETF working groups that reference a sufficiently stable Internet-Draft instead of a published Standards-Track RFC.
IANA可接受IETF工作组提出的提前分配[RFC4020]请求（其中称为“提前分配”），该工作组参考的是足够稳定的互联网草案，而不是已发布的标准跟踪RFC。
o Port Number: If assignment of a port number is desired, either the port number the requester suggests for assignment or indication of port range (user or system) MUST be provided. If only a service name is to be assigned, this field is left empty. If a specific port number is requested, IANA is encouraged to assign the requested number. If a range is specified, IANA will choose a suitable number from the User or System Ports ranges. Note that the applicant MUST NOT use the requested port in implementations deployed for use on the public Internet prior to the completion of the assignment, because there is no guarantee that IANA will assign the requested port.
o 端口号：如果需要分配端口号，则必须提供请求者建议分配的端口号或端口范围指示（用户或系统）。如果只分配服务名称，则此字段保留为空。如果请求特定的端口号，建议IANA分配请求的端口号。如果指定了一个范围，IANA将从用户或系统端口范围中选择一个合适的数字。请注意，申请人不得在分配完成之前在部署用于公共互联网的实现中使用请求的端口，因为无法保证IANA将分配请求的端口。
o Service Code: If the assignment request includes DCCP as a transport protocol, then the request MUST include a desired unique DCCP service code [RFC5595], and MUST NOT include a requested DCCP service code otherwise. Section 19.8 of the DCCP specification [RFC4340] defines requirements and rules for assignment, updated by this document. Note that, as per the DCCP Service Codes document [RFC5595], some service codes are not assigned; zero (absence of a meaningful service code) and 4294967295 (0xFFFFFFFF; invalid service code) are permanently reserved, and the Private service codes 1056964608-1073741823 (0x3F000000-0x3FFFFFFF; i.e., 32-bit values with the high-order byte equal to a value of 63 (0x3F), corresponding to the ASCII character '?') are not centrally assigned.
o 服务代码：如果分配请求包括DCCP作为传输协议，则请求必须包括所需的唯一DCCP服务代码[RFC5595]，否则不得包括所请求的DCCP服务代码。DCCP规范[RFC4340]第19.8节定义了本文件更新的分配要求和规则。注意，根据DCCP服务代码文件[RFC5595]，一些服务代码未分配；零（没有有意义的服务代码）和4294967295（0xFFFFFF；无效的服务代码）被永久保留，并且私有服务代码1056964608-1073741823（0x3F000000-0x3FFFFFFF；即，高阶字节等于63（0x3F）的32位值，对应于ASCII字符“？”）没有集中分配。
o Known Unauthorized Uses: A list of uses by applications or organizations who are not the Assignee. This is OPTIONAL. This list may be augmented by IANA after assignment when unauthorized uses are reported.
o 已知未授权使用：非受让人的应用程序或组织的使用列表。这是可选的。当报告未经授权的使用时，IANA可在分配后增加此列表。
o Assignment Notes: Indications of owner/name change, or any other assignment process issue. This is OPTIONAL. This list may be updated by IANA after assignment to help track changes to an assignment, e.g., de-assignment, owner/name changes, etc.
o 转让说明：业主/名称变更的迹象，或任何其他转让过程问题。这是可选的。IANA可在分配后更新此列表，以帮助跟踪分配的更改，例如取消分配、所有者/姓名更改等。
If the assignment request is for the addition of a new transport protocol to a previously assigned service name and the requester is not the Assignee or Contact for the previously assigned service name, IANA needs to confirm with the Assignee for the existing assignment whether this addition is appropriate.
如果分配请求是为了向先前分配的服务名称添加新的传输协议，而请求者不是先前分配的服务名称的受让人或联系人，IANA需要与现有分配的受让人确认此添加是否合适。
If the assignment request is for a new service name sharing the same port as a previously assigned service name (see port number overloading in Section 5), IANA needs to confirm with the Assignee for the existing service name and other appropriate experts whether the overloading is appropriate.
如果分配请求的新服务名称与先前分配的服务名称共享同一端口（参见第5节中的端口号重载），IANA需要与现有服务名称的受让人和其他相关专家确认重载是否合适。
When IANA receives an assignment request -- containing the above information -- that is requesting a port number, IANA SHALL initiate an "Expert Review" [RFC5226] in order to determine whether an assignment should be made. For requests that are not seeking a port number, IANA SHOULD assign the service name under a simple "First Come First Served" policy [RFC5226].
当IANA收到请求端口号的分配请求（包含上述信息）时，IANA应启动“专家评审”[RFC5226]，以确定是否应进行分配。对于不寻求端口号的请求，IANA应根据简单的“先到先得”策略[RFC5226]分配服务名称。
Section 6 describes the different port number ranges. It is important to note that IANA applies slightly different procedures when managing the different port ranges of the service name and port number registry:
第6节描述了不同的端口号范围。需要注意的是，IANA在管理服务名称和端口号注册表的不同端口范围时应用的程序略有不同：
o Ports in the Dynamic Ports range (49152-65535) have been specifically set aside for local and dynamic use and cannot be assigned through IANA. Application software may simply use any dynamic port that is available on the local host, without any sort of assignment. On the other hand, application software MUST NOT assume that a specific port number in the Dynamic Ports range will always be available for communication at all times, and a port number in that range hence MUST NOT be used as a service identifier.
o 动态端口范围（49152-65535）中的端口已专门预留供本地和动态使用，不能通过IANA分配。应用软件可以简单地使用本地主机上可用的任何动态端口，而无需任何类型的分配。另一方面，应用软件不得假设动态端口范围内的特定端口号始终可用于通信，因此该范围内的端口号不得用作服务标识符。
o Ports in the User Ports range (1024-49151) are available for assignment through IANA, and MAY be used as service identifiers upon successful assignment. Because assigning a port number for a specific application consumes a fraction of the shared resource that is the port number registry, IANA will require the requester to document the intended use of the port number. For most IETF protocols, ports in the User Ports range will be assigned under the "IETF Review" or "IESG Approval" procedures [RFC5226] and no further documentation is required. Where these procedures do not apply, then the requester must input the documentation to the "Expert Review" procedure [RFC5226], by which IANA will have a technical expert review the request to determine whether to grant the assignment. Regardless of the path ("IETF Review", "IESG Approval", or "Expert Review"), the submitted documentation is expected to be the same, as described in this section, and MUST explain why using a port number in the Dynamic Ports range is unsuitable for the given application. Further, IANA MAY utilize the "Expert Review" process informally to inform their position in participating in "IETF Review" and "IESG Approval".
o 用户端口范围（1024-49151）中的端口可通过IANA进行分配，并可在成功分配后用作服务标识符。由于为特定应用程序分配端口号会消耗端口号注册表共享资源的一小部分，因此IANA将要求请求者记录端口号的预期用途。对于大多数IETF协议，用户端口范围内的端口将根据“IETF审查”或“IESG批准”程序[RFC5226]分配，无需进一步的文档。如果这些程序不适用，则请求者必须将文件输入“专家评审”程序[RFC5226]，IANA将通过该程序对请求进行技术专家评审，以确定是否授予该任务。无论路径（“IETF审查”、“IESG批准”或“专家审查”）如何，提交的文档应与本节所述的相同，并且必须解释为什么在动态端口范围内使用端口号不适合给定应用。此外，IANA可以非正式地利用“专家评审”流程，告知其参与“IETF评审”和“IESG批准”的立场。
o Ports in the System Ports range (0-1023) are also available for assignment through IANA. Because the System Ports range is both the smallest and the most densely assigned, the requirements for new assignments are more strict than those for the User Ports range, and will only be granted under the "IETF Review" or "IESG Approval" procedures [RFC5226]. A request for a System Port number MUST document *both* why using a port number from the Dynamic Ports range is unsuitable *and* why using a port number from the User Ports range is unsuitable for that application.
o 系统端口范围（0-1023）中的端口也可通过IANA分配。由于系统端口范围是最小且分配最密集的，因此新分配的要求比用户端口范围的要求更严格，并且仅在“IETF审查”或“IESG批准”程序下授予[RFC5226]。对系统端口号的请求必须记录*为什么使用动态端口范围中的端口号不合适*以及*为什么使用用户端口范围中的端口号不适合该应用程序。
The Assignee of a granted port number assignment can return the port number to IANA at any time if they no longer have a need for it. The port number will be de-assigned and will be marked as Reserved. IANA should not reassign port numbers that have been de-assigned until all unassigned port numbers in the specific range have been assigned.
被授予的端口号分配的受让人如果不再需要端口号，可以随时将端口号返回给IANA。端口号将被取消分配并标记为保留。IANA不应重新分配已取消分配的端口号，直到分配了特定范围内所有未分配的端口号。
Before proceeding with a port number de-assignment, IANA needs to reasonably establish that the value is actually no longer in use.
在继续进行端口号取消分配之前，IANA需要合理地确定该值实际上已不再使用。
Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that a given service name remain assigned even after all associated port number assignments have become de-assigned. Under this policy, it will appear in the registry as if it had been created through a service name assignment request that did not include any port numbers.
由于与端口号空间相比，耗尽服务名称空间的危险要小得多，因此建议即使在所有相关的端口号分配都已取消分配之后，仍保留指定的服务名称。在此策略下，它将显示在注册表中，就好像它是通过不包含任何端口号的服务名称分配请求创建的一样。
On rare occasions, it may still be useful to de-assign a service name. In such cases, IANA will mark the service name as Reserved. IANA will involve their IESG-appointed expert in such cases.
在极少数情况下，取消分配服务名称可能仍然有用。在这种情况下，IANA会将服务名称标记为保留名称。IANA将在此类情况下让IESG指定的专家参与。
IANA will include a comment in the registry when de-assignment happens to indicate its historic usage.
当取消分配时，IANA将在注册表中包含注释，以指示其历史用途。
If the Assignee of a granted port number assignment no longer has a need for the assigned number, but would like to reuse it for a different application, they can submit a request to IANA to do so.
如果授予的端口号分配的受让人不再需要分配的端口号，但希望将其重新用于不同的应用程序，他们可以向IANA提交请求。
Logically, port number reuse is to be thought of as a de-assignment (Section 8.2) followed by an immediate (re-)assignment (Section 8.1) of the same port number for a new application. Consequently, the information that needs to be provided about the proposed new use of the port number is identical to what would need to be provided for a new port number assignment for the specific ports range.
从逻辑上讲，端口号重用被认为是一种取消分配（第8.2节），然后立即（重新）分配（第8.1节）新应用程序的相同端口号。因此，需要提供的关于端口号拟议新用途的信息与需要为特定端口范围的新端口号分配提供的信息相同。
Because there is much less danger of exhausting the service name space compared to the port number space, it is RECOMMENDED that the original service name associated with the prior use of the port number remains assigned, and a new service name be created and associated with the port number. This is again consistent with viewing a reuse request as a de-assignment followed by an immediate (re-)assignment. Reusing an assigned service name for a different application is NOT RECOMMENDED.
由于与端口号空间相比，耗尽服务名称空间的危险要小得多，因此建议保留与先前使用的端口号关联的原始服务名称，并创建新的服务名称并与端口号关联。这与将重用请求视为取消分配，然后立即（重新）分配是一致的。不建议为其他应用程序重用分配的服务名称。
IANA needs to carefully review such requests before approving them. In some instances, the Expert Reviewer will determine that the application the port number was assigned to has found usage beyond the original Assignee, or that there is a concern that it may have such users. This determination MUST be made quickly. A community call concerning revocation of a port number (see below) MAY be considered, if a broader use of the port number is suspected.
IANA需要在批准这些请求之前仔细审查这些请求。在某些情况下，专家评审员将确定分配端口号的应用程序发现其使用超出了原始受让人的范围，或者存在可能有此类用户的担忧。必须迅速作出这一决定。如果怀疑某个端口号的使用范围更广，则可以考虑有关撤销该端口号（见下文）的社区电话。
A port number revocation can be thought of as an IANA-initiated de-assignment (Section 8.2), and has exactly the same effect on the registry.
端口号撤销可以被视为IANA发起的取消分配（第8.2节），并且对注册表具有完全相同的效果。
Sometimes, it will be clear that a specific port number is no longer in use and that IANA can revoke it and mark it as Reserved. At other times, it may be unclear whether a given assigned port number is still in use somewhere in the Internet. In those cases, IANA must carefully consider the consequences of revoking the port number, and SHOULD only do so if there is an overwhelming need.
有时，很明显，某个特定的端口号不再使用，IANA可以撤销该端口号并将其标记为保留端口号。在其他情况下，可能不清楚指定的端口号是否仍在Internet的某个位置使用。在这些情况下，IANA必须仔细考虑撤销端口号的后果，并且只有在有压倒性需求时才应该这样做。
With the help of their IESG-appointed Expert Reviewer, IANA SHALL formulate a request to the IESG to issue a four-week community call concerning the pending port number revocation. The IESG and IANA, with the Expert Reviewer's support, SHALL determine promptly after the end of the community call whether revocation should proceed, and then communicate their decision to the community. This procedure typically involves similar steps to de-assignment except that it is initiated by IANA.
在IESG指定的专家评审员的帮助下，IANA应向IESG提出请求，就待撤销的端口号发出为期四周的社区电话。IESG和IANA应在专家评审员的支持下，在社区呼叫结束后立即确定是否应继续撤销，然后将其决定传达给社区。除IANA发起外，该程序通常包括与取消分配类似的步骤。
Because there is much less danger of exhausting the service name space compared to the port number space, revoking service names is NOT RECOMMENDED.
因为与端口号空间相比，耗尽服务名称空间的危险要小得多，所以不建议撤消服务名称。
The value of service names and port numbers is defined by their careful management as a shared Internet resource, whereas enabling transfer allows the potential for associated monetary exchanges. As a result, the IETF does not permit service name or port number assignments to be transferred between parties, even when they are mutually consenting.
服务名称和端口号的价值是由其作为共享互联网资源的谨慎管理定义的，而启用转移允许进行相关的货币交换。因此，IETF不允许在双方之间传输服务名称或端口号分配，即使双方同意。
The appropriate alternate procedure is a coordinated de-assignment and assignment: The new party requests the service name or port number via an assignment and the previous party releases its assignment via the de-assignment procedure outlined above.
适当的替代程序是协调的取消分配和分配：新的一方通过分配请求服务名称或端口号，前一方通过上述取消分配程序释放其分配。
With the help of their IESG-appointed Expert Reviewer, IANA SHALL carefully determine if there is a valid technical, operational, or managerial reason to grant the requested new assignment.
在IESG指定的专家评审员的帮助下，IANA应仔细确定是否有有效的技术、操作或管理理由批准所请求的新任务。
In addition to the formal procedures described above, updates to the Description and Contact information are coordinated by IANA in an informal manner, and may be initiated by either the Assignee or by IANA, e.g., by the latter requesting an update to current Contact information. (Note that the Assignee cannot be changed as a separate procedure; see instead Section 8.5 above.)
除上述正式程序外，描述和联系信息的更新由IANA以非正式方式协调，并可由受让人或IANA发起，例如，由后者请求更新当前联系信息。（请注意，受让人不能作为单独的程序进行变更；请参见上文第8.5节。）
In the case of disagreements around any request, there is the possibility of appeal following the normal appeals process for IANA assignments as defined by Section 7 of "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226].
如果对任何请求存在分歧，则有可能按照“RFCs中IANA考虑事项编写指南”第7节规定的IANA分配正常上诉程序进行上诉[RFC5226]。
The IANA guidelines described in this document do not change the security properties of UDP, TCP, SCTP, or DCCP.
本文档中描述的IANA指南不会更改UDP、TCP、SCTP或DCCP的安全属性。
Assignment of a service name or port number does not in any way imply an endorsement of an application or product, and the fact that network traffic is flowing to or from an assigned port number does not mean that it is "good" traffic, or even that it is used by the assigned service. Firewall and system administrators should choose how to configure their systems based on their knowledge of the traffic in question, not based on whether or not there is an assigned service name or port number.
服务名称或端口号的分配绝不意味着对应用程序或产品的认可，网络流量流入或流出分配的端口号并不意味着它是“良好”流量，甚至不意味着它被分配的服务使用。防火墙和系统管理员应该根据他们对相关流量的了解来选择如何配置他们的系统，而不是根据是否有分配的服务名称或端口号。
Services are expected to include support for security, either as default or dynamically negotiated in-band. The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services.
服务预计将包括对安全性的支持，无论是默认的还是带内动态协商的。应避免对同一服务的安全和不安全变体使用单独的服务名称或端口号分配，以阻止部署不安全的服务。
This document obsoletes Sections 8 and 9.1 of the March 2000 IANA Allocation Guidelines [RFC2780].
本文件废除了2000年3月IANA分配指南[RFC2780]第8节和第9.1节。
Upon approval of this document for publication as an RFC, IANA worked with Stuart Cheshire, maintainer of the independent service name registry [SRVREG], to merge the contents of that private registry into the official IANA registry. The independent registry web page has been updated with pointers to the IANA registry and to this RFC.
在批准将本文件作为RFC发布后，IANA与独立服务名称注册中心[SRVREG]的维护者Stuart Cheshire合作，将该私人注册中心的内容合并到IANA官方注册中心。独立注册表网页已更新，其中包含指向IANA注册表和此RFC的指针。
IANA created a new service name entry in the service name and port number registry [PORTREG] for all entries in the Protocol and Service Names registry [PROTSERVREG] that did not already have one assigned.
IANA在服务名称和端口号注册表[PORTREG]中为协议和服务名称注册表[PROTSERVREG]中尚未分配的所有条目创建了一个新的服务名称条目。
IANA also indicates in the Assignment Notes for "www" and "www-http" that they are duplicate terms that refer to the "http" service, and should not be used for discovery purposes. For this conceptual service (human-readable web pages served over HTTP), the correct service name to use for service discovery purposes is "http" (see Section 5).
IANA还在“www”和“www-http”的分配说明中指出，它们是指“http”服务的重复术语，不应用于查找目的。对于这个概念性服务（通过HTTP提供的人类可读网页），用于服务发现目的的正确服务名称是“HTTP”（参见第5节）。
Section 8.1 defines which character strings are well-formed service names, which until now had not been clearly defined. The definition in Section 8.1 was chosen to allow maximum compatibility of service names with current and future service discovery mechanisms.
第8.1节定义了哪些字符串是格式良好的服务名称，到目前为止还没有明确定义。选择第8.1节中的定义是为了最大限度地使服务名称与当前和未来的服务发现机制兼容。
As of August 5, 2009, approximately 98% of the so-called "Short Names" from existing port number assignments [PORTREG] met the rules for legal service names stated in Section 8.1, and hence for these services their service name is exactly the same as their "Short Name".
截至2009年8月5日，现有端口号分配[PORTREG]中约98%的所谓“短名称”符合第8.1节中规定的法律服务名称规则，因此这些服务的服务名称与其“短名称”完全相同。
The remaining approximately 2% of the existing "Short Names" are not suitable to be used directly as well-formed service names because they contain illegal characters such as asterisks, dots, pluses, slashes, or underscores. All existing "Short Names" conform to the length requirement of 15 characters or fewer. For these 96 unsuitable "Short Names", listed in the table below, the service name is the Short Name with any illegal characters replaced by hyphens. IANA added an entry to the registry that uses the new well-formed primary service name for the existing service and that otherwise duplicates the original assignment information. In the description field of this new entry giving the primary service name, IANA recorded that it has assigned a well-formed service name for the previous service and references the original assignment. In the
其余约2%的现有“短名称”不适合直接用作格式良好的服务名称，因为它们包含非法字符，如星号、点、加号、斜线或下划线。所有现有的“短名称”都符合15个字符或更少的长度要求。对于下表中列出的96个不合适的“短名称”，服务名称是短名称，任何非法字符都用连字符替换。IANA向注册表中添加了一个条目，该条目为现有服务使用新的格式良好的主服务名称，否则会复制原始分配信息。在这个提供主要服务名称的新条目的描述字段中，IANA记录它已为以前的服务分配了格式良好的服务名称，并引用了原始分配。在
Assignment Notes field of the original assignment, IANA added a note that this entry is an alias to the new well-formed service name, and that the old service name is historic, not usable for use with many common service discovery mechanisms.
在原始分配的“分配注释”字段中，IANA添加了一条注释，说明此条目是新格式良好的服务名称的别名，并且旧的服务名称是历史性的，不能用于许多常见的服务发现机制。
96 names containing illegal characters to be replaced by hyphens:
96个包含要用连字符替换的非法字符的名称：
+----------------+-----------------+-----------------+
| 914c/g | acmaint_dbd | acmaint_transd |
| atex_elmd | avanti_cdp | badm_priv |
| badm_pub | bdir_priv | bdir_pub |
| bmc_ctd_ldap | bmc_patroldb | boks_clntd |
| boks_servc | boks_servm | broker_service |
| bues_service | canit_store | cedros_fds |
| cl/1 | contamac_icm | corel_vncadmin |
| csc_proxy | cvc_hostd | dbcontrol_agent |
| dec_dlm | dl_agent | documentum_s |
| dsmeter_iatc | dsx_monitor | elpro_tunnel |
| elvin_client | elvin_server | encrypted_admin |
| erunbook_agent | erunbook_server | esri_sde |
| EtherNet/IP-1 | EtherNet/IP-2 | event_listener |
| flr_agent | gds_db | ibm_wrless_lan |
| iceedcp_rx | iceedcp_tx | iclcnet_svinfo |
| idig_mux | ife_icorp | instl_bootc |
| instl_boots | intel_rci | interhdl_elmd |
| lan900_remote | LiebDevMgmt_A | LiebDevMgmt_C |
| LiebDevMgmt_DM | mapper-ws_ethd | matrix_vnet |
| mdbs_daemon | menandmice_noh | msl_lmd |
| nburn_id | ncr_ccl | nds_sso |
| netmap_lm | nms_topo_serv | notify_srvr |
| novell-lu6.2 | nuts_bootp | nuts_dem |
| ocs_amu | ocs_cmu | pipe_server |
| pra_elmd | printer_agent | redstorm_diag |
| redstorm_find | redstorm_info | redstorm_join |
| resource_mgr | rmonitor_secure | rsvp_tunnel |
| sai_sentlm | sge_execd | sge_qmaster |
| shiva_confsrvr | sql*net | srvc_registry |
| stm_pproc | subntbcst_tftp | udt_os |
| universe_suite | veritas_pbx | vision_elmd |
| vision_server | wrs_registry | z39.50 |
+----------------+-----------------+-----------------+
+----------------+-----------------+-----------------+
| 914c/g | acmaint_dbd | acmaint_transd |
| atex_elmd | avanti_cdp | badm_priv |
| badm_pub | bdir_priv | bdir_pub |
| bmc_ctd_ldap | bmc_patroldb | boks_clntd |
| boks_servc | boks_servm | broker_service |
| bues_service | canit_store | cedros_fds |
| cl/1 | contamac_icm | corel_vncadmin |
| csc_proxy | cvc_hostd | dbcontrol_agent |
| dec_dlm | dl_agent | documentum_s |
| dsmeter_iatc | dsx_monitor | elpro_tunnel |
| elvin_client | elvin_server | encrypted_admin |
| erunbook_agent | erunbook_server | esri_sde |
| EtherNet/IP-1 | EtherNet/IP-2 | event_listener |
| flr_agent | gds_db | ibm_wrless_lan |
| iceedcp_rx | iceedcp_tx | iclcnet_svinfo |
| idig_mux | ife_icorp | instl_bootc |
| instl_boots | intel_rci | interhdl_elmd |
| lan900_remote | LiebDevMgmt_A | LiebDevMgmt_C |
| LiebDevMgmt_DM | mapper-ws_ethd | matrix_vnet |
| mdbs_daemon | menandmice_noh | msl_lmd |
| nburn_id | ncr_ccl | nds_sso |
| netmap_lm | nms_topo_serv | notify_srvr |
| novell-lu6.2 | nuts_bootp | nuts_dem |
| ocs_amu | ocs_cmu | pipe_server |
| pra_elmd | printer_agent | redstorm_diag |
| redstorm_find | redstorm_info | redstorm_join |
| resource_mgr | rmonitor_secure | rsvp_tunnel |
| sai_sentlm | sge_execd | sge_qmaster |
| shiva_confsrvr | sql*net | srvc_registry |
| stm_pproc | subntbcst_tftp | udt_os |
| universe_suite | veritas_pbx | vision_elmd |
| vision_server | wrs_registry | z39.50 |
+----------------+-----------------+-----------------+
In addition to the 96 names listed above, the service name for "whois++" is "whoispp", following the example set by the "application/whoispp-query" MIME Content-Type [RFC2957].
除了上面列出的96个名称外，“whois++”的服务名称是“whoisp”，遵循“application/whoisp query”MIME内容类型[RFC2957]设置的示例。
There were four names recorded in IANA's Port Number Registry [PORTREG] that conflicted with names previously recorded in the ad hoc SRV name registry [SRVREG]: esp, hydra, recipe, and xmp.
IANA的端口号注册表[PORTREG]中记录的四个名称与之前在特设SRV名称注册表[SRVREG]中记录的名称冲突：esp、hydra、recipe和xmp。
The name conflicts were resolved amicably:
名称冲突得到友好解决：
The IANA Port Number Registry Short Name "esp" had been registered by Andrew Chernow, and he informed the authors that the port was no longer in use and the registration was no longer required. The SRV registry entry for "esp" remains in effect.
Andrew Chernow已注册IANA端口号注册短名称“esp”，他通知提交人该端口已不再使用，不再需要注册。“esp”的SRV注册表项仍然有效。
The SRV name "hydra" for SubEthaEdit had already been retired in favor of the new SRV name "see". The IANA Port Number Registry entry for "hydra" remains in effect.
SubEthaEdit的SRV名称“hydra”已经被取消，取而代之的是新的SRV名称“see”。“hydra”的IANA端口号注册表项仍然有效。
The SRV name "recipe" was in use in an open source project that had not yet been packaged for distribution, and the registrant Daniel Taylor was willing to change to a different service name. Thanks to Daniel Taylor for accommodating this change. The IANA Port Number Registry entry for "recipe" remains in effect.
SRV名称“recipe”在一个开源项目中使用，该项目尚未打包发布，注册人Daniel Taylor愿意更改为不同的服务名称。感谢Daniel Taylor适应了这一变化。“配方”的IANA端口号注册表项仍然有效。
The IANA Port Number Registry Short Name "xmp" had been registered by Bobby Krupczak, but since his registration included an assigned port number (which is still in use and remains unaffected by this change), he was willing to switch to a different service name. Thanks to Bobby Krupczak for accommodating this change. The SRV registry entry for "xmp" remains in effect.
IANA端口号注册表短名称“xmp”已由Bobby Krupczak注册，但由于他的注册包括一个指定的端口号（该端口号仍在使用且不受此更改的影响），他愿意切换到其他服务名称。感谢鲍比·克鲁普扎克对这一变化的适应。“xmp”的SRV注册表项仍然有效。
Two System UDP and TCP ports, 1021 and 1022, have been reserved for experimental use [RFC4727]. This document assigns the same port numbers for SCTP and DCCP, updates the TCP and UDP assignments, and also instructs IANA to automatically assign these two port numbers for any future transport protocol with a similar 16-bit port number namespace.
两个系统UDP和TCP端口1021和1022已保留供实验使用[RFC4727]。本文档为SCTP和DCCP分配相同的端口号，更新TCP和UDP分配，并指示IANA为具有类似16位端口号命名空间的任何未来传输协议自动分配这两个端口号。
Note that these port numbers are meant for temporary experimentation and development in controlled environments. Before using these port numbers, carefully consider the advice in Section 6.1 in this document, as well as in Sections 1 and 1.1 of "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692]. Most importantly, application developers must request a permanent port number assignment from IANA as described in Section 8.1 before any kind of non-experimental deployment.
请注意，这些端口号用于受控环境中的临时试验和开发。在使用这些端口号之前，请仔细考虑本文档第6.1节中的建议，以及“分配被认为有用的实验和测试数字”的第1和第1.1节[RCF3692]。最重要的是，在进行任何类型的非实验性部署之前，应用程序开发人员必须按照第8.1节所述，向IANA请求永久端口号分配。
+--------------------+-----------------------------+
| Service Name | exp1 |
| Transport Protocol | DCCP, SCTP, TCP, UDP |
| Assignee | IESG <iesg@ietf.org> |
| Contact | IETF Chair <chair@ietf.org> |
| Description | RFC3692-style Experiment 1 |
| Reference | [RFC4727] [RFC6335] |
| Port Number | 1021 |
+--------------------+-----------------------------+
+--------------------+-----------------------------+
| Service Name | exp1 |
| Transport Protocol | DCCP, SCTP, TCP, UDP |
| Assignee | IESG <iesg@ietf.org> |
| Contact | IETF Chair <chair@ietf.org> |
| Description | RFC3692-style Experiment 1 |
| Reference | [RFC4727] [RFC6335] |
| Port Number | 1021 |
+--------------------+-----------------------------+
+--------------------+-----------------------------+
| Service Name | exp2 |
| Transport Protocol | DCCP, SCTP, TCP, UDP |
| Assignee | IESG <iesg@ietf.org> |
| Contact | IETF Chair <chair@ietf.org> |
| Description | RFC3692-style Experiment 2 |
| Reference | [RFC4727] [RFC6335] |
| Port Number | 1022 |
+--------------------+-----------------------------+
+--------------------+-----------------------------+
| Service Name | exp2 |
| Transport Protocol | DCCP, SCTP, TCP, UDP |
| Assignee | IESG <iesg@ietf.org> |
| Contact | IETF Chair <chair@ietf.org> |
| Description | RFC3692-style Experiment 2 |
| Reference | [RFC4727] [RFC6335] |
| Port Number | 1022 |
+--------------------+-----------------------------+
This document updates the IANA assignment procedures for the DCCP Port Number and DCCP Service Codes Registries [RFC4340].
本文档更新了DCCP端口号和DCCP服务代码注册表的IANA分配程序[RFC4340]。
Service codes are assigned on a "first come, first served" basis according to Section 19.8 of the DCCP specification [RFC4340]. This document updates that section by extending the guidelines given there in the following ways:
根据DCCP规范[RFC4340]第19.8节，按照“先到先得”的原则分配服务代码。本文件通过以下方式扩展其中给出的指南来更新该部分：
o IANA MAY assign new service codes without seeking "Expert Review" using their discretion, but SHOULD seek "Expert Review" if a request asks for more than five service codes.
o IANA可自行分配新的服务代码，而无需寻求“专家评审”，但如果请求的服务代码超过五个，则应寻求“专家评审”。
o IANA should feel free to contact the DCCP Expert Reviewer with any questions related to requests for DCCP-related codepoints.
o IANA如有任何与DCCP相关代码点请求相关的问题，请随时联系DCCP专家评审员。
The DCCP ports registry is defined by Section 19.9 of the DCCP specification [RFC4340]. Assignments in this registry require prior assignment of a service code. Not all service codes require IANA-assigned ports. This document updates that section by extending the guidelines given there in the following way:
DCCP端口注册表由DCCP规范[RFC4340]第19.9节定义。此注册表中的分配要求事先分配服务代码。并非所有服务代码都需要IANA分配的端口。本文件通过以下方式扩展其中给出的指南来更新该部分：
o IANA should normally assign a value in the range 1024-49151 to a DCCP server port. IANA requests to assign port numbers in the System Ports range (0 through 1023) require an "IETF Review" [RFC5226] prior to assignment by IANA [RFC4340].
o IANA通常应将1024-49151范围内的值分配给DCCP服务器端口。IANA请求分配系统端口范围（0到1023）内的端口号时，需要在IANA分配[RFC4340]之前进行“IETF审查”[RFC5226]。
o IANA MUST NOT assign more than one DCCP server port to a single service code value.
o IANA不得将多个DCCP服务器端口分配给单个服务代码值。
o The assignment of multiple service codes to the same DCCP port is allowed, but subject to "Expert Review".
o 允许将多个服务代码分配给同一DCCP端口，但需经过“专家审查”。
o The set of service code values associated with a DCCP server port should be recorded in the service name and port number registry.
o 与DCCP服务器端口关联的服务代码值集应记录在服务名称和端口号注册表中。
o A request for additional service codes to be associated with an already assigned port number requires "Expert Review". These requests will normally be accepted when they originate from the contact associated with the port assignment. In other cases, these applications will be expected to use an unassigned port, when this is available.
o 请求与已分配的端口号关联的附加服务代码需要“专家审查”。当这些请求来自与端口分配相关的联系人时，通常会被接受。在其他情况下，这些应用程序将使用未分配的端口（如果可用）。
The DCCP specification [RFC4340] notes that a short port name MUST be associated with each DCCP server port that has been assigned. This document clarifies that this short port name is the service name as defined here, and this name MUST be unique.
DCCP规范[RFC4340]指出，短端口名必须与分配的每个DCCP服务器端口相关联。本文档说明此短端口名是此处定义的服务名称，并且此名称必须是唯一的。
Alfred Hoenes (ah@tr-sys.de) and Allison Mankin (mankin@psg.com) have contributed text and ideas to this document.
阿尔弗雷德·霍恩斯(ah@tr-sys.de）和Allison Mankin(mankin@psg.com)为本文件提供了文本和想法。
The text in Section 10.3 is based on a suggestion originally proposed as a part of the DCCP Service Codes document [RFC5595] by Gorry Fairhurst.
第10.3节中的文本基于Gorry Fairhurst最初作为DCCP服务代码文件[RFC5595]的一部分提出的建议。
Lars Eggert is partly funded by the Trilogy Project [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program.
拉尔斯·艾格特（Lars Eggert）的部分资金来自三部曲项目（Trilogy Project）[Trilogy]，这是一个由欧盟委员会根据其第七个框架计划支持的研究项目。
[ANSI.X3.4-1986] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ANSI.X3.4-1986]美国国家标准协会，“编码字符集-信息交换用7位美国标准代码”，ANSI X3.41986。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，2000年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP Lite）”，RFC 38282004年7月。
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC4020]Kompella，K.和A.Zinin，“早期IANA标准轨道代码点分配”，BCP 100，RFC 4020，2005年2月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
[RFC5595]Fairhurst，G.“数据报拥塞控制协议（DCCP）服务代码”，RFC5952009年9月。
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, February 2011.
[DNS-SD]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，正在进行的工作，2011年2月。
[IGD] UPnP Forum, "Internet Gateway Device (IGD) V 1.0", November 2001.
[IGD]UPnP论坛，“互联网网关设备（IGD）v1.0”，2001年11月。
[NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP]柴郡，S.，“NAT端口映射协议（NAT-PMP）”，正在进行的工作，2008年4月。
[PORTREG] Internet Assigned Numbers Authority (IANA), "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/port-numbers>.
[PORTREG]互联网分配号码管理局（IANA），“服务名称和传输协议端口号注册表”<http://www.iana.org/assignments/port-numbers>.
[PROTSERVREG] Internet Assigned Numbers Authority (IANA), "Protocol and Service Names Registry", <http://www.iana.org/assignments/service-names>.
[PROTSERVREG]互联网分配号码管理局（IANA），“协议和服务名称注册表”<http://www.iana.org/assignments/service-names>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", RFC 1078, November 1988.
[RFC1078]洛托，M.，“TCP端口服务多路复用器（TCPMUX）”，RFC1078，1988年11月。
[RFC1340] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340, July 1992.
[RFC1340]Reynolds，J.和J.Postel，“分配的数字”，RFC1340，1992年7月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，RFC1700，1994年10月。
[RFC2957] Daigle, L. and P. Faltstrom, "The application/ whoispp-query Content-Type", RFC 2957, October 2000.
[RFC2957]Daigle，L.和P.Faltstrom，“应用程序/WHOISP查询内容类型”，RFC 2957，2000年10月。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]Reynolds，J.，“分配号码：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342]Floyd，S.，Kohler，E.，和J.Padhye，“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”，RFC 43422006年3月。
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4844]Daigle，L.和互联网架构委员会，“RFC系列和RFC编辑器”，RFC 48442007年7月。
[RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the Protocol Field", BCP 37, RFC 5237, February 2008.
[RFC5237]Arkko，J.和S.Bradner，“协议领域的IANA分配指南”，BCP 37，RFC 5237，2008年2月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，2010年4月。
[SRVREG] "DNS SRV Service Types Registry", <http://www.dns-sd.org/ServiceTypes.html>.
[SRVREG]“DNS SRV服务类型注册表”<http://www.dns-sd.org/ServiceTypes.html>.
[SYSFORM] Internet Assigned Numbers Authority (IANA), "Application for System (Well Known) Port Number", <http://www.iana.org/>.
[SYSFORM]互联网分配号码管理局（IANA），“系统（知名）端口号申请”<http://www.iana.org/>.
[TRILOGY] "Trilogy Project", <http://www.trilogy-project.org/>.
[三部曲]“三部曲项目”<http://www.trilogy-project.org/>.
[USRFORM] Internet Assigned Numbers Authority (IANA), "Application for User (Registered) Port Number", <http://www.iana.org/>.
[USRFORM]互联网分配号码管理局（IANA），“用户（注册）端口号申请”<http://www.iana.org/>.
Authors' Addresses
作者地址
Michelle Cotton Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA
Michelle Cotton互联网公司，地址：美国加利福尼亚州玛丽娜·德雷市金钟路4676号330室，邮编：90292
Phone: +1 310 823 9358
EMail: michelle.cotton@icann.org
URI: http://www.iana.org/
Phone: +1 310 823 9358
EMail: michelle.cotton@icann.org
URI: http://www.iana.org/
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
芬兰诺基亚集团00045诺基亚研究中心邮政信箱407
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292 USA
Joe Touch USC/ISI 4676美国加利福尼亚州玛丽娜·德雷海军部路90292号
Phone: +1 310 448 9151
EMail: touch@isi.edu
URI: http://www.isi.edu/touch
Phone: +1 310 448 9151
EMail: touch@isi.edu
URI: http://www.isi.edu/touch
Magnus Westerlund Ericsson Farogatan 6 Stockholm 164 80 Sweden
Magnus Westerlund Ericsson Farogatan 6斯德哥尔摩16480瑞典
Phone: +46 8 719 0000
EMail: magnus.westerlund@ericsson.com
Phone: +46 8 719 0000
EMail: magnus.westerlund@ericsson.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
斯图尔特柴郡苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 3207
EMail: cheshire@apple.com
URI: http://stuartcheshire.org/
Phone: +1 408 974 3207
EMail: cheshire@apple.com
URI: http://stuartcheshire.org/