Internet Engineering Task Force (IETF) M. Eisler
Request for Comments: 5665 NetApp
Updates: 1833 January 2010
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Eisler
Request for Comments: 5665 NetApp
Updates: 1833 January 2010
Category: Standards Track
ISSN: 2070-1721
IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats
远程过程调用（RPC）网络标识符和通用地址格式的IANA注意事项
Abstract
摘要
This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This document updates, but does not replace, RFC 1833.
本文档列出了远程过程调用（RPC）网络标识符（NetID）和RPC通用网络地址（UADDR）的IANA注意事项。本文件更新但不替换RFC 1833。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc5665.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5665.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction and Motivation .....................................3
2. Requirements Language ...........................................3
3. Considerations for the Netid of the Stream Control
Transmission Protocol ...........................................3
4. Security Considerations .........................................3
5. IANA Considerations .............................................3
5.1. IANA Considerations for Netids .............................4
5.1.1. Initial Registry ....................................6
5.1.2. Updating Registrations ..............................8
5.2. IANA Considerations for Uaddr Formats ......................8
5.2.1. Initial Registry ....................................9
5.2.2. Updating Registrations .............................10
5.2.3. Uaddr Formats ......................................10
5.2.3.1. Uaddr Format for System V Release
4 Loopback Transports .....................10
5.2.3.2. Uaddr Format for Netid "-" ................10
5.2.3.3. Uaddr Format for Most IPv4 Transports .....11
5.2.3.4. Uaddr Format for Most IPv6 Transports .....11
5.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6 ..11
5.3. Cross Referencing between the Netid and Format Registry ...12
5.4. Port Assignment for NFS over SCTP .........................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
Appendix A. Acknowledgments ......................................14
1. Introduction and Motivation .....................................3
2. Requirements Language ...........................................3
3. Considerations for the Netid of the Stream Control
Transmission Protocol ...........................................3
4. Security Considerations .........................................3
5. IANA Considerations .............................................3
5.1. IANA Considerations for Netids .............................4
5.1.1. Initial Registry ....................................6
5.1.2. Updating Registrations ..............................8
5.2. IANA Considerations for Uaddr Formats ......................8
5.2.1. Initial Registry ....................................9
5.2.2. Updating Registrations .............................10
5.2.3. Uaddr Formats ......................................10
5.2.3.1. Uaddr Format for System V Release
4 Loopback Transports .....................10
5.2.3.2. Uaddr Format for Netid "-" ................10
5.2.3.3. Uaddr Format for Most IPv4 Transports .....11
5.2.3.4. Uaddr Format for Most IPv6 Transports .....11
5.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6 ..11
5.3. Cross Referencing between the Netid and Format Registry ...12
5.4. Port Assignment for NFS over SCTP .........................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
Appendix A. Acknowledgments ......................................14
The concepts of an RPC (defined in RFC 5531 [4]) Network Identifier (netid) and an RPC Universal Address (uaddr) were introduced in RFC 1833 [1] for distinguishing network addresses of multiple protocols and representing those addresses in a canonical form. RFC 1833 states that a netid "is defined by a system administrator based on local conventions, and cannot be depended on to have the same value on every system". (The netid is contained in the field r_netid of the data type rpcb_entry, and the uaddr is contained in the field r_addr of the same data type, where rpcb_entry is defined in RFC 1833.) Since the publication of RFC 1833, it has been found that protocols like Network File System version 4 (NFSv4.0) [5] and RPC/ RDMA (Remote Direct Memory Access) [6] depend on consistent values of netids and representations of uaddrs. Current practices tend to ensure this consistency. Thus, this document identifies the considerations for IANA to establish registries of netids and uaddr formats for RPC and specifies the initial content of the two registries.
RFC 1833[1]引入了RPC（在RFC 5531[4]中定义）网络标识符（netid）和RPC通用地址（uaddr）的概念，用于区分多个协议的网络地址，并以规范形式表示这些地址。RFC 1833规定，netid“由系统管理员根据本地约定定义，不能依赖于在每个系统上具有相同的值”。（netid包含在数据类型rpcb_条目的字段r_netid中，uaddr包含在相同数据类型的字段r_addr中，其中rpcb_条目在RFC 1833中定义。）自RFC 1833发布以来，已经发现网络文件系统版本4（NFSv4.0）[5]和RPC/RDMA（远程直接内存访问）[6]取决于NetID的一致值和UADDR的表示。目前的做法倾向于确保这种一致性。因此，本文件确定了IANA为RPC建立NetID和uaddr格式注册的注意事项，并指定了两个注册的初始内容。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
3. Considerations for the Netid of the Stream Control Transmission Protocol
3. 流控制传输协议Netid的考虑
The Stream Control Transmission Protocol (SCTP) (described in RFC 4960 [7]) is a connection-oriented protocol that supports both byte-streamed and record-oriented data transfer. When the "sctp" and "sctp6" netids are used, the Open Network Computing (ONC) RPC Record Marking standard (see Section 11 of RFC 5531 [4]) is not used; instead, SCTP's native record-oriented data transfer is used.
流控制传输协议（SCTP）（在RFC 4960[7]中描述）是一种面向连接的协议，支持字节流和面向记录的数据传输。当使用“sctp”和“sctp6”NetID时，不使用开放网络计算（ONC）RPC记录标记标准（见RFC 5531[4]第11节）；相反，使用了SCTP的本机面向记录的数据传输。
Since this document is only concerned with the IANA management of the Network Identifier (netid) and Universal Network Addresses (uaddrs) format registry, it raises no new security issues.
由于本文档仅涉及IANA对网络标识符（netid）和通用网络地址（UADDR）格式注册表的管理，因此不会产生新的安全问题。
This section uses terms that are defined in RFC 5226 [8].
本节使用RFC 5226[8]中定义的术语。
IANA has created a registry called "ONC RPC Netids". The remainder of this section describes the registry.
IANA创建了一个名为“ONC RPC NetID”的注册表。本节的其余部分介绍注册表。
All assignments to the ONC RPC Netids registry are made on one of two bases:
ONC RPC NetID注册表的所有分配基于以下两种基础之一：
o A First Come First Served basis subregistry per Section 4.1 of RFC 5226.
o RFC 5226第4.1节规定的先到先得原则。
o A Standards Action basis subregistry per Section 4.1 of RFC 5226.
o RFC 5226第4.1节规定的标准行动依据分区域。
The eXternal Data Representation (XDR) encoding allows netids to be up to 2^32 - 1 octets in length, but the registry will only allow a much shorter length. Assignments made on a Standards Action basis should be assigned netids 1 to 8 octets long. Assignments made on a First Come First Served basis should be assigned netids 9 to 128 octets long. Some exceptions are listed in Table 2.
外部数据表示（XDR）编码允许NetID的长度达到2^32-1个八位字节，但注册表只允许更短的长度。以标准行动为基础的作业应分配1至8个八位字节长的NetID。在先到先得的基础上完成的作业应分配9到128个八位字节。表2中列出了一些例外情况。
Some portion of the netid name space is Reserved:
保留部分netid名称空间：
o All netids, regardless of length, that start with the prefixes "STDS" or "FCFS" are Reserved, in order to extend the name space of either Standards Action or First Come First Served bases.
o 所有以前缀“STD”或“FCFS”开头的NetID，无论长度如何，都会被保留，以扩展标准行动或先到先得基地的名称空间。
o To give the IESG the flexibility in the future to permit Private and Experimental Uses, all netids with the prefixes "PRIV" or "EXPE" are Reserved.
o 为了使IESG在未来能够灵活地允许私人和实验性使用，保留了所有前缀为“PRIV”或“EXPE”的NetID。
o To prevent confusion with the control protocol by the same name [9], netids with the prefix "ICMP" are Reserved.
o 为防止与同名控制协议混淆[9]，保留前缀为“ICMP”的网络ID。
o Since netids are not constructed in an explicit hierarchical manner, this document does not provide for Hierarchical Allocation of netids. Nonetheless, all netids containing the octet "." are Reserved for future possible provision of Hierarchical Allocation.
o 由于NetID不是以明确的分层方式构建的，因此本文件不提供NetID的分层分配。尽管如此，所有包含八位字节“.”的NetID都是保留的，以便将来可能提供分层分配。
o The zero length netid is Reserved.
o 保留长度为零的netid。
A recommended convention for netids corresponding to transports that work over the IPv6 protocol is to have "6" as the last character in the netid's name.
与通过IPv6协议工作的传输相对应的netid的推荐约定是将“6”作为netid名称的最后一个字符。
There are two subregistries of netids: one for Standards Action assignments and one for First Come First Served assignments. Each registry of netids is a list of assignments, each containing five fields for each assignment.
NetID有两个子区域：一个用于标准行动任务，另一个用于先到先得任务。每个NetID注册表都是一个作业列表，每个作业包含五个字段。
1. A US-ASCII string name that is the actual netid. The netid should be 1 to 8 octets long for the Standards Action subregistry, and 9 to 128 octets long for the First Come First Served subregistry. The netid MUST NOT conflict with any other registered netid. Despite the fact that netids are case sensitive, the netid, when mapped to all upper case, MUST NOT conflict with the value of any other registered netid after the registered netid is mapped to upper case. In addition, when mapped to upper case, the prefix of the netid MUST NOT be equal to a Reserved prefix.
1. 一个US-ASCII字符串名称，它是实际的netid。对于标准行动分区，netid的长度应为1至8个八位字节，对于先到先得分区，netid的长度应为9至128个八位字节。netid不得与任何其他已注册的netid冲突。尽管netid是区分大小写的，但当映射到所有大写时，netid不得与注册netid映射到大写后的任何其他注册netid的值冲突。此外，当映射到大写时，netid的前缀不得等于保留前缀。
2. A constant name that can be used for software programs that wish to use the transport protocol associated with the netid. The name of the constant typically has the prefix "NC_", and a suffix equal to the upper-case version of the netid. This constant name should be a constant that is valid in the 'C' programming language. This constant name MUST NOT conflict with any other netid constant name. Constant names with the prefix "NC_STDS", "NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved. Constant names with a prefix of "NC_" and a total length of 11 characters or less should be for assignments made on the Standards Action basis. The constant "NC_" is Reserved. The constant name can be 1 to 131 octets long.
2. 可用于希望使用与netid关联的传输协议的软件程序的常量名称。常量的名称通常具有前缀“NC_3;”，后缀等于netid的大写版本。此常量名称应该是在“C”编程语言中有效的常量。此常量名称不得与任何其他netid常量名称冲突。保留前缀为“NC_STDS”、“NC_FCFS”、“NC_PRIV”、“NC_EXPE”和“NC_ICMP”的常量名称。前缀为“NC_”且总长度不超过11个字符的常量名称应用于基于标准操作的赋值。保留常量“NC_”。常量名称的长度可以是1到131个八位字节。
Given the typical derivation of the constant name from the netid, the registration of the constant might be considered redundant. This is not always true. For example, a netid might use a character that is not valid in the programming language. The first entry of Table 1 provides such an example.
考虑到常量名称从netid的典型派生，常量的注册可能被认为是多余的。这并不总是正确的。例如，netid可能使用在编程语言中无效的字符。表1的第一项提供了这样一个示例。
3. A description and/or a reference to a description of how the netid will be used. For assignments made on a First Come First Served basis, the description should include, if applicable, a reference to the transport and network protocols corresponding to the netid. For assignments made on a Standards Action basis, the description field must include the RFC numbers of the protocol associated with the netid, including, if applicable, RFC numbers of the transport and network protocols.
3. 说明和/或对如何使用netid的说明的引用。对于以先到先得方式进行的分配，如果适用，说明应包括对与netid对应的传输和网络协议的参考。对于基于标准行动的分配，描述字段必须包括与netid关联的协议的RFC编号，包括传输和网络协议的RFC编号（如适用）。
4. A point of contact of the registrant. For assignments made on a First Come First Served basis:
4. 注册人的联系人。对于以先到先得方式完成的任务：
* the point of contact should include an email address.
* 联系人应包括电子邮件地址。
* subject to authorization by a Designated Expert, the point of contact may be omitted for extraordinary situations, such as the registration of a commonly used netid where the owner is unknown.
* 根据指定专家的授权，在特殊情况下，可以省略联系点，例如注册一个不知道所有者的常用网络ID。
For assignments made on a Standards Action basis, the point of contact is always determined by IESG.
对于基于标准行动的任务，联络点始终由IESG确定。
5. A numerical value, used to cross reference the netid assignment with an assignment in the uaddr format registry (see Section 5.2). If the registrant is registering a netid that cross references an existing assignment in the uaddr format registry, then the registrant provides the actual value of the cross reference along with the date the registrant retrieved the cross reference value from the uaddr format registry. If the registrant is registering both a new netid and new uaddr format, then the registrant provides a value of TBD1 in the netid request, and uses TBD1 in the uaddr format request. IANA will then substitute TBD1 for the cross reference number IANA allocates. Note that if a document requests multiple netid and uaddr assignments, each additional uaddr format cross reference will be identified as TBD2, TBD3, ..., etc.
5. 一个数值，用于将netid分配与uaddr格式注册表中的分配进行交叉引用（见第5.2节）。如果注册人在uaddr格式注册表中注册交叉引用现有分配的netid，则注册人提供交叉引用的实际值以及注册人从uaddr格式注册表检索交叉引用值的日期。如果注册人同时注册新的netid和新的uaddr格式，则注册人在netid请求中提供TBD1值，并在uaddr格式请求中使用TBD1。然后，IANA将用TBD1代替IANA分配的交叉参考号。请注意，如果文档请求多个netid和uaddr分配，则每个附加的uaddr格式交叉引用将标识为TBD2、TBD3等。
The initial list of netids is broken into two subregistries: those assigned on a First Come First Served basis in Table 1 and those assigned on a Standards Action basis in Table 2. These lists will change as IANA registers additional netids as needed, and the authoritative list of registered netids will always live with IANA.
最初的NetID列表分为两个子区域：表1中按先到先得原则分配的子区域和表2中按标准行动原则分配的子区域。随着IANA根据需要注册其他NetID，这些列表将发生变化，注册NetID的权威列表将始终与IANA保持一致。
+-------------+--------------+---------------------------+-----+----+
| Netid | Constant | Description and/or | PoC | CR |
| | Name | Reference | | |
+-------------+--------------+---------------------------+-----+----+
| "-" | NC_NOPROTO | RFC1833 [1], | | 1 |
| | | Section 5.2.3.2 of RFC | | |
| | | 5665 | | |
| "ticlts" | NC_TICLTS | The loop back | | 0 |
| | | connectionless transport | | |
| | | used in System V Release | | |
| | | 4 and other operating | | |
| | | systems. Although this | | |
| | | assignment is made on a | | |
| | | First Come First Served | | |
| | | basis and is fewer than | | |
| | | nine characters long, the | | |
| | | exception is authorized. | | |
| | | See [10]. | | |
| "ticots" | NC_TICOTS | The loop back | | 0 |
| | | connection-oriented | | |
| | | transport used in System | | |
| | | V Release 4 and other | | |
| | | operating systems. See | | |
| | | [10]. Although this | | |
| | | assignment is made on a | | |
| | | First Come First Served | | |
| | | basis and is fewer than | | |
| | | nine characters long, the | | |
| | | exception is authorized. | | |
| "ticotsord" | NC_TICOTSORD | The loop back | | 0 |
| | | connection-oriented with | | |
| | | orderly-release transport | | |
| | | used in System V Release | | |
| | | 4 and other operating | | |
| | | systems. See [10]. | | |
+-------------+--------------+---------------------------+-----+----+
+-------------+--------------+---------------------------+-----+----+
| Netid | Constant | Description and/or | PoC | CR |
| | Name | Reference | | |
+-------------+--------------+---------------------------+-----+----+
| "-" | NC_NOPROTO | RFC1833 [1], | | 1 |
| | | Section 5.2.3.2 of RFC | | |
| | | 5665 | | |
| "ticlts" | NC_TICLTS | The loop back | | 0 |
| | | connectionless transport | | |
| | | used in System V Release | | |
| | | 4 and other operating | | |
| | | systems. Although this | | |
| | | assignment is made on a | | |
| | | First Come First Served | | |
| | | basis and is fewer than | | |
| | | nine characters long, the | | |
| | | exception is authorized. | | |
| | | See [10]. | | |
| "ticots" | NC_TICOTS | The loop back | | 0 |
| | | connection-oriented | | |
| | | transport used in System | | |
| | | V Release 4 and other | | |
| | | operating systems. See | | |
| | | [10]. Although this | | |
| | | assignment is made on a | | |
| | | First Come First Served | | |
| | | basis and is fewer than | | |
| | | nine characters long, the | | |
| | | exception is authorized. | | |
| "ticotsord" | NC_TICOTSORD | The loop back | | 0 |
| | | connection-oriented with | | |
| | | orderly-release transport | | |
| | | used in System V Release | | |
| | | 4 and other operating | | |
| | | systems. See [10]. | | |
+-------------+--------------+---------------------------+-----+----+
Table 1: Initial First Come First Served Netid Assignments
表1：初始先到先得的Netid分配
PoC: Point of Contact.
PoC：联络点。
CR: Cross Reference to the Uaddr Format Registry.
CR：对Uaddr格式注册表的交叉引用。
+---------+----------+----------------------------------+------+----+
| Netid | Constant | RFC(s) and Description (if | PoC | CR |
| | Name | needed) | | |
+---------+----------+----------------------------------+------+----+
| "rdma" | NC_RDMA | RFC 5666 [6], RFC 791 [11] | IESG | 2 |
| "rdma6" | NC_RDMA6 | RFC 5666 [6], RFC 2460 [12] | IESG | 3 |
| "sctp" | NC_SCTP | RFC 4960 [7], RFC 791 [11], | IESG | 2 |
| | | Section 3 of RFC 5665 | | |
| "sctp6" | NC_SCTP6 | RFC 4960 [7], RFC 2460 [12], | IESG | 3 |
| | | Section 3 of RFC 5665 | | |
| "tcp" | NC_TCP | RFC 793 [13], RFC 791 [11], | IESG | 2 |
| | | Section 11 of RFC 5531 [4] | | |
| "tcp6" | NC_TCP6 | RFC 793 [13], RFC 2460 [12], | IESG | 3 |
| | | Section 11 of RFC 5531 [4] | | |
| "udp" | NC_UDP | RFC 768 [14], RFC 791 [11] | IESG | 2 |
| "udp6" | NC_UDP6 | RFC 768 [14], RFC 2460 [12] | IESG | 3 |
+---------+----------+----------------------------------+------+----+
+---------+----------+----------------------------------+------+----+
| Netid | Constant | RFC(s) and Description (if | PoC | CR |
| | Name | needed) | | |
+---------+----------+----------------------------------+------+----+
| "rdma" | NC_RDMA | RFC 5666 [6], RFC 791 [11] | IESG | 2 |
| "rdma6" | NC_RDMA6 | RFC 5666 [6], RFC 2460 [12] | IESG | 3 |
| "sctp" | NC_SCTP | RFC 4960 [7], RFC 791 [11], | IESG | 2 |
| | | Section 3 of RFC 5665 | | |
| "sctp6" | NC_SCTP6 | RFC 4960 [7], RFC 2460 [12], | IESG | 3 |
| | | Section 3 of RFC 5665 | | |
| "tcp" | NC_TCP | RFC 793 [13], RFC 791 [11], | IESG | 2 |
| | | Section 11 of RFC 5531 [4] | | |
| "tcp6" | NC_TCP6 | RFC 793 [13], RFC 2460 [12], | IESG | 3 |
| | | Section 11 of RFC 5531 [4] | | |
| "udp" | NC_UDP | RFC 768 [14], RFC 791 [11] | IESG | 2 |
| "udp6" | NC_UDP6 | RFC 768 [14], RFC 2460 [12] | IESG | 3 |
+---------+----------+----------------------------------+------+----+
Table 2: Initial Standards Action Netid Assignments
表2：初始标准行动Netid分配
Per Section 5.2 of RFC 5226, the registrant is always permitted to update a registration made on a First Come First Served basis "subject to the same constraints and review as with new registrations". The IESG or a Designated Expert is permitted to update any registration made on a First Come First Served basis, which normally is done when the PoC cannot be reached in order to make necessary updates. Examples where an update would be needed include, but are not limited to: the email address or other contact information becomes invalid; the reference to the corresponding protocol becomes obsolete or unavailable; RFC 1833 is updated or replaced in such a way that the scope of netids changes, requiring additional fields in the assignment.
根据RFC 5226第5.2节，注册人始终可以按照先到先得的原则更新注册，“遵守与新注册相同的限制和审查”。IESG或指定专家可以按照先到先得的原则更新任何注册，通常在无法联系PoC时进行更新，以便进行必要的更新。需要更新的示例包括但不限于：电子邮件地址或其他联系信息无效；对相应协议的引用变得过时或不可用；RFC 1833的更新或替换方式使NetID的范围发生变化，需要在分配中添加其他字段。
Only the IESG, on the advice of a Designated Expert, can update a registration made on a Standards Action basis.
只有IESG根据指定专家的建议，才能更新基于标准行动的注册。
IANA has created a registry called "ONC RPC Uaddr Format Registry" (called the "format registry" for the remainder of this document). The remainder of this section describes the registry.
IANA创建了一个名为“ONC RPC Uaddr格式注册表”的注册表（本文档其余部分称为“格式注册表”）。本节的其余部分介绍注册表。
All assignments to the format registry are made on one of two bases:
格式注册表的所有分配都基于以下两种基础之一：
o First Come First Served basis per Section 4.1 of RFC 5226.
o 根据RFC 5226第4.1节，先到先得。
o Standards Action per Section 4.1 of RFC 5226.
o RFC 5226第4.1节规定的标准行动。
The registry of formats is a list of assignments, each containing four fields for each assignment.
格式注册表是一个分配列表，每个分配包含四个字段。
1. The basis for the assignment, which can be either FCFS for First Come First Served assignments or STDS for Standards Action assignments.
1. 任务的基础，可以是先到先得任务的FCF，也可以是标准行动任务的STD。
2. A description and/or reference to a description of the actual uaddr format. Assignments made on a Standards Action basis always have a reference to an RFC.
2. 对实际uaddr格式的描述和/或引用。在标准行动基础上进行的分配始终参考RFC。
3. For assignments made on a First Come First Served basis, a point of contact, including an email address. Subject to authorization by a Designated Expert, the point of contact may be omitted for extraordinary situations, such as the registration of a commonly used format where the owner is unknown. For assignments made on a Standards Action basis, the point of contact is always determined by the IESG.
3. 对于以先到先得方式完成的任务，应提供联系人，包括电子邮件地址。根据指定专家的授权，在特殊情况下，如注册一种通常使用的格式，而所有者未知，可省略联络点。对于基于标准行动的任务，联络点始终由IESG确定。
4. A numerical value, used to cross reference the format assignment with an assignment in the netid registry. The registrant provides a value of TBD1 for the cross reference field when requesting an assignment. IANA will assign TBD1 to a real value. Note that if a document requests multiple uaddr assignments, each additional uaddr format cross reference will be identified as TBD2, TBD3, ..., etc.
4. 一个数值，用于将格式分配与netid注册表中的分配进行交叉引用。当请求分配时，注册人为交叉引用字段提供TBD1值。IANA将TBD1分配给实际值。请注意，如果一个文档请求多个uaddr分配，每个额外的uaddr格式交叉引用将标识为TBD2、TBD3等。
All requests for assignments to the format registry on a Standards Action basis are only for Standards Track RFCs approved by the IESG.
所有以标准行动为基础向格式注册表分配的请求仅适用于IESG批准的标准跟踪RFC。
The initial list of formats is in Table 3. This list will change as IANA registers additional formats as needed, and the authoritative list of registered formats will always live with IANA.
初始格式列表见表3。当IANA根据需要注册其他格式时，此列表将发生变化，并且注册格式的权威列表将始终与IANA共存。
+-------+-----------------------------------------------+------+----+
| Basis | Description and/or Reference | PoC | CR |
+-------+-----------------------------------------------+------+----+
| FCFS | System V Release 4 loopback transport uaddr | | 0 |
| | format. Section 5.2.3.1 of RFC 5665 | | |
| FCFS | Uaddr format for NC_NOPROTO. Section 5.2.3.2 | | 1 |
| | of RFC 5665 | | |
| STDS | Uaddr format for IPv4 transports. | IESG | 2 |
| | Section 5.2.3.3 of RFC 5665 | | |
| STDS | Uaddr format for IPv6 transports. | IESG | 3 |
| | Section 5.2.3.4 of RFC 5665 | | |
+-------+-----------------------------------------------+------+----+
+-------+-----------------------------------------------+------+----+
| Basis | Description and/or Reference | PoC | CR |
+-------+-----------------------------------------------+------+----+
| FCFS | System V Release 4 loopback transport uaddr | | 0 |
| | format. Section 5.2.3.1 of RFC 5665 | | |
| FCFS | Uaddr format for NC_NOPROTO. Section 5.2.3.2 | | 1 |
| | of RFC 5665 | | |
| STDS | Uaddr format for IPv4 transports. | IESG | 2 |
| | Section 5.2.3.3 of RFC 5665 | | |
| STDS | Uaddr format for IPv6 transports. | IESG | 3 |
| | Section 5.2.3.4 of RFC 5665 | | |
+-------+-----------------------------------------------+------+----+
Table 3: Initial Format Assignments
表3：初始格式分配
The registrant is always permitted to update a registration made on a First Come First Served basis "subject to the same constraints and review as with new registrations." The IESG is permitted to update any registration made on a First Come First Served basis, which normally is done when the PoC cannot be reached in order to make necessary updates. Examples where an update would be needed include, but are not limited to: the email address or other contact information becomes invalid; the reference to the format description becomes obsolete or unavailable; RFC 1833 is updated or replaced in such a way that the scope of uaddr formats changes, requiring additional fields in the assignment.
注册人始终被允许更新以先到先得方式进行的注册，“受与新注册相同的约束和审查”。IESG被允许更新以先到先得方式进行的任何注册，这通常是在无法联系PoC时进行的，以便进行必要的更新。需要更新的示例包括但不限于：电子邮件地址或其他联系信息无效；对格式说明的引用已过时或不可用；RFC 1833的更新或替换方式使uaddr格式的范围发生变化，需要在分配中添加其他字段。
Only the IESG, on the advice of a Designated Expert, can update a registration made on a Standards Action basis.
只有IESG根据指定专家的建议，才能更新基于标准行动的注册。
Although RFC 1833 specifies the uaddr as the XDR data type string (hence, limited to US-ASCII), implementations of the System V Release 4 loopback transports will use an opaque string of octets. Thus, the format of a loopback transport address is any non-zero length array of octets.
尽管RFC 1833将uaddr指定为XDR数据类型字符串（因此，仅限于US-ASCII），但System V Release 4环回传输的实现将使用不透明的八位字节字符串。因此，环回传输地址的格式是任何长度为非零的八位字节数组。
There is no address format for netid "-". This netid is apparently for internal use for supporting some implementations of RFC 1833.
netid“-”没有地址格式。这个netid显然是内部使用的，用于支持RFC1833的一些实现。
Most transport protocols that operate over IPv4 use 16-bit port numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14]. The format of the uaddr for the above 16-bit port transports (when used over IPv4) is the US-ASCII string:
大多数在IPv4上运行的传输协议使用16位端口号，包括RDMA[6]、SCTP[7]、TCP[13]和UDP[14]。上述16位端口传输（通过IPv4使用时）的uaddr格式为US-ASCII字符串：
h1.h2.h3.h4.p1.p2
h1.h2.h3.h4.p1.p2
The prefix "h1.h2.h3.h4" is the standard textual form for representing an IPv4 address, which is always four octets long. Assuming big-endian ordering, h1, h2, h3, and h4 are, respectively, the first through fourth octets each converted to ASCII-decimal. The suffix "p1.p2" is a textual form for representing a service port. Assuming big-endian ordering, p1 and p2 are, respectively, the first and second octets each converted to ASCII-decimal. For example, if a host, in big-endian order, has an address in hexadecimal of 0xC0000207 and there is a service listening on, in big-endian order, port 0xCB51 (decimal 52049), then the complete uaddr is "192.0.2.7.203.81".
前缀“h1.h2.h3.h4”是表示IPv4地址的标准文本形式，其长度始终为四个八位字节。假设大端排序，h1、h2、h3和h4分别是第一个到第四个八位字节，每个八位字节转换为ASCII十进制。后缀“p1.p2”是表示服务端口的文本形式。假设大端排序，p1和p2分别是第一个和第二个八位字节，每个八位字节转换为ASCII十进制。例如，如果主机以大端顺序具有十六进制的地址0xC0000207，并且有服务以大端顺序侦听端口0xCB51（十进制52049），则完整的uaddr为“192.0.2.7.203.81”。
Most transport protocols that operate over IPv6 use 16-bit port numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14]. The format of the uaddr for the above 16-bit port transports (when used over IPv6) is the US-ASCII string:
大多数在IPv6上运行的传输协议都使用16位端口号，包括RDMA[6]、SCTP[7]、TCP[13]和UDP[14]。上述16位端口传输（在IPv6上使用时）的uaddr格式为US-ASCII字符串：
x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
The suffix "p1.p2" is the service port, and is computed the same way as with uaddrs for transports over IPv4 (see Section 5.2.3.3). The prefix "x1:x2:x3:x4:x5:x6:x7:x8" is the preferred textual form for representing an IPv6 address as defined in Section 2.2 of RFC 4291 [3]. Additionally, the two alternative forms specified in Section 2.2 of RFC 4291 are also acceptable.
后缀“p1.p2”是服务端口，其计算方法与IPv4上传输的UADDR相同（参见第5.2.3.3节）。前缀“x1:x2:x3:x4:x5:x6:x7:x8”是表示RFC 4291[3]第2.2节中定义的IPv6地址的首选文本形式。此外，RFC 4291第2.2节中规定的两种替代形式也是可以接受的。
As ICMP is not a true transport, there is no uaddr format for ICMP. The netid assignments "icmp" and "icmp6" and their shared uaddr "format" are listed to prevent any registrant from allocating the netids "icmp" and "icmp6" for a purpose that would likely cause confusion.
由于ICMP不是真正的传输，因此ICMP没有uaddr格式。列出netid分配“icmp”和“icmp6”及其共享的uaddr“格式”，以防止任何注册人分配netid“icmp”和“icmp6”用于可能导致混淆的目的。
The last field of the netids registry is used to cross reference with the last field of the format registry. IANA is under no obligation to maintain the same numeric values in cross references when updating each registry; i.e., IANA is free to "re-number" these corresponding fields. However, if IANA does so, both the netid and format registries must be updated atomically.
NetID注册表的最后一个字段用于与格式注册表的最后一个字段进行交叉引用。IANA没有义务在更新每个注册表时在交叉引用中保持相同的数值；i、 例如，IANA可以自由地“重新编号”这些对应字段。然而，如果IANA这样做，则必须对netid和格式注册表进行原子更新。
Port 2049 is assigned to NFS over SCTP for the sctp and sctp6 netids.
端口2049通过SCTP为SCTP和sctp6 NetID分配给NFS。
[1] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995.
[1] Srinivasan，R.，“ONC RPC版本2的绑定协议”，RFC 1833，1995年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[3] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[4] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009.
[4] 瑟洛，R.，“RPC：远程过程调用协议规范版本2”，RFC55312009年5月。
[5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[5] Shepler，S.，Callaghan，B.，Robinson，D.，Thurlow，R.，Beame，C.，Eisler，M.，和D.Noveck，“网络文件系统（NFS）版本4协议”，RFC 3530，2003年4月。
[6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access Transport for Remote Procedure Call", RFC 5666, January 2010.
[6] Talpey，T.和B.Callaghan，“远程过程调用的远程直接内存访问传输”，RFC 5666，2010年1月。
[7] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[7] Stewart，R.，编辑，“流控制传输协议”，RFC 4960，2007年9月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[8] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[9] Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[10] American Telephone and Telegraph Company, "UNIX System V, Release 4 Programmer's Guide: Networking Interfaces, ISBN 0139470786", 1990.
[10] 美国电话电报公司，“UNIX系统V，第4版程序员指南：网络接口，ISBN 0139470786”，1990年。
[11] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[11] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[12] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[13] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[13] 《传输控制协议》，标准7，RFC 793，1981年9月。
[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[14] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
Lisa Dusseault, Lars Eggert, Pasi Eronen, Tim Polk, Juergen Schoenwaelder, and Robert Sparks reviewed the document and gave valuable feedback.
Lisa Dusseault、Lars Eggert、Pasi Eronen、Tim Polk、Juergen Schoenwaeld和Robert Sparks审查了该文件并给出了宝贵的反馈。
Author's Address
作者地址
Mike Eisler NetApp 5765 Chase Point Circle Colorado Springs, CO 80919 US
Mike Eisler NetApp 5765 Chase Point Circle科罗拉多州斯普林斯市美国80919
Phone: +1-719-599-9026
EMail: mike@eisler.com
Phone: +1-719-599-9026
EMail: mike@eisler.com