--- 1/draft-ietf-nfsv4-rpc-netid-05.txt 2009-01-30 12:12:02.000000000 +0100 +++ 2/draft-ietf-nfsv4-rpc-netid-06.txt 2009-01-30 12:12:02.000000000 +0100 @@ -1,112 +1,126 @@ NFSv4 M. Eisler Internet-Draft NetApp -Updates: 1833 (if approved) December 10, 2008 +Updates: 1833 (if approved) January 30, 2009 Intended status: Standards Track -Expires: June 13, 2009 +Expires: August 3, 2009 IANA Considerations for RPC Net Identifiers and Universal Address Formats - draft-ietf-nfsv4-rpc-netid-05.txt + draft-ietf-nfsv4-rpc-netid-06.txt Status of this Memo - By submitting this Internet-Draft, each author represents that any - 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 - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 13, 2009. + This Internet-Draft will expire on August 3, 2009. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Abstract 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 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 - 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Considerations for the Netid of the SCTP Protocol . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4.1. IANA Considerations for Netids . . . . . . . . . . . . . . 3 4.1.1. Initial Registry . . . . . . . . . . . . . . . . . . . 6 - 4.1.2. Updating Registrations . . . . . . . . . . . . . . . . 7 - 4.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 7 - 4.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 8 + 4.1.2. Updating Registrations . . . . . . . . . . . . . . . . 8 + 4.2. IANA Considerations for Uaddr Formats . . . . . . . . . . 8 + 4.2.1. Initial Registry . . . . . . . . . . . . . . . . . . . 9 4.2.2. Updating Registrations . . . . . . . . . . . . . . . . 9 - 4.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 9 - 4.3. Cross Referencing Between the Netid and Format Registry . 10 - 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 4.2.3. Uaddr Formats . . . . . . . . . . . . . . . . . . . . 10 + 4.3. Cross Referencing Between the Netid and Format Registry . 11 + 4.4. Port Assignment for NFS over SCTP . . . . . . . . . . . . 11 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 5.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Appendix A. RFC Editor Notes . . . . . . . . . . . . . . . . . . 12 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . . . 13 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 + Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 12 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction and Motivation The concepts of an RPC (defined in RFC1831 [4]) Network Identifier (netid) and an RPC Universal Address (uaddr) were introduced in RFC1833 [2] for distinguishing network addresses of multiple protocols and representing those addresses in a canonical form. RFC1833 states that a netid ``is defined by a system administrator based on local conventions, and cannot be depended on to have the same value on every system.'' (The netid is contained in the field r_netid of the data type rpcb_entry, and the uaddr is contained in the field r_addr of the same data type, where rpcb_entry is defined in RFC1833.) Since the publication of RFC1833, it has been found that protocols like NFSv4.0 [5] and RPC/RDMA [6] depend on consistent values of 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 formats for RPC and specifies the initial content of the two registries. -2. Acknowledgements +2. Considerations for the Netid of the SCTP Protocol - Lars Eggert, Juergen Schoenwaelder, and Robert Sparks reviewed the - document and gave valuable feed back. + The SCTP protocol (described in RFC4960 [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 ONC RPC + Record Marking standard (see Section 10 of RFC1831 [4]) are not used; + instead, SCTP's native record-oriented data transfer is used. 3. Security Considerations 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. 4. IANA Considerations - This section uses terms that are defined in RFC5226 [7]. + This section uses terms that are defined in RFC5226 [8]. 4.1. IANA Considerations for Netids IANA will create a registry called "ONC RPC Netids". The remainder of this section describes the registry. All assignments to the ONC RPC Netids registry are made on one of two bases: o A First Come First Served basis subregistry per section 4.1 of @@ -125,21 +139,21 @@ o All netids, regardless of length, that start with the prefixes "STDS" or "FCFS" are Reserved, in order to extend the name space of either Standards Action or First Come First Served bases. o To give IESG the flexibility in the future to permit Private and Experimental Uses, all netids with the prefixes "PRIV" or "EXPE" are Reserved. o To prevent confusion with the control protocol by the same name - [8], 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 manner, this document does not provide for Hierarchical Allocation of netids. Nonetheless, all netids containing the octet "." are Reserved for future possible provision of Hierarchical Allocation. o The zero length netid is Reserved. A recommended convention for netids corresponding to transports that work over the IPv6 protocol is to have "6" as the last character in @@ -167,20 +181,26 @@ equal to the upper case version of the netid. This constant name should be a constant that is valid in the 'C' programming language. This constant name MUST NOT conflict with any other netid constant name. Constant names with the prefix "NC_STDS", "NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved. Constant names with a prefix of "NC_" and a total length of 11 characters or less should be for assignments made on the Standards Action basis. The constant "NC_" is Reserved. The constant name can be one to 131 octets long. + Given the typical derivation of the constant name from the netid, + the registration of the constant might be considered redundant. + This is not always true. For example, a netid might use a + character than is not valid in the programming language. The + first entry of Table 1 provides such an example. + 3. A description and/or a reference to a description of the how the netid will be used. For assignments made on a First Come First Served basis the description should include, if applicable, a reference to the transport and network protocols corresponding to the netid. For assignments made on a Standards Action basis, the description field must include the RFC numbers of the protocol associated with the netid, including if applicable, RFC numbers of the transport and network protocols. 4. A point of contact of the registrant. For assignments made on a @@ -200,21 +220,23 @@ with an assignment in the uaddr format registry (see Section 4.2). If the registrant is registering a netid that cross references an existing assignment in the uaddr format registry, then the registrant provides the actual value of the cross reference along with the date the registrant retrieved the cross reference value from the uaddr format registry. If the registrant is registering both a new netid and new uaddr format, then the registrant provides a value of TBD1 in the netid request, and uses TBD1 in the the uaddr format request. IANA will then substitute TBD1 for cross reference number IANA - allocates. + allocates. Note that if a document requests multiple netid and + uaddr assignments, each additional uaddr format cross reference + will be identified as TBD2, TBD3, ..., etc. 4.1.1. Initial Registry 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 Standards Action basis in Table 2. These lists will change when IANA registers additional netids as needed, and the authoritative list of registered netids will always live with IANA. +-------------+--------------+---------------------------+-----+----+ @@ -227,60 +249,62 @@ | "ticlts" | NC_TICLTS | The loop back | | 0 | | | | connectionless transport | | | | | | used in System V Release | | | | | | 4 and other operating | | | | | | systems. Although this | | | | | | assignment is made on a | | | | | | First Come First Served | | | | | | basis and is fewer than | | | | | | nine characters long, the | | | | | | exception is authorized. | | | - | | | See [9]. | | | + | | | See [10]. | | | | "ticots" | NC_TICOTS | The loop back | | 0 | | | | connection-oriented | | | | | | transport used in System | | | | | | V Release 4 and other | | | | | | operating systems. See | | | - | | | [9]. Although this | | | + | | | [10]. Although this | | | | | | assignment is made on a | | | | | | First Come First Served | | | | | | basis and is fewer than | | | | | | nine characters long, the | | | | | | exception is authorized. | | | | "ticotsord" | NC_TICOTSORD | The loop back | | 0 | | | | connection-oriented with | | | | | | orderly-release transport | | | | | | used in System V Release | | | | | | 4 and other operating | | | - | | | systems. See [9]. | | | + | | | systems. See [10]. | | | +-------------+--------------+---------------------------+-----+----+ Table 1: Initial First Come First Serve Netid Assignments PoC: Point of Contact. CR: Cross Reference to the Uaddr Format Registry. - +---------+--------------+------------------------------+------+----+ + +---------+-----------+---------------------------------+------+----+ | Netid | Constant | RFC(s) and Description (if | PoC | CR | | | Name | needed) | | | - +---------+--------------+------------------------------+------+----+ - | "dccp" | NC_DCCP | RFC4340 [10] RFC0791 [11] | IESG | 2 | - | "dccp6" | NC_DCCP6 | RFC4340 [10] RFC2460 [12] | IESG | 3 | + +---------+-----------+---------------------------------+------+----+ | "rdma" | NC_RDMA | RFCTBD1 [6] RFC0791 [11] | IESG | 2 | | "rdma6" | NC_RDMA6 | RFCTBD1 [6] RFC2460 [12] | IESG | 3 | - | "sctp" | NC_SCTP | RFC2960 [13] RFC0791 [11] | IESG | 2 | - | "sctp6" | NC_SCTP6 | RFC2960 [13] RFC2460 [12] | IESG | 3 | - | "tcp" | NC_TCP | RFC0793 [14] RFC0791 [11] | IESG | 2 | - | "tcp6" | NC_TCP6 | RFC0793 [14] RFC2460 [12] | IESG | 3 | - | "udp" | NC_UDP | RFC0768 [15] RFC0791 [11] | IESG | 2 | - | "udp6" | NC_UDP6 | RFC0768 [15] RFC2460 [12] | IESG | 3 | - +---------+--------------+------------------------------+------+----+ + | "sctp" | NC_SCTP | RFC4960 [7] RFC0791 [11] | IESG | 2 | + | | | Section 2 of RFCTBD2 | | | + | "sctp6" | NC_SCTP6 | RFC4960 [7] RFC2460 [12] | IESG | 3 | + | | | Section 2 of RFCTBD2 | | | + | "tcp" | NC_TCP | RFC0793 [13] RFC0791 [11] | IESG | 2 | + | | | Section 10 of RFC1831 [4] | | | + | "tcp6" | NC_TCP6 | RFC0793 [13] RFC2460 [12] | IESG | 3 | + | | | Section 10 of RFC1831 [4] | | | + | "udp" | NC_UDP | RFC0768 [14] RFC0791 [11] | IESG | 2 | + | "udp6" | NC_UDP6 | RFC0768 [14] RFC2460 [12] | IESG | 3 | + +---------+-----------+---------------------------------+------+----+ Table 2: Initial Standards Action Netid Assignments 4.1.2. Updating Registrations Per section 5.2 of RFC5226 the registrant is always permitted to update a registration made on a First Come First Served basis "subject to the same constraints and review as with new registrations." IESG or a Designated Expert is permitted to update any registration made on a First Come First Served basis, which @@ -323,23 +347,26 @@ by a Designated Expert, the point of contact may be omitted for extraordinary situations, such as the registration of a commonly used format where the owner is unknown. For assignments made on a Standards Action basis, the point of contact is always determined by IESG. 4. A numerical value, used to cross reference the format assignment with an assignment in the netid registry. The registrant provides a value of TBD1 for the cross reference field when requesting an assignment. IANA will assign TBD1 to a real value. + Note that if a document requests multiple uaddr assignments, each + additional uaddr format cross reference will be identified as + TBD2, TBD3, ..., etc. All requests for assignments to the format registry on a Standards - Action basis must undergo Expert Review and must be approved by IESG. + Action basis are only for Standards Track RFCs approved by the IESG. 4.2.1. Initial Registry The initial list of formats is in Table 3. This lists will change when IANA registers additional formats as needed, and the authoritative list of registered formats will always live with IANA. +-------+-----------------------------------------------+------+----+ | Basis | Description and/or Reference | PoC | CR | +-------+-----------------------------------------------+------+----+ @@ -382,32 +410,31 @@ of octets. 4.2.3.2. Uaddr Format for Netid "-" There is no address format for netid "-". This netid is apparently for internal use for supporting some implementations of RFC1833. 4.2.3.3. Uaddr Format for Most IPv4 Transports Most transport protocols that operate over IPv4 use 16 bit port - numbers, including DCCP [10], RDMA [6], SCTP [13], TCP [14], and UDP - [15]. The format of the uaddr for the above 16 bit port transports - (when used over IPv4) is the US-ASCII string: + 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 + over IPv4) is the US-ASCII string: h1.h2.h3.h4.p1.p2 The prefix, "h1.h2.h3.h4", is the standard textual form for representing an IPv4 address, which is always four octets long. Assuming big-endian ordering, h1, h2, h3, and h4, are respectively, the first through fourth octets each converted to ASCII-decimal. The suffix, "p1.p2", is a textual form for representing a service port. - Assuming big-endian ordering, p1 and p2 are, respectively, the first and second octets each converted to ASCII-decimal. For example, if a host, in big-endian order, has an address in hexadecimal of 0xC0000207 and there is a service listening on, in big endian order, port 0xCB51 (decimal 52049) then the complete uaddr is "192.0.2.7.203.81". 4.2.3.4. Uaddr Format for Most IPv6 Transports Most transport protocols that operate over IPv6 use 16 bit port @@ -404,23 +431,23 @@ Assuming big-endian ordering, p1 and p2 are, respectively, the first and second octets each converted to ASCII-decimal. For example, if a host, in big-endian order, has an address in hexadecimal of 0xC0000207 and there is a service listening on, in big endian order, port 0xCB51 (decimal 52049) then the complete uaddr is "192.0.2.7.203.81". 4.2.3.4. Uaddr Format for Most IPv6 Transports Most transport protocols that operate over IPv6 use 16 bit port - numbers, including DCCP [10], RDMA [6], SCTP [13], TCP [14], and UDP - [15]. The format of the uaddr for the above 16 bit port transports - (when used over IPv6) is the US-ASCII string: + 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 + over IPv6) is the US-ASCII string: x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 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 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 [3]. Additionally, the two alternative forms specified in Section 2.2 of RFC4291 are also acceptable. @@ -434,20 +461,25 @@ 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 format registry. IANA is under no obligation to maintain same numeric value in cross references when updating each registry; i.e. IANA is free to "re-number" these corresponding fields. However, if IANA does so, both the netid and format registries must be updated atomically. +4.4. Port Assignment for NFS over SCTP + + Port TBD100 is assigned to NFS over SCTP for the sctp and sctp6 + netids. + 5. References 5.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995. @@ -460,101 +492,67 @@ Specification Version 2", RFC 1831, August 1995. [5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003. [6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access Transport for Remote Procedure Call", draft-ietf-nfsv4-rpcrdma-09 (work in progress), December 2008. - [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + [7] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, + September 2007. + + [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. - [8] Postel, J., "Internet Control Message Protocol", STD 5, + [9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. - [9] 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 0139470786", 1990. - [10] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion - Control Protocol (DCCP)", RFC 4340, March 2006. - [11] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. - [13] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, - H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. - Paxson, "Stream Control Transmission Protocol", RFC 2960, - October 2000. - - [14] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, + [13] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. - [15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. -Appendix A. RFC Editor Notes +Appendix A. Acknowledgements + + Lisa Dusseault, Lars Eggert, Pasi Eronen, Tim Polk, Juergen + Schoenwaelder, and Robert Sparks reviewed the document and gave + valuable feed back. + +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 Mike Eisler NetApp 5765 Chase Point Circle Colorado Springs, CO 80919 US Phone: +1-719-599-9026 Email: mike@eisler.com - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - 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, THE IETF TRUST 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. - -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.