idnits 2.17.1 draft-satapati-v6ops-natpt-applicability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2003) is 7496 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2766 (ref. '1') (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2765 (ref. '2') (Obsoleted by RFC 6145) == Outdated reference: A later version (-02) exists of draft-itojun-v6ops-v4mapped-harmful-01 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 3142 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 3574 (ref. '6') -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '9') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. '11') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '12') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2408 (ref. '13') (Obsoleted by RFC 4306) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-08 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Satapati 3 Internet-Draft S. Sivakumar 4 Expires: April 16, 2004 Cisco Systems, Inc. 5 P. Barany 6 No Affiliation 7 S. Okazaki 8 NTT Multimedia Communications Labs 9 H. Wang 10 Nokia 11 October 17, 2003 13 NAT-PT Applicability 14 draft-satapati-v6ops-natpt-applicability-00 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 16, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 This document discusses the applicability RFC 2766, Network Address 45 Translation - Protocol Translation (NAT-PT) employing the Stateless 46 IP/ICMP Translation (SIIT) algorithm, as an IPv4-to-IPv6 transition 47 and co-existence mechanism. It highlights the NAT-PT/SIIT operational 48 principles and the network context for which NAT-PT was designed. 49 Known limitations of NAT-PT/SIIT are presented. Applicable scenarios 50 along with guidelines for deployment are being offered. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. SIIT Limitations . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Overloading the Use of IPv4-mapped addresses . . . . . . . . 4 57 2.2 Translation Semantics Difficult to Use . . . . . . . . . . . 4 58 2.3 Multicast Mapping Impossible . . . . . . . . . . . . . . . . 5 59 2.4 SCTP and Multihoming . . . . . . . . . . . . . . . . . . . . 5 60 2.5 IP Security (IPsec) . . . . . . . . . . . . . . . . . . . . 5 61 2.5.1 IPsec Encapsulating Security Protocol (ESP) . . . . . . . . 5 62 2.5.2 IPsec Authentication Header (AH) . . . . . . . . . . . . . . 6 63 2.5.3 Key Management . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. NAT-PT Limitations . . . . . . . . . . . . . . . . . . . . . 7 65 3.1 Application deployment . . . . . . . . . . . . . . . . . . . 7 66 3.2 Scalability/Single-point-of-failure . . . . . . . . . . . . 7 67 3.3 IP Security . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.3.1 IPsec ESP/AH . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.3.2 Key Management . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.4 DNS-ALG . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.5 Denial of Service . . . . . . . . . . . . . . . . . . . . . 8 72 3.5.1 Address Pool Depletion Attacks . . . . . . . . . . . . . . . 9 73 3.5.2 Reflection Attacks . . . . . . . . . . . . . . . . . . . . . 9 74 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1 SIIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.2 NAT-PT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.2.1 Legacy IPv4-only nodes in an IPv6 network . . . . . . . . . 10 78 4.2.2 Special Nodes/Networks . . . . . . . . . . . . . . . . . . . 10 79 4.2.3 IPv6-only Networks . . . . . . . . . . . . . . . . . . . . . 11 80 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 83 Normative References . . . . . . . . . . . . . . . . . . . . 12 84 Informative References . . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 86 A. IPv6-only Networks . . . . . . . . . . . . . . . . . . . . . 14 87 Intellectual Property and Copyright Statements . . . . . . . 16 89 1. Introduction 91 NAT-PT [1], or Network Address translation Protocol translation, is 92 the standard mechanism that allows communication between IPv6-only 93 and IPv4-only nodes. RFC 2766 also defines NAPT-PT, a variant of 94 NAT-PT that translates transport identifiers (TCP/UDP port numbers 95 and ICMP identifiers) in addition to IP header, allows multiple V6 96 nodes to communicate with V4 nodes using a single public IPv4 97 address. 99 SIIT [2] specifies an algorithm for translation between IPv4 and IPv6 100 packet headers (including ICMP headers) in separate translator boxes 101 in the network without requiring any per-connection state in those 102 boxes. An IPv6-only node acquires a temporary IPv4 address (known as 103 an IPv4-translated address) when communicating with an IPv4-only 104 node. IPv6 nodes, that use SIIT, would need additional logic in the 105 network layer so that an application inserts IPv4 type literals in 106 the payload if the destination is an IPv4-mapped IPv6 address. SIIT 107 does not specify a mechanism for the IPv6-only node to acquire a 108 temporary IPv4 address, nor does it specify a mechanism for providing 109 routing (perhaps using tunneling) to and from the temporary IPv4 110 address assigned to the IPv6-only node. 112 NAT-PT uses SIIT algorithm for protocol independent translation of 113 IPv4 and IPv6 datagrams. NAT-PT describes the dynamic address 114 assignment of IPv4 address to IPv6 nodes and vice-versa, as sessions 115 are initiated across IPv4/IPv6 boundaries. The IPv4 addresses are 116 assigned from an IPv4 address pool and are used to transparently 117 replace the original IPv6 addresses used by the IPv6-only nodes. 118 Consequently, the IPv6-only nodes need not be changed in any way. 119 However, NAT-PT must track sessions (i.e., state must be maintained) 120 and the inbound and outband packets pertaining to a session must 121 traverse the same NAT-PT device. 123 RFC 2766 specifies DNS-ALG for address discovery to support 124 bidirectional session initiation. RFC 2766 also specifies FTP-ALG to 125 provide application level transparency between IPv4 and IPv6. For 126 applications (like FTP) that carry IP addresses and/or transport 127 layer port numbers in their application-level data, additional 128 Application Layer Gateways (ALGs) would need to be deployed along 129 with NAT-PT. 131 This document discusses the applicability of Network Address 132 Translation - Protocol Translation as an IPv4-to-IPv6 transition and 133 co-existence mechanism. It highlights the NAT-PT/SIIT operational 134 principles and the network context for which NAT-PT was designed. 135 Known limitations of NAT-PT/SIIT are presented. Applicable scenarios 136 along with guidelines for deployment are being offered. 138 Sections 2 and 3 talk about limitations of SIIT and NAT-PT (including 139 DNS-ALG) in its current form. Section 4 presents the applicable 140 scenarios. Section 5 summarizes the applicability and proposes some 141 recommendations when deploying NAT-PT. 143 2. SIIT Limitations 145 In this section, we present the limitatons that are specific to SIIT. 146 It is important to analyze SIIT because it is an integral part of 147 NAT-PT. 149 2.1 Overloading the Use of IPv4-mapped addresses 151 IPv4-mapped IPv6 addresses are of the form ::ffff:a.b.c.d, and are 152 used to refer to IPv4-only nodes. An IPv6 packet, going through SIIT 153 from an IPv6-only node, will have IPv4-mapped address as destination 154 in the IPv6 header. Problems associated with usage of IPv4-mapped 155 address have been discussed in an expired draft [3]. 157 Most notably, as described in RFC 3493 [8], the IPv4-mapped address 158 representation is used in the basic API to denote IPv4 addresses 159 using the AF_INET6 socket. However, at the same time, the IPv4-mapped 160 address is also used by SIIT to denote IPv6 communication using 161 AF_INET6 sockets. Consequently, a security threat exists due to the 162 ambiguous dual use of IPv4-mapped addresses. 164 2.2 Translation Semantics Difficult to Use 166 Some of the translation semantics defined by SIIT are difficult to 167 implement/interpret. The ICMPv4 "Parameter Problem" (type 12 code 0) 168 and the ICMPv6 "Parameter Problem" (Type 4 Code 0, 1, 2) error 169 messages are classic examples. Some ICMP error messages do not have 170 IPv6 counterpart and hence there were no semantics defined. A 171 particular problem being reported in the IPv4-side may go 172 unrecognized from the IPv6 perspective. 174 In order to translate from ICMPv6 to ICMPv4, if the ICMPv6 code field 175 is set to 1 (unrecognizable Next Header Type encountered), then the 176 ICMPv6 message is translated into an ICMPv4 Destination Unreachable 177 Message (Type 3 code 2) Error Message. There is no loss of 178 information in this case. However, if the ICMPv6 code field is set to 179 0 (erronenous header field encountered) or 2 (unrecognized IPv6 180 option encountered), then the ICMPv6 message is translated into an 181 ICMPv4 Parameter Problem (Type 12 Code 0) Error Message and the 182 pointer needs to be updated to point to the corresponding field in 183 the translated and included IP header. There is a loss of information 184 in this case. 186 2.3 Multicast Mapping Impossible 188 IPv4 multicast addresses cannot be mapped to IPv6 multicast addresses 189 (e.g., ::ffff:224.1.2.3 is an IPv4-mapped address with a Class D IPv4 190 address, but it is not an IPv6 multicast address). This limitation 191 makes it impossible for SIIT to support multicast between IPv6 and 192 IPv4 networks. 194 2.4 SCTP and Multihoming 196 SCTP [9] supports multihoming. If an IPv6-only node sets up SCTP 197 connections to an IPv4-only node with one or more SIITs between them, 198 there could be a problem. If more than one IPv4-translated address is 199 used, these addresses are transported to the IPv4-only node during 200 association setup in the payloads of the INIT and INIT-ACK chunks. 201 SIIT, as specified in [1], cannot translate IP addresses included in 202 INIT and INIT-ACK chunks. Even if it could, there would be a problem 203 with SCTP/IP packets being carried through the translator using ESP 204 in Transport-mode. 206 Also, there is ongoing work which allows the modification of the IP 207 address once an SCTP association has been established (for 208 non-multihoming purposes). The modification messages have IP 209 addresses in the SCTP packet [14]. 211 2.5 IP Security (IPsec) 213 2.5.1 IPsec Encapsulating Security Protocol (ESP) 215 ESP provides both confidentiality and integrity for the packet that 216 it is protecting [10]. ESP in Transport-mode encrypts the transport 217 layer header, the data, and the ESP trailer (optional Padding, Pad 218 Length, and Next Header). ESP in Transport-mode authenticates the ESP 219 header (SPI, Sequence Number, and IV) in addition to the transport 220 layer header, the data, and the ESP trailer. 222 SIIT does not modify any headers above the logical IP layer (IP 223 headers, IPv6 fragment headers). Therefore, TCP/UDP packets encrypted 224 using ESP in Transport-mode can pass through, assuming that key 225 management (manual or IKE) can operate somehow between an IPv6-only 226 node and IPv4-only node. The reason being the notation of 227 IPv4-translatable addresses, which is ::ffff:0:a.b.c.d, was chosen to 228 avoid any changes to the transport layer protocol's pseudo-header 229 checksum. Also, SCTP calculates a CRC-32c checksum only on the SCTP 230 packet (SCTP common header and one or more control or DATA chunks). 231 Therefore, as long as SCTP control chunks like INIT and INIT-ACK do 232 not contain IP addresses, SCTP packets encrypted using ESP in 233 Transport-mode can pass through SIIT. 235 ICMP messages, on the other hand, cannot be carried through SIIT for 236 a number of reasons: 238 o the ICMP checksum field must be updated as part of the translation 239 since ICMPv6, unlike ICMPv4, has a pseudo-header checksum like TCP 240 or UDP 242 o ICMP packets need to have the Type value translated 244 o for ICMP error messages, the included IP header also needs 245 translation 247 ESP in Tunnel-mode encrypts the IP header of the encapsulated IP 248 packet in addition to the transport layer header, the data, and the 249 ESP trailer of the encapsulated IP packet. ESP in Tunnel-mode 250 authenticates the ESP header in addition to the encapsulated IP 251 packet and the transport layer header, the data, and the ESP trailer 252 of the encapsulated IP packet. Consequently, TCP/IP packets, UDP/IP 253 packets, SCTP/IP packets, and ICMP packets cannot be carried through 254 the SIIT translator using ESP in Tunnel-mode. 256 2.5.2 IPsec Authentication Header (AH) 258 AH provides integrity for the packet that it is protecting [11]. AH 259 is explicitly designed to detect alterations to IP packet headers. AH 260 in Transport-mode authenticates the immutable fields of the IP header 261 (setting the mutable fields to zero prior to calculating the 262 Integrity Check Value (ICV)), the AH header (Next Header, Payload 263 Length, Reserved, SPI, and Sequence Number), and the data. 264 Consequently, TCP/IP packets, UDP/IP packets, SCTP/IP packets, and 265 ICMP packets, or any such packets cannot be carried through the SIIT 266 translator using AH in Transport-mode. 268 AH in Tunnel-mode authenticates the immutable fields of the outer IP 269 header (setting the mutable fields to zero prior to calculating the 270 ICV), the AH header, the encapsulated IP header, the transport layer 271 header, and the data. Consequently, TCP/IP packets, UDP/IP packets, 272 SCTP/IP packets, and ICMP packets, or any such packets cannot be 273 carried through the SIIT translator using AH in Tunnel-mode. 275 2.5.3 Key Management 277 Note that this entire discussion begs the question that key 278 management can operate between the IPv6-only node and the IPv4-only 279 node. While this may not be an issue for IPsec implementations that 280 are integrated with the host's Operating System (OS), there could be 281 substantial challenges that need to be overcome with either a 282 Bump-In-the-Stack (BIS) or Bump-In-The-Wire (BITW) IPsec 283 implementation [12]. 285 For example, the ISAKMP Identification payload [13] that is used in 286 IKE Phase 1 Main Mode/Aggressive Mode (pre-shared secret, digital 287 signatures with certificates, public key encryption, and revised 288 public key encryption) may contain the IP address of the host as an 289 identifier (e.g., ID_IPV6_ADDR, ID_IPV4_ADDR). The same holds true 290 for IKE Phase 2 Quick Mode and the optional usage of the Client 291 Identification payload. While the use of other identifiers such as 292 ID_FQDN and ID_USER_FQDN are possible, there are usage scenarios that 293 cannot be accommodated in this manner (e.g., SPD entries describing 294 subnets). 296 3. NAT-PT Limitations 298 The adverse effects of NAT [4] have been studied to a great extent in 299 the past [7]. While NAT-PT has exactly the same implications as NAT, 300 the DNS-ALG as specified in RFC 2766 introduces additional failure 301 modes. Most applications may fail for exactly the same reasons as 302 those cited for IPv4 NAT. All SIIT limitations mentioned above hold 303 true for NAT-PT, except those due to usage of IPv4-mapped IPv6 304 addresses. NAT-PT proposes to use a /96 prefix, which need not be a 305 IPv4-mapped IPv6 address type. The limitations of DNS-ALG, as an 306 inherent address discovery mechanism, are also discussed in this 307 section. 309 3.1 Application deployment 311 Applications that embed literals, such as IP addresses and/or TCP/UDP 312 port numbers, will break across NAT-PT in the absence of a supporting 313 ALG. ALGs are required to setup bindings during signalling, which 314 would subsequently be used for data (or media) traffic. Each 315 application requires its own specific ALG to be deployed that should 316 work in tandem with header-translation functionality. It is hard to 317 cope up with this situation, as new applications become popular or 318 existing applications define new extensions or message types. 320 3.2 Scalability/Single-point-of-failure 322 A single device implementing NAT-PT (and ALGs) can easily become a 323 bottleneck, when traffic from a large IPv6 network is forced to go 324 through a single device. The device builds and maintains binding 325 state as traffic flows traverse. Therefore all subsequent traffic of 326 the flow must pass through it, turning the device into a single point 327 of failure. 329 3.3 IP Security 330 3.3.1 IPsec ESP/AH 332 All of the IPsec ESP and AH limitations that apply to SIIT also apply 333 to NAT-PT because NAT-PT(and NAPT-PT) make use of SIIT translation 334 algorithm to translate IP headers and transport identifiers. However, 335 unlike SIIT, NAT-PT need not use IPv4-translated addresses and IPv4- 336 mapped addresses. Therefore, TCP/IP, UDP/IP, and ICMP packets cannot 337 be carried through NAT-PT in ESP Transport-mode because TCP, UDP, and 338 ICMPv6 checksums have a dependency on the IP source and destination 339 addresses via the pseudo-header. However, SCTP calculates a CRC-32c 340 checksum only on the SCTP packet (SCTP common header and one or more 341 control or DATA chunks). Therefore, as long as SCTP control chunks 342 like INIT and INIT-ACK do not contain IP addresses, SCTP packets 343 encrypted using ESP in Transport-mode can pass through NAT-PT. 345 3.3.2 Key Management 347 All of the key management limitations that apply to SIIT also apply 348 to NAT-PT because NAT-PT (and NAPT-PT) make use of SIIT translation 349 algorithm to translate IP headers and transport identifiers. Also, 350 since NAT-PT maintains state (unlike SIIT), even if IP addresses are 351 not used in the ISAKMP Identification payload during IKE Phase 1 Main 352 Mode/Aggressive Mode and IKE Phase 2 Quick Mode, there is still 353 difficulty with retaining the IPv4-to-IPv6 address mapping on NAT-PT 354 from the time that IKE completes negotiation to the time that IPsec 355 uses the key on an application. 357 3.4 DNS-ALG 359 Address discovery is the mechanism by which an IPv4-only or an 360 IPv6-only node discovers the "translated address" to which the 361 packets should be sent. The NAT-PT specification proposes to solve 362 address discovery, for applications that use DNS, by using a DNS-ALG, 363 as specified in section 4 of RFC-2766. 365 Address discovery through DNS-ALG is broken when dual-stack nodes 366 attempt to talk to either IPv6-only or IPv4-only nodes. The result 367 here is the possibility of traffic flow taking a translated path as 368 opposed to native. Additionally an IPv4 node that sends an A query, 369 through DNS-ALG, may receive a AAAA reply. 371 Since DNS-ALG modifies queries (from A to AAAA) and replies (IPv6 372 address to IPv4 address literals), DNSSEC cannot be deployed in the 373 presence of DNS-ALG. 375 3.5 Denial of Service 377 The DoS attacks being discussed here are mostly due to address 378 spoofing. 380 3.5.1 Address Pool Depletion Attacks 382 Suppose that the attacker resides in the same IPv6 stub domain as 383 NAT-PT, and is sending packets to an IPv4-only destination. If the 384 IPv6 attacker sends multiple packets with different source address 385 (that are topologically inside the stub domain), then the pool of 386 IPv4 addresses managed by NAT-PT will quickly exhaust resulting in a 387 Denial of Service to legitimate IPv6-only nodes. 389 3.5.2 Reflection Attacks 391 There is another address spoofing attack, wherein the attacker forges 392 the IPv6 source address to be a broadcast or multicast or the source 393 address of an existing node. The reply IPv4 packets that get 394 translated by NAT-PT will result in an attack. 396 4. Applicability 398 4.1 SIIT 400 SIIT assumes v4 address assignment to IPv6 nodes, and routing to that 401 assigned v4 address. These aspects are actually requirements for SIIT 402 deployment. Additionally, IPv6 nodes need some modification as 403 mentioned in Section 1. Any host modifications to support a certain 404 transition mechanism are strongly discouraged. Applications cannot 405 interoperate between pure IPv6-only and IPv4-only nodes using SIIT, 406 unless there exists an ALG accompanying SIIT. 408 If SIIT were to de deployed for IPv6-only nodes (i.e. without the 409 modifications proposed by SIIT), it is mandatory to have supporting 410 ALGs for applications that need interoperability. The device 411 implementing SIIT must maintain binding state somehow. This 412 combination is not very different from deployment model of NAT-PT. 413 Hence applicable scenarios would be the same as the ones explained 414 below. 416 The SIIT algorithm may be useful in header translation if some 417 specific-purpose translators are specified which can live with the 418 shortcomings of SIIT. 420 4.2 NAT-PT 422 It is theoretically possible to deploy NAT-PT at the border of an 423 IPv6-only stub network, either translating specific IPv6-only 424 services to IPv4 nodes or by translating IPv4-only services to IPv6 425 nodes. The latter comes in two flavors: translation by the party 426 providing such an IPv4-only service, or someone servicing them, or by 427 the party which is planning to deploy IPv6-only infrastructure. There 428 are some very specific cases, where one may be able to consider its 429 use. 431 4.2.1 Legacy IPv4-only nodes in an IPv6 network 433 This is the scenario where the entire network infrastructure is IPv6 434 and the majority of nodes attached to the network are IPv6-only. But 435 there are some existing (legacy) IPv4-only hosts that cannot be 436 upgraded (or abandoned) and that need connectivity to the neighboring 437 IPv6 nodes. 439 It is unrealistic to continue deploying/supporting dual-stack nodes 440 network-wide to support a small set of legacy IPv4-only hosts. 441 Ideally, legacy nodes must be retired as quickly as possible. Proxy/ 442 relay mechanism, such as TRT[5], could be used to enable basic 443 applications that use TCP/UDP. Since host upgrade is ruled out, 444 NAT-PT can be used when traffic to/from these legacy hosts is 445 minimal. NAT-PT must be considered only when proxies cannot be 446 deployed or deemed unfit for the specific application being enabled. 448 While this scenario may be acceptable within an organization/domain, 449 the same may not be true between independent domains. The 450 consequences of NAT-PT, as discussed above, must be kept in mind 451 during deployment. 453 4.2.2 Special Nodes/Networks 455 This scenario applies to situations where constraints arise that are 456 either imposed by the network or by the end nodes. These constraints 457 do not apply to a general purpose IP network or generic TCP/IP hosts 458 connected to a general purpose IP network. Few special cases are 459 listed below: 461 o devices are IPv6-only due to memory and code size constraints 463 o devices are built to run a specific well-defined set of 464 applications 466 o devices could be dual-stack; but resource consumption in the 467 network should be kept at a minimum 469 3GPP networks is an example of the latter, where IMS is IPv6-only by 470 design and PDP context is supposedly a scarce resource. 472 4.2.2.1 Restricted use in 3GPP Networks 473 An important requirement for 3GPP networks is that 3GPP hosts, 474 running SIP-based IMS applications over IPv6, must be able to 475 communicate with IPv4 SIP hosts on the Internet [6]. To minimize the 476 number of active PDP Contexts in the mobile network, it should be 477 possible for a 3GPP host to access both IMS applications and other 478 non-IMS applications (non-SIP-based) over a single IPv6 connection 479 (IPv6 PDP Context in 3GPP). 481 NA(P)T-PT may be used for translating traffic pertaining to specific 482 (non-IMS) applications, for which dual-stack application proxies are 483 not suitable. NA(P)T-PT may be used for header translation of IMS 484 media traffic, provided the binding is acquired through different 485 means. In other words, the device implementing header translation 486 must not implement ALGs. The mechanism of acquiring the binding from 487 an external entity is beyond the scope of this document. 489 IMS media translation may prove to be a burden and inefficient if a 490 single device is implementing header translation. Distributed 491 approaches/techniques may be considered to offload the translation 492 responsibility to multiple devices, which requires exchange of 493 binding state between devices. The exact operation of such an 494 approach is beyond the scope of this document. 496 4.2.2.2 3GPP2 Networks 498 For further study. 500 4.2.3 IPv6-only Networks 502 The deployment of IPv6-only networks in general is not recommended, 503 and therefore this scenario is only tentatively described in Appendix 504 A. 506 5. Summary 508 This document discourages NAT-PT (RFC 2766) as a general purpose 509 transition mechanism, except for the scenarios mentioned above. The 510 limitations cited in this document must be observed during 511 deployment. Only if the shortcomings of NAT-PT are acceptable in a 512 particular deployment, may the use of NAT-PT be considered as a 513 short-term solution. In no case should NAT-PT be viewed as a generic 514 solution for IPv6/IPv4 transition in an IPv6-only network. 516 It is to be noted that DNS-ALG has severe failure modes when 517 processing AAAA queries. However, DNS-ALG could still be used for 518 IPv4-initiated connections. 520 For special networks, targeted translation using NAT-PT is acceptable 521 for short term. Migrating entirely to IPv6 is considered beneficial 522 in the long run. 524 RFC 2766 specifies NAT-PT using the SIIT algorithm for header 525 conversion, DNS-ALG for address discovery, and FTP-ALG as one 526 application level gateway mechanism. The terminology in RFC 2766 can 527 easily be misinterpreted, in that NAT-PT mandates ALGs. RFC 2766 does 528 not mandate DNS-ALG to be implemented along with header translation 529 mechanism. 531 6. Security Considerations 533 This memo discusses the limitations and the applicability of NAT-PT. 534 One important consideration in this analysis is the security related 535 to packet translation. As shown, IPsec AH and ESP generally do not 536 work through the NAT-PT translators. Similarly, the NAT-PT DNS-ALG 537 and similar algorithms cause bottlenecks and a concern for 538 availability if deployed. The generic translation mechanisms seem to 539 be causing a number of problems. Therefore, mass deployment of 540 translators is not recommended; some use may be possible in very 541 specific cases identified in this memo. 543 7. Acknowledgements 545 The authors gratefully acknowledge the contributions of Pekka Savola 546 and Rob Austein. 548 Normative References 550 [1] Tsirtsis and Srisuresh, "Network Address Translation - Protocol 551 Translation (NAT-PT)", RFC 2766, February 2000. 553 [2] Nordmark, "Stateless IP/ICMP Translator (SIIT)", RFC 2765, 554 February 2000. 556 [3] Metz and Hagino, "IPv4-Mapped Addresses on the Wire Considered 557 Harmful", draft-itojun-v6ops-v4mapped-harmful-01 Expired, 558 October 2002. 560 [4] Srisuresh and Egevang, "The IP Network Address Translator", RFC 561 3022, January 2001. 563 [5] Hagino and Yamamoto, "An IPv6-to-IPv4 Transport Relay 564 Translator", RFC 3142, June 2001. 566 [6] Soininen et al., "Transition Scenarios for 3GPP Networks", RFC 567 3574, August 2003. 569 Informative References 571 [7] Hain, "Architectural Implications of NAT", RFC 2993, November 572 2000. 574 [8] Gilligan, R. et al., "Basic Socket Interface Extensions for 575 IPv6", RFC 3493, February 2003. 577 [9] Stewart, R. et al., "Stream Control Transmission Protocol", RFC 578 2960, October 2000. 580 [10] Kent and Atkinson, "IP Encapsulating Security Payload", RFC 581 2406, November 1998. 583 [11] Kent and Atkinson, "IP Authentication Header", RFC 2402, 584 November 1998. 586 [12] Kent and Atkinson, "Security Architecture for the Internet 587 Protocol", RFC 2401, November 1998. 589 [13] Maughan, D. et al., "Internet Security Association and Key 590 Management Protocol", RFC 2408, November 1998. 592 [14] Stewart, R. et al., "Stream Control Transmission Protocol 593 (SCTP) Dynamic Address Reconfiguration", 594 draft-ietf-tsvwg-addip-sctp-08 Work in progress, September 595 2003. 597 Authors' Addresses 599 Suresh Satapati 600 Cisco Systems, Inc. 601 170 West Tasman Dr. 602 San Jose, CA 95134 603 USA 605 EMail: satapati@cisco.com 607 Senthil Sivakumar 608 Cisco Systems, Inc. 609 170 West Tasman Dr. 610 San Jose, CA 95134 611 USA 613 EMail: ssenthil@cisco.com 614 Peter Barany 615 No Affiliation 617 EMail: Baranyp9@aol.com 619 Satomi Okazaki 620 NTT Multimedia Communications Labs 621 250 Cambridge Avenue 622 Palo Alto, CA 94306 623 USA 625 EMail: satomi@nttmcl.com 627 Hao H. Wang 628 Nokia 629 5th Floor, House 1, No.11, Hepingli Dongjie 630 Beijing 631 China 633 EMail: hao.h.wang@nokia.com 635 Appendix A. IPv6-only Networks 637 To roll out a new network, the options are IP4-only, IPv6-only or 638 dual-stack. The most important requirement would be connectivity to 639 surrounding internal networks or an external network such as the 640 Internet. This connectivity has to be IPv4, due to existing deployed 641 base. Therefore the options are: 643 o If the new network is deployed as IPv4-only, there needs to be a 644 NAT at the edge of the network due to private addressing. 646 o If the network is dual-stack, there is still a need for NAT again 647 due to private addressing. 649 o If the network is deployed as IPv6-only, then there is a need for 650 mechanism such as NAT-PT. 652 Some are of the opinion that dual-stack network is most preferred 653 manner of introducing IPv6, until such time when there are no 654 IPv4-only nodes. Several questions arise like: what are the costs 655 involved in running a dual-stack network; will IPv4-only 656 implementations cease to appear in the marketplace; will the true 657 potential of IPv6 be realized on a dual-stack network; how do 658 protocols interact in a dual-stack network; are there known problems/ 659 limitations/failure modes; do we have enough experience running a 660 dual-stack network etc. 662 Intellectual Property Statement 664 The IETF takes no position regarding the validity or scope of any 665 intellectual property or other rights that might be claimed to 666 pertain to the implementation or use of the technology described in 667 this document or the extent to which any license under such rights 668 might or might not be available; neither does it represent that it 669 has made any effort to identify any such rights. Information on the 670 IETF's procedures with respect to rights in standards-track and 671 standards-related documentation can be found in BCP-11. Copies of 672 claims of rights made available for publication and any assurances of 673 licenses to be made available, or the result of an attempt made to 674 obtain a general license or permission for the use of such 675 proprietary rights by implementors or users of this specification can 676 be obtained from the IETF Secretariat. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights which may cover technology that may be required to practice 681 this standard. Please address the information to the IETF Executive 682 Director. 684 Full Copyright Statement 686 Copyright (C) The Internet Society (2003). All Rights Reserved. 688 This document and translations of it may be copied and furnished to 689 others, and derivative works that comment on or otherwise explain it 690 or assist in its implementation may be prepared, copied, published 691 and distributed, in whole or in part, without restriction of any 692 kind, provided that the above copyright notice and this paragraph are 693 included on all such copies and derivative works. However, this 694 document itself may not be modified in any way, such as by removing 695 the copyright notice or references to the Internet Society or other 696 Internet organizations, except as needed for the purpose of 697 developing Internet standards in which case the procedures for 698 copyrights defined in the Internet Standards process must be 699 followed, or as required to translate it into languages other than 700 English. 702 The limited permissions granted above are perpetual and will not be 703 revoked by the Internet Society or its successors or assignees. 705 This document and the information contained herein is provided on an 706 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 707 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 708 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 709 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 710 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 712 Acknowledgment 714 Funding for the RFC Editor function is currently provided by the 715 Internet Society.