NFSv4
Internet Engineering Task Force (IETF)                         M. Eisler
Internet-Draft
Request for Comments: 5665                                        NetApp
Updates: 1833 (if approved)                                               January 30, 2009
Intended status: 2010
Category: Standards Track
Expires: August 3, 2009
ISSN: 2070-1721

          IANA Considerations for RPC Net Remote Procedure Call (RPC)
           Network Identifiers and Universal Address Formats
                   draft-ietf-nfsv4-rpc-netid-06.txt

Abstract

   This document lists IANA Considerations for Remote Procedure Call
   (RPC) Network Identifiers (netids) and RPC Universal Network
   Addresses (uaddrs).  This document updates, but does not replace, RFC
   1833.

Status of this This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product 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
   (IETF).  It represents the consensus of six months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other documents at any
   time.  It the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work available in progress."

   The list Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 3, 2009. http://www.rfc-
   editor.org/info/rfc5665.

Copyright Notice

   Copyright (c) 2009 2010 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  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are to be interpreted provided without warranty as
   described in RFC 2119 [1]. the BSD License.

Table of Contents

   1. Introduction and Motivation  . . . . . . . . . . . . . . . . .  3 .....................................3
   2. Requirements Language ...........................................3
   3. Considerations for the Netid of the SCTP Stream Control
      Transmission Protocol  . . . . . .  3
   3. ...........................................3
   4. Security Considerations  . . . . . . . . . . . . . . . . . . .  3
   4. .........................................3
   5. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  3
     4.1. .............................................3
      5.1. IANA Considerations for Netids . . . . . . . . . . . . . .  3
       4.1.1. .............................4
           5.1.1. Initial Registry . . . . . . . . . . . . . . . . . . .  6
       4.1.2. ....................................6
           5.1.2. Updating Registrations . . . . . . . . . . . . . . . .  8
     4.2. ..............................8
      5.2. IANA Considerations for Uaddr Formats  . . . . . . . . . .  8
       4.2.1. ......................8
           5.2.1. Initial Registry . . . . . . . . . . . . . . . . . . .  9
       4.2.2. ....................................9
           5.2.2. Updating Registrations . . . . . . . . . . . . . . . .  9
       4.2.3. .............................10
           5.2.3. Uaddr Formats  . . . . . . . . . . . . . . . . . . . . 10
     4.3. ......................................10
                  5.2.3.1. Uaddr Format for System V Release
                           4 Loopback Transports .....................10
                  5.2.3.2. Uaddr Format for Netid "-" ................10
                  5.2.3.3. Uaddr Format for Most IPv4 Transports .....11
                  5.2.3.4. Uaddr Format for Most IPv6 Transports .....11
                  5.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6 ..11
      5.3. Cross Referencing Between between the Netid and Format Registry  . 11
     4.4. ...12
      5.4. Port Assignment for NFS over SCTP  . . . . . . . . . . . . 11
   5. .........................12
   6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1. .....................................................12
      6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     5.2. ......................................12
      6.2. Informative References . . . . . . . . . . . . . . . . . . 11 ....................................12
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 12
   Appendix B.  RFC Editor Notes  . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13  Acknowledgments ......................................14

