idnits 2.17.1 draft-ietf-nfsv4-rpc-iana-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC1831]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 97 has weird spacing: '...fffffff defi...' == Line 98 has weird spacing: '...fffffff defi...' == Line 99 has weird spacing: '...fffffff tran...' == Line 100 has weird spacing: '...fffffff rese...' == Line 101 has weird spacing: '...fffffff rese...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2004) is 7283 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1831' on line 399 looks like a reference -- Missing reference section? 'RFC1833' on line 407 looks like a reference -- Missing reference section? 'RFC1057' on line 395 looks like a reference -- Missing reference section? 'RFC2203' on line 411 looks like a reference -- Missing reference section? 'RFC2623' on line 419 looks like a reference -- Missing reference section? 'RFC2695' on line 423 looks like a reference -- Missing reference section? 'RFC2434' on line 415 looks like a reference -- Missing reference section? 'RFC1831bis' on line 439 looks like a reference -- Missing reference section? 'RFC1094' on line 427 looks like a reference -- Missing reference section? 'RFC1813' on line 431 looks like a reference -- Missing reference section? 'RFC3010' on line 435 looks like a reference -- Missing reference section? 'RFC1832' on line 403 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Thurlow 3 Internet Draft May 2004 4 Document: draft-ietf-nfsv4-rpc-iana-01.txt 6 RPC Numbering Authority Transfer to IANA 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Discussion and suggestions for improvement are requested. This 30 document will expire in October, 2003. Distribution of this draft is 31 unlimited. 33 Abstract 35 Network services based on RPC [RFC1831] use program numbers rather 36 than well known transport ports to permit clients to find them, and 37 use authentication flavor numbers to define the format of the 38 authentication data passed. The assignment of RPC program numbers 39 and authentication flavor numbers is still performed by Sun 40 Microsystems, Inc. This is inappropriate for an IETF standard 41 protocol, as such work is done well by the Internet Assigned Numbers 42 Authority (IANA). This document defines how IANA will maintain and 43 assign RPC program numbers and authentication flavor numbers. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Past Sun Assignment Practice . . . . . . . . . . . . . . . . 3 49 2.1. RPC Program Numbers . . . . . . . . . . . . . . . . . . . 3 50 2.1.1. RPC Program Number Assignments . . . . . . . . . . . . . 3 51 2.1.2. RPC Program Protocol Definitions . . . . . . . . . . . . 4 52 2.1.3. RPC Program Numbers Actually Assigned . . . . . . . . . 4 53 2.2. RPC Authentication Flavor Numbers . . . . . . . . . . . . 4 54 3. Proposed IANA Assignment Practice . . . . . . . . . . . . . 4 55 3.1. Protecting Past Assignments . . . . . . . . . . . . . . . 4 56 3.2. RPC Number Assignment . . . . . . . . . . . . . . . . . . 5 57 3.2.1. To be assigned by IANA . . . . . . . . . . . . . . . . . 5 58 3.2.2. Defined by local administrator . . . . . . . . . . . . . 5 59 3.2.3. Transient block . . . . . . . . . . . . . . . . . . . . 6 60 3.2.4. Reserved block . . . . . . . . . . . . . . . . . . . . . 6 61 3.2.5. RPC Number Sub-Blocks . . . . . . . . . . . . . . . . . 6 62 3.2.6. Information Necessary To Grant RPC Program Numbers . . . 8 63 3.3. RPC Authentication Flavor Number Assignment . . . . . . . 9 64 3.3.1. Information Necessary To Grant RPC Authentication Flavor 65 Numbers . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 10 67 5. Author's Address . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 This procedure will explain how RPC number assignments have been made 72 in the past and how they should be made in the future in order to 73 transfer the authority for assigning RPC program and authentication 74 flavor numbers from Sun Microsystems to IANA (the Internet Assigned 75 Number Authority). Users of RPC protocols will benefit by having an 76 independent body responsible for RPC number assignments. 78 2. Past Sun Assignment Practice 80 The administrator for these numbers was previously Sun Microsystems, 81 Inc. Requests for number assignments were sent to "rpc@sun.com" as 82 described in [RFC1831]. This section details the rules Sun used to 83 grant numbers. 85 2.1. RPC Program Numbers 87 Each application that uses RPC will typically require at least one 88 RPC program number. Because of this, there are hundreds of program 89 numbers assigned, some in delegated "blocks". 91 2.1.1. RPC Program Number Assignments 93 The program number is a 32-bit field partitioned into several blocks, 94 as defined by [RFC1831] paragraph 7.3. The table from the RFC is 95 shown in hexadecimal: 97 0 - 0x1fffffff defined by rpc@sun.com 98 0x20000000 - 0x3fffffff defined by user 99 0x40000000 - 0x5fffffff transient 100 0x60000000 - 0x7fffffff reserved 101 0x80000000 - 0x9fffffff reserved 102 0xa0000000 - 0xbfffffff reserved 103 0xc0000000 - 0xdfffffff reserved 104 0xe0000000 - 0xffffffff reserved 106 The "defined by user" block was not managed by Sun, but was intended 107 for controlled use by local administrative domains in a manner 108 similar to the "Defined by local administrator" block proposed in 109 Section 3.2.2. The "transient" block was intended to be used 110 dynamically by applications which prearranged a particular program 111 number and used it only while the application was in use. This is 112 similar to the "Transient" block proposed in Section 3.2.3. 114 2.1.2. RPC Program Protocol Definitions 116 Sun Microsystems, Inc.'s former policy was to ask for RPC protocol 117 definitions in XDR definition language [RFC1833]. This information 118 was not useful, and was in some cases proprietary. Sun will not 119 transfer such definitions to IANA; the choice to publish such 120 protocols is left to the owner of the protocol. 122 2.1.3. RPC Program Numbers Actually Assigned 124 Prior to the assumption of RPC program number assignment 125 responsibilities by IANA, Sun Microsystems, Inc. assigned individual 126 and small groups of RPC numbers only within the range of 100000 to 127 399999, decimal. A small number of large blocks was also granted. 128 In hexadecimal format, these assigned blocks are: 130 0x20010000 - 0x2001ffff 131 0x20020000 - 0x2002ffff 132 0x20020000 - 0x20020007 133 0x20030000 - 0x2003ffff 134 0x20040000 - 0x2004ffff 135 0x7f000000 - 0x7fffffff 137 2.2. RPC Authentication Flavor Numbers 139 In contrast to the case with RPC program numbers, RPC authentication 140 flavor numbers are assigned only when a new authentication method is 141 developed, which is rare. Standards which define or discuss 142 authentication flavors include [RFC1057], [RFC1831], [RFC2203], 143 [RFC2623] and [RFC2695]. Since less than 20 authentication flavor 144 numbers plus two number blocks have been granted, it has not been 145 necessary to formally subdivide the 32-bit range. Individual 146 assignments are within the decimal range 0-300002. One of the 147 granted blocks is held by a group within Sun Microsystems, Inc. to 148 allocate 'pseudo-flavors' for use with RPCSEC_GSS; this decimal range 149 390000-390255 will be relinquished to IANA for further assignments 150 for the same purpose. 152 3. Proposed IANA Assignment Practice 154 3.1. Protecting Past Assignments 156 Sun has made assignments in both number spaces since the original 157 deployment of RPC. The assignments made by Sun Microsystems are 158 still valid, and existing holders of number assignments from this 159 range do not need to reapply for numbers. The conventions and 160 procedures for future assignments must account for the protection of 161 these numbers. Sun will communicate all current assignments in both 162 number spaces to IANA before final handoff of number assignment is 163 done. 165 3.2. RPC Number Assignment 167 Future IANA practice should deal with the following partitioning of 168 the 32-bit number space: 170 0 Reserved 171 1 - 0x1fffffff To be assigned by IANA 172 0x20000000 - 0x3fffffff Defined by local administrator 173 (see note1) 174 0x40000000 - 0x5fffffff Transient 175 0x60000000 - 0x7effffff Reserved 176 0x7f000000 - 0x7fffffff Assignment outstanding 177 0x80000000 - 0xffffffff Reserved 179 Detailed information for the administration of these blocks is given 180 below. 182 3.2.1. To be assigned by IANA 184 The first block will be administered by IANA, with previous 185 assignments by Sun protected. Previous assignments were restricted 186 to the range decimal 100000-399999 (0x000186a0 to 0x00061a7f), 187 therefore IANA should begin assignments at decimal 400000. 188 Individual numbers should be grated on a first-come, first-served 189 basis, and blocks should be granted under rules related to the size 190 of the block. 192 3.2.2. Defined by local administrator 194 The "Defined by local administrator" block is available for any local 195 administrative domain to use, in a similar manner to IP address 196 ranges reserved for private use. The expected use would be through 197 the establishment of a local domain "authority" for assigning numbers 198 from this range. This authority would establish any policies or 199 procedures to be used within that local domain for use or assignment 200 of RPC numbers from the range. The local domain should be 201 sufficiently isolated that it would be unlikely that RPC applications 202 developed by other local domains could communicate with the domain. 203 This could result in RPC number contention, which would cause one of 204 the applications to fail. In the absence of a local administrator, 205 this block can be utilized in a "Private Use" manner per [RFC2434]. 207 Note1: Sun delegated a small number of large RPC blocks in this 208 range; see Section 2.1.3. 210 3.2.3. Transient block 212 The "Transient" block can be used by any RPC application on a "as 213 available" basis. This range is intended for services that can 214 communicate a dynamically selected RPC program number to clients of 215 the service. Any mechanism can be used to communicate the number. 216 Examples include shared memory when the client and server are located 217 on the same system, or a network message (either RPC or otherwise) 218 that disseminates the selected number. 220 The transient block is not administered. An RPC service uses this 221 range by selecting a number in the transient range and attempting to 222 register that number with the local system's RPC bindery (see the 223 RPCBPROC_SET or PMAPPROC_SET procedures in "Binding Protocols for ONC 224 RPC", [RFC1833]). If successful, no other RPC service was using that 225 number and the RPC Bindery has assigned that number to the requesting 226 RPC application. The registration is valid until the RPC Bindery 227 terminates, which normally would only happen if the system reboots 228 causing all applications, including the RPC service using the 229 transient number, to terminate. If the transient number registration 230 fails, another RPC application is using the number and the requestor 231 must select another number and try again. To avoid conflicts, the 232 recommended method is to select a number randomly from the transient 233 range. 235 3.2.4. Reserved block 237 The "Reserved" blocks are available for future use. RPC applications 238 must not use numbers in these ranges unless their use is allowed by 239 future action by the IESG. 241 3.2.5. RPC Number Sub-Blocks 243 RPC numbers are usually assigned for specific RPC services. Some 244 applications, however, require multiple RPC numbers for a service. 245 The most common example is an RPC service that needs to have multiple 246 instances of the service active simultaneously at a specific site. 247 RPC does not have an "instance identifier" in the protocol, so either 248 a mechanism must be implemented to multiplex RPC requests amongst 249 various instances of the service, or unique RPC numbers must be used 250 by each instance. 252 In these cases, the RPC protocol used with the various numbers may be 253 different or the same. The numbers may be assigned dynamically by 254 the application, or as part of a site-specific administrative 255 decision. If possible, RPC services that dynamically assign RPC 256 numbers should use the "Transient" RPC number block defined in 257 section 2. If not possible, RPC number sub-blocks may be requested. 259 Assignment of RPC Number Sub-Blocks is controlled by the size of the 260 sub-block being requested. "Specification Required" and "IESG 261 Approval" are used as defined by [RFC2434] Section 2. 263 Size of sub-block Assignment Method Authority 264 ----------------- ----------------- --------- 265 Up to 100 numbers First Come First Served IANA 266 Up to 1000 numbers Specification Required IANA 267 More than 1000 numbers IESG Approval required IESG 269 Note: sub-blocks can be any size. The limits given above are 270 maximums and smaller size sub-blocks are allowed. 272 Sub-blocks sized up to 100 numbers may be assigned by IANA on a First 273 Come First Served basis. The RPC Service Description included in the 274 range must include an indication of how the sub-block is managed. At 275 minimum, the statement should indicate whether the sub-block is used 276 with a single RPC protocol or multiple RPC protocols, and whether the 277 numbers are dynamically assigned or statically (through 278 administrative action) assigned. 280 Sub-blocks of up to 1000 numbers must be documented in detail. The 281 documentation must describe the RPC protocol or protocols that are to 282 be used in the range. It must also describe how the numbers within 283 the sub-block are to be assigned or used. 285 Sub-blocks sized over 1000 numbers must be documented as described 286 above, however an Internet Draft must be submitted as an 287 Informational or Standards Track RFC. If accepted as either, IANA 288 will assign the requested number sub-block. 290 In order to avoid multiple requests of large blocks of numbers the 291 following rule is proposed. 293 Requests up to and including 100 RPC numbers are handled via the 294 First Come First Served assignment method. This 100 number 295 threshhold applies to the total number of RPC numbers assigned to an 296 individual or entity. For example, if an individual or entity first 297 requests say 70 numbers, and then later requests 40 numbers, then the 298 request for the 40 numbers will be assigned via the Specification 299 Required method. As long as the total number of numbers assigned 300 does not exceed 1000, IANA is free to waive the Specification 301 Required assignment for incremental requests of less than 100 302 numbers. 304 If an individual or entity has under 1000 numbers and later requests 305 an additional set of numbers such that the individual or entity would 306 over 1000 numbers, then the individual or entity will have the 307 additional request submitted to the IESG. IESG is free to waive the 308 IESG Action Required assignment method for incremental requests of 309 less than 1000 numbers. 311 3.2.6. Information Necessary To Grant RPC Program Numbers 313 [RFC1831bis] describes how users request new RPC program numbers. If 314 changes are made to that procedure, IANA should continue to request 315 the following information: 317 o Name of person or company which will use the number 319 o An "identifier string" which associates the number with a 320 service 322 o Email address of the contact person for the RPC service which 323 will be using the number. 325 o A short description of the purpose of the RPC service 327 This information is needed to associate the RPC number with an RPC 328 service, and in turn to associate an RPC service with the company or 329 person who originated the RPC service. This information may be 330 necessary for network administrators to manage their networks or 331 firewalls. Network administrators who observe RPC transactions on 332 their network may need to contact the company or person who created 333 or deployed the service to understand the application's behavior. 334 This may happen if the service is thought to be operating improperly, 335 or if its operation is having an impact on the local network. 337 In most cases, interested parties only need to know the name of the 338 RPC service using the number. IANA will make this list available 339 through publication or other means to allow for lookup of RPC 340 services by RPC number. To be effective, this requires that the 341 "identifier string" be meaningful. The string should clearly 342 identify the RPC service or application with which the RPC number is 343 to be associated. Sites supporting RPC services typically publish a 344 mapping of RPC numbers to RPC identifiers. For example, UNIX systems 345 publish this mapping in the file "/etc/rpc". 347 3.3. RPC Authentication Flavor Number Assignment 349 The second number space is the authentication mechanism identifier, 350 or "flavor", number. This number is used to distinguish between 351 various authentication mechanisms which can be optionally used with 352 an RPC message. An authentication identifier is used in the "flavor" 353 field of the "opaque_auth" structure. 355 Recent progress in RPC security has focused on using the existing 356 RPCSEC_GSS flavor and inventing novel GSS-API mechanisms which can be 357 used with it. Even though RPCSEC_GSS is an assigned authentication 358 flavor, use of a new RPCSEC_GSS mechanism with NFS ([RFC1094] 359 [RFC1813] and [RFC3010]) will require the registration of 'pseudo- 360 flavors' which are used to negotiate security mechanisms in an 361 unambiguous way, as defined by [RFC2623]. Existing pseudo-flavors 362 have been granted in the decimal range 390000-390255 as described in 363 2.2. 365 For non-pseudo-flavor requests, IANA should begin granting RPC 366 authentication flavor numbers at 400000 to avoid conflicts with 367 currently granted numbers. 369 3.3.1. Information Necessary To Grant RPC Authentication Flavor Numbers 371 [RFC1831bis] describes how users request new RPC Authentication 372 Flavor numbers. If changes are made to that procedure, IANA should 373 continue to request the following information: 375 o Name of person or company which will use the number 377 o An "identifier string" which associates the number with a 378 service 380 o Email address of the contact person for the RPC service which 381 will be using the number. 383 o A description of the authentication flavor. 385 o If the authentication flavor is a 'pseudo-flavor' intended for 386 use with RPCSEC_GSS and NFS, mappings analogous to those in 387 Section 4.2 of [RFC2623] are required. 389 For authentication flavors to be used on the Internet, it is strongly 390 advised that an informational or standards-track RFC be published 391 describing the authentication mechanism behaviour and parameters. 393 4. Bibliography 395 [RFC1057] 396 Sun Microsystems Inc., "RPC: Remote Procedure Call Protocol 397 Specification Version 2", RFC 1057, August 1995. 399 [RFC1831] 400 R. Srinivasan, "RPC: Remote Procedure Call Protocol Specification 401 Version 2", RFC 1831, August 1995. 403 [RFC1832] 404 R. Srinivasan, "XDR: External Data Representation Standard", RFC 405 1832, August 1995. 407 [RFC1833] 408 R. Srinivasan, "Binding Protocols for ONC RPC Version 2", RFC 1833, 409 August 1995. 411 [RFC2203] 412 M. Eisler, A. Chiu, L. Ling, "RPCSEC_GSS Protocol Specification", RFC 413 2203, September 1997. 415 [RFC2434] 416 T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 417 Considerations Section in RFCs", RFC 2434, October 1998. 419 [RFC2623] 420 M. Eisler, "NFS Version 2 and Version 3 Security Issues and the NFS 421 Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999. 423 [RFC2695] 424 A. Chiu, "Authentication Mechanisms for ONC RPC", RFC 2695, September 425 1999. 427 [RFC1094] 428 Sun Microsystems, Inc., "NFS: Network File System Protocol 429 Specification", RFC 1094, March 1989. 431 [RFC1813] 432 B. Callaghan, B. Pawlowski. P. Staubach, "NFS Version 3 Protocol 433 Specification", RFC 1813, June 1995. 435 [RFC3010] 436 S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. 437 Eisler, D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000. 439 [RFC1831bis] 440 R. Thurlow, "RPC: Remote Procedure Call Protocol Specification 441 Version 2", draft-ietf-nfsv4-rfc1831bis-02.txt, May 2004. 443 5. Author's Address 445 Address comments related to this memorandum to: 447 nfsv4-wg@sunroof.eng.sun.com 449 Robert Thurlow 450 Sun Microsystems, Inc. 451 500 Eldorado Boulevard, UBRM05-171 452 Broomfield, CO 80021 454 Phone: 877-718-3419 455 E-mail: robert.thurlow@sun.com