8. IANA 管理服务名称和传输协议端口号注册表的程序 (IANA Procedures for Managing the Service Name and Transport Protocol Port Number Registry)

本节描述了处理与 IANA 管理服务名称和传输协议端口号注册表相关的请求的过程。此类请求包括初始分配、取消分配、重用以及更新与分配关联的联系信息或描述。撤销是 IANA 启动的额外流程。

8.1. 服务名称和端口号分配 (Service Name and Port Number Assignment)

分配是指向申请人提供服务名称或端口号的过程。所有此类分配都是从分配时未分配或保留的服务名称或端口号中进行的。

• 未分配的名称和号码根据下面第 8.1.2 节中描述的规则分配。

• 保留的号码和名称通常只通过"标准行动"或"IESG 批准"分配，并且必须附有说明为何保留号码或名称适合此操作的声明。此规则的唯一例外是，端口号的当前受让人可以在需要时请求为其他传输协议分配相应的保留端口号。IANA 将为此类请求启动"专家评审" [RFC5226]。

当批准一个或多个传输协议的分配时，任何未请求的传输协议的端口号都将标记为保留。IANA 不应该将该端口号分配给任何其他应用程序或服务，直到请求范围内没有其他端口号保持未分配。预计在那时将发布一份新文档，指定 IANA 分配此类端口的程序。

8.1.1. 一般分配程序 (General Assignment Procedure)

服务名称或端口号分配请求包含以下信息。服务名称是给定服务的唯一标识符：

• Service Name (REQUIRED) - 服务名称（必需）
• Transport Protocol(s) (REQUIRED) - 传输协议（必需）
• Assignee (REQUIRED) - 受让人（必需）
• Contact (REQUIRED) - 联系人（必需）
• Description (REQUIRED) - 描述（必需）
• Reference (REQUIRED) - 参考（必需）
• Port Number (OPTIONAL) - 端口号（可选）
• Service Code (REQUIRED for DCCP only) - 服务代码（仅 DCCP 必需）
• Known Unauthorized Uses (OPTIONAL) - 已知未授权使用（可选）
• Assignment Notes (OPTIONAL) - 分配说明（可选）

字段说明：

Service Name (服务名称)：必须提供与分配请求关联的服务所需的唯一服务名称。此名称可与各种服务选择和发现机制一起使用（包括但不限于 DNS SRV 记录 [RFC2782]）。名称必须符合第 5.1 节中定义的语法。为了唯一，它们不得与 IANA 注册表 [PORTREG] 中任何当前分配的服务名称相同。服务名称不区分大小写；它们可以提供并以混合大小写输入注册表以提高清晰度，但否则忽略大小写。

Transport Protocol(s) (传输协议)：必须提供请求分配的传输协议。此字段当前限于 TCP、UDP、SCTP 和 DCCP 中的一个或多个。没有任何端口分配且仅有服务名称的请求仍然需要指示服务使用哪个协议。

Assignee (受让人)：分配给其的一方的名称和电子邮件地址。这是必需的。受让人是负责初始分配的组织、公司或个人。对于通过"IETF 文档流" [RFC4844] 发布的 RFC 进行的分配，受让人将是 IESG <[email protected]>。

Contact (联系人)：分配的联系人的名称和电子邮件地址。这是必需的。联系人是互联网社区发送问题的负责人。此人还有权代表受让人提交更改；在受让人和联系人之间发生冲突的情况下，受让人的决定优先。可以提供额外的地址信息。对于通过"IETF 文档流" [RFC4844] 发布的 RFC 进行的分配，联系人将是 IETF 主席 <[email protected]>。

Description (描述)：与分配请求关联的服务的简短描述是必需的。它应该避免所有但最知名的首字母缩写词。

Reference (参考)：对（或参考描述）使用此端口的协议或应用程序的文档的描述。这是必需的。描述必须说明协议是否使用 IP 层广播、多播或任播通信。

对于仅请求服务名称或服务名称和用户端口的分配，如果协议是专有的且未公开记录，则可以接受声明，前提是提供了有关使用 IP 广播、多播或任播的必需信息。

对于包括用户端口的任何分配请求，分配请求必须解释为什么动态端口范围（由客户端在运行时动态发现）中的端口号不适合给定应用程序。

对于包括系统端口的任何分配请求，分配请求必须解释为什么用户端口或动态端口范围中的端口号不适合，并且必须提供对稳定协议规范文档的参考。

