idnits 2.17.1 draft-baker-v6ops-end2end-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 795. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (August 12, 2005) is 6832 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) == Missing Reference: 'RFC2766' is mentioned on line 670, but not defined ** Obsolete undefined reference: RFC 2766 (Obsoleted by RFC 4966) == Missing Reference: 'I-D.despres-v6ops-transition-v5roadmap' is mentioned on line 567, but not defined == Missing Reference: 'I-D.huitema-v6ops-teredo' is mentioned on line 572, but not defined == Missing Reference: 'I-D.ietf-v6ops-3gpp-analysis' is mentioned on line 577, but not defined == Missing Reference: 'I-D.ietf-v6ops-ent-analysis' is mentioned on line 582, but not defined == Missing Reference: 'I-D.ietf-v6ops-ipsec-tunnels' is mentioned on line 587, but not defined == Missing Reference: 'I-D.ietf-v6ops-mech-v2' is mentioned on line 592, but not defined == Missing Reference: 'I-D.ietf-v6ops-natpt-to-exprmntl' is mentioned on line 597, but not defined == Missing Reference: 'I-D.jaehwoon-dstm-multitep' is mentioned on line 602, but not defined == Missing Reference: 'I-D.lee-v6ops-natpt-mobility' is mentioned on line 607, but not defined == Missing Reference: 'I-D.massar-v6ops-heartbeat' is mentioned on line 612, but not defined == Missing Reference: 'I-D.massar-v6ops-tunneldiscovery' is mentioned on line 617, but not defined == Missing Reference: 'I-D.ooms-v6ops-bgp-tunnel' is mentioned on line 622, but not defined == Missing Reference: 'I-D.palet-v6tc-goals-tunneling' is mentioned on line 628, but not defined == Missing Reference: 'I-D.parent-v6tc-protocol-exploration' is mentioned on line 633, but not defined == Missing Reference: 'I-D.reddy-dhcpv6-opt-dstm-exp' is mentioned on line 638, but not defined == Missing Reference: 'I-D.shin-dstm-ports' is mentioned on line 644, but not defined == Missing Reference: 'I-D.yamamoto-v6tc-security-considerations' is mentioned on line 648, but not defined == Missing Reference: 'RFC2460' is mentioned on line 654, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'RFC2473' is mentioned on line 657, but not defined == Missing Reference: 'RFC2529' is mentioned on line 660, but not defined == Missing Reference: 'RFC2663' is mentioned on line 663, but not defined == Missing Reference: 'RFC2765' is mentioned on line 667, but not defined ** Obsolete undefined reference: RFC 2765 (Obsoleted by RFC 6145) == Missing Reference: 'RFC2767' is mentioned on line 674, but not defined ** Obsolete undefined reference: RFC 2767 (Obsoleted by RFC 6535) == Missing Reference: 'RFC2772' is mentioned on line 678, but not defined == Missing Reference: 'RFC2775' is mentioned on line 681, but not defined == Missing Reference: 'RFC2784' is mentioned on line 684, but not defined == Missing Reference: 'RFC3053' is mentioned on line 688, but not defined == Missing Reference: 'RFC3068' is mentioned on line 691, but not defined ** Obsolete undefined reference: RFC 3068 (Obsoleted by RFC 7526) == Missing Reference: 'RFC3964' is mentioned on line 694, but not defined == Missing Reference: 'RFC4031' is mentioned on line 697, but not defined == Unused Reference: 'RFC2119' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'I-D.bound-dstm-exp' is defined on line 523, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1958 ** Downref: Normative reference to an Informational RFC: RFC 2185 ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) -- Possible downref: Non-RFC (?) normative reference: ref. 'Saltzer' == Outdated reference: A later version (-04) exists of draft-blanchet-v6ops-tunnelbroker-tsp-02 == Outdated reference: A later version (-04) exists of draft-bound-dstm-exp-03 -- Obsolete informational reference (is this intentional?): RFC 1933 (Obsoleted by RFC 2893) -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 11 errors (**), 0 flaws (~~), 37 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations F. Baker 3 Internet-Draft Cisco Systems 4 Expires: February 13, 2006 August 12, 2005 6 The End to End Problem in a fully generalized IPv4, IPv6, and IPv4+IPv6 7 network 8 draft-baker-v6ops-end2end-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 13, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This note is intended to describe the end to end problem as it 42 applies to a network of networks, wherein some component networks 43 independently run only IPv4 with or without a transition mechanism, 44 some run only IPv6 with or without a transition mechanism and without 45 coordination of transition mechanisms, and some run IPv4 and IPv6 in 46 parallel supporting native routing. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Transition, and transition problems . . . . . . . . . . . . . 4 53 2.1 A provably correct transition plan . . . . . . . . . . . . 4 54 2.2 The IPv4 rendezvous problem . . . . . . . . . . . . . . . 6 55 2.3 The IPv6 rendezvous problem . . . . . . . . . . . . . . . 6 56 2.4 And then there is multicast... . . . . . . . . . . . . . . 7 58 3. End to end arguments in transition design . . . . . . . . . . 8 59 3.1 The end to end problem in IPv6 over or in IPv4 . . . . . . 8 60 3.2 The end to end problem in IPv4 over or in IPv6 . . . . . . 9 61 3.3 Mutual encapsulation considered bizarre . . . . . . . . . 10 63 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.1 Normative References . . . . . . . . . . . . . . . . . . . 16 73 8.2 Informative References . . . . . . . . . . . . . . . . . . 16 74 8.3 More Informative References . . . . . . . . . . . . . . . 17 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 78 A. Requirements for a general transition strategy . . . . . . . . 21 80 Intellectual Property and Copyright Statements . . . . . . . . 23 82 1. Introduction 84 This note is intended to describe the end to end problem as it 85 applies to a network of networks, wherein some component networks 86 independently run only IPv4 with or without a transition mechanism, 87 some run only IPv6 with or without a transition mechanism and without 88 coordination of transition mechanisms, and some run IPv4 and IPv6 in 89 parallel supporting native routing. This is to say that the IETF 90 recommendations in [RFC2893] and [RFC4029] are not necessarily 91 implemented during IPv6 deployment, and this creates issues for the 92 Internet as a whole. 94 [RFC1958] states that 96 Many members of the Internet community would argue that there is 97 no architecture, but only a tradition, which was not written 98 down for the first 25 years (or at least not by the IAB). 99 However, in very general terms, the community believes that the 100 goal is connectivity, the tool is the Internet Protocol, and the 101 intelligence is end to end rather than hidden in the network. 103 The current exponential growth of the network seems to show that 104 connectivity is its own reward, and is more valuable than any 105 individual application such as mail or the World-Wide Web. This 106 connectivity requires technical cooperation between service 107 providers, and flourishes in the increasingly liberal and 108 competitive commercial telecommunications environment. 110 The key to global connectivity is the inter-networking layer. 111 The key to exploiting this layer over diverse hardware providing 112 global connectivity is the "end to end argument". 114 This note starts from those key observations, including the End to 115 End Argument (which will be spelled out in Section 3), and raises a 116 very deep concern about the wild proliferation of mutually 117 incompatible transition strategies with little or no useful guidance 118 from the networking community. 120 2. Transition, and transition problems 122 Much has been written about possible transition scenarios, and about 123 the transition from an IPv4 to an IPv6 Internet. [RFC2185], which is 124 somewhat dated, comments on the Routing Aspects of the transition. 125 [RFC2893] proposes basic Transition Mechanisms. [RFC3574] comments 126 on the Transition Scenarios for 3GPP Networks. [RFC3750] looks at 127 unmanaged networks, and [RFC3904] evaluates that approach. [RFC4038] 128 comments on the application issues. Numerous other documents look at 129 specific transition scenarios and propose various ways to translate 130 between IPv4 and IPv6 in a gateway at the network layer, tunnel IPv4 131 over IPv6 or IPv6 over IPv4, and rendezvous between systems of either 132 type over networks running the other. 134 2.1 A provably correct transition plan 136 A provably correct algorithm, in mathematical terms, is one for which 137 a proof can be presented demonstrating that it works without error in 138 all cases. It is not exclusive: there may also be other algorithms 139 that work correctly, and the fact may or may not be readily proven. 141 The IETF's current recommendation, originally proposed in [RFC1933] 142 and now documented in [RFC2893] is that the best possible transition 143 mechanism envisions these steps: 145 1. The basic network runs IPv4 forwarding and routing. 147 2. IPv6 forwarding and routing is added to that network, either by 148 tunneling IPv6 over IPv4 or by directly bringing IPv6 forwarding 149 and routing up in parallel with the IPv4 network. 151 3. Applications determine whether IPv6 connectivity is available 152 between them, and if so use it; otherwise, they default to IPv4, 153 which is presumed to work. 155 4. A market develops, driving IPv6 deployment to also become 156 essentially ubiquitous. The key steps in this development 157 include 159 * administrations obtaining and deploying IPv6 address space, 160 perhaps in response to increasingly stringent IPv4 prefix 161 allocation guidelines or diminishing allocation availability, 163 * business drivers toward end to end connectivity that are not 164 readily solved using NAT traversal techniques, 166 * some edge networks administrations deploying only IPv6, and 167 * other administrations needing to communicate with the IPv6- 168 only administrations or using IPv6-only applications. 170 5. At some point in the (very) distant future, IPv6 connectivity is 171 sufficiently ubiquitous that IPv4 connectivity becomes 172 unnecessary. At this point, businesses independently remove IPv4 173 from the network as being no longer useful. 175 Within a single administration, one could imagine that central IPv4 176 network being instead an IPv6 network with IPv4 connectivity provided 177 over it by tunneling. Within a single administration, this is 178 workable, as the administration is in control of all access to that 179 network and the basic paradigm is preserved (IPv4 connectivity is 180 ubiquitous and IPv6 connectivity is growing). The key point is that 181 at the network edge, IPv4 and IPv6 always run natively, providing 182 robust IPv4 services until IPv6 becomes ubiquitous, and after that 183 robustly provides IPv6 connectivity, and other transition mechanisms 184 if used operate within a single administration. 186 A network connecting IPv6 over an IPv4 core is as shown in Figure 1. 187 The gateways may be provided by the central network or by its 188 clients; the key point is that they interoperate. 190 ,---. ,---. 191 ,' `. ,' `. 192 / \ / \ 193 / \ / \ 194 ; IPv6+IPv4 : ; IPv4 : 195 | Network | | Network | 196 : ; ,---. : ; 197 \ +----+,' `.+--\ / 198 \ | GW | \ R \ / 199 `. ,+----+ \---+`. ,' 200 '---' : IPv4 : '---' 201 | Network | 202 ,---. : ; ,---. 203 ,' `.+--\ +----+,' `. 204 / \ R \ | GW | \ 205 / \---+`. ,'+----+ \ 206 ; IPv4 : '---' ; IPv6+IPv4 : 207 | Network | | Network | 208 : ; : ; 209 \ / \ / 210 \ / \ / 211 `. ,' `. ,' 212 '---' '---' 214 Figure 1: An end to end IPv4 network with potential IPv6 connectivity 215 This is not without risk; there is concern in some sectors that 216 relatively new IPv6 services might destabilize IPv4 services in a 217 domain. However, it is provably correct. There may or may not be 218 IPv6 connectivity between any two points in the network, but if the 219 entire network is running and routing IPv4, there is at minimum IPv4 220 connectivity. 222 2.2 The IPv4 rendezvous problem 224 If static tunneling of IPv6 traffic over an IPv4 infrastructure, such 225 as the 6bone, is used, routing IPv6 through the tunnels is not hard. 226 There is a problem in the second step, however, if dynamic tunneling 227 (or translation) is used; there must be some means for a system on 228 one side of an IPv4-only domain to determine the ingress and egress 229 gateways between which to tunnel. The ingress and egress systems 230 must, of course, interoperate, and must provide a path that gets 231 traffic between the relevant endpoints. Various approaches have been 232 suggested, including 234 o advertising DNS names of end systems with the addresses of 235 translators between naming domains [RFC2694][RFC2766], 237 o Automated Tunneling [RFC3056], 239 o Translating IPv4 addresses to IPv6 addresses in IPv6 routing 240 [RFC3513] section 2.5.5, 242 o Tunnel Brokers [I-D.blanchet-v6ops-tunnelbroker-tsp], 244 o The use of an address server to determine the appropriate egress 245 gateway address from the ingress gateway or end system[I-D.bound- 246 dstm-exp], 248 o The use of an address server to interconnect IPv4 NATs 249 [I-D.liumin-v6ops-silkroad], 251 o and a variety of others. 253 2.3 The IPv6 rendezvous problem 255 At this point, various administrations are deploying or considering 256 deploying IPv6-only or what are called "IPv6-dominant" networks. An 257 IPv6-dominant network is one that internally routes only IPv6 and 258 perhaps only forwards IPv6, and provides IPv4 services by tunneling 259 or translation to IPv6. The problem noted in the preceding paragraph 260 applies equally to such networks; there must be a way to establish 261 IPv4 routes over the intervening IPv6 network, and if dynamic 262 tunneling is used, there must be a way to dynamically determine the 263 appropriate ingress and egress gateways. 265 2.4 And then there is multicast... 267 There is a saying in IETF circles concerning routing, which is the 268 issue addressed in this document. "There is a simple test that will 269 tell whether one understands a given routing problem adequately, and 270 whether a given solution is adequate to cover the routing issues. 271 Simply repeat the sentence used to describe the solution using the 272 word 'Multicast'". 274 There is need for additional transition work regarding deployment of 275 IPv6 multicast. 277 3. End to end arguments in transition design 279 In [Saltzer], Saltzer and Reed discussed a fundamental argument, 280 which they call the End to End Argument. This has been stated in 281 many ways, but at its simplest it states that unnecessary complexity 282 in a network results in side-effects that decrease performance, 283 reduce functionality, and in the worst case cause the system to fail 284 in some way. The paper argues that unnecessary network complexity is 285 to be avoided, leaving maximum flexibility to the end system to 286 innovate and change. "A satisfactory solution", it could be said, 287 "contains no unnecessary complexity", and "first, does no harm." 289 3.1 The end to end problem in IPv6 over or in IPv4 291 Figure 2 shows a network that has multiple transition strategies for 292 IPv6 connectivity. Granting that each transition strategy works in 293 isolation, and therefore the two IPv6 networks connected via 294 transition strategy A inter-work and the two IPv6 networks connected 295 via transition strategy B inter-work, it is not obvious that all four 296 IPv6 networks inter-work. 298 ,---. ,---. 299 ,' `. ,' `. 300 / \ / \ 301 / \ / \ 302 ; IPv6+IPv4 : ; IPv6+IPv4 : 303 | Network | | Network | 304 : ; ,---. ,---. : ; 305 \ +----+,' `. ,' `.+----+ / 306 \ |GW-A| \ / |GW-B| / 307 `. ,+----+ \ / +----+`. ,' 308 '---' : IPv4 :: IPv4 : '---' 309 | Network || Network | 310 ,---. : Transition ;: Transition : ,---. 311 ,' `.+----+ Strategy / \ Strategy +----+,' `. 312 / |GW-A| A / \ B |GW-B| \ 313 / +----+`. ,' `. ,'+----+ \ 314 ; IPv6+IPv4 : '---' '---' ; IPv6+IPv4 : 315 | Network | | Network | 316 : ; : ; 317 \ / \ / 318 \ / \ / 319 `. ,' `. ,' 320 '---' '---' 322 Figure 2: An end to end network with multiple support strategies for 323 IPv6 325 The problem is, of course, that the transition strategies are not 326 necessarily compatible. Imagine, for example, that strategy A 327 depends on routing to distribute the IPv4 addresses of edge dual 328 stack routers, enabling them to dynamically create tunnels as needed, 329 while strategy B depends on DNS for this function. While both of the 330 IPv4 cores are providing IPv6 transition services, neither will 331 directly interoperate with the other. 333 If the central IPv4 networks are providing the transition strategy, 334 they have the opportunity to bridge the two together. The means to 335 do this is unspecified, however, and may be problematic. In the 336 example just given, one domain might have to poll all names in the 337 other domain in order to map the addresses. If the transition 338 strategies are implemented by the edge networks around the IPv4 339 domains, however, they will be unaware of the other part of the 340 network and will not know to translate. For them, the only option is 341 to provide both transition strategies (BGP NHRP-like extensions *and* 342 DNS lookups) in their gateways and perform the correct transition for 343 any given address - which they can only do if they know the 344 difference between routes from different domains. 346 In the early stages of the transition plan mentioned in Section 2, 347 this is perfectly acceptable. During the interval in which IPv6 348 connectivity is not guaranteed end to end, there is no expectation of 349 such a guarantee. IPv4 continues to operate end to end, and that is 350 sufficient during the early stages of the transition. 352 3.2 The end to end problem in IPv4 over or in IPv6 354 Figure 3 Addresses the mirror issue raised in Section 2.3. As in 355 Section 3.1, it shows a network that has multiple transition 356 strategies for IPv4 connectivity over intervening IPv6 networks. 357 Granting that each transition strategy works in isolation, and 358 therefore the two IPv4 networks connected via transition strategy A 359 inter-work and the two IPv4 networks connected via transition 360 strategy B inter-work, it is not obvious that all four IPv4 networks 361 inter-work. 363 ,---. ,---. 364 ,' `. ,' `. 365 / \ / \ 366 / \ / \ 367 ; IPv6+IPv4 : ; IPv6+IPv4 : 368 | Network | | Network | 369 : ; ,---. ,---. : ; 370 \ +----+,' `. ,' `.+----+ / 371 \ |GW-A| \ / |GW-B| / 372 `. ,+----+ \ / +----+`. ,' 373 '---' : IPv6 :: IPv6 : '---' 374 | Network || Network | 375 ,---. : Transition ;: Transition : ,---. 376 ,' `.+----+ Strategy / \ Strategy +----+,' `. 377 / |GW-A| A / \ B |GW-B| \ 378 / +----+`. ,' `. ,'+----+ \ 379 ; IPv6+IPv4 : '---' '---' ; IPv6+IPv4 : 380 | Network | | Network | 381 : ; : ; 382 \ / \ / 383 \ / \ / 384 `. ,' `. ,' 385 '---' '---' 387 Figure 3: An end to end network with multiple support strategies for 388 IPv4 390 Once again, the transition strategies are not necessarily compatible. 391 If, for example, strategy A depends on a tunnel server between IPv4 392 NATs around an IPv6 core, and strategy B depends on distribution of 393 the IPv6 address of the gateway in BGP, IPv4 connectivity across the 394 combined IPv6 domains will be problematic. 396 In the final stages of the transition plan mentioned in Section 2, 397 this is perfectly acceptable. At the point where IPv4 support 398 becomes a lower business priority, IPv6 connectivity is presumed to 399 exist end to end, and there is no longer a need, and therefore no 400 continuing expectation, of such a guarantee. IPv6 continues to 401 operate end to end, and that is sufficient during the final stages of 402 the transition. 404 3.3 Mutual encapsulation considered bizarre 406 Figure 4 shows the network this author greatly fears that we are in 407 the process of building. It combines the worst parts of Section 3.1 408 with the worst effects of Section 3.2, resulting in a network in 409 which neither IPv4 nor IPv6 connectivity is guaranteed between any 410 two points. 412 ,---. ,---. 413 / \ / \ 414 / \ / \ 415 ; IPv4+6 : ; IPv4+6 : 416 | Network | | Network | 417 : +----+---. ,---. ,---. ,---+----+ ; 418 \ |GW-A| \ / \ / \ / |GW-D| / 419 \ +----+ +----+ \ / +----+ +----+ / 420 `---' ; IPv6 |GW-B| IPv4 : ; IPv4 |GW-C| IPv6 : `---' 421 | Network+----+Network | | Network----+Network | 422 ,---. :Transition :Transition :Transition :Transition ,---. 423 / +----+A / \ B / \ C / \ D+----+ \ 424 / |GW-A| / \ / \ / \ |GW-D| \ 425 ; IPv4+6+----+--' `---' `---' `--+----+IPv4+6 : 426 | Network | | Network | 427 : ; : ; 428 \ / \ / 429 \ / \ / 430 `---' `---' 432 Figure 4: An end to end network with multiple transition strategies 434 The problem is that there is a continuing requirement for some form 435 of connectivity, whether IPv4 or IPv6, but neither can be guaranteed 436 in such a network. 438 The trap here is local optimizations for what some might consider to 439 be an isolated network. While each individual local optimization may 440 work in isolation, there is no guarantee that the network of networks 441 it uses as its context works, and therefore its connectivity or the 442 connectivity of others may be limited by the choices it makes. 444 4. Recommendation 446 In the opinion of this writer, Section 2 provably works despite the 447 kinds of problems raised in Section 3.1 or Section 3.2. The problems 448 those sections raise result from the complexities in the network 449 related to the transition strategies in use, which from the 450 perspective of the argument in [Saltzer] are unnecessary complexities 451 that result in a failure of the network to deliver connectivity. The 452 problems that extra complexity causes are acceptable only because 453 connectivity is in fact guaranteed in another way. 455 In comparison, Section 3.3 provably fails to guarantee connectivity 456 by either IPv4 or IPv6. The "unnecessary complexities" tolerated by 457 Section 3.1 overwhelm the network to cause utter connectivity 458 failure. As a result, although "current exponential growth of the 459 network seems to show that connectivity is its own reward, and is 460 more valuable than any individual application such as mail or the 461 World-Wide Web", the network we are well on our way to creating fails 462 to deliver that fundamental characteristic. This transition non- 463 plan, through negligence, fails the "do no harm" test. 465 In the mind of this writer, therefore, the scenarios contemplated in 466 Section 3 are to be avoided at all costs. Rather than allowing a 467 proliferation of incompatible transition approaches, the IETF must 468 recommend a provably correct transition approach that supports 469 Section 2 throughout each of its steps. 471 5. IANA Considerations 473 This memo adds no new IANA considerations. 475 Note to RFC Editor: This section will have served its purpose if it 476 correctly tells IANA that no new assignments or registries are 477 required, or if those assignments or registries are created during 478 the RFC publication process. From the author's perspective, it may 479 therefore be removed upon publication as an RFC at the RFC Editor's 480 discretion. 482 6. Security Considerations 484 One could view the problem analysis that is at the heart of this 485 document as a security consideration. In any event, the document 486 does not create new problems. It points out a set of problems that 487 already exist. 489 7. Acknowledgements 491 Detailed comments were received from Dave Green, Dave Ward, Pekka 492 Savola, Ralph Droms, Steve Klynsma, Stig Venaas, and Tim Chown. Dave 493 Green suggested the text found in Appendix A. 495 8. References 497 8.1 Normative References 499 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 500 RFC 1958, June 1996. 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, March 1997. 505 [RFC2185] Callon, R. and D. Haskin, "Routing Aspects Of IPv6 506 Transition", RFC 2185, September 1997. 508 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 509 IPv6 Hosts and Routers", RFC 2893, August 2000. 511 [Saltzer] Saltzer, JH. and DP. Reed, "End-to-end arguments in system 512 design", ACM Transactions on Computer Systems (TOCS) v.2 513 n.4, p277-288, Nov 1984. 515 8.2 Informative References 517 [I-D.blanchet-v6ops-tunnelbroker-tsp] 518 Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the 519 Tunnel Setup Protocol (TSP)", 520 draft-blanchet-v6ops-tunnelbroker-tsp-02 (work in 521 progress), May 2005. 523 [I-D.bound-dstm-exp] 524 Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism 525 (DSTM)", draft-bound-dstm-exp-03 (work in progress), 526 July 2005. 528 [I-D.liumin-v6ops-silkroad] 529 Min, L., "Tunneling IPv6 with private IPv4 addresses 530 through NAT devices", draft-liumin-v6ops-silkroad-03 (work 531 in progress), July 2005. 533 [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 534 IPv6 Hosts and Routers", RFC 1933, April 1996. 536 [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. 537 Heffernan, "DNS extensions to Network Address Translators 538 (DNS_ALG)", RFC 2694, September 1999. 540 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 541 via IPv4 Clouds", RFC 3056, February 2001. 543 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 544 (IPv6) Addressing Architecture", RFC 3513, April 2003. 546 [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", 547 RFC 3574, August 2003. 549 [RFC3750] Huitema, C., Austein, R., Satapati, S., and R. van der 550 Pol, "Unmanaged Networks IPv6 Transition Scenarios", 551 RFC 3750, April 2004. 553 [RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der 554 Pol, "Evaluation of IPv6 Transition Mechanisms for 555 Unmanaged Networks", RFC 3904, September 2004. 557 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 558 Savola, "Scenarios and Analysis for Introducing IPv6 into 559 ISP Networks", RFC 4029, March 2005. 561 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 562 Castro, "Application Aspects of IPv6 Transition", 563 RFC 4038, March 2005. 565 8.3 More Informative References 567 [I-D.despres-v6ops-transition-v5roadmap] 568 Despres, R., "The v5 Approach for the Transition from IPv4 569 to IPv6", draft-despres-v6ops-transition-v5roadmap-00 570 (work in progress), July 2005. 572 [I-D.huitema-v6ops-teredo] 573 Huitema, C., "Teredo: Tunneling IPv6 over UDP through 574 NATs", draft-huitema-v6ops-teredo-05 (work in progress), 575 April 2005. 577 [I-D.ietf-v6ops-3gpp-analysis] 578 Wiljakka, J., "Analysis on IPv6 Transition in 3GPP 579 Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in 580 progress), October 2004. 582 [I-D.ietf-v6ops-ent-analysis] 583 Bound, J., "IPv6 Enterprise Network Analysis", 584 draft-ietf-v6ops-ent-analysis-03 (work in progress), 585 July 2005. 587 [I-D.ietf-v6ops-ipsec-tunnels] 588 Savola, P., "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 589 draft-ietf-v6ops-ipsec-tunnels-00 (work in progress), 590 July 2005. 592 [I-D.ietf-v6ops-mech-v2] 593 Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 594 for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 595 (work in progress), March 2005. 597 [I-D.ietf-v6ops-natpt-to-exprmntl] 598 Aoun, C. and E. Davies, "Reasons to Move NAT-PT to 599 Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work 600 in progress), July 2005. 602 [I-D.jaehwoon-dstm-multitep] 603 Lee, J., "Multiple TEP Extension to DSTM", 604 draft-jaehwoon-dstm-multitep-02 (work in progress), 605 July 2005. 607 [I-D.lee-v6ops-natpt-mobility] 608 Shin, M. and J. Lee, "Considerations for Mobility Support 609 in NAT-PT", draft-lee-v6ops-natpt-mobility-01 (work in 610 progress), July 2005. 612 [I-D.massar-v6ops-heartbeat] 613 Massar, J., "SixXS Heartbeat Protocol", 614 draft-massar-v6ops-heartbeat-01 (work in progress), 615 June 2005. 617 [I-D.massar-v6ops-tunneldiscovery] 618 Massar, J., "IPv6 Tunnel Discovery", 619 draft-massar-v6ops-tunneldiscovery-00 (work in progress), 620 July 2005. 622 [I-D.ooms-v6ops-bgp-tunnel] 623 Clercq, J., "Connecting IPv6 Islands over IPv4 MPLS using 624 IPv6 Provider Edge Routers (6PE)", 625 draft-ooms-v6ops-bgp-tunnel-05 (work in progress), 626 May 2005. 628 [I-D.palet-v6tc-goals-tunneling] 629 Palet, J., "Goals for Tunneling Configuration", 630 draft-palet-v6tc-goals-tunneling-00 (work in progress), 631 February 2005. 633 [I-D.parent-v6tc-protocol-exploration] 634 Parent, F., "v6tc Protocol Exploration", 635 draft-parent-v6tc-protocol-exploration-00 (work in 636 progress), December 2004. 638 [I-D.reddy-dhcpv6-opt-dstm-exp] 639 Reddy, A. and J. Bound, "Dual Stack Transition Mechanism 640 (DSTM) Options for DHCPv6", 641 draft-reddy-dhcpv6-opt-dstm-exp-00 (work in progress), 642 April 2005. 644 [I-D.shin-dstm-ports] 645 Shin, M., "Ports Option Support in DSTM", 646 draft-shin-dstm-ports-00 (work in progress), June 2005. 648 [I-D.yamamoto-v6tc-security-considerations] 649 Yamamoto, S., "Security Considerations for the Tunnel 650 Broker Model", 651 draft-yamamoto-v6tc-security-considerations-00 (work in 652 progress), July 2005. 654 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 655 (IPv6) Specification", RFC 2460, December 1998. 657 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 658 IPv6 Specification", RFC 2473, December 1998. 660 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 661 Domains without Explicit Tunnels", RFC 2529, March 1999. 663 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 664 Translator (NAT) Terminology and Considerations", 665 RFC 2663, August 1999. 667 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 668 (SIIT)", RFC 2765, February 2000. 670 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 671 Translation - Protocol Translation (NAT-PT)", RFC 2766, 672 February 2000. 674 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 675 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 676 RFC 2767, February 2000. 678 [RFC2772] Rockell, R. and B. Fink, "6Bone Backbone Routing 679 Guidelines", RFC 2772, February 2000. 681 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 682 February 2000. 684 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 685 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 686 March 2000. 688 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 689 Tunnel Broker", RFC 3053, January 2001. 691 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 692 RFC 3068, June 2001. 694 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 695 6to4", RFC 3964, December 2004. 697 [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 698 3 Provider Provisioned Virtual Private Networks (PPVPNs)", 699 RFC 4031, April 2005. 701 Author's Address 703 Fred Baker 704 Cisco Systems 705 Santa Barbara, California 93117 706 USA 708 Phone: +1-408-526-4257 709 Email: fred@cisco.com 711 Appendix A. Requirements for a general transition strategy 713 What we need is Internet-level transition strategy that defines a 714 limited subset of simple transition mechanisms that provide reliable 715 bi-directional connectivity into a dual-stack backbone and to the 716 global dual-stacked Internet backbone. 718 To avoid the fragmentation this document concerns itself with, the 719 advice of the IPv6 Operations Working Group is that Enterprises 720 should transition to IPv6 by: 722 Case 1: Fully dual stacked backbone: Deploying a native IPv6 service 723 along with native IPv4 service throughout the Enterprise from dual 724 stack hosts to dual stack routers connecting to a dual-stacked 725 Internet backbone. (Preferred method) 727 Case 2: Partially dual-stacked backbone: Deploying a limited number 728 of dual stack "work group" routers with tunnels between them. The 729 dual-stacked work group routers provide both IPv4 and IPv6 service 730 to dual-stack hosts while the majority of the Enterprise backbone 731 network remains IPv4-only. Since the Enterprise has an IPv4- 732 dominant infrastructure throughout most of the Enterprise's 733 backbone, the IPv6-capable work group routers must tunnel IPv6 734 through the IPv4 enterprise to a central dual-stacked router that 735 connects the IPv6 work group router tunnels and provides service 736 to the dual-stack Internet backbone. Both IPv4 and IPv6 service 737 is provided from the host to the global dual-stacked backbone. It 738 is expected that this network design may be eventually upgraded to 739 case 1. 741 Case 3: Deploying limited IPv6-in-IPv4 tunneling (bidirectional) from 742 dual stack hosts to a tunnel end-point (tunnel broker, 6to4, 743 etc...) that can connect hosts to a native IPv6 backbone. This 744 case assumes an Enterprise architecture with only one (or a few) 745 dual-stacked router which is acting as the IPv6 TEP. This 746 solution has the most overhead and least scalability and should be 747 used for early adoption until upgrades to case 1 or 2 can be made. 748 If the IPv4 infrastructure contains NAT, then the tunnel setup 749 protocol must provide NAT traversal and keep-alive features. 751 All of these provide both native IPv6 and IPv4 connectivity to a 752 fully dual-stacked backbone. That is the key to interoperability. 754 Translation should not be used as an Enterprise solution for IPv6 755 connectivity - it breaks the End to End model described in [Saltzer], 756 and is too technically complex to maintain as an enterprise service 757 for a large multi-application network. Translation should only be 758 used at the edge of a network for specific pieces of equipment that 759 cannot be upgraded to IPv6 by a dual-stack software patch. 761 IPv6 dominant networks are only recommended for edge networks that 762 have all internal communications via IPv6 and only a small portion of 763 external communications via IPv4. 765 If the IPv6 dominant network may act as a local backbone that will 766 have to service some IPv4-only networks, then it needs manual (GRE) 767 IPv4-in-IPv6 tunnels or some form of automatic edge-to-edge IPv4-in- 768 IPv6 tunnels (not defined at this point) to service the IPv4 traffic 769 through the infrastructure between IPv4-only islands and to the 770 global dual-stack backbone. Perhaps some form of BGP tunnels could 771 service this need. 773 Intellectual Property Statement 775 The IETF takes no position regarding the validity or scope of any 776 Intellectual Property Rights or other rights that might be claimed to 777 pertain to the implementation or use of the technology described in 778 this document or the extent to which any license under such rights 779 might or might not be available; nor does it represent that it has 780 made any independent effort to identify any such rights. Information 781 on the procedures with respect to rights in RFC documents can be 782 found in BCP 78 and BCP 79. 784 Copies of IPR disclosures made to the IETF Secretariat and any 785 assurances of licenses to be made available, or the result of an 786 attempt made to obtain a general license or permission for the use of 787 such proprietary rights by implementers or users of this 788 specification can be obtained from the IETF on-line IPR repository at 789 http://www.ietf.org/ipr. 791 The IETF invites any interested party to bring to its attention any 792 copyrights, patents or patent applications, or other proprietary 793 rights that may cover technology that may be required to implement 794 this standard. Please address the information to the IETF at 795 ietf-ipr@ietf.org. 797 Disclaimer of Validity 799 This document and the information contained herein are provided on an 800 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 801 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 802 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 803 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 804 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 805 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 807 Copyright Statement 809 Copyright (C) The Internet Society (2005). This document is subject 810 to the rights, licenses and restrictions contained in BCP 78, and 811 except as set forth therein, the authors retain all their rights. 813 Acknowledgment 815 Funding for the RFC Editor function is currently provided by the 816 Internet Society.