IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats
updates
- rfc-1833 — Binding Protocols for ONC RPC Version 2
Extracted elements (23)
Netids with the prefix 'ICMP' are Reserved to prevent confusion with the ICMP control protocol (RFC 792). The netids 'icmp' and 'icmp6' are listed in the registry solely to block their allocation for unrelated purposes, since ICMP is not a true transport and has no valid uaddr format.
RFC 1833 defined netids as locally determined by system administrators with no guarantee of cross-system consistency. Protocols such as NFSv4.0 and RPC/RDMA were subsequently found to depend on consistent netid values and uaddr representations across systems, motivating the creation of IANA registries to formalize and standardize these values.
The cross-reference fields linking the netid registry and the uaddr format registry use numeric values. IANA is explicitly permitted to renumber these cross-references, but if it does so, both registries must be updated atomically to maintain consistency.
The recommended convention for netids corresponding to IPv6 transports is to end the netid name with '6' (e.g., 'tcp6', 'udp6', 'sctp6', 'rdma6'). This is a convention, not a hard requirement, intended to improve readability and consistency.
The uaddr is defined in RFC 1833 as an XDR data type string (US-ASCII only), but SVR4 loopback transport implementations use an opaque octet array instead. Implementors must handle this deviation from the RFC 1833 uaddr specification when interoperating with SVR4-based systems.
When the 'sctp' or 'sctp6' netids are used, the ONC RPC Record Marking standard (RFC 5531, Section 11) is NOT used. Instead, SCTP's native record-oriented data transfer mechanism is used directly, because SCTP natively supports record boundaries.
A registered netid MUST NOT conflict with any other registered netid. Furthermore, when any registered netid is mapped to upper case, it MUST NOT conflict with the upper-case mapping of any other registered netid.
All requests for assignments to the uaddr format registry on a Standards Action basis are only for Standards Track RFCs approved by the IESG.
For Standards Action assignments to the netid registry, the description field must include the RFC numbers of the associated protocol, including transport and network protocol RFCs. For First Come First Served assignments, a reference to the transport and network protocols should be included where applicable.
Only the IESG, on the advice of a Designated Expert, can update a netid or uaddr format registration made on a Standards Action basis. First Come First Served registrations may be updated by the registrant, the IESG, or a Designated Expert.
When a netid is mapped to upper case, its prefix MUST NOT equal any Reserved prefix (STDS, FCFS, PRIV, EXPE, ICMP). Constant names with prefixes NC_STDS, NC_FCFS, NC_PRIV, NC_EXPE, and NC_ICMP are also Reserved, and MUST NOT conflict with any other registered constant name.
A netid is a US-ASCII string up to 2^32–1 octets in XDR encoding, though the registry restricts Standards Action assignments to 1–8 octets and First Come First Served assignments to 9–128 octets. The zero-length netid is Reserved.
Port 2049 is assigned to NFS over SCTP for both the 'sctp' and 'sctp6' netids, standardizing the well-known port for NFS when running over SCTP transport.
The constant name associated with a netid typically carries the prefix 'NC_' and a suffix equal to the upper-case netid. The constant 'NC_' alone is Reserved, and the constant name may be 1 to 131 octets long. Constants with 'NC_' prefix and total length ≤11 characters should be for Standards Action assignments.
The initial First Come First Served netid assignments are: '-' (NC_NOPROTO), 'ticlts' (NC_TICLTS, SVR4 connectionless loopback), 'ticots' (NC_TICOTS, SVR4 connection-oriented loopback), and 'ticotsord' (NC_TICOTSORD, SVR4 connection-oriented with orderly-release loopback). The SVR4 entries are exceptions to the 9–128 octet length rule.
The initial Standards Action netid assignments are: 'rdma' (NC_RDMA, IPv4), 'rdma6' (NC_RDMA6, IPv6), 'sctp' (NC_SCTP, IPv4), 'sctp6' (NC_SCTP6, IPv6), 'tcp' (NC_TCP, IPv4), 'tcp6' (NC_TCP6, IPv6), 'udp' (NC_UDP, IPv4), 'udp6' (NC_UDP6, IPv6), all with IESG as point of contact.
The netid '-' (NC_NOPROTO) has no associated uaddr format (cross-reference 1 in Table 3 designates 'no address'). It is reserved for internal use in some RFC 1833 implementations and carries no transport or network protocol.
IANA created the 'ONC RPC Netids' registry with two subregistries: one for Standards Action assignments (netids 1–8 octets) and one for First Come First Served assignments (netids 9–128 octets). Each entry contains the netid string, a constant name, a description/reference, a point of contact, and a cross-reference to the uaddr format registry.
IANA created the 'ONC RPC Uaddr Format Registry' with assignments made on either a First Come First Served or Standards Action basis. Each entry contains the assignment basis, a description/reference to the uaddr format, a point of contact, and a cross-reference number linking to the netid registry.
RFC 5665 is solely concerned with IANA management of the netid and uaddr format registries and raises no new security issues beyond those already present in RFC 1833 and the transport protocols referenced.
The uaddr format for IPv4 transports using 16-bit ports (RDMA, SCTP, TCP, UDP) is the US-ASCII string 'h1.h2.h3.h4.p1.p2', where h1–h4 are the four IPv4 address octets in ASCII-decimal and p1.p2 encodes the 16-bit port as two ASCII-decimal octets (big-endian). Example: address 0xC0000207 on port 0xCB51 yields '192.0.2.7.203.81'.
The uaddr format for IPv6 transports using 16-bit ports is the US-ASCII string 'x1:x2:x3:x4:x5:x6:x7:x8.p1.p2'. The prefix follows RFC 4291 Section 2.2 preferred (or two alternative) textual forms for IPv6 addresses, and the '.p1.p2' port suffix is computed identically to the IPv4 uaddr format.
The uaddr format for System V Release 4 loopback transports (ticlts, ticots, ticotsord) is any non-zero length array of octets; it is opaque rather than US-ASCII text, which is an exception to the general XDR string constraint specified in RFC 1833.