idnits 2.17.1 draft-penno-behave-64-analysis-06.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 (January 6, 2011) is 4856 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-02) exists of draft-haddad-mext-nat64-mobility-harmful-01 == Outdated reference: A later version (-12) exists of draft-ietf-behave-ftp64-06 == Outdated reference: A later version (-03) exists of draft-wing-behave-dns64-config-02 -- 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: 1 error (**), 0 flaws (~~), 4 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: July 10, 2011 M. Boucadair 7 France Telecom 8 S. Sivakumar 9 Cisco Systems 10 January 6, 2011 12 Analysis of 64 Translation 13 draft-penno-behave-64-analysis-06 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 evaluates 21 how the new translation mechanisms avoid the problems that caused the 22 IETF to deprecate NAT-PT. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 10, 2011. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Analysis of 64 Translation Against Concerns of RFC4966 . . . . 4 68 2.1. Problems Not Addressed by 64 . . . . . . . . . . . . . . . 4 69 2.2. Problems Addressed by 64 . . . . . . . . . . . . . . . . . 7 70 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 76 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 1.1. Definition 83 This document uses 64 proposal (or 64 for short) to refer to the 84 mechanisms defined in the following documents: 86 o Stateful NAT64: Network Address and Protocol Translation from IPv6 87 Clients to IPv4 Servers [I-D.ietf-behave-v6v4-xlate-stateful] 89 o DNS64: DNS extensions for Network Address Translation from IPv6 90 Clients to IPv4 Servers [I-D.ietf-behave-dns64] 92 o IPv6 Addressing of IPv4/IPv6 Translators [RFC6052] 94 o Framework for IPv4/IPv6 Translation 95 [I-D.ietf-behave-v6v4-framework] 97 1.2. Context 99 The current 64 proposal is widely seen as the next step in the 100 evolution of interconnection techniques enabling communications 101 between IPv6-only and IPv4-only networks. One of the building blocks 102 of this proposal is decoupling the DNS functionality from the 103 protocol translation itself. 105 This approach is pragmatic in the sense that there is no dependency 106 on DNS implementation for the successful NAT handling. As long as 107 there is a function (e.g., DNS64 [I-D.ietf-behave-dns64] or other 108 means) that can construct an IPv6-Embedded IPv4 address with a pre- 109 configured IPv6 prefix, an IPv4 address and a suffix (refer to 110 [RFC6052]), NAT64 will work just fine. 112 To understand the 64 proposal, we must keep in mind that the focus of 113 this proposal is on the deployment and not the implementation 114 details. As long as a NAT64 implementation conforms to the expected 115 behaviour, as desired in the deployment scenario, the details are not 116 very important as mentioned in this excerpt from 117 [I-D.ietf-behave-v6v4-xlate-stateful]: 119 "A NAT64 MAY perform the steps in a different order, or MAY 120 perform different steps, but the externally visible outcome MUST 121 be the same as the one described in this document." 123 1.3. Scope 125 This document provides an analysis of how the proposed set of 126 documents that specify stateful IPv6-only to IPv4-only translation 127 and replace NAT-PT [RFC2766] address the issues raised in [RFC4966]. 129 As a reminder, it is worth mentioning the 64 proposal analysis is 130 limited in the sense that hosts from IPv6 networks can initiate a 131 communication to IPv4 network/Internet, but not vice-versa. This 132 corresponds to Scenario 1 and Scenario 5 described in 133 [I-D.ietf-behave-v6v4-framework]. Hence, the scenario of servers 134 moving to IPv6 while clients remaining IPv4 remains unaddressed. Of 135 course, IPv6 to IPv4 communications can also be supported if static 136 bindings are configured on the stateful NAT64. 138 The 64 proposal, just like any other technique under development, has 139 some positives and some drawbacks. The ups and downs of the proposal 140 must be clearly understood while going forward with its future 141 development. 143 The scope of this document does not include stateless translation. 145 2. Analysis of 64 Translation Against Concerns of RFC4966 147 Of the set of problems pointed out in [RFC4966], the 64 proposal 148 addresses some of them, whereas leaves others unaddressed. 150 Some issues mentioned in [RFC4966] were solved by [RFC4787], 151 [RFC5382] and [RFC5508]. At the time when NAT-PT was published these 152 recommendations were not in place but they are orthogonal to the 153 translation algorithm per se, therefore they could be implemented 154 with NAT-PT. On the other hand, NAT64 explicitly mentions that these 155 recommendations need to be followed and thus should be seen as a 156 complete specification. 158 It is also worth pointing out that the scope of the 64 proposal is 159 reduced when compared to NAT-PT. Following is a point by point 160 analysis of the problems. 162 2.1. Problems Not Addressed by 64 164 Problems discussed in [RFC4966], which are not addressed by the 64 165 proposal: 167 1. Disruption of all protocols that embed IP addresses (and/or 168 ports) in packet payloads or apply integrity mechanisms using IP 169 addresses (and ports). 171 Analysis: In the case of FTP [RFC0959] this problem is 172 addressed by the use of a FTP64 ALG [I-D.ietf-behave-ftp64] 173 which is a workaround solution. In the case of SIP 174 [RFC3261], no specific issue is induced by 64; the same 175 techniques for NAT traversal can be used when a NAT64 is 176 involved in the path (e.g., ICE [RFC5245], Hosted NAT 177 Traversal [RFC5853], embedded SIP ALGs, etc. ). The 178 functioning of other protocols is left unaddressed. Note 179 that the traversal of NAT64 by application embedding IP 180 address literal is not specific to NAT64 but generic to all 181 NAT-based solutions. 183 2. Inability to redirect traffic for protocols that lack de- 184 multiplexing capabilities or are not built on top of specific 185 transport-layer protocols for transport address translations. 187 Analysis: This issue is not specific to 64 but to all NAT- 188 based solutions. 190 3. Loss of information due to incompatible semantics between IPv4 191 and IPv6 versions of headers and protocols. 193 Analysis: This issue is not specific to 64 but due to the 194 design of IPv4 and IPv6. 196 4. Need for additional state and/or packet reconstruction in 197 dealing with packet fragmentation. Otherwise, implement no 198 support for fragments. 200 Analysis: This issue is not specific to 64 but to all NAT- 201 based solutions. [I-D.ietf-behave-v6v4-xlate-stateful] 202 specifies how to handle fragmentation; appropriate 203 recommendations to avoid fragmentation-related DoS attacks 204 are proposed (e.g., limit resources to be dedicated to out of 205 order fragments). 207 5. Interaction with SCTP [RFC4960] and multihoming. 209 Analysis: SCTP is out of scope of 64. Only TCP and UDP 210 transport protocols are within the scope of 64. 212 6. Need for the NAT64-capable device to act as proxy for 213 correspondent node when IPv6 node is mobile, with consequent 214 restrictions on mobility. 216 Analysis: This is not specific to NAT64 but to all NAT 217 flavors. Refer to [I-D.haddad-mext-nat64-mobility-harmful] 218 for an early analysis on mobility complications encountered 219 when NAT64 is involved. 221 7. Inability to handle multicast traffic. 223 Analysis: This problem is not addressed by the current 64 224 specifications. 226 8. Scalability concerns together with introduction of a single 227 point of failure and a security attack nexus. 229 Analysis: This is not specific to NAT64 but to all stateful 230 NAT flavors. 232 9. Creation of a DoS (Denial of Service) threat relating to 233 exhaustion of memory and address/port pool resources on the 234 translator. 236 Analysis: This specific DoS concern on Page 6 of [RFC4966] is 237 under a DNS-ALG heading in that document, and refers to NAT- 238 PT's creation of NAT mapping state when a DNS query occurred. 239 With the new IPv6-IPv4 translation mechanisms, DNS queries do 240 not create any mapping state. Thus, this concern is fully 241 eliminated with the new IPv6-IPv4 translation mechanisms. 243 10. Restricted validity of translated DNS records: a translated 244 record may be forwarded to an application that cannot use it. 246 Analysis: If a node on the IPv4 side forwards the address of 247 the other endpoint to a node which cannot reach the NAT box 248 or is not covered under the endpoint-independent constraint 249 of NAT, then the new node will not be able to initiate a 250 successful session. 252 Actually, this is not a limitation of 64 (or even NAT-PT) but 253 a deployment context where shared IPv4 addresses managed by 254 the NAT64 are not globally reachable. The same limitation 255 can be encountered when referrals (even without any NAT in 256 the path) include reachability information with limited 257 reachability scope (See 258 [I-D.carpenter-behave-referral-object] for more discussion 259 about scope-related issues). 261 11. Unless UDP encapsulation is used for IPsec [RFC3948], traffic 262 using IPsec AH (Authentication Header), in transport and tunnel 263 mode, and IPsec ESP (Encapsulating Security Payload), in 264 transport mode, is unable to be carried through NAT-PT without 265 terminating the security associations on the NAT-PT, due to 266 their usage of cryptographic integrity protection. 268 Analysis: This is not specific to NAT64 but to all NAT 269 flavours. 271 12. Address selection issues when either the internal or external 272 hosts implement both IPv4 and IPv6. 274 Analysis: This is out of scope of 64 since Scenarios 1 and 5 275 of [I-D.ietf-behave-v6v4-framework] assume IPv6-only hosts. 277 Therefore this issue is not resolved and mitigation 278 techniques outside the 64 need to be used. These techniques 279 may allow to offload NAT64 resources and prefer native 280 communications which do not involve address family 281 translation. Avoiding NAT devices in the path is encouraged 282 for mobile nodes in order to save power consumption due to 283 keepalive messages which are required to maintain NAT states 284 ("always-on" services). An in-depth discussion can be found 285 in [I-D.wing-behave-dns64-config]. 287 2.2. Problems Addressed by 64 289 Problems, identified in [RFC4966], which are adequately addressed by 290 the 64 proposal: 292 1. Constraints on network topology (as it relates to DNS-ALG; see 293 Section 3.1 of [RFC4966]). 295 Analysis: This issue has mitigated severity as the DNS is 296 separated from the NAT functionality. Nevertheless, a minimal 297 coordination may be required to ensure that the NAT64 to be 298 crossed (the one to which the IPv4-Converted IPv6 address 299 returned to a requesting host) must be in the path and has 300 also sufficient resources to handle received traffic. 302 2. Inappropriate translation of responses to A queries from IPv6 303 nodes. 305 Analysis: DNS64 [I-D.ietf-behave-dns64] does not resolve A 306 queries. 308 3. Address selection issues and resource consumption in a DNS-ALG 309 with multi-addressed nodes. 311 Analysis: Since the DNS-ALG is not there and communications 312 initiated from the IPv4 side are not supported, there is no 313 need to maintain temporary states in anticipation of 314 connections. 316 4. Limitations on DNS security capabilities when using a DNS-ALG. 318 Analysis: A DNSSEC validating stub resolver behind a DNS64 in 319 server mode is not supported. Therefore if a host wants to do 320 its own DNSSEC validation, and it wants to use a NAT64, the 321 host has to also perform its own DNS64 synthesis. Refer to 322 Section 3 of[I-D.ietf-behave-dns64] for more details. 324 5. Creation of a DoS (Denial of Service) threat relating to 325 exhaustion of memory and address/port pool resources on the 326 translator. 328 Analysis: This specific DoS concern on Page 6 of [RFC4966] is 329 under a DNS-ALG heading in that document, and refers to NAT- 330 PT's creation of NAT mapping state when a DNS query occurred. 331 With the new IPv6-IPv4 translation mechanisms, DNS queries do 332 not create any mapping state in the NAT64. Thus, this concern 333 is fully eliminated in 64. 335 6. Requirement for applications to use keepalive mechanisms to 336 workaround connectivity issues caused by premature timeout for 337 session table and BIB entries. 339 Analysis: Since NAT64 follows some of the [RFC4787], [RFC5382] 340 and [RFC5508] requirements, there is a high lower bound for 341 the lifetime of sessions. In NAT-PT this was unknown and 342 applications needed to assume the worst case. For instance, 343 in NAT64, the lifetime for a TCP session is approximately 2 344 hours, so not much keep-alive signalling overhead is needed. 346 Application clients (e.g., VPN clients) are not aware of the 347 timer configured in the NAT device. For unmanaged services, a 348 conservative approach would be adopted by applications which 349 issue frequent keepalive messages to be sure that an active 350 mapping is still be maintained by any involved NAT64 device 351 even if the NAT64 complies with TCP/UDP/ICMP BEHAVE WG 352 specifications. 354 Note that keepalive messages may be issued by applications to 355 ensure that an active entry is maintained by a firewall, with 356 or without a NAT in the path, which is located in the 357 boundaries of a local domain. 359 7. Lack of address mapping persistence: Some applications require 360 address retention between sessions. The user traffic will be 361 disrupted if a different mapping is used. The use of the DNS- 362 ALG to create address mappings with limited lifetimes means that 363 applications must start using the address shortly after the 364 mapping is created, as well as keep it alive once they start 365 using it. 367 Analysis: In the context of 64, the external IPv4 address 368 (representing the IPv6 host in the IPv4 network) is assigned 369 by the NAT64 machinery and not the DNS64 function. Address 370 persistence can be therefore easily ensured by the NAT64 371 function (which complies with BEHAVE NAT recommendations). 372 Address persistence should be guaranteed for both dynamic and 373 static bindings. 375 In the IPv6 side of the NAT64, the same IPv6 address is used 376 to represent an IPv4 host; no issue about address persistence 377 is raised in IPv6 network. 379 3. Conclusions 381 The above analysis of the solutions provided by the 64 proposal shows 382 that the majority of the problems that are not directly related to 383 the decoupling of NAT and DNS remain unaddressed. Some of these 384 problems are not specific to 64 but are generic to all NAT-based 385 solutions. 387 This points to several shortcomings of 64 proposal which must be 388 addressed if the future network deployments have to move reliably 389 towards 64 as a solution to IPv6-IPv4 interconnection. 391 Some of the issues, as pointed out in [RFC4966], have possible 392 solutions. However these solutions will require significant updates 393 to the 64 proposal, increasing its complexity. 395 The following table summarizes the conclusions based on the analysis 396 of 64 proposal. 398 +---------------+----------+---------+----------+---------+---------+ 399 | Issue | NAT-PT | Exists | DNS ALG | Generic | Can be | 400 | | Specific | in | Specific | NAT | solved? | 401 | | | NAT64 | | | | 402 +---------------+----------+---------+----------+---------+---------+ 403 | Protocols | No | Yes | No | Yes | Yes | 404 | embedding | | | | | | 405 | addresses | | | | | | 406 +---------------+----------+---------+----------+---------+---------+ 407 | Protocols | No | Yes | No | Yes | No | 408 | without demux | | | | | | 409 | capability | | | | | | 410 +---------------+----------+---------+----------+---------+---------+ 411 | Binding state | No | Yes | No | Yes | No | 412 | decay | | | | | | 413 +---------------+----------+---------+----------+---------+---------+ 414 | Loss of | No | Yes | No | No | No | 415 | information | | | | | | 416 +---------------+----------+---------+----------+---------+---------+ 417 | Fragmentation | No | No | No | Yes | Yes | 418 +---------------+----------+---------+----------+---------+---------+ 419 | SCTP and | No | Yes | No | Yes | Yes | 420 | Multihoming | | | | | | 421 | interaction | | | | | | 422 +---------------+----------+---------+----------+---------+---------+ 423 | Proxy corresp | Yes | Yes | No | Yes | ?? | 424 | node for | | | | | | 425 | MIPv6 | | | | | | 426 +---------------+----------+---------+----------+---------+---------+ 427 | Multicast | No | Yes | No | Yes | Yes | 428 +---------------+----------+---------+----------+---------+---------+ 429 | Topology | Yes | No | Yes | No | Yes | 430 | constraints | | | | | | 431 | with DNS-ALG | | | | | | 432 +---------------+----------+---------+----------+---------+---------+ 433 | Scale and | No | Yes | No | Yes | Yes | 434 | Single point | | | | | | 435 | of failure | | | | | | 436 +---------------+----------+---------+----------+---------+---------+ 437 | Lack of | No | Yes | No | Yes | No | 438 | address | | | | | | 439 | persistence | | | | | | 440 +---------------+----------+---------+----------+---------+---------+ 441 | DoS attacks | No | Yes | No | Yes | Yes | 442 +---------------+----------+---------+----------+---------+---------+ 443 +---------------+----------+---------+----------+---------+---------+ 444 | Address | Yes | No | Yes | No | Yes | 445 | selection | | | | | | 446 | issues with | | | | | | 447 | Dual stack | | | | | | 448 | hosts | | | | | | 449 +---------------+----------+---------+----------+---------+---------+ 450 | Non-global | Yes | No | Yes | Yes | Yes | 451 | validity of | | | | | | 452 | Translated RR | | | | | | 453 | records | | | | | | 454 +---------------+----------+---------+----------+---------+---------+ 455 | Incorrect | Yes | No | Yes | No | Yes | 456 | translation | | | | | | 457 | of A | | | | | | 458 | responses | | | | | | 459 +---------------+----------+---------+----------+---------+---------+ 460 | DNS-ALG and | No | Yes | No | Yes | Yes | 461 | Multi- | | | | | | 462 | addressed | | | | | | 463 | nodes | | | | | | 464 +---------------+----------+---------+----------+---------+---------+ 465 | DNSSEC | No | Yes | No | Yes | Yes | 466 | limitations | | | | | | 467 +---------------+----------+---------+----------+---------+---------+ 469 Table 1: Summary of NAT64 analysis 471 4. IANA Considerations 473 This document makes no request of IANA. 475 Note to RFC Editor: this section may be removed on publication as an 476 RFC. 478 5. Security Considerations 480 This document does not specify any new protocol or architecture. It 481 only analyses how BEHAVE WG 64 documents mitigate concerns raised in 482 [RFC4966] and which ones are still unaddressed. 484 6. Acknowledgements 486 Many thanks to Marcelo Bagnulo for his comments. 488 7. References 490 7.1. Normative References 492 [I-D.ietf-behave-dns64] 493 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 494 "DNS64: DNS extensions for Network Address Translation 495 from IPv6 Clients to IPv4 Servers", 496 draft-ietf-behave-dns64-11 (work in progress), 497 October 2010. 499 [I-D.ietf-behave-v6v4-xlate-stateful] 500 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 501 NAT64: Network Address and Protocol Translation from IPv6 502 Clients to IPv4 Servers", 503 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 504 progress), July 2010. 506 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 507 STD 9, RFC 959, October 1985. 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, March 1997. 512 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 513 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 514 RFC 4787, January 2007. 516 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 517 RFC 4960, September 2007. 519 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 520 Address Translator - Protocol Translator (NAT-PT) to 521 Historic Status", RFC 4966, July 2007. 523 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 524 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 525 RFC 5382, October 2008. 527 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 528 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 529 April 2009. 531 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 532 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 533 October 2010. 535 7.2. Informative References 537 [I-D.carpenter-behave-referral-object] 538 Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and 539 K. Moore, "A Generic Referral Object for Internet 540 Entities", draft-carpenter-behave-referral-object-01 (work 541 in progress), October 2009. 543 [I-D.haddad-mext-nat64-mobility-harmful] 544 Haddad, W. and C. Perkins, "A Note on NAT64 Interaction 545 with Mobile IPv6", 546 draft-haddad-mext-nat64-mobility-harmful-01 (work in 547 progress), April 2010. 549 [I-D.ietf-behave-ftp64] 550 Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", 551 draft-ietf-behave-ftp64-06 (work in progress), 552 November 2010. 554 [I-D.ietf-behave-v6v4-framework] 555 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 556 IPv4/IPv6 Translation", 557 draft-ietf-behave-v6v4-framework-10 (work in progress), 558 August 2010. 560 [I-D.wing-behave-dns64-config] 561 Wing, D., "DNS64 Resolvers and Dual-Stack Hosts", 562 draft-wing-behave-dns64-config-02 (work in progress), 563 February 2010. 565 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 566 Translation - Protocol Translation (NAT-PT)", RFC 2766, 567 February 2000. 569 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 570 A., Peterson, J., Sparks, R., Handley, M., and E. 571 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 572 June 2002. 574 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 575 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 576 RFC 3948, January 2005. 578 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 579 (ICE): A Protocol for Network Address Translator (NAT) 580 Traversal for Offer/Answer Protocols", RFC 5245, 581 April 2010. 583 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 584 A., and M. Bhatia, "Requirements from Session Initiation 585 Protocol (SIP) Session Border Control (SBC) Deployments", 586 RFC 5853, April 2010. 588 Authors' Addresses 590 Reinaldo Penno 591 Juniper Networks 592 1194 N Mathilda Avenue 593 Sunnyvale, California 94089 594 USA 596 Email: rpenno@juniper.net 598 Tarun Saxena 599 Cisco Systems 601 Email: tasaxena@cisco.com 603 Mohamed Boucadair 604 France Telecom 605 Rennes 35000 606 France 608 Email: mohamed.boucadair@orange-ftgroup.com 610 Senthil Sivakumar 611 Cisco Systems 612 7100-8 Kit Creek Road 613 Research Triangle Park, North Carolina 27709 614 USA 616 Email: ssenthil@cisco.com