idnits 2.17.1 draft-ietf-nfsv4-ipv4v6-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 -- 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 451, but no explicit reference was found in the text == Unused Reference: 'RFC1833' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC4007' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'RFC4506' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC5378' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC5531' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC1094' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'RFC2624' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC3493' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC3542' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC3593' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC4620' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 517, 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 (~~), 17 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 Bhargo Sunil, Ed. 4 Intended status: Standards Track Dhawal Bhagwat 5 Expires: April 21, 2011 Dipankar Roy 6 Rishikesh Barooah 7 NetApp 8 October 18, 2010 10 NFS operation over IPv4 and IPv6 11 draft-ietf-nfsv4-ipv4v6-00.txt 13 Abstract 15 This Internet-Draft provides the description of problem set faced by 16 NFS and its various side band protocols when implemented over IPv4 17 and IPv6 networks in various deployment scenarios. Solution to the 18 various problems are also given in the draft and are sought for 19 approval in the respective NFS and side band protocol versions. 21 Foreword 23 This "forward" section is an unnumbered section that is not included 24 in the table of contents. It is primarily used for the IESG to make 25 comments about the document. It can also be used for comments about 26 the status of the document and sometimes is used for the RFC2119 27 requirements language statement. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 21, 2011. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Various Deployment Scenarios . . . . . . . . . . . . . . . . . 4 71 4. PORTMAP and RPCBIND . . . . . . . . . . . . . . . . . . . . . 5 72 5. NLM and NSM . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 6. Client Identification . . . . . . . . . . . . . . . . . . . . 6 74 7. Dual to single stack mode transition . . . . . . . . . . . . . 8 75 8. NFSv4 Callback Information . . . . . . . . . . . . . . . . . . 9 76 9. Reply cache tuples for NFSv4 . . . . . . . . . . . . . . . . . 9 77 10. Other optimizations . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Address Persistence . . . . . . . . . . . . . . . . . . . 10 79 10.2. IP addresses as keys . . . . . . . . . . . . . . . . . . 11 80 10.3. NFSv4 Id Mapping . . . . . . . . . . . . . . . . . . . . 11 81 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 14.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Terminology 91 Host: Used to refer to the client or the server where the specific(s) 92 of client or the server does not matter. 94 IPv4: Internet Protocol Version 4. 96 IPv6: Internet Protocol Version 6. 98 NFS: Used to refer to Network File System irrespective of the 99 version. 101 NFSv2: Network File System Protocol Version 2. 103 NFSv3: Network File System Protocol version 3. 105 NFSv4: Network File System Protocol version 4. 107 NFSv4.1: Network File System Protocol version 4.1. 109 NLM: Network Lock Manager Protocol. 111 NSM: Network Status Monitor Protocol. 113 Operation: Refers to the NFS operation when its mode of request or 114 response is inconsequential. 116 2. Introduction 118 This draft addresses problems associated with operating NFS in an 119 environment that has a mix of IPv4 and IPv6. 121 3. Various Deployment Scenarios 123 The various deployment scenarios involving a mix of IPv4 and IPv6, 124 are as follows: 126 (a) Client in IPv4-only network and Server in IPv6-only network. 127 (b) Client in IPv6-only network and Server in IPv4-only network. 128 (c) Client in IPv4 and IPv6 capable network and Server too in IPv4 129 and IPv6 capable network. 131 The first two scenarios can be called asymmetric single stack mode. 132 The third scenario can be called dual stack mode. 134 Note: These scenarios - 135 (a) Client in IPv4-only network and Server in IPv4-only network. 136 (b) Client in IPv6 only network and Server in IPv6-only network. 138 can be referred to as symmetric single stack mode. They are not 139 discussed in this document, as the focus of this document is 140 scenarios that have a mix of IPv4 and IPv6. 142 The problems discussed below are primarily related to sharing of NFS 143 state across different protocol address families. State come into 144 picture in NFS, in case of NLM/NSM, and NFSv4. 146 4. PORTMAP and RPCBIND 148 Clients SHOULD use PORTMAP (version 2) while querying IPv4 server 149 addresses, and RPCBIND (version 3/4) while querying IPv6 server 150 addresses. 152 Similarly, servers should use PORTMAP (version 2) while querying 153 clients for making callbacks to IPv4 client addresses and RPCBIND 154 (version 3/4) while querying clients making callbacks to IPv6 client 155 addresses. 157 Callbacks from server to client are needed in case of port 158 information verification (NFSv4), asynchronous lock requests (NLM), 159 and delegation recalls (NFSv4). 161 5. NLM and NSM 163 Clients and servers should use the "caller_name" (in the NLM_LOCK 164 call), and the "mon_name" (in the SM_NOTIFY call) as the identity of 165 the caller. This will make the identify of the caller independent of 166 the protocol address family, and will help in proper operation in the 167 situations described below in this section. 169 A dual stack NSM server implementation with persistent recording of 170 source IP address, SHOULD record at least one IPv4 and one IPv6 171 address for the client (from the caller_name in the NLM_LOCK 172 request), so that in case of a reboot, it can send out NOTIFY 173 messages to the client via either/both protocol address families. 175 This will ensure proper operation in scenarios like these : 177 (a) Client1 connects to the server using IPv6 address. 178 (b) Client2 connects to the server using IPv4 address. 179 (c) The server switches from dual stack to single stack mode of 180 operation. 181 (d) Server restarts. 183 Step 'c' can happen due to a network or interface disruption, or it 184 could also happen as part of step 'd' (due to administrative action 185 during step 'd'). Either way, it will result in loss of ability of 186 the server to communicate with the clients via one of the protocol 187 address families. 189 To handle such scenarios, the server SHOULD associate one IP address 190 for each protocol address family, with the client (caller_name from 191 the NLM_LOCK call). Otherwise, after step 'd', the server will not 192 be able to send a SM_NOTIFY to some of the clients. This will result 193 in those clients incorrectly assuming that the server is holding 194 their locks, when infact the server is not. 196 When clients receive a SM_NOTIFY from a server via one address 197 family, they SHOULD try to determine whether they hold locks on that 198 server (mon_name in the SM_NOTIFY call) via the other address family, 199 and if so, they SHOULD reclaim those locks too from the server. 201 Similarly, to handle the scenario where a dual stack client switches 202 to a single stack mode, and restarts, a server, when it receives a 203 SM_NOTIFY from a client on one address family, should try to 204 determine whether it holds any lock for that client (mon_name in the 205 SM_NOTIFY call), on another address family, and if so, it should 206 clear those locks too. 208 6. Client Identification 210 In the case of NFSv4.1, the short hand clientid is very similar to 211 NFSv4.0 clientid. Since states are tied to clientid, state sharing 212 across and within sessions are immune to individual connection 213 failures. The sessions from individual connections of an address 214 family can be failed over to another address family if available. 216 For NFSv4 however, RFC3530 [RFC3530] says - that a client MUST send a 217 different client string in SETCLIENTID to a different destination 218 addresses(s)/family of address(s). Even if the same server is 219 servicing on a different network address/address family the server 220 MUST return a different clientid to the client. This is to prevent 221 confusion on the client side as there is no way of determining 222 whether the server to which the client is connecting again is the 223 same or not. 225 The client using different client strings for different network 226 addresses / address families might result in a case that the multiple 227 requests from the same client conflict with each other on a 228 multihomed server, and result in revocation of delegation. This can 229 happen in this scenario: 231 (a) Client establishes a connection to server on address X and then 232 opens the file Z in write mode. 233 (b) Server grants the client a write delegation. 234 (c) The connection the client had established with server address X 235 in step a), breaks for some reason. Client establishes another 236 connection with server address Y, and then tries to open the 237 file Z. 239 In step c) as client is trying to connect to a different server 240 address/address family, it would send the SETCLIENTID with different 241 client string than in step a). Since servers generate clientid based 242 on client string, the clientid generated by the server in step c) 243 will be different than the clientid generated by the server in step 244 a). The server will then end up revoking the delegation granted in 245 step b). 247 Step c) can happen if the client side faced a disruption on one of 248 its address families and then connected on a different address family 249 to the server. Example would be client connected using IPv6 in step 250 a) and then client IPv6 stack or interfaces faced disruption after 251 step b). Client then used IPv4 to connect to the server in step c). 253 To handle such scenarios, the implementations should do the following 254 - 256 (a) The client SHOULD use the same client string irrespective of 257 which server address or address family it is communicating with. 258 (b) For generating the clientid, the server SHOULD use a combination 259 of the client string with its own server identifier. The server 260 identifier should be generated in a unique way on similar lines 261 as that of the client identifier. Specifically the server 262 identifier should be such that no two servers should use the 263 same server identifier. An example of well generated server 264 identifier can be the one that includes the following: 265 (c) 266 (a) a) MAC address 267 (b) b) Machine serial number 268 (d) The client SHOULD always send the SETCLIENTID as the first 269 request on the connection; even if the client is retransmitting 270 the request. If the clientid returned by server is the same as 271 a clientid that the client has received from some server in the 272 past, the client SHOULD conclude that both the connections are 273 to the same server. To prevent the server from expunging the 274 client due to non renewal, the client should send a RENEW even 275 if it does not have a lease after a SETCLIENTID to the server. 277 With the above mechanism, in the preceding example, the client string 278 in step c) would have been the same as step a) and therefore the 279 server would not revoke the delegation granted in step b). 280 Additionally, the clientid returned by the server in setp c) would be 281 the same as that in step a), and so the client would know that it is 282 communicating to the same server as in step a). 284 7. Dual to single stack mode transition 286 Dual stack implementations of NFS over IPv4 and IPv6 should ensure 287 that the shutdown of one stack implementation does not leave any data 288 in indeterminate state. This means that state like locks that is 289 shared between both IPv4 and IPv6 paths, should be handled carefully. 290 A shutdown of one path could result in a partial or complete 291 unreachability to the client, temporarily or permanently. To allow 292 for possible reconnects after reachability condition are restored, 293 the states SHOULD be left intact. To handle scenarios where 294 reachability is not expected to be restored within any reasonable 295 period of time, administrative action SHOULD be used for clearing the 296 appropriate states (removal, cleanup etc). 298 Shutting down of one address family stack, or loss of all interfaces 299 of one address family, SHOULD NOT lead to NFSv4 client states being 300 removed upon lease period expiry. This is required so that server 301 does not grant conflicting access to other clients via a different 302 address family; otherwise, they may find data file to be in some 303 inconsistent state, leading to corruption. 305 Consider this scenario - 307 a) An IPv6 client A is connected to the server and is accessing file 308 X, and has some state on the server, for that file. 310 b) The partial reachability condition happens for IPv6. 312 c) An IPv4 client B connects to the server and tries to access file X 313 on which the client A had states. 315 If after step b), the server had removed the state, then client B 316 might find the file to be in unusable state and so the state for 317 client A should be maintained unless the disruption due to step b) is 318 permanent, in which case the administrator needs to take some steps 319 to check / restore file X to some proper state, and then clear the 320 state the server had for client A, for file X. 322 For NFSv4, one of the ways to implement the above recommendation is 323 that the server should mark the client and the states associated with 324 it as temporarily unusable but should not remove the state associated 325 with the clients in such case. After the complete reachability is 326 restored the server should go into partial restart case for only the 327 clients that had their state marked as temporarily unusable and thus 328 should allow such clients to regain their state. The server should 329 identify the clientid/states that are marked as temporarily unusable 330 and should send those client the NFSERR_STALE_CLIENTID/ 331 NFSERR_STALE_STATEID errors, which will start the state recovery 332 procedure on the client side. The server can remove the client state 333 if the clients have not recovered the state in the grace period after 334 the complete reachability condition has been restored. 336 For example, if the partial reachability condition affected only the 337 clients accessing the server over IPv6, then after the reachability 338 is restored, the grace period should be started only for the clients 339 coming over IPv6. Till the time the grace period completes, clients 340 coming over IPv4, trying to take locks that conflict with ones being 341 held by IPv6 clients, should be denied. 343 In such cases, for NLM, the SM_NOTIFYs should be sent only to the 344 IPv6 clients (the ones that were affected due to partial reachability 345 condition). 347 8. NFSv4 Callback Information 349 The NFSv4 server implementation SHOULD verify the netid information 350 in the callbacks corresponds to respective address families. The 351 netid used for IPv6 address SHOULD be tcp6 and for IPv4 addresses, it 352 SHOULD be tcp. Otherwise, the callback information SHOULD be 353 rejected as incorrect. 355 9. Reply cache tuples for NFSv4 357 Reply cache implementations usually use some combination of elements 358 like client address, client port, server address, protocol, RPC XID, 359 etc., to index into the reply cache. Use of the client IP usually 360 has a drawback; for example, a client using a different source IP 361 address + port while retransmitting a request, might result in a 362 reply cache miss on the server. 364 In environments where there is a mix of IPv4 and IPv6, there are 365 greater chances of a server seeing a different source IP + port for a 366 client retransmission. For example, one address family being 367 completely disabled on a client, might cause the client to send 368 retransmissions from a different address family (and therefore 369 different source IP), as compared to the original request. 371 Therefore, reply cache indexing mechanisms, that don't rely on client 372 IP address, will add considerable value in environments having a mix 373 of IPv4 and IPv6. One alternative could be using the client string 374 instead of the client IP address, for the indexing, as explained here 375 - 377 As mentioned in Client Identification (Section 6) - 379 The client SHOULD always send the same client string, irrespective of 380 the server address that it is communicating with. Also, the NFSv4.0 381 client should always send the SETCLIENTID procedure as the first 382 request on any connection to the server. If a request is to be 383 retransmitted on a different connection, the first procedure sent out 384 should be a SETCLIENTID with no change in the callback address or 385 client string or verifier. This will help the server to associate 386 the new connection with the clientid. 388 Once a connection is associated with an existing clientid (and 389 therefore, an existing client string), any request restransmission on 390 the new connection can then successfully be indexed to it's match in 391 the reply cache, in a NFSv4 reply cache implementation that uses the 392 client string instead of the client IP address, for indexing into the 393 reply cache. 395 10. Other optimizations 397 10.1. Address Persistence 399 There are scenarios where NFS implementations need to store IP 400 addresses in persistent storage, like - 402 NSM monitor/notify database. 404 persistent reply cache. 406 In such scenarios, to support dual stack mode, or a switch to/from 407 it, implementations should store the protocol address family 408 information explicitly, along with the IP address. This information 409 can be used during upgrades and downgrades, across versions which 410 have may or may not have turned on support for NFS over IPv6. 412 10.2. IP addresses as keys 414 Functionalities like export checks require information to be indexed 415 based on client IP, for efficient insertion / updation, and lookup. 417 When using IP addresses as keys in these scenarios, the variability 418 of the bits in the IP addresses SHOULD be considered. In IPv6, for 419 the same interface, the different addresses might differ mostly in 420 the subnet part (the lower order bits are often generated from the 421 MAC address of the interface and are therefore mostly static). In 422 IPv4 however, that may not be the case. Depending on the 423 implementation specifics, different indexing algorithms might be 424 needed for IPv4 and IPv6 addresses. 426 10.3. NFSv4 Id Mapping 428 The "dns_domain" in "user@dns_domain" as referred to in section 5.8 429 [RFC3530], used to map owners, groups, users and user groups string 430 principals, to internal representations (usually numeric id) at the 431 client and server SHOULD be the same for the same client accessing an 432 NFSv4 server simultaneously over IPv4 and IPv6. 434 11. Acknowledgments 436 The authors would like to acknowledge Mike Eisler for reviews of the 437 various versions of the draft. 439 12. IANA Considerations 441 This memo includes no request to IANA. 443 13. Security Considerations 445 All considerations from RFC 3530 Section 16 [RFC3530] 447 14. References 449 14.1. Normative References 451 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 452 Version 3 Protocol Specification", RFC 1813, June 1995. 454 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 455 RFC 1833, August 1995. 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997, 459 . 461 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 462 (IPv6) Specification", RFC 2460, December 1998. 464 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 465 Beame, C., Eisler, M., and D. Noveck, "Network File System 466 (NFS) version 4 Protocol", RFC 3530, April 2003. 468 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 469 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 470 March 2005. 472 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 473 Architecture", RFC 4291, February 2006. 475 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 476 STD 67, RFC 4506, May 2006. 478 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 479 to the IETF Trust", BCP 78, RFC 5378, November 2008. 481 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 482 Specification Version 2", RFC 5531, May 2009. 484 [netid_ID] 485 Eisler, M., "IANA Considerations for RPC Net Identifiers 486 and Universal Address Formats", 487 draft-ietf-nfsv4-rpc-netid-04 (work in progress), 488 December 2008. 490 14.2. Informative References 492 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 493 specification", RFC 1094, March 1989. 495 [RFC2624] Shepler, S., "NFS Version 4 Design Considerations", 496 RFC 2624, June 1999. 498 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 499 Translator (NAT) Terminology and Considerations", 500 RFC 2663, August 1999. 502 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 503 Stevens, "Basic Socket Interface Extensions for IPv6", 504 RFC 3493, February 2003. 506 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 507 "Advanced Sockets Application Program Interface (API) for 508 IPv6", RFC 3542, May 2003. 510 [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using 511 Performance History Based on 15 Minute Intervals", 512 RFC 3593, September 2003. 514 [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information 515 Queries", RFC 4620, August 2006. 517 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 518 Specifications: ABNF", STD 68, RFC 5234, January 2008. 520 Authors' Addresses 522 Alex RN (editor) 523 NetApp 524 3rd Floor, Fair Winds Block, EGL Software Park, 525 Bangalore, Karnataka 560071 526 IN 528 Phone: +91-80-41843352 529 Email: rnalex@netapp.com 531 Bhargo Sunil (editor) 532 NetApp 533 3rd Floor, Fair Winds Block, EGL Software Park, 534 Bangalore, Karnataka 560071 535 IN 537 Phone: +91-80-41843963 538 Email: bhargo@netapp.com 540 Dhawal Bhagwat 541 NetApp 542 3rd Floor, Fair Winds Block, EGL Software Park, 543 Bangalore, Karnataka 560071 544 IN 546 Phone: +91-80-41843134 547 Email: dhawal@netapp.com 548 Dipankar Roy 549 NetApp 550 3rd Floor, Fair Winds Block, EGL Software Park, 551 Bangalore, Karnataka 560071 552 IN 554 Phone: +91-80-41843303 555 Email: dipankar@netapp.com 557 Rishikesh Barooah 558 NetApp 559 3rd Floor, Fair Winds Block, EGL Software Park, 560 Bangalore, Karnataka 560071 561 IN 563 Email: rbarooah@netapp.com