draft-ietf-nfsv4-rpc-iana-02.txt   draft-ietf-nfsv4-rpc-iana-03.txt 
Network Working Group Robert Thurlow Network Working Group Robert Thurlow
Document: draft-ietf-nfsv4-rpc-iana-02.txt Document: draft-ietf-nfsv4-rpc-iana-03.txt
RPC Numbering Authority Transfer to IANA RPC Numbering Authority Transfer to IANA
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, I certify that any applicable
of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
document will expire in March, 2005. Distribution of this draft is document will expire in August, 2005. Distribution of this draft is
unlimited. unlimited.
Abstract Abstract
Network services based on RPC [RFC1831] use program numbers rather Network services based on RPC [RFC1831] use program numbers rather
than well known transport ports to permit clients to find them, and than well known transport ports to permit clients to find them, and
use authentication flavor numbers to define the format of the use authentication flavor numbers to define the format of the
authentication data passed. The assignment of RPC program numbers authentication data passed. The assignment of RPC program numbers
and authentication flavor numbers is still performed by Sun and authentication flavor numbers is still performed by Sun
Microsystems, Inc. This is inappropriate for an IETF standard Microsystems, Inc. This is inappropriate for an IETF standard
protocol, as such work is done well by the Internet Assigned Numbers protocol, as such work is done well by the Internet Assigned Numbers
Authority (IANA). This document defines how IANA will maintain and Authority (IANA). This document defines how IANA will maintain and
assign RPC program numbers and authentication flavor numbers. assign RPC program numbers and authentication flavor numbers.
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Past Sun Assignment Practice . . . . . . . . . . . . . . . . 3 2. Past Sun Assignment Practice . . . . . . . . . . . . . . . . 3
2.1. RPC Program Numbers . . . . . . . . . . . . . . . . . . . 3 2.1. RPC Program Numbers . . . . . . . . . . . . . . . . . . . 3
2.1.1. RPC Program Number Assignments . . . . . . . . . . . . . 3 2.1.1. RPC Program Number Assignments . . . . . . . . . . . . . 3
2.1.2. RPC Program Protocol Definitions . . . . . . . . . . . . 4 2.1.2. RPC Program Protocol Definitions . . . . . . . . . . . . 4
2.1.3. RPC Program Numbers Actually Assigned . . . . . . . . . 4 2.1.3. RPC Program Numbers Actually Assigned . . . . . . . . . 4
2.2. RPC Authentication Flavor Numbers . . . . . . . . . . . . 4 2.2. RPC Authentication Flavor Numbers . . . . . . . . . . . . 4
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3.2. RPC Number Assignment . . . . . . . . . . . . . . . . . . 5 3.2. RPC Number Assignment . . . . . . . . . . . . . . . . . . 5
3.2.1. To be assigned by IANA . . . . . . . . . . . . . . . . . 5 3.2.1. To be assigned by IANA . . . . . . . . . . . . . . . . . 5
3.2.2. Defined by local administrator . . . . . . . . . . . . . 5 3.2.2. Defined by local administrator . . . . . . . . . . . . . 5
3.2.3. Transient block . . . . . . . . . . . . . . . . . . . . 6 3.2.3. Transient block . . . . . . . . . . . . . . . . . . . . 6
3.2.4. Reserved block . . . . . . . . . . . . . . . . . . . . . 6 3.2.4. Reserved block . . . . . . . . . . . . . . . . . . . . . 6
3.2.5. RPC Number Sub-Blocks . . . . . . . . . . . . . . . . . 6 3.2.5. RPC Number Sub-Blocks . . . . . . . . . . . . . . . . . 6
3.2.6. Information Necessary To Grant RPC Program Numbers . . . 8 3.2.6. Information Necessary To Grant RPC Program Numbers . . . 8
3.3. RPC Authentication Flavor Number Assignment . . . . . . . 9 3.3. RPC Authentication Flavor Number Assignment . . . . . . . 9
3.3.1. Information Necessary To Grant RPC Authentication Flavor 3.3.1. Information Necessary To Grant RPC Authentication Flavor
Numbers . . . . . . . . . . . . . . . . . . . . . . . . 9 Numbers . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . 10
5. Author's Address . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
6. Full Copyright Statement . . . . . . . . . . . . . . . . . 10
7. Intellectual property . . . . . . . . . . . . . . . . . . 10
8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 11
9. Author's Address . . . . . . . . . . . . . . . . . . . . . 13
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
1. Introduction 1. Introduction
This procedure will explain how RPC number assignments have been made This procedure will explain how RPC number assignments have been made
in the past and how they should be made in the future in order to in the past and how they should be made in the future in order to
transfer the authority for assigning RPC program and authentication transfer the authority for assigning RPC program and authentication
flavor numbers from Sun Microsystems to IANA (the Internet Assigned flavor numbers from Sun Microsystems to IANA (the Internet Assigned
Number Authority). Users of RPC protocols will benefit by having an Number Authority). Users of RPC protocols will benefit by having an
independent body responsible for RPC number assignments. independent body responsible for RPC number assignments.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
0xe0000000 - 0xffffffff reserved 0xe0000000 - 0xffffffff reserved
The "defined by user" block was not managed by Sun, but was intended The "defined by user" block was not managed by Sun, but was intended
for controlled use by local administrative domains in a manner for controlled use by local administrative domains in a manner
similar to the "Defined by local administrator" block proposed in similar to the "Defined by local administrator" block proposed in
Section 3.2.2. The "transient" block was intended to be used Section 3.2.2. The "transient" block was intended to be used
dynamically by applications which prearranged a particular program dynamically by applications which prearranged a particular program
number and used it only while the application was in use. This is number and used it only while the application was in use. This is
similar to the "Transient" block proposed in Section 3.2.3. similar to the "Transient" block proposed in Section 3.2.3.
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
2.1.2. RPC Program Protocol Definitions 2.1.2. RPC Program Protocol Definitions
Sun Microsystems, Inc.'s former policy was to ask for RPC protocol Sun Microsystems, Inc.'s former policy was to ask for RPC protocol
definitions in XDR definition language [RFC1833]. This information definitions in XDR definition language [RFC1833]. This information
was not useful, and was in some cases proprietary. Sun will not was not useful, and was in some cases proprietary. Sun will not
transfer such definitions to IANA; the choice to publish such transfer such definitions to IANA; the choice to publish such
protocols is left to the owner of the protocol. protocols is left to the owner of the protocol.
2.1.3. RPC Program Numbers Actually Assigned 2.1.3. RPC Program Numbers Actually Assigned
skipping to change at page 5, line 5 skipping to change at page 5, line 5
3. Proposed IANA Assignment Practice 3. Proposed IANA Assignment Practice
3.1. Protecting Past Assignments 3.1. Protecting Past Assignments
Sun has made assignments in both number spaces since the original Sun has made assignments in both number spaces since the original
deployment of RPC. The assignments made by Sun Microsystems are deployment of RPC. The assignments made by Sun Microsystems are
still valid, and existing holders of number assignments from this still valid, and existing holders of number assignments from this
range do not need to reapply for numbers. The conventions and range do not need to reapply for numbers. The conventions and
procedures for future assignments must account for the protection of procedures for future assignments must account for the protection of
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
these numbers. Sun will communicate all current assignments in both these numbers. Sun will communicate all current assignments in both
number spaces to IANA before final handoff of number assignment is number spaces to IANA before final handoff of number assignment is
done. done.
3.2. RPC Number Assignment 3.2. RPC Number Assignment
Future IANA practice should deal with the following partitioning of Future IANA practice should deal with the following partitioning of
the 32-bit number space: the 32-bit number space:
skipping to change at page 6, line 5 skipping to change at page 6, line 5
of RPC numbers from the range. The local domain should be of RPC numbers from the range. The local domain should be
sufficiently isolated that it would be unlikely that RPC applications sufficiently isolated that it would be unlikely that RPC applications
developed by other local domains could communicate with the domain. developed by other local domains could communicate with the domain.
This could result in RPC number contention, which would cause one of This could result in RPC number contention, which would cause one of
the applications to fail. In the absence of a local administrator, the applications to fail. In the absence of a local administrator,
this block can be utilized in a "Private Use" manner per [RFC2434]. this block can be utilized in a "Private Use" manner per [RFC2434].
Note1: Sun delegated a small number of large RPC blocks in this Note1: Sun delegated a small number of large RPC blocks in this
range; see Section 2.1.3. range; see Section 2.1.3.
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
3.2.3. Transient block 3.2.3. Transient block
The "Transient" block can be used by any RPC application on a "as The "Transient" block can be used by any RPC application on a "as
available" basis. This range is intended for services that can available" basis. This range is intended for services that can
communicate a dynamically selected RPC program number to clients of communicate a dynamically selected RPC program number to clients of
the service. Any mechanism can be used to communicate the number. the service. Any mechanism can be used to communicate the number.
Examples include shared memory when the client and server are located Examples include shared memory when the client and server are located
on the same system, or a network message (either RPC or otherwise) on the same system, or a network message (either RPC or otherwise)
that disseminates the selected number. that disseminates the selected number.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
a mechanism must be implemented to multiplex RPC requests amongst a mechanism must be implemented to multiplex RPC requests amongst
various instances of the service, or unique RPC numbers must be used various instances of the service, or unique RPC numbers must be used
by each instance. by each instance.
In these cases, the RPC protocol used with the various numbers may be In these cases, the RPC protocol used with the various numbers may be
different or the same. The numbers may be assigned dynamically by different or the same. The numbers may be assigned dynamically by
the application, or as part of a site-specific administrative the application, or as part of a site-specific administrative
decision. If possible, RPC services that dynamically assign RPC decision. If possible, RPC services that dynamically assign RPC
numbers should use the "Transient" RPC number block defined in numbers should use the "Transient" RPC number block defined in
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
section 2. If not possible, RPC number sub-blocks may be requested. section 2. If not possible, RPC number sub-blocks may be requested.
Assignment of RPC Number Sub-Blocks is controlled by the size of the Assignment of RPC Number Sub-Blocks is controlled by the size of the
sub-block being requested. "Specification Required" and "IESG sub-block being requested. "Specification Required" and "IESG
Approval" are used as defined by [RFC2434] Section 2. Approval" are used as defined by [RFC2434] Section 2.
Size of sub-block Assignment Method Authority Size of sub-block Assignment Method Authority
----------------- ----------------- --------- ----------------- ----------------- ---------
Up to 100 numbers First Come First Served IANA Up to 100 numbers First Come First Served IANA
skipping to change at page 8, line 5 skipping to change at page 8, line 5
individual or entity. For example, if an individual or entity first individual or entity. For example, if an individual or entity first
requests say 70 numbers, and then later requests 40 numbers, then the requests say 70 numbers, and then later requests 40 numbers, then the
request for the 40 numbers will be assigned via the Specification request for the 40 numbers will be assigned via the Specification
Required method. As long as the total number of numbers assigned Required method. As long as the total number of numbers assigned
does not exceed 1000, IANA is free to waive the Specification does not exceed 1000, IANA is free to waive the Specification
Required assignment for incremental requests of less than 100 Required assignment for incremental requests of less than 100
numbers. numbers.
If an individual or entity has under 1000 numbers and later requests If an individual or entity has under 1000 numbers and later requests
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
an additional set of numbers such that the individual or entity would an additional set of numbers such that the individual or entity would
over 1000 numbers, then the individual or entity will have the over 1000 numbers, then the individual or entity will have the
additional request submitted to the IESG. IESG is free to waive the additional request submitted to the IESG. IESG is free to waive the
IESG Action Required assignment method for incremental requests of IESG Action Required assignment method for incremental requests of
less than 1000 numbers. less than 1000 numbers.
3.2.6. Information Necessary To Grant RPC Program Numbers 3.2.6. Information Necessary To Grant RPC Program Numbers
[RFC1831bis] describes how users request new RPC program numbers. If [RFC1831bis] describes how users request new RPC program numbers. If
skipping to change at page 9, line 5 skipping to change at page 9, line 5
In most cases, interested parties only need to know the name of the In most cases, interested parties only need to know the name of the
RPC service using the number. IANA will make this list available RPC service using the number. IANA will make this list available
through publication or other means to allow for lookup of RPC through publication or other means to allow for lookup of RPC
services by RPC number. To be effective, this requires that the services by RPC number. To be effective, this requires that the
"identifier string" be meaningful. The string should clearly "identifier string" be meaningful. The string should clearly
identify the RPC service or application with which the RPC number is identify the RPC service or application with which the RPC number is
to be associated. Sites supporting RPC services typically publish a to be associated. Sites supporting RPC services typically publish a
mapping of RPC numbers to RPC identifiers. For example, UNIX systems mapping of RPC numbers to RPC identifiers. For example, UNIX systems
publish this mapping in the file "/etc/rpc". publish this mapping in the file "/etc/rpc".
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
3.3. RPC Authentication Flavor Number Assignment 3.3. RPC Authentication Flavor Number Assignment
The second number space is the authentication mechanism identifier, The second number space is the authentication mechanism identifier,
or "flavor", number. This number is used to distinguish between or "flavor", number. This number is used to distinguish between
various authentication mechanisms which can be optionally used with various authentication mechanisms which can be optionally used with
an RPC message. An authentication identifier is used in the "flavor" an RPC message. An authentication identifier is used in the "flavor"
field of the "opaque_auth" structure. field of the "opaque_auth" structure.
Recent progress in RPC security has focused on using the existing Recent progress in RPC security has focused on using the existing
skipping to change at page 10, line 5 skipping to change at page 10, line 5
o A description of the authentication flavor. o A description of the authentication flavor.
o If the authentication flavor is a 'pseudo-flavor' intended for o If the authentication flavor is a 'pseudo-flavor' intended for
use with RPCSEC_GSS and NFS, mappings analogous to those in use with RPCSEC_GSS and NFS, mappings analogous to those in
Section 4.2 of [RFC2623] are required. Section 4.2 of [RFC2623] are required.
For authentication flavors to be used on the Internet, it is strongly For authentication flavors to be used on the Internet, it is strongly
advised that an informational or standards-track RFC be published advised that an informational or standards-track RFC be published
describing the authentication mechanism behaviour and parameters. describing the authentication mechanism behaviour and parameters.
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
4. Bibliography 4. Security Considerations
This document has no impact on RPC security; please see [RFC1831bis]
and [RFC2623] for information about ROC security.
5. IANA Considerations
This entire document discusses a transition of a numbering service to
IANA, so this section needs nothing further.
6. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
7. Intellectual property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Title RPC Numbering Authority Transfer to IANA February 2005
8. Bibliography
[RFC1057] [RFC1057]
Sun Microsystems Inc., "RPC: Remote Procedure Call Protocol Sun Microsystems Inc., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1057, August 1995. Specification Version 2", RFC 1057, August 1995.
[RFC1831] [RFC1831]
R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC 1831, August 1995. Version 2", RFC 1831, August 1995.
[RFC1832] [RFC1832]
skipping to change at page 11, line 5 skipping to change at page 12, line 5
Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999. Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999.
[RFC2695] [RFC2695]
A. Chiu, "Authentication Mechanisms for ONC RPC", RFC 2695, September A. Chiu, "Authentication Mechanisms for ONC RPC", RFC 2695, September
1999. 1999.
[RFC1094] [RFC1094]
Sun Microsystems, Inc., "NFS: Network File System Protocol Sun Microsystems, Inc., "NFS: Network File System Protocol
Specification", RFC 1094, March 1989. Specification", RFC 1094, March 1989.
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
[RFC1813] [RFC1813]
B. Callaghan, B. Pawlowski. P. Staubach, "NFS Version 3 Protocol B. Callaghan, B. Pawlowski. P. Staubach, "NFS Version 3 Protocol
Specification", RFC 1813, June 1995. Specification", RFC 1813, June 1995.
[RFC3010] [RFC3010]
S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M.
Eisler, D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000. Eisler, D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000.
[RFC1831bis] [RFC1831bis]
R. Thurlow, "RPC: Remote Procedure Call Protocol Specification R. Thurlow, "RPC: Remote Procedure Call Protocol Specification
Version 2", draft-ietf-nfsv4-rfc1831bis-04.txt, March 2005. Version 2", draft-ietf-nfsv4-rfc1831bis-05.txt, February 2005.
Title RPC Numbering Authority Transfer to IANA September 2004 Title RPC Numbering Authority Transfer to IANA February 2005
5. Author's Address 9. Author's Address
Address comments related to this memorandum to: Address comments related to this memorandum to:
nfsv4-wg@sunroof.eng.sun.com nfsv4-wg@sunroof.eng.sun.com
Robert Thurlow Robert Thurlow
Sun Microsystems, Inc. Sun Microsystems, Inc.
500 Eldorado Boulevard, UBRM05-171 500 Eldorado Boulevard, UBRM05-171
Broomfield, CO 80021 Broomfield, CO 80021
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/