idnits 2.17.1 draft-ietf-v6ops-natpt-to-exprmntl-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1131. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1108. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1115. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1121. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 draft header indicates that this document updates RFC2766, but the abstract doesn't seem to directly say this. It does mention RFC2766 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2766, updated by this document, for RFC5378 checks: 1997-12-29) -- 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 20, 2005) is 6763 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ipv6-node-requirements' is defined on line 995, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-3gpp-analysis' is defined on line 1000, but no explicit reference was found in the text == Unused Reference: 'I-D.satapati-v6ops-natpt-applicability' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'I-D.vanderpol-v6ops-translation-issues' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'I-D.elmalki-sipping-3gpp-translator' is defined on line 1061, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Downref: Normative reference to an Informational RFC: RFC 2663 ** Downref: Normative reference to an Informational RFC: RFC 3027 ** Downref: Normative reference to an Informational RFC: RFC 3314 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational draft: draft-ietf-ipv6-node-requirements (ref. 'I-D.ietf-ipv6-node-requirements') ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-3gpp-analysis (ref. 'I-D.ietf-v6ops-3gpp-analysis') -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group C. Aoun 3 Internet-Draft ZTE/ENST Paris 4 Updates: 2766 (if approved) E. Davies 5 Expires: April 23, 2006 Consultant 6 October 20, 2005 8 Reasons to Move NAT-PT to Experimental 9 draft-ietf-v6ops-natpt-to-exprmntl-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 23, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document discusses issues with the specific form of IPv6-IPv4 43 protocol translation mechanism implemented by the Network Address 44 Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These 45 issues are sufficiently serious that recommending RFC 2766 as a 46 general purpose transition mechanism is no longer desirable, and this 47 document recommends that the IETF should reclassify RFC 2766 from 48 Standards Track to Experimental status. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Issues Unrelated to DNS-ALG . . . . . . . . . . . . . . . . . 6 54 2.1. Issues with Protocols Embedding IP Addresses . . . . . . . 6 55 2.2. NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 7 56 2.3. NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 8 57 2.4. Loss of Information through Incompatible Semantics . . . . 8 58 2.5. NAT-PT and Fragmentation . . . . . . . . . . . . . . . . . 9 59 2.6. NAT-PT Interaction with SCTP and Multihoming . . . . . . . 10 60 2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 11 61 2.8. NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 12 62 3. Issues exacerbated by the Use of DNS-ALG . . . . . . . . . . . 12 63 3.1. Network Topology Constraints Implied by NAT-PT . . . . . . 12 64 3.2. Scalability and Single Point of Failure Concerns . . . . . 14 65 3.3. Issues with Lack of Address Persistence . . . . . . . . . 14 66 3.4. DoS Attacks on Memory and Address/Port Pools . . . . . . . 15 67 4. Issues Directly Related to Use of DNS-ALG . . . . . . . . . . 16 68 4.1. Address Selection Issues when Communicating with 69 Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . 16 70 4.2. Non-global Validity of Translated RR Records . . . . . . . 17 71 4.3. Inappropriate Translation of Responses to A Queries . . . 18 72 4.4. DNS-ALG and Multi-addressed Nodes . . . . . . . . . . . . 18 73 4.5. Limitations on Deployment of DNS Security Capabilities . . 18 74 5. Impact on IPv6 Application Development . . . . . . . . . . . . 19 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 77 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 83 Intellectual Property and Copyright Statements . . . . . . . . . . 25 85 1. Introduction 87 The Network Address Translator - Protocol Translator (NAT-PT) 88 document [RFC2766] defines a set of network-layer translation 89 mechanisms designed to allow nodes that only support IPv4 to 90 communicate with nodes that only support IPv6 during the transition 91 to the use of IPv6 in the Internet. 93 [RFC2766] specifies the basic NAT-PT in which only addresses are 94 translated and Network Address Port Translator - Protocol Translator 95 (NAPT-PT), which also translates transport identifiers, allowing for 96 greater economy of scarce IPv4 addresses. Protocol translation is 97 performed using the Stateless IP/ICMP Translation Algorithm (SIIT) 98 defined in [RFC2765]. In the following discussion, where the term 99 "NAT-PT" is used unqualified, the discussion applies to both basic 100 NAT-PT and NAPT-PT. "Basic NAT-PT" will be used if points apply to 101 the basic address-only translator. 103 A number of previous documents have raised issues with NAT-PT. This 104 document will summarize these issues, note several other issues 105 carried over from traditional IPv4 NATs, and identify some additional 106 issues that have not been discussed elsewhere. Where solutions to 107 the issues have been proposed, these are mentioned and any resulting 108 need for changes to the specification is identified. 110 Whereas NAT is seen as an ongoing capability that is needed to work 111 around the limited availability of globally unique IPv4 addresses, 112 NAT-PT has a different status as a transition mechanism for IPv6. As 113 such, NAT-PT should not be allowed to constrain the development of 114 IPv6 applications or impose limitations on future developments of 115 IPv6. 117 This document draws the conclusion that the technical and operational 118 difficulties resulting from these issues, especially the possible 119 future constraints on the development of IPv6 networks (see 120 Section 5), make it undesirable to recommend NAT-PT as described in 121 [RFC2766] as a general purpose transition mechanism for 122 intercommunication between IPv6 networks and IPv4 networks. 124 Although the [RFC2766] form of packet translation is not generally 125 applicable, it is likely that in some circumstances a node that can 126 only support IPv4 will need to communicate with a node that can only 127 support IPv6; this needs a translation mechanism of some kind. 128 Although this may be better carried out by an application-level proxy 129 or transport-layer translator, there may still be scenarios in which 130 a (possibly restricted) version of NAT-PT can be a suitable solution; 131 accordingly, this document recommends that the IETF should reclassify 132 RFC2766 from Standards Track to Experimental status. 134 The following documents relating directly to NAT-PT have been 135 reviewed while drafting this document: 137 o Network Address Translation - Protocol Translation (NAT-PT) 138 [RFC2766] 139 o Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765] 140 o NAT-PT applicability statement [I-D.satapati-v6ops-natpt- 141 applicability] 142 o Issues with NAT-PT DNS ALG in RFC2766 [I-D.durand-natpt-dns-alg- 143 issues] 144 o NAT-PT DNS ALG solutions [I-D.hallin-natpt-dns-alg-solutions] 145 o NAT-PT Security Considerations [I-D.okazaki-v6ops-natpt-security] 146 o Issues when translating between IPv4 and IPv6 [I-D.vanderpol- 147 v6ops-translation-issues] 148 o IPv6-IPv4 Translation mechanism for SIP-based services in Third 149 Generation Partnership Project (3GPP) Networks [I-D.elmalki- 150 sipping-3gpp-translator] 151 o Analysis on IPv6 Transition in 3GPP Networks [I-D.ietf-v6ops-3gpp- 152 analysis] 153 o Considerations for Mobile IP Support in NAT-PT [I-D.lee-v6ops- 154 natpt-mobility] 155 o An IPv6/IPv4 Multicast Translator based on Internet Group 156 Management Protocol / Multicast Listener Discovery (IGMP/MLD) 157 Proxying (mtp) [I-D.tsuchiya-mtp] 158 o An IPv4 - IPv6 multicast gateway [I-D.venaas-mboned-v4v6mcastgw] 159 o Scalable mNAT-PT Solution [I-D.park-scalable-multi-natpt] 161 Because the majority of the documents containing discussions of the 162 issues are Internet Drafts which are unlikely to become RFCs, the 163 issues are summarized here to avoid the need for normative 164 references. 166 Some additional issues can be inferred from corresponding issues 167 known to exist in 'traditional' IPv4 NATs. The following documents 168 are relevant: 170 o Protocol Complications with the IP Network Address Translator 171 [RFC3027] 172 o IP Network Address Translator (NAT) Terminology and Considerations 173 [RFC2663] 175 There is some ambiguity in [RFC2766] about whether the Application 176 Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this document) 177 is an integral and mandatory part of the specification. The 178 ambiguity arises mainly from the first section of the applicability 179 section (Section 8), which appears to imply that 'simple' use of 180 NAT-PT could avoid the use of the DNS-ALG. 182 This is important because a number of the major issues arise from the 183 interactions between DNS and NAT-PT. However, detailed inspection of 184 [RFC2766] shows that the 'simple' case has not been worked out and it 185 is unclear how information about the address translation could be 186 passed to the hosts in the absence of the DNS-ALG. Therefore, this 187 document assumes that the DNS-ALG is an integral part of NAT-PT; 188 accordingly, issues with the DNS-ALG must be considered as issues for 189 the whole specification. 191 Note that issues not specifically related to the use of the DNS-ALG 192 will apply to any network-layer translation scheme, including any 193 based on the SIIT algorithm [RFC2765]. In the event that new forms 194 of translator are developed as alternatives to NAT-PT, the generic 195 issues relevant to all IPv6-IPv4 translators should be borne in mind. 197 Issues raised with IPv6-IPv4 translators in general and NAT-PT in 198 particular can be categorized as follows: 200 o Issues that are independent of the use of a DNS-ALG and are, 201 therefore, applicable to any form of IPv6-IPv4 translator: 202 * Disruption of all protocols that embed IP addresses (and/or 203 ports) in packet payloads or apply integrity mechanisms using 204 IP addresses (and ports). 205 * Inability to re-direct traffic for protocols that lack 206 demultiplexing capabilities or are not built on top of specific 207 transport-layer protocols in situations where one NAPT-PT is 208 translating for multiple IPv6 hosts. 209 * Requirement for applications to use keep alive mechanisms to 210 workaround connectivity issues caused by premature NAT-PT state 211 timeout. 212 * Loss of information due to incompatible semantics between IPv4 213 and IPv6 versions of headers and protocols. 214 * Need for additional state and/or packet reconstruction in 215 NAPT-PT translators dealing with packet fragmentation. 216 * Interaction with SCTP and multihoming. 217 * Need for NAT-PT to act as proxy for correspondent node when 218 IPv6 node is mobile, with consequent restrictions on mobility. 219 * NAT-PT not being able to handle multicast traffic. 221 o Issues that are exacerbated by the use of a DNS-ALG and are, 222 therefore, also applicable to any form of IPv6-IPv4 translator: 223 * Constraints on network topology. 224 * Scalability concerns together with introduction of single point 225 of failure and security attack nexus. 226 * Lack of address mapping persistence: Some applications require 227 address retention between sessions. The user traffic will be 228 disrupted if a different mapping is used. The use of the DNS- 229 ALG to create address mappings with limited lifetimes means 230 that applications must start using the address shortly after 231 the mapping is created, as well as keeping it alive once they 232 start using it. 233 * Creation of a DoS threat relating to exhaustion of memory and 234 address/port pool resources on the translator. 236 o Issues that result from the use of a DNS-ALG and are, therefore, 237 specific to NAT-PT as defined in [RFC2766]: 238 * Address selection issues when either the internal or external 239 hosts implement both IPv4 and IPv6. 240 * Restricted validity of translated DNS records: a translated 241 record may be forwarded to an application that cannot use it. 242 * Inappropriate translation of responses to A queries from IPv6 243 nodes. 244 * Address selection issues and resource consumption in DNS-ALG 245 with multi-addressed nodes. 246 * Limitations on DNS security capabilities when using DNS-ALG. 248 Section 2, Section 3 and Section 4 discuss these groups of issues. 249 Section 5 examines the consequences of deploying NAT-PT for 250 application developers and the long term effects of NAT-PT (or any 251 form of generally deployed IPv6-IPv4 translator) on the further 252 development of IPv6. 254 The terminology used in this document is defined in [RFC2663], 255 [RFC2766], and [RFC3314]. 257 2. Issues Unrelated to DNS-ALG 259 2.1. Issues with Protocols Embedding IP Addresses 261 It is well known from work on IPv4 NATs (see Section 8 of [RFC2663] 262 and [RFC3027]) that the large class of protocols that embed numeric 263 IP addresses in their payloads either cannot work through NATs or 264 require specific ALGs as helpers to translate the payloads in line 265 with the address and port translations. The same set of protocols 266 cannot pass through NAT-PT. The problem is exacerbated because the 267 IPv6 and IPv4 addresses are of different lengths so that packet 268 lengths as well as contents are altered. [RFC2766] describes the 269 consequences as part of the description of the FTP ALG: similar 270 workarounds are needed for all protocols with embedded IP addresses 271 that run over TCP transports. 273 The issues raised in Sections 2 and 3 of [RFC2663], relating to 274 authentication and encryption with NAT, are also applicable to 275 NAT-PT. 277 Implementing a suite of ALGs requires that NAT-PT equipment includes 278 the logic for each of the relevant protocols. Most of these 279 protocols are continuously evolving, requiring continual and 280 coordinated updates of the ALGs to keep them in step. 282 Assuming that the NAT-PT contains a co-located ALG for one of the 283 relevant protocols, the ALG could replace the embedded IP addresses 284 and ports. However, this replacement can only happen if no 285 cryptographic integrity mechanism is used and the protocol messages 286 are sent in the clear (i.e., not encrypted). 288 A possible workaround relies on the NAT-PT being party to the 289 security association used to provide authentication and/or 290 encryption. NAT-PT would then be aware of the cryptographic 291 algorithms and keys used to secure the traffic. It could then modify 292 and re-secure the packets; this would certainly complicate network 293 operations and provides additional points of security vulnerability. 295 Unless UDP encapsulation is used for IPsec [RFC3498], traffic using 296 IPsec AH (in transport and tunnel mode) and IPsec ESP (in transport 297 mode) is unable to be carried through NAT-PT without terminating the 298 security associations on the NAT-PT, due to their usage of 299 cryptographic integrity protection. 301 A related issue with DNS security is discussed in Section 4.5. 303 2.2. NAPT-PT Redirection Issues 305 Section 4.2 of [RFC3027] discusses problems specific to RSVP and 306 NATs, one of which is actually a more generic problem for all port 307 translators. When several end-hosts are using a single NAPT-PT box, 308 protocols that do not have a demultiplexing capability similar to 309 transport-layer port numbers may be unable to work through NAPT-PT 310 (and any other port translator) because there is nothing for NAPT-PT 311 to use to identify the correct binding. 313 This type of issue affects IPsec encrypted packets where the 314 transport port is not visible (although it might be possible to use 315 the Security Parameter Index (SPI) as an alternative demultiplexer) 316 and protocols, such as RSVP, which are carried directly in IP 317 datagrams rather than using a standard transport-layer protocol such 318 as TCP or UDP. In the case of RSVP, packets going from the IPv4 319 domain to the IPv6 domain do not necessarily carry a suitable 320 demultiplexing field, because the port fields in the flow identifier 321 and traffic specifications are optional. 323 Several ad hoc workarounds could be used to solve the demultiplexing 324 issues, however in most cases these solutions are not documented 325 anywhere, which could lead to non-deterministic, undesirable behavior 326 (for example, such workarounds often assume particular network 327 topologies, etc., in order to function correctly; if the assumptions 328 are not met in a deployment, the workaround may not work as 329 expected). 331 This issue is closely related to the fragmentation issue described in 332 Section 2.5. 334 2.3. NAT-PT Binding State Decay 336 NAT-PT will generally use dynamically created bindings to reduce the 337 need for IPv4 addresses both for basic NAT-PT and NAPT-PT. Both 338 basic NAT-PT and NAPT-PT use soft state mechanisms to manage the 339 address and, in the case of NAPT-PT, port pools used for dynamically 340 created address bindings. This allows all types of NAT-PT box to 341 operate autonomously without requiring clients to signal, either 342 implicitly or explicitly, that a binding is no longer required. In 343 any case, without soft state timeouts, network and application 344 unreliability would inevitably lead to leaks, eventually causing 345 address or port pool exhaustion. 347 For a dynamic binding to persist for longer than the soft state 348 timeout, packets must be sent periodically from one side of the 349 NAT-PT to the other (the direction is not specified by the NAT-PT 350 specification). If no packets are sent in the proper direction, the 351 NAT-PT binding will not be refreshed and the application connection 352 will be broken. Hence, all applications need to maintain their 353 NAT-PT bindings during long idle periods by incorporating a keep- 354 alive mechanism, which may not be possible for legacy systems. 356 Also, [RFC2766] does not specify how to choose timeouts for bindings. 357 As is discussed in [RFC2663] for traditional NATs, selecting suitable 358 values is a matter of heuristics, and coordinating with application 359 expectations may be impossible. 361 2.4. Loss of Information through Incompatible Semantics 363 NAT-PT reuses the SIIT header and protocol translations defined in 364 [RFC2765]. Mismatches in semantics between IPv4 and IPv6 versions 365 can lead to loss of information when packets are translated. Three 366 issues arising from this are: 368 o There is no equivalent in IPv4 for the flow label field of the 369 IPv6 header. Hence, any special treatment of packets based on 370 flow label patterns cannot be propagated into the IPv4 domain. 372 o IPv6 extension headers provide flexibility for improvements in the 373 IP protocol suite in future. In the future, new headers may be 374 defined that do not have equivalents in IPv4. In practice, some 375 existing extensions such as routing headers and mobility 376 extensions are not translatable. 377 o As described in Section 2.2 of [I-D.satapati-v6ops-natpt- 378 applicability], there are no equivalents in IPv6 for some ICMP(v4) 379 messages, while for others (notably the 'Parameter Problem' 380 messages) the semantics are not equivalent. Translation of such 381 messages may lead to loss of information. However, this issue may 382 not be very severe because the error messages relate to packets 383 that have been translated by NAT-PT rather than arbitrary packets. 384 If the NAT-PT is functioning correctly, there is, for example, no 385 reason why IPv6 packets with unusual extension headers or options 386 should be generated. This case is cited in [I-D.satapati-v6ops- 387 natpt-applicability] as an example where the IPv6 error has no 388 equivalent in IPv4 resulting in lost information. 390 Loss of information in any of these cases could be a constraint to 391 certain applications. 393 A related matter concerns the propagation of the Differentiated 394 Services Code Point (DSCP). NAT-PT and SIIT simply copy the DSCP 395 field when translating packets. Accordingly, the IPv4 and IPv6 396 domains must have equivalent Per-Hop Behaviors for the same code 397 point, or alternative means must be in place to translate the DSCP 398 between domains. 400 2.5. NAT-PT and Fragmentation 402 As mentioned in [RFC3027], simple port translators are unable to 403 translate packet fragments, other than the first, from a fragmented 404 packet, because subsequent fragments do not contain the port number 405 information. 407 This means that generally fragmentation cannot be allowed for any 408 traffic that traverses a NAPT-PT. One attempted workaround requires 409 the NAPT-PT to maintain state about fragmented packets in transit. 410 This is not a complete solution because fragment misordering could 411 lead to the first fragment appearing at the NAPT-PT after later 412 fragments. The NAPT-PT would then not have the information needed to 413 translate the fragments received before the first. 415 Although it would not be expected in normal operation, NAPT-PT needs 416 to be proofed against receiving short first fragments that don't 417 contain the transport port numbers. Note that such packets are a 418 problem for IPv6 stateful packet inspection. The current 419 specifications of IPv6 do not mandate (1) any minimum packet size 420 beyond the need to carry the unfragmentable part (which doesn't 421 include the transport port numbers) or (2) reassembly rules to 422 minimize the effects of overlapping fragments. Thus, IPv6 is open to 423 the sort of attacks described in [RFC1858] and [RFC3128]. 425 An additional concern arises when a fragmented IPv4 UDP packet, which 426 does not have a transport-layer checksum, traverses any type of 427 NAT-PT box. As described in [RFC2766], the NAT-PT has to reconstruct 428 the whole packet so that it can calculate the checksum needed for the 429 translated IPv6 packet. This can result in significant delay to the 430 packet, especially if it has to be re-fragmented before transmission 431 on the IPv6 side. 433 If NAT-PT boxes reassembled all incoming fragmented packets (both 434 from the IPv4 and IPv6 directions) in the same way as they have to do 435 for unchecksummed IPv4 UDP packets, this would be a solution to the 436 first problem. The resource cost would be considerable apart from 437 the potential delay problem if the outgoing packet has to be re- 438 fragmented. In any case, fragmentation would mean that the NAT-PT 439 would consume extra memory and CPU resources, making the NAT-PT even 440 less scalable (see Section 3.2). 442 Packet reassembly in a NAT-PT box also opens up the possibility of 443 various fragment-related security attacks. Some of these are 444 analogous to attacks identified for IPv4. Of particular concern is a 445 DoS attack based on sending large numbers of small fragments without 446 a terminating last fragment, which would potentially overload the 447 reconstruction buffers and consume large amounts of CPU resources. 449 2.6. NAT-PT Interaction with SCTP and Multihoming 451 The Stream Control Transmission Protocol (SCTP) [RFC2960] is a 452 transport protocol, which has been standardized since SIIT was 453 specified. SIIT does not explicitly cover translation of SCTP, but 454 SCTP uses transport port numbers in the same way as UDP and TCP so 455 that similar techniques could be used. 457 However, SCTP also supports multihoming. During connection setup, 458 SCTP control packets carry embedded addresses that would have to be 459 translated. This would also require that the types of the options 460 fields in the SCTP control packets be changed with consequent changes 461 to packet length; the transport checksum would also have to be 462 recalculated. The ramifications of multihoming as it might interact 463 with NAT-PT have not been fully explored. Because of the 'chunked' 464 nature of data transfer, it does not appear that state would have to 465 be maintained to relate packets transmitted using the different IP 466 addresses associated with the connection. 468 Even if these technical issues can be overcome, using SCTP in a 469 NAT-PT environment may effectively nullify the multihoming advantages 470 of SCTP if all the connections run through the same NAT-PT. The 471 consequences of running a multihomed network with separate NAT-PT 472 boxes associated with each of the 'homes' have not been fully 473 explored, but one issue that will arise is described in Section 4.4. 474 SCTP will need an associated 'ALG' -- actually a Transport Layer 475 Gateway -- to handle the packet payload modifications. If it turns 476 out that state is required, the state would have to distributed and 477 synchronized across several NAT-PT boxes in a multihomed environment. 479 SCTP running through NAT-PT in a multihomed environment is also 480 incompatible with IPsec as described in Section 2.1. 482 2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 484 As discussed in [I-D.lee-v6ops-natpt-mobility], it is not possible to 485 propagate Mobile IPv6 control messages into the IPv4 domain. 486 According to the IPv6 Node Requirements [I-D.ietf-ipv6-node- 487 requirements], IPv6 nodes should normally be prepared to support the 488 route optimization mechanisms needed in a correspondent node. If 489 communications from an IPv6 mobile node are traversing a NAT-PT, the 490 destination IPv4 node will certainly not be able to support the 491 correspondent node features needed for route optimization. 493 This can be resolved in two ways: 495 o The NAT-PT can discard messages and headers relating to changes of 496 care-of addresses, including reverse routing checks. 497 Communications with the mobile node will continue through the home 498 agent without route optimization. This is clearly sub-optimal, 499 but communication should remain possible. 500 o Additional functionality could be implemented in the NAT-PT to 501 allow it to function as a proxy correspondent node for all IPv4 502 nodes for which it has bindings. This scheme adds considerably to 503 the complexity of NAT-PT. Depending on the routability of the 504 IPv6 PREFIX used for translated IPv4 addresses, it may also limit 505 the extent of mobility of the mobile node: all communications to 506 the IPv4 destination have to go through the same NAT-PT, even if 507 the mobile node moves to a network that does not have direct IPv6 508 connectivity with the NAT-PT. 510 In both cases, the existing NAT-PT specification would need to be 511 extended to deal with IPv6 mobile nodes, and neither is a fully 512 satisfactory solution. 514 2.8. NAT-PT and Multicast 516 SIIT [RFC2765] cannot handle translation of multicast packets and 517 NAT-PT does not discuss a way to map multicast addresses between IPv4 518 and IPv6. Some separate work has been done to provide an alternative 519 mechanism to handle multicast. This uses a separate gateway that 520 understands some or all of the relevant multicast control and routing 521 protocols in each domain. This work has not been carried through 522 into standards as yet. 524 A basic mechanism, which involves only IGMP on the IPv4 side and MLD 525 on the IPv6 side, is described in 'An IPv6/IPv4 Multicast Translator 526 based on IGMP/MLD Proxying (mtp)' [I-D.tsuchiya-mtp]. A more 527 comprehensive approach, which includes proxying of the multicast 528 routing protocols, is described in 'An IPv4 - IPv6 multicast gateway' 529 [I-D.venaas-mboned-v4v6mcastgw]. Both approaches have several of the 530 issues described in this section, notably issues with embedded 531 addresses. 533 [I-D.okazaki-v6ops-natpt-security] identifies the possibility of a 534 multiplicative reflection attack if the NAT-PT can be spoofed into 535 creating a binding for a multicast address. This attack would be 536 very hard to mount because routers should not forward packets with 537 multicast addresses in the source address field. However, it 538 highlights the possibility that a naively implemented DNS-ALG could 539 create such bindings from spoofed DNS responses since [RFC2766] does 540 not mention the need for checks on the types of addresses in these 541 responses. 543 The issues for NAT-PT and multicast reflect the fact that NAT-PT is 544 at best a partial solution. Completing the translation solution to 545 cater for multicast traffic is likely to carry a similar set of 546 issues to the current unicast NAT-PT and may open up significant 547 additional security risks. 549 3. Issues exacerbated by the Use of DNS-ALG 551 3.1. Network Topology Constraints Implied by NAT-PT 553 Traffic flow initiators in a NAT-PT environment are dependent on the 554 DNS-ALG in the NAT-PT to provide the mapped address needed to 555 communicate with the flow destination on the other side of the 556 NAT-PT. Whether used for flows initiated in the IPv4 domain or the 557 IPv6 domain, the NAT-PT has to be on the path taken by the DNS query 558 sent by the flow initiator to the relevant DNS server; otherwise, the 559 DNS query will not be modified and the response type would not be 560 appropriate. 562 The implication is that the NAT-PT box also has to be the default 563 IPv6 router for the site so that the DNS-ALG is able to examine all 564 DNS requests made over IPv6. On sites with both IPv6 and dual-stack 565 nodes, this will result in all traffic flowing through the NAT-PT 566 with consequent scalability concerns. 568 These constraints are described in more detail in [I-D.durand-natpt- 569 dns-alg-issues]. 571 [I-D.hallin-natpt-dns-alg-solutions] proposes a solution for flows 572 initiated from the IPv6 domain, but it appears that this solution 573 still has issues. 575 For IPv6-only clients, the solution requires the use of a DNS server 576 in the IPv4 domain accessed via an IPv6 address which uses the NAT-PT 577 PREFIX (see [RFC2766]). Queries to this server would necessarily 578 pass through the NAT-PT. Dual-stack hosts would use a separate DNS 579 server accessed through a normal IPv6 address. This removes the need 580 for the NAT-PT box to be the default IPv6 gateway for the domain. 582 The primary proposal suggests that the IPv6-only clients should use 583 this DNS server for all queries. This is expensive on NAT-PT 584 resources because requests relating to hosts with native IPv6 585 addresses would also use the NAT-PT DNS-ALG. 587 The alternate suggestion to reduce this burden appears to be flawed: 588 if IPv6-only clients are provided with a list of DNS servers 589 including both the server accessed via NAT-PT and server(s) accessed 590 natively via IPv6, the proposal suggests that the client could avoid 591 using NAT-PT for hosts that have native IPv6 addresses. 593 Unfortunately for the alternate suggestion, there is no a priori way 594 in which the initiator can decide which DNS server to use for a 595 particular query. In the event that the initiator makes the wrong 596 choice, the DNS query will return an empty list rather than failing 597 to respond. With standard DNS logic, the initiator will not try 598 alternative DNS servers because it has received a response. This 599 means that the solution would consist of always using DNS servers 600 having the NAT-PT prefix. This imposes the burden of always 601 requiring DNS RR [RFC1035] translation. 603 For flows initiated from the IPv4 network, the proposal recommends 604 that the advertised DNS servers for the IPv6 network would have the 605 IPv4 address of the NAT-PT. Again there is no deterministic way to 606 choose the correct DNS server for each query resulting in the same 607 issues as were raised for flows initiated from the IPv6 domain. 609 Although the engineering workaround, just described, provides a 610 partial solution to the topology constraints issue, it mandates that 611 DNS queries and responses should still go through a NAT-PT even if 612 there would normally be no reason to do so. This mandatory passage 613 through the NAT-PT for all DNS requests will exacerbate the other 614 DNS-related issues discussed in Section 3.4 and Section 4.1. 616 3.2. Scalability and Single Point of Failure Concerns 618 As with traditional NAT, NAT-PT is a bottleneck in the network with 619 significant scalability concerns and the anchoring of flows to a 620 particular NAT-PT makes the NAT-PT a potential single point of 621 failure in the network. The addition of the DNS-ALG in NAT-PT 622 further increases the scalability concerns. 624 Solutions to both problems have been envisaged using collections of 625 cooperating NAT-PT boxes, but such solutions require coordination and 626 state synchronization, which has not yet been standardized and again 627 adds to the functional and operational complexity of NAT-PT. One 628 such solution is described in [I-D.park-scalable-multi-natpt]. 630 As with traditional NAT, the concentration of flows through NAT-PT 631 and the legitimate modification of packets in the NAT-PT make NAT-PTs 632 enticing targets for security attacks. 634 3.3. Issues with Lack of Address Persistence 636 Using the DNS-ALG to create address bindings requires that the 637 application uses the translated address returned by the DNS query 638 before the NAT-PT binding state is timed out (see Section 2.3). 639 Applications will not normally be aware of this constraint, which may 640 be different from the existing lifetime of DNS query responses. This 641 could lead to "difficult to diagnose" problems with applications. 643 Additionally, the DNS-ALG needs to determine the initial lifetime of 644 bindings that it creates. As noted in Section 2.3, this may need to 645 be determined heuristically. The DNS-ALG does not know which 646 protocol the mapping is to be used for, and so needs another way to 647 determine the initial lifetime. This could be tied to the DNS 648 response lifetime, but that might open up additional DoS attack 649 possibilities if very long validities are allowed. Also, the 650 lifetime should be adjusted once the NAT-PT determines which protocol 651 is being used with the binding. 653 As with traditional NATs (see Section 2.5 of [RFC3027], NAT-PT will 654 most likely break applications that require address mapping to be 655 retained across contiguous sessions. These applications require the 656 IPv4 to IPv6 address mapping to be retained between sessions so the 657 same mapped address may be reused for subsequent session 658 interactions. NAT-PT cannot know this requirement and may reassign 659 the previously used mapped address to different hosts between 660 sessions. 662 Trying to keep NAT-PT from discarding an address mapping would 663 require either a NAT-PT extension protocol that would allow the 664 application to request the NAT-PT device to retain the mappings, or 665 an extended ALG (which has all the issues discussed in Section 2.1) 666 that can interact with NAT-PT to keep the address mapping from being 667 discarded after a session. 669 3.4. DoS Attacks on Memory and Address/Port Pools 671 As discussed in Section 2.3, a NAT-PT may create dynamic NAT 672 bindings, each of which consumes memory resources as well as an 673 address (or port if NAPT-PT is used) from an address (or port) pool. 674 A number of documents, including [RFC2766] and [I-D.okazaki-v6ops- 675 natpt-security] discuss possible denial of service (DoS) attacks on 676 basic NAT-PT and NAPT-PT that result in resource depletion associated 677 with address and port pools. NAT-PT does not specify any 678 authentication mechanisms; thus, an attacker may be able to create 679 spurious bindings by spoofing addresses in packets sent through 680 NAT-PT. The attack is more damaging if the attacker is able to spoof 681 protocols with long binding timeouts (typically used for TCP). 683 The use of the DNS-ALG in NAT-PT introduces another vulnerability 684 that can result in resource depletion. The attack identified in 685 [I-D.durand-natpt-dns-alg-issues] exploits the use of DNS queries 686 traversing NAT-PT to create dynamic bindings. Every time a DNS query 687 is sent through the NAT-PT, the NAT-PT may create a new basic NAT-PT 688 or NAPT-PT binding without any end-host authentication or 689 authorization mechanisms. This behavior could lead to a serious DoS 690 attack on both memory and address or port pools. Address spoofing is 691 not required for this attack to be successful. 693 [I-D.hallin-natpt-dns-alg-solutions] proposes to mitigate the DoS 694 attack by using Access Control Lists (ACLs) and static binds, which 695 increases the operational cost and may not always be practical. 697 The ideal mitigation solution would be to disallow dynamically 698 created binds until authentication and authorization of the end-host 699 needing the protocol translation has been carried out. This would 700 require that the proper security infrastructure be in place to 701 support the authentication and authorization, which increases the 702 network operational complexity. 704 4. Issues Directly Related to Use of DNS-ALG 706 4.1. Address Selection Issues when Communicating with Dual-Stack End- 707 Hosts 709 [I-D.durand-natpt-dns-alg-issues] discusses NAT-PT DNS-ALG issues 710 with regard to address selection. As specified in [RFC2766], the 711 DNS-ALG returns AAAA resource records (RRs) from two possible sources 712 to the IPv6 host that has made an AAAA DNS query. 714 If the query relates to a dual-stack host, the query will return both 715 the native IPv6 address(es) and the translated IPv4 address(es) in 716 AAAA RRs. Without additional information, the IPv6 host address 717 selection may pick a translated IPv4 address instead of selecting the 718 more appropriate native IPv6 address. Under some circumstances, the 719 address selection algorithms [RFC3484] will always prefer the 720 translated address over the native IPv6 address; this is obviously 721 undesirable. 723 [I-D.hallin-natpt-dns-alg-solutions] proposes a solution that 724 involves modification to the NAT-PT specification intended to return 725 only the most appropriate address(es) to an IPv6 capable host: 727 o When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT 728 will forward the query to the DNS server in the IPv4 domain 729 unchanged, but using IPv4 transport: 730 * If the authoritative DNS server has one or more AAAA records, 731 it returns them. The DNS-ALG then forwards this response to 732 the IPv6 host and does not send an A query as the standard 733 NAT-PT would do. 734 * Otherwise, if the DNS server does not understand the AAAA query 735 or has no AAAA entry for the host, it will return an error. 736 The NAT-PT DNS-ALG will intercept the error or empty return and 737 send an A query for the same host. If this query returns an 738 IPv4 address, the ALG creates a binding and synthesizes a 739 corresponding AAAA record, which it sends back to the IPv6 740 host. 742 o The NAT-PT thus forwards the result of the first successful DNS 743 response back to the end-host or an error if neither succeeds. 744 Consequently, only AAAA RRs from one source will be provided 745 instead of two as specified in [RFC2766], and it will contain the 746 most appropriate address for a dual-stack or IPv6-only querier. 748 There is, however, still an issue with the proposed solution: 750 o The DNS client may timeout the query if it doesn't receive a 751 response in time. This is more likely because the NAT-PT may have 752 to make two separate, sequential queries of which the client is 753 not aware. It may be possible to reduce the response time by 754 sending the two queries in parallel and ignoring the result of the 755 A query if the AAAA returns one or more addresses. However, it is 756 still necessary to delay after receiving the first response to 757 determine if a second is coming, which may still trigger the DNS 758 client timeout. 760 Unfortunately, the two queries cannot be combined in a single DNS 761 request (all known DNS servers only process a single DNS query per 762 request message because of difficulties expressing authoritativeness 763 for arbitrary combinations of requests). 765 An alternative solution would be to allow the IPv6 host to have, 766 within its address selection policies, the NAT-PT PREFIX [RFC2766] 767 used and to assign it a low selection priority. This solution 768 requires an automatic configuration of the NAT-PT PREFIX as well as 769 its integration within the address selection policies. The simplest 770 way to integrate this automatic configuration would be through 771 configuration file download (in case the host or Dynamic Host 772 Configuration Protocol for IPv6 (DHCPv6) server did not support 773 vendor options, to avoid standardization effort on the NAT-PT PREFIX 774 option). This solution does not require any modification to the 775 NAT-PT specification. 777 Neither of these solutions resolves a second issue related to address 778 selection that is identified in [I-D.durand-natpt-dns-alg-issues]. 779 Applications have no way of knowing that the IPv6 address returned 780 from the DNS-ALG is not a 'real' IPv6 address, but a translated IPv4 781 address. The application may therefore be led to believe that it has 782 end-to-end IPv6 connectivity with the destination. As a result, the 783 application may use IPv6-specific options that are not supported by 784 NAT-PT. This issue is closely related to the issue described in 785 Section 4.2 and the discussion in Section 5. 787 4.2. Non-global Validity of Translated RR Records 789 Some applications propagate information records retrieved from DNS to 790 other applications. The published semantics of DNS imply that the 791 results will be consistent to any user for the duration of the 792 attached lifetime. RR records translated by NAT-PT violate these 793 semantics because the retrieved addresses are only usable for 794 communications through the translating NAT-PT. 796 Applications that pass on retrieved DNS records to other applications 797 will generally assume that they can rely on the passed on addresses 798 to be usable by the receiving application. This may not be the case 799 if the receiving application is on another node, especially if it is 800 not in the domain served by the NAT-PT that generated the 801 translation. 803 4.3. Inappropriate Translation of Responses to A Queries 805 Some applications running on dual-stack nodes may wish to query the 806 IPv4 address of a destination. If the resulting A query passes 807 through the NAT-PT DNS-ALG, the DNS-ALG will translate the response 808 inappropriately into a AAAA record using a translated address. This 809 happens because the DNS-ALG specified in [RFC2766] operates 810 statelessly and hence has no memory of the IPv6 query that induced 811 the A request on IPv4 side. The default action is to translate the 812 response. 814 The specification of NAT-PT could be modified to maintain minimal 815 state about queries passed through the DNS-ALG, and hence to respond 816 correctly to A queries as well as AAAA queries. 818 4.4. DNS-ALG and Multi-addressed Nodes 820 Many IPv6 nodes, especially in multihomed situations but also in 821 single homed deployments, can expect to have multiple global 822 addresses. The same may be true for multihomed IPv4 nodes. 823 Responses to DNS queries for these nodes will normally contain all 824 these addresses. Since the DNS-ALG in the NAT-PT has no knowledge 825 which of the addresses can or will be used by the application issuing 826 the query, it is obliged to translate all of them. 828 This could be a significant drain on resources in both basic NAT-PT 829 and NAPT-PT, as bindings will have to be created for each address. 831 When using SCTP in a multihomed network, the problem is exacerbated 832 if multiple NAT-PTs translate multiple addresses. Also, it is not 833 clear that SCTP will actually look up all the destination IP 834 addresses via DNS so that bindings may not be in place when packets 835 arrive. 837 4.5. Limitations on Deployment of DNS Security Capabilities 839 Secure DNS (DNSSEC) [I-D.ietf-dnsext-dnssec-intro] uses public key 840 cryptographic signing to authenticate DNS responses. The DNS-ALG 841 modifies DNS query responses traversing the NAT-PT in both directions 842 which would invalidate the signatures as (partially) described in 843 Section 7.5 of [RFC2766]. 845 Workarounds have been proposed, such as making the DNS-ALG behave 846 like a secure DNS server. This would need to be done separately for 847 both the IPv6 and IPv4 domains. This is operationally very complex 848 and there is a risk that the server could be mistaken for a 849 conventional DNS server. The NAT-PT specification would have to be 850 altered to implement any such workaround. 852 Hence DNSSEC is not deployable in domains that use NAT-PT as 853 currently specified. Widespread deployment of NAT-PT would become a 854 serious obstacle to the large scale deployment of DNSSEC. 856 5. Impact on IPv6 Application Development 858 One of the major design goals for IPv6 is to restore the end-to-end 859 transparency of the Internet. Therefore, because IPv6 may be 860 expected to remove the need for NATs and similar impediments to 861 transparency, developers creating applications to work with IPv6 may 862 be tempted to assume that the complex expedients that might have been 863 needed to make the application work in a 'NATted' IPv4 environment 864 are not required. 866 Consequently, some classes of applications (e.g., peer-to-peer) that 867 would need special measures to manage NAT traversal, including 868 special encapsulations, attention to binding lifetime, and provision 869 of keepalives, may build in assumptions on whether IPv6 is being used 870 or not. Developers would also like to exploit additional 871 capabilities of IPv6 not available in IPv4. 873 NAT-PT as specified in [RFC2766] is intended to work autonomously and 874 be transparent to applications. Therefore, there is no way for 875 application developers to discover that a path contains a NAT-PT. 877 If NAT-PT is deployed, applications that have assumed a NAT-free IPv6 878 environment may break when the traffic passes through a NAT-PT. This 879 is bad enough, but requiring developers to include special 880 capabilities to work around what is supposed to be a temporary 881 transition 'aid' is even worse. Finally, deployment of NAT-PT is 882 likely to inhibit the development and use of additional IPv6 883 capabilities enabled by the flexible extension header system in IPv6 884 packets. 886 Some of these deleterious effects could possibly be alleviated if 887 applications could discover the presence of NAT-PT boxes on paths in 888 use, allowing the applications to take steps to workaround the 889 problems. However, requiring applications to incorporate extra code 890 to workaround problems with a transition aid still seems to be a very 891 bad idea: the behavior of the application in native IPv6 and NAT-PT 892 environments would be likely to be significantly different. 894 6. Security Considerations 896 This document summarizes security issues related to the NAT-PT 897 [RFC2766] specification. Security issues are discussed in various 898 sections: 900 o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and 901 IPsec ESP transport mode are broken by NAT-PT (when IPSEC UDP 902 encapsulation is not used [RFC3498]); and authentication and 903 encryption are generally incompatible with NAT-PT. 904 o Section 2.5 discusses possible fragmentation related security 905 attacks on NAT-PT. 906 o Section 2.8 discusses security issues related to multicast 907 addresses and NAT-PT. 908 o Section 3.3 highlights that NAT-PT is an enticing nexus for 909 security attacks. 910 o Section 3.4 discusses possible NAT-PT DoS attacks on both memory 911 and address/port pools. 912 o Section 4.5 discusses why NAT-PT is incompatible with DNSSEC 913 [RFC2535] and how deployment of NAT-PT may inhibit deployment of 914 DNSSEC. 916 7. IANA Considerations 918 There are no IANA considerations defined in this document. 920 8. Conclusion 922 This document has discussed a number of significant issues with 923 NAT-PT as defined in [RFC2766]. From a deployment perspective, 3GPP 924 networks are currently the only 'standardised' scenario where an 925 IPv6-only host communicates with an IPv4-only host using NAT-PT as 926 described in the 3GPP IPv6 transition analysis [I-D.ietf-v6ops-3gpp- 927 analysis], but NAT-PT has seen some limited usage for other purposes. 929 Although some of the issues identified with NAT-PT appear to have 930 solutions, many of the solutions required significant alterations to 931 the existing specification and would be likely to increase 932 operational complexity. Even if these solutions were applied, we 933 have shown that NAT-PT still has significant, irresolvable issues and 934 appears to have limited applicability. The potential constraints on 935 the development of IPv6 applications described in Section 5 are 936 particularly undesirable. It appears that alternatives to NAT-PT 937 exist to cover the circumstances where NAT-PT has been suggested as a 938 solution, such as the use of tunneling and header compression in 3GPP 939 scenarios. 941 However, it is clear that in some circumstances an IPv6/IPv4 protocol 942 translation solution may be a useful transitional solution, 943 particularly in more constrained situations where the translator is 944 not required to deal with traffic for a wide variety of protocols 945 that are not determined in advance. Therefore, it is possible that a 946 more limited form of NAT-PT could be defined for use in specific 947 situations. 949 Accordingly, we recommend that the IETF no longer suggest its usage 950 as a general IPv4/IPv6 transition mechanism in the Internet, but 951 retain it as an experimental mechanism while further experience is 952 gained and any future replacement is defined and deployed. 953 Consequently, we recommend moving RFC2766 to experimental status. 955 9. Acknowledgments 957 This work builds on a large body of existing work examining the 958 issues and applicability of NAT-PT: the work of the authors of the 959 documents referred to in Section 1 has been extremely useful in 960 creating this document. Particular thanks are due to Pekka Savola 961 for rapid and thorough review of the document. 963 10. References 965 10.1. Normative References 967 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 968 (SIIT)", RFC 2765, February 2000. 970 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 971 Translation - Protocol Translation (NAT-PT)", RFC 2766, 972 February 2000. 974 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 975 RFC 2535, March 1999. 977 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 978 Translator (NAT) Terminology and Considerations", 979 RFC 2663, August 1999. 981 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications 982 with the IP Network Address Translator", RFC 3027, 983 January 2001. 985 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 986 Generation Partnership Project (3GPP) Standards", 987 RFC 3314, September 2002. 989 [RFC3484] Draves, R., "Default Address Selection for Internet 990 Protocol version 6 (IPv6)", RFC 3484, February 2003. 992 [RFC1035] Mockapetris, P., "Domain names - implementation and 993 specification", STD 13, RFC 1035, November 1987. 995 [I-D.ietf-ipv6-node-requirements] 996 Loughney, J., "IPv6 Node Requirements", 997 draft-ietf-ipv6-node-requirements-11 (work in progress), 998 August 2004. 1000 [I-D.ietf-v6ops-3gpp-analysis] 1001 Wiljakka, J., "Analysis on IPv6 Transition in 3GPP 1002 Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in 1003 progress), October 2004. 1005 [I-D.ietf-dnsext-dnssec-intro] 1006 Arends, R., Austein, R., Massey, D., Larson, M., and S. 1007 Rose, "DNS Security Introduction and Requirements", 1008 draft-ietf-dnsext-dnssec-intro-13 (work in progress), 1009 October 2004. 1011 10.2. Informative References 1013 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1014 Considerations for IP Fragment Filtering", RFC 1858, 1015 October 1995. 1017 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1018 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1020 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1021 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1022 Zhang, L., and V. Paxson, "Stream Control Transmission 1023 Protocol", RFC 2960, October 2000. 1025 [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of 1026 Managed Objects for Synchronous Optical Network (SONET) 1027 Linear Automatic Protection Switching (APS) 1028 Architectures", RFC 3498, March 2003. 1030 [I-D.satapati-v6ops-natpt-applicability] 1031 Satapati, S., "NAT-PT Applicability", 1032 draft-satapati-v6ops-natpt-applicability-00 (work in 1033 progress), October 2003. 1035 [I-D.durand-natpt-dns-alg-issues] 1036 Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", 1037 draft-durand-natpt-dns-alg-issues-00 (work in progress), 1038 February 2002. 1040 [I-D.hallin-natpt-dns-alg-solutions] 1041 Hallingby, P. and S. Satapati, "NAT-PT DNS ALG solutions", 1042 draft-hallin-natpt-dns-alg-solutions-01 (work in 1043 progress), July 2002. 1045 [I-D.lee-v6ops-natpt-mobility] 1046 Shin, M. and J. Lee, "Considerations for Mobility Support 1047 in NAT-PT", draft-lee-v6ops-natpt-mobility-01 (work in 1048 progress), July 2005. 1050 [I-D.okazaki-v6ops-natpt-security] 1051 Okazaki, S. and A. Desai, "NAT-PT Security 1052 Considerations", draft-okazaki-v6ops-natpt-security-00 1053 (work in progress), June 2003. 1055 [I-D.vanderpol-v6ops-translation-issues] 1056 Pol, R., Satapati, S., and S. Sivakumar, "Issues when 1057 translating between IPv4 and IPv6", 1058 draft-vanderpol-v6ops-translation-issues-00 (work in 1059 progress), January 2003. 1061 [I-D.elmalki-sipping-3gpp-translator] 1062 Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based 1063 services in Third Generation Partnership Project (3GPP) 1064 Networks", draft-elmalki-sipping-3gpp-translator-00 (work 1065 in progress), December 2003. 1067 [I-D.tsuchiya-mtp] 1068 Tsuchiya, K., Higuchi, H., Sawada, S., and S. Nozaki, "An 1069 IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying 1070 (mtp)", draft-tsuchiya-mtp-01 (work in progress), 1071 February 2003. 1073 [I-D.venaas-mboned-v4v6mcastgw] 1074 Venaas, S., "An IPv4 - IPv6 multicast gateway", 1075 draft-venaas-mboned-v4v6mcastgw-00 (work in progress), 1076 February 2003. 1078 [I-D.park-scalable-multi-natpt] 1079 Park, S., "Scalable mNAT-PT Solution", 1080 draft-park-scalable-multi-natpt-00 (work in progress), 1081 May 2003. 1083 Authors' Addresses 1085 Cedric Aoun 1086 ZTE Corporation/ENST Paris 1087 France 1089 Email: aoun.cedric@zte.com.fr 1091 Elwyn B. Davies 1092 Consultant 1093 Soham, Cambs 1094 UK 1096 Phone: +44 7889 488 335 1097 Email: elwynd@dial.pipex.com 1099 Intellectual Property Statement 1101 The IETF takes no position regarding the validity or scope of any 1102 Intellectual Property Rights or other rights that might be claimed to 1103 pertain to the implementation or use of the technology described in 1104 this document or the extent to which any license under such rights 1105 might or might not be available; nor does it represent that it has 1106 made any independent effort to identify any such rights. Information 1107 on the procedures with respect to rights in RFC documents can be 1108 found in BCP 78 and BCP 79. 1110 Copies of IPR disclosures made to the IETF Secretariat and any 1111 assurances of licenses to be made available, or the result of an 1112 attempt made to obtain a general license or permission for the use of 1113 such proprietary rights by implementers or users of this 1114 specification can be obtained from the IETF on-line IPR repository at 1115 http://www.ietf.org/ipr. 1117 The IETF invites any interested party to bring to its attention any 1118 copyrights, patents or patent applications, or other proprietary 1119 rights that may cover technology that may be required to implement 1120 this standard. Please address the information to the IETF at 1121 ietf-ipr@ietf.org. 1123 Disclaimer of Validity 1125 This document and the information contained herein are provided on an 1126 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1127 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1128 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1129 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1130 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1131 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1133 Copyright Statement 1135 Copyright (C) The Internet Society (2005). This document is subject 1136 to the rights, licenses and restrictions contained in BCP 78, and 1137 except as set forth therein, the authors retain all their rights. 1139 Acknowledgment 1141 Funding for the RFC Editor function is currently provided by the 1142 Internet Society.