idnits 2.17.1 draft-bagnulo-v6ops-6man-nat64-pb-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 712. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 725. 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 64: '...equirements that MUST be supported . ...' RFC 2119 keyword, line 65: '...tant things that SHOULD be supported ...' RFC 2119 keyword, line 484: '...ic Requirements that MUST be supported...' RFC 2119 keyword, line 490: '...lation mechanism MUST NOT require chan...' RFC 2119 keyword, line 492: '...lation mechanism MAY require changes t...' (15 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 introduce new vulnerabilities in the 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 (February 20, 2008) is 5908 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 636, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 644, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '4') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4214 (ref. '5') (Obsoleted by RFC 5214) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '6') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 4941 (ref. '7') (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 8 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: August 23, 2008 Cisco Systems 6 February 20, 2008 8 IPv4/IPv6 Coexistence and Transition: Requirements for solutions 9 draft-bagnulo-v6ops-6man-nat64-pb-statement-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 23, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This note presents the problem statement, analysis and requirements 43 for solutions to IPv4/IPv6 coexistence and eventual transition in a 44 scenario in which dual stack operation is not the norm. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Transition scenarios . . . . . . . . . . . . . . . . . . . 3 51 2.1.1. Simple transition scenarios . . . . . . . . . . . . . 3 52 2.1.2. Transition scenarios that do not require 53 translation . . . . . . . . . . . . . . . . . . . . . 4 54 2.1.3. Transition scenarios that require translation . . . . 5 55 2.2. Requirements for the overall transition strategy . . . . . 6 56 3. Preliminary analysis for translation mechanisms . . . . . . . 7 57 3.1. Application behavior taxonomy . . . . . . . . . . . . . . 7 58 3.2. Placement of the NAT64 mechanisms . . . . . . . . . . . . 8 59 3.3. v4 addressing consideration . . . . . . . . . . . . . . . 10 60 3.4. Name-space considerations . . . . . . . . . . . . . . . . 10 61 3.5. Market timing considerations . . . . . . . . . . . . . . . 11 62 4. Requirements for new generation of v4-v6 translation 63 mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.1. Basic Requirements that MUST be supported . . . . . . . . 11 65 4.2. Important things that SHOULD be supported . . . . . . . . 13 66 4.3. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 14 67 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 6. Security considerations . . . . . . . . . . . . . . . . . . . 14 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Intellectual Property and Copyright Statements . . . . . . . . . . 17 76 1. Introduction 78 This note addresses requirements for solutions to IPv4/IPv6 79 coexistence and eventual transition in a scenario in which dual stack 80 operation is not the norm. 82 2. Problem statement 84 Operationally, we now expect the transition to be less a matter of 85 connecting ever-growing IPv6 islands in an IPv4 network, and more a 86 matter of the network becoming a patchwork quilt of IPv4, IPv6, and 87 dual domains. 88 o Hosts now generally support IPv6 and IPv4 natively. 89 o As described in [1], the IETF community had expected 90 administrations to turn on IPv6 in their existing IPv4 networks, 91 resulting in a simple coexistence scenario. 92 o Increasingly, we hear statements that people want to move directly 93 to an IPv6-only or IPv6-dominant network. 95 In this context, "IPv6-only" refers to a network or system that only 96 runs IPv6, and "IPv6-dominant" refers to a network or system that may 97 use IPv4 internally or with other clients, but in the context only 98 routes IPv6 datagrams. "IPv4-only" and "IPv4-dominant" are defined 99 similarly. Since these are indistinguishable to the peer, the terms 100 "IPv4-only" and "IPv6-only" will be used in this paper and considered 101 to subsume the "dominant" issues. 103 2.1. Transition scenarios 105 There are six obvious transition scenarios: 106 o IPv4 system connecting to an IPv4 system across an IPv4 network, 107 o An IPv6 system connecting to an IPv6 system across an IPv6 108 network, 109 o an IPv4 system connecting to an IPv4 system across an IPv6 110 network, 111 o an IPv6 system connecting to an IPv6 system across an IPv4 112 network, 113 o an IPv4 system connecting to an IPv6 system, or 114 o an IPv6 system connecting to an IPv4 system. 116 2.1.1. Simple transition scenarios 118 The simplest coexistence cases are about an IPv4 system connecting to 119 an IPv4 system across an IPv4 network, or an IPv6 system connecting 120 to an IPv6 system across an IPv6 network. The dual stack case, in 121 which both endpoints and the relevant applications support IPv4 and 122 IPv6 and the network supports at least one of the protocols, falls 123 into this case as the applications can connect using whichever stack 124 is consistent end to end. 126 The IETF strongly prefers and recommends this scenario, as the 127 operational matters are the simplest. Until the Internet reaches 128 IPv4 address exhaustion, an IPv4 and an IPv6 address can be assigned 129 to every interface, and the applications are supported. When it 130 becomes necessary to deploy only IPv6 addresses, since all other 131 systems have both, IPv6-only systems cleanly interoperate with 132 existing systems. 134 2.1.2. Transition scenarios that do not require translation 136 [1] discusses the scenario in Figure 1, in which routers connect two 137 dual domains via an IPv4-only domain. Obviously, this can be 138 reversed: routers can connect two dual domains via an IPv6-only 139 domain. Note that the connecting domain need not actually be IPv4- 140 only or IPv6-only; to create this scenario, it need merely fail to 141 offer IPv6 or IPv4 services to the neighboring domains. 143 ,-. ,-. ,-. 144 ,' `. ,' `. ,' `. 145 ; : ; : ; : 146 ; IPv4+ : ; IPv4- : ; IPv4+ : 147 ; IPv6 : ; only : ; IPv6 : 148 ; Domain : ; Domain : ; Domain : 149 ; : ; : ; : 150 | +----+ | | +----+ | | +----+ | 151 | |IPv4| | | |IPv4| | | |IPv4| | 152 | |Host+ | | |Host| | | |Host| | 153 : +----+\ ; : /+----+\ ; :/ +----+ ; 154 : +----+ \+------+ +------+ +----+ ; 155 : |IPv6+--+Router+=======+Router+-+IPv6| ; 156 :|Host| ;+------+ +------+:|Host| ; 157 :+----+ ; : ; :+----+ ; 158 `. ,' `. ,' `. ,' 159 `-' `-' `-' 161 Figure 1: Disconnected continuity 163 In such a scenario, there are two obvious solutions: one can tunnel 164 across the connecting domain, as shown, or one can translate between 165 IP layers using something akin to traditional NAT technology. The 166 tunnel approach offers some pros and some cons: it natively connects 167 the dual domains, meaning that all applications should work, but they 168 may have issues with the path MTU, and the tunnels require some form 169 of configuration. The NAT approach similarly offers pros and cons: 170 it offers something similar to standard routing, but it suffers from 171 the various ills of Network Address Translation on both sides, 172 meaning that it may be difficult for the dual domains to offer 173 services to each other. 175 In general, the IETF recommends the use of tunnels rather than a dual 176 NAT. 178 There are at least three generic models that could be used to 179 describe this kind of tunneling scenario: 180 o Static tunnels with interior dynamic routing 181 o Start-time negotiated tunnels to some central point with default 182 routing (example in [9]) 183 o Dynamic tunnels with specific routing to islands (examples might 184 include ISATAP [5] or a tunnel broker of some description) 186 Static tunnels with routing through them are commonly deployed today, 187 both in VPNs and in overlay networks. The positive side is that they 188 provide simple service; the negative is that the generally require 189 manual configuration and can result in suboptimal routing. 191 A "start-time" tunnel might be useful in an access network that 192 serves homes or SOHO environments. In this model, the ISP informs 193 the CPE of a cross-network peer that it can create a tunnel to, 194 reducing the case to one similar to static tunneling but without 195 manual configuration. 197 A dynamic tunneling environment is an overlay model in which systems 198 create tunnels to various peers across the connecting domain as 199 needed, based on a priori knowledge of the correlation between remote 200 prefixes and next hop routers. This has not been adequately 201 described at this point, and therefore involves complexities in 202 implementation and deployment. 204 2.1.3. Transition scenarios that require translation 206 Translation, as found in Figure 2, is considered in NAT-PT [6], which 207 has in turn been set aside via [8]. In essence, translation is 208 required when an IPv4-only system connects to an IPv6-only system or 209 an IPv6-only system connects to an IPv4-only system. These systems 210 need not actually be IPv4-only or IPv6-only; if the connecting 211 network is IPv4-only or IPv6-only and provides no tunnel, but only 212 offers IPv4 service to one and only offers IPv6 service to the other, 213 the situation is equivalent. 215 ,-----. ,-----. 216 ,' `. ,' `. 217 / \ / \ 218 / IPv4-only \ / IPv6-only \ 219 / Domain +-----------+ Domain \ 220 ; |Translation| : 221 | | Gateway | | 222 : +-----------+ ; 223 \ +----+ / \ +----+ / 224 \ |IPv4| / \ |IPv6| / 225 \ |Host| / \ |Host| / 226 `. +----+,' `. +----+,' 227 '-----' '-----' 229 Figure 2: Translation 231 In such a scenario, it is necessary for the network to create a 232 translation gateway, at which datagrams from one system are 233 translated forwarded to the other. The situation is in many ways 234 reflexive, since most Internet sessions are bidirectional - TCP 235 between an IPv4 and an IPv6 system translate data messages in one 236 direction and acknowledgments in the other. 238 They are not reflexive, however, in the distribution of domain names. 239 If the application is client-server and the server is in one of the 240 domains, the name of the server need only be propagated to the other. 241 Reverse lookups, frequently used in spam verification would require 242 the client's name to be propagated into the server's domain. But in 243 this there are issues. The address of the client (the TCP peer) as 244 seen by the server is not the remote system in the other domain; it 245 is the translator. This is readily worked around for an IPv6 server, 246 as the IPv4 address of the remote peer can be embedded in a "privacy" 247 address [7], making the reverse lookup viable. This doesn't work on 248 the IPv4 side, however. 250 2.2. Requirements for the overall transition strategy 252 Given the problem statement presented here, we see the following 253 requirements for a complete transition strategy: 254 1. Any transition strategy must contemplate a period of coexistence, 255 with ultimate transition (e.g., turning off IPv4) being a 256 business decision. 257 2. Many are delaying turning on IPv6 (initiating coexistence in 258 their networks) as long as possible. 259 3. Some are turning off IPv4 immediately, at least as a customer 260 service. 262 4. Therefore, dual stack approaches, tunneled architectures, and 263 translation architectures are all on the table. 264 5. Any solution that makes translation between semi-connected 265 islands "normal" has failed the fundamental architecture of the 266 Internet and can expect service complexity to be an issue. [3] 267 6. Translation architectures must provide for the advertisement of 268 IPv4 names to IPv6 systems and vice versa. The address 269 advertised in the "far" domain must be that of the translating 270 gateway. 271 7. Tunneling architectures must provide a way to minimize and 272 ideally eliminate configuration of the tunnel. 274 3. Preliminary analysis for translation mechanisms 276 3.1. Application behavior taxonomy 278 The general purpose of NAT64 type of mechanisms is to enable 279 communication between a v4-only node and a v6-only node. However, 280 there is wide range of type of communications, when considering how 281 they handle IP addresses. So, in order to properly characterize the 282 problem, we need to do an analysis of the different application 283 behavior in terms of the usage of their IP addresses. We will next 284 present a taxonomy of the behavior of the application with respect of 285 how they use the IP address. The support of the different type of 286 behavior will impose a different set of constraints to the design of 287 a NAT64 mechanisms. It is then important to decide which type of 288 application behavior will be supported before starting to design a 289 NAT64 mechanism. The proposed taxonomy is heavily based on the one 290 presented in section 1.1 of draft-ietf-shim6-app-refer-00.txt. 292 The proposed application behavior taxonomy is the following: 294 Short-lived local handle. The IP addresses is never retained by the 295 application. The only usage is for the application to pass it from 296 the DNS APIs (e.g., getaddrinfo()) and the API to the protocol stack 297 (e.g., connect() or sendto()). This type of communication can be 298 either initiated by the v4-only node or by the v6-only node, 299 resulting in two type of behaviors, v4-initiated short lived local 300 handle and v6-initiated short lived local handle. 302 Long-lived application associations. The IP address is retained by 303 the application for several instances of communication. However, it 304 is always the same node that initiates the communication. This type 305 of communication can be either initiated by the v4-only node or by 306 the v6-only node, resulting in two type of behaviors, v4-initiated 307 long-lived associations and v6-initiated long-lived associations. 309 Callbacks. The application at one end retrieves the IP address of 310 the peer and uses that to later communicate "back" to the peer. This 311 type of communication can be either initiated by the v4-only node or 312 by the v6-only node, resulting in two type of behaviors, v4-initiated 313 callback, meaning that the initial communication is initiated by the 314 v6-only node, and later the v4-only node initiates the callback, and 315 v6-initiated callback, meaning that the initial communication is 316 initiated by the v4-only node, and later the v6-only node initiates 317 the callback. An additional disticntion can be made based on the 318 time-frame of the call back operation. There can be short-lived 319 call-backs, where the receiver inmediatelly calls back to the 320 initiator and long-lived call-backs where the receiver calls backs 321 after a while. 323 Referrals. In an application with more than two parties, party B 324 takes the IP address of party A and passes that to party C. After 325 this party C uses the IP address to communicate with A. In this type 326 of communication, the following 6 sub-cases are possible. 327 o A and B are v6-only nodes and C is a v4-only node; 328 o A and C are v6-only nodes and B is a v4-only node, 329 o B and C are v6-only nodes and A is a v4-only node, 330 o A and B are v4-only nodes and C is a v6-only node; 331 o A and C are v4-only nodes and B is a v6-only node, 332 o B and C are v4-only nodes and A is a v6-only node, 334 "Identity" comparison. Some applications might retain the IP 335 address, not as a means to initiate communication as in the above 336 cases, but as a means to compare whether a peer is the same as 337 another peer. While this is insecure in general, it might be 338 something which is used e.g., when TLS is used. This type of 339 communication results in two sub-cases, when the v4-only node 340 performs comparison of the v6-only node identity, and when the v6- 341 only node performs comparison of the v4-only node identity 343 Discussion: is there another type of application that embed IP 344 addresses in the application data that doesn't fit in the previous 345 cases? 347 3.2. Placement of the NAT64 mechanisms 349 Another aspect that is critical to design a NAT64 mechanism is the 350 placement of the mechanisms involved. In other words, what elements 351 can be modified/updated to support the NAT64 mechanisms. We assume 352 that the NAT64 box supports a set of mechanisms that are the core 353 part of the solution, but some approaches may require the 354 modification of additional elements. In particular, we can identify 355 the following additional elements that may require modification to 356 support a NAT64 approach. 358 Modification to v4-only nodes: one option is to require modification 359 to existent v4-only nodes in order to support the NAT64 mechanism. 360 This option would impose high deployment costs, because the existent 361 base of v4-only nodes is really big and there is no incentives for 362 the v4-only nodes to install such mechanism, since it seems unlikely 363 that v4-only nodes will have a strong need to communicate with v6- 364 only nodes (at least at the initial stages of v6 deployment). 365 However, it may be possible that this is the only viable solution for 366 supporting some type of application behavior. 368 Modification to v6-only nodes: Another option is to require 369 modifications to v6-only nodes. This option seems much more 370 acceptable, since the existent base of v6-nodes is relatively small 371 and there would be a strong incentive for v6-only nodes to 372 communicate with v4-only nodes, since most of the contents are 373 available only in v4 today. However, imposing modifications to v6- 374 only nodes does make deployment of the solution more difficult, since 375 update of current v6-implementations is needed. In addition, there 376 is an architectural consideration, that we would be imposing v6-only 377 nodes to support "NAT hacks" in order to enable communication with 378 the v4 world, and that those modifications may stay forever, even 379 when the need for communication with the v4-Internet is not so 380 pressing. 382 Modification to both v4-only nodes and v6-only nodes. Another option 383 is to require updates to both v4-only nodes and also to v6-only 384 nodes. Needless to say that this would be the option with higher 385 deployment costs. 387 No modification. Another option is that the NAT64 mechanisms does 388 not require modification to any host and that the mechanism is fully 389 contained in the NAT64 box. This was the case of the previously 390 defined NAT-PT approach. However, it may be challenging to design a 391 solution with this constraint that does not suffer the limitations 392 suffered by the NAT-PT mechanism that lead the IETF community to 393 deprecate it. 395 Another consideration related to the modification imposed by a NAT64 396 approach is about what elements in the nodes need to be updated. In 397 particular, it is important to determine if only the IP layer on the 398 affected nodes needs to be modified or f other elements in the nodes 399 needs to be updated. In particular, it is critical to determine if 400 applications need to e modified in order to support the NAT64 401 mechanism. 403 3.3. v4 addressing consideration 405 We assume that both the v6-only nodes and the v6 interface of the 406 NAT64 boxes will have routable IPv6 addresses. However, on the v4 407 side, there are more options. Either the v4 interface of the NAT64 408 boxes and/or the v4-only nodes can have either v4 private addresses 409 or v4 public addresses. Actually, it is possible that the different 410 combinations make sense. It seems clear that the case where public 411 v4 addresses are used in both the v4 interface of the NAT64 box and 412 the v4-only nodes is relevant. The case where the v4-only node has a 413 private v4 address and the NAT64 box has a public address seems also 414 possible, but here it seems reasonable to assume that a NAT box will 415 exist between the v4 only node and the NAT64 box. The case where 416 both the v4 node and the NAT64 box have v4 private addresses could 417 also make sense, since this could apply to a scenario where a site 418 that has v4 private addresses and v6 addresses could try to use a 419 NAT64 box internally. The last case, where the v4 node has public 420 address and the NAT64 box has a private address seems harder to 421 justify though. 423 Another consideration related to v4 addressing of the NAT64 approach 424 is the number of addresses required by the NAT64 box. It is possible 425 that some NAT64 approaches require a pool of v4 addresses instead of 426 a single v4 address. Considering the status of the v4 address space 427 consumption, it may not be feasible to use a NAT64 approach that 428 require a big number of v4 public addresses. 430 3.4. Name-space considerations 432 One of the major choices that are faced when designing a NAT4 433 mechanism that enable communication initiated by the v4-only node 434 towards a v6-only node. In this case, the v4 only node needs to 435 identify the v6 only node and the problem is that there is no means 436 to permanently map the v6 address space in the v4 address space. So 437 in order to enable a v4-only node to identify a v6-only node a name 438 space other than the IPv4 address space is needed. We will next 439 discuss some options that could be considered to identify v6 nodes in 440 the v4 world. 442 A first option is to use IPv4 addresses to identify IPv6 nodes. The 443 problem is that the v6 address space is much bigger than the v4 444 address space, so it is not possible to do permanent mapping between 445 these two. This basically implies that dynamic mapping between a 446 given v4 address and different v6 addresses are established. While 447 this works for some type of application behavior, it does not support 448 others, such as communications initiated by a v4 node towards a v6 449 node in a general case (it is possible for a given subset of v6 450 nodes, but not as a general solution) 451 A second option is to use IPv6 addresses themselves. In this case, 452 the IPv4 node is aware of the IPv6 address of the destination and it 453 uses it to identify the target at the NAT64 box. This option would 454 likely imply modifications in the v4 nodes. 456 A third option is to use FQDN to identify nodes. In this case v4 457 nodes identify v6 nodes using FQDNs, which is already supported in 458 the v4 world. The difficulties with such a approach is that DNS ALG 459 are likely to be required. 461 A fourth option is to use a combination of IPv4 address, transport 462 protocol and port for identification of a v6 node or a v6 flow. 464 3.5. Market timing considerations 466 We expect translation mechanism to require deployment in the very 467 near term, prior to IPv4 address depletion, and to be interoperable 468 with end systems that have been deployed in that timeframe. Since 469 address space depletion is expected t occur in the 2010-2012 470 timeframe and host software tends to be changed primarily when people 471 buy new hardware (every 2-3 years on average), we expect that this 472 needs to be compatible with currently-deployed Windows (XP and 473 Vista), MacOSX (Tiger and Leopard), Linux, and Solaris operating 474 systems. That argues for a solution that requires no changes to host 475 software that cannot be reasonably expected to deploy via patch 476 update procedures - this is otherwise all solved in network devices. 478 4. Requirements for new generation of v4-v6 translation mechanisms 480 This list of requirements basically should contain all the aspects 481 that should be considered when designing a new generation of 482 translation mechanisms. 484 4.1. Basic Requirements that MUST be supported 486 These are the requirements for short term mechanism behaviour 488 R1: Changes in the hosts 490 The translation mechanism MUST NOT require changes in the v4-only 491 nodes to support the Basic requirements described in this section. 492 The translation mechanism MAY require changes to v6-only nodes. 494 R2: Basic communication support 496 Translation mechanim must support v4-initiated and v6-initiated (?) 497 short-lived local handle. 499 R3: Interaction with dual-stack hosts 501 Translation mechanism MUST allow using native connectivity when it is 502 available. This means that if a v6-only nodes wants to communicate 503 with a dual stack, it must use native v6 connectivity and if a v4- 504 only nodes wants to communicate with a dual stack, it must use native 505 v4 connectivity.(In this case, dual stack means a host with both IPv6 506 and IPv4 stacks, wich are both active, i.e. they have v4 and v6 507 connectivity). 509 R4: Private Addressing. 511 The translation mechanism MUST support v4-initiated short-lived local 512 handle type of communication when the v4-only node has a private v4 513 address. This covers both the cases when there is a site with v4 514 private addresses and v6 addresses and the case where there is a site 515 connected to the v4 Internet through a NAT. 517 R5: DNS semantics preservation 519 Any modifications to DNS responses associated with translation MUST 520 NOT violate standard DNS semantics. This includesin particular that 521 a DNS response should not be invalid if it ends up in the wrong 522 context, i.e. traversing a non expected part of the topology. 524 R6: Routing 526 IPv6 routing should not be affected in any way, and there should be 527 no risk of importing "entropy" from the IPv4 routing tables into 528 IPv6. 530 R7: Protocols supported 532 The translation mechanism MUST support at least TCP, UDP, ICMP, TLS. 534 R8: Behave-type requirements 536 We could include a set of requirements similar to the ones defined by 537 the BEHAVE WG related to Mapping timeout (5min), Address mapping 538 behaviour (Endpoint independent, Address Dependent, Address and Port 539 dependent), Port Assignment(Port preservation, no port preservation, 540 port overloading), Filtering behaviour (Endpoint independent, Address 541 Dependent, Address and Port dependent). However, this maybe assuming 542 some form of solution, so maybe this should be defined later, once 543 the solution space has been explored. 545 R9: Fragmented packets 546 The translation mechanism MUST suport fragmented packets when the 547 fragments arrive in an ordered fashion. 549 R10: Security 551 The adoption of the translation mechanism MUST not introduce new 552 vulnerabilities in the Internet 554 4.2. Important things that SHOULD be supported 556 I1: DNSSec support 558 DNSSec support SHOULD NOT be prevented. If the translation mechanism 559 is used jointly with DNSSec, then DNSSec requirements take precedence 560 over the translation requirements. Morevoer DNSSec must not be 561 weakened in any way 563 I2: Operational flxibility 565 It should be possible to locate the translation device at an 566 arbitrary point in the network (i.e. not at fixed points such as a 567 site exit), so that there is full operational flexibility. 569 I3: Central Management 571 Any configuration need for an IPv6 host to make use of the mechanism 572 should be possible centrally, e.g. a DHCP option. 574 I4: Fragmented packets bis 576 The translation mechanism SHOULD suport fragmented packets when the 577 fragments arrive in an out of order fashion. 579 I5: Richer application behaviour support 581 The translation mechanism SHOULD support the other types of 582 application behaviours, including Long-lived application 583 associations, callbacks and referrals.In order to support this. the 584 translation mechanism MAY require changes to v4-only nodes too 586 I6: MIPv6 support 588 The translation mechanism SHOULD not prevent MIPv6 Route Optimization 589 when the CN is a v4-only node 591 I7: SCTP support 593 The translation mechanism SHOULD not prevent a SCTP communication 594 between a v6-only node and a v4-only node 596 I8: DCCP support 598 The translation mechanism SHOULD not prevent a DCCP communication 599 between a v6-only node and a v4-only node 601 I9: Multicast support 603 The translation mechanism SHOULD not prevent multicast traffic 604 between the v4-only nodes and the v6-only nodes. 606 4.3. Non-goals 608 It would be important that the translation mechanism could support 609 IPSec using AH and ESP both in tunnel and transport modes. However, 610 IPSec and translation approaches seem hardly compatible, so it is 611 non-goal trying to support IPSec through the translation mechanism. 613 5. Contributors 615 This draft contains contributions from Iljitsch van Beijnum, Brian 616 Carpenter and Elwyn Davies (this doesn't mean that they agree on the 617 draft, just that we have used text provided by them). 619 6. Security considerations 621 TBD 623 7. Acknowledgments 625 Marcelo Bagnulo is partly funded by Trilogy, a research project 626 supported by the European Commission under its Seventh Framework 627 Program. 629 8. References 631 8.1. Normative References 633 [1] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 634 IPv6 Hosts and Routers", RFC 4213, October 2005. 636 [2] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 637 Co-existence Security Considerations", RFC 4942, September 2007. 639 8.2. Informative References 641 [3] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines 642 and Philosophy", RFC 3439, December 2002. 644 [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 645 Specification", RFC 2460, December 1998. 647 [5] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site 648 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, 649 October 2005. 651 [6] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 652 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 654 [7] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for 655 Stateless Address Autoconfiguration in IPv6", RFC 4941, 656 September 2007. 658 [8] Aoun, C. and E. Davies, "Reasons to Move the Network Address 659 Translator - Protocol Translator (NAT-PT) to Historic Status", 660 RFC 4966, July 2007. 662 [9] Stenberg, M. and O. Troan, "IPv6 Prefix Delegation routing state 663 maintenance approaches", 664 draft-stenberg-v6ops-pd-route-maintenance-00 (work in progress), 665 December 2007. 667 Authors' Addresses 669 Marcelo Bagnulo 670 Huawei Labs at Universidad Carlos III de Madrid 671 Av. Universidad 30 672 Leganes, Madrid 28911 673 SPAIN 675 Phone: 34 91 6249500 676 Email: marcelo@it.uc3m.es 677 URI: http://www.it.uc3m.es 678 Fred Baker 679 Cisco Systems 680 Santa Barbara, California 93117 681 USA 683 Phone: +1-408-526-4257 684 Fax: +1-413-473-2403 685 Email: fred@cisco.com 687 Full Copyright Statement 689 Copyright (C) The IETF Trust (2008). 691 This document is subject to the rights, licenses and restrictions 692 contained in BCP 78, and except as set forth therein, the authors 693 retain all their rights. 695 This document and the information contained herein are provided on an 696 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 697 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 698 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 699 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 700 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 701 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 703 Intellectual Property 705 The IETF takes no position regarding the validity or scope of any 706 Intellectual Property Rights or other rights that might be claimed to 707 pertain to the implementation or use of the technology described in 708 this document or the extent to which any license under such rights 709 might or might not be available; nor does it represent that it has 710 made any independent effort to identify any such rights. Information 711 on the procedures with respect to rights in RFC documents can be 712 found in BCP 78 and BCP 79. 714 Copies of IPR disclosures made to the IETF Secretariat and any 715 assurances of licenses to be made available, or the result of an 716 attempt made to obtain a general license or permission for the use of 717 such proprietary rights by implementers or users of this 718 specification can be obtained from the IETF on-line IPR repository at 719 http://www.ietf.org/ipr. 721 The IETF invites any interested party to bring to its attention any 722 copyrights, patents or patent applications, or other proprietary 723 rights that may cover technology that may be required to implement 724 this standard. Please address the information to the IETF at 725 ietf-ipr@ietf.org. 727 Acknowledgment 729 Funding for the RFC Editor function is provided by the IETF 730 Administrative Support Activity (IASA).