idnits 2.17.1 draft-ietf-v6ops-nat64-pb-statement-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 760. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 62: '...equirements that MUST be supported . ...' RFC 2119 keyword, line 63: '...tant things that SHOULD be supported ...' RFC 2119 keyword, line 479: '...ic Requirements that MUST be supported...' RFC 2119 keyword, line 485: '...lation mechanism MUST NOT require chan...' RFC 2119 keyword, line 488: '...lation mechanism MAY require changes t...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The adoption of the translation mechanism MUST not result in a significantly more vulnerable Internet == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The translation mechanism SHOULD not prevent MIPv6 Route Optimization when the CN is a v4-only node == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The translation mechanism SHOULD not prevent a SCTP communication between a v6-only node and a v4-only node == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The translation mechanism SHOULD not prevent a DCCP communication between a v6-only node and a v4-only node == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The translation mechanism SHOULD not prevent multicast traffic between the v4-only nodes and the v6-only nodes. -- 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 (May 13, 2008) is 5789 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4942' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 667, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4214 (Obsoleted by RFC 5214) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft Huawei Labs at UC3M 4 Intended status: Informational F. Baker 5 Expires: November 14, 2008 Cisco Systems 6 I. van Beijnum 7 IMDEA Networks 8 May 13, 2008 10 IPv4/IPv6 Coexistence and Transition: Requirements for solutions 11 draft-ietf-v6ops-nat64-pb-statement-req-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 23 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 November 14, 2008. 38 Abstract 40 This note presents the problem statement, analysis and requirements 41 for solutions to IPv4/IPv6 coexistence and eventual transition in a 42 scenario in which dual stack operation is not the norm. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 48 2.1. Transition scenarios . . . . . . . . . . . . . . . . . . . 3 49 2.1.1. Simple transition scenarios . . . . . . . . . . . . . 3 50 2.1.2. Transition scenarios that do not require 51 translation . . . . . . . . . . . . . . . . . . . . . 4 52 2.1.3. Transition scenarios that require translation . . . . 5 53 2.2. Requirements for the overall transition strategy . . . . . 6 54 3. Preliminary analysis for translation mechanisms . . . . . . . 7 55 3.1. Application behavior taxonomy . . . . . . . . . . . . . . 7 56 3.2. Placement of the NAT64 mechanisms . . . . . . . . . . . . 8 57 3.3. v4 addressing consideration . . . . . . . . . . . . . . . 9 58 3.4. Name-space considerations . . . . . . . . . . . . . . . . 10 59 3.5. Market timing considerations . . . . . . . . . . . . . . . 11 60 4. Requirements for new generation of v4-v6 translation 61 mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.1. Basic Requirements that MUST be supported . . . . . . . . 11 63 4.2. Important things that SHOULD be supported . . . . . . . . 13 64 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 6. Security considerations . . . . . . . . . . . . . . . . . . . 14 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 71 Intellectual Property and Copyright Statements . . . . . . . . . . 17 73 1. Introduction 75 This note addresses requirements for solutions to IPv4/IPv6 76 coexistence and eventual transition in a scenario in which dual stack 77 operation is not the norm. 79 2. Problem statement 81 Operationally, we now expect the transition to be less a matter of 82 connecting ever-growing IPv6 islands in an IPv4 network, and more a 83 matter of the network becoming a patchwork quilt of IPv4, IPv6, and 84 dual domains. 85 o Hosts now generally support IPv6 and IPv4 natively. 86 o As described in [RFC4213], the IETF community had expected 87 administrations to turn on IPv6 in their existing IPv4 networks, 88 resulting in a simple coexistence scenario. 89 o Increasingly, we hear statements that people want to move directly 90 to an IPv6-only or IPv6-dominant network. 92 In this context, "IPv6-only" refers to a network or system that only 93 runs IPv6, and "IPv6-dominant" refers to a network or system that may 94 use IPv4 internally or with other clients, but in the context only 95 routes IPv6 datagrams. "IPv4-only" and "IPv4-dominant" are defined 96 similarly. Since these are indistinguishable to the peer, the terms 97 "IPv4-only" and "IPv6-only" will be used in this paper and considered 98 to subsume the "dominant" issues. 100 2.1. Transition scenarios 102 There are six obvious transition scenarios: 103 o IPv4 system connecting to an IPv4 system across an IPv4 network, 104 o An IPv6 system connecting to an IPv6 system across an IPv6 105 network, 106 o an IPv4 system connecting to an IPv4 system across an IPv6 107 network, 108 o an IPv6 system connecting to an IPv6 system across an IPv4 109 network, 110 o an IPv4 system connecting to an IPv6 system, or 111 o an IPv6 system connecting to an IPv4 system. 113 2.1.1. Simple transition scenarios 115 The simplest coexistence cases are about an IPv4 system connecting to 116 an IPv4 system across an IPv4 network, or an IPv6 system connecting 117 to an IPv6 system across an IPv6 network. The dual stack case, in 118 which both endpoints and the relevant applications support IPv4 and 119 IPv6 and the network supports at least one of the protocols, falls 120 into this case as the applications can connect using whichever stack 121 is consistent end to end. 123 The IETF strongly prefers and recommends this scenario, as the 124 operational matters are the simplest. Until the Internet reaches 125 IPv4 address exhaustion, an IPv4 and an IPv6 address can be assigned 126 to every interface, and the applications are supported. When it 127 becomes necessary to deploy only IPv6 addresses, since all other 128 systems have both, IPv6-only systems cleanly interoperate with 129 existing systems. 131 2.1.2. Transition scenarios that do not require translation 133 [RFC4213] discusses the scenario in Figure 1, in which routers 134 connect two dual domains via an IPv4-only domain. Obviously, this 135 can be reversed: routers can connect two dual domains via an IPv6- 136 only domain. Note that the connecting domain need not actually be 137 IPv4-only or IPv6-only; to create this scenario, it need merely fail 138 to offer IPv6 or IPv4 services to the neighboring domains. 140 ,-. ,-. ,-. 141 ,' `. ,' `. ,' `. 142 ; : ; : ; : 143 ; IPv4+ : ; IPv4- : ; IPv4+ : 144 ; IPv6 : ; only : ; IPv6 : 145 ; Domain : ; Domain : ; Domain : 146 ; : ; : ; : 147 | +----+ | | +----+ | | +----+ | 148 | |IPv4| | | |IPv4| | | |IPv4| | 149 | |Host+ | | |Host| | | |Host| | 150 : +----+\ ; : /+----+\ ; :/ +----+ ; 151 : +----+ \+------+ +------+ +----+ ; 152 : |IPv6+--+Router+=======+Router+-+IPv6| ; 153 :|Host| ;+------+ +------+:|Host| ; 154 :+----+ ; : ; :+----+ ; 155 `. ,' `. ,' `. ,' 156 `-' `-' `-' 158 Figure 1: Disconnected continuity 160 In such a scenario, there are two obvious solutions: one can tunnel 161 across the connecting domain, as shown, or one can translate between 162 IP layers using something akin to traditional NAT technology. The 163 tunnel approach offers some pros and some cons: it natively connects 164 the dual domains, meaning that all applications should work, but they 165 may have issues with the path MTU, and the tunnels require some form 166 of configuration. The NAT approach similarly offers pros and cons: 167 it offers something similar to standard routing, but it suffers from 168 the various ills of Network Address Translation on both sides, 169 meaning that it may be difficult for the dual domains to offer 170 services to each other. 172 In general, the IETF recommends the use of tunnels rather than a dual 173 NAT. 175 There are at least three generic models that could be used to 176 describe this kind of tunneling scenario: 177 o Static tunnels with interior dynamic routing 178 o Start-time negotiated tunnels to some central point with default 179 routing (example in [I-D.stenberg-v6ops-pd-route-maintenance]) 180 o Dynamic tunnels with specific routing to islands (examples might 181 include ISATAP [RFC4214] or a tunnel broker of some description) 183 Static tunnels with routing through them are commonly deployed today, 184 both in VPNs and in overlay networks. The positive side is that they 185 provide simple service; the negative is that the generally require 186 manual configuration and can result in suboptimal routing. 188 A "start-time" tunnel might be useful in an access network that 189 serves homes or SOHO environments. In this model, the ISP informs 190 the CPE of a cross-network peer that it can create a tunnel to, 191 reducing the case to one similar to static tunneling but without 192 manual configuration. 194 A dynamic tunneling environment is an overlay model in which systems 195 create tunnels to various peers across the connecting domain as 196 needed, based on a priori knowledge of the correlation between remote 197 prefixes and next hop routers. This has not been adequately 198 described at this point, and therefore involves complexities in 199 implementation and deployment. 201 2.1.3. Transition scenarios that require translation 203 Translation, as found in Figure 2, is considered in NAT-PT [RFC2766], 204 which has in turn been set aside via [RFC4966]. In essence, 205 translation is required when an IPv4-only system connects to an IPv6- 206 only system or an IPv6-only system connects to an IPv4-only system. 207 These systems need not actually be IPv4-only or IPv6-only; if the 208 connecting network is IPv4-only or IPv6-only and provides no tunnel, 209 but only offers IPv4 service to one and only offers IPv6 service to 210 the other, the situation is equivalent. 212 ,-----. ,-----. 213 ,' `. ,' `. 214 / \ / \ 215 / IPv4-only \ / IPv6-only \ 216 / Domain +-----------+ Domain \ 217 ; |Translation| : 218 | | Gateway | | 219 : +-----------+ ; 220 \ +----+ / \ +----+ / 221 \ |IPv4| / \ |IPv6| / 222 \ |Host| / \ |Host| / 223 `. +----+,' `. +----+,' 224 '-----' '-----' 226 Figure 2: Translation 228 In such a scenario, it is necessary for the network to create a 229 translation gateway, at which datagrams from one system are 230 translated forwarded to the other. The situation is in many ways 231 reflexive, since most Internet sessions are bidirectional - TCP 232 between an IPv4 and an IPv6 system translate data messages in one 233 direction and acknowledgments in the other. 235 They are not reflexive, however, in the distribution of domain names. 236 If the application is client-server and the server is in one of the 237 domains, the name of the server need only be propagated to the other. 238 Reverse lookups, frequently used in spam verification would require 239 the client's name to be propagated into the server's domain. But in 240 this there are issues. The address of the client (the TCP peer) as 241 seen by the server is not the remote system in the other domain; it 242 is the translator. This is readily worked around for an IPv6 server, 243 as the IPv4 address of the remote peer can be embedded in a "privacy" 244 address [RFC4941], making the reverse lookup viable. This doesn't 245 work on the IPv4 side, however. 247 2.2. Requirements for the overall transition strategy 249 Given the problem statement presented here, we see the following 250 requirements for a complete transition strategy: 251 1. Any transition strategy must contemplate a period of coexistence, 252 with ultimate transition (e.g., turning off IPv4) being a 253 business decision. 254 2. Many are delaying turning on IPv6 (initiating coexistence in 255 their networks) as long as possible. 256 3. Some are turning off IPv4 immediately, at least as a customer 257 service. 259 4. Therefore, dual stack approaches, tunneled architectures, and 260 translation architectures are all on the table. 261 5. Any solution that makes translation between semi-connected 262 islands "normal" has failed the fundamental architecture of the 263 Internet and can expect service complexity to be an issue. 264 [RFC3439] 265 6. Translation architectures must provide for the advertisement of 266 IPv4 names to IPv6 systems and vice versa. The address 267 advertised in the "far" domain must be that of the translating 268 gateway. 269 7. Tunneling architectures must provide a way to minimize and 270 ideally eliminate configuration of the tunnel. 272 3. Preliminary analysis for translation mechanisms 274 3.1. Application behavior taxonomy 276 The general purpose of NAT64 type of mechanisms is to enable 277 communication between a v4-only node and a v6-only node. However, 278 there is wide range of type of communications, when considering how 279 they handle IP addresses. So, in order to properly characterize the 280 problem, we need to do an analysis of the different application 281 behavior in terms of the usage of their IP addresses. We will next 282 present a taxonomy of the behavior of the application with respect of 283 how they use the IP address. The support of the different type of 284 behavior will impose a different set of constraints to the design of 285 a NAT64 mechanisms. It is then important to decide which type of 286 application behavior will be supported before starting to design a 287 NAT64 mechanism. The proposed taxonomy is heavily based on the one 288 presented in section 1.1 of draft-ietf-shim6-app-refer-00.txt. 290 The proposed application behavior taxonomy is the following: 292 Short-lived local handle. The IP addresses is never retained by the 293 application. The only usage is for the application to pass it from 294 the DNS APIs (e.g., getaddrinfo()) and the API to the protocol stack 295 (e.g., connect() or sendto()). This type of communication can be 296 either initiated by the v4-only node or by the v6-only node, 297 resulting in two type of behaviors, v4-initiated short lived local 298 handle and v6-initiated short lived local handle. 300 Long-lived application associations. The IP address is retained by 301 the application for several instances of communication. However, it 302 is always the same node that initiates the communication. This type 303 of communication can be either initiated by the v4-only node or by 304 the v6-only node, resulting in two type of behaviors, v4-initiated 305 long-lived associations and v6-initiated long-lived associations. 307 Callbacks. The application at one end retrieves the IP address of 308 the peer and uses that to later communicate "back" to the peer. This 309 type of communication can be either initiated by the v4-only node or 310 by the v6-only node, resulting in two type of behaviors, v4-initiated 311 callback, meaning that the initial communication is initiated by the 312 v6-only node, and later the v4-only node initiates the callback, and 313 v6-initiated callback, meaning that the initial communication is 314 initiated by the v4-only node, and later the v6-only node initiates 315 the callback. An additional disticntion can be made based on the 316 time-frame of the call back operation. There can be short-lived 317 call-backs, where the receiver inmediatelly calls back to the 318 initiator and long-lived call-backs where the receiver calls backs 319 after a while. 321 Referrals. In an application with more than two parties, party B 322 takes the IP address of party A and passes that to party C. After 323 this party C uses the IP address to communicate with A. In this type 324 of communication, the following 6 sub-cases are possible. 325 o A and B are v6-only nodes and C is a v4-only node; 326 o A and C are v6-only nodes and B is a v4-only node, 327 o B and C are v6-only nodes and A is a v4-only node, 328 o A and B are v4-only nodes and C is a v6-only node; 329 o A and C are v4-only nodes and B is a v6-only node, 330 o B and C are v4-only nodes and A is a v6-only node, 332 "Identity" comparison. Some applications might retain the IP 333 address, not as a means to initiate communication as in the above 334 cases, but as a means to compare whether a peer is the same as 335 another peer. While this is insecure in general, it might be 336 something which is used e.g., when TLS is used. This type of 337 communication results in two sub-cases, when the v4-only node 338 performs comparison of the v6-only node identity, and when the v6- 339 only node performs comparison of the v4-only node identity 341 3.2. Placement of the NAT64 mechanisms 343 Another aspect that is critical to design a NAT64 mechanism is the 344 placement of the mechanisms involved. In other words, what elements 345 can be modified/updated to support the NAT64 mechanisms. We assume 346 that the NAT64 box supports a set of mechanisms that are the core 347 part of the solution, but some approaches may require the 348 modification of additional elements. In particular, we can identify 349 the following additional elements that may require modification to 350 support a NAT64 approach. 352 Modification to v4-only nodes: one option is to require modification 353 to existent v4-only nodes in order to support the NAT64 mechanism. 354 This option would impose high deployment costs, because the existent 355 base of v4-only nodes is really big and there is no incentives for 356 the v4-only nodes to install such mechanism, since it seems unlikely 357 that v4-only nodes will have a strong need to communicate with v6- 358 only nodes (at least at the initial stages of v6 deployment). 359 However, it may be possible that this is the only viable solution for 360 supporting some type of application behavior. 362 Modification to v6-only nodes: Another option is to require 363 modifications to v6-only nodes. This option seems much more 364 acceptable, since the existent base of v6-nodes is relatively small 365 and there would be a strong incentive for v6-only nodes to 366 communicate with v4-only nodes, since most of the contents are 367 available only in v4 today. However, imposing modifications to v6- 368 only nodes does make deployment of the solution more difficult, since 369 update of current v6-implementations is needed. In addition, there 370 is an architectural consideration, that we would be imposing v6-only 371 nodes to support "NAT hacks" in order to enable communication with 372 the v4 world, and that those modifications may stay forever, even 373 when the need for communication with the v4-Internet is not so 374 pressing. 376 Modification to both v4-only nodes and v6-only nodes. Another option 377 is to require updates to both v4-only nodes and also to v6-only 378 nodes. Needless to say that this would be the option with higher 379 deployment costs. 381 No modification. Another option is that the NAT64 mechanisms does 382 not require modification to any host and that the mechanism is fully 383 contained in the NAT64 box. This was the case of the previously 384 defined NAT-PT approach. However, it may be challenging to design a 385 solution with this constraint that does not suffer the limitations 386 suffered by the NAT-PT mechanism that lead the IETF community to 387 deprecate it. 389 Another consideration related to the modification imposed by a NAT64 390 approach is about what elements in the nodes need to be updated. In 391 particular, it is important to determine if only the IP layer on the 392 affected nodes needs to be modified or f other elements in the nodes 393 needs to be updated. In particular, it is critical to determine if 394 applications need to e modified in order to support the NAT64 395 mechanism. 397 3.3. v4 addressing consideration 399 We assume that both the v6-only nodes and the v6 interface of the 400 NAT64 boxes will have routable IPv6 addresses. However, on the v4 401 side, there are more options. Either the v4 interface of the NAT64 402 boxes and/or the v4-only nodes can have either v4 private addresses 403 or v4 public addresses. Actually, it is possible that the different 404 combinations make sense. It seems clear that the case where public 405 v4 addresses are used in both the v4 interface of the NAT64 box and 406 the v4-only nodes is relevant. The case where the v4-only node has a 407 private v4 address and the NAT64 box has a public address seems also 408 possible, but here it seems reasonable to assume that a NAT box will 409 exist between the v4 only node and the NAT64 box. The case where 410 both the v4 node and the NAT64 box have v4 private addresses could 411 also make sense, since this could apply to a scenario where a site 412 that has v4 private addresses and v6 addresses could try to use a 413 NAT64 box internally. The last case, where the v4 node has public 414 address and the NAT64 box has a private address seems harder to 415 justify though. 417 Another consideration related to v4 addressing of the NAT64 approach 418 is the number of addresses required by the NAT64 box. It is possible 419 that some NAT64 approaches require a pool of v4 addresses instead of 420 a single v4 address. Considering the status of the v4 address space 421 consumption, it may not be feasible to use a NAT64 approach that 422 require a big number of v4 public addresses. 424 3.4. Name-space considerations 426 One of the major choices that are faced when designing a NAT4 427 mechanism that enable communication initiated by the v4-only node 428 towards a v6-only node. In this case, the v4 only node needs to 429 identify the v6 only node and the problem is that there is no means 430 to permanently map the v6 address space in the v4 address space. So 431 in order to enable a v4-only node to identify a v6-only node a name 432 space other than the IPv4 address space is needed. We will next 433 discuss some options that could be considered to identify v6 nodes in 434 the v4 world. 436 A first option is to use IPv4 addresses to identify IPv6 nodes. The 437 problem is that the v6 address space is much bigger than the v4 438 address space, so it is not possible to do permanent mapping between 439 these two. This basically implies that dynamic mapping between a 440 given v4 address and different v6 addresses are established. While 441 this works for some type of application behavior, it does not support 442 others, such as communications initiated by a v4 node towards a v6 443 node in a general case (it is possible for a given subset of v6 444 nodes, but not as a general solution) 446 A second option is to use IPv6 addresses themselves. In this case, 447 the IPv4 node is aware of the IPv6 address of the destination and it 448 uses it to identify the target at the NAT64 box. This option would 449 likely imply modifications in the v4 nodes. 451 A third option is to use FQDN to identify nodes. In this case v4 452 nodes identify v6 nodes using FQDNs, which is already supported in 453 the v4 world. The difficulties with such a approach is that DNS ALG 454 are likely to be required. 456 A fourth option is to use a combination of IPv4 address, transport 457 protocol and port for identification of a v6 node or a v6 flow. 459 3.5. Market timing considerations 461 We expect translation mechanism to require deployment in the very 462 near term, prior to IPv4 address depletion, and to be interoperable 463 with end systems that have been deployed in that timeframe. Since 464 address space depletion is expected t occur in the 2010-2012 465 timeframe and host software tends to be changed primarily when people 466 buy new hardware (every 2-3 years on average), we expect that this 467 needs to be compatible with currently-deployed Windows (XP and 468 Vista), MacOSX (Tiger and Leopard), Linux, and Solaris operating 469 systems. That argues for a solution that requires no changes to host 470 software that cannot be reasonably expected to deploy via patch 471 update procedures - this is otherwise all solved in network devices. 473 4. Requirements for new generation of v4-v6 translation mechanisms 475 This list of requirements basically should contain all the aspects 476 that should be considered when designing a new generation of 477 translation mechanisms. 479 4.1. Basic Requirements that MUST be supported 481 These are the requirements for short term mechanism behaviour 483 R1: Changes in the hosts 485 The translation mechanism MUST NOT require changes in the v4-only 486 nodes to support the Basic requirements described in this section, 487 unless explicitly stated in the particular requirement. The 488 translation mechanism MAY require changes to v6-only nodes. 490 R2: Basic communication support 491 o R2.1: Translation mechanim must support v6-initiated short-lived 492 local handle (as defined in Section 3.1. (strong consensus on 493 this) 494 o R2.2: Translation mechanim must support v4-initiated short-lived 495 local handle (as defined in Section 3.1). (not clear if there is 496 consensus for this) 498 o R2.2.1: v4 initiators can either use IPv4 public addresses or IPv4 499 private addresses and use a NAT.(The acceptance of R2.2.1 is 500 subject to the acceptance of R2.2. 502 R3: Interaction with dual-stack hosts 504 Translation mechanism MUST allow using native connectivity when it is 505 available. This means that if a v6-only nodes wants to communicate 506 with a dual stack, it must use native v6 connectivity and if a v4- 507 only nodes wants to communicate with a dual stack, it must use native 508 v4 connectivity.(In this case, dual stack means a host with both IPv6 509 and IPv4 stacks, wich are both active, i.e. they have v4 and v6 510 connectivity). 512 R4: DNS semantics preservation 514 Any modifications to DNS responses associated with translation MUST 515 NOT violate standard DNS semantics. This includes in particular that 516 a DNS response (that has been modified by the translator mechanism) 517 should not be invalid if it ends up in the wrong context, i.e. 518 traversing a non expected part of the topology. 520 R5: Routing 522 IPv6 routing should not be affected in any way, and there should be 523 no risk of importing "entropy" from the IPv4 routing tables into 524 IPv6. 526 R6: Protocols supported 528 The translation mechanism MUST support at least TCP, UDP, ICMP, TLS. 530 R7: Behave requirements 532 The translation mechanism MUST be compliant with the requirements for 533 IPv4 NATs defined in [I-D.ietf-behave-tcp] and in [RFC4787] when 534 applicable. These requirements should be interpreted with the IPv6 535 side on the IPv6-IPv4 translator being the IPv4 private side of the 536 conventional NAT. 538 R8: Fragmented packets 540 The translation mechanism MUST suport fragmented packets when the 541 fragments arrive within an interval smaller or equal to 5 seconds. 542 However, the translator device MUST avoid that the support for 543 fragmented packets introduces a DoS attack vector (i.e. an attacker 544 injecting a high number of fragments would result in a DoS attack to 545 the device), so the device MUST implement some form of limitation to 546 the resources used by the fragmented packet support. for example a 547 translator device may define a maximum amount of memory used for 548 storing fragmented packet state (the actual amount of memory will 549 depend on the intended usage of the box, carrier grade vs. set top 550 box). 552 R9: Security 554 The adoption of the translation mechanism MUST not result in a 555 significantly more vulnerable Internet 557 R10: DNSSec support 559 DNSSec support MUST NOT be prevented. 560 o R10.1: In particular, if an IPv6 node is initiating a 561 communication with an IPv4 that is located behind a translator, 562 the IPv6 initiator MUST be able to perform DNSSec verification of 563 the DNS information of the IPv4 target. (strong consensus on this 564 one). 565 o R10.2: In particular, if an IPv4 node is initiating a 566 communication with an IPv6 that is located behind a translator, 567 the IPv4 initiator MUST be able to perform DNSSec verification of 568 the DNS information of the IPv4 target. This may require the 569 modification of the IPv4 node as well. (not clear if there 570 consensus on this one) 572 R11: IPsec support. 574 The translator MUST support communication between IPv4 node and IPv6 575 node using UDP Encapsulation of IPsec ESP Packets as defined in 576 [RFC3948] as applicable. RFC3948 should be interpreted as with the 577 IPv6 side on the IPv6-IPv4 translator being the IPv4 private side of 578 the conventional NAT. IPsec support MAY require updating also the 579 IPv4 side. 581 4.2. Important things that SHOULD be supported 583 I2: Operational flxibility 585 It should be possible to locate the translation device at an 586 arbitrary point in the network (i.e. not at fixed points such as a 587 site exit), so that there is full operational flexibility. 589 I3: Central Management 591 Any configuration need for an IPv6 host to make use of the mechanism 592 should be possible centrally, e.g. a DHCP option. 594 I4: Richer application behaviour support 596 The translation mechanism SHOULD support the other types of 597 application behaviours, including Long-lived application 598 associations, callbacks and referrals.In order to support this. the 599 translation mechanism MAY require changes to v4-only nodes too 601 I5: MIPv6 support 603 The translation mechanism SHOULD not prevent MIPv6 Route Optimization 604 when the CN is a v4-only node 606 I6: SCTP support 608 The translation mechanism SHOULD not prevent a SCTP communication 609 between a v6-only node and a v4-only node 611 I7: DCCP support 613 The translation mechanism SHOULD not prevent a DCCP communication 614 between a v6-only node and a v4-only node 616 I8: Multicast support 618 The translation mechanism SHOULD not prevent multicast traffic 619 between the v4-only nodes and the v6-only nodes. 621 5. Contributors 623 This draft contains contributions from Iljitsch van Beijnum, Brian 624 Carpenter and Elwyn Davies (this doesn't mean that they agree on the 625 draft, just that we have used text provided by them). We would like 626 to acknowledge the comments from Dave Thaler, Michael Richardson, 627 George Tsirtsis, Hesham Soliman, Yaron Sheffer and Kurt Lindqvist. 629 6. Security considerations 631 The requirements include R9 and R11 concerning security issues. 633 7. Acknowledgments 635 Marcelo Bagnulo is partly funded by Trilogy, a research project 636 supported by the European Commission under its Seventh Framework 637 Program. 639 8. References 641 8.1. Normative References 643 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 644 for IPv6 Hosts and Routers", RFC 4213, October 2005. 646 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 647 Co-existence Security Considerations", RFC 4942, 648 September 2007. 650 [I-D.ietf-behave-tcp] 651 Guha, S., "NAT Behavioral Requirements for TCP", 652 draft-ietf-behave-tcp-07 (work in progress), April 2007. 654 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 655 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 656 RFC 4787, January 2007. 658 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 659 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 660 RFC 3948, January 2005. 662 8.2. Informative References 664 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 665 Guidelines and Philosophy", RFC 3439, December 2002. 667 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 668 (IPv6) Specification", RFC 2460, December 1998. 670 [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 671 "Intra-Site Automatic Tunnel Addressing Protocol 672 (ISATAP)", RFC 4214, October 2005. 674 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 675 Translation - Protocol Translation (NAT-PT)", RFC 2766, 676 February 2000. 678 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 679 Extensions for Stateless Address Autoconfiguration in 680 IPv6", RFC 4941, September 2007. 682 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 683 Address Translator - Protocol Translator (NAT-PT) to 684 Historic Status", RFC 4966, July 2007. 686 [I-D.stenberg-v6ops-pd-route-maintenance] 687 Stenberg, M. and O. Troan, "IPv6 Prefix Delegation routing 688 state maintenance approaches", 689 draft-stenberg-v6ops-pd-route-maintenance-00 (work in 690 progress), December 2007. 692 Authors' Addresses 694 Marcelo Bagnulo 695 Huawei Labs at Universidad Carlos III de Madrid 696 Av. Universidad 30 697 Leganes, Madrid 28911 698 SPAIN 700 Phone: 34 91 6249500 701 Email: marcelo@it.uc3m.es 702 URI: http://www.it.uc3m.es 704 Fred Baker 705 Cisco Systems 706 Santa Barbara, California 93117 707 USA 709 Phone: +1-408-526-4257 710 Fax: +1-413-473-2403 711 Email: fred@cisco.com 713 Iljitsch van Beijnum 714 IMDEA Networks 715 Madrid, Madrid 28911 716 Spain 718 Phone: 719 Fax: 720 Email: iljitsch@muada.com 722 Full Copyright Statement 724 Copyright (C) The IETF Trust (2008). 726 This document is subject to the rights, licenses and restrictions 727 contained in BCP 78, and except as set forth therein, the authors 728 retain all their rights. 730 This document and the information contained herein are provided on an 731 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 732 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 733 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 734 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 735 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 736 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 738 Intellectual Property 740 The IETF takes no position regarding the validity or scope of any 741 Intellectual Property Rights or other rights that might be claimed to 742 pertain to the implementation or use of the technology described in 743 this document or the extent to which any license under such rights 744 might or might not be available; nor does it represent that it has 745 made any independent effort to identify any such rights. Information 746 on the procedures with respect to rights in RFC documents can be 747 found in BCP 78 and BCP 79. 749 Copies of IPR disclosures made to the IETF Secretariat and any 750 assurances of licenses to be made available, or the result of an 751 attempt made to obtain a general license or permission for the use of 752 such proprietary rights by implementers or users of this 753 specification can be obtained from the IETF on-line IPR repository at 754 http://www.ietf.org/ipr. 756 The IETF invites any interested party to bring to its attention any 757 copyrights, patents or patent applications, or other proprietary 758 rights that may cover technology that may be required to implement 759 this standard. Please address the information to the IETF at 760 ietf-ipr@ietf.org.