idnits 2.17.1 draft-ietf-v6ops-ent-analysis-07.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1289. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 (December 8, 2007) is 5956 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) ** Obsolete normative reference: RFC 2462 (ref. 'CONF') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (ref. 'DHCPv6') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 4057 (ref. 'BSCN') ** Obsolete normative reference: RFC 4214 (ref. 'ISTP') (Obsoleted by RFC 5214) ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. 'TBRK') ** Obsolete normative reference: RFC 3177 (ref. 'ALLOC') (Obsoleted by RFC 6177) ** Obsolete normative reference: RFC 2766 (ref. 'NATPT') (Obsoleted by RFC 4966) ** Downref: Normative reference to an Informational RFC: RFC 3904 (ref. 'UMAN') ** Downref: Normative reference to an Informational RFC: RFC 4029 (ref. 'ISPA') ** Downref: Normative reference to an Informational RFC: RFC 4215 (ref. '3GPA') ** Obsolete normative reference: RFC 2740 (ref. 'OSPF') (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 2858 (ref. 'BGP4') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 1142 (ref. 'ISIS') (Obsoleted by RFC 7142) ** Downref: Normative reference to an Informational RFC: RFC 4038 (ref. 'APPS') ** Downref: Normative reference to an Informational RFC: RFC 4192 (ref. 'RENUM') ** Downref: Normative reference to an Informational RFC: RFC 4472 (ref. 'DNSOP6') ** Obsolete normative reference: RFC 4305 (ref. 'IPSEC') (Obsoleted by RFC 4835) ** Obsolete normative reference: RFC 3041 (ref. 'PRIVv6') (Obsoleted by RFC 4941) Summary: 22 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Operations WG Jim Bound 2 Internet-Draft Yanick Pouffary 3 Expires June 8, 2007 Hewlett-Packard 4 Steve Klynsma 5 MITRE 6 Tim Chown 7 University of Southampton 8 Dave Green 9 Command Information 10 December 8, 2007 12 IPv6 Enterprise Network Analysis - IP Layer 3 Focus 14 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on June 1, 2007. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 46 This document analyzes the transition to IPv6 in enterprise 47 networks focusing on IP Layer 3. These networks are characterized 48 as a network that has multiple internal links, one or more router 49 connections, to one or more Providers, and is managed by a network 50 operations entity. The analysis will focus on a base set of 51 transition notational networks and requirements expanded from a 52 previous Enterprise Scenarios document. Discussion is provided on a 53 focused set of transition analysis required for the enterprise to 54 transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) 55 network and node environment, within the enterprise. Then a set of 56 transition mechanisms are recommended for each notational network. 58 Table of Contents: 60 1. Introduction................................................4 61 2. Terminology.................................................7 62 3. Enterprise Matrix Analysis for Transition...................8 63 4. Wide-Scale Dual-Stack Deployment Analysis..................12 64 4.1 Staged Dual-Stack Deployment...............................12 65 4.2 Routing Capability Analysis for Dual-IP Deployment.........13 66 4.2.1 IPv6 Routing Capability..................................13 67 4.2.2 IPv6 Routing Non-Capability..............................14 68 4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure...............14 69 4.2.2.2 Deploy a parallel IPv6 infrastructure..................14 70 4.3 Remote IPv6 access to the enterprise.......................15 71 4.4 Other considerations.......................................15 72 5. Sparse Dual-Stack Deployment Analysis......................16 73 5.1 Internal versus External Tunnel End Point..................16 74 5.2 Manual versus Autoconfigured...............................17 75 6. IPv6 Dominant Network Deployment Analysis..................18 76 7. General Issues from Analysis...............................20 77 7.1 Staged Plan for IPv6 Deployment............................20 78 7.2 Network Infrastructure Requirements........................20 79 7.3 Stage 1: Initial connectivity steps........................20 80 7.3.1 Obtaining external connectivity..........................20 81 7.3.2 Obtaining global IPv6 address space......................21 82 7.4 Stage 2: Deploying generic basic service components........21 83 7.4.1 Developing an IPv6 addressing plan.......................21 84 7.4.2 IPv6 DNS.................................................22 85 7.4.3 IPv6 Routing.............................................22 86 7.4.4 Configuration of Hosts...................................23 87 7.4.5 Security.................................................23 88 7.5 Stage 3: Widespread Dual-Stack deployment on-site..........24 89 8. Applicable Transition Mechanisms...........................26 90 8.1 Recognizing Incompatible Network touchpoints...............26 91 8.2 Recognizing Application incompatibilities..................27 92 8.3 Using Multiple Mechanisms to Support IPv6 Transition.......28 93 9. Security Considerations....................................29 94 10. IANA Considerations........................................29 95 11. References.................................................29 96 11.1 Normative References......................................29 97 11.2 Non-Normative References..................................31 98 Change Log.....................................................32 99 Acknowledgments................................................34 100 Author's Addresses.............................................35 101 Intellectual Property and Copyright Statements.................36 102 Appendix A - Crisis Management Network Scenarios...............37 103 1. Introduction 105 This document analyzes the transition to IPv6 in enterprise 106 networks focusing on IP Layer 3. These networks are characterized 107 as a network that has multiple internal links, one or more router 108 connections, to one or more Providers, and is managed by a network 109 operations entity. The analysis will focus on a base set of 110 transition notational networks and requirements expanded from a 111 previous Enterprise Scenarios document. Discussion is provided on a 112 focused set of transition analysis required for the enterprise to 113 transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) 114 network and node environment, within the enterprise. Then a set of 115 transition mechanisms are recommended for each notational network. 117 The audience for this document is the enterprise network team 118 considering deployment of IPv6. The document will be useful for 119 enterprise teams that will have to determine the IPv6 transition 120 strategy for their enterprise. It is expected those teams include 121 members from management, network operations, and engineering. The 122 analysis and notational networks presented provide an example set 123 of cases the enterprise can use to build an IPv6 transition 124 strategy. 126 The enterprise analysis will begin by describing a matrix as a tool 127 to be used to portray the different IPv4 and IPv6 possibilities for 128 deployment. The document will then provide analysis to support a 129 wide Dual-IP layer deployment strategy across the enterprise, to 130 provide the reader a view of how that can be planned and what are 131 the options available. The document will then discuss the 132 deployment of sparse IPv6 nodes within the enterprise and what 133 requirements need to be considered and implemented, when the 134 enterprise will remain with IPv4-only routing infrastructure for 135 some time. The next discussion focuses on the use of IPv6 when it 136 is determined to be dominant across or within parts of the 137 enterprise network. 139 The document then begins to discuss the general issues and 140 applicability from the previous analysis. The document concludes 141 providing a set of current transition mechanism recommendations for 142 the notational network scenarios to support an enterprise planning 143 to deploy IPv6. 145 This document, as stated in the introduction, focuses only on the 146 deployment cases where a Dual-IP Layer 3 is supported across the 147 network and on the nodes in the enterprise. Additional deployment 148 transition analysis will be required from the effects of IPv6-only 149 node or Provider deployments, and beyond the scope of this 150 document. In addition this document does not attempt to define or 151 discuss any use with network address translation [NATPT] or the use 152 of Provider Independent address space. 154 The following specific topics are currently out of scope for this 155 document: 157 - Multihoming 158 - Application transition/porting (see [APPS]). 159 - IPv6 VPN, firewall or intrusion detection deployment 160 - IPv6 network management and QoS deployment 161 - Detailed IT Department requirements 162 - Deployment of novel IPv6 services, e.g. Mobile IPv6 163 - Requirements or Transition at the Providers network 164 - Transport protocol selection for applications with IPv6 165 - Application layer and configuration issues. 166 - IPv6 only future deployment scenarios. 168 We are focusing in this document on IP Layer 3 deployment, in the 169 same way as the other IPv6 deployment analysis works have done 170 [UMAN] [ISPA] [3GPA]. This document covers deployment of IPv6 "on 171 the wire", including address management and DNS services. 173 We are also assuming that the enterprise deployment is being 174 undertaken by the network administration team, i.e. this document 175 is not discussing the case of an individual user gaining IPv6 176 connectivity (to some external IPv6 provider) from within an 177 enterprise network. Much of the analysis is applicable to wireless 178 networks, but there are additional considerations for wireless 179 networks not contained within this document. 181 In Section 2 we introduce the terminology used in this document. In 182 Section 3 we introduce and define a tools matrix and define the IP 183 layer 3 connectivity requirements. In Section 4 we discuss wide 184 scale Dual-IP layer use within an enterprise. In section 5 we 185 discuss sparse Dual-IP layer deployment within an enterprise. In 186 section 6 we discuss IPv6-dominant network deployment within the 187 enterprise. In section 7 we discuss general issues and 188 applicability. In section 8 a set of transition mechanisms are 189 recommended that can support the deployment of IPv6 with an 190 enterprise. 192 This document then provides Appendix A for readers depicting a 193 Crisis Management enterprise network to demonstrate an enterprise 194 network example that requires all the properties as analyzed in 195 Sections 3, 4, 5, 6, and 7. In addition we recommend readers of 196 this document also read another use case document to support an 197 IPv6 Transition for a Campus Network [CAMP]. 199 Readers should also be aware a parallel effort for an enterprise to 200 transition to IPv6 is training, but out of scope for this document. 202 2. Terminology 204 Enterprise Network - A network that has multiple internal links, 205 one or more router connections, to one or 206 more Providers and is actively managed by a 207 network operations entity. 209 Provider - An entity that provides services and 210 connectivity to the Internet or 211 other private external networks for the 212 enterprise network. 214 IPv6-capable - A node or network capable of supporting both 215 IPv6 and IPv4. 217 IPv4-only - A node or network capable of supporting only 218 IPv4. 220 IPv6-only - A node or network capable of supporting only 221 IPv6. This does not imply an IPv6 only 222 stack, in this document. 224 Dual-IP - References a network or node that supports 225 both IPv4 and IPv6. 227 IP-capability - The ability to support IPv6 only, IPv4 only, 228 or Dual IP Layer 230 IPv6-dominant - A network running IPv6 routing and control plane 231 services that provides transport for both IPv4 and 232 IPv6 protocol services 234 Transition - The network strategy the enterprise uses to 235 Implementation transition to IPv6. 237 3. Enterprise Matrix Analysis for Transition 239 In order to identify the best suited transition mechanisms for an 240 enterprise, it is recommended that the enterprise have an in-depth 241 up-to-date understanding of its current IT environment. This 242 understanding will help choose the best suited transition 243 mechanisms. It is important to note that one size does not fit all. 244 While selecting a mechanism it is suggested to select mechanisms 245 which reduce the impact on the existing environment. When selecting 246 a transition mechanism one must consider the functionality 247 required, its scalability characteristic, and the security 248 implications of each mechanism. 250 To provide context for an analysis of the transitioning enterprise 251 at layer 3 we have provided a matrix which describes various 252 scenarios which might be encountered during an IPv6 transition. 253 The notional enterprise network is comprised of hosts attached to 254 an enterprise-owned intranet(s) at two different global locations 255 separated by the Internet. The enterprise owns, operates and 256 maintains its own intranetworks, but relies on an external provider 257 organization that offers Internet Service. Both local and 258 destination intranetworks are operated by different organizations 259 within the same enterprise and consequently could have different 260 IP-capability, than other intranetworks, at certain times in the 261 transition period. 263 Addressing every possible combination of network IP-capability in 264 this notional enterprise network is impractical, therefore trivial 265 (i.e. pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not 266 considered. In addition, the authors could not conceive of any 267 scenarios involving IPv6-only ISPs or IPv6-only nodes in the near 268 term and consequently have not addressed scenarios with IPv6-only 269 ISPs or IPv6-only nodes. We assume all nodes that host IPv6 270 applications are Dual IP. The matrix does not assume or suggest 271 that network address translation is used. The authors recommend 272 that network address translation not be used in these notional 273 cases. 275 Future enterprise transitions that support IPv6-only nodes and 276 IPv6-only ISPs will require separate analysis, that is beyond the 277 scope of this document. 279 Table 1 scenarios below is a matrix of ten possible Transition 280 Implementations that, being encountered in an enterprise, may 281 require analysis and the selection of an IPv6 transition mechanism 282 for that notional network. Each possible implementation is 283 represented by the rows of the matrix. The matrix describes a set 284 of notional networks as follows: 286 - The first column represents the protocol used by the 287 application and below, the IP-capability of the node 288 originating the IP packets. 289 (Application/Host 1 OS). 291 - The second column represents the IP-capability of the 292 host network wherein the node originated the packet. 293 (Host 1 Network) 295 - The third column represents the IP-capability of the 296 service provider network. 297 (Service Provider) 299 - The fourth column represents the IP-capability of the 300 destination network wherein the originating IP packets 301 are received. 302 (Host 2 Network) 304 - The fifth column represents the protocol used by the 305 application and, below, the IP-capability of the 306 destination node receiving the originating IP packets. 307 (Application/Host 2 OS). 309 As an example, notional network 1 is an IPv6 application residing 310 on a Dual-IP layer host trying to establish a communications 311 exchange with a destination IPv6 application. To complete the 312 information exchange the packets must first traverse the host's 313 originating IPv4 network (intranet), then the service provider's, 314 and destination hosts Dual-IP network. 316 Obviously Table 1 does not describe every possible scenario. 317 Trivial notional networks (such as pure IPv4, pure IPv6, and 318 ubiquitous Dual-IP) are not addressed. However, the authors feel 319 these ten represent the vast majority of transitional situations 320 likely to be encountered in today's enterprise. Therefore, we will 321 use these ten to address the analysis for enterprise deployment. 323 Table 1 - Enterprise Scenario Deployment Matrix 325 ====================================================== 326 |Application |Host 1 |Service |Host 2 |Application | 327 |----------- |Network|Provider|Network|---------- | 328 | Host 1 OS | | | | Host 2 OS | 329 =====================================+================ 330 | IPv6 | |Dual IP | | IPv6 | 331 A | ---- | IPv4 | or |Dual IP| ---- | 332 | Dual IP | | IPv4 | | Dual IP | 333 ====================================================== 334 | IPv6 | | | | IPv6 | 335 B | ---- | IPv6 | IPv4 | IPv4 | ---- | 336 | Dual IP | | | | Dual IP | 337 ====================================================== 338 | IPv4 | | | | IPv4 | 339 C | ---- | IPv4 |Dual IP | IPv6 | ---- | 340 | Dual IP | | | | Dual IP | 341 ====================================================== 342 | IPv4 |Dual IP| | | IPv4 | 343 D | ---- | or | IPv4 | IPv6 | ---- | 344 | Dual IP | IPv6 | | | Dual IP | 345 ====================================================== 346 | IPv6 |Dual IP| |Dual IP| IPv4 | 347 E | ---- | or |Dual IP | or | ---- | 348 | Dual IP | IPv6 | | IPv6 | Dual IP | 349 ====================================================== 350 | IPv6 | | | | IPv4 | 351 F | ---- | IPv6 | IPv4 | IPv4 | ---- | 352 | Dual IP | | | | Dual IP | 353 ====================================================== 354 | IPv4 | | | | IPv6 | 355 G | ---- | IPv6 | Dual IP| IPv6 | ---- | 356 | Dual IP | | | | Dual IP | 357 ====================================================== 358 | IPv4 | | | | IPv6 | 359 H | ---- | IPv6 |Dual IP | IPv4 | ---- | 360 | IPv4 | | | | Dual IP | 361 ====================================================== 362 | IPv4 | | | | IPv6 | 363 I | ---- | IPv6 | IPv4 | IPv6 | ---- | 364 | IPv4 | | | | Dual IP | 365 ====================================================== 366 | IPv6 | | | | IPv4 | 367 J | ---- | IPv4 | IPv4 | IPv6 | ---- | 368 | Dual IP | | | | Dual IP | 369 ====================================================== 370 The reader should note that scenarios A-C in Table 1 are variations 371 of compatible hosts communicating across largely (but not entirely) 372 homogenous networks. In each of the first three scenarios, the 373 packet must traverse at least one incompatible network component. 374 For example, scenario B represents an enterprise which wishes to 375 use IPv6 applications, but has yet to transition its internal 376 networks and its Service Provider also lags, offering only a v4 377 IP-service. Conversely, Scenario C represents an enterprise which 378 has completed transition to IPv6 in its core networks (as has its 379 Service Provider), but continues to require a legacy IPv4-based 380 application. 382 Scenario D represents the unusual situation where the enterprise 383 has transitioned its core intranetworks to IPv6, but (like scenario 384 B) it's ISP provider has yet to transition. In addition, this 385 Enterprise continues to retain critical legacy IPv4-based 386 applications which must communicate over this heterogeneous network 387 environment. 389 Scenarios E-J represent transitional situations wherein the 390 Enterprise has both IPv4 and IPv6 based instantiations of the same 391 application that must continue to interoperate. In addition, these 392 scenarios show that the Enterprise has not completed transition to 393 IPv6 in all its organic and/or Service Provider networks. Instead, 394 it maintains a variety of heterogeneous network segments between 395 the communicating applications. Scenarios E and J represent 396 distinctly different extremes on either end of the spectrum. In 397 scenario E, the enterprise has largely transitioned to IPv6 in both 398 its applications and networks. However, scenario E shows that a few 399 legacy IPv4-based applications may still be found in the 400 enterprise. On the other hand, scenario J shows an Enterprise that 401 has begun its transition in a very disjointed manner and, in which 402 IPv6-based applications and network segments are relatively rare. 404 4. Wide-Scale Dual-Stack Deployment Analysis 406 In this section we address Scenario 1 as described in Section 3.1 407 of [BSCN]. The scenario, assumptions and requirements are driven 408 from the [BSCN] text. This analysis further corresponds to 409 Scenario A in Section 3 above (although Scenario A shows a 410 transitional situation wherein the enterprise has one network 411 segment still lagging on transition to Dual-IP). 413 Within these IPv6 deployment scenarios the enterprise network 414 administrator would introduce IPv6 by enabling IPv6 on the wire 415 (i.e. within the network infrastructure) in a structured fashion 416 with the existing IPv4 infrastructure. In such scenarios, a number 417 of the existing IPv4 routers (and thus subnets) will be made dual- 418 IP, such that communications can run over either protocol. 420 Nodes on the dual-IP links may themselves be IPv4-only or IPv6- 421 capable. The driver for deploying IPv6 on the wire may not be for 422 immediate wide-scale usage of IPv6, but rather to prepare an 423 existing IPv4 infrastructure to support IPv6-capable nodes. Thus, 424 while IPv6 is not used, dual-IP nodes exist, and the enterprise can 425 be transitioned to IPv6 on demand. 427 Analyzing this scenario against existing transition mechanisms for 428 their applicability, suggests a staged approach for IPv6 deployment 429 in the enterprise. 431 4.1 Staged Dual-Stack Deployment 433 Under these scenarios (as well as most others), the site 434 administrator should formulate a staged plan for the introduction 435 of a dual-IP IPv6 network. We suggest that the generic plan of 436 Section 7 of this document provides a good basis for such a plan. 438 In an enterprise network, the administrator will generally seek to 439 deploy IPv6 in a structured, controlled manner, such that IPv6 can 440 be enabled on specific links at various stages of deployment. There 441 may be a requirement that some links remain IPv4 only, or some that 442 specifically should not have IPv6 connectivity (e.g. Scenario A of 443 Table 1). There may also be a requirement that aggregatable global 444 IPv6 addresses, assigned by the enterprise's upstream provider from 445 the address space allocated to them by the Regional Internet 446 Registries (RIRs), be assigned. 448 In this document we do not discuss the deployment of Unique Local 449 IPv6 Unicast Addresses [ULA] because the address type and scope 450 selected is orthogonal to the layer 3 analysis of this document. 452 A typical deployment would initially involve the establishment of a 453 single "testbed" Dual-IP subnet at the enterprise site prior to 454 wider deployment. Such a testbed not only allows the IPv6 455 capability of specific platforms and applications to be evaluated 456 and verified, but also permits the steps in Sections 7.3 and 7.4 of 457 this document to be undertaken without (potential) adverse impact 458 on the production elements of the enterprise. 460 Section 7.5 describes the stages for the widespread deployment in 461 the enterprise, which could be undertaken after the basic building 462 blocks for IPv6 deployment are in place. 464 4.2 Routing Capability Analysis for Dual-IP Deployment 466 A critical part of Dual-IP deployment is the selection of the 467 IPv6-capable routing infrastructure to be implemented. The path 468 taken will depend on whether the enterprise has existing Layer 2/3 469 switch/router equipment that has an IPv6 (routing) capability, or 470 that can be upgraded to have such capability. 472 In Section 4, we are not considering sparse IPv6 deployment; the 473 goal of Dual-IP deployment is widespread use in the enterprise. 475 4.2.1 IPv6 Routing Capability 477 Where IPv6 routing capability exists within the infrastructure, the 478 network administrator can enable IPv6 on the same physical hardware 479 as the existing IPv4 service. This is the end goal of any 480 enterprise to support Dual-IP deployment, when the capability, 481 performance, and robustness of the Dual-IP operational deployment 482 has been verified. 484 Ideally, the IPv6 capability will span the entire enterprise, 485 allowing deployment on any link or subnet. If not, techniques from 486 Section 4.4 below may be required. 488 4.2.2 IPv6 Routing Non-Capability 490 If the enterprise cannot provide IPv6 routing initially there are 491 alternative methods for transition. In this case the enterprise 492 administrator faces two basic choices, either to tunnel IPv6 over 493 some or all of the existing IPv4 infrastructure, or to deploy a 494 parallel IPv6 routing infrastructure providing IPv6 connectivity 495 into existing IPv4 subnets. 497 It may thus be the case that a nodes IPv4 and IPv6 default routes 498 to reach other links (subnets) are through different routing 499 platforms. 501 4.2.2.1 Tunnel IPv6 over the IPv4 infrastructure 503 Consider the situation where there exists IPv6 edge routers which 504 are IPv6-capable, while others,and perhaps the enterprise backbone 505 itself, are not IPv6-capable (Scenario B of Table 1). Tunneling, 506 as described in [BCNF] would be established between the Dual-IP 507 capable routers on the enterprise, thus "bypassing" existing non 508 IPv6-capable routers and platforms. 510 In the widespread dual-IP scenario, a more structured, manageable 511 method is required, where the administrator has control of the 512 deployment per-link and (ideally) long-term, aggregatable global 513 IPv6 addressing is obtained, planned and used from the outset. 515 4.2.2.2 Deploy a parallel IPv6 infrastructure 517 Alternatively,the administrator may deploy a new, separate IPv6- 518 capable router (or set of routers). It is quite possible that such 519 a parallel infrastructure would be IPv6-dominant. 521 Such an approach would likely require additional hardware, but it 522 has the advantage that the existing IPv4 routing platforms are not 523 disturbed by the introduction of IPv6. 525 To distribute IPv6 to existing IPv4 enterprise subnets, either 526 dedicated physical infrastructure can be employed or, if available, 527 IEEE 802.1q VLANs could be used, as described in [VLAN]. The 528 latter has the significant advantage of not requiring any 529 additional physical cabling/wiring and also offers all the 530 advantages of VLANs for the new dual-IP environment. Many router 531 platforms can tag multiple VLAN IDs on a single physical interface 532 based on the subnet/link the packet is destined for; thus multiple 533 IPv6 links can be collapsed for delivery on a single (or small 534 number of) physical IPv6 router interfaces in the early stages of 535 deployment. 537 The parallel infrastructure should only be seen as an interim step 538 towards full Dual-IP deployment on a unified infrastructure. The 539 parallel infrastructure however allows all other aspects of the 540 IPv6 enterprise services to be deployed, including IPv6 addressing, 541 thus making the enterprise ready for that unifying step at a later 542 date. 544 4.3 Remote IPv6 access to the enterprise 546 When the enterprise's users are off-site, and using an ISP that 547 does not support any native IPv6 service or IPv6 transition aids, 548 the enterprise may consider deploying it's own remote IPv6 access 549 support. Such remote support might for example be offered by 550 deployment of an IPv6 Tunnel Broker [TBRK]. 552 4.4 Other considerations 554 There are some issues associated with turning IPv6 on by default, 555 including application connection delays, poor connectivity, and 556 network insecurity, as discussed in [V6DEF]. The issues can be 557 worked around or mitigated by following the advice in [V6DEF] 558 5. Sparse Dual-Stack Deployment Analysis 560 This section covers the Scenario 2 as described in Section 3.1 of 561 [BSCN]. This scenario assumes the requirements defined within the 562 [BSCN] text. 564 IPv6 deployment within the enterprise network, with an existing 565 IPv4 infrastructure, could be motivated by mission critical or 566 business applications or services that require IPv6. In this case 567 the prerequisite is that only the nodes using those IPv6 568 applications need to be upgraded to be IPv6-capable. The routing 569 infrastructure will not be upgraded to support IPv6, nor does the 570 enterprise wish to deploy a parallel IPv6 routing infrastructure at 571 this point, since this is an option in section 4. 573 There is a need for end-to-end communication with IPv6, but the 574 infrastructure only supports IPv4 routing. Thus, the only viable 575 method for end-to-end communication with IPv6 is to tunnel the 576 traffic over the existing IPv4 infrastructure, within this analysis 577 documents boundaries defined. 579 The network team needs to decide which are the most efficient the 580 available transition tunneling mechanisms to deploy, so they can be 581 used without disrupting the existing IPv4 infrastructure. Several 582 conditions require analysis, as introduced in the following sub 583 sections. 585 5.1 Internal versus External Tunnel End Point 587 Let's assume the upstream provider has deployed some IPv6 services, 588 either native IPv6 in its backbone or in the access network, or 589 some combination of both (Scenario B of Table 1). In this case, the 590 provider will likely also deploy one or more transition mechanisms 591 to support their IPv6 subscribers. Obviously, the enterprise could 592 decide to take advantage of those transition services offered from 593 the Provider. However, this will usually mean that individual nodes 594 in the network will require their own IPv6-in-IPv4 tunnel. The end 595 result is somewhat inefficient IPv6 intranetworks communication, 596 because all IPv6 traffic must be forwarded by the Enterprise's IPv4 597 infrastructure to the Tunnel End-Point offered by the Provider. 598 Nevertheless, this may be acceptable paticularly if the IPv6 599 applications do not require intranetworks communication at all. For 600 example when an application's server is located outside of the 601 enterprise network, or on other intranetworks of the same 602 enterprise. 604 Alternatively, the enterprise could decide to deploy its own 605 transition mechanism node, possibly collocating it adjacent to the 606 border router that connects to the upstream Provider. In this case, 607 intranetnetworks communication using this tunnel end point is also 608 possible. 610 5.2 Manual versus Autoconfigured 612 If the number of nodes to be using IPv6 is low, the first option is 613 to use statically configured tunnels. However, automatically 614 configured tunnels may be preferable, especially if the number is 615 higher. 617 6. IPv6 Dominant Network Deployment Analysis 619 In this section we are covering Scenario 3 as described in Section 620 3.1 of [BSCN]. The scenario, assumptions and requirements are 621 driven from the [BSCN] text. Within this document, this situation 622 is captured in Scenario C of Table 1. 624 Some enterprise networks may wish to employ an IPv6-dominant 625 network deployment strategy. What this means essentially is that 626 the network or specific sites within the enterprise network will 627 transition to IPv6 using only IPv6 routing to transfer both IPv4 628 and IPv6 packets over the network, even though the network may be 629 Dual-IP capable. IPv4 routing would not be turned on within an 630 IPv6-dominant network, except if required to support edge IPv4 631 networks. 633 Under this scenario, communications between IPv6 nodes will use 634 IPv6. When IPv6-capable nodes in the IPv6-dominant network need to 635 communicate with IPv4 nodes, the IPv6 nodes will use their Dual-IP 636 implementation to tunnel IPv4 packets in IPv6 [V6TUN]. An edge 637 router within the IPv6-dominant network will decapsulate the IPv4 638 packet and route to the path of the IPv4 node on the network. This 639 permits Dual-IP layer nodes to communicate with legacy IPv4 nodes 640 within an IPv6-dominant network. 642 From Table 1 scenarios E and F depict additional cases where an 643 IPv6- dominant deployment strategy could be in place. In scenario 644 E the entire network could be IPv6-dominant, but the Host OS 2 645 system is running an IPv4 application. In scenario F the Host OS 1 646 system network could be IPv6-dominant, but the rest of the networks 647 are all IPv4. 649 In each case, communicating with an IPv4 end host or over an IPv4 650 network requires a transition point exist within the network to 651 support that operation. Furthermore, the node in the IPv6-dominant 652 network must acquire an IPv4 address (to interoperate with the IPv4 653 end host), and locate a tunnel endpoint on their network which 654 permits the IPv4 packet to be tunneled to the next hop IPv6 router 655 and eventually to a destination Dual IP router. 657 While retaining interoperability with IPv4 is a noble goal for 658 Enterprise architects, it is an unfortunate fact that maintaining 659 IPv4 services in an IPv6-dominant network slows and may even impede 660 your ability to reap the maximum benefits of IPv6. 662 The decision whether or not to use an IPv6-dominant network 663 deployment strategy is completely driven by the Enterprise's 664 business and operational objectives and guided by the Enterprise's 665 transition plan. 667 7. General Issues from Analysis 669 In this section we describe generic enterprise IPv6 deployment 670 issues, applicable to the analysis sections 4-6 in this document. 672 7.1 Staged Plan for IPv6 Deployment 673 The enterprise network administrator will need to follow a staged 674 plan for IPv6 deployment. What this means is that a strategic 675 identification of the enterprise network must be performed for all 676 points and components of the transition. 678 7.2 Network Infrastructure Requirements 680 The considerations for the enterprise components are detailed in 681 Section 3.2 of [BSCN]. We do not go into detail of all aspects of 682 such components in this document. In this document we focus on 683 Layer 3 issues. 685 7.3 Stage 1: Initial connectivity steps 687 The first steps for IPv6 deployment do not involve technical 688 aspects per se; the enterprise needs to select an external IPv6 689 provider, and obtain globally routable IPv6 address space from that 690 provider. 692 7.3.1 Obtaining external connectivity 694 The enterprise service provider would typically be a 695 topographically close IPv6 provider that is able to provide an IPv6 696 upstream link. It would be expected that the enterprise would use 697 either native IPv6 upstream connectivity or, in its absence, a 698 manually configured tunnel [BCNF] to the upstream provider. 700 7.3.2 Obtaining global IPv6 address space 702 The enterprise will obtain global IPv6 address space from its 703 selected upstream provider, as provider assigned (PA) address 704 space. 706 The enterprise should receive at least a /48 allocation from its 707 provider, as described in [ALLOC]. 709 Should an enterprise change their provider, a procedure for 710 enterprise renumbering between providers is described in [RENUM]. 712 7.4 Stage 2: Deploying generic basic service components 714 Most of these are discussed in Section 4 of [BSCN]. Here we comment 715 on those aspects that we believe are in scope for this analysis 716 document. Thus we have not included network management, 717 multihoming, multicast or application transition analysis here, but 718 these aspects should be addressed in Stage 2. 720 7.4.1 Developing an IPv6 addressing plan 722 A site will need to formulate an IPv6 addressing plan, utilizing 723 the globally aggregatable public IPv6 prefix allocated to it by its 724 upstream connectivity provider. 726 In a Dual-IP deployment, the site will need to decide whether it 727 wishes to deploy IPv6 links to be congruent with existing IPv4 728 subnets. In this case, nodes will fall into the same links or 729 subnets for both protocols. Such a scheme could be followed, with 730 IPv6 prefix allocations being made such that room for topological 731 growth is provisioned (reducing the potential requirement for 732 future renumbering due to restructuring). 734 A beneficial property of IPv6 is that an administrator will not 735 need to invest as much effort in address conservation. With IPv4, 736 a site will likely allocate IPv4 subnets to be as small as possible 737 for the number of hosts currently in the subnet (e.g. a /26 for 50 738 nodes), because IPv4 address conservation is required. This creates 739 problems when the number of nodes on a subnet grows, larger IPv4 740 prefixes are then required, and potentially time-consuming and 741 disruptive renumbering events will follow. 743 With IPv6, a link can in effect have any number of nodes, allowing 744 link growth without the need to adjust prefix allocations with the 745 associated renumbering requirement. The size of the initial site 746 allocation (currently recommended to be a /48) also is likely to 747 allow room for site growth without a need to return to the 748 connectivity provider to obtain more, potentially non-sequential, 749 address space (as is the case for IPv4 today, with the associated 750 paperwork and probable delays). 752 At the time of writing, best practice in IPv6 site address planning 753 is restricted due to limited wide-scale deployments. Administrators 754 should allocate /64 size prefixes for subnets, and do so in a way 755 that has scope for growth within a site. The site should utilize a 756 plan that reserves space for topological growth in the site, given 757 that its initial IPv6 prefix allocation (currently recommended to 758 be a /48) is likely to include such room for growth. Also see IPv6 759 unicast address assignments document in process [UNAD]. 761 7.4.2 IPv6 DNS 763 The enterprise site should deploy a DNS service that is capable of 764 both serving IPv6 DNS records using the AAAA format [DNSV6R] and of 765 communicating over IPv6 transport. 767 Specific IPv6 DNS issues are reported in [DNSOP6]. 769 7.4.3 IPv6 Routing 771 The enterprise network will need to support methods for internal 772 and external routing. 774 For a single-homed single-site network, a static route to a single 775 upstream provider may be sufficient, although the site may choose 776 to use an exterior routing protocol, especially where it has 777 multiple upstream providers. 779 For internal routing, an appropriate interior routing protocol may 780 be deployed. IPv6 routing protocols that can be used are as 781 follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng 782 [RIPng]. 784 7.4.4 Configuration of Hosts 786 An enterprise network will have a number of tools available for 787 IPv4 address and other configuration information delegation and 788 management, including manual configuration, NIS [NIS] or DHCP 789 [DHCPv4]. 791 In an IPv6 enterprise, Stateless Address Autoconfiguration [CONF] 792 may be used to configure a host with a global IPv6 address, a 793 default router, and an on-link prefix information. 795 Where support for secure autoconfiguration is required, SEND [SEND] 796 can be used. Readers should see the applicability statements to 797 IPsec [IPSEC] within the SEND document. 799 A stateless configured node wishing to gain other configuration 800 information (e.g. DNS, NTP servers) will likely need a Stateful 801 DHCPv6 [DHCPv6] service available. 803 For nodes configuring using DHCPv6, where DHCPv6 servers are 804 offlink, a DHCPv6 Relay Agent function will be required. Where 805 DHCPv4 and DHCPv6 service are deployed together, dual-stack 806 considerations need to be made, as discussed within current work on 807 DHCP dual stack issues [DHDS]. 809 Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; 810 there is support for DHCPv6 to assign privacy addresses to nodes in 811 managed environments. 813 7.4.5 Security 815 When deploying IPv6 within a Dual-IP network, a site will need to 816 implement its site security policy for IPv6-capable nodes as it 817 does for IPv4-capable nodes. For example, a border firewall 818 should be capable of filtering and controlling IPv6 traffic by 819 enforcing the same policy as it already does for IPv4. 821 However, a site will also need to review its security policy in 822 light of IPv6 specific functionality that will be deployed in the 823 site, e.g. Mobile IPv6, stateless autoconfiguration (and SEND), 824 IPv6 Privacy Extensions, end-to-end IPsec, and, not least, the use 825 of globally aggregatable public address space where for IPv4 826 private addressing and NAT may have been used. 828 An overview of how Network Architecture Protection (NAP) using IPv6 829 can provide the same or more benefits without the need for NAT can 830 be found in [NAP]. This describes how the perceived security with 831 IPv4 NAT can be achieved and surpassed with IPv6, i.e. how IPv6 832 technology can be used to provide the market-perceived benefits of 833 IPv4 NAT. 835 Where deployed, intrusion detection systems will need to be 836 enhanced to both check IPv6 transport for known application layer 837 attack patterns and also to check for new potential IPv6 threats, 838 e.g. excessive hop-by-hop headers, or errant IPv6 header options. 840 The deployment of specific transition mechanisms may also introduce 841 threats, e.g. carrying IPv6 data tunnelled in IPv4. The site 842 security policy should embrace the transition mechanisms that are 843 deployed. 845 An overview of IPv6 security issues can be found in [V6SEC]. This 846 includes discussion of issues specific to the IPv6 protocol, to 847 transition mechanisms, and to IPv6 deployment itself. 849 In addition an enterprise should review all current Host Based 850 security requirements for their networks and verify support for 851 IPv6. 853 7.5 Stage 3: Widespread Dual-Stack deployment on-site 855 With the basic building blocks of external connectivity, interior 856 IPv6 routing, an IPv6 DNS service and address allocation management 857 in place, the IPv6 capability can be rolled out to the wider 858 enterprise. This involves putting IPv6 on the wire in the desired 859 links, and enabling applications and other services to begin using 860 an IPv6 transport. 862 In the Dual-IP deployment case, this means enabling IPv6 on 863 existing IPv4 subnets. As described in Section 7.4.4 above, it is 864 likely that IPv6 links will be congruent with IPv4 subnets, because 865 IPv4 subnets tend to be created for geographic, policy or 866 administrative reasons that would be IP version-independent. 868 While the use of IPv6 by some applications can be administratively 869 controlled (e.g. in the case of open source software by compiling 870 the application without IPv6 support enabled), the use of IPv6 871 transport, and preference over IPv4 transport, will vary per 872 application based on the developer/author's implementation. 874 A Dual-IP deployment will often be made by sites wishing to support 875 use of IPv6 within a site, even if IPv6 transport is not preferred 876 by all applications. Putting support for IPv6 in all site 877 infrastructure (DNS, email transport, etc) allows IPv6 usage to be 878 phased in over time. As nodes become IPv6 capable, and 879 applications and services IPv6 enabled, the IPv6 capable 880 infrastructure can be leveraged. For most networks, Dual-IP will 881 be at the very least a medium-term transition towards an IPv6- 882 dominant future. However, the introduction of IPv6 support, with 883 the potential benefits of globally aggregatable public address 884 usage (with [NAP]), and other new IPv6 capabilities, can bring more 885 immediate benefits for the site. 887 8. Applicable Transition Mechanisms 889 This section will provide general guidance for the use of specific 890 transition mechanisms which in turn can be used by the enterprise 891 to support the enterprise matrix notional networks (rows) in 892 Section 3, and within the context of the analysis discussed in 893 Sections 4, 5, and 6. 895 Table 1 provides a number of common scenarios that an enterprise 896 architect might encounter as they consider how and where they 897 should consider deploying transition mechanisms to support the 898 network transition to IPv6. Selecting the most appropriate 899 mechanism for each scenario is more of an art than a science and 900 consequently making recommendations against each of the ten 901 scenarios would be simply fodder for sharpshooters touting their 902 favored product. However we can provide some high-level guidance 903 that should benefit the architect's decision making process. 905 8.1 Recognizing Incompatible Network touchpoints 907 Mapping your specific situation into one of the ten scenarios of 908 Table 1 is far less important than recognizing the critical 909 touchpoints within the enterprise networks where incompatible 910 networks interface. Unless a transition mechanism is being offered 911 by the enterprise as a service, it is at these touchpoints that a 912 mechanism must be considered. 914 A quick review of Table 1 reveals that the ten scenarios can be 915 boiled down to variations of four major themes. The simplest, but 916 also most favored (due to its flexibility), is wide spread Dual IP 917 with compatible hosts at either end. This situation is illustrated 918 in Scenario A and transition mechanism considerations have already 919 been described in some detail in Section 4. 921 In the second common theme (depicted in Scenarios B-D of Table 1), 922 the enterprise is comprised of compatible hosts, with one or more 923 incompatible network touchpoints in between. As described in 924 Section 4.2.2.1, tunneling can be used to "bypass" the incompatible 925 network segments. One tunneling option, Manual Configured Tunnels 926 [BCNF] could be used by the enterprise, but as the name implies, 927 this mechanism provides no automated tunnel configuration. 929 6TO4 [6TO4] can be used to support enterprises that do not have an 930 assigned IPv6 prefix address. 932 Identifying the responsible device to perform the tunneling is 933 driven by the position of the incompatible touchpoint. If a local 934 network is incompatible then host tunneling is appropriate. If the 935 backbone (provider) network is incompatible then gateway-to-gateway 936 tunneling might be a better choice. By working to ensure tunnel 937 endpoints are always configured at dual-IP devices, end-to-end 938 communication or services (IPv4 or IPv6) can be preserved. 940 Readers should review the current work regarding tunnels within the 941 IETF Softwire working group and problem statement [SOFTW]. 943 Having IPv6 applications on a Dual-IP host on a v4-only network 944 requires some form of tunneling. Where configured tunnels are not 945 sufficient a more automatic solution may be appropriate. Available 946 solutions include ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6 947 end service. ISATAP [ISTP] can be used to provide end node IPv6 948 connectivity from nodes on an isolated IPv4 network, through the 949 use of automatic tunneling of IPv6 in IPv4. Teredo [TRDO] can be 950 used when the enterprise network is behind a NAT. 952 Enterprise architects should consider providing a Tunnel Broker 953 [TBRK] [TSPB] as a cost effective service to local users or 954 applications. Tunnel Brokers can be used to provide tunnel setup 955 for an enterprise using manual configured tunnels and 6TO4 [6TO4]. 956 Tunnel Brokers can automate the use of tunnels across an enterprise 957 deploying IPv6. 959 Later in the transition process, after the enterprise has 960 transitioned to a predominately IPv6 infrastructure, the architect 961 will need to determine a network transition strategy to tunnel IPv4 962 within IPv6 [V6TUN] across IPv6-dominant links, or the enterprise 963 Intranet. Or in the case of early deployment of IPv6-dominant 964 networks the architect will need to address this from the beginning 965 of the required transition planning. 967 8.2 Recognizing Application incompatibilities 969 Having recognized incompatible network touchpoints, it is also 970 incumbent on the architect to identify application 971 incompatibilities. During the transition period, particularly for 972 large enterprises, it is to be expected that applications hosted at 973 one location may lead (or lag) the IPv6-compability of its peer (or 974 server) at some other location. 976 This leads us to the third theme represented by Scenario E and G, 977 i.e. incompatible applications communicating across a homogenous 978 network. Translation is an obvious solution, but not recommended 979 except for legacy devices at the network edge which cannot or never 980 will be upgraded to IPv6. A more scaleable solution would be to 981 use an Application Layer Gateways (ALG) between the incompatible 982 hosts. 984 8.3 Using Multiple Mechanisms to Support IPv6 Transition 986 Inevitably, during the course of transitioning a large enterprise 987 to IPv6, the architect will be faced with both incompatible hosts 988 and simultaneously (at different parts of the enterprise) 989 incompatible networks. These highly complex situations represent 990 the fourth common theme in Table 1 and are specifically depicted by 991 Scenarios F, H, I and J. Maintaining IP interoperability in these 992 situations requires additional planning and may require multiple or 993 even nested use of diverse transition mechanisms. For example, an 994 ALG co-located with the application server may be required to 995 service both IPv4 and IPv6 data streams that are simultaneously 996 tunneled through incompatible network segment(s). 998 9. Security Considerations 1000 Security considerations for IPv6 deployment in a Dual-IP 1001 environment are discussed above in section 7.4.5, where external 1002 references to overview documents [V6SEC] [NAP] are also included. 1004 10. IANA Considerations 1006 This document has no actions for IANA. 1008 11. References 1010 11.1 Normative References 1012 [CONF] Thomson, S., Narten, T., "IPv6 Stateless 1013 Autoconfiguration" RFC 2462 December 1998. 1015 [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., 1016 et al. "Dynamic Host Configuration Protocol 1017 for IPv6 (DHCPv6)" RFC 3315 July 2003. 1019 [6TO4] Carpenter, B., Moore, K., "Connection of IPv6 1020 Domains via IPv4 Clouds" RFC 3056 February 2001. 1022 [BSCN] Bound, J., (Ed) et al. "IPv6 Enterprise Network 1023 Scenarios" RFC 4057 June 2005. 1025 [TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP 1026 through NATs" RFC 4380. 1028 [ISTP] Templin, F., et al "Intra-Site Automatic Tunnel 1029 Addressing Protocol (ISATAP)". 1030 RFC 4214 October 2005. 1032 [V6TUN] Conta, A., Deering, S., "Generic Packet Tunneling 1033 in IPv6" RFC 2473 December 1998. 1035 [TBRK] Durand, A., et al "IPv6 Tunnel Broker" 1036 RFC 3053 January 2001. 1038 [ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6 1039 Address Allocations to Sites" 1040 RFC 3177 September 2001. 1042 [NATPT] Tsirtsis, G., Srisuresh, P., "Network Address 1043 `Translation - Protocol Translation (NAT-PT)" 1044 RFC 2766 February 2000 1046 [UMAN] Huitema, C.,. et al "Evaluation of IPv6 1047 Transition Mechanisms for Unmanaged Networks". 1048 RFC 3904 September 2004. 1050 [ISPA] Lind, M., et al "Scenarios and Analysis for 1051 Introducing IPv6 into ISP Networks". 1052 RFC 4029 March 2005. 1054 [3GPA] Wiljakka, J., "Analysis on IPv6 Transition in 1055 3GPP Networks" RFC 4215 October 2005. 1057 [OSPF] Coltun, R., Ferguson, D., Moy, J. "OSPF for 1058 IPv6" RFC2740 December 1999. 1060 [BGP4] Bates, T., Rekhter, Y. et. al. "Multiprotocol 1061 Extensions for BGP-4", RFC2858 June 2000. 1063 [ISIS] Oran, D. EDITOR, "OSI IS-IS Intra-domain 1064 Routing Protocol", RFC1142 February 1990. 1066 [RIPng] Malkin, G., Minnear, R. "RIPng for IPv6" 1067 RFC2080 January 1997 1069 [APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., 1070 Castro, E., "Application Aspects of IPv6 1071 Transition" RFC 4038 March 2005. 1073 [RENUM] Baker, F., Lear, E., Droms, R., "Procedures for 1074 Renumbering an IPv6 Network without a Flag Day". 1075 RFC 4192 September 2005. 1077 [BCNF] Nordmark, E., Gilligan, R., "Basic Transition 1078 Mechanisms for IPv6 Hosts and Routers" 1079 RFC 4213 October 2005 1081 [ULA] Hinden, B., Haberman, B., "Unique Local IPv6 1082 Addresses". RFC 4193 October 2005. 1084 [DNSOP6] Durand, A., Ihren, J. and P. Savola, 1085 "Operational Considerations and Issues with 1086 IPv6 DNS". RFC 4472 April 2006. 1088 [DNSV6R] Thomson, S., Huitema, C., et al "DNS 1089 Extensions to Support IP Version 6". 1090 RFC 3596 October 2003. 1092 [NIS] Kalusivalingam. V, "Network Information 1093 Service (NIS) Configuration Options for D 1094 HCPv6. RFC 3898 October 2004. 1096 [DHCPv4] Droms, R., "Dynamic Host Configuration 1097 Protocol" RFC 2131 March 1997. 1099 [IPSEC] Eastlake. D., "Cryptographic Algorithm 1100 Implementation Requirements for Encapsulating 1101 Security Payload (ESP) and Authentication 1102 Header (AH)". RFC 4305 December 2005. 1104 [SEND] Arkko, J. et al. "Secure Neighbor Discovery 1105 (SEND)". RFC 3971 March 2005. 1107 [PRIVv6] Narten, T., Draves, R., "Privacy Extensions 1108 for Stateless Address Autoconfiguration in 1109 IPv6. RFC 3041 January 2001. 1111 11.2 Non-Normative References 1113 [TSPB] Blanchet, M., Parent, F. "IPv6 Tunnel Broker 1114 with the Tunnel Setup Protocol". 1115 Work in Progress. 1117 [V6SEC] Davies, E. et al "IPv6 Transition/Co-existence 1118 Security Considerations". Work in Progress. 1120 [NAP] Van de Velde, G. et al "IPv6 Network 1121 Architecture Protection". Work in Progress. 1123 [CAMP] Chown, T., "IPv6 Campus Transition Scenario 1124 Description and Analysis". Work in Progress. 1126 [DHDS] Chown, T., "DHCP: IPv4 and IPv6 Dual-Stack 1127 Issues", Work in Progress. 1129 [UNAD] Van de Velde, G., Popoviciu, C., Chown, T., 1130 "IPv6 Unicast Address Assignment". 1131 Work in Progress. 1133 [VLAN] Chown, T. "Use of VLANs for IPv4-IPv6 1134 Coexistence in Enterprise Networks". 1135 Work in Progress. 1137 [V6DEF] Roy, S., Durand, A., Paugh, J., "IPv6 Neighbor 1138 Discovery On-Link Assumption Considered 1139 Harmful". Work in Progress. 1141 [SOFTW] Dawkins, S. (Ed) "Softwire Problem Statement" 1142 Work in Progress 1144 Change Log 1146 June 2006 - Oct 2006 1147 ID 06-07 1148 - Add IP Layer 3 Focus to the title 1149 - Remove IPsec use SEND for Autoconfiguration 1150 - Remove all mentions of DSTM 1151 - Add Softwire Tunnel Reference 1152 - Add Host Based Security check to security section 1154 May 2006 - June 2006 1155 ID 05 - 06 1156 - Fix ID Nits for IESG 1158 February - May 2006 1159 ID 04 to 05 1160 - Edits: Intro, Sections 4 and 7, References 1161 - Update definition IPv6-Dominant 1162 - Add Campus Deployment Reference 1163 - Fix ID-Nits 1165 July 2005 - February 2006 1166 ID 03 to 04 1168 - Edits to document (minor). 1170 - Removed any reference to DSTM as IETF supported mechanism. 1172 - Remove 8.4 Transition Mechanisms Recommendations. 1174 - Updated references move to RFC. 1176 - Added Normative references. 1178 June 2005 - to July 2005 1179 ID 02 to 03 1181 - Fixed more IETF id-nits. 1183 - Added Section 8.4 Transition Mechanism Summary 1184 analysis. 1186 March 2005 to June 2005 1187 ID 01 to 02 1189 - Fixed IETF id-nits. 1191 - Updated Section 3 Table 1 and added discussion of intent and 1192 scenario analysis per WG input. 1194 - Completed sections 6, 7, and 8. 1196 - Completed required Security Section. 1198 - Fixed normative vs. non-normative references. 1200 - Changed abstract and context of document to only deal with dual 1201 IP layer networks and nodes. 1203 - Removed Table of Content Campus VLAN appendix place holder. 1205 November 2004 to March 2005 1206 ID 00 to 01 1208 - Changed introduction, Section 1-3 to reflect authors and IETF WG 1209 discussions to attempt consensus on these initial sections. 1211 - Added explanation of why Appendix A is in the document to 1212 introduction. 1214 - Expanded what topics are out of scope for this document. 1216 - Updated terminology section. 1218 - Updated section 3 matrix and description to simplify and focus 1219 on dual IP layer. 1221 - Edited base text of Sections 4-7 but all three require extensive 1222 additional test for descriptions. 1224 - Edited section 8 and removed table and will reference table in 1225 section 3. This section still needs to be written. 1227 Acknowledgments 1229 The Author's would like to acknowledge contributions from the 1230 following: IETF v6ops Working Group members, Fred Baker, Pekka 1231 Savola, and Jordi Palet 1232 Author's Addresses 1234 Jim Bound 1235 HP 1236 110 Spitbrook Road 1237 Nashua, NH 03062 1238 USA 1239 Phone: 603.465.3130 1240 Email: jim.bound@hp.com 1242 Yanick Pouffary 1243 HP Competency Center 1244 950, Route des Colles, BP027, 1245 06901 Sophia Antipolis CEDEX 1246 FRANCE 1247 Phone: + 33492956285 1248 Email: Yanick.pouffary@hp.com 1250 Tim Chown 1251 School of Electronics and Computer Science 1252 University of Southampton 1253 Southampton SO17 1BJ 1254 United Kingdom 1255 Email: tjc@ecs.soton.ac.uk 1257 David Green 1258 Command Information 1259 13655 Dulles Technology Drive 1260 Suite 500 1261 Herndon, VA 20171 1262 USA 1263 Phone: 703.561.5937 1264 Email: green@commandinformation.com 1266 Steve Klynsma 1267 The MITRE Corporation 1268 7515 Colshire Drive 1269 McLean, VA 22102-5708 1270 USA 1271 703-883-6469 1272 Email: sklynsma@mitre.org 1273 Intellectual Property and Copyright Statements 1275 The IETF takes no position regarding the validity or scope of any 1276 Intellectual Property Rights or other rights that might be claimed to 1277 pertain to the implementation or use of the technology described in 1278 this document or the extent to which any license under such rights 1279 might or might not be available; nor does it represent that it has 1280 made any independent effort to identify any such rights. Information 1281 on the procedures with respect to rights in RFC documents can be 1282 found in BCP 78 and BCP 79. 1284 Copies of IPR disclosures made to the IETF Secretariat and any 1285 assurances of licenses to be made available, or the result of an 1286 attempt made to obtain a general license or permission for the use of 1287 such proprietary rights by implementers or users of this 1288 specification can be obtained from the IETF on-line IPR repository at 1289 http://www.ietf.org/ipr. 1291 The IETF invites any interested party to bring to its attention any 1292 copyrights, patents or patent applications, or other proprietary 1293 rights that may cover technology that may be required to implement 1294 this standard. Please address the information to the IETF at 1295 ietf.org. 1297 Disclaimer of Validity 1299 This document and the information contained herein are provided on an 1300 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1301 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1302 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1303 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1304 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1305 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1307 Copyright Statement 1309 Copyright (C) The Internet Society (2006). This document is subject 1310 to the rights, licenses and restrictions contained in BCP 78, and 1311 except as set forth therein, the authors retain all their rights. 1313 Acknowledgment 1315 Funding for the RFC Editor function is currently provided by the 1316 Internet Society. 1318 Appendix A - Crisis Management Network Scenarios 1320 Introduction: 1322 This appendix first describes different scenarios for the 1323 introduction of IPv6 into a crisis management network for emergency 1324 services, defense, or security forces that are currently running 1325 IPv4 service. Then, the scenarios for introducing IPv6 are analyzed 1326 and the relevance of already defined transition mechanisms are 1327 evaluated. Known challenges are also identified. 1329 When a crisis management enterprise deploys IPv6, its goal is to 1330 provide IPv6 connectivity on it's institutional fixed networks and 1331 on the mobile wireless services that are deployed to a crisis area. 1332 The new IPv6 service must be added to an already existing IPv4 1333 service, the introduction of IPv6 must not interrupt this IPv4 1334 service, and the IPv6 services must be interoperable with existing 1335 IPv4 services. 1337 Crisis management enterprises accessing IPv4 service across mobile 1338 ground networks, airborne networks, and satellites will find 1339 different ways to add IPv6 to this service based on their network 1340 architecture, funding, and institutional goals. This document 1341 discusses a small set of scenarios representing the architectures 1342 for IPv6 expected to be dominant in crisis management networks 1343 during the next decade. It evaluates the relevance of the existing 1344 transition mechanisms in the context of these deployment scenarios, 1345 and points out the lack of essential functionality in these methods 1346 to the ISP's operation of an IPv6 service. 1348 The document is focused on services that include both IPv6 and IPv4 1349 and does cover issues surrounding accessing IPv4 services across 1350 IPv6-only networks. It is outside the scope of this document to 1351 describe detailed implementation plans for IPv6 in defense networks 1353 Scenarios for IPv6 Deployment in Crisis Management Networks: 1355 Scenario 1: Limited IPv6 Deployment Network..................... 1357 Sparse IPv6 dual-stack deployment in an existing IPv4 network 1358 infrastructure. Enterprise with an existing IPv4 network wants to 1359 deploy a set of particular IPv6 "applications" and have some 1360 ability to interoperate with other institutions that are using IPv6 1361 services. The IPv6 deployment is limited to the minimum required to 1362 operate this set of applications. 1364 Assumptions: IPv6 software/hardware components for the application 1365 are available, and platforms for the application are IPv6 capable. 1367 Requirements: Do not disrupt IPv4 infrastructure. 1369 Scenario 2: Dual Stack Network 1371 Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable 1372 hosts and network infrastructure. Enterprise with an existing IPv4 1373 network wants to deploy IPv6 in conjunction with their IPv4 network 1374 in order to take advantage of emerging IPv6 network-centric 1375 capabilities and to be interoperable with other agencies, 1376 international partners, and commercial enterprises that are 1377 deploying an IPv6 architecture. 1379 Assumptions: The IPv4 network infrastructure used has an 1380 equivalent capability in IPv6. 1382 Requirements: Do not disrupt existing IPv4 network infrastructure 1383 with IPv6. IPv6 should be equivalent or "better" than the network 1384 infrastructure in IPv4. It may not be feasible to deploy IPv6 on 1385 all parts of the network immediately. Dual stacked defense 1386 enterprise network must be interoperable with both IPv4 and IPv6 1387 networks and applications. 1389 Scenario 3: IPv6 Dominant Network 1391 Enterprise has some limited IPv4-capable/only nodes/applications 1392 needing to communicate over the IPv6 infrastructure. Crisis 1393 management enterprise re-structuring an existing network, decides 1394 to pursue aggressive IPv6 transition as an enabler for network- 1395 centric services and wants to run some native IPv6-only networks to 1396 eliminate cost/complexity of supporting a dual stack. Some legacy 1397 IPv4 capable nodes/applications within the enterprise will have 1398 slow technical refresh/replacement path and will need to 1399 communicate over the IPv6 dominant infrastructure for years until 1400 they are replaced. The IPv6 dominant enterprise network will need 1401 to be interoperable with it's own legacy networks, commercial 1402 networks, and the legacy networks of similar organizations that 1403 will remain IPv4 dominant during a long transition period. Reserve 1404 units, contractors, other agencies, and international partners may 1405 need IPv4 service across this enterprise's IPv6 dominant backbone. 1407 Assumptions: Required IPv6 network infrastructure is available, or 1408 available over some defined timeline, supporting the aggressive 1409 transition plan. 1411 Requirements: Reduce operation and maintenance requirements and 1412 increase net-centricity through aggressive IPv6 transition. 1413 Interoperation and coexistence with legacy IPv4 networks and 1414 applications is required. Legacy IPv4 nodes/applications/networks 1415 will need to be able to operate across the IPv6 backbone and need 1416 to be able to interoperate with the IPv6-dominant network's 1417 nodes/applications. 1419 Description of a Generic Crisis Management Network 1421 A generic network topology for a crisis management reflects the 1422 various ways a crisis management network can connect customers 1423 through their network infrastructure. Because the institution's 1424 existing wired and fixed site wireless infrastructure can be 1425 destroyed or unavailable in a crisis, the crisis management network 1426 must be able to deploy it's own mobile wireless network or connect 1427 through external wired and wireless networks provided by ISPs or 1428 partner organizations. This infrastructure lets us divide the 1429 basic areas for IPv4/IPv6 interoperability into three main areas: 1430 the customer applications, the local network, and the network 1431 backbone. 1433 The basic components in a crisis management network are depicted in 1434 Figure 1. 1436 ------------ ---------- ---- Wired Connection 1437 | Network and| | | .... Wireless Connection 1438 | Service |--| Backbone | 1439 | Operation | | | 1440 ------------ ---------- 1441 / | --------------------- 1442 / : _|Connection to | 1443 / : |Commercial Internet | 1444 / : --------------------- 1445 Network Backbone 1446 -------------- /------|-------------|-------------------- 1447 ---------- / ---------- ---------- 1448 | Home |/ | Wireless | External |............. 1449 | Base | | Mobile | |Untrusted |+--------- : 1450 | Network | | Network | |Network | | : 1451 ---------- ---------- ---------- | : 1452 | : : | : 1453 Local Network 1454 -----:------------:----------------------------------- 1455 Custome Applications 1456 | : : | : 1457 +--------+ +--------+ +--------+ | : 1458 | | | | | | | : 1459 |Customer| |Customer| |Customer|+----------- : 1460 | | | | | |.............. 1461 +--------+ +--------+ +--------+ 1463 Figure 1: Crisis Management Network Topology. 1465 Stages of IPv6 Deployment: 1467 The stages are derived from the generic description of scenarios 1468 for crisis management networks in Section 2. Combinations of 1469 different building blocks that constitute an crisis network 1470 environment lead to a number of scenarios from which the network 1471 engineers can choose. The scenarios most relevant to this document 1472 are those that maximize the network's ability to offer IPv6 to its 1473 customers in the most efficient and feasible way. The assumption in 1474 the first three stages the goal is to offer both IPv4 and IPv6 to 1475 the customer, and that in the distant future all IPv4 services will 1476 be eventually switched to IPv6. This document will cover 1477 engineering the first four stages. 1479 The four most probable stages are: 1481 o Stage 1 Limited Launch 1482 o Stage 2 Dual Stack Dominance 1483 o Stage 3 IPv6 Dominance 1484 o Stage 4 IPv6 Transition Complete 1486 Generally, a crisis management network is able to entirely upgrade 1487 a current IPv4 network to provide IPv6 services via a dual-stack 1488 network in Stage 2 and then slowly progress to stages 3 and 4 as 1489 indicted in Figure 2. During stage 2, When most applications are 1490 IPv6 dominant, operational and maintenance costs can be reduced on 1491 some networks by moving to stage 3 and running backbone networks 1492 entirely on IPv6 while adding IPv4 backwards compatibility via v4 1493 in v6 tunneling or translation mechanisms to the existing 1494 configuration from stage 2. When designing a new network, if a new 1495 IPv6-only service is required, it can be implemented at a lower 1496 cost jumping directly to stage 3/4 if there are only limited/no 1497 legacy concerns. 1499 Stage 1 Scenario: Limited Launch 1500 The first stage begins with an IPv4-only network and IPv4 1501 customers. This is the most common case today and the natural 1502 starting point for the introduction of IPv6. During this stage the 1503 enterprise begins to connect individual IPv6 applications run on 1504 dual stacked hosts through host based tunneling using Tunnel 1505 Broker, ISATAP, Teredo. Some early adopter networks are created for 1506 pilot studies and networked together through configured tunnels and 1507 6to4. 1509 The immediate first step consists of obtaining a prefix allocation 1510 typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC, 1511 ARIN, LACNIC, RIPE) according to allocation procedures. 1513 The crisis management enterprise will also need to establish IPv6 1514 connectivity between its home base networks and mobile wireless 1515 networks over it's backbone and negotiate IPv6 service with its 1516 service providers and with peer organizations; it is of utmost 1517 importance to require IPv6 capability or an upgrade plan when 1518 negotiating purchases of network applications and infrastructure. 1519 In the short term, network connections, especially legacy wireless 1520 networks, that cannot provide IPv6 services can provide IPv6 1521 services through the use of tunnels. However, the longer-term goal 1522 must be requiring and obtaining IPv6 native connectivity from the 1523 transit networks, because otherwise the quality of IPv6 1524 connectivity will likely be poor and the transition to stage 2 will 1525 be delayed. 1527 Stage 2 Scenario: Dual Stack Dominance 1529 Stage 2 occurs when most applications, local networks, and network 1530 backbones become dual-stacked so that native IPv6 connections are 1531 enabled. At this point there is a mix of IPv4 and IPv6 applications 1532 and services in use across the enterprise. The enterprise may be 1533 made IPv6-capable through either software upgrades, hardware 1534 upgrades, or a combination of both. Generally IPv6 is added during 1535 normal technical refresh as the enterprise buys new equipment that 1536 is IPv6 ready. 1538 Specialty legacy applications and wireless/satellite networks may 1539 be especially slow to transition to IPv6 capability due to upgrade 1540 costs so plans must be made for backwards compatibility for these 1541 systems. Since some new IPv6 services cannot be provided through 1542 IPv4, and some legacy network connections may not yet be upgraded, 1543 tunneling mechanisms have to be provided on the backbone to provide 1544 IPv6 connectivity through to customer IPv6 applications still 1545 relying on legacy IPv4-only networks. The tunnels may provide 1546 host-based tunneling for individual customers or site-to-site 1547 tunnels to connect small IPv6 domains through IPv4 only networks. 1548 If any new applications are IPv6-only rather than dual-stacked, and 1549 need to interact with IPv4-only legacy applications, translators 1550 will be used as a transition mechanism of last resort during this 1551 stage. 1553 Stage 3 Scenario: IPv6 Dominance 1555 Applications are deployed specifically to use IPv6 as benefit, thus 1556 network backbone and nodes use IPv6 and not IPv4, except where IPv4 1557 is legacy.