draft-ietf-nfsv4-rpc-netid-03.txt		draft-ietf-nfsv4-rpc-netid-04.txt
	NFSv4 M. Eisler		NFSv4 M. Eisler
	Internet-Draft NetApp		Internet-Draft NetApp
	Updates: 1833 (if approved) August 19, 2008		Updates: 1833 (if approved) December 3, 2008
	Intended status: Standards Track		Intended status: Standards Track
	Expires: February 20, 2009		Expires: June 6, 2009
	IANA Considerations for RPC Net Identifiers and Universal Address		IANA Considerations for RPC Net Identifiers and Universal Address
	Formats		Formats
	draft-ietf-nfsv4-rpc-netid-03.txt		draft-ietf-nfsv4-rpc-netid-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on February 20, 2009.		This Internet-Draft will expire on June 6, 2009.
	Abstract		Abstract
	This Internet-Draft lists IANA Considerations for RPC Network		This Internet-Draft lists IANA Considerations for RPC Network
	Identifiers (netids) and RPC Universal Network Addresses (uaddrs).		Identifiers (netids) and RPC Universal Network Addresses (uaddrs).
	This Internet-Draft updates, but does not replace, RFC1833.		This Internet-Draft updates, but does not replace, RFC1833.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].		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. Security Considerations . . . . . . . . . . . . . . . . . . . 3		2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3		3. Security Considerations . . . . . . . . . . . . . . . . . . . 3
	3.1. IANA Considerations for Netids . . . . . . . . . . . . . . 3		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
	3.1.1. Initial Registry . . . . . . . . . . . . . . . . . . . 5		4.1. IANA Considerations for Netids . . . . . . . . . . . . . . 3
	3.1.2. Updating Registrations . . . . . . . . . . . . . . . . 7		4.1.1. Initial Registry . . . . . . . . . . . . . . . . . . . 5
	3.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 7		4.1.2. Updating Registrations . . . . . . . . . . . . . . . . 7
	3.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 8		4.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 7
	3.2.2. Updating Registrations . . . . . . . . . . . . . . . . 8		4.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 8
	3.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 9		4.2.2. Updating Registrations . . . . . . . . . . . . . . . . 9
	3.3. Cross Referencing Between the Netid and Format Registry . 10		4.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 9
	4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.3. Cross Referencing Between the Netid and Format Registry . 10
	4.1. Normative References . . . . . . . . . . . . . . . . . . . 10		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.2. Informative References . . . . . . . . . . . . . . . . . . 10		5.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	Appendix A. RFC Editor Notes . . . . . . . . . . . . . . . . . . 11		5.2. Informative References . . . . . . . . . . . . . . . . . . 11
			Appendix A. RFC Editor Notes . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . . . 13		Intellectual Property and Copyright Statements . . . . . . . . . . 13
	1. Introduction and Motivation		1. Introduction and Motivation
	The concepts of an RPC [4] Network Identifier (netid) and an RPC		The concepts of an RPC (defined in RFC1831 [4]) Network Identifier
	Universal Address (uaddr) were introduced in [2] for distinguishing		(netid) and an RPC Universal Address (uaddr) were introduced in
	network addresses of multiple protocols and representing those		RFC1833 [2] for distinguishing network addresses of multiple
	addresses in a canonical form. [2] states that a netid ``is defined		protocols and representing those addresses in a canonical form.
	by a system administrator based on local conventions, and cannot be		RFC1833 states that a netid ``is defined by a system administrator
	depended on to have the same value on every system.'' (The netid is		based on local conventions, and cannot be depended on to have the
	contained in the field r_netid of the data type rpcb_entry, and the		same value on every system.'' (The netid is contained in the field
	uaddr is contained in the field r_addr of the same data type, where		r_netid of the data type rpcb_entry, and the uaddr is contained in
	rpcb_entry is defined in [2].) Since the publication of [2], it has		the field r_addr of the same data type, where rpcb_entry is defined
	been found to be necessary that protocols like [5] and [6] depend on		in RFC1833.) Since the publication of RFC1833, it has been found
	consistent values of netids and representations of uaddrs. Current		that protocols like NFSv4.0 [5] and RPC/RDMA [6] depend on consistent
	practices tend to ensure this consistency. Thus, this document		values of netids and representations of uaddrs. Current practices
	identifies the considerations for IANA to establish registries of		tend to ensure this consistency. Thus, this document identifies the
	netids and uaddr formats for RPC and specifies the initial content of		considerations for IANA to establish registries of netids and uaddr
	the two registries.		formats for RPC and specifies the initial content of the two
			registries.
	2. Security Considerations		2. Acknowledgements
	See section 9 of [7].		Lars Eggert and Juergen Schoenwaelder reviewed the document and gave
			valuable feed back for improving its readability.
	3. IANA Considerations		3. Security Considerations
	This section uses terms that are defined in [7].		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.
	3.1. IANA Considerations for Netids		4. IANA Considerations
			This section uses terms that are defined in RFC5226 [7].
			4.1. IANA Considerations for Netids
	IANA will create a registry called "ONC RPC Netids". The remainder		IANA will create 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 First Come First Served basis per section 4.1 of [7].		o First Come First Served basis per section 4.1 of RFC5226.
	o Standards Action per section 4.1 of [7].		o Standards Action per section 4.1 of RFC5226.
	Netids can be up to 2^32 - 1 octets in length. However, to ensure		Netids can be up to 2^32 - 1 octets in length. However, to ensure
	that practical values for Standards Track protocols are not		that practical values for Standards Track protocols are not
	exhausted, the values of netids one to eight octets long should be		exhausted, the values of netids one to eight octets long should be
	used for netids assigned on the Standards Action basis. Assignments		used for netids assigned on the Standards Action basis. Assignments
	made on a First Come First Served basis should be assigned netids of		made on a First Come First Served basis should be assigned netids of
	length 9 to 128 octets long. All netids, regardless of length, that		length 9 to 128 octets long. All netids, regardless of length, that
	start with the prefixes "STDS" or "FCFS" are Reserved, in order to		start with the prefixes "STDS" or "FCFS" are Reserved, in order to
	extend the name space of either basis. In addition, to give IESG the		extend the name space of either basis. In addition, to give IESG the
	flexibility in the future to permit Private and Experimental Uses,		flexibility in the future to permit Private and Experimental Uses,
	skipping to change at page 5, line 15		skipping to change at page 5, line 24
	* 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 IESG.		contact is always 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 3.2). If the registrant is registering a netid that		Section 4.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 the uaddr format request. IANA
	will then substitute TBD1 for cross reference number IANA		will then substitute TBD1 for cross reference number IANA
	allocates.		allocates.
	3.1.1. Initial Registry		4.1.1. Initial Registry
	The initial list of netids is broken into those assigned on a First		The initial list of netids is broken into those assigned on a First
	Come First Serve basis in Table 1 and those assigned on a Standards		Come First Serve basis in Table 1 and those assigned on a Standards
	Action basis in Table 2. These lists will change when IANA registers		Action basis in Table 2. These lists will change when IANA registers
	additional netids as needed, and the authoritative list of registered		additional netids as needed, and the authoritative list of registered
	netids will always live with IANA.		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 [2], | | 1 |
	| | | Section 3.2.3.2 of | | |		| | | Section 4.2.3.2 of | | |
	| | | RFCTBD2 | | |		| | | RFCTBD2 | | |
	| "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 9 | | |		| | | basis and is fewer than 9 | | |
	| | | characters long, the | | |		| | | characters long, the | | |
	skipping to change at page 7, line 5		skipping to change at page 7, line 25
	| "sctp" | NC_SCTP | RFC2960 [13] RFC0760 [10] | IESG | 2 |		| "sctp" | NC_SCTP | RFC2960 [13] RFC0760 [10] | IESG | 2 |
	| "sctp6" | NC_SCTP6 | RFC2960 [13] RFC2460 [11] | IESG | 3 |		| "sctp6" | NC_SCTP6 | RFC2960 [13] RFC2460 [11] | IESG | 3 |
	| "tcp" | NC_TCP | RFC0675 [14] RFC0760 [10] | IESG | 2 |		| "tcp" | NC_TCP | RFC0675 [14] RFC0760 [10] | IESG | 2 |
	| "tcp6" | NC_TCP6 | RFC0675 [14] RFC2460 [11] | IESG | 3 |		| "tcp6" | NC_TCP6 | RFC0675 [14] RFC2460 [11] | IESG | 3 |
	| "udp" | NC_UDP | RFC0768 [15] RFC0760 [10] | IESG | 2 |		| "udp" | NC_UDP | RFC0768 [15] RFC0760 [10] | IESG | 2 |
	| "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [11] | IESG | 3 |		| "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [11] | IESG | 3 |
	+---------+--------------+------------------------------+------+----+		+---------+--------------+------------------------------+------+----+
	Table 2: Initial Standards Action Netid Assignments		Table 2: Initial Standards Action Netid Assignments
	3.1.2. Updating Registrations		4.1.2. Updating Registrations
	Per section 5.2 of [7] the registrant is always permitted to update a		Per section 5.2 of RFC5226 the registrant is always permitted to
	registration made on a First Come First Served basis "subject to the		update a registration made on a First Come First Served basis
	same constraints and review as with new registrations." IESG or a		"subject to the same constraints and review as with new
	Designated Expert is permitted to update any registration made on a		registrations." IESG or a Designated Expert is permitted to update
	First Come First Served basis, which normally is done when the PoC		any registration made on a First Come First Served basis, which
	cannot be reached in order to make necessary updates. Examples where		normally is done when the PoC cannot be reached in order to make
	an update would be needed include, but are not limited to: the email		necessary updates. Examples where an update would be needed include,
	address or other contact information becomes invalid; the reference		but are not limited to: the email address or other contact
	to the corresponding protocol becomes obsolete or unavailable; and		information becomes invalid; the reference to the corresponding
	RFC1833 [2] is updated or replaced in such a way that the scope of		protocol becomes obsolete or unavailable; and RFC1833 is updated or
	netids changes, requiring additional fields in the assignment.		replaced in such a way that the scope of netids changes, requiring
			additional fields in the assignment.
	Only IESG, on the advice of a Designated Expert, can update a		Only 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.
	3.2. IANA Considerations for Uaddr Formats		4.2. IANA Considerations for Uaddr Formats
	IANA will create a registry called "ONC RPC Uaddr Format Registry"		IANA will create 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 [7].		o First Come First Served basis per section 4.1 of RFC5226.
	o Standards Action per section 4.1 of [7].		o Standards Action per section 4.1 of RFC5226.
	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
	skipping to change at page 8, line 15		skipping to change at page 8, line 37
	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 filed when		provides a value of TBD1 for the cross reference filed when
	requesting an assignment. IANA will assign TBD1 to a real value.		requesting an assignment. IANA will assign TBD1 to a real value.
	All requests for assignments to the format registry must undergo		All requests for assignments to the format registry must undergo
	Expert Review. All requests for assignments made on a Standards		Expert Review. All requests for assignments made on a Standards
	Action basis must be approved by IESG.		Action basis must be approved by IESG.
	3.2.1. Initial Registry		4.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 lists will change
	when IANA registers additional formats as needed, and the		when IANA registers additional formats as needed, and the
	authoritative list of registered formats will always live with IANA.		authoritative 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 3.2.3.1 of RFCTBD2 | | |		| | format. Section 4.2.3.1 of RFCTBD2 | | |
	| FCFS | Uaddr format for NC_NOPROTO. Section 3.2.3.2 | | 1 |		| FCFS | Uaddr format for NC_NOPROTO. Section 4.2.3.2 | | 1 |
	| | of RFCTBD2 | | |		| | of RFCTBD2 | | |
	| STDS | Uaddr format for IPv4 transports. | IESG | 2 |		| STDS | Uaddr format for IPv4 transports. | IESG | 2 |
	| | Section 3.2.3.3 of RFCTBD2 | | |		| | Section 4.2.3.3 of RFCTBD2 | | |
	| STDS | Uaddr format for IPv6 transports. | IESG | 3 |		| STDS | Uaddr format for IPv6 transports. | IESG | 3 |
	| | Section 3.2.3.4 of RFCTBD2 | | |		| | Section 4.2.3.4 of RFCTBD2 | | |
	| STDS | Uaddr formation for ICMP. Section 3.2.3.5 of | IESG | 4 |		| STDS | Uaddr formation for ICMP. Section 4.2.3.5 of | IESG | 4 |
	| | RFCTBD2 | | |		| | RFCTBD2 | | |
	+-------+-----------------------------------------------+------+----+		+-------+-----------------------------------------------+------+----+
	Table 3: Initial Format Assignments		Table 3: Initial Format Assignments
	3.2.2. Updating Registrations		4.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.", but as with new registrations,		review as with new registrations.", but as with new registrations,
	any requested changes to any field other the point of contact		any requested changes to any field other the point of contact
	requires Expert Review. IESG or a Designated Expert is permitted to		requires Expert Review. IESG or a Designated Expert is permitted to
	update any registration made on a First Come First Served basis,		update any registration made on a First Come First Served basis,
	which normally is done when the PoC cannot be reached in order to		which normally is done when the PoC cannot be reached in order to
	make necessary updates. Examples where an update would be needed		make necessary updates. Examples where an update would be needed
	include, 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 format description		information becomes invalid; the reference to the format description
	becomes obsolete or unavailable; and RFC1833 [2] is updated or		becomes obsolete or unavailable; and RFC1833 is updated or replaced
	replaced in such a way that the scope of uaddr formats changes,		in such a way that the scope of uaddr formats changes, requiring
	requiring additional fields in the assignment.		additional fields in the assignment.
	Only IESG, on the advice of a Designated Expert, can update a		Only 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.
	3.2.3. Uaddr Formats		4.2.3. Uaddr Formats
	3.2.3.1. Uaddr Format for System V Release 4 Loopback Transports		4.2.3.1. Uaddr Format for System V Release 4 Loopback Transports
	Although [2] identifies the uaddr as data type string (hence, limited		Although RFC1833 specifies the uaddr as the XDR data type string
	to US-ASCII), implementations of the System V Release 4 loopback		(hence, limited to US-ASCII), implementations of the System V Release
	transports will use an opaque string of octets. Thus format of a		4 loopback transports will use an opaque string of octets. Thus the
	loopback transport address is any non-zero length array of octets.		format of a loopback transport address is any non-zero length array
			of octets.
	3.2.3.2. Uaddr Format for Netid "-"		4.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 [2].		for internal use for supporting some implementations of RFC1833.
	3.2.3.3. Uaddr Format for Most IPv4 Transports		4.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 DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP		numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP
	[15]. The format of the uaddr for the above 16 bit port transports		[15]. The format of the uaddr for the above 16 bit port transports
	(when used over IPv4) is the US-ASCII string:		(when used 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".
	3.2.3.4. Uaddr Format for Most IPv6 Transports		4.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 DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP		numbers, including DCCP [9], RDMA [6], SCTP [13], TCP [14], and UDP
	[15]. The format of the uaddr for the above 16 bit port transports		[15]. The format of the uaddr for the above 16 bit port transports
	(when used over IPv6) is the US-ASCII string:		(when used 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 3.2.3.3). The		as with uaddrs for transports over IPv4 (see Section 4.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 [3].		representing an IPv6 address as defined in Section 2.2 of RFC4291
	Additionally, the two alternative forms specified in Section 2.2 of		[3]. Additionally, the two alternative forms specified in Section
	[3] are also acceptable.		2.2 of RFC4291 are also acceptable.
	3.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6		4.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.
	3.3. Cross Referencing Between the Netid and Format Registry		4.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 same numeric value in cross references when updating each
	registry; i.e. IANA is free to "re-number" these corresponding		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. References		5. References
	4.1. Normative References		5.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997.		Levels", RFC 2119, March 1997.
	[2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",		[2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
	RFC 1833, August 1995.		RFC 1833, August 1995.
	[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.
	4.2. Informative References		5.2. Informative References
	[4] Srinivasan, R., "RPC: Remote Procedure Call Protocol		[4] Srinivasan, R., "RPC: Remote Procedure Call Protocol
	Specification Version 2", RFC 1831, August 1995.		Specification Version 2", RFC 1831, August 1995.
	[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",
End of changes. 41 change blocks.
	87 lines changed or deleted		98 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/