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