7. 服务名称和传输协议端口号注册表管理原则 (Principles for Service Name and Transport Protocol Port Number Registry Management)

服务名称和传输协议端口号注册表的管理程序包括根据请求分配服务名称和端口号，以及管理有关现有分配的信息。后者包括维护有关分配的联系人和描述信息、撤销已放弃的分配以及在需要时重新定义分配。

在这些程序中，谨慎的端口号分配最为关键，以便继续保护剩余的端口号。如前所述，目前只有大约 9% 的用户端口空间被分配。当前的分配速率大约为每年 400 个端口，并且在过去 8 年中保持稳定。以这种速度，如果继续进行类似的保护，这个资源将维持另外 85 年的分配——而无需诉诸重新分配已释放的值或撤销。

可用于服务名称的命名空间要大得多，这允许更简单的管理程序。

7.1. 过去的原则 (Past Principles)

服务名称和端口号管理的原则基于 IANA"专家评审"团队的建议。直到最近，该团队遵循一套基于先前分配请求的审查经验而开发的非正式指南。这些原始指南虽然是非正式的，但从未公开记录。它们在此仅为历史目的记录；当前指南在第 7.2 节中描述。

这些指南以前是：

• 当请求任一协议时，TCP 和 UDP 端口同时分配
• 端口号是主要分配；服务名称仅是信息性的，没有明确定义的语法
• 端口号被非正式地保护，有时不一致（例如，即使不严格必要，一些服务也被分配了许多端口号的范围）
• SCTP 和 DCCP 服务名称和端口号注册表与 TCP/UDP 注册表分开管理
• 在旧的端口注册表中，服务名称不能在不同时分配关联端口号的情况下分配

7.2. 更新的原则 (Updated Principles)

本节总结了 IANA 处理服务名称和传输协议端口号注册表以及尝试保护端口号空间的当前原则。此描述旨在告知申请服务名称和端口号的申请人。

IANA 在处理分配请求时具有超越这些原则的灵活性；其他因素可能会发挥作用，并且可以做出例外以最好地满足互联网的需求。申请人应该知道 IANA 的决定不必受这些原则的约束。

这些原则和关于端口使用的一般用户建议预计会随时间而变化。

IANA 努力在简单的"先到先得"政策 [RFC5226] 下分配不请求关联端口号分配的服务名称。IANA 可以自行决定将服务名称请求提交给"专家评审"，在大量分配请求或其他 IANA 认为"专家评审"可取的情况下 [RFC5226]；使用"专家评审"有助于在使用"IETF 评审"或"IESG 批准"的情况下非正式地向 IANA 提供建议，就像大多数 IETF 协议一样。

服务名称和端口号注册表管理的基本原则是尽可能保护端口空间的使用。支持更大端口号空间的扩展将需要改变当前互联网的许多核心协议，这种方式不会向后兼容，并且会干扰当前和旧应用程序。

保护端口号空间是必需的，因为该空间是有限的资源，因此应用程序在可行的情况下应参与流量解复用过程。端口号应编码尽可能少的信息，仍然能够使应用程序自己执行进一步的解复用。

特别是，这些原则形成了 IANA 努力为新应用程序实现的目标（在适当的情况下有例外，特别是对于旧服务的扩展），如下所示：

• IANA 努力为每个服务或应用程序仅分配一个分配的端口号。注意：在撰写本文档时，关于何时适合为协议的不安全版本使用第二个端口，尚无 IETF 共识。

• IANA 努力为服务的所有变体（例如，用于服务的更新版本）仅分配一个分配的端口号。

• IANA 努力鼓励部署安全协议。

• IANA 努力为使用或参与同一服务的所有不同类型的设备仅分配一个分配的端口号。

• IANA 努力仅为分配请求中明确指定的传输协议分配端口号。

• IANA 可以通过新的取消分配、撤销和转移程序恢复未使用的端口号。

在可能的情况下，给定的服务应在必要时解复用消息。例如，应用程序和协议应包括带内版本信息，以便应用程序或协议的未来版本可以共享相同的分配端口。应用程序和协议还应能够有效地使用单个分配的端口进行多个会话，无论是通过在一个端口内解复用多个流，还是通过使用分配的端口来协调使用动态端口进行后续交换（例如，按照 FTP [RFC0959] 的精神）。

端口以各种方式使用，特别是：

• 作为端点进程标识符
• 作为应用协议标识符
• 用于防火墙过滤目的

进程标识符和协议标识符的使用都表明，单个进程可以解复用的任何内容，或者可以编码为单个协议的任何内容，都应该如此。防火墙过滤的使用表明，一些可以复用或编码的使用可能会被分开，以便于防火墙管理。

请注意，后一种使用不太可靠，因为端口号仅对连接中涉及的两个端点有意义，并且根据观察到的端口号对生成给定流的服务得出结论并不总是可靠的。

从本文档发布起，IANA 将开始仅为分配请求中明确包含的那些传输协议分配端口号。这结束了长期以来的做法，即即使请求仅针对其中一个传输协议，也会自动为应用程序同时分配 TCP 和 UDP 的端口号。

新的分配程序通过仅为应用程序实际使用的那些传输协议（TCP、UDP、SCTP 和/或 DCCP）分配端口号来保护资源。端口号将在其他传输协议的端口号注册表中标记为保留——而不是已分配。

当应用程序开始支持使用其中一些额外的传输协议时，分配的受让人必须请求 IANA 将这些保留端口转换为分配。应用程序不得假设它可以将分配给它用于一种传输协议的端口号用于另一种传输协议，除非 IANA 将保留转换为分配。

当端口范围中的未分配号码可用池已用完时，IANA 将需要考虑将保留端口用于分配。这是不自动为除请求的协议之外的传输协议分配端口的动机的一部分。这将允许在那时有更多的端口可用于分配。

为了帮助保护端口，应用程序开发者应该仅请求分配他们的应用程序当前使用的那些传输协议。

通过允许先前分配的端口号通过取消分配或撤销变为未分配，以及通过允许应用程序设计者将已分配但未使用的端口号转移到新应用程序的程序，改善了端口号的保护。第 8 节描述了这些直到现在未记录的程序。

通过建议不需要分配端口的应用程序应该仅注册服务名称而不关联端口号，也改善了端口号的保护。