draft-ietf-nfsv4-federated-fs-dns-srv-namespace-03.txt   draft-ietf-nfsv4-federated-fs-dns-srv-namespace-04.txt 
Network Working Group C. Everhart Network Working Group C. Everhart
Internet-Draft W. Adamson Internet-Draft W. Adamson
Intended status: Standards Track NetApp Intended status: Standards Track NetApp
Expires: October 1, 2010 J. Zhang Expires: November 26, 2010 J. Zhang
Google Google
March 30, 2010 May 25, 2010
Using DNS SRV to Specify a Global File Name Space with NFS version 4 Using DNS SRV to Specify a Global File Name Space with NFS version 4
draft-ietf-nfsv4-federated-fs-dns-srv-namespace-03.txt draft-ietf-nfsv4-federated-fs-dns-srv-namespace-04.txt
Abstract Abstract
The NFS version 4 protocol provides a natural way for a collection of The NFS version 4 protocol provides a natural way for a collection of
NFS file servers to collaborate in providing an organization-wide NFS file servers to collaborate in providing an organization-wide
file name space. The DNS SRV RR allows a simple and appropriate way file name space. The DNS SRV RR allows a simple and appropriate way
for an organization to publish the root of its name space, even to for an organization to publish the root of its name space, even to
clients that might not be intimately associated with such an clients that might not be intimately associated with such an
organization. The DNS SRV RR can be used to join these organization- organization. The DNS SRV RR can be used to join these organization-
wide file name spaces together to allow construction of a global, wide file name spaces together to allow construction of a global,
uniform NFS version 4 file name space. uniform NFS version 4 file name space.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 26, 2010.
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 October 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 3 3. Proposed Use of SRV Resource Record in DNS . . . . . . . . . . 4
4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 5 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6
4.1. Globally-useful names: conventional mount point . . . . . 5 4.1. Globally-useful names: conventional mount point . . . . . 6
4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Filesystem integration issues . . . . . . . . . . . . . . 7 4.3. Filesystem integration issues . . . . . . . . . . . . . . 8
5. Where is this integration carried out? . . . . . . . . . . . . 7 5. Where is this integration carried out? . . . . . . . . . . . . 8
6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 8 6. Relationship to DNS NFS4ID RR . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Background 2. Background
With the advent of fs_locations attributes in the NFS Version 4 With the advent of fs_locations attributes in the NFS Version 4
protocol [RFC3530], NFS servers can cooperate to build a file name protocol [RFC3530], NFS servers can cooperate to build a file name
space that crosses server boundaries, as detailed in the description space that crosses server boundaries, as detailed in the description
of referrals in [NB0510]. With NFS Version 4 referrals, a file of referrals in [NB0510] and as further developed in the NFS Version
server may indicate to its client that the file name tree beneath a 4 Minor Version 1 protocol [RFC5661]. With NFS Version 4 referrals,
given name in the server is not present on itself, but is represented a file server may indicate to its client that the file name tree
by a filesystem in some other set of servers. The mechanism is beneath a given name in the server is not present on itself, but is
general, allowing servers to describe any filesystem as being represented by a filesystem in some other set of servers. The
reachable by requests to any of a set of servers. Thus, starting mechanism is general, allowing servers to describe any filesystem as
with a single NFS Version 4 server, using these referrals, an NFS being reachable by requests to any of a set of servers. Thus,
Version 4 client might be able to see a large name space associated starting with a single NFS Version 4 server, using these referrals,
with a collection of interrelated NFS Version 4 file servers. An an NFS Version 4 client might be able to see a large name space
organization could use this capability to construct a uniform file associated with a collection of interrelated NFS Version 4 file
name space for itself. servers. An organization could use this capability to construct a
uniform file name space for itself.
An organization might wish to publish the starting point for this An organization might wish to publish the starting point for this
name space to its clients. In many cases, the organization will want name space to its clients. In many cases, the organization will want
to publish this starting point to a broader set of possible clients. to publish this starting point to a broader set of possible clients.
At the same time, it is useful to require clients to know only the At the same time, it is useful to require clients to know only the
smallest amount of information in order to locate the appropriate smallest amount of information in order to locate the appropriate
name space. Simultaneously, that required information should be name space. Simultaneously, that required information should be
constant through the life of an organization if the clients are not constant through the life of an organization if the clients are not
to require reconfiguration as administrative events change, for to require reconfiguration as administrative events change, for
instance, a server's name or address. instance, a server's name or address.
skipping to change at page 6, line 34 skipping to change at page 6, line 35
This DNS SRV record evaluation could, in principle, be done either in This DNS SRV record evaluation could, in principle, be done either in
the NFSv4 client or in an NFSv4 server. In either case, the result the NFSv4 client or in an NFSv4 server. In either case, the result
would appear the same to applications on the NFSv4 client. would appear the same to applications on the NFSv4 client.
4.1. Globally-useful names: conventional mount point 4.1. Globally-useful names: conventional mount point
For the inter-organizational name space to be a global name space, it For the inter-organizational name space to be a global name space, it
is useful for its mount point in local systems to be uniform as well. is useful for its mount point in local systems to be uniform as well.
On POSIX machines, the name /nfs4/ SHOULD be used so that names on On POSIX machines, the name /nfs4/ SHOULD be used so that names on
one machine will be directly usable on any machine. Thus, the one machine will< be directly usable on any machine. Thus, the
example.net published filesystem would be accessible as example.net published filesystem would be accessible as
/nfs4/example.net/ /nfs4/example.net/
on any POSIX client. Using this convention, "/nfs4/" is the name of on any POSIX client. Using this convention, "/nfs4/" is the name of
the special directory that is populated with domain names, leading to the special directory that is populated with domain names, leading to
file servers and filesystems that capture the results of SRV record file servers and filesystems that capture the results of SRV record
lookups. lookups.
4.2. Mount options 4.2. Mount options
SRV records are necessarily less complete than the information in the SRV records are necessarily less complete than the information in the
existing NFS Version 4 attributes fs_locations and the proposed existing NFS Version 4 attributes fs_locations [RFC3530] or
fs_locations_info. For the rootpath field of fs_location, as fs_locations_info [RFC5661]. For the rootpath field of fs_location,
mentioned, we use the "/.domainroot-{Name}" string. Thus, the or the fli_fs_root of fs_locations_info, we use the "/.domainroot-
servers listed as targets for the SRV resource records should export {Name}" string. Thus, the servers listed as targets for the SRV
the root of the organization's published filesystem as the directory resource records should export the root of the organization's
"/.domainroot-{Name}" (for the given organization Name) in its published filesystem as the directory "/.domainroot-{Name}" (for the
exported namespace. For example, for organization "example.net", the given organization Name) in its exported namespace. For example, for
directory "/.domainroot-example.net" should be used. organization "example.net", the directory "/.domainroot-example.net"
should be used.
As for the other attributes in fs_locations_info, the recommended As for the other attributes in fs_locations_info, the recommended
approach is for a client to make its first possible contact with any approach is for a client to make its first possible contact with any
of the referred-to servers, obtain the fs_locations_info structure of the referred-to servers, obtain the fs_locations_info structure
from that server, and use the information from that obtained from that server, and use the information from that obtained
structure as the basis for its judgment of whether it would be better structure as the basis for its judgment of whether it would be better
to use a different server representative from the set of servers for to use a different server representative from the set of servers for
that filesystem. that filesystem.
The process of mounting an organization's name space should permit The process of mounting an organization's name space should permit
skipping to change at page 9, line 23 skipping to change at page 9, line 27
such clients. Yet even if it is desirable to deploy this such clients. Yet even if it is desirable to deploy this
functionality on the NFS client side, it may be valuable as a functionality on the NFS client side, it may be valuable as a
transition aid for a site to be able to deploy it on the NFS server transition aid for a site to be able to deploy it on the NFS server
side: it may be easier for them to install it on special NFS servers side: it may be easier for them to install it on special NFS servers
rather than install it on all their NFS clients. Thus, from an rather than install it on all their NFS clients. Thus, from an
implementation standpoint, NFS clients SHOULD implement the implementation standpoint, NFS clients SHOULD implement the
functionality, and NFS servers MAY implement it. functionality, and NFS servers MAY implement it.
6. Relationship to DNS NFS4ID RR 6. Relationship to DNS NFS4ID RR
This DNS use has no obvious relationship to the NFS4ID RR. The This DNS use has no obvious relationship to the NFS4ID RR [Mesta].
NFS4ID RR is a mechanism to help clients and servers configure The NFS4ID RR is a mechanism to help clients and servers configure
themselves with respect to the domain strings used in "who" strings themselves with respect to the domain strings used in "who" strings
in ACL entries and in owner and group names. The authentication/ in ACL entries and in owner and group names. The authentication/
authorization domain string of a server need have no direct authorization domain string of a server need have no direct
relationship to the name of the organization that is publishing a relationship to the name of the organization that is publishing a
file name space of which this server's filesystems form a part. At file name space of which this server's filesystems form a part. At
the same time, it might be seen as straightforward or normal for such the same time, it might be seen as straightforward or normal for such
a server to refer to the ownership of most of its files using a a server to refer to the ownership of most of its files using a
domain string with an evident relationship to that NFS4ID-given domain string with an evident relationship to that NFS4ID-given
domain name, but this document imposes no such requirement. domain name, but this document imposes no such requirement.
skipping to change at page 11, line 23 skipping to change at page 11, line 27
[RFC5178] Williams, N. and A. Melnikov, "Generic Security Service [RFC5178] Williams, N. and A. Melnikov, "Generic Security Service
Application Program Interface (GSS-API) Application Program Interface (GSS-API)
Internationalization and Domain-Based Service Names and Internationalization and Domain-Based Service Names and
Name Type", RFC 5178, May 2008. Name Type", RFC 5178, May 2008.
[RFC5179] Williams, N., "Generic Security Service Application [RFC5179] Williams, N., "Generic Security Service Application
Program Interface (GSS-API) Domain-Based Service Names Program Interface (GSS-API) Domain-Based Service Names
Mapping for the Kerberos V GSS Mechanism", RFC 5179, Mapping for the Kerberos V GSS Mechanism", RFC 5179,
May 2008. May 2008.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, Editors, "Network
File System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010.
9.2. Informative References 9.2. Informative References
[AFS] Howard, J., "An Overview of the Andrew File System"", [AFS] Howard, J., "An Overview of the Andrew File System"",
Proc. USENIX Winter Tech. Conf. Dallas, February 1988. Proc. USENIX Winter Tech. Conf. Dallas, February 1988.
[AMD] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter [AMD] Pendry, J. and N. Williams, "Amd: The 4.4 BSD Automounter
Reference Manual", March 1991, Reference Manual", March 1991,
<http://docs.freebsd.org/info/amdref/amdref.pdf>. <http://docs.freebsd.org/info/amdref/amdref.pdf>.
[DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V.,
skipping to change at page 11, line 44 skipping to change at page 11, line 52
and E. Zayas, "DEcorum File System Architectural and E. Zayas, "DEcorum File System Architectural
Overview", Proc. USENIX Summer Conf. Anaheim, Calif., Overview", Proc. USENIX Summer Conf. Anaheim, Calif.,
June 1990. June 1990.
[Gudmundsson] [Gudmundsson]
Gudmundsson, O. and A. Hoenes, "Creation of a Registry for Gudmundsson, O. and A. Hoenes, "Creation of a Registry for
DNS SRV Record Service Prefixes", October 2009, <ftp:// DNS SRV Record Service Prefixes", October 2009, <ftp://
ftp.rfc-editor.org/in-notes/internet-drafts/ ftp.rfc-editor.org/in-notes/internet-drafts/
draft-gudmundsson-dns-srv-iana-registry-04.txt>. draft-gudmundsson-dns-srv-iana-registry-04.txt>.
[Mesta] Mesta, R., "A DNS RR for NFSv4 ID Domains", October 2005,
<http://tools.ietf.org/id/draft-ietf-nfsv4-dns-rr-00.txt>.
[NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4 [NB0510] Noveck, D. and R. Burnett, "Next Steps for NFSv4
Migration/Replication", October 2005, <ftp://www.ietf.org/ Migration/Replication", October 2005, <ftp://www.ietf.org/
internet-drafts/draft-noveck-nfsv4-migrep-00.txt>. internet-drafts/draft-noveck-nfsv4-migrep-00.txt>.
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183, Mockapetris, "New DNS RR Definitions", RFC 1183,
October 1990. October 1990.
Authors' Addresses Authors' Addresses
 End of changes. 14 change blocks. 
52 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/