draft-ietf-nfsv4-federated-fs-dns-srv-namespace-09.txt   draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.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: April 9, 2012 J. Zhang Expires: April 28, 2012 J. Zhang
Google Google
October 7, 2011 October 26, 2011
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-09.txt draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.txt
Abstract Abstract
The NFS version 4 protocol provides a mechanism for a collection of The NFS version 4 protocol provides a mechanism 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 way for an
for an organization to publish the root of its filesystem name space, organization to publish the root of its filesystem name space, even
even to clients that might not be intimately associated with such an to 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 file name space. uniform NFS file name space.
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on April 9, 2012. This Internet-Draft will expire on April 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use of SRV Resource Record in DNS . . . . . . . . . . . . . . 4 3. Use of SRV Resource Record in DNS . . . . . . . . . . . . . . 4
4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6 4. Integration with Use of NFS Version 4 . . . . . . . . . . . . 6
4.1. Globally-useful names: conventional mount point . . . . . 6 4.1. Globally-useful names: conventional mount point . . . . . 6
4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Filesystem integration issues . . . . . . . . . . . . . . 8 4.3. Filesystem integration issues . . . . . . . . . . . . . . 7
4.4. Multicast, mDNS, and DNS-SD . . . . . . . . . . . . . . . 8 4.4. Multicast, mDNS, and DNS-SD . . . . . . . . . . . . . . . 8
5. Where is this integration carried out? . . . . . . . . . . . . 8 5. Where is this integration carried out? . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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
Version 4 of the NFS protocol [RFC3530] introduced the fs_locations Version 4 of the NFS protocol [RFC3530] introduced the fs_locations
skipping to change at page 5, line 27 skipping to change at page 5, line 27
The Service name is "_nfs._domainroot". The Protocol as of this The Service name is "_nfs._domainroot". The Protocol as of this
writing could be either "_tcp" or "_sctp"; version 4 NFS is not writing could be either "_tcp" or "_sctp"; version 4 NFS is not
defined over UDP. Other transport protocols could be defined in the defined over UDP. Other transport protocols could be defined in the
future, and SRV records that advertise domain root file services with future, and SRV records that advertise domain root file services with
other transport protocols would use the same Service name. The other transport protocols would use the same Service name. The
Target fields give the domain names of the NFS servers that export Target fields give the domain names of the NFS servers that export
filesystems for the domain's root. An NFS client may then interpret filesystems for the domain's root. An NFS client may then interpret
any of the exported root filesystems as the filesystem published by any of the exported root filesystems as the filesystem published by
the organization with the given domain name. the organization with the given domain name.
The domain root service is not useful for NFS versions prior to v4,
as the fs_locations attribute was introduced only in NFSv4 (as
described in Section 2). The "_nfs." Service name prefix is not
limited to NFSv4; it is possible to use that prefix in naming
additional Services (and their SRV records) that are also applicable
to other versions of NFS (e.g., NFSv3 [RFC1813].
In order to allow the NFSv4 servers so given to export a variety of In order to allow the NFSv4 servers so given to export a variety of
filesystems, those file servers MUST export the given domain's root filesystems, those file servers MUST export the given domain's root
filesystems at "/.domainroot-{Name}" within their pseudo-filesystems, filesystems at "/.domainroot-{Name}" within their pseudo-filesystems,
where the "{Name}" is the name of the organization as used in the SRV where the "{Name}" is the name of the organization as used in the SRV
RR. RR.
As an example, suppose a client wished to locate the root of the As an example, suppose a client wished to locate the root of the
filesystem published by organization example.net. The DNS servers filesystem published by organization example.net. The DNS servers
for the domain would publish records like for the domain would publish records like
skipping to change at page 5, line 50 skipping to change at page 6, line 8
The result domain names nfs1tr.example.net and nfs2ex.example.net The result domain names nfs1tr.example.net and nfs2ex.example.net
indicate NFS Version 4 file servers that export the root of the indicate NFS Version 4 file servers that export the root of the
published name space for the example.net domain. In accordance with published name space for the example.net domain. In accordance with
RFC 2782 [RFC2782], these records are to be interpreted using the RFC 2782 [RFC2782], these records are to be interpreted using the
Priority and Weight field values, selecting an appropriate file Priority and Weight field values, selecting an appropriate file
server with which to begin a network conversation. The two file server with which to begin a network conversation. The two file
servers would export filesystems that would be found at servers would export filesystems that would be found at
"/.domainroot-example.net" in their pseudo-filesystems, which clients "/.domainroot-example.net" in their pseudo-filesystems, which clients
would mount. Clients then carry out subsequent accesses in would mount. Clients then carry out subsequent accesses in
accordance with the ordinary NFS Version 4 protocol. accordance with the ordinary NFS Version 4 protocol. The records use
the port number 2049 assigned to NFS, but another port number could
be specified here; the NFS servers would provide NFS service at the
indicated port number, and NFS clients would connect to the service
at that indicated port number.
Other filesystem protocols could make use of the same "domain root" Other filesystem protocols could make use of the same "domain root"
abstraction, but this document discusses only the SRV records abstraction, as well as the same "_domainroot" Service name suffix,
indicating NFS servers. but this document discusses only the SRV records indicating NFS
servers.
4. Integration with Use of NFS Version 4 4. Integration with Use of NFS Version 4
NFSv4 clients adhering to this specification implement a special NFSv4 clients adhering to this specification implement a special
directory, analogous to an Automounter [AMD1][AMD2] directory, the directory, analogous to an Automounter [AMD1][AMD2] directory, the
entries in which are domain names that have recently been traversed. entries in which are domain names that have recently been traversed.
When an application attempts to traverse a new name in that special When an application attempts to traverse a new name in that special
directory, the NFSv4 client consults DNS to obtain the SRV data for directory, the NFSv4 client consults DNS to obtain the SRV data for
the given name, and if successful, it mounts the indicated the given name, and if successful, it mounts the indicated
filesystem(s) in that name in the special directory. The goal is filesystem(s) in that name in the special directory. The goal is
that NFS applications will be able to lookup an organization's domain that NFSv4 applications will be able to lookup an organization's
name in the special directory, and the NFSv4 client will be able to domain name in the special directory, and the NFSv4 client will be
discover the filesystem that that organization publishes. Entries in able to discover the filesystem that that organization publishes.
the special directory will be domain names, and they will each appear Entries in the special directory will be domain names, and they will
to the application as a directory name pointing to the root directory each appear to the application as a directory name pointing to the
of the filesystem published by the organization responsible for that root directory of the filesystem published by the organization
domain name. responsible for that domain name.
This DNS SRV record evaluation could, in principle, be done either in As noted in Section 3, the domain root service is not useful for NFS
the NFSv4 client or in an NFSv4 server. In either case, the result versions prior to version 4.
would appear the same to applications on the NFSv4 client. This is
discussed further in section 5 of this document.
4.1. Globally-useful names: conventional mount point 4.1. Globally-useful names: conventional mount point
In order that the inter-organizational name space function as a In order that the inter-organizational name space function as a
global name space, the client-side mount point for that name space global name space, the client-side mount point for that name space
must be the same on different clients. Conventionally, on POSIX must be the same on different clients. Conventionally, on POSIX
machines, the name /nfs4/ is be used so that names on one machine machines, the name /nfs4/ is be used so that names on one machine
will be directly usable on any machine. Thus, the example.net will be directly usable on any machine. Thus, the example.net
published filesystem would be accessible as published filesystem would be accessible as
skipping to change at page 7, line 25 skipping to change at page 7, line 35
The process of mounting an organization's name space should permit The process of mounting an organization's name space should permit
the use of what is likely to impose the lowest cost on the server. the use of what is likely to impose the lowest cost on the server.
Thus, the NFS client SHOULD NOT insist on using a writable copy of Thus, the NFS client SHOULD NOT insist on using a writable copy of
the filesystem if read-only copies exist, or a zero-age copy rather the filesystem if read-only copies exist, or a zero-age copy rather
than a copy that may be a little older. We presume that the than a copy that may be a little older. We presume that the
organization's file name space can be navigated to provide access to organization's file name space can be navigated to provide access to
higher-cost properties such as writability or freshness as necessary, higher-cost properties such as writability or freshness as necessary,
but that the default use when navigating to the base information for but that the default use when navigating to the base information for
an organization ought to be as low-overhead as possible. an organization ought to be as low-overhead as possible.
Because of the possible distinction between read-only and read-write
versions of a filesystem, organizations MAY also publish the location
of a writable instance of their domain root filesystems, and that
NFSv4 clients would conventionally mount that filesystem under the
organizational domain name preceded by a period ("."). Therefore,
when names beginning with a period are looked up under the NFSv4
client's special directory, the SRV RR looked up in DNS uses a
Service name of "_nfs._write._domainroot", and any indicated server
(or servers) MUST export the writable instance at "/.domainroot-
write-{Name}" for a domain name Name.
Extending the opening example, suppose a client wished to locate the
read-only and read-write roots of the filesystem published by
organization example.net. Suppose a read-write instance were hosted
on server nfs1tr.example.net, and read-only instances were on that
server and also on server nfs2ex.example.net. The DNS servers for
the domain would publish records like
$ORIGIN example.net.
_nfs._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
_nfs._domainroot._tcp IN SRV 1 0 2049 nfs2ex.example.net.
_nfs._write._domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
The nfs1tr.example.net server would export filesystems at both
"/.domainroot-example.net" (the read-only instance) and
"/.domainroot-write-example.net" (the read-write instance). The
nfs2ex.example.net server need export only the "/.domainroot-
example.net" name for its read-only instance.
The read-write version of the filesystem would be mounted (upon use)
under ".example.net" in the special directory, and a read-only
version would be mounted under "example.net". Thus,
/nfs4/example.net/users
might be a directory in a read-only instance of the root filesystem
of the organization "example.net", while
/nfs4/.example.net/users
would be a writable form of that same directory.
4.3. Filesystem integration issues 4.3. Filesystem integration issues
The result of the DNS search SHOULD appear as a (pseudo-)directory in The result of the DNS search SHOULD appear as a (pseudo-)directory in
the client name space. A further refinement is RECOMMENDED: that the client name space. A further refinement is RECOMMENDED: that
only fully-qualified domain names appear as directories. That is, in only fully-qualified domain names appear as directories. That is, in
many environments, DNS names may be abbreviated from their fully- many environments, DNS names may be abbreviated from their fully-
qualified form. In such circumstances, multiple names might be given qualified form. In such circumstances, multiple names might be given
to NFS clients that all resolve to the same DNS SRV RRs. The to NFS clients that all resolve to the same DNS SRV RRs. The
abbreviated form SHOULD be represented in the client's name space abbreviated form SHOULD be represented in the client's name space
cache as a symbolic link, pointing to the fully-qualified name, case- cache as a symbolic link, pointing to the fully-qualified name. This
folded if the client filesystem is case-sensitive. This will allow will allow pathnames obtained with, say, getcwd() to include the DNS
pathnames obtained with, say, getcwd() to include the DNS name that name that is most likely to be usable outside the scope of any
is most likely to be usable outside the scope of any particular DNS particular DNS abbreviation convention.
abbreviation convention.
4.4. Multicast, mDNS, and DNS-SD 4.4. Multicast, mDNS, and DNS-SD
Location of the NFS domain root does not involve IP-layer broadcast, Location of the NFS domain root by this mechanism does not involve
multicast, or anycast communication. IP-layer broadcast, multicast, or anycast communication.
It is not expected that this DNS SRV record format will be used in It is not expected that this DNS SRV record format will be used in
conjunction with Multicast DNS (mDNS) or DNS Service Discovery conjunction with Multicast DNS (mDNS) or DNS Service Discovery
(DNS-SD). While mDNS could be used to locate a local domain root via (DNS-SD). While mDNS could be used to locate a local domain root via
these SRV records, no other domain's root could be discovered. This these SRV records, no other domain's root could be discovered. This
means that mDNS with DNS-SD has too little value to use in locating means that mDNS with DNS-SD has too little value to use in locating
NFSv4 domain roots. NFSv4 domain roots.
5. Where is this integration carried out? 5. Where is this integration carried out?
skipping to change at page 11, line 4 skipping to change at page 10, line 4
the specified domain root filesystem(s). the specified domain root filesystem(s).
Using SRV records to advertise the locations of NFS servers may Using SRV records to advertise the locations of NFS servers may
expose those NFS servers to attacks. Organizations should carefully expose those NFS servers to attacks. Organizations should carefully
consider whether they wish their DNS servers to respond consider whether they wish their DNS servers to respond
differentially to different DNS clients, perhaps exposing their SRV differentially to different DNS clients, perhaps exposing their SRV
records to only those DNS requests that originate within a given records to only those DNS requests that originate within a given
perimeter, in order to reduce this exposure. perimeter, in order to reduce this exposure.
7. IANA Considerations 7. IANA Considerations
This document requests the assignment of two new Service names This document requests the assignment of a new Service name without
without associated port numbers, each for both TCP and SCTP. For an associated port numbers (as defined in RFC 6335 [RFC6335], each
both Services, the Reference is this document. for both TCP and SCTP. For this new Service, the Reference is this
document.
Service name: _nfs._domainroot Service name: _nfs._domainroot
Transport Protocol(s) TCP, SCTP Transport Protocol(s) TCP, SCTP
Assignee (REQUIRED) IESG (iesg@ietf.org) Assignee (REQUIRED) IESG (iesg@ietf.org)
Contact (REQUIRED) IETF Chair (chair@ietf.org) Contact (REQUIRED) IETF Chair (chair@ietf.org)
Description (REQUIRED) NFS file service for the domain root, the root Description (REQUIRED) NFS file service for the domain root, the root
of the organization's published file name space of the organization's published file name space
Reference (REQUIRED) This document Reference (REQUIRED) This document
Port Number (OPTIONAL) Port Number (OPTIONAL)
Service Code (REQUIRED for DCCP only) Service Code (REQUIRED for DCCP only)
Known Unauthorized Uses (OPTIONAL) Known Unauthorized Uses (OPTIONAL)
Assignment Notes (OPTIONAL) Assignment Notes (OPTIONAL)
Service name: _nfs._write._domainroot
Transport Protocol(s) TCP, SCTP
Assignee (REQUIRED) IESG (iesg@ietf.org)
Contact (REQUIRED) IETF Chair (chair@ietf.org)
Description (REQUIRED) Writable file server for the NFS file service
for the domain root, the root of the organization's
published file name space
Reference (REQUIRED) This document
Port Number (OPTIONAL)
Service Code (REQUIRED for DCCP only)
Known Unauthorized Uses (OPTIONAL)
Assignment Notes (OPTIONAL)
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, November 1987. RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
skipping to change at page 13, line 5 skipping to change at page 11, line 41
[AMD2] Crosby, M., "AMD--AutoMount Daemon", Linux Journal 1997, [AMD2] Crosby, M., "AMD--AutoMount Daemon", Linux Journal 1997,
35es Article 4, March 1997. 35es Article 4, March 1997.
[DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V., [DFS] Kazar, M., Leverett, B., Anderson, O., Apostolides, V.,
Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S., Bottos, B., Chutani, S., Everhart, C., Mason, W., Tu, S.,
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.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995.
Authors' Addresses Authors' Addresses
Craig Everhart Craig Everhart
NetApp NetApp
800 Cranberry Woods Drive, Ste. 300 800 Cranberry Woods Drive, Ste. 300
Cranberry Township, PA 16066 Cranberry Township, PA 16066
US US
Phone: +1 724 741 5101 Phone: +1 724 741 5101
Email: everhart@netapp.com Email: everhart@netapp.com
 End of changes. 18 change blocks. 
94 lines changed or deleted 52 lines changed or added

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