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