1.  Introduction and Motivation

   The concepts of an RPC (defined in RFC1831 RFC 5531 [4]) Network Identifier
   (netid) and an RPC Universal Address (uaddr) were introduced in
   RFC1833 [2] RFC
   1833 [1] for distinguishing network addresses of multiple protocols
   and representing those addresses in a canonical form.
   RFC1833  RFC 1833
   states that a netid ``is "is defined by a system administrator based on
   local conventions, and cannot be depended on to have the same value
   on every system.'' 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.) RFC
   1833.)  Since the publication of RFC1833, RFC 1833, it has been found that
   protocols like NFSv4.0 Network File System version 4 (NFSv4.0) [5] and RPC/RDMA RPC/
   RDMA (Remote Direct Memory Access) [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.  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 [2].

3.  Considerations for the Netid of the SCTP Stream Control Transmission
    Protocol

   The SCTP protocol Stream Control Transmission Protocol (SCTP) (described in RFC4960 RFC
   4960 [7]) is a connection-oriented protocol that supports both byte-streamed byte-
   streamed and record-oriented data transfer.  When the "sctp" and
   "sctp6" netids are used, the ONC Open Network Computing (ONC) RPC Record
   Marking standard (see Section 10 11 of RFC1831 RFC 5531 [4]) are is not used;
   instead, SCTP's native record-oriented data transfer is used.

3.

4.  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.

5.  IANA Considerations

   This section uses terms that are defined in RFC5226 RFC 5226 [8].

4.1.

5.1.  IANA Considerations for Netids

   IANA will create has created 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 Section 4.1 of
      RFC5226. RFC
      5226.

   o  A Standards Action basis subregistry per section Section 4.1 of RFC5226. RFC 5226.

   The XDR eXternal Data Representation (XDR) encoding allows netids to be
   up to 2^32 - 1 octets in length, but the registry will only allow a
   much shorter length.  Assignments made on a Standards Action basis
   should be assigned netids one 1 to
   eight 8 octets long.  Assignments made on a
   First Come First Served basis should be assigned netids nine 9 to 128
   octets long.  Some exceptions are listed in Table 2.

   Some portion of the netid name space is Reserved:

   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 the 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
      [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
   the netid's name.

   There are two subregistries of netids, netids: one for Standards Action
   assignments,
   assignments and one for First Come First Serve Served assignments.  Each
   registry of netids is a list of assignments, each containing five
   fields for each assignment.

   1.  A US-ASCII string name that is the actual netid.  The netid
       should be one 1 to eight 8 octets long for the Standards Action
       subregistry, and should be nine 9 to 128 octets long for the First Come First
       Served subregistry.  The netid MUST NOT conflict with any other
       registered netid.  Despite the fact that netids are case
       sensitive, the netid, when mapped to all upper case case, MUST NOT
       conflict with the value of any other registered netid after the
       registered netid is mapped to upper case.  In addition, when
       mapped to upper case, the prefix of the netid MUST NOT be equal
       to a Reserved prefix.

   2.  A constant name that can be used for software programs that wish
       to use the transport protocol associated with protocol. the netid.  The
       name of the constant typically has the prefix: prefix "NC_", and a suffix
       equal to the upper case 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 1 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 that 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 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 including, if applicable, RFC numbers
       of the transport and network protocols.

   4.  A point of contact of the registrant.  For assignments made on a
       First Come First Served basis, basis:

       *  the point of contact should include an email address.

       *  subject to authorization by a Designated Expert, the point of
          contact may be omitted for extraordinary situations, such as
          the registration of a commonly used netid where the owner is
          unknown.

       For assignments made on a Standards Action basis basis, the point of
       contact is always determined by IESG.

   5.  A numerical value, used to cross reference the netid assignment
       with an assignment in the uaddr format registry (see
       Section 4.2). 5.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 the cross reference number IANA
       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.

5.1.1.  Initial Registry

   The initial list of netids is broken into two subregistries: those
   assigned on a First Come First Serve Served basis in Table 1 and those
   assigned on a Standards Action basis in Table 2.  These lists will
   change when as IANA registers additional netids as needed, and the
   authoritative list of registered netids will always live with IANA.

   +-------------+--------------+---------------------------+-----+----+
   | Netid       | Constant     | Description and/or        | PoC | CR |
   |             | Name         | Reference                 |     |    |
   +-------------+--------------+---------------------------+-----+----+
   | "-"         | NC_NOPROTO   | RFC1833 [2], [1],              |     | 1  |
   |             |              | Section 4.2.3.2 5.2.3.2 of RFC    |     |    |
   |             |              | RFCTBD2 5665                      |     |    |
   | "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 [10].                 |     |    |
   | "ticots"    | NC_TICOTS    | The loop back             |     | 0  |
   |             |              | connection-oriented       |     |    |
   |             |              | transport used in System  |     |    |
   |             |              | V Release 4 and other     |     |    |
   |             |              | operating systems.  See   |     |    |
   |             |              | [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 [10].       |     |    |
   +-------------+--------------+---------------------------+-----+----+

        Table 1: Initial First Come First Serve Served 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)                          |      |    |
   +---------+-----------+---------------------------------+------+----+
   +---------+----------+----------------------------------+------+----+
   | "rdma"  | NC_RDMA  | RFCTBD1 [6] RFC0791 RFC 5666 [6], RFC 791 [11]       | IESG | 2  |
   | "rdma6" | NC_RDMA6 | RFCTBD1 [6] RFC2460 RFC 5666 [6], RFC 2460 [12]      | IESG | 3  |
   | "sctp"  | NC_SCTP  | RFC4960 [7] RFC0791 [11] RFC 4960 [7], RFC 791 [11],      | IESG | 2  |
   |         |          | Section 2 3 of RFCTBD2 RFC 5665            |      |    |
   | "sctp6" | NC_SCTP6 | RFC4960 [7] RFC2460 [12] RFC 4960 [7], RFC 2460 [12],     | IESG | 3  |
   |         |          | Section 2 3 of RFCTBD2 RFC 5665            |      |    |
   | "tcp"   | NC_TCP   | RFC0793 [13] RFC0791 [11] RFC 793 [13], RFC 791 [11],      | IESG | 2  |
   |         |          | Section 10 11 of RFC1831 RFC 5531 [4]       |      |    |
   | "tcp6"  | NC_TCP6  | RFC0793 [13] RFC2460 [12] RFC 793 [13], RFC 2460 [12],     | IESG | 3  |
   |         |          | Section 10 11 of RFC1831 RFC 5531 [4]       |      |    |
   | "udp"   | NC_UDP   | RFC0768 [14] RFC0791 RFC 768 [14], RFC 791 [11]       | IESG | 2  |
   | "udp6"  | NC_UDP6  | RFC0768 [14] RFC2460 RFC 768 [14], RFC 2460 [12]      | IESG | 3  |
   +---------+-----------+---------------------------------+------+----+
   +---------+----------+----------------------------------+------+----+

            Table 2: Initial Standards Action Netid Assignments

4.1.2.

5.1.2.  Updating Registrations

   Per section Section 5.2 of RFC5226 RFC 5226, 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."
   registrations".  The IESG or a Designated Expert is permitted to
   update any registration made on a First Come First Served basis,
   which normally is done when the PoC cannot be reached in order to
   make necessary updates.  Examples where an update would be needed
   include, but are not limited to: the email address or other contact
   information becomes invalid; the reference to the corresponding
   protocol becomes obsolete or unavailable; and RFC1833 RFC 1833 is updated or
   replaced in such a way that the scope of netids changes, requiring
   additional fields in the assignment.

   Only the IESG, on the advice of a Designated Expert, can update a
   registration made on a Standards Action basis.

4.2.

5.2.  IANA Considerations for Uaddr Formats

   IANA will create has created a registry called "ONC RPC Uaddr Format Registry"
   (called the "format registry" for the remainder of this document).
   The remainder of this section describes the registry.

   All assignments to the format registry are made on one of two bases:

   o  First Come First Served basis per section Section 4.1 of RFC5226. RFC 5226.

   o  Standards Action per section Section 4.1 of RFC5226. RFC 5226.

   The registry of formats is a list of assignments, each containing
   four fields for each assignment.

   1.  The basis for the assignment, which can be either FCFS for First
       Come First Served assignments, assignments or STDS for Standards Action
       assignments.

   2.  A description and/or reference to a description of the actual
       uaddr format.  Assignments made on a Standards Action basis
       always have a reference to an RFC.

   3.  For assignments made on a First Come First Served basis, a point
       of contact, including an email address.  Subject to authorization
       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 the 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 are only for Standards Track RFCs approved by the IESG.

4.2.1.

5.2.1.  Initial Registry

   The initial list of formats is in Table 3.  This lists list will change
   when as
   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 |
   +-------+-----------------------------------------------+------+----+
   | FCFS  | System V Release 4 loopback transport uaddr   |      | 0  |
   |       | format.  Section 4.2.3.1 5.2.3.1 of RFCTBD2 RFC 5665          |      |    |
   | FCFS  | Uaddr format for NC_NOPROTO.  Section 4.2.3.2 5.2.3.2 |      | 1  |
   |       | of RFCTBD2 RFC 5665                                   |      |    |
   | STDS  | Uaddr format for IPv4 transports.             | IESG | 2  |
   |       | Section 4.2.3.3 5.2.3.3 of RFCTBD2 RFC 5665                   |      |    |
   | STDS  | Uaddr format for IPv6 transports.             | IESG | 3  |
   |       | Section 4.2.3.4 5.2.3.4 of RFCTBD2 RFC 5665                   |      |    |
   +-------+-----------------------------------------------+------+----+

                    Table 3: Initial Format Assignments

4.2.2.

5.2.2.  Updating Registrations

   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."  The IESG is permitted to update
   any registration made on a First Come First Served basis, which
   normally is done when the PoC cannot be reached in order to make
   necessary updates.  Examples where an update would be needed include,
   but are not limited to: the email address or other contact
   information becomes invalid; the reference to the format description
   becomes obsolete or unavailable; and RFC1833 RFC 1833 is updated or replaced in
   such a way that the scope of uaddr formats changes, requiring
   additional fields in the assignment.

   Only the IESG, on the advice of a Designated Expert, can update a
   registration made on a Standards Action basis.

4.2.3.

5.2.3.  Uaddr Formats

4.2.3.1.

5.2.3.1.  Uaddr Format for System V Release 4 Loopback Transports

   Although RFC1833 RFC 1833 specifies the uaddr as the XDR data type string
   (hence, limited to US-ASCII), implementations of the System V Release
   4 loopback transports will use an opaque string of octets.  Thus  Thus, the
   format of a loopback transport address is any non-zero length array
   of octets.

4.2.3.2.

5.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. RFC 1833.

5.2.3.3.  Uaddr Format for Most IPv4 Transports

   Most transport protocols that operate over IPv4 use 16 bit 16-bit port
   numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14].  The
   format of the uaddr for the above 16 bit 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", 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 h4 are, respectively,
   the first through fourth octets each converted to ASCII-decimal.  The
   suffix, "p1.p2",
   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 big-endian order,
   port 0xCB51 (decimal 52049) 52049), then the complete uaddr is
   "192.0.2.7.203.81".

