One document matched: draft-ietf-nfsv4-rpc-netid-05.txt
Differences from draft-ietf-nfsv4-rpc-netid-04.txt
NFSv4 M. Eisler
Internet-Draft NetApp
Updates: 1833 (if approved) December 10, 2008
Intended status: Standards Track
Expires: June 13, 2009
IANA Considerations for RPC Net Identifiers and Universal Address
Formats
draft-ietf-nfsv4-rpc-netid-05.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.
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.
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].
Eisler Expires June 13, 2009 [Page 1]
Internet-Draft RPC Netids December 2008
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 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.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
5.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. RFC Editor Notes . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Eisler Expires June 13, 2009 [Page 2]
Internet-Draft RPC Netids December 2008
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
Lars Eggert, Juergen Schoenwaelder, and Robert Sparks reviewed the
document and gave valuable feed back.
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].
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
RFC5226.
Eisler Expires June 13, 2009 [Page 3]
Internet-Draft RPC Netids December 2008
o A Standards Action basis subregistry per section 4.1 of RFC5226.
The 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 to
eight octets long. Assignments made on a First Come First Served
basis should be assigned netids nine 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 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.
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, one for Standards Action
assignments, and one for First Come First Serve 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 to eight octets long for the Standards Action
subregistry, and should be nine 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 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.
Eisler Expires June 13, 2009 [Page 4]
Internet-Draft RPC Netids December 2008
2. A constant name that can be used for software programs that wish
to use the transport protocol associated with protocol. The name
of the constant typically has the prefix: "NC_", and a suffix
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.
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
First Come First Served 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 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). 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.
Eisler Expires June 13, 2009 [Page 5]
Internet-Draft RPC Netids December 2008
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.
+-------------+--------------+---------------------------+-----+----+
| Netid | Constant | Description and/or | PoC | CR |
| | Name | Reference | | |
+-------------+--------------+---------------------------+-----+----+
| "-" | NC_NOPROTO | RFC1833 [2], | | 1 |
| | | Section 4.2.3.2 of | | |
| | | RFCTBD2 | | |
| "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]. | | |
| "ticots" | NC_TICOTS | The loop back | | 0 |
| | | connection-oriented | | |
| | | transport used in System | | |
| | | V Release 4 and other | | |
| | | operating systems. See | | |
| | | [9]. 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]. | | |
+-------------+--------------+---------------------------+-----+----+
Table 1: Initial First Come First Serve Netid Assignments
PoC: Point of Contact. CR: Cross Reference to the Uaddr Format
Eisler Expires June 13, 2009 [Page 6]
Internet-Draft RPC Netids December 2008
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 |
+---------+--------------+------------------------------+------+----+
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
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 is updated or
replaced in such a way that the scope of netids changes, requiring
additional fields in the assignment.
Only IESG, on the advice of a Designated Expert, can update a
registration made on a Standards Action basis.
4.2. IANA Considerations for Uaddr Formats
IANA will create 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 4.1 of RFC5226.
Eisler Expires June 13, 2009 [Page 7]
Internet-Draft RPC Netids December 2008
o Standards Action per section 4.1 of RFC5226.
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, 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 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.
All requests for assignments to the format registry on a Standards
Action basis must undergo Expert Review and must be approved by 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 |
+-------+-----------------------------------------------+------+----+
| FCFS | System V Release 4 loopback transport uaddr | | 0 |
| | format. Section 4.2.3.1 of RFCTBD2 | | |
| FCFS | Uaddr format for NC_NOPROTO. Section 4.2.3.2 | | 1 |
| | of RFCTBD2 | | |
| STDS | Uaddr format for IPv4 transports. | IESG | 2 |
| | Section 4.2.3.3 of RFCTBD2 | | |
| STDS | Uaddr format for IPv6 transports. | IESG | 3 |
| | Section 4.2.3.4 of RFCTBD2 | | |
+-------+-----------------------------------------------+------+----+
Eisler Expires June 13, 2009 [Page 8]
Internet-Draft RPC Netids December 2008
Table 3: Initial Format Assignments
4.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." 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 is updated or replaced in such a
way that the scope of uaddr formats changes, requiring additional
fields in the assignment.
Only IESG, on the advice of a Designated Expert, can update a
registration made on a Standards Action basis.
4.2.3. Uaddr Formats
4.2.3.1. Uaddr Format for System V Release 4 Loopback Transports
Although RFC1833 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 the
format of a loopback transport address is any non-zero length array
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:
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.
Eisler Expires June 13, 2009 [Page 9]
Internet-Draft RPC Netids December 2008
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:
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.
4.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6
As ICMP is not a true transport, there is no uaddr format for ICMP.
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. 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.
5. References
5.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
Eisler Expires June 13, 2009 [Page 10]
Internet-Draft RPC Netids December 2008
[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. Informative References
[4] Srinivasan, R., "RPC: Remote Procedure Call Protocol
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
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[8] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[9] 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,
September 1981.
[15] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
Eisler Expires June 13, 2009 [Page 11]
Internet-Draft RPC Netids December 2008
Appendix A. 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.]
Author's Address
Mike Eisler
NetApp
5765 Chase Point Circle
Colorado Springs, CO 80919
US
Phone: +1-719-599-9026
Email: mike@eisler.com
Eisler Expires June 13, 2009 [Page 12]
Internet-Draft RPC Netids December 2008
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.
Eisler Expires June 13, 2009 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-19 00:21:49 |