draft-ietf-nfsv4-federated-fs-dns-srv-namespace-11.txt   draft-ietf-nfsv4-federated-fs-dns-srv-namespace-12.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: June 23, 2012 J. Zhang Expires: September 1, 2012 J. Zhang
Google Google
December 21, 2011 February 29, 2012
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-11.txt draft-ietf-nfsv4-federated-fs-dns-srv-namespace-12.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 way for an file name space. The DNS SRV RR allows a simple way for an
organization to publish the root of its filesystem name space, even organization to publish the root of its filesystem name space, 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,
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 June 23, 2012. This Internet-Draft will expire on September 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 14 skipping to change at page 3, line 14
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 . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Mount options . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Filesystem integration issues . . . . . . . . . . . . . . 7 4.3. Filesystem integration issues . . . . . . . . . . . . . . 7
4.4. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 8
5. Where is this integration carried out? . . . . . . . . . . . . 8 5. Where is this integration carried out? . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Requirements notation 1. Requirements notation
skipping to change at page 4, line 46 skipping to change at page 4, line 46
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.
3. Use of SRV Resource Record in DNS 3. Use of SRV Resource Record in DNS
Providing an organization's published filesystem name space is a Providing an organization's published filesystem name space is a
service, and the DNS [RFC1034][RFC1035] provides methods for service, and the DNS [RFC1034][RFC1035] provides methods for
discovery of that service. This standard defines a mapping from a discovery of that service. This standard defines a mapping from a
domain name to the NFS filesystem(s) associated with that name; such DNS name to the NFS filesystem(s) providing the root of the
filesystems are called "domain root" filesystems. From such filesystem name space associated with that DNS name; such filesystems
filesystems, like other NFS filesystems, an NFS client can use the are called "domain root" filesystems. From such filesystems, like
standard NFS mechanisms to navigate the rest of the NFS file servers other NFS filesystems, an NFS client can use the standard NFS
that make up the filesystem name space for the given domain. mechanisms to navigate the rest of the NFS file servers that make up
the filesystem name space for the given domain.
Such "domain root" filesystems are mounted at a conventional point in Such "domain root" filesystems are mounted at a conventional point in
the NFS client namespace. The mechanism results in a uniform cross- the NFS client namespace. The mechanism results in a uniform cross-
organizational file name space, similar to that seen in both AFS organizational file name space, similar to that seen in both AFS
[AFS][RFC5864] and DCE/DFS [DFS]. An NFS client need know only the [AFS][RFC5864] and DCE/DFS [DFS]. An NFS client need know only the
domain name for an organization in order to locate the filesystem domain name for an organization in order to locate the filesystem
name space published by that organization. name space published by that organization.
The DNS SRV resource record type [RFC2782] is used to locate "domain The DNS SRV resource record type [RFC2782] is used to locate "domain
root" file servers. The format of the DNS SRV record is as follows: root" file servers. The format of the DNS SRV record is as follows:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target _Service._Proto.Name TTL Class SRV Priority Weight Port Target
The Service name used is "_domainroot._nfs" (using a "_domainroot" The Service name used is "_nfs-domainroot", in conformance with RFC
subtype within the "_nfs" service). The Protocol without limitation 6335 [RFC6335]. The Protocol name used is "_tcp", for NFS service
could be either of the labels "_tcp" or "_udp". The Target fields over TCP. Future NFS services using other protocols MUST use another
give the domain names of the NFS servers that export filesystems for Protocol name. The Target fields give the domain names of the NFS
the domain's root. An NFS client may then interpret any of the servers that export filesystems for the domain's root. An NFS client
exported root filesystems as the root of the filesystem published by may then interpret any of the exported root filesystems as the root
the organization with the given domain name. of the filesystem published by the organization with the given domain
name.
The domain root service is not useful for NFS versions prior to v4, The domain root service is not useful for NFS versions prior to v4,
as the fs_locations attribute was introduced only in NFSv4 (as as the fs_locations attribute was introduced only in NFSv4 (as
described in Section 2). The "_nfs" Service name is not limited to described in Section 2). The "_nfs" Service name is not limited to
NFSv4; it is possible to use that prefix in naming additional NFSv4; it is possible to use that prefix in naming additional
Services (and their SRV records) that are also applicable to other Services (and their SRV records) that are also applicable to other
versions of NFS (e.g., NFSv3 [RFC1813]. 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
$ORIGIN example.net. $ORIGIN example.net.
_domainroot._nfs._tcp IN SRV 0 0 2049 nfs1tr.example.net. _nfs-domainroot._tcp IN SRV 0 0 2049 nfs1tr.example.net.
_domainroot._nfs._tcp IN SRV 1 0 18204 nfs2ex.example.net. _nfs-domainroot._tcp IN SRV 1 0 18204 nfs2ex.example.net.
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
skipping to change at page 10, line 8 skipping to change at page 10, line 8
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 a new Service name without This document requests the assignment of a new Service name without
an associated port number (as defined in RFC 6335 [RFC6335]), for an associated port number (as defined in RFC 6335 [RFC6335]), for
TCP. For this new Service, the Reference is this document. TCP. For this new Service, the Reference is this document.
Service name: domainroot Service name: nfs-domainroot
Transport Protocol(s) TCP Transport Protocol(s) TCP
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) Subtype of NFS file service, indicating NFS Description (REQUIRED) NFS service for the domain root, the root of
service for the domain root, the root of an an organization's published file name space.
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)
8. References 8. References
8.1. Normative References 8.1. Normative References
 End of changes. 11 change blocks. 
24 lines changed or deleted 25 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/