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