draft-ietf-nfsv4-rpc-netid-06.txt		rfc5665.txt
	NFSv4 M. Eisler		Internet Engineering Task Force (IETF) M. Eisler
	Internet-Draft NetApp		Request for Comments: 5665 NetApp
	Updates: 1833 (if approved) January 30, 2009		Updates: 1833 January 2010
	Intended status: Standards Track		Category: Standards Track
	Expires: August 3, 2009		ISSN: 2070-1721
	IANA Considerations for RPC Net Identifiers and Universal Address
	Formats
	draft-ietf-nfsv4-rpc-netid-06.txt
	Status of this Memo		IANA Considerations for Remote Procedure Call (RPC)
			Network Identifiers and Universal Address Formats
	This Internet-Draft is submitted to IETF in full conformance with the		Abstract
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document lists IANA Considerations for Remote Procedure Call
	Task Force (IETF), its areas, and its working groups. Note that		(RPC) Network Identifiers (netids) and RPC Universal Network
	other groups may also distribute working documents as Internet-		Addresses (uaddrs). This document updates, but does not replace, RFC
	Drafts.		1833.
	Internet-Drafts are draft documents valid for a maximum of six months		Status of This Memo
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This is an Internet Standards Track document.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		This document is a product of the Internet Engineering Task Force
	http://www.ietf.org/shadow.html.		(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.
	This Internet-Draft will expire on August 3, 2009.		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.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document.		to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
	Abstract		the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	This Internet-Draft lists IANA Considerations for RPC Network
	Identifiers (netids) and RPC Universal Network Addresses (uaddrs).
	This Internet-Draft updates, but does not replace, RFC1833.
	Requirements Language
	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 [1].
	Table of Contents		Table of Contents
	1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3		1. Introduction and Motivation .....................................3
	2. Considerations for the Netid of the SCTP Protocol . . . . . . 3		2. Requirements Language ...........................................3
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 3		3. Considerations for the Netid of the Stream Control
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3		Transmission Protocol ...........................................3
	4.1. IANA Considerations for Netids . . . . . . . . . . . . . . 3		4. Security Considerations .........................................3
	4.1.1. Initial Registry . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations .............................................3
	4.1.2. Updating Registrations . . . . . . . . . . . . . . . . 8		5.1. IANA Considerations for Netids .............................4
	4.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 8		5.1.1. Initial Registry ....................................6
	4.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 9		5.1.2. Updating Registrations ..............................8
	4.2.2. Updating Registrations . . . . . . . . . . . . . . . . 9		5.2. IANA Considerations for Uaddr Formats ......................8
	4.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 10		5.2.1. Initial Registry ....................................9
	4.3. Cross Referencing Between the Netid and Format Registry . 11		5.2.2. Updating Registrations .............................10
	4.4. Port Assignment for NFS over SCTP . . . . . . . . . . . . 11		5.2.3. Uaddr Formats ......................................10
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.2.3.1. Uaddr Format for System V Release
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 11		4 Loopback Transports .....................10
	5.2. Informative References . . . . . . . . . . . . . . . . . . 11		5.2.3.2. Uaddr Format for Netid "-" ................10
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12		5.2.3.3. Uaddr Format for Most IPv4 Transports .....11
	Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 12		5.2.3.4. Uaddr Format for Most IPv6 Transports .....11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13		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		1. Introduction and Motivation
	The concepts of an RPC (defined in RFC1831 [4]) Network Identifier		The concepts of an RPC (defined in RFC 5531 [4]) Network Identifier
	(netid) and an RPC Universal Address (uaddr) were introduced in		(netid) and an RPC Universal Address (uaddr) were introduced in RFC
	RFC1833 [2] for distinguishing network addresses of multiple		1833 [1] for distinguishing network addresses of multiple protocols
	protocols and representing those addresses in a canonical form.		and representing those addresses in a canonical form. RFC 1833
	RFC1833 states that a netid ``is defined by a system administrator		states that a netid "is defined by a system administrator based on
	based on local conventions, and cannot be depended on to have the		local conventions, and cannot be depended on to have the same value
	same value on every system.'' (The netid is contained in the field		on every system". (The netid is contained in the field r_netid of
	r_netid of the data type rpcb_entry, and the uaddr is contained in		the data type rpcb_entry, and the uaddr is contained in the field
	the field r_addr of the same data type, where rpcb_entry is defined		r_addr of the same data type, where rpcb_entry is defined in RFC
	in RFC1833.) Since the publication of RFC1833, it has been found		1833.) Since the publication of RFC 1833, it has been found that
	that protocols like NFSv4.0 [5] and RPC/RDMA [6] depend on consistent		protocols like Network File System version 4 (NFSv4.0) [5] and RPC/
	values of netids and representations of uaddrs. Current practices		RDMA (Remote Direct Memory Access) [6] depend on consistent values of
	tend to ensure this consistency. Thus, this document identifies the		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		considerations for IANA to establish registries of netids and uaddr
	formats for RPC and specifies the initial content of the two		formats for RPC and specifies the initial content of the two
	registries.		registries.
	2. Considerations for the Netid of the SCTP Protocol		2. Requirements Language
	The SCTP protocol (described in RFC4960 [7]) is a connection-oriented		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	protocol that supports both byte-streamed and record-oriented data		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	transfer. When the "sctp" and "sctp6" netids are used, the ONC RPC		document are to be interpreted as described in RFC 2119 [2].
	Record Marking standard (see Section 10 of RFC1831 [4]) are not used;
			3. Considerations for the Netid of the Stream Control Transmission
			Protocol
			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.		instead, SCTP's native record-oriented data transfer is used.
	3. Security Considerations		4. Security Considerations
	Since this document is only concerned with the IANA management of the		Since this document is only concerned with the IANA management of the
	Network Identifier (netid) and Universal Network Addresses (uaddrs)		Network Identifier (netid) and Universal Network Addresses (uaddrs)
	format registry, it raises no new security issues.		format registry, it raises no new security issues.
	4. IANA Considerations		5. IANA Considerations
	This section uses terms that are defined in RFC5226 [8].		This section uses terms that are defined in RFC 5226 [8].
	4.1. IANA Considerations for Netids		5.1. IANA Considerations for Netids
	IANA will create a registry called "ONC RPC Netids". The remainder		IANA has created a registry called "ONC RPC Netids". The remainder
	of this section describes the registry.		of this section describes the registry.
	All assignments to the ONC RPC Netids registry are made on one of two		All assignments to the ONC RPC Netids registry are made on one of two
	bases:		bases:
	o A First Come First Served basis subregistry per section 4.1 of		o A First Come First Served basis subregistry per Section 4.1 of RFC
	RFC5226.		5226.
	o A Standards Action basis subregistry per section 4.1 of RFC5226.		o A Standards Action basis subregistry per Section 4.1 of RFC 5226.
	The XDR encoding allows netids to be up to 2^32 - 1 octets in length,		The eXternal Data Representation (XDR) encoding allows netids to be
	but the registry will only allow a much shorter length. Assignments		up to 2^32 - 1 octets in length, but the registry will only allow a
	made on a Standards Action basis should be assigned netids one to		much shorter length. Assignments made on a Standards Action basis
	eight octets long. Assignments made on a First Come First Served		should be assigned netids 1 to 8 octets long. Assignments made on a
	basis should be assigned netids nine to 128 octets long. Some		First Come First Served basis should be assigned netids 9 to 128
	exceptions are listed in Table 2.		octets long. Some exceptions are listed in Table 2.
	Some portion of the netid name space is Reserved:		Some portion of the netid name space is Reserved:
	o All netids, regardless of length, that start with the prefixes		o All netids, regardless of length, that start with the prefixes
	"STDS" or "FCFS" are Reserved, in order to extend the name space		"STDS" or "FCFS" are Reserved, in order to extend the name space
	of either Standards Action or First Come First Served bases.		of either Standards Action or First Come First Served bases.
	o To give IESG the flexibility in the future to permit Private and		o To give the IESG the flexibility in the future to permit Private
	Experimental Uses, all netids with the prefixes "PRIV" or "EXPE"		and Experimental Uses, all netids with the prefixes "PRIV" or
	are Reserved.		"EXPE" are Reserved.
	o To prevent confusion with the control protocol by the same name		o To prevent confusion with the control protocol by the same name
	[9], netids with the prefix "ICMP" are Reserved.		[9], netids with the prefix "ICMP" are Reserved.
	o Since netids are not constructed in an explicit hierarchical		o Since netids are not constructed in an explicit hierarchical
	manner, this document does not provide for Hierarchical Allocation		manner, this document does not provide for Hierarchical Allocation
	of netids. Nonetheless, all netids containing the octet "." are		of netids. Nonetheless, all netids containing the octet "." are
	Reserved for future possible provision of Hierarchical Allocation.		Reserved for future possible provision of Hierarchical Allocation.
	o The zero length netid is Reserved.		o The zero length netid is Reserved.
	A recommended convention for netids corresponding to transports that		A recommended convention for netids corresponding to transports that
	work over the IPv6 protocol is to have "6" as the last character in		work over the IPv6 protocol is to have "6" as the last character in
	the netid's name.		the netid's name.
	There are two subregistries of netids, one for Standards Action		There are two subregistries of netids: one for Standards Action
	assignments, and one for First Come First Serve assignments. Each		assignments and one for First Come First Served assignments. Each
	registry of netids is a list of assignments, each containing five		registry of netids is a list of assignments, each containing five
	fields for each assignment.		fields for each assignment.
	1. A US-ASCII string name that is the actual netid. The netid		1. A US-ASCII string name that is the actual netid. The netid
	should be one to eight octets long for the Standards Action		should be 1 to 8 octets long for the Standards Action
	subregistry, and should be nine to 128 octets long for the First		subregistry, and 9 to 128 octets long for the First Come First
	Come First Served subregistry. The netid MUST NOT conflict with		Served subregistry. The netid MUST NOT conflict with any other
	any other registered netid. Despite the fact that netids are		registered netid. Despite the fact that netids are case
	case sensitive, the netid, when mapped to all upper case MUST NOT		sensitive, the netid, when mapped to all upper case, MUST NOT
	conflict with the value of any other registered netid after the		conflict with the value of any other registered netid after the
	registered netid is mapped to upper case. In addition, when		registered netid is mapped to upper case. In addition, when
	mapped to upper case, the prefix of the netid MUST NOT be equal		mapped to upper case, the prefix of the netid MUST NOT be equal
	to a Reserved prefix.		to a Reserved prefix.
	2. A constant name that can be used for software programs that wish		2. A constant name that can be used for software programs that wish
	to use the transport protocol associated with protocol. The name		to use the transport protocol associated with the netid. The
	of the constant typically has the prefix: "NC_", and a suffix		name of the constant typically has the prefix "NC_", and a suffix
	equal to the upper case version of the netid. This constant name		equal to the upper-case version of the netid. This constant name
	should be a constant that is valid in the 'C' programming		should be a constant that is valid in the 'C' programming
	language. This constant name MUST NOT conflict with any other		language. This constant name MUST NOT conflict with any other
	netid constant name. Constant names with the prefix "NC_STDS",		netid constant name. Constant names with the prefix "NC_STDS",
	"NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved.		"NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved.
	Constant names with a prefix of "NC_" and a total length of 11		Constant names with a prefix of "NC_" and a total length of 11
	characters or less should be for assignments made on the		characters or less should be for assignments made on the
	Standards Action basis. The constant "NC_" is Reserved. The		Standards Action basis. The constant "NC_" is Reserved. The
	constant name can be one to 131 octets long.		constant name can be 1 to 131 octets long.
	Given the typical derivation of the constant name from the netid,		Given the typical derivation of the constant name from the netid,
	the registration of the constant might be considered redundant.		the registration of the constant might be considered redundant.
	This is not always true. For example, a netid might use a		This is not always true. For example, a netid might use a
	character than is not valid in the programming language. The		character that is not valid in the programming language. The
	first entry of Table 1 provides such an example.		first entry of Table 1 provides such an example.
	3. A description and/or a reference to a description of the how the		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		netid will be used. For assignments made on a First Come First
	Served basis the description should include, if applicable, a		Served basis, the description should include, if applicable, a
	reference to the transport and network protocols corresponding to		reference to the transport and network protocols corresponding to
	the netid. For assignments made on a Standards Action basis, the		the netid. For assignments made on a Standards Action basis, the
	description field must include the RFC numbers of the protocol		description field must include the RFC numbers of the protocol
	associated with the netid, including if applicable, RFC numbers		associated with the netid, including, if applicable, RFC numbers
	of the transport and network protocols.		of the transport and network protocols.
	4. A point of contact of the registrant. For assignments made on a		4. A point of contact of the registrant. For assignments made on a
	First Come First Served basis,		First Come First Served basis:
	* the point of contact should include an email address.		* the point of contact should include an email address.
	* subject to authorization by a Designated Expert, the point of		* subject to authorization by a Designated Expert, the point of
	contact may be omitted for extraordinary situations, such as		contact may be omitted for extraordinary situations, such as
	the registration of a commonly used netid where the owner is		the registration of a commonly used netid where the owner is
	unknown.		unknown.
	For assignments made on a Standards Action basis the point of		For assignments made on a Standards Action basis, the point of
	contact is always determined by IESG.		contact is always determined by IESG.
	5. A numerical value, used to cross reference the netid assignment		5. A numerical value, used to cross reference the netid assignment
	with an assignment in the uaddr format registry (see		with an assignment in the uaddr format registry (see
	Section 4.2). If the registrant is registering a netid that		Section 5.2). If the registrant is registering a netid that
	cross references an existing assignment in the uaddr format		cross references an existing assignment in the uaddr format
	registry, then the registrant provides the actual value of the		registry, then the registrant provides the actual value of the
	cross reference along with the date the registrant retrieved the		cross reference along with the date the registrant retrieved the
	cross reference value from the uaddr format registry. If the		cross reference value from the uaddr format registry. If the
	registrant is registering both a new netid and new uaddr format,		registrant is registering both a new netid and new uaddr format,
	then the registrant provides a value of TBD1 in the netid		then the registrant provides a value of TBD1 in the netid
	request, and uses TBD1 in the the uaddr format request. IANA		request, and uses TBD1 in the uaddr format request. IANA will
	will then substitute TBD1 for cross reference number IANA		then substitute TBD1 for the cross reference number IANA
	allocates. Note that if a document requests multiple netid and		allocates. Note that if a document requests multiple netid and
	uaddr assignments, each additional uaddr format cross reference		uaddr assignments, each additional uaddr format cross reference
	will be identified as TBD2, TBD3, ..., etc.		will be identified as TBD2, TBD3, ..., etc.
	4.1.1. Initial Registry		5.1.1. Initial Registry
	The initial list of netids is broken into two subregistries: those		The initial list of netids is broken into two subregistries: those
	assigned on a First Come First Serve basis in Table 1 and 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		assigned on a Standards Action basis in Table 2. These lists will
	change when IANA registers additional netids as needed, and the		change as IANA registers additional netids as needed, and the
	authoritative list of registered netids will always live with IANA.		authoritative list of registered netids will always live with IANA.
	+-------------+--------------+---------------------------+-----+----+		+-------------+--------------+---------------------------+-----+----+
	| Netid | Constant | Description and/or | PoC | CR |		| Netid | Constant | Description and/or | PoC | CR |
	| | Name | Reference | | |		| | Name | Reference | | |
	+-------------+--------------+---------------------------+-----+----+		+-------------+--------------+---------------------------+-----+----+
	| "-" | NC_NOPROTO | RFC1833 [2], | | 1 |		| "-" | NC_NOPROTO | RFC1833 [1], | | 1 |
	| | | Section 4.2.3.2 of | | |		| | | Section 5.2.3.2 of RFC | | |
	| | | RFCTBD2 | | |		| | | 5665 | | |
	| "ticlts" | NC_TICLTS | The loop back | | 0 |		| "ticlts" | NC_TICLTS | The loop back | | 0 |
	| | | connectionless transport | | |		| | | connectionless transport | | |
	| | | used in System V Release | | |		| | | used in System V Release | | |
	| | | 4 and other operating | | |		| | | 4 and other operating | | |
	| | | systems. Although this | | |		| | | systems. Although this | | |
	| | | assignment is made on a | | |		| | | assignment is made on a | | |
	| | | First Come First Served | | |		| | | First Come First Served | | |
	| | | basis and is fewer than | | |		| | | basis and is fewer than | | |
	| | | nine characters long, the | | |		| | | nine characters long, the | | |
	| | | exception is authorized. | | |		| | | exception is authorized. | | |
	| | | See [10]. | | |		| | | See [10]. | | |
	| "ticots" | NC_TICOTS | The loop back | | 0 |		| "ticots" | NC_TICOTS | The loop back | | 0 |
	| | | connection-oriented | | |		| | | connection-oriented | | |
	| | | transport used in System | | |		| | | transport used in System | | |
	| | | V Release 4 and other | | |		| | | V Release 4 and other | | |
	| | | operating systems. See | | |		| | | operating systems. See | | |
	| | | [10]. Although this | | |		| | | [10]. Although this | | |
	| | | assignment is made on a | | |		| | | assignment is made on a | | |
	| | | First Come First Served | | |		| | | First Come First Served | | |
	| | | basis and is fewer than | | |		| | | basis and is fewer than | | |
	| | | nine characters long, the | | |		| | | nine characters long, the | | |
	| | | exception is authorized. | | |		| | | exception is authorized. | | |
	| "ticotsord" | NC_TICOTSORD | The loop back | | 0 |		| "ticotsord" | NC_TICOTSORD | The loop back | | 0 |
	| | | connection-oriented with | | |		| | | connection-oriented with | | |
	| | | orderly-release transport | | |		| | | orderly-release transport | | |
	| | | used in System V Release | | |		| | | used in System V Release | | |
	| | | 4 and other operating | | |		| | | 4 and other operating | | |
	| | | systems. See [10]. | | |		| | | systems. See [10]. | | |
	+-------------+--------------+---------------------------+-----+----+		+-------------+--------------+---------------------------+-----+----+
	Table 1: Initial First Come First Serve Netid Assignments		Table 1: Initial First Come First Served Netid Assignments
	PoC: Point of Contact. CR: Cross Reference to the Uaddr Format		PoC: Point of Contact.
	Registry.
	+---------+-----------+---------------------------------+------+----+		CR: Cross Reference to the Uaddr Format Registry.
	| Netid | Constant | RFC(s) and Description (if | PoC | CR |
	| | Name | needed) | | |		+---------+----------+----------------------------------+------+----+
	+---------+-----------+---------------------------------+------+----+		| Netid | Constant | RFC(s) and Description (if | PoC | CR |
	| "rdma" | NC_RDMA | RFCTBD1 [6] RFC0791 [11] | IESG | 2 |		| | Name | needed) | | |
	| "rdma6" | NC_RDMA6 | RFCTBD1 [6] RFC2460 [12] | IESG | 3 |		+---------+----------+----------------------------------+------+----+
	| "sctp" | NC_SCTP | RFC4960 [7] RFC0791 [11] | IESG | 2 |		| "rdma" | NC_RDMA | RFC 5666 [6], RFC 791 [11] | IESG | 2 |
	| | | Section 2 of RFCTBD2 | | |		| "rdma6" | NC_RDMA6 | RFC 5666 [6], RFC 2460 [12] | IESG | 3 |
	| "sctp6" | NC_SCTP6 | RFC4960 [7] RFC2460 [12] | IESG | 3 |		| "sctp" | NC_SCTP | RFC 4960 [7], RFC 791 [11], | IESG | 2 |
	| | | Section 2 of RFCTBD2 | | |		| | | Section 3 of RFC 5665 | | |
	| "tcp" | NC_TCP | RFC0793 [13] RFC0791 [11] | IESG | 2 |		| "sctp6" | NC_SCTP6 | RFC 4960 [7], RFC 2460 [12], | IESG | 3 |
	| | | Section 10 of RFC1831 [4] | | |		| | | Section 3 of RFC 5665 | | |
	| "tcp6" | NC_TCP6 | RFC0793 [13] RFC2460 [12] | IESG | 3 |		| "tcp" | NC_TCP | RFC 793 [13], RFC 791 [11], | IESG | 2 |
	| | | Section 10 of RFC1831 [4] | | |		| | | Section 11 of RFC 5531 [4] | | |
	| "udp" | NC_UDP | RFC0768 [14] RFC0791 [11] | IESG | 2 |		| "tcp6" | NC_TCP6 | RFC 793 [13], RFC 2460 [12], | IESG | 3 |
	| "udp6" | NC_UDP6 | RFC0768 [14] RFC2460 [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		Table 2: Initial Standards Action Netid Assignments
	4.1.2. Updating Registrations		5.1.2. Updating Registrations
	Per section 5.2 of RFC5226 the registrant is always permitted to		Per Section 5.2 of RFC 5226, the registrant is always permitted to
	update a registration made on a First Come First Served basis		update a registration made on a First Come First Served basis
	"subject to the same constraints and review as with new		"subject to the same constraints and review as with new
	registrations." IESG or a Designated Expert is permitted to update		registrations". The IESG or a Designated Expert is permitted to
	any registration made on a First Come First Served basis, which		update any registration made on a First Come First Served basis,
	normally is done when the PoC cannot be reached in order to make		which normally is done when the PoC cannot be reached in order to
	necessary updates. Examples where an update would be needed include,		make necessary updates. Examples where an update would be needed
	but are not limited to: the email address or other contact		include, but are not limited to: the email address or other contact
	information becomes invalid; the reference to the corresponding		information becomes invalid; the reference to the corresponding
	protocol becomes obsolete or unavailable; and RFC1833 is updated or		protocol becomes obsolete or unavailable; RFC 1833 is updated or
	replaced in such a way that the scope of netids changes, requiring		replaced in such a way that the scope of netids changes, requiring
	additional fields in the assignment.		additional fields in the assignment.
	Only IESG, on the advice of a Designated Expert, can update a		Only the IESG, on the advice of a Designated Expert, can update a
	registration made on a Standards Action basis.		registration made on a Standards Action basis.
	4.2. IANA Considerations for Uaddr Formats		5.2. IANA Considerations for Uaddr Formats
	IANA will create a registry called "ONC RPC Uaddr Format Registry"		IANA has created a registry called "ONC RPC Uaddr Format Registry"
	(called the "format registry" for the remainder of this document).		(called the "format registry" for the remainder of this document).
	The remainder of this section describes the registry.		The remainder of this section describes the registry.
	All assignments to the format registry are made on one of two bases:		All assignments to the format registry are made on one of two bases:
	o First Come First Served basis per section 4.1 of RFC5226.		o First Come First Served basis per Section 4.1 of RFC 5226.
	o Standards Action per section 4.1 of RFC5226.		o Standards Action per Section 4.1 of RFC 5226.
	The registry of formats is a list of assignments, each containing		The registry of formats is a list of assignments, each containing
	four fields for each assignment.		four fields for each assignment.
	1. The basis for the assignment, which can be either FCFS for First		1. The basis for the assignment, which can be either FCFS for First
	Come First Served assignments, or STDS for Standards Action		Come First Served assignments or STDS for Standards Action
	assignments.		assignments.
	2. A description and/or reference to a description of the actual		2. A description and/or reference to a description of the actual
	uaddr format. Assignments made on a Standards Action basis		uaddr format. Assignments made on a Standards Action basis
	always have a reference to an RFC.		always have a reference to an RFC.
	3. For assignments made on a First Come First Served basis, a point		3. For assignments made on a First Come First Served basis, a point
	of contact, including an email address. Subject to authorization		of contact, including an email address. Subject to authorization
	by a Designated Expert, the point of contact may be omitted for		by a Designated Expert, the point of contact may be omitted for
	extraordinary situations, such as the registration of a commonly		extraordinary situations, such as the registration of a commonly
	used format where the owner is unknown. For assignments made on		used format where the owner is unknown. For assignments made on
	a Standards Action basis, the point of contact is always		a Standards Action basis, the point of contact is always
	determined by IESG.		determined by the IESG.
	4. A numerical value, used to cross reference the format assignment		4. A numerical value, used to cross reference the format assignment
	with an assignment in the netid registry. The registrant		with an assignment in the netid registry. The registrant
	provides a value of TBD1 for the cross reference field when		provides a value of TBD1 for the cross reference field when
	requesting an assignment. IANA will assign TBD1 to a real value.		requesting an assignment. IANA will assign TBD1 to a real value.
	Note that if a document requests multiple uaddr assignments, each		Note that if a document requests multiple uaddr assignments, each
	additional uaddr format cross reference will be identified as		additional uaddr format cross reference will be identified as
	TBD2, TBD3, ..., etc.		TBD2, TBD3, ..., etc.
	All requests for assignments to the format registry on a Standards		All requests for assignments to the format registry on a Standards
	Action basis are only for Standards Track RFCs approved by the IESG.		Action basis are only for Standards Track RFCs approved by the IESG.
	4.2.1. Initial Registry		5.2.1. Initial Registry
	The initial list of formats is in Table 3. This lists will change		The initial list of formats is in Table 3. This list will change as
	when IANA registers additional formats as needed, and the		IANA registers additional formats as needed, and the authoritative
	authoritative list of registered formats will always live with IANA.		list of registered formats will always live with IANA.
	+-------+-----------------------------------------------+------+----+		+-------+-----------------------------------------------+------+----+
	| Basis | Description and/or Reference | PoC | CR |		| Basis | Description and/or Reference | PoC | CR |
	+-------+-----------------------------------------------+------+----+		+-------+-----------------------------------------------+------+----+
	| FCFS | System V Release 4 loopback transport uaddr | | 0 |		| FCFS | System V Release 4 loopback transport uaddr | | 0 |
	| | format. Section 4.2.3.1 of RFCTBD2 | | |		| | format. Section 5.2.3.1 of RFC 5665 | | |
	| FCFS | Uaddr format for NC_NOPROTO. Section 4.2.3.2 | | 1 |		| FCFS | Uaddr format for NC_NOPROTO. Section 5.2.3.2 | | 1 |
	| | of RFCTBD2 | | |		| | of RFC 5665 | | |
	| STDS | Uaddr format for IPv4 transports. | IESG | 2 |		| STDS | Uaddr format for IPv4 transports. | IESG | 2 |
	| | Section 4.2.3.3 of RFCTBD2 | | |		| | Section 5.2.3.3 of RFC 5665 | | |
	| STDS | Uaddr format for IPv6 transports. | IESG | 3 |		| STDS | Uaddr format for IPv6 transports. | IESG | 3 |
	| | Section 4.2.3.4 of RFCTBD2 | | |		| | Section 5.2.3.4 of RFC 5665 | | |
	+-------+-----------------------------------------------+------+----+		+-------+-----------------------------------------------+------+----+
	Table 3: Initial Format Assignments		Table 3: Initial Format Assignments
	4.2.2. Updating Registrations		5.2.2. Updating Registrations
	The registrant is always permitted to update a registration made on a		The registrant is always permitted to update a registration made on a
	First Come First Served basis "subject to the same constraints and		First Come First Served basis "subject to the same constraints and
	review as with new registrations." IESG is permitted to update any		review as with new registrations." The IESG is permitted to update
	registration made on a First Come First Served basis, which normally		any registration made on a First Come First Served basis, which
	is done when the PoC cannot be reached in order to make necessary		normally is done when the PoC cannot be reached in order to make
	updates. Examples where an update would be needed include, but are		necessary updates. Examples where an update would be needed include,
	not limited to: the email address or other contact information		but are not limited to: the email address or other contact
	becomes invalid; the reference to the format description becomes		information becomes invalid; the reference to the format description
	obsolete or unavailable; and RFC1833 is updated or replaced in such a		becomes obsolete or unavailable; RFC 1833 is updated or replaced in
	way that the scope of uaddr formats changes, requiring additional		such a way that the scope of uaddr formats changes, requiring
	fields in the assignment.		additional fields in the assignment.
	Only IESG, on the advice of a Designated Expert, can update a		Only the IESG, on the advice of a Designated Expert, can update a
	registration made on a Standards Action basis.		registration made on a Standards Action basis.
	4.2.3. Uaddr Formats		5.2.3. Uaddr Formats
	4.2.3.1. Uaddr Format for System V Release 4 Loopback Transports		5.2.3.1. Uaddr Format for System V Release 4 Loopback Transports
	Although RFC1833 specifies the uaddr as the XDR data type string		Although RFC 1833 specifies the uaddr as the XDR data type string
	(hence, limited to US-ASCII), implementations of the System V Release		(hence, limited to US-ASCII), implementations of the System V Release
	4 loopback transports will use an opaque string of octets. Thus the		4 loopback transports will use an opaque string of octets. Thus, the
	format of a loopback transport address is any non-zero length array		format of a loopback transport address is any non-zero length array
	of octets.		of octets.
	4.2.3.2. Uaddr Format for Netid "-"		5.2.3.2. Uaddr Format for Netid "-"
	There is no address format for netid "-". This netid is apparently		There is no address format for netid "-". This netid is apparently
	for internal use for supporting some implementations of RFC1833.		for internal use for supporting some implementations of RFC 1833.
	4.2.3.3. Uaddr Format for Most IPv4 Transports		5.2.3.3. Uaddr Format for Most IPv4 Transports
	Most transport protocols that operate over IPv4 use 16 bit port		Most transport protocols that operate over IPv4 use 16-bit port
	numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14]. The		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		format of the uaddr for the above 16-bit port transports (when used
	over IPv4) is the US-ASCII string:		over IPv4) is the US-ASCII string:
	h1.h2.h3.h4.p1.p2		h1.h2.h3.h4.p1.p2
	The prefix, "h1.h2.h3.h4", is the standard textual form for		The prefix "h1.h2.h3.h4" is the standard textual form for
	representing an IPv4 address, which is always four octets long.		representing an IPv4 address, which is always four octets long.
	Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,		Assuming big-endian ordering, h1, h2, h3, and h4 are, respectively,
	the first through fourth octets each converted to ASCII-decimal. The		the first through fourth octets each converted to ASCII-decimal. The
	suffix, "p1.p2", is a textual form for representing a service port.		suffix "p1.p2" is a textual form for representing a service port.
	Assuming big-endian ordering, p1 and p2 are, respectively, the first		Assuming big-endian ordering, p1 and p2 are, respectively, the first
	and second octets each converted to ASCII-decimal. For example, if a		and second octets each converted to ASCII-decimal. For example, if a
	host, in big-endian order, has an address in hexadecimal of		host, in big-endian order, has an address in hexadecimal of
	0xC0000207 and there is a service listening on, in big endian order,		0xC0000207 and there is a service listening on, in big-endian order,
	port 0xCB51 (decimal 52049) then the complete uaddr is		port 0xCB51 (decimal 52049), then the complete uaddr is
	"192.0.2.7.203.81".		"192.0.2.7.203.81".
	4.2.3.4. Uaddr Format for Most IPv6 Transports		5.2.3.4. Uaddr Format for Most IPv6 Transports
	Most transport protocols that operate over IPv6 use 16 bit port		Most transport protocols that operate over IPv6 use 16-bit port
	numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14]. The		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		format of the uaddr for the above 16-bit port transports (when used
	over IPv6) is the US-ASCII string:		over IPv6) is the US-ASCII string:
	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		The suffix "p1.p2" is the service port, and is computed the same way
	as with uaddrs for transports over IPv4 (see Section 4.2.3.3). The		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		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 RFC4291		representing an IPv6 address as defined in Section 2.2 of RFC 4291
	[3]. Additionally, the two alternative forms specified in Section		[3]. Additionally, the two alternative forms specified in Section
	2.2 of RFC4291 are also acceptable.		2.2 of RFC 4291 are also acceptable.
	4.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6		5.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6
	As ICMP is not a true transport, there is no uaddr format for ICMP.		As ICMP is not a true transport, there is no uaddr format for ICMP.
	The netid assignments "icmp" and "icmp6" and their shared uaddr		The netid assignments "icmp" and "icmp6" and their shared uaddr
	"format" are listed to prevent any registrant from allocating the		"format" are listed to prevent any registrant from allocating the
	netids "icmp" and "icmp6" for a purpose that would likely cause		netids "icmp" and "icmp6" for a purpose that would likely cause
	confusion.		confusion.
	4.3. Cross Referencing Between the Netid and Format Registry		5.3. Cross Referencing between the Netid and Format Registry
	The last field of the netids registry is used to cross reference with		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		the last field of the format registry. IANA is under no obligation
	to maintain same numeric value in cross references when updating each		to maintain the same numeric values in cross references when updating
	registry; i.e. IANA is free to "re-number" these corresponding		each registry; i.e., IANA is free to "re-number" these corresponding
	fields. However, if IANA does so, both the netid and format		fields. However, if IANA does so, both the netid and format
	registries must be updated atomically.		registries must be updated atomically.
	4.4. Port Assignment for NFS over SCTP		5.4. Port Assignment for NFS over SCTP
	Port TBD100 is assigned to NFS over SCTP for the sctp and sctp6
	netids.
	5. References		Port 2049 is assigned to NFS over SCTP for the sctp and sctp6 netids.
	5.1. Normative References		6. References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		6.1. Normative References
	Levels", RFC 2119, March 1997.
	[2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",		[1] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
	RFC 1833, August 1995.		RFC 1833, August 1995.
			[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119, March 1997.
	[3] Hinden, R. and S. Deering, "IP Version 6 Addressing		[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
	5.2. Informative References		6.2. Informative References
	[4] Srinivasan, R., "RPC: Remote Procedure Call Protocol		[4] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification
	Specification Version 2", RFC 1831, August 1995.		Version 2", RFC 5531, May 2009.
	[5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,		[5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
	C., Eisler, M., and D. Noveck, "Network File System (NFS)		C., Eisler, M., and D. Noveck, "Network File System (NFS)
	version 4 Protocol", RFC 3530, April 2003.		version 4 Protocol", RFC 3530, April 2003.
	[6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access		[6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access
	Transport for Remote Procedure Call",		Transport for Remote Procedure Call", RFC 5666, January 2010.
	draft-ietf-nfsv4-rpcrdma-09 (work in progress), December 2008.
	[7] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,		[7] Stewart, R., Ed., "Stream Control Transmission Protocol",
	September 2007.		RFC 4960, September 2007.
	[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.		Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
	[9] Postel, J., "Internet Control Message Protocol", STD 5,		[9] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, September 1981.		RFC 792, September 1981.
	[10] American Telephone and Telegraph Company, "UNIX System V,		[10] American Telephone and Telegraph Company, "UNIX System V,
	Release 4 Programmer's Guide: Networking Interfaces, ISBN		Release 4 Programmer's Guide: Networking Interfaces, ISBN
	0139470786", 1990.		0139470786", 1990.
	skipping to change at page 12, line 34		skipping to change at page 14, line 5
	[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	[13] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,		[13] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
	September 1981.		September 1981.
	[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980.		August 1980.
	Appendix A. Acknowledgements		Appendix A. Acknowledgments
	Lisa Dusseault, Lars Eggert, Pasi Eronen, Tim Polk, Juergen		Lisa Dusseault, Lars Eggert, Pasi Eronen, Tim Polk, Juergen
	Schoenwaelder, and Robert Sparks reviewed the document and gave		Schoenwaelder, and Robert Sparks reviewed the document and gave
	valuable feed back.		valuable feedback.
	Appendix B. RFC Editor Notes
	[RFC Editor: please remove this section prior to publication.]
	[RFC Editor: Please replace occurrences of RFCTBD1 with the RFCxxxx
	where xxxx is the RFC number assigned to the document referenced in
	[6].]
	[RFC Editor: Please replace occurrences of RFCTBD2 with the RFCyyyy
	where yyyy is the RFC number assigned to this document.]
	[IANA: Please use port 2049 for NFS/SCTP, as this is consistent with
	NFS/TCP and NFS/UDP.]
	[RFC Editor: Please replace occurrences of TBD100 with port assigned
	to SCTP over NFS.]
	Author's Address		Author's Address
	Mike Eisler		Mike Eisler
	NetApp		NetApp
	5765 Chase Point Circle		5765 Chase Point Circle
	Colorado Springs, CO 80919		Colorado Springs, CO 80919
	US		US
	Phone: +1-719-599-9026		Phone: +1-719-599-9026
	Email: mike@eisler.com		EMail: mike@eisler.com
End of changes. 98 change blocks.
	238 lines changed or deleted		223 lines changed or added
This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/