idnits 2.17.1 draft-wing-behave-v4app-v6server-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 863 has weird spacing: '...ication along...' -- The document date (February 24, 2010) is 5174 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-huang-behave-rfc2767bis-01 == Outdated reference: A later version (-02) exists of draft-huang-behave-rfc3338bis-01 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-08 == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-media-path-middleboxes-02 == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-22 == Outdated reference: A later version (-22) exists of draft-ietf-mmusic-rtsp-nat-09 == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-rtsp-nat-evaluation-02 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-03 == Outdated reference: A later version (-08) exists of draft-saito-mmusic-sdp-ike-06 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-05 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group D. Wing 3 Internet-Draft Cisco 4 Intended status: Informational C. Byrne 5 Expires: August 28, 2010 T-Mobile USA 6 February 24, 2010 8 Concerns with IPv4 Applications Accessing IPv6 Servers (NAT46) 9 draft-wing-behave-v4app-v6server-02 11 Abstract 13 Bump-in-the-Stack and Bump-in-the-API allow IPv4 applications to 14 access IPv6 servers, using an in-host NAT46 translator. When used in 15 conjunction with an in-network NAT64, it is also possible for the 16 IPv4 application to access an IPv4 server via an IPv6-only network. 17 This document describes how these functions work in detail, and 18 discusses some concerns especially around IPv4 applications accessing 19 IPv6 servers. These concerns can be reduced by not having IPv4 20 applications access IPv6 servers. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 28, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. PNAT Walk-Through . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1.1. Outgoing Connection: FTP Passive Mode . . . . . . . . 4 66 2.1.2. Incoming connection: FTP Active Mode . . . . . . . . . 7 67 2.2. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 2.2.1. IPv4 Client to IPv4 Server (peer to peer) . . . . . . 11 69 2.2.2. IPv4 client to IPv4 Server (client/server) . . . . . . 12 70 2.2.3. IPv4 Client to IPv6 Server . . . . . . . . . . . . . . 12 71 2.3. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 2.4. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 2.5. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 2.6. email protocols (SMTP, IMAP, POP) . . . . . . . . . . . . 14 75 2.7. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 3. Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 3.1. Interference with IPv6 Deployment . . . . . . . . . . . . 15 78 3.2. Troubleshooting . . . . . . . . . . . . . . . . . . . . . 15 79 3.3. Application Layer Gateways . . . . . . . . . . . . . . . . 16 80 3.3.1. Standardization . . . . . . . . . . . . . . . . . . . 16 81 3.3.2. Interference with Application Evolution . . . . . . . 16 82 3.3.3. Encrypted Application Signaling . . . . . . . . . . . 17 83 3.3.4. ALG interference with IPv6-aware applications . . . . 17 84 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 17 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 91 Appendix A. To Do . . . . . . . . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 96 As IPv6 is introduced to networks it is desirable that existing IPv4 97 applications continue to function across native IPv6-only networks. 98 However, due to exhaustion of IPv4 address space, it is not possible 99 to provide a publicly-routable IPv4 address to every host. Thus, 100 some form of IPv4 address multiplexing is necessary. There are 101 several proposals to accomplish this multiplexing in combination with 102 IPv6 ([I-D.ietf-softwire-dual-stack-lite], [I-D.ymbk-aplusp], 103 [I-D.boucadair-port-range]). All of these proposals expect the 104 applications and host to use IPv4 to communicate with other IPv4 105 hosts and to use IPv6 to communicate with other IPv6 hosts. With 106 these techniques, the host sends and receives IPv4 packets and IPv6 107 packets on the wire, which are tunneled by some of the techniques. 109 Two approaches have been proposed which perform IPv4 to IPv6 110 translation. Both approaches have similar needs for ALG assistance 111 to support protocols which contain IP addresses in their payloads 112 (e.g., FTP, SIP, XMPP). One approach does translation in the host 113 [I-D.huang-behave-pnat] by extending existing in-host translation 114 Bump-in-the-API ("BIA", [I-D.huang-behave-rfc3338bis]) or Bump-in- 115 the-Stack ("BIS", [I-D.huang-behave-rfc2767bis]), and uses an in- 116 network stateful NAT64 access IPv4 servers. The other approach, 117 Virtual IPv6 Connectivity [I-D.vogt-durand-virtual-ip6-connectivity], 118 does DNS manipulation and translation in a CPE device, external from 119 the IPv4 host. Virtual IPv6 Connectivity is not studied in detail in 120 this document. 122 PNAT provides two features for IPv4 applications, which are analyzed 123 in detail in the sections below: 125 o access IPv4 servers over an IPv6-only access network. This 126 achieves the same end result as the dual-stack approaches listed 127 in the previous paragraph. PNAT provides this function by doing 128 NAT464. NAT464 is realized by a combination of NAT46 in the host 129 (achieved by extensions to BIA/BIS) and an in-network stateful 130 NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] to translate the IPv6 131 packets back to IPv4 packets. 133 o access IPv6 servers (or dual-stack servers) over an IPv6-only 134 access network. This is realized by a NAT46 function in the host 135 (achieved by extensions to BIA/BIS). The NAT46 function provides 136 a unique advantage, in that IPv4 applications are immediately able 137 to connect to IPv6 servers. However, it also raises some concerns 138 described below. 140 2. PNAT Walk-Through 142 2.1. FTP 144 This section details the operation of PNAT, using an IPv4-only FTP 145 client application. PNAT is a system that combines extensions to 146 BIA/BIS in the host and (when necessary to access an IPv4 server) an 147 in-network stateful NAT64. 149 In some of the following scenarios, the BIA/BIS function in the host 150 needs to create artificial IPv4 addresses in order to access IPv6 151 servers. These IPv4 addresses are never exposed outside of the host. 152 To clarify the examples, this document assumes the network 153 10.127.0.0/16 is used for these artificial IPv4 addresses. 155 These walk-throughs detail how outgoing and incoming connections are 156 handled with BIA/BIS when IP addresses are contained in application 157 payloads. FTP is a simple, well-understood protocol which supports 158 both outgoing data connections (passive mode) and incoming data 159 connections (active mode), both of which require communicating IP 160 addresses and TCP ports in the application payload. FTP is a good 161 example because its data connection can be outgoing (from the client) 162 or incoming (to the client), and FTP is sensitive to the IP address 163 family (PASV is needed with IPv4; EPSV with IPv6). The servers can 164 be in another host ("peer to peer"), inside the operator's network, 165 or on the Internet. 167 The following table summarizes the notes in the subsequent sections: 169 +-----------+------------+---------+-------------+----------------+ 170 | Direction | Server | result | in-host ALG | in-network ALG | 171 +-----------+------------+---------+-------------+----------------+ 172 | Outgoing | IPv4 | succeed | no | no | 173 | Outgoing | IPv6 | fail | no | no | 174 | Outgoing | dual-stack | fail | no | no | 175 | Incoming | IPv4 | succeed | required | required | 176 | Incoming | IPv6 | succeed | required | no | 177 | Incoming | dual-stack | succeed | required | no | 178 +-----------+------------+---------+-------------+----------------+ 180 Table 1: Summary of PNAT Walk-Through 182 2.1.1. Outgoing Connection: FTP Passive Mode 184 This demonstrates how an outgoing connection is performed with BIA/ 185 BIS with an application containing an IP address in the application 186 payload. 188 Passive mode FTP causes the FTP data connection to be initiated by 189 the FTP client. Passive mode FTP is necessary to operate behind NATs 190 (or firewalls) that lack an FTP-aware ALG in the NAT (or firewall). 191 FTP passive mode is the default for many standalone FTP clients 192 (e.g., WS_FTP Pro) and all major web browsers (e.g., Internet 193 Explorer, Firefox, Safari, Opera). 195 2.1.1.1. IPv4 Application to IPv4 Server (NAT464) 197 An IPv4-only FTP application wants to connect to an FTP server at 198 ftp.example.com, which has the IPv4 address 192.0.2.1 and an A 199 record, and no IPv6 address and no AAAA record. 201 +-----------------+ +---------+ 202 |IPv4 FTP +------| < IPv6 > +-----+- < IPv4 > |IPv4 FTP | 203 | client | HBT +---|NAT64| ---+ server | 204 | using | | +-----+ +---------+ 205 | PASV | | 206 +----------+------+ 208 Figure 1: FTP, IPv4 client to IPv4 server (FTP passive mode) 210 The IPv4 FTP application does a gethostaddr() call for 211 ftp.example.com. This is intercepted by the BIA/BIS in the host, and 212 converted to an AAAA query and sent to the DNS server and receives 213 'no such host' as the response. This causes the BIA/BIS in the host 214 to send an A query to the DNS server and receive 192.0.2.1 as the 215 response. This address is returned to the application's 216 gethostaddr() call. The FTP application then opens a TCP connection 217 to 192.0.2.1, which is intercepted by BIA/BIS in the host which adds 218 the necessary IPv6 prefix for the in-network NAT64 device, and sends 219 the IPv6 packet towards that address. The in-network NAT64 220 translates the packet to IPv4 and sends it to 192.0.2.1. The TCP 221 connection is established and the FTP client logs into the FTP 222 server. After login, the FTP client sends the PASV command prior to 223 its data transfer command. The IPv4 FTP server responds to the PASV 224 command with its IPv4 address and the TCP port for the incoming data 225 connection. The FTP client connects to that IPv4 address and port, 226 which is intercepted by BIA/BIS in the host which adds the necessary 227 IPv6 prefix for the in-network NAT64 device, and sends the IPv6 228 packet towards that address. The in-network NAT64 translates the 229 packet to IPv4 and sends it to the FTP server. 231 Notes: 233 o This scenario is transparent to the application. 235 o No Application-Layer Gateway (ALG) is needed. 237 o A requirement is that both the FTP control channel and the FTP 238 data channel use the same NAT64, so that the IPv4 FTP server sees 239 both connections coming from the same IPv4 address. This is 240 trivially accomplished, as the IPv6 prefix -- which selects the 241 NAT64 for this host -- is implemented inside the host's BIA/BIS 242 function. 244 o The BIA/BIS function creates no additional state in the host for 245 any of the IPv4/IPv6 mappings; the mappings are entirely 246 algorithmic. Also note that a DNS query is not required for the 247 BIA/BIS function to work. 249 2.1.1.2. IPv4 Application to IPv6 Server (NAT46) 251 An IPv4-only FTP application wants to connect to an FTP server at 252 ftp.example.com, which has the IPv6 address 2001:DB8::1 and an AAAA 253 record, and no IPv4 address and no A record. 255 +-----------------+ +---------+ 256 |IPv4 FTP +------| < IPv6 > |IPv6 FTP | 257 | client | HBT +---| server | 258 | using |w/FTP | +---------+ 259 | PASV | ALG | 260 +----------+------+ 262 Figure 2: FTP, IPv4 client to IPv6-only server (FTP passive mode) 264 The IPv4 FTP application does a gethostaddr() call for 265 ftp.example.com. This is intercepted by the BIA/BIS in the host, and 266 converted to an AAAA query and sent to the DNS server and receives 267 2001:DB8::1 as the response. The BIA/BIS in the host creates an 268 artificial IPv4 address, 10.127.0.1, and a mapping between that 269 artificial address and the IPv6 address. The artificial address 270 10.127.0.1 is returned to the application's gethostaddr() call. The 271 FTP application then opens a TCP connection to 10.127.0.1, which is 272 intercepted by BIA/BIS in the host and maps this to the IPv6 address 273 2001:DB8::1 and sends the IPv6 packet towards that address. The TCP 274 connection is established and the FTP client logs into the FTP 275 server. After login, the FTP client sends the PASV command prior to 276 its data transfer command. The IPv6 FTP server cannot send a useful 277 response to the PASV command, because the PASV response can only 278 indicate an IPv4 address. 280 Notes: 282 o Not transparent to application. 284 o This scenario needs an FTP ALG in the host 286 o There is no in-network translation, and there is no need for in- 287 network ALG. 289 o The BIA/BIS function creates additional state in the host for the 290 IPv4/IPv6 mappings. 292 2.1.1.3. IPv4 Application to Dual-Stack Server (NAT46) 294 An IPv4-only FTP application wants to connect to an FTP server at 295 ftp.example.com, which has the IPv4 address 192.0.2.1 and A record, 296 and the IPv6 address 2001:DB8::1 and AAAA record. 298 +-----------------+ +--------------+ 299 |IPv4 FTP +------| < IPv6 > |dual-stack FTP| 300 | client | HBT +---| server | 301 | using |w/FTP | +--------------+ 302 | PASV | ALG | 303 +----------+------+ 305 Figure 3: FTP, IPv4 client to dual-stack server (FTP passive mode) 307 The IPv4 FTP application does a gethostaddr() call for 308 ftp.example.com. This is intercepted by the BIA/BIS in the host, and 309 converted to an AAAA query and sent to the DNS server and receives 310 2001:DB8::1 as the response. From this point forward, the behavior 311 is exactly the same as the previous section, Section 2.1.1.2, and has 312 the same requirement for an in-host FTP ALG. 314 Notes: 316 o The same Notes from Section 2.1.1.2, above, apply to this 317 scenario. 319 o This walk-through assumes the application and the host stack both 320 prefer IPv6 over IPv4, which is the default ([RFC3484]). 322 2.1.2. Incoming connection: FTP Active Mode 324 This demonstrates how an incoming connection is performed with BIA/ 325 BIS with an application containing an IP address in the application 326 payload. 328 Active mode FTP is the 'normal' mechanism popular before the 329 widespread deployment of IPv4 NATs and firewalls. In this mode, the 330 data connection is initiated from the FTP server back to the FTP 331 client. For this to work when the client is behind a typical IPv4 332 NAT (NAT44) or a typical firewall, the NAT (or firewall) needs to 333 implement an FTP-aware ALG, so that when the FTP client sends its 334 PORT command (containing the FTP client's TCP port), the ALG can 335 perform the necessary functions. If a NAT, the necessary ALG 336 functions are to map the internal TCP port to an external TCP port 337 and rewrite the FTP command to contain the that newly-mapped port. 338 If a firewall ALG, the necessary ALG function is to create a 339 temporary permission for the incoming TCP connection. 341 2.1.2.1. IPv4 Application to IPv4 Server (NAT464) 343 An IPv4-only FTP application wants to connect to an FTP server at 344 ftp.example.com, which has the IPv4 address 192.0.2.1 and an A 345 record, and no IPv6 address and no AAAA record. 347 +-----------------+ +---------+ 348 |IPv4 FTP +------| < IPv6 > +-----+- < IPv4 > |IPv4 FTP | 349 | client | HBT +---|NAT64| ---+ server | 350 | using | | +-----+ +---------+ 351 | PASV | | 352 +----------+------+ 354 Figure 4: FTP, IPv4 client to IPv4 server (FTP active mode) 356 The IPv4 FTP application does a gethostaddr() call for 357 ftp.example.com. This is intercepted by the BIA/BIS in the host, and 358 converted to an AAAA query and sent to the DNS server and receives 359 'no such host' as the response. This causes the BIA/BIS in the host 360 to send an A query to the DNS server and receive 192.0.2.1 as the 361 response. This address is returned to the application's 362 gethostaddr() call. The FTP application then opens a TCP connection 363 to 192.0.2.1, which is intercepted by BIA/BIS in the host which 364 notices the TCP connection is to the FTP control port (TCP port 21) 365 and activates its FTP-aware ALG function. The BIA/BIS in the host 366 adds the necessary IPv6 prefix for the in-network NAT64 device, and 367 sends the IPv6 packet towards that address. The FTP ALG in the in- 368 network NAT64 notices the packet is to the FTP control port (TCP port 369 21) and activates its FTP ALG function. The in-network NAT64 370 translates the packet to IPv4 and sends it to 192.0.2.1. The TCP 371 connection is established with the FTP server and the FTP client logs 372 into the FTP server. After login, the FTP client wants to accept an 373 incoming connection for a data transfer. It begins listening on a 374 TCP port, and sends the PORT command which indicates its own IPv4 375 address and the TCP port it is listening on. The FTP-aware ALG in 376 the host modifies the FTP control packet to contain the host's IPv6 377 address, and sends it. The FTP-aware ALG in the in-network NAT64 378 sees the PORT command and creates a mapping from a public TCP port to 379 the IPv6 address and TCP port, and modifies the FTP control packet to 380 contain the public IPv4 address of the NAT64 and that newly-mapped 381 TCP port, and sends it to the FTP server. The FTP server initiates a 382 TCP connection to the listening port and the data transfer is 383 successful. 385 Notes: 387 o As with NAT44, this requires an Application Layer Gateway. 389 o Two Application Layer Gateways are necessary - one in the host (to 390 modify the FTP command from containing IPv4 to containing IPv6) 391 and another in the in-network NAT64 (to create the necessary TCP 392 mapping on the NAT64, and to modify the FTP command to contain the 393 NAT64's public IPv4 address and that newly-mapped TCP port).s 395 o A requirement is that both the FTP control channel and the FTP 396 data channel use the same NAT64, so that the IPv4 FTP server sees 397 both connections coming from the same IPv4 address. This is 398 trivially accomplished, as the IPv6 prefix -- which selects the 399 NAT64 for this host -- is implemented inside the host's BIA/BIS 400 function. 402 o The BIA/BIS function creates no additional state in the host for 403 any of the IPv4/IPv6 mappings; the mappings are entirely 404 algorithmic. Also note that a DNS query is not required for the 405 BIA/BIS function to work. 407 2.1.2.2. IPv4 Application to IPv6-only Server (NAT46) 409 An IPv4-only FTP application wants to connect to an FTP server at 410 ftp.example.com, which has the IPv6 address 2001:DB8::1 and an AAAA 411 record. It has no IPv4 address and no A record. 413 +-----------------+ +---------+ 414 |IPv4 FTP +------| < IPv6 > |IPv6 FTP | 415 | client | HBT +---| server | 416 | using |w/FTP | +---------+ 417 | PASV | ALG | 418 +----------+------+ 420 Figure 5: FTP, IPv4 client to IPv6-only server (FTP active mode) 422 The IPv4 FTP application does a gethostaddr() call for 423 ftp.example.com. This is intercepted by the BIA/BIS in the host, and 424 converted to an AAAA query and sent to the DNS server and receives 425 2001:DB8::1 as the response. The BIA/BIS in the host creates an 426 artificial IPv4 address, 10.127.0.1, and a mapping between that 427 artificial address and the IPv6 address. The artificial address 428 10.127.0.1 is returned to the application's gethostaddr() call. The 429 FTP application then opens a TCP connection to 10.127.0.1 which is 430 intercepted by BIA/BIS in the host which notices the TCP connection 431 is to the FTP control port (TCP port 21) and activates its FTP-aware 432 ALG function. The BIA/BIS in the host maps the TCP connection to 433 2001:DB8::1 and sends the IPv6 packet towards this address. The TCP 434 connection is established and the FTP client logs into the FTP 435 server. After login, the FTP client wants to accept an incoming 436 connection for a data transfer. It begins listening on a TCP port, 437 and sends the PORT command which indicates its own IPv4 address and 438 the TCP port it is listening on. The FTP-aware ALG in the host 439 intercepts this information, and changes the PORT command to EPRT 440 [RFC2428] containing the host's IPv6 address and the listening TCP 441 port, and sends it to 2001:DB8::1. The FTP server initiates a TCP 442 connection to the listening port and the data transfer is successful. 444 Notes: 446 o As with NAT44, this requires an Application Layer Gateway (ALG). 448 o One ALG is necessary in the host. 450 2.1.2.3. IPv4 Application to Dual-Stack Server (NAT46) 452 An IPv4-only FTP application wants to connect to an FTP server at 453 ftp.example.com, which has the IPv4 address 192.0.2.1 an A record, 454 and the IPv6 address 2001:DB8::1 and AAAA record. 456 +-----------------+ +--------------+ 457 |IPv4 FTP +------| < IPv6 > |dual-stack FTP| 458 | client | HBT +---| server | 459 | using |w/FTP | +--------------+ 460 | PASV | ALG | 461 +----------+------+ 463 Figure 6: FTP, IPv4 client to dual-stack server (FTP active mode) 465 The IPv4 FTP application does a gethostaddr() call for 466 ftp.example.com. This is intercepted by the BIA/BIS in the host, and 467 converted to an AAAA query and sent to the DNS server and receives 468 2001:DB8::1 as the response. From this point forward, the behavior 469 is exactly the same as the previous section, Section 2.1.2.2, and 470 also succeeds. 472 Notes: 474 o The same Notes from Section 2.1.1.2 apply to this scenario. 476 o This walk-through assumes the application and the host stack both 477 prefer IPv6 over IPv4, which is the default ([RFC3484]). 479 2.2. RTSP 481 Real Time Streaming Protocol (RTSP [RFC2326]) is most commonly used 482 to stream unicast or multicast RTP media from a server to a client. 483 RTSP encodes information about the media stream into SDP such as the 484 codec, and information about IP address and port of the media stream 485 into RTSP's transport headers. Many existing ALGs, shipping in NATs 486 today, modify these payloads. 488 However, RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] includes NAT traversal 489 built into the RTSP client and RTSP server itself 490 [I-D.ietf-mmusic-rtsp-nat] which uses a technique derived from ICE 491 [I-D.ietf-mmusic-ice]. An ALG that mistakenly interferes with these 492 components of RTSP signaling will cause failure of the RTSP setup, as 493 discussed in Section 4.1.5 of [I-D.ietf-mmusic-rtsp-nat-evaluation] 494 but the mitigation suggested in that document (encrypting RTSP 495 signaling) also means both in-host and in-network RTSP ALGs cannot be 496 used, as discussed in Section 3.3.3. The general concern of ALG 497 interference with application evolution discussed in Section 3.3.2. 499 2.2.1. IPv4 Client to IPv4 Server (peer to peer) 501 An IPv4 RTSP client might want to stream data from an IPv4 server, 502 located on the same network -- that is, peer-to-peer. With host- 503 based translation, both of the IPv4 clients would believe they are 504 communicating with IPv4-based servers, but their traffic is 505 translated to IPv6 over the network. This is depicted in the 506 following figure. 508 +-----------------+ +-----------------+ 509 |IPv4 RTSP +------| |------+ IPv4 RTSP| 510 | client | HBT +----+HBT | server | 511 | |w/RTSP| |w/RTSP| | 512 | | ALG | |ALG | | 513 +----------+------+ +------+----------+ 515 Figure 7: RTSP, IPv4 client to IPv4 server (peer to peer) 517 To accomplish this, both hosts need an RTSP ALG between IPv4 RTSP 518 messages and IPv6 RTSP messages. This is because they are in 519 different IPv4 address domains and their IPv4 addresses may overlap. 520 The host operating as an RTSP client uses an IPv4-to-IPv6 ALG, which 521 rewrites the RTSP signaling messages from IPv4 to IPv6. The host 522 operating as the RTSP server uses an IPv6-to-IPv4 ALG, which rewrites 523 the RTSP signaling messages from IPv6 to IPv4. 525 The hosts can avoid an in-network ALG if they realize the 526 communication is with a peer that has an integrated RTSP ALG; this 527 might be accomplished, for example, by assuming all IPv6 hosts with a 528 certain IPv6 prefix have an integrated RTSP ALG, which would be 529 somehow configured into the host-based ALG. 531 2.2.2. IPv4 client to IPv4 Server (client/server) 533 An IPv4 RTSP client might want to stream data from an IPv4 RTSP 534 server on an IPv4 network, as depicted in the following figure. 536 +-----------------+ +-----+ +---------+ 537 |IPv4 RTSP +------| < IPv6 > +NAT64+- < IPv4 > |IPv4 RTSP| 538 | client | HBT +---| with| ---+ server | 539 | | | | RTSP| +---------+ 540 | | | | ALG | 541 +----------+------+ +-----+ 543 Figure 8: RTSP, IPv4 client to IPv4 server (client/server) 545 To accomplish this, the HBT in the host realizes it is sending 546 packets to a NAT64 (e.g., because it matches the network's NAT64 547 prefix (NSP or WKP)), and does not invoke its own ALG. The in- 548 network RTSP ALG, implemented in conjunction with the network's NAT64 549 device, rewrites the RTSP signaling messages from IPv6 to IPv4. 551 Note: It is almost always the case the RTSP media receiver and 552 RTSP client have the same IP address, and the RTSP server and RTSP 553 media server have the same IP address. In the unlikely case this 554 isn't true, the dis-association of the ALG from the host's 555 translator causes a 3-party referral, which will fail. 557 Emerging standards for streaming RTSP media (e.g., 558 [I-D.ietf-mmusic-rtsp-nat]) are using RTSPv2 and RTSP's own NAT 559 traversal, would reasonably be expected to use IPv6, and could 560 have different IP addresses for the RTSP client/media receiver, 561 and the RTSP server/media server. 563 2.2.3. IPv4 Client to IPv6 Server 565 An IPv4 RTSP client might want to stream data from an IPv6 server, as 566 depicted in the following figure. 568 +-----------------+ +---------+ 569 |IPv4 RTSP +------| < IPv6 > |IPv6 RTSP| 570 | client | HBT +---+ server | 571 | |w/RTSP| +---------+ 572 | | ALG | 573 +----------+------+ 575 Figure 9: RTSP, IPv4 client to IPv6 server 577 To accomplish this, the IPv4 host needs an RTSP ALG, because it won't 578 understand the IPv6 addresses provided by the IPv6 RTSP server. 580 2.3. XMPP 582 Extensible Messaging and Presence Protocol (XMPP [RFC3920]) is 583 commonly used for text-based chat. In addition to text-based chat, 584 XMPP also supports voice and video which is signaled using XMPP 585 extensions [ICE-UDP]. This evolution of XMPP to include voice and 586 video requires either (a) host-based XMPP-aware ALGs and in-network 587 XMPP-aware ALGs are deployed, or (b) XMPP clients are updated to 588 natively support IPv6 and support network-based NAT64 translation 589 (e.g., by supporting [I-D.wing-v6ops-v6app-v4server] so that XMPP- 590 aware ALGs would be unnecessary). A difficulty with achieving (a), 591 above, is that XMPP clients routinely use TLS to encrypt traffic to 592 their XMPP servers because text chat messages are often considered 593 confidential, which renders ALGs impossible to deploy with XMPP. 595 These problems prevent an IPv4-only XMPP application from being 596 transparently translated from IPv4 to IPv6 and successfully use voice 597 or video chat. Instead, the XMPP application has to support IPv6 and 598 has to support NAT64 translation to communicate with IPv4 XMPP peers. 600 2.4. IPsec 602 Many residential-grade NATs implement "IPsec Passthru" for a variety 603 of reasons. These create a variety of problems [RFC3715], but some 604 of the problems are masked if only one IPsec association to a 605 specific VPN concentrator -- as is common for Internet access from a 606 coffee shop or hotel. However, when a large NAT serves a larger 607 community of users it becomes more difficult or impossible to mask 608 the deficiencies of IPsec Passthru. Thus, a NAT64 with many IPsec 609 associations, especially to the same VPN concentrator, will fail 610 sessions whereas dozens of low-end NAT devices, with the same number 611 of IPsec associations, will fare better. This is discussed in detail 612 in Section 4.1 of [RFC3715]. 614 Thus, in a large NAT environment, IPsec applications will need to use 615 IPsec-over-UDP [RFC3947] rather than IPsec-over-IP (protocol 50) and 616 relying on IPsec Passthru. This is not unique to v4 applications 617 contacting v6 servers, but it does mean that IPsec cannot enjoy 618 transparent translation from IPv4 to IPv6 to IPv4; it has to run over 619 UDP. 621 Traditionally, IPsec is used purely in client/server scenarios for 622 corporate PCs to connect to a VPN concentrator. However, deployments 623 of Windows 7's DirectAccess and OSX's Back-to-My-Mac service, and of 624 peer-to-peer IPsec [I-D.saito-mmusic-sdp-ike] (which standardizes a 625 similar mechanism), means use of IPsec is likely to increase in peer- 626 to-peer scenarios. 628 2.5. SIP 630 Most SIP networks deploy SBCs to assist with IPv4 NAT traversal 631 ("media latching", described in Section 5 of 632 [I-D.ietf-mmusic-media-path-middleboxes]), IPv6/IPv4 interworking, 633 protection of the service provider's network, and peering between 634 service providers. When used with an SBC, a SIP endpoint works fine 635 with in-host translation, as shown in the figure below. 636 +-------------+ +---------+ 637 |IPv4 SIP +---+ < IPv6 > +---+ < IPv4 > |IPv4 SIP | 638 |endpoint |HBT+----+SBC+----+ endpoint| 639 +---------+---+ +---+ +---------+ 641 However, if an SBC is not present, the IPv4-only SIP endpoint would 642 need its SIP peer to support ICE [I-D.ietf-sipping-v6-transition], as 643 shown in the figure below. 644 +-------------+ +---------+ 645 |IPv4 SIP +---+ < IPv6 > +-----+ < IPv4 > |IPv4 SIP | 646 |endpoint |HBT+----+NAT64+----+ endpoint| 647 +---------+---+ +-----+ | w/ ICE | 648 +---------+ 650 2.6. email protocols (SMTP, IMAP, POP) 652 SMTP Submission [RFC4409], IMAP [RFC3501], and POP3 [RFC1939] are 653 client-initiated protocols and do not contain IP addresses in their 654 payload (except Received: header fields which are only used for 655 troubleshooting). These protocols work fine with in-host 656 translation. Similarly, supporting IPv6 natively in these 657 application is a trivial change, as they are typically configured 658 with a hostname within the host's mail application. HTML rendering 659 by IMAP and POP clients, especially of external objects, does require 660 more effort in the mail client, almost on par with HTTP. However, 661 all major mail clients (e.g., Outlook, Thunderbird, mail.app) already 662 support IPv6 including their HTML renderers. 664 2.7. HTTP 666 HTTP is a client-initiated protocol. When an IPv4 address literals 667 are contained within the URI, or within a page (such as in Javascript 668 or used by a plug-in), the IPv4 server can still be accessed (because 669 the host-based translator knows how to convert an IPv4 address into a 670 corresponding IPv6 address). 672 An HTTP client is more difficult to update to support IPv6 natively. 673 However, all major web browsers have supported IPv6 natively 674 (Internet Explorer, Firefox, Safari, Opera) for years. Thus, native 675 IPv6 support by HTTP clients has already been achieved and there is 676 no need to expect HTTP clients are IPv4-only. 678 3. Concerns 680 3.1. Interference with IPv6 Deployment 682 We assume that BIA/BIS prefer IPv6 addresses over IPv4 addresses, as 683 is common today [RFC3484]. With BIA/BIS, a client application will 684 experience new behavior as soon as its server adds an AAAA record. 685 The addition of an AAAA record changes the operation from NAT464 686 (IPv4 application accessing an IPv4 server) to NAT46 (IPv4 687 application accessing an IPv6 server). This new behavior occurs no 688 matter if an ALG is necessary for that application or not. But the 689 new behavior is even more severe if an ALG is necessary. This means 690 if a server on the Internet adds an AAAA record it may cause existing 691 IPv4 applications to break if an ALG is necessary for those 692 applications (see also Section 3.3). 694 By comparison, if a dual-stack or IPv6-only with in-network NAT64 695 approach ([I-D.ietf-softwire-dual-stack-lite], [I-D.ymbk-aplusp], 696 [I-D.boucadair-port-range]) is used, adding an AAAA record to a 697 server does not adversely affect existing IPv4 host applications. 698 Dual-stack approaches allow a smoother upgrade to IPv6, because AAAA 699 records are only used by IPv6-aware applications running on IPv6- 700 capable hosts connected to IPv6-capable networks. 702 3.2. Troubleshooting 704 The in-host interaction of BIA/BIS, and the in-host ALG necessary for 705 some scenarios with some applications, requires accessing information 706 in the host regarding the state and operation of BIA/BIS and the ALG. 707 This increases the complexity of troubleshooting for the network 708 operator compared with the common approach of capturing and analyzing 709 traffic traversing the network. Beyond troubleshooting historically 710 problematic ALGs, fixing the host-based ALG may require software 711 changes to potentially millions of end-points. 713 3.3. Application Layer Gateways 715 3.3.1. Standardization 717 There are implementations of a ALGs for a wide variety of protocols 718 for IPv4 to IPv4 translation. However, NAT464 needs an IPv4 to IPv6 719 ALG. As demonstrated by April 2009 survey of EPSV support on the 720 Internet (Section 1 of [I-D.van-beijnum-behave-ftp64]), IPv4/IPv6 721 ALGs are more difficult than anticipated for even a simple and long- 722 established protocol such as FTP. 724 To date, only one detailed specification exists to describe the 725 function of an ALG [I-D.van-beijnum-behave-ftp64] for IPv6 clients to 726 access IPv4 servers. Yet for BIA/BIS to be successfully deployed 727 with IPv6 servers, the opposite will need to be specified (IPv4 728 client accessing an IPv6 server). Furthermore, an ALG will need to 729 be standardized for every protocol that exchanges IP addresses in its 730 payload, including applications such as (but not limited to) active- 731 mode FTP44, passive mode FTP64 (work in progress, 732 [I-D.van-beijnum-behave-ftp64]), H.323, HELD 733 [I-D.ietf-geopriv-held-identity-extensions], RTSP, RTSPv2 (see Note, 734 below), SAP, SIP (see Note, below), PPTP, IPsec, and XMPP. 736 Note: Although some protocols include their own advanced NAT 737 traversal mechanisms (e.g., SIP can use [I-D.ietf-mmusic-ice], 738 RTSPv2 can use [I-D.ietf-mmusic-rtsp-nat], H.325 has some NAT 739 traversal mechanisms), it is impossible to know if the IPv4 740 application running on the host implements those advanced NAT 741 traversal mechanisms. Thus, ALGs for protocols running on the 742 same port are probably still necessary. 744 3.3.2. Interference with Application Evolution 746 An ALG can interfere in undesirable ways with enhancements to 747 applications. For example, both Teredo (Section 3.1 of [RFC4380]) 748 and STUN (Section 15.2 of [RFC5389]) needed to explicitly encode 749 their application payloads to avoid overly-ambitious ALGs. Thus, 750 careful standardization, design, and implementation of ALG behavior 751 is critical or else ALGs will interfere with applications. Even so, 752 experience demonstrates that it is unlikely that all interference 753 with applications can be avoided; a quick search using your favorite 754 search engine for "SIP ALG disable" will yield a treasure trove of 755 industry experience with a protocol that embeds IP addresses in its 756 payloads. 758 3.3.3. Encrypted Application Signaling 760 Some application that carry IP addresses in their payloads are 761 encrypted (e.g., FTPS [RFC4217], SIPS [I-D.ietf-sip-sips]), while 762 others are routinely encrypted (e.g., XMPP). This encryption 763 prevents an ALG from modifying the application signaling messages, 764 which means those IPv4 applications will fail if they attempt to 765 communicate with an IPv6 server -- no matter if the ALG is inside the 766 host or not. This is because the application performs the TLS 767 encryption using its own TLS library, whereas an in-host ALG is part 768 of the IP stack (beneath the application). 770 3.3.4. ALG interference with IPv6-aware applications 772 The in-network NAT64 device will operate ALGs, for various protocols. 773 These ALGs will necessarily rewrite addresses, even for IPv6-aware 774 applications. That may cause problems for those IPv6-aware 775 applications. [[need more detail.]] 777 4. Recommendations 779 Of the concerns outlined in the previous section, the most 780 significant is that some protocols need an ALG to function correctly 781 when a NAT46 function is performed by BIA/BIS. Thus, limiting the 782 PNAT system to only NAT464 reduces this concern. This appears 783 achievable by having the in-host BIA/BIS function so it only performs 784 A queries (and never AAAA) queries. 786 If that capability is removed from BIA/BIS, PNAT should be carefully 787 compared with other approaches to evaluate the advantages and 788 disadvantages of PNAT. 790 5. Security Considerations 792 TBD. 794 6. IANA Considerations 796 This document requires no IANA actions. 798 7. Acknowledgements 800 Thanks to Christian Vogt for his review comments. 802 This document was produced using version 1.35pre1 of xml2rfc. 804 8. References 806 8.1. Normative References 808 [I-D.huang-behave-pnat] 809 Huang, B. and H. Deng, "Prefix NAT: Host based IPv6 810 translation", draft-huang-behave-pnat-01 (work in 811 progress), February 2010. 813 [I-D.huang-behave-rfc2767bis] 814 Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts 815 using the "Bump-In-the-Stack" Technique (BIS)", 816 draft-huang-behave-rfc2767bis-01 (work in progress), 817 February 2010. 819 [I-D.huang-behave-rfc3338bis] 820 Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts 821 Using "Bump-in-the-API" (BIA)", 822 draft-huang-behave-rfc3338bis-01 (work in progress), 823 February 2010. 825 [I-D.ietf-behave-v6v4-xlate-stateful] 826 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 827 NAT64: Network Address and Protocol Translation from IPv6 828 Clients to IPv4 Servers", 829 draft-ietf-behave-v6v4-xlate-stateful-08 (work in 830 progress), January 2010. 832 [I-D.vogt-durand-virtual-ip6-connectivity] 833 Vogt, C. and A. Durand, "Virtual IPv6 Connectivity for 834 IPv4-Only Networks", 835 draft-vogt-durand-virtual-ip6-connectivity-03 (work in 836 progress), October 2009. 838 8.2. Informative References 840 [I-D.boucadair-port-range] 841 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 842 "IPv4 Connectivity Access in the Context of IPv4 Address 843 Exhaustion: Port Range based IP Architecture", 844 draft-boucadair-port-range-02 (work in progress), 845 July 2009. 847 [I-D.ietf-geopriv-held-identity-extensions] 848 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 850 Barnes, "Use of Device Identity in HTTP-Enabled Location 851 Delivery (HELD)", 852 draft-ietf-geopriv-held-identity-extensions-03 (work in 853 progress), February 2010. 855 [I-D.ietf-mmusic-ice] 856 Rosenberg, J., "Interactive Connectivity Establishment 857 (ICE): A Protocol for Network Address Translator (NAT) 858 Traversal for Offer/Answer Protocols", 859 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 861 [I-D.ietf-mmusic-media-path-middleboxes] 862 Stucker, B. and H. Tschofenig, "Analysis of Middlebox 863 Interactions for Signaling Protocol Communication along 864 the Media Path", 865 draft-ietf-mmusic-media-path-middleboxes-02 (work in 866 progress), March 2009. 868 [I-D.ietf-mmusic-rfc2326bis] 869 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 870 and M. Stiemerling, "Real Time Streaming Protocol 2.0 871 (RTSP)", draft-ietf-mmusic-rfc2326bis-22 (work in 872 progress), July 2009. 874 [I-D.ietf-mmusic-rtsp-nat] 875 Goldberg, J., Westerlund, M., and T. Zeng, "A Network 876 Address Translator (NAT) Traversal mechanism for media 877 controlled by Real-Time Streaming Protocol (RTSP)", 878 draft-ietf-mmusic-rtsp-nat-09 (work in progress), 879 January 2010. 881 [I-D.ietf-mmusic-rtsp-nat-evaluation] 882 Westerlund, M. and T. Zeng, "The evaluation of different 883 NAT traversal Techniques for media controlled by Real-time 884 Streaming Protocol (RTSP)", 885 draft-ietf-mmusic-rtsp-nat-evaluation-02 (work in 886 progress), January 2010. 888 [I-D.ietf-sip-sips] 889 Audet, F., "The use of the SIPS URI Scheme in the Session 890 Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work 891 in progress), November 2008. 893 [I-D.ietf-sipping-v6-transition] 894 Camarillo, G., "IPv6 Transition in the Session Initiation 895 Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work 896 in progress), August 2007. 898 [I-D.ietf-softwire-dual-stack-lite] 899 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 900 Y., and R. Bush, "Dual-stack lite broadband deployments 901 post IPv4 exhaustion", 902 draft-ietf-softwire-dual-stack-lite-03 (work in progress), 903 February 2010. 905 [I-D.saito-mmusic-sdp-ike] 906 Saito, M., Wing, D., and M. Toyama, "Media Description for 907 IKE in the Session Description Protocol (SDP)", 908 draft-saito-mmusic-sdp-ike-06 (work in progress), 909 November 2009. 911 [I-D.van-beijnum-behave-ftp64] 912 Beijnum, I., "IPv6-to-IPv4 translation FTP 913 considerations", draft-van-beijnum-behave-ftp64-06 (work 914 in progress), October 2009. 916 [I-D.wing-v6ops-v6app-v4server] 917 Wing, D., "Building IPv6 Applications which Access IPv4 918 Servers", draft-wing-v6ops-v6app-v4server-01 (work in 919 progress), October 2009. 921 [I-D.ymbk-aplusp] 922 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 923 draft-ymbk-aplusp-05 (work in progress), October 2009. 925 [ICE-UDP] Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., 926 Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP 927 Transport Method", June 2009, 928 . 930 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 931 STD 53, RFC 1939, May 1996. 933 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 934 Streaming Protocol (RTSP)", RFC 2326, April 1998. 936 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 937 for IPv6 and NATs", RFC 2428, September 1998. 939 [RFC3484] Draves, R., "Default Address Selection for Internet 940 Protocol version 6 (IPv6)", RFC 3484, February 2003. 942 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 943 4rev1", RFC 3501, March 2003. 945 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 946 (NAT) Compatibility Requirements", RFC 3715, March 2004. 948 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 949 Protocol (XMPP): Core", RFC 3920, October 2004. 951 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 952 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 953 January 2005. 955 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 956 October 2005. 958 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 959 Network Address Translations (NATs)", RFC 4380, 960 February 2006. 962 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 963 RFC 4409, April 2006. 965 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 966 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 967 October 2008. 969 Appendix A. To Do 971 Add walk throughs for: 973 o Dual-Stack Application to IPv4 Server 975 o Dual-Stack Application to IPv6-only Server 977 o Dual-Stack Application to Dual-Stack Server 979 Authors' Addresses 981 Dan Wing 982 Cisco Systems, Inc. 983 170 West Tasman Drive 984 San Jose, CA 95134 985 USA 987 Email: dwing@cisco.com 988 Cameron Byrne 989 T-Mobile USA, Inc. 991 Email: cameron.byrne@t-mobile.com