Skip to main content

10. IANA 考虑 (IANA Considerations)

本文档淘汰了 2000 年 3 月的 IANA 分配指南 [RFC2780] 的第 8 节和第 9.1 节。

在本文档被批准发布为 RFC 后,IANA 与独立服务名称注册表 [SRVREG] 的维护者 Stuart Cheshire 合作,将该私有注册表的内容合并到官方 IANA 注册表中。独立注册表网页已更新为指向 IANA 注册表和本 RFC 的指针。

IANA 在协议和服务名称注册表 [PROTSERVREG] 中为所有尚未分配的条目在服务名称和端口号注册表 [PORTREG] 中创建了新的服务名称条目。

IANA 还在"www"和"www-http"的分配说明中指出它们是指"http"服务的重复术语,不应用于发现目的。对于这个概念服务(通过 HTTP 提供的人类可读网页),用于服务发现目的的正确服务名称是"http"(见第 5 节)。

10.1. 服务名称一致性 (Service Name Consistency)

第 8.1 节定义了哪些字符串是格式良好的服务名称,直到现在还没有明确定义。第 8.1 节中的定义旨在允许服务名称与当前和未来的服务发现机制最大程度的兼容性。

截至 2009 年 8 月 5 日,现有端口号分配 [PORTREG] 中约 98% 的所谓"短名称"符合第 8.1 节所述的合法服务名称规则,因此对于这些服务,它们的服务名称与它们的"短名称"完全相同。

其余约 2% 的现有"短名称"不适合直接用作格式良好的服务名称,因为它们包含非法字符,如星号、点、加号、斜杠或下划线。所有现有的"短名称"都符合 15 个字符或更少的长度要求。

对于下表中列出的这 96 个不合适的"短名称",服务名称是短名称,其中任何非法字符都替换为连字符。

IANA 添加了一个使用新的格式良好的主服务名称的条目到注册表中,该条目用于现有服务,否则复制原始分配信息。在给出主服务名称的这个新条目的描述字段中,IANA 记录了它已为先前的服务分配了格式良好的服务名称,并引用了原始分配。在原始分配的分配说明字段中,IANA 添加了一个注释,说明此条目是新的格式良好的服务名称的别名,并且旧服务名称是历史性的,不能用于许多常见的服务发现机制。

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

除了上面列出的 96 个名称外,"whois++"的服务名称是"whoispp",遵循"application/whoispp-query" MIME 内容类型 [RFC2957] 设定的示例。

在 IANA 的端口号注册表 [PORTREG] 中记录的四个名称与临时 SRV 名称注册表 [SRVREG] 中先前记录的名称冲突:esp、hydra、recipe 和 xmp。名称冲突得到了友好解决:

  • IANA 端口号注册表短名称"esp"已由 Andrew Chernow 注册,他通知作者该端口不再使用,不再需要注册。SRV 注册表中的"esp"条目仍然有效。

  • SubEthaEdit 的 SRV 名称"hydra"已被淘汰,改用新的 SRV 名称"see"。IANA 端口号注册表中的"hydra"条目仍然有效。

  • SRV 名称"recipe"在尚未打包分发的开源项目中使用,注册者 Daniel Taylor 愿意更改为不同的服务名称。感谢 Daniel Taylor 接受此更改。IANA 端口号注册表中的"recipe"条目仍然有效。

  • IANA 端口号注册表短名称"xmp"已由 Bobby Krupczak 注册,但由于他的注册包括已分配的端口号(仍在使用且不受此更改影响),他愿意切换到不同的服务名称。感谢 Bobby Krupczak 接受此更改。SRV 注册表中的"xmp"条目仍然有效。

10.2. SCTP 和 DCCP 实验的端口号 (Port Numbers for SCTP and DCCP Experimentation)

两个系统 UDP 和 TCP 端口,1021 和 1022,已为实验使用保留 [RFC4727]。本文档为 SCTP 和 DCCP 分配相同的端口号,更新 TCP 和 UDP 分配,并指示 IANA 自动为任何具有类似 16 位端口号命名空间的未来传输协议分配这两个端口号。

请注意,这些端口号用于受控环境中的临时实验和开发。在使用这些端口号之前,请仔细考虑本文档第 6.1 节以及"分配实验和测试号码被认为是有用的" [RFC3692] 第 1 节和第 1.1 节中的建议。最重要的是,应用程序开发者必须在任何类型的非实验部署之前,按照第 8.1 节中的描述从 IANA 请求永久端口号分配。

exp1 端口分配:

字段
Service Nameexp1
Transport ProtocolDCCP, SCTP, TCP, UDP
AssigneeIESG <[email protected]>
ContactIETF Chair <[email protected]>
DescriptionRFC3692-style Experiment 1
Reference[RFC4727] [RFC6335]
Port Number1021

exp2 端口分配:

字段
Service Nameexp2
Transport ProtocolDCCP, SCTP, TCP, UDP
AssigneeIESG <[email protected]>
ContactIETF Chair <[email protected]>
DescriptionRFC3692-style Experiment 2
Reference[RFC4727] [RFC6335]
Port Number1022

10.3. DCCP 注册表的更新 (Updates to DCCP Registries)

本文档更新了 DCCP 端口号和 DCCP 服务代码注册表 [RFC4340] 的 IANA 分配程序。

10.3.1. DCCP 服务代码注册表 (DCCP Service Code Registry)

服务代码根据 DCCP 规范 [RFC4340] 第 19.8 节按"先到先得"的原则分配。本文档通过以下方式扩展该部分中给出的指南来更新该部分:

  • IANA 可以在不寻求"专家评审"的情况下使用其自由裁量权分配新的服务代码,但如果请求请求超过五个服务代码,应该寻求"专家评审"。

  • IANA 应随时联系 DCCP 专家审查员,提出与 DCCP 相关代码点请求相关的任何问题。

10.3.2. DCCP 端口号注册表 (DCCP Port Numbers Registry)

DCCP 端口注册表由 DCCP 规范 [RFC4340] 第 19.9 节定义。此注册表中的分配需要事先分配服务代码。并非所有服务代码都需要 IANA 分配的端口。

本文档通过以下方式扩展该部分中给出的指南来更新该部分:

  • IANA 通常应为 DCCP 服务器端口分配 1024-49151 范围内的值。IANA 要求在系统端口范围(0 到 1023)中分配端口号需要在 IANA 分配之前进行"IETF 评审" [RFC5226] [RFC4340]。

  • IANA 不得将多个 DCCP 服务器端口分配给单个服务代码值。

  • 允许将多个服务代码分配给同一 DCCP 端口,但需要"专家评审"。

  • 与 DCCP 服务器端口关联的服务代码值集应记录在服务名称和端口号注册表中。

  • 请求将额外的服务代码与已分配的端口号关联需要"专家评审"。当这些请求来自与端口分配关联的联系人时,这些请求通常会被接受。在其他情况下,当可用时,这些应用程序应使用未分配的端口。

DCCP 规范 [RFC4340] 指出,短端口名称必须与已分配的每个 DCCP 服务器端口关联。本文档澄清,此短端口名称是如此处定义的服务名称,并且此名称必须是唯一的。