idnits 2.17.1 draft-alexrn-nfsv4-ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (June 27, 2009) is 5417 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 587, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC4506' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC5378' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC5531' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC1094' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'RFC2624' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC3593' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC4620' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 653, 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: 4 errors (**), 0 flaws (~~), 12 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: December 29, 2009 Dipankar Roy 6 Rishikesh Barooah 7 NetApp 8 June 27, 2009 10 NFS operation over IPv4 and IPv6 11 draft-alexrn-nfsv4-ipv6-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 29, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This Internet-Draft provides the description of problem set faced by 50 NFS and its various side band protocols when implemented over IPv6 in 51 various deployment scenarios. Solution to the various problems are 52 also given in the draft and are sought for approval in the respective 53 NFS and side band protocol versions. 55 Foreword 57 This "forward" section is an unnumbered section that is not included 58 in the table of contents. It is primarily used for the IESG to make 59 comments about the document. It can also be used for comments about 60 the status of the document and sometimes is used for the RFC2119 61 requirements language statement. 63 Requirements Language 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 Table of Contents 71 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Various Deployment Scenarios . . . . . . . . . . . . . . . 4 74 3. Multi homing support . . . . . . . . . . . . . . . . . . . . . 5 75 4. RPCBIND . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5. NLM and NSM . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6. Client Identification . . . . . . . . . . . . . . . . . . . . 9 78 7. Dual to single stack mode transition . . . . . . . . . . . . . 10 79 8. NFSv4 Callback Information . . . . . . . . . . . . . . . . . . 11 80 9. Reply cache tuples for NFSv4 . . . . . . . . . . . . . . . . . 12 81 10. External Interfaces . . . . . . . . . . . . . . . . . . . . . 12 82 11. Other optimizations . . . . . . . . . . . . . . . . . . . . . 13 83 11.1. Address Persistence . . . . . . . . . . . . . . . . . . . 13 84 11.2. IP addresses as keys . . . . . . . . . . . . . . . . . . . 13 85 11.3. NFSv4 Id Mapping . . . . . . . . . . . . . . . . . . . . . 13 86 12. Consideration for running NFS along with NAT/ALG . . . . . . . 13 87 12.1. Asymmetric Reachability . . . . . . . . . . . . . . . . . 14 88 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 89 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 15. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 16.1. Normative References . . . . . . . . . . . . . . . . . . . 14 93 16.2. Informative References . . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 96 1. Terminology 98 ALG: Application Level Gateway. 100 NFS-ALG: NFS Application Level Gateway. 102 Host: Used to refer to the client or the server where the specific(s) 103 of client or the server does not matter. 105 IPv4: Internet Protocol Version 4. 107 IPv6: Internet Protocol Version 6. 109 NAT: Network Address Translator. 111 NFS: Used to refer to Network File System irrespective of the 112 version. 114 NFSv2: Network File System Protocol Version 2. 116 NFSv3: Network File System Protocol version 3. 118 NFSv4: Network File System Protocol version 4. 120 NFSv4.1: Network File System Protocol version 4.1. 122 NLM: Network Lock Manager Protocol. 124 NSM: Network Status Monitor Protocol. 126 Operation: Refers to the NFS operation when its mode of request or 127 response is inconsequential. 129 2. Introduction 131 NFS being a application layer protocol can operate over several 132 network layer protocols. This draft addresses problems associated 133 with NFS operation over IPv4 and IPv6. NFS follows the client server 134 approach and does not restrict the network layer capability of the 135 hosts. 137 2.1. Various Deployment Scenarios 139 The various deployment scenarios are as follows: 141 (a) Client in IPv4 only network and Server being in IPv4 only 142 network. 143 (b) Client in IPv6 only network and Server being in IPv6 only 144 network. 145 (c) Client in IPv4 only network and Server being in IPv6 only 146 network. 147 (d) Client in IPv6 only network and Server being in IPv4 only 148 network. 149 (e) Client in IPv4 and IPv6 capable network and Server being in IPv4 150 and IPv6 capable network 152 In the above mentioned scenarios, types a) b) are called symmetric 153 stack mode of operation. Type c) and d) can be called as asymmetric 154 stack mode . Type a)-d) can be interchangeably be called as single 155 stack mode. Type e) can be interchangeably be called as dual stack 156 mode. 158 In the case of asymmetric stack operation mode the client and server 159 MUST use protocol translation at the network level and the 160 application level. This is achieved using a combination of network 161 level and application level protocol address translations done using 162 NAT-PT and NFS-ALG. 164 The problems which are discussed below are primarily related to state 165 sharing across different protocol address families. The states are 166 maintained through NFSv4(or later versions) and NLM/NSM. 168 3. Multi homing support 170 IPv6 supports various types of scoped addresses which can be 171 ambiguous at the scope boundary as referenced in [RFC4007] . A link 172 local address is one whose validity is only within a link and hence 173 is link scoped. Global addresses on the other hand are valid across 174 links. 176 In IPv6 case we can have link local address in a link scope boundary 177 like say Host H1 having 2 interfaces connected to Clients C1,C2 on 178 two links L1 and L2 as below. 180 Typical multi homed host 182 C1------- H1-----------C2 184 Figure 1 186 The link local address is ambiguous because of the private nature 187 Link L1 and L2 could have the same address (similar to private 188 addresses of 10.x , 192.x in IPv4. In IPv4 this is an exception but 189 for IPv6 this is default, due to auto configuration). In the case of 190 outbound packet transmission the link scope could be ambiguous and 191 MUST be explicitly specified or the implementation MAY support a 192 default scoped addresses. 194 NFS as a service operating in the link scope boundary MAY need to 195 explicitly specify its scope of communication using a scope 196 identifier [RFC4007], depending on different client scenarios 197 supported. NFS over IPv6 using link local address MAY be supported. 198 In particular, the NFS server or client may or may not decide to 199 support the scope field in an IPv6 link local address. 201 NFS servers on scope boundaries doing an outbound communication, the 202 scope SHOULD be derived from the inbound context when the server 203 receives an NFSv4.0 SETCLIENTID operation or an RPCBIND GETVERSADDR 204 procedure which contain universal addresses section 2.2 [RFC3530] . 205 Any outbound communication initiated like NFSv4 callbacks or NSM 206 notifies SHOULD use this information. 208 For scenarios like NFS servers running over IPv6 with only auto- 209 configured (link local only)addresses, some clients could boot off 210 the NFS servers. In such situations link local support SHOULD be 211 supported.The NFS server MAY provide for a default scope to operate 212 unambiguously. 214 4. RPCBIND 216 NFS servers supporting IPv6 MUST support RPCBINDv3 as defined in 217 [RFC1833], over IPv6. Additionally, RPCBINDv4 SHOULD be supported, 218 as noted later in this section. 220 RPCBINDv3/4 protocols 'use a transport-independent format for the 221 transport address'. Using RPCBINDv3/4, a client can clearly 222 communicate to the server which transport (IPv4/v6, TCP/UDP) it is 223 interested in for contacting a service.The server can communicate 224 clearly to the client, the various transports on which a service is 225 available. RPCBINDv2 (aka PORTMAP) provides limited support in this 226 area. 228 RPCBINDv4 SHOULD be supported because it introduces useful procedures 229 like, RPCBPROC_GETVERSADDR - to query the server for the address of a 230 specific version of an RPC service and RPCBPROC_GETADDRLIST - to 231 query the server for a list of all addresses / transports on which an 232 RPC service is available. 234 Supporting RPCBINDv3/4 over IPv4 is OPTIONAL, if supported it may 235 ease basic troubleshooting of IPv6 servers from IPv4 hosts. It may 236 also make it easier for applications to identify a transport of 237 interest, that the server supports, by making RPCBPROC_GETADDRLIST 238 calls over IPv4. 240 The netid and address formats in the RPCBINDv3/4 procedures, MUST be 241 as per those defined for netid and universal addresses, in netid_ID 242 draft [netid_ID]. The implementation SHOULD NOT use IPv4 embedded 243 IPv6 addresses defined in Section 2.5.5 [RFC4291], for the 244 RPCBINDv3/4 procedures. 246 Where specific information regarding a service is needed from a 247 server, a client SHOULD prefer the RPCBINDv4 procedure 248 RPCBPROC_GETVERSADDR over RPCBPROC_GETADDR. On the other hand, in 249 scenarios where a list of details is required, a client SHOULD use 250 the procedures RPCBPROC_DUMP and RPCBPROC_GETADDRLIST, as applicable. 252 An NFS implementation SHOULD NOT propagate the link local addresses 253 encoded as universal addresses from one link scope domain to another. 254 This could result in the following problem 256 a) Server has 2 different link local addresses, A1 and A2 on links L1 257 and L2 . 259 b) Client is in link L1. 261 c) Server publishes RPCBIND universal address of link local address 262 A1 and A2. 264 d) Client decided to connect using A2. 266 Step d) violates the usage of a link local private address as A2 267 could be assigned to a valid host in the link scope of L1. 269 5. NLM and NSM 271 A dual stack NSM server implementation with persistent recording of 272 source IP address SHOULD record at least one IPv4 and one IPv6 273 address, for sending out NOTIFY messages. 275 This will be required in the following scenario : 277 a) Client connects to the server using IPv6 address. 279 b) Client connects to the server using IPv4 address. 281 c) The server switches from dual stack to single stack mode of 282 operation. 284 d) Server restarts. 286 Step c) can happen due to a network or interface disruption. Step c) 287 can also happen after step d) which results in loss of ability of a 288 host to contact the other host on a particular address family after 289 restarting. 291 The server in this case SHOULD associate two client addresses with 292 the client identifier "caller_name" field as referenced in section 293 6.1.4 [RFC1833] . 295 After d) if the server does not record at least one address of each 296 address family, the server after restarting will not be able to send 297 NOTIFY to the client on the address family that faced disruption. 298 This will result in the client incorrectly assuming that the server 299 is holding locks when it is not, if the client expects the NOTIFY to 300 come on the same interface and same version of the IP protocol on 301 which the locks were requested. The client when it receives the 302 NOTIFY from the server holding locks, through one of the address 303 families SHOULD try to reclaim the locks it had established on the 304 other address family as well, if it can find out that both the 305 addresses or address families refer to the same server. 307 Another example is, the client after establishing the locks on the 308 server on both the address families, restarts. When the client comes 309 back up and if the server can not be contacted on one of the address 310 families, it SHOULD use the "caller_name" in the name field of the 311 NOTIFY so that server when it receives the NOTIFY should be able to 312 remove the locks the client had held on other address family as well. 314 The server SHOULD identify the client based on the "caller_name" 315 field in the NLM request and it SHOULD remain constant irrespective 316 of the address family that the client uses to contact the server. 317 This would help the server in identifying which client's lock to 318 release in the event the client sends the notify from a different 319 address family than the one on which it had sent the NLM operations. 320 This would also help in the case, when the mode of operation is 321 asymmetric stack and the intermediate NAT-PT changes source address 322 while connecting to the server. 324 Callback port information verification from server to client for IPv6 325 cases MUST be done through RPCBIND. The scenarios are asynchronous 326 lock requests and call back port verification during granting of 327 waiting locks. 329 6. Client Identification 331 In the case of NFS4.1 the short hand clientid is very similar to 332 NFSv4.0 clientid. Since states are tied to clientid, state sharing 333 across and within sessions are immune to individual connection 334 failures. The failures from individual connections of an address 335 family can be failed over to another address family if available. 337 As per current NFSv4.0 standards RFC3530 [RFC3530] server identifies 338 the client using the short identifier called as Client Identifier. 339 Client MUST send a different client string in SETCLIENTID to a 340 different destination addresses(s)/family of address(s). Even if the 341 same server is servicing on a different network address/address 342 family the server MUST return a different clientid to the client. 343 This is to prevent confusion on the client side as there is no way of 344 determining whether the server to which the client is connecting 345 again is the same or not. 347 The usage of different client strings for different network addresses 348 families might result in a case that the request(s) from the same 349 client be deemed to conflict and will result in revocation of 350 delegation. This can happen in the given client scenario: 352 a) Client establishes a connection to server on address X with 353 address family IPv4 and then opens the file Z in write mode. 355 b) Server grants the client will get a write delegation. 357 c)Client breaks the connection with server address X and/or tries to 358 establish another connection with server address Y with address 359 family B and then tries to open the file Z. 361 In step c) as client is trying to connect to a different server 362 address/address famiily it would send the SETCLIENTID with different 363 client string than in step a). As the clientid given in step c) will 364 be different than the clientid granted in step a) the server will end 365 up revoking the delegation granted in step b). This is because the 366 clientid is calculated based on client string which would be 367 different in step a) and step c). Step c) can happen even if the 368 client side faced a disruption on one of its address families and 369 then connected on a different address family to the server. Example 370 would be client connected using IPv4 in step a) and then client IPv4 371 stack or interfaces faced disruption after step b). Client then uses 372 the IPv6 to connect to server in step c). In either case after step 373 c) the client would not be holding the delegation. 375 To handle this case the server SHOULD NOT use the client string alone 376 in the generation of the short hand clientid but should combine the 377 client string with its own server identifier to calculate the 378 clientid. The server identifier should be generated in a unique way 379 on similar lines as that of the client identifier. Specifically the 380 server identifier should be such that no two servers should use the 381 same server identifier. An example of well generated server 382 identifier can be the one that includes the following : 384 a) MAC address 386 b) Machine serial number 388 The client SHOULD always send the SETCLIENTID as the first request on 389 the connection. Even if the client is retransmitting the request on 390 a new connection it SHOULD send the SETCLIENTID as the first request. 391 The client SHOULD use the same client string across different IP 392 address families as no two different servers would end up giving the 393 same clientid as both the components, client string and server 394 identifier, used in the calculation are unique. If the clientid 395 returned by server is the same as one of the existing clientid, the 396 client SHOULD conclude that both the connections are to the same 397 server. To prevent the server from expunging the client due to non 398 renewal, the client should send a RENEW even if it does not have a 399 lease after a SETCLIENTID to the server. 401 In the above example the client string in step c) would have been the 402 same as step a) and therefore the server would not revoke the 403 delegation granted in step b). 405 7. Dual to single stack mode transition 407 Dual stack implementations of NFS over IPv4 and IPv6 should ensure 408 that the shutdown of one stack implementation leaves the host in a 409 usable state. This is important for shared state like locks 410 accessible through both IPv4 and IPv6 paths. A shutdown of one path 411 would result in a permanent, partial, or temporary un-reachability to 412 the client. Anticipating reconnects, after the partial reachability 413 condition are resolved, the states should be left intact. 414 Administrative support for forceful lock management (removal /cleanup 415 etc) is recommended. 417 Shutting down of one stack IPv4/IPv6 or loss of all interfaces of one 418 particular address family IPv4/IPv6 should not result in the NFSv4.0 419 client states to be removed after the lease period expires. This is 420 required so that server does not grant the locks to any other client 421 reachable from another address family. If the locks are removed the 422 subsequent clients over IPv4, which are granted locks might find the 423 the file to be in unusable state. 425 a) If the IPv6 client A is connected to the server and has locks and 426 open share state. 428 b) The partial reachability condition happens for IPv6. 430 c) The IPv4 client B tries to access the files on which the client A 431 had states. 433 If after step b) the server had removed the state then the client B 434 might find the file to be in unusable state and so the state for 435 client A should be maintained unless the disruption due to step b) is 436 permanent, in which case the administrator needs to take some steps 437 to prevent the unusable file state. 439 For NFSv4 one of the ways to implement the above recommendation is 440 that the server should mark the client and the states associated with 441 it as temporarily unusable but should not remove the state associated 442 with the clients in such case. After the complete reachability is 443 restored the server should go into partial restart case for only the 444 clients that had their state marked as temporarily unusable and thus 445 should allow such clients to regain their state. The server should 446 identify the clientid/states that are marked as temporarily unusable 447 and should send the NFSERR_STALE_CLIENTID/NFSERR_STALE_STATEID which 448 will start the state recovery procedure on the client side. The 449 server can remove the client state if the clients have not recovered 450 the state in the grace period after the complete reachability 451 condition has been restored. 453 Supposedly the partial reachability condition affected only the 454 clients accessing the server over IPv6, after the reachability is 455 restored then the grace period should be started for only the clients 456 coming over IPv6. If the clients are coming over IPv4 contending for 457 the same lock for which is being held by IPv6 client the IPv4 client 458 should be denied. 460 For the case of NLM in such cases the NOTIFY should be sent to 461 clients that were affected due to partial reachability condition and 462 that had held the locks prior to that condition coming into effect. 464 8. NFSv4 Callback Information 466 In the case of asymmetric stack mode, if the client is in IPv6 467 network and tries to contact the server in IPv4 domain it should be 468 using an IPv6 address transparently translated by an ALG. The 469 intermediate network element (NFS-ALG) in the asymmetric stack mode 470 should convert the embedded addresses in the NFS operations so that 471 the other host can understand the network address. 473 The NFSv4 server implementation should verify the netid information 474 in the callbacks corresponds to respective address families. The 475 netid used for IPv6 address is tcp6 and for IPv4 addresses is tcp. 477 9. Reply cache tuples for NFSv4 479 Currently, most of the reply cache implementations use some form of 480 combination of the elements client address, client port, server 481 address, protocol, RPC XID as the values on which to decide on the 482 hit in the cache. But if the environment is such that the client is 483 working only in one address family and the server in another family 484 (no dual stack) and the translation is handled by an intermediate 485 element, then it might be possible that when the client retransmits 486 the request the source pair (address/port) that the server sees might 487 change from the previous connection values and the replay cache might 488 be rendered ineffective. It might also be that the client has lost 489 all of its interfaces of a particular address family and might switch 490 to another address family. It might also be the case that the client 491 uses a new source pair for the retransmission which will have the 492 similar effect. 494 As listed in Client Identification (Section 6) the client can obviate 495 the need to send different client strings to different server 496 addresses. The NFSv4.0 client should always send the SETCLIENTID 497 procedure as the first request to the server. If a request is to be 498 retransmitted on a different connection, the first procedure sent out 499 should be a SETCLIENTID with no change in the callback address or 500 client string or verifier. This will help the server to associate 501 the new connection with the clientid. 503 The replay cache implementations thus can switch to just using the 504 client string and RPC XID as the basis for determining a replay cache 505 hit, if the server is using the address/address family to determine 506 the cache hit. 508 10. External Interfaces 510 NFS servers considering usage of information like MTU control or 511 other lower level information from the IPv6 stack MAY consider, the 512 updated standard sockets APIs in the form of advanced sockets 513 implementation as specified in RFC 3542 [RFC3542] and RFC 3493 514 [RFC3493]. 516 In the case of client and server operating in different address 517 families with no dual stack support DNS-ALG and NAT-PT MUST be used. 519 11. Other optimizations 521 11.1. Address Persistence 523 In all cases where the IP addresses are stored in stable storage it 524 is always preferable to store addresses with the address family 525 information. The scenarios could be that of recording addresses for 526 NSM notifies and client addresses persistently stored for reply 527 cache. One way of implicit typing is with the IPv4 mapped IPv6 528 addresses for storage efficiency. It is RECOMMENDED that IPv6 529 support capability information is preserved. This information can be 530 used during upgrades and downgrades of NFS server instances which 531 have may or may not have turned on support for NFS over IPv6. 533 11.2. IP addresses as keys 535 There are a number of situations where decisions are based on the IP 536 addresses like access control, which determines which IP address gets 537 access and which does not. Other situations like distributing 538 resources based on the client IP addresses within an implementation 539 system, the resources could be the amount of cached replies. 541 When considering using IP addresses as keys into these scenarios, the 542 variability of the bits in the IP addresses SHOULD be considered. In 543 IPv6 for the same interface the different address differ mostly in 544 the non subnet part, in IPv4 that is not the case. The lower order 545 bits are generated from the MAC addresses and are mostly static. 547 11.3. NFSv4 Id Mapping 549 The "dns_domain" in "user@dns_domain" as referred in section 5.8 550 [RFC3530], used to map owners, groups, users and user groups in the 551 string principals to internal representations at the client and 552 server SHOULD be the same for the same client accessing an NFSv4 553 server simultaneously over IPv4 and IPv6. 555 12. Consideration for running NFS along with NAT/ALG 557 For NFS ALGs, the only information at the protocol level is the 558 embedded universal addresses, which SHOULD be translated for RPCBIND 559 and SETCLIENTID calls to work transparently. If names are used as 560 identifiers then DNS-ALG should be used for translating names. The 561 ALG SHOULD NOT multiplex multiple client side connections to single 562 server side connection. 564 12.1. Asymmetric Reachability 566 If the server is in IPv6/IPv4 address space and the client is in 567 IPv4/IPv6 address space connected through intermediate translation 568 network element, then a separate callback port can be fixed. 570 13. Acknowledgments 572 The authors would like to acknowledge Mike Eisler for reviews of the 573 various early versions of the draft. 575 14. IANA Considerations 577 This memo includes no request to IANA. 579 15. Security Considerations 581 All considerations from RFC 3530 Section 16 [RFC3530] 583 16. References 585 16.1. Normative References 587 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 588 Version 3 Protocol Specification", RFC 1813, June 1995. 590 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 591 RFC 1833, August 1995. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997, 595 . 597 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 598 (IPv6) Specification", RFC 2460, December 1998. 600 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 601 Beame, C., Eisler, M., and D. Noveck, "Network File System 602 (NFS) version 4 Protocol", RFC 3530, April 2003. 604 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 605 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 606 March 2005. 608 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 609 Architecture", RFC 4291, February 2006. 611 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 612 STD 67, RFC 4506, May 2006. 614 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 615 to the IETF Trust", BCP 78, RFC 5378, November 2008. 617 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 618 Specification Version 2", RFC 5531, May 2009. 620 [netid_ID] 621 Eisler, M., "IANA Considerations for RPC Net Identifiers 622 and Universal Address Formats", 623 draft-ietf-nfsv4-rpc-netid-04 (work in progress), 624 December 2008. 626 16.2. Informative References 628 [RFC1094] Nowicki, B., "NFS: Network File System Protocol 629 specification", RFC 1094, March 1989. 631 [RFC2624] Shepler, S., "NFS Version 4 Design Considerations", 632 RFC 2624, June 1999. 634 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 635 Translator (NAT) Terminology and Considerations", 636 RFC 2663, August 1999. 638 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 639 Stevens, "Basic Socket Interface Extensions for IPv6", 640 RFC 3493, February 2003. 642 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 643 "Advanced Sockets Application Program Interface (API) for 644 IPv6", RFC 3542, May 2003. 646 [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using 647 Performance History Based on 15 Minute Intervals", 648 RFC 3593, September 2003. 650 [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information 651 Queries", RFC 4620, August 2006. 653 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 654 Specifications: ABNF", STD 68, RFC 5234, January 2008. 656 Authors' Addresses 658 Alex RN (editor) 659 NetApp 660 3rd Floor, Fair Winds Block, EGL Software Park, 661 Bangalore, Karnataka 560071 662 IN 664 Phone: +91-80-41843352 665 Email: rnalex@netapp.com 667 Bhargo Sunil (editor) 668 NetApp 669 3rd Floor, Fair Winds Block, EGL Software Park, 670 Bangalore, Karnataka 560071 671 IN 673 Phone: +91-80-41843963 674 Email: bhargo@netapp.com 676 Dhawal Bhagwat 677 NetApp 678 3rd Floor, Fair Winds Block, EGL Software Park, 679 Bangalore, Karnataka 560071 680 IN 682 Phone: +91-80-41843134 683 Email: dhawal@netapp.com 685 Dipankar Roy 686 NetApp 688 Phone: +91-80-41843303 689 Email: dipankar@netapp.com 691 Rishikesh Barooah 692 NetApp 694 Email: rbarooah@netapp.com