4.2.3.4.

5.2.3.4.  Uaddr Format for Most IPv6 Transports

   Most transport protocols that operate over IPv6 use 16 bit 16-bit port
   numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14].  The
   format of the uaddr for the above 16 bit 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). 5.2.3.3).  The
   prefix, "x1:x2:x3:x4:x5:x6:x7:x8",
   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 RFC 4291
   [3].  Additionally, the two alternative forms specified in Section
   2.2 of RFC4291 RFC 4291 are also acceptable.

4.2.3.5.

5.2.3.5.  Uaddr Format for ICMP over IPv4 and IPv6

   As ICMP is not a true transport, there is no uaddr format for ICMP.
   The netid assignments "icmp" and "icmp6" and their shared uaddr
   "format" are listed to prevent any registrant from allocating the
   netids "icmp" and "icmp6" for a purpose that would likely cause
   confusion.

4.3.

5.3.  Cross Referencing Between 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 the same numeric value values in cross references when updating
   each registry; i.e. 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.

5.4.  Port Assignment for NFS over SCTP

   Port TBD100 2049 is assigned to NFS over SCTP for the sctp and sctp6 netids.

5.

6.  References

5.1.

6.1.  Normative References

   [1]   Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
         RFC 1833, August 1995.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
         RFC 1833, August 1995.

   [3]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 4291, February 2006.

5.2.

6.2.  Informative References

   [4]   Srinivasan,   Thurlow, R., "RPC: Remote Procedure Call Protocol Specification
         Version 2", RFC 1831, August 1995. 5531, May 2009.

   [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. RFC 5666, October 2009.

   [7]   Stewart, R., Ed., "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.

   [9]   Postel, J., "Internet Control Message Protocol", STD 5,
         RFC 792, September 1981.

   [10]  American Telephone and Telegraph Company, "UNIX System V,
         Release 4 Programmer's Guide: Networking Interfaces, ISBN
         0139470786", 1990.

   [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]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
         September 1981.

   [14]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
         August 1980.

Appendix A.  Acknowledgements  Acknowledgments

   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.] feedback.

Author's Address

   Mike Eisler
   NetApp
   5765 Chase Point Circle
   Colorado Springs, CO  80919
   US

   Phone: +1-719-599-9026
   Email:
   EMail: mike@eisler.com