idnits 2.17.1 draft-ietf-nfsv4-ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 71 has weird spacing: '...sses in multi...' == Line 168 has weird spacing: '...sses in multi...' -- The document date (October 18, 2010) is 4939 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1813' is defined on line 215, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 225, but no explicit reference was found in the text == Unused Reference: 'RFC4506' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'RFC5378' is defined on line 242, but no explicit reference was found in the text == Unused Reference: 'RFC5531' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'RFC1094' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC2624' is defined on line 259, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC3493' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'RFC3542' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'RFC3593' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC4620' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 281, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1813 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Alex RN, Ed. 3 Internet-Draft Dhawal Bhagwat, Ed. 4 Intended status: Standards Track Dipankar Roy 5 Expires: April 21, 2011 Rishikesh Barooah 6 NetApp 7 October 18, 2010 9 NFS operation over IPv6 10 draft-ietf-nfsv4-ipv6-00.txt 12 Abstract 14 This Internet-Draft provides the description of problems faced by NFS 15 and its various side band protocols, when implemented over IPv6 in 16 various deployment scenarios. Solutions to the various problems are 17 also given in the draft and are sought for approval. 19 Foreword 21 This "forward" section is an unnumbered section that is not included 22 in the table of contents. It is primarily used for the IESG to make 23 comments about the document. It can also be used for comments about 24 the status of the document and sometimes is used for the RFC2119 25 requirements language statement. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 21, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. RPCBIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. NFSv4 Callback Information . . . . . . . . . . . . . . . . . . 4 71 5. Handling of link-local addresses in multi-homed hosts . . . . 4 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Terminology 82 Host: Used to refer to the client or the server where the specific(s) 83 of client or the server does not matter. 85 IPv4: Internet Protocol Version 4. 87 IPv6: Internet Protocol Version 6. 89 NFS: Used to refer to Network File System irrespective of the 90 version. 92 NFSv2: Network File System Protocol Version 2. 94 NFSv3: Network File System Protocol version 3. 96 NFSv4: Network File System Protocol version 4. 98 NFSv4.1: Network File System Protocol version 4.1. 100 NLM: Network Lock Manager Protocol. 102 NSM: Network Status Monitor Protocol. 104 Operation: Refers to the NFS operation when its mode of request or 105 response is inconsequential. 107 2. Introduction 109 NFS being a application layer protocol can operate over several 110 network layer protocols. This draft addresses problems associated 111 with NFS operation over an IPv6 only network. 113 3. RPCBIND 115 NFS servers supporting IPv6 MUST support RPCBINDv3 as defined in 116 [RFC1833], over IPv6. Additionally, RPCBINDv4 SHOULD be supported, 117 as noted later in this section. 119 RPCBINDv3/4 protocols 'use a transport-independent format for the 120 transport address'. Using RPCBINDv3/4, a client can clearly 121 communicate to the server which transport (IPv4/v6, TCP/UDP) it is 122 interested in for contacting a service. The server can communicate 123 clearly to the client, the various transports on which a service is 124 available. RPCBINDv2 (aka PORTMAP) provides limited support in this 125 area. 127 RPCBINDv4 SHOULD be supported because it introduces useful procedures 128 -- 130 o RPCBPROC_GETVERSADDR - to query the server for the address of a 131 specific version of an RPC service. 133 o RPCBPROC_GETADDRLIST - to query the server for a list of all 134 addresses / transports on which an RPC service is available. 136 Clients SHOULD use those procedures wherever those procedures enable 137 them to get the information of interest in one go, instead of making 138 multiple RPCBPROC_GETADDR calls. 140 The netid and address formats in the RPCBINDv3/4 procedures, MUST be 141 as per those defined for netid and universal addresses, in netid_ID 142 draft [netid_ID]. The implementation MUST NOT use IPv4 embedded IPv6 143 addresses defined in Section 2.5.5 [RFC4291], for the RPCBINDv3/4 144 procedures. 146 An NFS client SHOULD specify a proper universal address in a 147 RPCBPROC_GETADDR call; specifically, it SHOULD match the server's IP 148 address on which the client made the call. 150 While processing the RPCBPROC_GETADDR call, the NFS server needs to 151 know which local address the client is querying on; the server SHOULD 152 pull that address from the network layer instead (the local address 153 on which the RPCBPROC_GETADDR call was received; similar to what 154 [RFC1833] recommends for the "r_netid" parameter - 156 The "r_netid" field of the argument is ignored and the "r_netid" is 157 inferred from the network identifier of the transport on which the 158 request came in.) 160 4. NFSv4 Callback Information 162 In the case of NFSv4.0 procedure SETCLIENTID, the netid and address 163 formats in the callback information MUST be as per those defined for 164 netid and universal addresses, in netid_ID draft [netid_ID]. The 165 implementation MUST NOT use IPv4 embedded IPv6 addresses defined in 166 Section 2.5.5 [RFC4291]. 168 5. Handling of link-local addresses in multi-homed hosts 170 [RFC4007] describes link-local IPv6 addresses. 172 There may be environments where hosts operate only with auto- 173 configured (link-local) addresses. NFS implementations SHOULD 174 support link-local addresses, so they can operate in such 175 environments. For example, hosts booting over the network, via NFS. 176 However, since link-local addresses are link-scoped, they can cause 177 ambiguity on multi-homed hosts. 179 An NFS implementation on a multi-homed host MUST keep track of the 180 local interface (zone) when communicating with a link-local address 181 of another host. Alternately, such hosts can support a default zone, 182 which the network layer can use when no interface info is specified 183 explicitly. See the 'Scope Zones' section of RFC 4007 [RFC4007] for 184 more on (scope) zones and their implementation. 186 While making a callback to an address received in a NLM LOCK call or 187 a NFSv4 SETCLIENTID call, a server MUST specify the local interface 188 via which the call needs to be made (or let the default zone be 189 selected, if supported). 191 An NFS implementation on multi-homed hosts MUST also make sure that a 192 link-local address of any one of it's (local) interfaces is not 193 advertised out in any way, via any of it's other (local) interfaces. 194 For instance, the address list that a NFS server returns in a 195 RPCBPROC_GETADDRLIST response, MUST NOT contain a link-local address 196 any interface other than the one on which the request was received 197 (which will be same as the one which the response is being sent out). 199 6. Acknowledgments 201 The authors would like to acknowledge Mike Eisler for reviews of the 202 various early versions of the draft. 204 7. IANA Considerations 206 This memo includes no request to IANA. 208 8. Security Considerations 210 All considerations from RFC 3530 Section 16 [RFC3530] 212 9. References 213 9.1. Normative References 215 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 216 Version 3 Protocol Specification", RFC 1813, June 1995. 218 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 219 RFC 1833, August 1995. 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, March 1997, 223 . 225 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 226 (IPv6) Specification", RFC 2460, December 1998. 228 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 229 Beame, C., Eisler, M., and D. Noveck, "Network File System 230 (NFS) version 4 Protocol", RFC 3530, April 2003. 232 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 233 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 234 March 2005. 236 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 237 Architecture", RFC 4291, February 2006. 239 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 240 STD 67, RFC 4506, May 2006. 242 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 243 to the IETF Trust", BCP 78, RFC 5378, November 2008. 245 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 246 Specification Version 2", RFC 5531, May 2009. 248 [netid_ID] 249 Eisler, M., "IANA Considerations for RPC Net Identifiers 250 and Universal Address Formats", 251 draft-ietf-nfsv4-rpc-netid-04 (work in progress), 252 December 2008. 254 9.2. Informative References 256 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 257 specification", RFC 1094, March 1989. 259 [RFC2624] Shepler, S., "NFS Version 4 Design Considerations", 260 RFC 2624, June 1999. 262 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 263 Translator (NAT) Terminology and Considerations", 264 RFC 2663, August 1999. 266 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 267 Stevens, "Basic Socket Interface Extensions for IPv6", 268 RFC 3493, February 2003. 270 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 271 "Advanced Sockets Application Program Interface (API) for 272 IPv6", RFC 3542, May 2003. 274 [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using 275 Performance History Based on 15 Minute Intervals", 276 RFC 3593, September 2003. 278 [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information 279 Queries", RFC 4620, August 2006. 281 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 282 Specifications: ABNF", STD 68, RFC 5234, January 2008. 284 Authors' Addresses 286 Alex RN (editor) 287 NetApp 288 3rd Floor, Fair Winds Block, EGL Software Park, 289 Bangalore, Karnataka 560071 290 IN 292 Phone: +91-80-41843352 293 Email: rnalex@netapp.com 295 Dhawal Bhagwat (editor) 296 NetApp 297 3rd Floor, Fair Winds Block, EGL Software Park, 298 Bangalore, Karnataka 560071 299 IN 301 Phone: +91-80-41843134 302 Email: dhawal@netapp.com 303 Dipankar Roy 304 NetApp 305 3rd Floor, Fair Winds Block, EGL Software Park, 306 Bangalore, Karnataka 560071 307 IN 309 Phone: +91-80-41843303 310 Email: dipankar@netapp.com 312 Rishikesh Barooah 313 NetApp 314 3rd Floor, Fair Winds Block, EGL Software Park, 315 Bangalore, Karnataka 560071 316 IN 318 Email: rbarooah@netapp.com