idnits 2.17.1 draft-ietf-behave-64-analysis-07.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 115: '... "A NAT64 MAY perform the steps i...' RFC 2119 keyword, line 116: '...ut the externally visible outcome MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2012) is 4431 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-03 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-05 == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-media-path-middleboxes-04 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-23 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance R. Penno 3 Avoidance Juniper Networks 4 Internet-Draft T. Saxena 5 Intended status: Informational Cisco Systems 6 Expires: September 3, 2012 M. Boucadair 7 France Telecom 8 S. Sivakumar 9 Cisco Systems 10 March 2, 2012 12 Analysis of Stateful 64 Translation 13 draft-ietf-behave-64-analysis-07 15 Abstract 17 Due to specific problems, NAT-PT was deprecated by the IETF as a 18 mechanism to perform IPv6-IPv4 translation. Since then, new efforts 19 have been undertaken within IETF to standardize alternative 20 mechanisms to perform IPv6-IPv4 translation. This document analyzes 21 to what extent the new stateful translation mechanisms avoid the 22 problems that caused the IETF to deprecate NAT-PT. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 3, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Analysis of 64 Translation Against Concerns of RFC4966 . . . . 4 63 2.1. Problems Impossible to Solve . . . . . . . . . . . . . . . 5 64 2.2. Problems Which Can be Solved . . . . . . . . . . . . . . . 5 65 2.3. Problems Solved . . . . . . . . . . . . . . . . . . . . . 7 66 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 1.1. Definition 79 This document uses stateful 64 (or 64 for short) to refer to the 80 mechanisms defined in the following documents: 82 o IP/ICMP Translation Algorithm [RFC6145] 84 o Stateful NAT64: Network Address and Protocol Translation from IPv6 85 Clients to IPv4 Servers [RFC6146] 87 o DNS64: DNS extensions for Network Address Translation from IPv6 88 Clients to IPv4 Servers [RFC6147] 90 o IPv6 Addressing of IPv4/IPv6 Translators [RFC6052] 92 o Framework for IPv4/IPv6 Translation [RFC6144] 94 1.2. Context 96 Stateful 64 is widely seen as a major interconnection technique 97 designed to enable communications between IPv6-only and IPv4-only 98 networks. One of the building blocks of the stateful 64 is 99 decoupling the DNS functionality from the protocol translation 100 itself. 102 This approach is pragmatic in the sense that there is no dependency 103 on DNS implementation for the successful NAT handling. As long as 104 there is a function (e.g., DNS64 [RFC6147] or other means) that can 105 construct an IPv6-embedded IPv4 address with a pre-configured IPv6 106 prefix, an IPv4 address and a suffix (refer to [RFC6052]), NAT64 will 107 work just fine. 109 The focus of the stateful 64 is on the deployment and not the 110 implementation details. As long as a NAT64 implementation conforms 111 to the expected behavior, as desired in the deployment scenario, the 112 details are not very important as mentioned in this excerpt from 113 [RFC6146]: 115 "A NAT64 MAY perform the steps in a different order, or MAY 116 perform different steps, but the externally visible outcome MUST 117 be the same as the one described in this document." 119 1.3. Scope 121 This document provides an analysis of how the proposed set of 122 documents that specify stateful IPv6-only to IPv4-only translation 123 and replace NAT-PT [RFC2766] address the issues raised in [RFC4966]. 125 As a reminder, it is worth mentioning the analysis is limited in the 126 sense that hosts from IPv6 networks can initiate a communication to 127 IPv4 network/Internet, but not vice-versa. This corresponds to 128 Scenario 1 and Scenario 5 described in [RFC6144]. Hence, the 129 scenario of servers moving to IPv6 while clients remaining IPv4 130 remains unaddressed. Of course, IPv6 to IPv4 communications can also 131 be supported if static or explicit bindings (e.g., 132 [I-D.ietf-pcp-base]) are configured on the stateful NAT64. 134 Stateful 64, just like any other technique under development, has 135 some positives and some drawbacks. The ups and downs of the proposal 136 must be clearly understood while going forward with its future 137 development. 139 The scope of this document does not include stateless translation. 141 2. Analysis of 64 Translation Against Concerns of RFC4966 143 Of the set of problems pointed out in [RFC4966], the stateful 64 144 addresses some of them, whereas leaves others unaddressed. 146 Some issues mentioned in [RFC4966] were solved by [RFC4787], 147 [RFC5382] and [RFC5508]. At the time when NAT-PT was published these 148 recommendations were not in place but they are orthogonal to the 149 translation algorithm per se, therefore they could be implemented 150 with NAT-PT. On the other hand, NAT64 [RFC6146] explicitly mentions 151 that these recommendations need to be followed and thus should be 152 seen as a complete specification. 154 It is also worth pointing out that the scope of the stateful 64 is 155 reduced when compared to NAT-PT. Following is a point by point 156 analysis of the problems. This document classifies the issues listed 157 in [RFC4966] into three categories: 159 1. Problems impossible to solve. 161 2. Problems which can be solved. 163 3. Problems solved. 165 2.1. Problems Impossible to Solve 167 Problems discussed in [RFC4966], which are impossible to solve: 169 1. Inability to redirect traffic for protocols that lack de- 170 multiplexing capabilities or are not built on top of specific 171 transport-layer protocols for transport address translations 172 (Section 2.2 of [RFC4966]). 174 Analysis: This issue is not specific to 64 but to all NAT- 175 based solutions. 177 2. Loss of information due to incompatible semantics between IPv4 178 and IPv6 versions of headers and protocols (Section 2.4 of 179 [RFC4966]). 181 Analysis: This issue is not specific to 64 but due to the 182 design of IPv4 and IPv6. 184 3. Need for the NAT64-capable device to act as proxy for 185 correspondent node when IPv6 node is mobile, with consequent 186 restrictions on mobility (Section 2.7 of [RFC4966]). 188 Analysis: This is not specific to NAT64 but to all NAT 189 flavors. Refer to [I-D.haddad-mext-nat64-mobility-harmful] 190 for an early analysis on mobility complications encountered 191 when NAT64 is involved. 193 2.2. Problems Which Can be Solved 195 Problems discussed in [RFC4966], which can be solved: 197 1. Disruption of all protocols that embed IP addresses (and/or 198 ports) in packet payloads or apply integrity mechanisms using IP 199 addresses (and ports) (Section 2.1 of [RFC4966]). 201 Analysis: In the case of FTP [RFC0959] this problem can be 202 mitigated in several ways (e.g., use a FTP64 ALG [RFC6384] or 203 in the FTP client (e.g., [I-D.ietf-ftpext2-ftp64])). 205 In the case of SIP [RFC3261], no specific issue is induced by 206 64; the same techniques for NAT traversal can be used when a 207 NAT64 is involved in the path (e.g., ICE [RFC5245], maintain 208 SIP-related NAT bindings as per Section 3.4 of [RFC5853], 209 media latching [I-D.ietf-mmusic-media-path-middleboxes], 210 embedded SIP ALGs, etc.). [RFC6157] provides more discussion 211 on how to establish SIP sessions between IPv4 and IPv6 SIP 212 user agents. 214 The functioning of other protocols is left for future study. 215 Note that the traversal of NAT64 by application embedding IP 216 address literal is not specific to NAT64 but generic to all 217 NAT-based solutions. 219 2. Interaction with SCTP [RFC4960] and multihoming (Section 2.6 of 220 [RFC4966]). 222 Analysis: Only TCP and UDP transport protocols are within the 223 scope of NAT64 [RFC6146]. SCTP is out of scope of this 224 document. 226 3. Inability to handle multicast traffic (Section 2.8 of [RFC4966]). 228 Analysis: This problem is not addressed by the current 64 229 specifications. 231 4. Scalability concerns together with introduction of a single point 232 of failure and a security attack nexus (Section 3.2 of 233 [RFC4966]). 235 Analysis: This is not specific to NAT64 but to all stateful 236 NAT flavors. The presence of single point of failures is 237 deployment-specific; some service providers may deploy state 238 synchronization means while others may only rely on a 239 distributed NAT64 model. 241 5. Restricted validity of translated DNS records: a translated 242 record may be forwarded to an application that cannot use it 243 (Section 4.2 of [RFC4966]). 245 Analysis: If a node on the IPv4 side forwards the address of 246 the other endpoint to a node which cannot reach the NAT box or 247 is not covered under the endpoint-independent constraint of 248 NAT, then the new node will not be able to initiate a 249 successful session. 251 Actually, this is not a limitation of 64 (or even NAT-PT) but 252 a deployment context where IPv4 addresses managed by the NAT64 253 are not globally reachable. The same limitation can be 254 encountered when referrals (even without any NAT in the path) 255 include reachability information with limited reachability 256 scope (See [I-D.carpenter-behave-referral-object] for more 257 discussion about issues related to reachability scope). 259 6. IPsec traffic using AH (Authentication Header) [RFC4302] in both 260 transport and tunnel modes cannot be carried through NAT-PT 261 without terminating the security associations on the NAT-PT, due 262 to the inclusion of IP header fields in the scope of AH's 263 cryptographic integrity protection [RFC3715] (Section 2.1 of 264 [RFC4966]). In addition, IPsec traffic using ESP (Encapsulating 265 Security Payload) [RFC4303] in transport mode generally uses UDP 266 encapsulation [RFC3948] for NAT traversal (including NAT-PT 267 traversal) in order to avoid the problems described in [RFC3715] 268 (Section 2.1 of [RFC4966]). 270 Analysis: This is not specific to NAT64 but to all NAT 271 flavors. 273 7. Address selection issues when either the internal or external 274 hosts implement both IPv4 and IPv6 (Section 4.1 of [RFC4966]). 276 Analysis: This is out of scope of 64 since Scenarios 1 and 5 277 of [RFC6144] assume IPv6-only hosts. 279 Therefore this issue is not resolved and mitigation techniques 280 outside the 64 need to be used (e.g., 281 [I-D.ietf-6man-addr-select-opt]). These techniques may allow 282 to offload NAT64 resources and prefer native communications 283 which do not involve address family translation. Avoiding NAT 284 devices in the path is encouraged for mobile nodes in order to 285 save power consumption due to keepalive messages which are 286 required to maintain NAT states ("always-on" services). An 287 in-depth discussion can be found in 288 [I-D.wing-behave-dns64-config]. 290 2.3. Problems Solved 292 Problems, identified in [RFC4966], which are solved: 294 1. Constraints on network topology (as it relates to DNS-ALG; see 295 Section 3.1 of [RFC4966]). 297 Analysis: The severity of this issue has been mitigated by the 298 separation of the DNS from the NAT functionality. 299 Nevertheless, a minimal coordination may be required to ensure 300 that the NAT64 to be crossed (the one to which the IPv4- 301 Converted IPv6 address returned to a requesting host) must be 302 in the path and has also sufficient resources to handle 303 received traffic. 305 2. Need for additional state and/or packet reconstruction in dealing 306 with packet fragmentation. Otherwise, implement no support for 307 fragments. (Section 2.5 of [RFC4966]) 308 Analysis: This issue is not specific to 64 but to all NAT- 309 based solutions. [RFC6146] specifies how to handle 310 fragmentation; appropriate recommendations to avoid 311 fragmentation-related DoS attacks are proposed (e.g., limit 312 resources to be dedicated to out of order fragments). 314 3. Inappropriate translation of responses to A queries from IPv6 315 nodes (Section 4.3 of [RFC4966]). 317 Analysis: DNS64 [RFC6147] does not alter A queries. 319 4. Address selection issues and resource consumption in a DNS-ALG 320 with multi-addressed nodes (Section 4.4 of [RFC4966]). 322 Analysis: Since no DNS-ALG is required to be co-located with 323 NAT64, there is no need to maintain temporary states in 324 anticipation of connections. Note that explicit bindings (See 325 Section 3 of [I-D.ietf-pcp-base]) are required to allow for 326 communications initiated from an IPv4-only client to an IPv6- 327 only server. 329 5. Limitations on DNS security capabilities when using a DNS-ALG 330 (Section 2.5 of [RFC4966]). 332 Analysis: A DNSSEC validating stub resolver behind a DNS64 in 333 server mode is not supported. Therefore if a host wants to do 334 its own DNSSEC validation, and it wants to use a NAT64, the 335 host has to also perform its own DNS64 synthesis. Refer to 336 Section 3 of[RFC6147] for more details. 338 6. Creation of a Denial of Service (DoS) threat relating to 339 exhaustion of memory and address/port pool resources on the 340 translator (Section 3.4 of [RFC4966]). 342 Analysis: This specific DoS concern on Page 6 of [RFC4966] is 343 under a DNS-ALG heading in that document, and refers to NAT- 344 PT's creation of NAT mapping state when a DNS query occurred. 345 With the new IPv6-IPv4 translation mechanisms, DNS queries do 346 not create any mapping state in the NAT64. 348 To mitigate the exhaustion of port pool issue (Section 3.4 of 349 [RFC4966]), 64 must enforce a port limit similar to the one 350 defined in [I-D.ietf-behave-lsn-requirements]. 352 Thus, this concern can be fully eliminated in 64. 354 7. Requirement for applications to use keepalive mechanisms to 355 workaround connectivity issues caused by premature timeout for 356 session table and BIB entries (Section 2.3 of [RFC4966]). 358 Analysis: Since NAT64 follows some of the [RFC4787], [RFC5382] 359 and [RFC5508] requirements, there is a high lower bound for 360 the lifetime of sessions. In NAT-PT this was unknown and 361 applications needed to assume the worst case. For instance, 362 in NAT64, the lifetime for a TCP session is approximately 2 363 hours, so not much keep-alive signaling overhead is needed. 365 Application clients (e.g., VPN clients) are not aware of the 366 timer configured in the NAT device. For unmanaged services, a 367 conservative approach would be adopted by applications which 368 issue frequent keepalive messages to be sure that an active 369 mapping is still be maintained by any involved NAT64 device 370 even if the NAT64 complies with [RFC4787][RFC5382][RFC5508]. 372 Note that keepalive messages may be issued by applications to 373 ensure that an active entry is maintained by a firewall, with 374 or without a NAT in the path, which is located in the 375 boundaries of a local domain. 377 8. Lack of address mapping persistence: Some applications require 378 address retention between sessions. The user traffic will be 379 disrupted if a different mapping is used. The use of the DNS-ALG 380 to create address mappings with limited lifetimes means that 381 applications must start using the address shortly after the 382 mapping is created, as well as keep it alive once they start 383 using it. (Section 3.3 of [RFC4966]) 385 Analysis: In the following, address persistence is used to 386 refer to the support of "IP address pooling" behavior of 387 "Paired" [RFC4787]. 389 In the context of 64, the external IPv4 address (representing 390 the IPv6 host in the IPv4 network) is assigned by the NAT64 391 machinery and not the DNS64 function. Address persistence can 392 be therefore easily ensured by the NAT64 function (which 393 complies with NAT recommendations [RFC4787][RFC5382]). 394 Address persistence should be guaranteed for both dynamic and 395 static bindings. 397 In the IPv6 side of the NAT64, the same IPv6 address is used 398 to represent an IPv4 host; no issue about address persistence 399 is raised in IPv6 network. 401 3. Conclusions 403 The above analysis of the solutions provided by the stateful 64 shows 404 that the majority of the problems that are not directly related to 405 the decoupling of NAT and DNS remain unaddressed. Some of these 406 problems are not specific to 64 but are generic to all NAT-based 407 solutions. 409 This points to several shortcomings of stateful 64 which must be 410 addressed if the future network deployments have to move reliably 411 towards 64 as a solution to IPv6-IPv4 interconnection. 413 Some of the issues, as pointed out in [RFC4966], have possible 414 solutions. However these solutions will require significant updates 415 to the stateful 64, increasing its complexity. 417 The following table summarizes the conclusions based on the analysis 418 of stateful 64. 420 +---------------+----------+---------+----------+---------+---------+ 421 | Issue | NAT-PT | Exists | DNS ALG | Generic | Can be | 422 | | Specific | in | Specific | NAT | solved? | 423 | | | NAT64 | | | | 424 +---------------+----------+---------+----------+---------+---------+ 425 | Protocols | No | Yes | No | Yes | Yes | 426 | embedding | | | | | | 427 | addresses | | | | | | 428 +---------------+----------+---------+----------+---------+---------+ 429 | Protocols | No | Yes | No | Yes | No | 430 | without demux | | | | | | 431 | capability | | | | | | 432 +---------------+----------+---------+----------+---------+---------+ 433 | Binding state | No | Yes | No | Yes | Yes | 434 | decay | | | | | | 435 +---------------+----------+---------+----------+---------+---------+ 436 | Loss of | No | Yes | No | No | No | 437 | information | | | | | | 438 +---------------+----------+---------+----------+---------+---------+ 439 | Fragmentation | No | No | No | Yes | Yes | 440 +---------------+----------+---------+----------+---------+---------+ 441 | SCTP and | No | Yes | No | Yes | Yes | 442 | Multihoming | | | | | | 443 | interaction | | | | | | 444 +---------------+----------+---------+----------+---------+---------+ 445 | Proxy | No | Yes | No | No | No | 446 | correspondent | | | | | | 447 | node for | | | | | | 448 | MIPv6 | | | | | | 449 | Multicast | No | Yes | No | Yes | Yes | 450 +---------------+----------+---------+----------+---------+---------+ 451 | Topology | Yes | No | Yes | No | Yes | 452 | constraints | | | | | | 453 | with DNS-ALG | | | | | | 454 +---------------+----------+---------+----------+---------+---------+ 455 | Scale and | No | Yes | No | Yes | Yes | 456 | Single point | | | | | | 457 | of failure | | | | | | 458 +---------------+----------+---------+----------+---------+---------+ 459 | Lack of | No | Yes | No | Yes | Yes | 460 | address | | | | | | 461 | persistence | | | | | | 462 +---------------+----------+---------+----------+---------+---------+ 463 | DoS attacks | No | Yes | No | Yes | Yes | 464 +---------------+----------+---------+----------+---------+---------+ 465 | Address | Yes | No | Yes | No | Yes | 466 | selection | | | | | | 467 | issues with | | | | | | 468 | Dual stack | | | | | | 469 | hosts | | | | | | 470 +---------------+----------+---------+----------+---------+---------+ 471 | Non-global | Yes | No | Yes | No | Yes | 472 | validity of | | | | | | 473 | Translated RR | | | | | | 474 | records | | | | | | 475 +---------------+----------+---------+----------+---------+---------+ 476 | Incorrect | Yes | No | Yes | No | Yes | 477 | translation | | | | | | 478 | of A | | | | | | 479 | responses | | | | | | 480 +---------------+----------+---------+----------+---------+---------+ 481 | DNS-ALG and | No | Yes | No | Yes | Yes | 482 | Multi- | | | | | | 483 | addressed | | | | | | 484 | nodes | | | | | | 485 +---------------+----------+---------+----------+---------+---------+ 486 | DNSSEC | No | Yes | No | Yes | Yes | 487 | limitations | | | | | | 488 +---------------+----------+---------+----------+---------+---------+ 490 Table 1: Summary of NAT64 analysis 492 4. IANA Considerations 494 This document makes no request of IANA. 496 Note to RFC Editor: this section may be removed on publication as an 497 RFC. 499 5. Security Considerations 501 This document does not specify any new protocol or architecture. It 502 only analyzes how BEHAVE WG 64 documents mitigate concerns raised in 503 [RFC4966] and which ones are still unaddressed. 505 6. Acknowledgements 507 Many thanks to M. Bagnulo, D. Wing, X. Li, D. Anipko and S. Moonesamy 508 for their review and comments. 510 D. Black provided the IPsec text. 512 7. References 514 7.1. Normative References 516 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 517 STD 9, RFC 959, October 1985. 519 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 520 A., Peterson, J., Sparks, R., Handley, M., and E. 521 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 522 June 2002. 524 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 525 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 526 RFC 3948, January 2005. 528 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 529 December 2005. 531 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 532 RFC 4303, December 2005. 534 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 535 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 536 RFC 4787, January 2007. 538 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 539 RFC 4960, September 2007. 541 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 542 Address Translator - Protocol Translator (NAT-PT) to 543 Historic Status", RFC 4966, July 2007. 545 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 546 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 547 RFC 5382, October 2008. 549 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 550 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 551 April 2009. 553 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 554 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 555 October 2010. 557 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 558 IPv4/IPv6 Translation", RFC 6144, April 2011. 560 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 561 Algorithm", RFC 6145, April 2011. 563 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 564 NAT64: Network Address and Protocol Translation from IPv6 565 Clients to IPv4 Servers", RFC 6146, April 2011. 567 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 568 Beijnum, "DNS64: DNS Extensions for Network Address 569 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 570 April 2011. 572 7.2. Informative References 574 [I-D.carpenter-behave-referral-object] 575 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 576 K. Moore, "A Generic Referral Object for Internet 577 Entities", draft-carpenter-behave-referral-object-01 (work 578 in progress), October 2009. 580 [I-D.haddad-mext-nat64-mobility-harmful] 581 Haddad, W. and C. Perkins, "A Note on NAT64 Interaction 582 with Mobile IPv6", 583 draft-haddad-mext-nat64-mobility-harmful-02 (work in 584 progress), March 2011. 586 [I-D.ietf-6man-addr-select-opt] 587 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 588 "Distributing Address Selection Policy using DHCPv6", 589 draft-ietf-6man-addr-select-opt-03 (work in progress), 590 February 2012. 592 [I-D.ietf-behave-lsn-requirements] 593 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 594 and H. Ashida, "Common requirements for Carrier Grade NATs 595 (CGNs)", draft-ietf-behave-lsn-requirements-05 (work in 596 progress), November 2011. 598 [I-D.ietf-ftpext2-ftp64] 599 Liu, D., Beijnum, I., and Z. Cao, "FTP consideration for 600 IPv4/IPv6 transition", draft-ietf-ftpext2-ftp64-02 (work 601 in progress), January 2012. 603 [I-D.ietf-mmusic-media-path-middleboxes] 604 Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis 605 of Middlebox Interactions for Signaling Protocol 606 Communication along the Media Path", 607 draft-ietf-mmusic-media-path-middleboxes-04 (work in 608 progress), January 2012. 610 [I-D.ietf-pcp-base] 611 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 612 Selkirk, "Port Control Protocol (PCP)", 613 draft-ietf-pcp-base-23 (work in progress), February 2012. 615 [I-D.wing-behave-dns64-config] 616 Wing, D., "IPv6-only and Dual Stack Hosts on the Same 617 Network with DNS64", draft-wing-behave-dns64-config-03 618 (work in progress), February 2011. 620 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 621 Translation - Protocol Translation (NAT-PT)", RFC 2766, 622 February 2000. 624 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 625 (NAT) Compatibility Requirements", RFC 3715, March 2004. 627 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 628 (ICE): A Protocol for Network Address Translator (NAT) 629 Traversal for Offer/Answer Protocols", RFC 5245, 630 April 2010. 632 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 633 A., and M. Bhatia, "Requirements from Session Initiation 634 Protocol (SIP) Session Border Control (SBC) Deployments", 635 RFC 5853, April 2010. 637 [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 638 Transition in the Session Initiation Protocol (SIP)", 639 RFC 6157, April 2011. 641 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 642 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 644 Authors' Addresses 646 Reinaldo Penno 647 Juniper Networks 648 1194 N Mathilda Avenue 649 Sunnyvale, California 94089 650 USA 652 Email: rpenno@juniper.net 654 Tarun Saxena 655 Cisco Systems 657 Email: tasaxena@cisco.com 659 Mohamed Boucadair 660 France Telecom 661 Rennes 35000 662 France 664 Email: mohamed.boucadair@orange.com 666 Senthil Sivakumar 667 Cisco Systems 668 7100-8 Kit Creek Road 669 Research Triangle Park, North Carolina 27709 670 USA 672 Email: ssenthil@cisco.com