IANA 可以接受 IETF 工作组的早期分配 [RFC4020] 请求（在其中称为"早期分配"），这些请求引用了足够稳定的互联网草案而不是已发布的标准跟踪 RFC。

Port Number (端口号)：如果需要分配端口号，则必须提供请求者建议分配的端口号或端口范围指示（用户或系统）。如果仅分配服务名称，则此字段留空。

如果请求特定端口号，建议 IANA 分配所请求的号码。如果指定了范围，IANA 将从用户或系统端口范围中选择合适的号码。

请注意，申请人不得在完成分配之前在部署用于公共互联网的实现中使用所请求的端口，因为不能保证 IANA 会分配所请求的端口。

Service Code (服务代码)：如果分配请求包括 DCCP 作为传输协议，则请求必须包括所需的唯一 DCCP 服务代码 [RFC5595]，并且不得包括请求的 DCCP 服务代码。DCCP 规范 [RFC4340] 第 19.8 节定义了分配的要求和规则，由本文档更新。

请注意，根据 DCCP 服务代码文档 [RFC5595]，某些服务代码未分配；零（缺少有意义的服务代码）和 4294967295 (0xFFFFFFFF；无效的服务代码）被永久保留，私有服务代码 1056964608-1073741823 (0x3F000000-0x3FFFFFFF；即，高位字节等于 63 (0x3F) 的 32 位值，对应于 ASCII 字符 '?') 不集中分配。

Known Unauthorized Uses (已知未授权使用)：不是受让人的应用程序或组织的使用列表。这是可选的。当报告未授权使用时，IANA 可以在分配后增强此列表。

Assignment Notes (分配说明)：所有者/名称更改的指示，或任何其他分配流程问题。这是可选的。IANA 可以在分配后更新此列表，以帮助跟踪分配的更改，例如，取消分配、所有者/名称更改等。

如果分配请求是为先前分配的服务名称添加新的传输协议，并且请求者不是先前分配的服务名称的受让人或联系人，IANA 需要与现有分配的受让人确认此添加是否适当。

如果分配请求是为与先前分配的服务名称共享同一端口的新服务名称（参见第 5 节中的端口号重载），IANA 需要与现有服务名称的受让人和其他适当的专家确认重载是否适当。

当 IANA 收到包含上述信息的分配请求——请求端口号时，IANA 应该启动"专家评审" [RFC5226]，以确定是否应进行分配。对于不寻求端口号的请求，IANA 应该根据简单的"先到先得"政策 [RFC5226] 分配服务名称。

8.1.2. 特定端口号范围的差异 (Variances for Specific Port Number Ranges)

第 6 节描述了不同的端口号范围。重要的是要注意，IANA 在管理服务名称和端口号注册表的不同端口范围时应用稍微不同的程序：

动态端口范围 (49152-65535)：动态端口范围中的端口已专门留出供本地和动态使用，不能通过 IANA 分配。应用软件可以简单地使用本地主机上可用的任何动态端口，无需任何形式的分配。另一方面，应用软件不得假设动态端口范围中的特定端口号将始终可用于通信，因此该范围中的端口号不得用作服务标识符。

用户端口范围 (1024-49151)：用户端口范围中的端口可通过 IANA 分配，并且在成功分配后可以用作服务标识符。由于为特定应用程序分配端口号会消耗端口号注册表这一共享资源的一部分，IANA 将要求请求者记录端口号的预期用途。

对于大多数 IETF 协议，用户端口范围中的端口将根据"IETF 评审"或"IESG 批准"程序 [RFC5226] 分配，无需进一步的文档。在这些程序不适用的情况下，请求者必须将文档输入到"专家评审"程序 [RFC5226]，IANA 将由技术专家审查请求以确定是否授予分配。

无论路径如何（"IETF 评审"、"IESG 批准"或"专家评审"），提交的文档应该是相同的，如本节所述，并且必须解释为什么使用动态端口范围中的端口号不适合给定应用程序。

此外，IANA 可以非正式地利用"专家评审"过程来告知他们在参与"IETF 评审"和"IESG 批准"中的立场。

系统端口范围 (0-1023)：系统端口范围中的端口也可通过 IANA 分配。由于系统端口范围既是最小的又是分配最密集的，新分配的要求比用户端口范围更严格，并且只会根据"IETF 评审"或"IESG 批准"程序 [RFC5226] 授予。

系统端口号的请求必须记录为什么使用动态端口范围中的端口号不适合以及为什么使用用户端口范围中的端口号不适合该应用程序。

8.2. 服务名称和端口号取消分配 (Service Name and Port Number De-Assignment)

已授予端口号分配的受让人可以在不再需要时随时将端口号返回给 IANA。端口号将被取消分配并将标记为保留。

IANA 不应重新分配已取消分配的端口号，直到特定范围内的所有未分配端口号都已分配。

在继续进行端口号取消分配之前，IANA 需要合理地确定该值实际上不再使用。

由于与端口号空间相比，服务名称空间耗尽的危险要小得多，建议即使在所有关联的端口号分配都已取消分配之后，给定的服务名称仍保持分配。根据此政策，它将在注册表中显示，就好像它是通过不包括任何端口号的服务名称分配请求创建的一样。

在极少数情况下，取消分配服务名称可能仍然有用。在这种情况下，IANA 将标记服务名称为保留。IANA 将在这种情况下让他们的 IESG 任命的专家参与。

IANA 将在取消分配发生时在注册表中包含注释以指示其历史使用。

8.3. 服务名称和端口号重用 (Service Name and Port Number Reuse)

如果已授予端口号分配的受让人不再需要分配的号码，但希望将其重用于不同的应用程序，他们可以向 IANA 提交请求。

逻辑上，端口号重用被认为是取消分配（第 8.2 节），然后是同一端口号用于新应用程序的立即（重新）分配（第 8.1 节）。因此，需要提供有关端口号的拟议新用途的信息与为特定端口范围的新端口号分配需要提供的信息相同。

由于与端口号空间相比，服务名称空间耗尽的危险要小得多，建议与端口号的先前使用关联的原始服务名称保持分配，并创建新的服务名称并与端口号关联。这再次与将重用请求视为取消分配后立即（重新）分配一致。

不建议为不同的应用程序重用已分配的服务名称。

IANA 需要在批准之前仔细审查此类请求。在某些情况下，专家审查员将确定分配端口号的应用程序已在原始受让人之外找到使用，或者担心它可能有此类用户。此确定必须迅速做出。如果怀疑端口号的更广泛使用，可以考虑关于撤销端口号的社区呼吁（见下文）。

8.4. 服务名称和端口号撤销 (Service Name and Port Number Revocation)

端口号撤销可以被认为是 IANA 启动的取消分配（第 8.2 节），并且对注册表具有完全相同的影响。

有时，很明显特定端口号不再使用，IANA 可以撤销它并将其标记为保留。在其他时候，可能不清楚给定的已分配端口号是否仍在互联网的某处使用。在这些情况下，IANA 必须仔细考虑撤销端口号的后果，并且应该仅在有压倒性需要时才这样做。

在他们的 IESG 任命的专家审查员的帮助下，IANA 应该向 IESG 制定请求，发出关于待定端口号撤销的四周社区呼吁。IESG 和 IANA，在专家审查员的支持下，应该在社区呼吁结束后迅速确定是否应继续撤销，然后将他们的决定传达给社区。

此程序通常涉及与取消分配类似的步骤，除了它由 IANA 启动。

由于与端口号空间相比，服务名称空间耗尽的危险要小得多，不建议撤销服务名称。

8.5. 服务名称和端口号转移 (Service Name and Port Number Transfers)

服务名称和端口号的价值由它们作为共享互联网资源的仔细管理定义，而启用转移允许相关货币交换的潜力。因此，IETF 不允许服务名称或端口号分配在各方之间转移，即使他们是相互同意的。

适当的替代程序是协调的取消分配和分配：新方通过分配请求服务名称或端口号，先前方通过上述取消分配程序释放其分配。

在他们的 IESG 任命的专家审查员的帮助下，IANA 应该仔细确定是否有有效的技术、操作或管理原因授予所请求的新分配。

8.6. 维护问题 (Maintenance Issues)

除了上述正式程序外，对描述和联系信息的更新由 IANA 以非正式方式协调，并且可以由受让人或 IANA 启动，例如，后者请求更新当前联系信息。

（请注意，受让人不能作为单独的程序更改；请参见上面的第 8.5 节。）

8.7. 争议 (Disagreements)

在围绕任何请求的争议的情况下，可以按照"在 RFC 中编写 IANA 考虑部分的指南" [RFC5226] 第 7 节定义的 IANA 分配的正常上诉程序进行上诉。