idnits 2.17.1 draft-ietf-v6ops-ent-analysis-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 3667, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1289. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1307), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 46. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 26) being 90 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 664 has weird spacing: '... and emphasiz...' == Line 1155 has weird spacing: '... stacks tra...' == Line 1158 has weird spacing: '...cations back...' == Line 1181 has weird spacing: '...ce with its...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'VLAN' is mentioned on line 410, but not defined == Missing Reference: 'V6DEF' is mentioned on line 440, but not defined == Missing Reference: 'ULAs' is mentioned on line 594, but not defined == Missing Reference: 'NAT-PT' is mentioned on line 675, but not defined == Missing Reference: 'SOCKS' is mentioned on line 672, but not defined == Unused Reference: 'CONF' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'DHCPF' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'DHCPL' is defined on line 829, but no explicit reference was found in the text == Unused Reference: 'TRDO' is defined on line 841, but no explicit reference was found in the text == Unused Reference: 'DSTM' is defined on line 847, but no explicit reference was found in the text == Unused Reference: 'ISTP' is defined on line 850, but no explicit reference was found in the text == Unused Reference: 'SEC1' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'NATPT' is defined on line 871, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSV6' ** Obsolete normative reference: RFC 2462 (ref. 'CONF') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (ref. 'DHCPF') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3756 (ref. 'DHCPL') -- Possible downref: Non-RFC (?) normative reference: ref. 'APPS' -- Possible downref: Non-RFC (?) normative reference: ref. 'BSCN' -- Possible downref: Non-RFC (?) normative reference: ref. 'TRDO' ** Obsolete normative reference: RFC 2893 (ref. 'BCNF') (Obsoleted by RFC 4213) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSTM' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISTP' ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. 'TBRK') -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ULA' -- Possible downref: Non-RFC (?) normative reference: ref. 'RENUM' ** Obsolete normative reference: RFC 3177 (ref. 'ALLOC') (Obsoleted by RFC 6177) ** Obsolete normative reference: RFC 2766 (ref. 'NATPT') (Obsoleted by RFC 4966) -- Possible downref: Non-RFC (?) normative reference: ref. 'UMAN' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISPA' -- Possible downref: Non-RFC (?) normative reference: ref. '3GPA' Summary: 14 errors (**), 0 flaws (~~), 21 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group 3 Internet Draft Jim Bound 4 Document: draft-ietf-v6ops-ent-analysis-00.txt Yanick Pouffary 5 Obsoletes: None HP 6 Expires: March 2005 Tim Chown 7 University of Southampton 8 David Green 9 SRI 10 Jordi Palet 11 Consulintel 12 Steve Klynsma 13 Mitre 15 IPv6 Enterprise Network Analysis 17 19 Status of this Memo 20 By submitting this Internet-Draft, I certify that any applicable 21 patent or other IPR claims of which I am aware have been 22 disclosed, and any of which I become aware will be disclosed, in 23 accordance with RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet- 33 Drafts as reference material or to cite them other than as "work 34 in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 10, 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2004). All Rights Reserved. 48 Abstract 50 This document analyzes the transition to IPv6 in enterprise 51 networks. These networks are characterized as a network that has 52 multiple internal links, one or more router connections, to one or 53 more Providers, and is managed by a network operations entity. The 54 analysis will focus on a base set of transition units and 55 requirements expanded from a previous Enterprise Scenarios 56 document, and will depict a set of components and transition 57 methods required for the enterprise to transition to IPv6 within 58 each scenario and then common to all scenarios. 60 Table of Contents: 62 1 Introduction.................................................3 63 2 Terminology..................................................5 64 3 Enterprise Matrix Analysis for Transition....................6 65 4 Wide-Scale Dual-Stack Deployment.............................8 66 4.1 Phased Dual-Stack Deployment...............................8 67 4.2 Analysis of Required Tools for Dual-Stack Deployment.......9 68 4.3 IPv6-Capable Existing Routing Infrastructure Available.....9 69 4.4 No IPv6-Capable Existing Routing Infrastructure............9 70 4.4.1 Tunnel IPv6 over the IPv4 infrastructure.................9 71 4.4.2 Deploy a parallel IPv6 infrastructure...................10 72 4.5 Remote IPv6 access to the enterprise......................10 73 4.6 Other considerations......................................10 74 5 Sparse Dual-Stack Deployment................................11 75 5.1 Internal versus External Tunnel-End-Point.................11 76 5.2 Manual versus Autoconfigured..............................12 77 6 IPv6 Dominant Network Deployment............................13 78 7 General issues and applicability for all Scenarios..........14 79 7.1 Phased Plan for IPv6 Deployment............................14 80 7.2 Network Infrastructure Requirements.......................14 81 7.3 Phase 1: Initial connectivity steps........................14 82 7.3.1 Obtaining external connectivity..........................14 83 7.3.2 Obtaining global IPv6 address space......................15 84 7.4 Phase 2: Deploying generic basic service components........15 85 7.4.1 IPv6 DNS.................................................15 86 7.4.2 IPv6 Routing............................................15 87 7.4.3 Configuration of Hosts..................................16 88 7.4.4 Developing an IPv6 addressing plan......................16 89 7.4.5 Security................................................16 90 7.4.6 IPv4-IPv6 interworking..................................17 91 7.5 Phase 3: Widespread Dual-Stack deployment on-site.........17 92 7.5.1 Deploying IPv6 across the enterprise....................17 93 7.5.2 Supporting remote access................................17 94 8 Applicable Transition Mechanisms............................19 95 9 Security Considerations.....................................21 96 10 References.................................................21 97 10.1 Normative References.....................................21 98 10.2 Non-Normative References.................................22 99 Document Acknowledgments.......................................22 100 Author's Address...............................................23 101 Appendix A - Campus Deployment Scenario with VLANs.............24 102 Appendix B - Crisis Management Network Scenarios...............25 103 Intellectual Property and Copyright Statements.................30 104 1 Introduction 106 This document analyzes the transition to IPv6 in enterprise 107 networks. These networks are characterized as a network that has 108 multiple internal links, one or more router connections, to one or 109 more Providers, and is managed by a network operations entity. The 110 analysis will focus on a base set of transition units and 111 requirements expanded from a previous Enterprise Scenarios 112 document, and will depict a set of components and transition 113 methods required for the enterprise to transition to IPv6 within 114 each scenario and then common to all scenarios. 116 The audience for this document is the enterprise network team 117 considering deployment of IPv6. The document will be useful for 118 enterprise teams that will have to determine the IPv6 transition 119 strategy for their enterprise. It is expected those teams include 120 members from management, network operations, and engineering. The 121 scenarios presented provide an example set of cases the enterprise 122 can use to build an IPv6 network scenario. 124 The enterprise analysis will begin by describing a matrix tool to 125 be used to portray the different IPv4 and IPv6 possibilities for 126 deployment. The first column (Application/Host 1 OS) represents the 127 IP-capability offered by the node that originates IP packets. The 128 second to last column (Application/Host 2 OS) represents the IP- 129 capability offered by the node that terminates the IP packet. In 130 between are three columns that represent the IP-capability of 131 typical networks traversed by the packet, including an originating 132 host network (Host 1 Network),Service Provider Network and 133 Destination Host Network (Host 2 Network). Each row (1 through 13) 134 is one possible scenario and the final column shows the recommended 135 transition mechanism to use for that particular scenario. 137 The objective of this document is to take the [BSCN] scenarios and 138 then integrate those with a basic unit transition set in the course 139 of this analysis to provide a set of options for an enterprise, 140 where one size does not fit all. 142 Will expand on this part of the introduction in next draft. 144 The following specific topics are currently out of scope for this 145 document: 147 - Multihoming 148 - Application transition/porting (see [APPS]). 149 - IPv6 VPN, firewall or intrusion detection deployment 150 - IPv6 network management and QoS deployment 151 - Detailed IT Department requirements 152 - Deployment of novel IPv6 services, e.g. MIPv6 153 - +others?? 155 Thus, we are focusing in this document on Layer 3 deployment, in 156 the same way as the other IPv6 deployment scenario texts have done 157 [UMAN,ISPA, 3GPA]. This document covers deployment of IPv6 "on the 158 wire", including address management and DNS services. 160 We are also assuming that the enterprise deployment is one being 161 undertaken by the network administration team, i.e. this document 162 is not discussing the case of an individual user gaining IPv6 163 connectivity (to some external IPv6 provider) from within an 164 enterprise network. 166 In Section 2 we introduce the terminology used in this document. 167 In Section 3 we introduce and define an enterprise matrix and 168 define the layer 3 connectivity requirements. In Section 4 we 169 discuss wide scale dual-stack use within an enterprise. In section 170 5 we discuss sparse dual-stack deployment within an enterprise. In 171 section 6 we discuss IPv6 dominant network deployment within the 172 enterprise. In section 8 we analyze the applicable transition 173 mechanisms to support the matrix defined in Section 1 referencing 174 the discussions in Sections 4, 5, 6, and 7. 176 2 Terminology 178 Enterprise Network - A network that has multiple internal links, 179 one or more router connections, to one or 180 more Providers and is actively managed by a 181 network operations entity. 183 Provider - An entity that provides services and 184 connectivity to the Internet or 185 other private external networks for the 186 enterprise network. 188 IPv6 Capable - A node or network capable of supporting both 189 IPv6 and IPv4. 191 IPv4 only - A node or network capable of supporting only 192 IPv4. 194 IPv6 only - A node or network capable of supporting only 195 IPv6. This does not imply an IPv6 only 196 stack, in this document. 198 IPv6 Dominant - A network or link that uses only IPv6 routing. 199 Network 201 3 Enterprise Matrix Analysis for Transition 203 To provide layer 3 enterprise analysis context for discussion we 204 provide for this document the use of a matrix with most common 205 transition scenarios to exist for the enterprise. 207 Table 1 below is a matrix of thirteen possible transition scenarios 208 that may be encountered in the enterprise. The first column 209 (Application/Host 1 OS) represents the IP-capability offered by the 210 node that originates IP packets. The second to last column 211 (Application/Host 2 OS) represents the IP-capability offered by the 212 node that terminates the IP packet. In between are three columns 213 that represent the IP-capability of typical networks traversed by 214 the packet, including an originating host network (Host 1 215 Network),Service Provider Network and Destination Host Network 216 (Host 2 Network). 218 As an example, Scenario 1 is an IPv6 application trying to 219 establish a communications exchange with a destination v4 only 220 application. Since proper porting of the application to the host 221 is a prerequisite, the IP-capability of the operating system at 222 both originating and destination host is not specifically addressed 223 herein. To complete the information exchange the packets must 224 first traverse the host's originating IPv4 network, then the 225 service provider's dual-IP network and finally, the destination 226 host's network. 228 Obviously Table 1 does not describe every possible scenario. 229 Trivial scenarios (such as pure IPv4, pure IPv6, and straight- 230 forward tunneling or translation) are not addressed. Instead we 231 will use these thirteen to address the analysis for enterprise 232 deployment. 234 ====================================================== 235 |Application |Host 1 |Service |Host 2 |Application | 236 |----------- |Network|Provider|Network|---------- | 237 | Host 1 OS | | | | Host 2 OS | 238 =====================================+================ 239 |IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6| 240 1 |---- or ----| or |Dual IP | or |---- or ----| 241 |IPv6 Dual|v6 Only| |v6 only|IPv6 Dual| 242 ====================================================== 243 |IPv4 IPv4| | | |IPv4 IPv4| 244 2 |---- or ----|Dual IP|Dual IP |Dual IP|---- or ----| 245 |IPv4 Dual| | | |IPv4 Dual| 246 ====================================================== 247 | IPv6 | | | | IPv6 | 248 3 | ---- | IPv4 |Dual IP |Dual IP| ---- | 249 | Dual | | | | IPv6 | 250 ====================================================== 251 | IPv6 | | | |IPv4 IPv4| 252 4 | ---- | IPv4 |Dual IP |Dual IP|---- or ----| 253 | Dual | | | |IPv4 Dual| 254 ====================================================== 255 | IPv6 | | | | IPv6 | 256 5 | ---- | IPv4 | IPv4 |Dual IP| ---- | 257 | Dual | | | | IPv6 | 258 ====================================================== 259 |IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6| 260 6 |---- or ----| or | IPv4 | or |---- or ----| 261 |IPv6 Dual|v6 only| |v6 only|IPv6 Dual| 262 ====================================================== 263 | IPv6 |Dual IP| IPv4, | | IPv4 | 264 7 | ---- | or | IPv6 or| IPv4 | ---- | 265 | IPv6 |v6 only|Dual IP | | IPv4 | 266 ====================================================== 267 | IPv6 |Dual IP| None - | | IPv4 | 268 8 | ---- | or | Local | IPv4 | ---- | 269 | IPv6 |v6 only| Connect| | IPv4 | 270 ====================================================== 271 | IPv4 | | | | IPv4 | 272 9 | ---- | IPv4 |v6 only | IPv4 | ---- | 273 | IPv4 | | | | IPv4 | 274 ====================================================== 275 | Dual | | | | IPv4 | 276 10| ---- |Dual IP| v6 Only| IPv4 | ---- | 277 | Dual | | | | IPv4 | 278 ====================================================== 279 | Dual | | | | IPv4 | 280 11| ---- |v6 only| v6 only| IPv4 | ---- | 281 | Dual | | | | IPv4 | 282 ====================================================== 283 | IPv6 | | | | IPv6 | 284 12| ---- |Dual IP|v6 only |Dual IP| ---- | 285 | Dual | | | | Dual | 286 ====================================================== 287 | IPv6 | | | | IPv6 | 288 13| ---- |v6 only|v6 only |v6 only| ---- | 289 | IPv6 | | | | IPv6 | 290 ====================================================== 292 4 Wide-Scale Dual-Stack Deployment 294 In this section we are covering Scenario 1 as described in Section 295 3.1 of [BSCN]. The scenario, assumptions and requirements are 296 driven from the [BSCN] text. 298 A common scenario for IPv6 deployment is the enterprise network 299 that wishes to introduce IPv6 by enabling IPv6 on the wire in a 300 structured fashion with the existing IPv4 infrastructure. In such 301 a scenario, a number of the existing IPv4 routers (and thus 302 subnets) will be made dual-stack, such that communications can run 303 over either protocol. 305 Nodes within the dual-stack links may themselves be IPv4-only, 306 IPv6-only or dual-stack. The driver for deploying IPv6 may not be 307 for immediate wide-scale usage of IPv6, but rather to prepare an 308 existing IPv4 infrastructure with IPv6 capability, such that dual- 309 stack nodes, or later IPv6-only nodes, can be deployed. 311 We analyze the scenario against existing transition mechanisms for 312 their applicability, suggesting a phased approach for IPv6 313 deployment in the enterprise. 315 4.1 Phased Dual-Stack Deployment 317 The site administrator should formulate a phased plan for the 318 introduction of dual-stack IPv6 network. We suggest that the 319 generic plan of Section 7 of this document provides a good basis 320 for such a plan. 322 The generic plan has a number of stages/phases that are independent 323 of whether dual-stack or IPv6-dominant deployment is undertaken. 325 In an enterprise network, the administrator will generally seek to 326 deploy IPv6 in a structured, controlled manner, such that IPv6 can 327 be enabled on specific links at specific stages of deployment. It 328 may be a specific requirement that some links remain IPv4 only, or 329 specifically should not have IPv6 connectivity. It may also be a 330 requirement that aggregatable global IPv6 addresses, assigned by 331 the enterprise's upstream provider from the address space allocated 332 to them by the Regional Internet Registries (RIRs), are used for 333 assignment. 335 In this document we do not advocate or discuss the deployment of 336 Unique Local IPv6 Unicast Addresses [ULA]. We do strongly suggest 337 that IPv6 NAT is not deployed, as doing so negates the key 338 advantages of moving to the new Internet Protocol version. 340 A typical deployment would involve the establishment of a single 341 "testbed" IPv6 capable subnet at the enterprise site, prior to 342 wider deployment. Such a testbed not only allows the IPv6 343 capability of specific platforms and applications to be evaluated 344 and verified, it also allows the steps in Sections 7.3 and 7.4 of 345 this document to be undertaken without (potential) adverse impact 346 on the production elements of the enterprise. 348 Section 7.5 describes the stages for the widespread deployment in 349 the enterprise, which would be undertaken after the basic building 350 blocks for deployment are in place. 352 4.2 Analysis of Required Tools for Dual-Stack Deployment 354 The critical part of the dual-stack deployment is the IPv6 routing 355 infrastructure. The path taken will depend on whether the 356 enterprise has existing Layer 2/3 switch/router equipment that has 357 an IPv6 (routing) capability, or that can be upgraded to have such 358 capability. 360 In Section 4, we are not considering sparse IPv6 deployment; the 361 goal of dual-stack deployment is widespread use in the enterprise. 363 4.3 IPv6-Capable Existing Routing Infrastructure Available 365 Where IPv6 routing capability exists in existing infrastructure, the 366 network administrator can enable IPv6 on the same physical hardware 367 as the existing IPv4 service. This is the end goal of any 368 enterprise dual-stack deployment, when the capability, performance, 369 and robustness of the dual-stack operational deployment is verified. 371 Ideally, the IPv6 capability will span the entire enterprise, 372 allowing deployment at any link or subnet. If not, techniques from 373 Section 4.4 below may be required. 375 4.4 No IPv6-Capable Existing Routing Infrastructure 377 In this case the enterprise administrator faces two basic choices, 378 either to tunnel IPv6 over some or all of the existing IPv4 379 infrastructure, or to deploy a parallel IPv6 routing infrastructure 380 providing IPv6 connectivity into existing IPv4 subnets. 382 It may thus be the case that a nodes IPv4 and IPv6 default routes 383 off-link are through different routing platforms. 385 4.4.1 Tunnel IPv6 over the IPv4 infrastructure 387 The tunneling, as described in [BCNF] would be established between 388 dual-stack capable routers on the enterprise, thus "bypassing" 389 existing non IPv6-capable routers and platforms. For example, some 390 IPv6 edge routers in the enterprise may be IPv6 capable, while 391 others, and perhaps the enterprise backbone itself, are not. 393 In the widespread dual-stack scenario, a more structured, manageable 394 method is required, where the administrator has control of the 395 deployment per-subnet and (ideally) long-term, aggregatable global 396 IPv6 addressing is obtained, planned and used from the outset. 398 4.4.2 Deploy a parallel IPv6 infrastructure 400 In this case, the administrator may deploy a new, separate IPv6- 401 capable router (or set of routers). It is quite possible that such 402 a parallel infrastructure would be IPv6 only. 404 Such an approach means acquiring additional hardware, but it has the 405 advantage that the existing IPv4 routing platforms are not disturbed 406 by the introduction of IPv6. 408 To distribute IPv6 to the existing IPv4 enterprise subnets, either 409 dedicated physical infrastructure can be deployed or, if it is 410 available, IEEE 802.1q VLANs could be used, as described in [VLAN]. 411 The latter has the significant advantage of not requiring any 412 additional physical cabling/wiring; it offers all the advantages of 413 VLANs for the new dual-stack environment. 415 Many router platforms can tag multiple VLAN IDs on a single physical 416 interface based on the subnet/link the packet is destined for; thus 417 multiple IPv6 links can be collapsed for delivery on a single (or 418 small number of) physical IPv6 router interfaces in the early stages 419 of deployment. 421 The parallel infrastructure would only ever be seen as an interim 422 step towards a full dual-stack deployment on a unified 423 infrastructure. The parallel infrastructure however allows all 424 other aspects of the IPv6 enterprise services to be deployed, 425 including IPv6 addressing, ready for that unifying step at a later 426 date. 428 4.5 Remote IPv6 access to the enterprise 430 Where the enterprise's users are off-site, and using an ISP that 431 does not support any native IPv6 service or IPv6 transition aids, 432 the enterprise may consider deploying it's own remote IPv6 access 433 support, as described in Section 7.5.2. 435 4.6 Other considerations 437 There are some identified issues with turning IPv6 on by default, 438 including application connection delays, poor connectivity, and 439 network insecurity, as discussed in [V6DEF]. The issues can be 440 worked around or mitigated by following the advice in [V6DEF]. 442 443 5 Sparse Dual-Stack Deployment 445 This section covers the Scenario 2 as described in Section 3.1 of 446 [BSCN]. This scenario assumes the requirements defined with the 447 [BSCN] text. 449 IPv6 deployment within the enterprise network, with an existing 450 IPv4 infrastructure, could be motivated by mission critical or 451 business applications or services that require IPv6. In this case 452 the prerequisite is that only the nodes using those IPv6 453 applications need to be upgraded to a dual-stack. The routing 454 infrastructure will not be upgraded to support IPv6, nor does the 455 enterprise wish to deploy a parallel IPv6 routing infrastructure at 456 this point, since this is an option in section 4. 458 The lack of existing IPv6-enabled routing infrastructure implies 459 the usage of IPv4 and IPv6 in the nodes. There is a need for end- 460 to-end communication with IPv6, but the infrastructure only 461 supports IPv4 transport. Thus the only viable method for end-to-end 462 communication with IPv6 is to tunnel the traffic over the existing 463 IPv4 infrastructure. 465 The network team needs to decide which is the most efficient among 466 the available transition tunneling mechanisms to deploy, so they 467 can be used without disrupting the existing IPv4 infrastructure. 469 Several decisions need to be taken into consideration, as 470 introduced in the following subsections. 472 5.1 Internal versus External Tunnel-End-Point 474 The upstream provider could have already deployed some IPv6 475 service, either native IPv6 in its backbone or in the access 476 network, or a combination of both. Also, or alternatively, could 477 have deployed one or several transition mechanisms based upon 478 tunnels, for example in the case where the access network doesn't 479 support IPv6. In this case, the enterprise could decide to use 480 those available transition services from the ISP. However, this 481 will usually mean that the each of the different nodes in the 482 network will have their own IPv6-in-IPv4 tunnel. Then, the IPv6 483 intranet communication will not be efficient, as it will require 484 all the traffic to be forwarded by the IPv4 infrastructure to the 485 Tunnel-End-Point located at the ISP. This could be acceptable if 486 the IPv6 applications do not require intranet communication at all, 487 for example in the case the application server that is located 488 outside of the enterprise network, or in other networks of the same 489 enterprise. 491 The enterprise could also decide to deploy its own transition box 492 and possibly collocate it adjacent to the border router that 493 connects to the upstream provider. In this case, the intranet 494 communication is also possible. 496 5.2 Manual versus Autoconfigured 498 If the number of nodes to be using IPv6 is reduced, an option is to 499 use statically configured tunnels. 501 However, in general automatic configured tunnels will be preferred. 503 Section 5 doesn't yet discuss pros and cons of connecting sparse 504 nodes, nor management/security issues. We need to add that in -01. 506 6 IPv6 Dominant Network Deployment 508 In this section we are covering Scenario 3 as described in Section 509 3.1 of [BSCN]. The scenario, assumptions and requirements are 510 driven from the [BSCN] text. 512 IPv6 deployment in some enterprise networks will use a dominant 513 IPv6 network deployment strategy. What this means essentially is 514 that the network or specific sites within the enterprise network 515 will transition to IPv6 using only IPv6 routing to transfer both 516 IPv4 and IPv6 packets over the network. 518 IPv6 communications between IPv6 nodes will use IPv6 to 519 communicate. When IPv6 dual-stack nodes in the dominant IPv6 520 network need to communicate with IPv4 nodes, in the dominant IPv6 521 network, the IPv6 nodes will use their IPv4 implementation of the 522 dual-stack to tunnel IPv4 packets in IPv6 [6TUN], and an edge 523 router within the dominant IPv6 network will decapsulate the IPv4 524 packet and route to the path of the IPv4 node on the network. This 525 permits dual-stack nodes to communicate with legacy IPv4 nodes 526 within a dominant IPv6 network. 528 Use of IPv4 within the dominant network and past the edge of the 529 dominant network to be added. 531 Add subsection on analysis of end-2-end security and not using NAT 532 to communicate with IPv4 legacy nodes. 534 This section to be completed. 536 7 General issues and applicability for all Scenarios 538 In this section we describe generic enterprise IPv6 deployment 539 issues, applicable to each of the scenarios described above. 541 7.1 Phased Plan for IPv6 Deployment 543 The enterprise network administrator will need to follow a staged 544 plan for IPv6 deployment. 546 548 7.2 Network Infrastructure Requirements 550 The considerations for the enterprise components are detailed in 551 Section 3.2 of [BSCN]. We do not go into detail of all aspects of 552 such components in this document. In this document we focus on 553 Layer 3 issues. 555 557 7.3 Phase 1: Initial connectivity steps 559 The first steps for IPv6 deployment do not involve technical 560 aspects per se; the enterprise needs to select an external IPv6 561 provider, and obtain globally routable IPv6 address space from that 562 provider. 564 7.3.1 Obtaining external connectivity 566 The enterprise service provider would typically be a 567 topographically close (to minimize connectivity RTT) IPv6 provider 568 that is able to provide an IPv6 upstream link. 570 It would be expected that the enterprise would use either native 571 IPv6 upstream connectivity or, in its absence, a manually 572 configured tunnel [BCNF] to the upstream provider. 574 It is not recommended to use 6to4 [6TO4] or a tunnel broker [TBRK] 575 for an enterprise deployment. The enterprise has a requirement for 576 long-term, stable IPv6 connectivity. 6to4 and the tunnel broker 577 are more appropriate for SOHO or single node environments. Use of 578 6to4 also prevents the enterprise adopting aggregatable global IPv6 579 addressing from the outset. 581 7.3.2 Obtaining global IPv6 address space 583 The enterprise will obtain global IPv6 address space from its 584 selected upstream provider, as provider assigned (PA) address 585 space. 587 The enterprise should receive at least a /48 allocation from its 588 provider, as described in [ALLOC]. 590 There is currently no Provider Independent (PI) address space 591 available. The procedure for enterprise renumbering between 592 providers is described in [RENUM]. 594 Unique Local Addressing [ULAs] should not be used for enterprise 595 networks. 597 7.4 Phase 2: Deploying generic basic service components 599 Most of these are discussed in Section 4 of [BSCN]. Here we 600 comment on those aspects that we believe are in scope for this 601 analysis document. Thus we have not included network management, 602 multihoming, multicast or application transition analysis here, but 603 these aspects should be addressed in Phase 2. 605 7.4.1 IPv6 DNS 607 The enterprise site should deploy a DNS service that is capable of 608 both serving IPv6 DNS records (of the AAAA format, see RFC????) and 609 of communicating over IPv6 transport. 611 Specific IPv6 DNS issues are reported in [DNSV6]. 613 7.4.2 IPv6 Routing 615 The enterprise network will need to support methods for internal 616 and external routing. 618 For a single-homed single-site network, a static route to a single 619 upstream provider may be sufficient, although the site may choose 620 to use an exterior routing protocol, especially where it has 621 multiple upstream providers. 623 For internal routing, an appropriate interior routing protocol may 624 be deployed. 626 IPv6 is standardized and capability exists in BGP4+ (RFC????), IS- 627 IS (RFC????), OSPFv3 (RFC????) and RIPng (RFC????). 629 Availability of such routing implementations will naturally vary 630 between vendors. Such commentary is outside the scope of this 631 document. 633 7.4.3 Configuration of Hosts 635 An enterprise network will have a number of tools available for 636 IPv4 address and other configuration information delegation and 637 management, including manual configuration, NIS or DHCP. 639 In an IPv6 enterprise, Stateless Address Autoconfiguration 640 (RFC2462) may be used to configure a host with a global IPv6 641 address, a default router, an on-link prefix information. 643 For secure autoconfiguration, the SEND protocol is defined (now at 644 RFC????). 646 A stateless configured node wishing to gain other configuration 647 information (e.g. DNS, NTP servers) will likely need a Stateless 648 DHCPv6 service available. 650 For nodes configuring via DHCPv6, where DHCPv6 servers are offlink, 651 a DHCPv6 Relay Agent function will be required. 653 Hosts may also generate or request IPv6 Privacy Addresses 654 (RFC3041); there is support for DHCPv6 to assign privacy addresses 655 to nodes in managed environments. 657 7.4.4 Developing an IPv6 addressing plan 659 661 7.4.5 Security 663 666 7.4.6 IPv4-IPv6 interworking 668 In the case of an IPv6 only node in an IPv6-dominant or dual-stack 669 enterprise, wishing to communicate with external IPv4-only systems, 670 some interworking (translation) method is required. The 671 translation could be applied at Layer 3 (e.g. [NAT-PT]), Layer 4 672 (e.g. [SOCKS]) or Layer 7 (a dual-stack application layer gateway - 673 ALG). 675 Use of [NAT-PT] is discouraged [cite the I-D on this?]. A 676 recommended solution is the use of ALGs. Many applications 677 naturally have an ALG behavior, and can be used to offer access for 678 "legacy" IPv4 services such as SMTP (dual-stack email server, see 679 [cite I-D, by Alain I think?]) or HTTP (a dual-stack web cache), 680 and are already operated by many enterprise sites. By dual-stacking 681 the servers, an IPv6 only node can reach an external IPv4-only web 682 site (for example) via the proxy without any additional (Layer 3 or 683 4) translation being required. 685 7.5 Phase 3: Widespread Dual-Stack deployment on-site 687 With the basic building blocks of external connectivity, interior 688 IPv6 routing, an IPv6 DNS service and address allocation management 689 in place, the IPv6 capability can be rolled out to the wider 690 enterprise. This involves putting IPv6 on the wire in the desired 691 links, and enabling applications and other services to begin using 692 IPv6 transport. 694 7.5.1 Deploying IPv6 across the enterprise 696 In the dual-stack case, this means enabling IPv6 on existing IPv4 697 subnets. It is most likely that the administrator will deploy IPv6 698 links to be congruent with existing IPv4 subnets (because IPv4 699 subnets tend to be created for geographic, policy or administrative 700 reasons that would be IP-independent). 702 7.5.2 Supporting remote access 704 Where an enterprise's users may be working off-site, and their 705 transient ISP has no IPv6 support (natively or through transition 706 aids) the enterprise should consider deploying its own transition 707 (remote access) aid. 709 Such an aid may be either a tunnel broker [TBRK], ideally one that 710 supports operation through an IPv4 NAT, or a 6to4 relay [6TO4]. If 711 a 6to4 relay is offered, the site should be aware of security 712 issues with operating 6to4 relays [cite ref?]. 714 There is ongoing work on auto-transition and assisted tunneling 715 tools that may also be applicable as remote access aids [cite 716 refs?]. 718 8 Applicable Transition Mechanisms 720 This section will provide guidance for the use of specific 721 transition mechanisms below that can be used by the enterprise to 722 support the enterprise matrix scenarios (rows) in Section 3, and 723 within the context of the three scenarios discussed in this 724 document in Section 4, 5, and 6. Table xx below shows the 725 transition mechanisms recommended by the authors in each of the 726 respective scenarios. In some cases the enterprise network team 727 will have a choice and the decision will be based upon criteria 728 that is not within the scope of this document. One size will not 729 fit all for the enterprise for transition in most cases and the 730 transition mechanisms are tools to be used by the enterprise as 731 required to fulfill their strategy and business reasons for 732 transitioning to IPv6. The mechanisms depicted below the authors 733 selected based on their knowledge of these mechanisms have gained 734 acceptance in the market and have multiple implementations in 735 current network pilots or in those network pilot plans within 736 industry. 738 Basic Configured Tunnels: 740 6to4: 742 Tunnel Broker: 744 Teredo: 746 DSTM: 748 ISATAP: 750 NAT-PT: 752 ====================================================================== 753 |Application |Host 1 |Service |Host 2 |Application | Recommended 754 |----------- |Network|Provider|Network|---------- | Transition 755 | Host 1 OS | | | | Host 2 OS | Mechanism 756 =====================================+================================ 757 |IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6|Dual IP Networks 758 1 |---- or ----| or |Dual IP | or |---- or ----|and Hosts for 759 |IPv6 Dual|v6 Only| |v6 only|IPv6 Dual|IPv6 760 ====================================================================== 761 |IPv4 IPv4| | | |IPv4 IPv4|Dual IP Networks 762 2 |---- or ----|Dual IP|Dual IP |Dual IP|---- or ----|and Hosts for 763 |IPv4 Dual| | | |IPv4 Dual|IPv4 764 ====================================================================== 765 | IPv6 | | | | IPv6 |IPv6 Host Tunnel 766 3 | ---- | IPv4 |Dual IP |Dual IP| ---- |(Brokered atISP) 767 | Dual | | | | IPv6 | 768 ====================================================================== 769 | IPv6 | | | |IPv4 IPv4|Translation on 770 4 | ---- | IPv4 |Dual IP |Dual IP|---- or ----|local IPv6 771 | Dual | | | |IPv4 Dual|domain 772 ====================================================================== 773 | IPv6 | | | | IPv6 |IPv6 Host Tunnel 774 5 | ---- | IPv4 | IPv4 |Dual IP| ---- |(Brokered at 775 | Dual | | | | IPv6 |Net2) 776 ====================================================================== 777 |IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6|Site-to-Site 778 6 |---- or ----| or | IPv4 | or |---- or ----|Tunnel| 779 |IPv6 Dual|v6 only| |v6 only|IPv6 Dual|(Brokered?) 780 ====================================================================== 781 | IPv6 |Dual IP| IPv4, | | IPv4 |Translation on 782 7 | ---- | or | IPv6 or| IPv4 | ---- |local IPv6 783 | IPv6 |v6 only|Dual IP | | IPv4 |domain 784 ====================================================================== 785 | IPv6 |Dual IP| None - | | IPv4 |Translation for 786 8 | ---- | or | Local | IPv4 | ---- |local nets 787 | IPv6 |v6 only| Connect| | IPv4 | 788 ====================================================================== 789 | IPv4 | | | | IPv4 |4in6 Config 790 9 | ---- | IPv4 |v6 only | IPv4 | ---- |Tunnel 791 | IPv4 | | | | IPv4 | 792 ====================================================================== 793 | Dual | | | | IPv4 |DSTM for 794 10| ---- |Dual IP| v6 Only| IPv4 | ---- |v4 thru v6 795 | Dual | | | | IPv4 | 796 ====================================================================== 797 | Dual | | | | IPv4 |DSTM for 798 11| ---- |v6 only| v6 only| IPv4 | ---- |v4 thru v6 799 | Dual | | | | IPv4 | 800 ====================================================================== 801 | IPv6 | | | | IPv6 |Dual IP plus 802 12| ---- |Dual IP|v6 only |Dual IP| ---- | v6 only 803 | Dual | | | | Dual | 804 ====================================================================== 805 | IPv6 | | | | IPv6 | 806 13| ---- |v6 only|v6 only |v6 only| ---- |v6 only 807 | IPv6 | | | | IPv6 | 808 ====================================================================== 810 9 Security Considerations 812 WRITING: Lets do this after we get above writing done. 814 10 References 816 10.1 Normative References 818 [DNSV6] Durand, A., Ihren, J. and P. Savola, "Operational 819 Considerations and Issues with IPv6 DNS", Work in 820 Progress. 822 [CONF] Thomson, S., Narten, T., "IPv6 Stateless Autoconfiguration" 823 RFC 2462 December 1998. 825 [DHCPF] Droms, R., Bound, J., Volz, B., Lemon, T., et al. "Dynamic 826 Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 July 827 2003. 829 [DHCPL] Droms, R., "Stateless Dynamic Host Configuration Protocol 830 (DHCP) Service for IPv6" RFC 3756 April 2004. 832 [APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., Castro, E., 833 "Application Aspects of IPv6 Transition" Work in Progress. 835 [BSCN] Bound, J., (Ed) et al. "IPv6 Enterprise Network Scenarios" 836 Work in Pogress. 838 [6TO4] Carpenter, B., Moore, K., "Connection of IPv6 Domains via 839 IPv4 Clouds" RFC 3056 February 2001. 841 [TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 842 NATs" Work in Progress. 844 [BCNF] Nordmark, E., Gilligan, R., "Basic Transition Mechanisms 845 for IPv6 Hosts and Routers" Work in Progress from RFC 2893. 847 [DSTM] Bound, J., (Ed) et al. "Dual Stack Transition Mechanim" 848 Work in Progress. 850 [ISTP] Templin, F., et al "Intra-Site Automatic Tunnel 851 Addressing Protocol (ISATAP)". Work in Progress. 853 [6TUN] Conta, A., Deering, S., "Generic Packet Tunneling in 854 IPv6" RFC 2473 December 1998. 856 [TBRK] Durand, A., et al "IPv6 Tunnel Broker" 857 RFC 3053 January 2001. 859 [SEC1] Savola, P., Patel, C., "Security Considerations for 860 6to4. Work in Progress. 862 [ULA] Hinden, B., Haberman, B., "Unique Local IPv6 863 Addresses". Work in Progress. 865 [RENUM] Baker, F., Lear, E., Droms, R., "Procedures for Renumbering 866 an IPv6 Network without a Flag Day". Work in Progress. 868 [ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address 869 Allocations to Sites" RFC 3177 September 2001. 871 [NATPT] Tsirtsis, G., Srisuresh, P., "Network Address Translation - 872 Protocol Translation (NAT-PT)" RFC 2766 February 2000 874 [UMAN] Huitema, C.,. et al "Evaluation of IPv6 Transition Mechanisms 875 for Unmanaged Networks". Work in Progress. 877 [ISPA] Lind, M., et al "Scenarios and Analysis for Introducing IPv6 878 into ISP Networks". Work in Progress. 880 [3GPA] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks" 881 Work in Progress. 883 10.2 Non-Normative References 885 None at this time. 887 Document Acknowledgments 889 The Authors would like to acknowledge contributions from the 890 following: IETF v6ops Working Group members Pekka Savola. 892 Author's Address 894 Jim Bound 895 HP 896 110 Spitbrook Road 897 Nashua, NH 03062 898 USA 899 Phone: 603.305.3051 900 Email: jim.bound@hp.com 902 Yanick Pouffary 903 HP Competency Center 904 950, Route des Colles, BP027, 905 06901 Sophia Antipolis CEDEX 906 FRANCE 907 Phone: + 33492956285 908 Email: Yanick.pouffary@hp.com 910 Tim Chown 911 School of Electronics and Computer Science 912 University of Southampton 913 Southampton SO17 1BJ 914 United Kingdom 915 Email: tjc@ecs.soton.ac.uk 917 David Green 918 SRI International 919 333 Ravenswood Ave 920 Menlo Park, CA 94025-3493 921 USA 922 Phone: 732 532-6715 923 Email: david.green@sri.com 925 Jordi Palet Martinez 926 Consulintel 927 San Jose Artesano, 1 928 Madrid, SPAIN 929 Phone: +34 91 151 81 99 930 Fax: +34 91 151 81 98 931 Email: jordi.palet@consulintel.es 933 Steve Klynsma 934 The MITRE Corporation 935 7515 Colshire Drive 936 McLean, VA 22102-5708 937 USA 938 703-883-6469 939 Email: sklynsma@mitre.org 941 Appendix A - Campus Deployment Scenario with VLANs 943 To be completed in next drafts. 945 Appendix B - Crisis Management Network Scenarios 947 Introduction: 949 This appendix first describes different scenarios for the 950 introduction of IPv6 into a crisis management network for 951 emergency services, defense, or security forces that are currently 952 running IPv4 service. Then, the scenarios for introducing IPv6 are 953 analyzed and the relevance of already defined transition mechanisms 954 are evaluated. Known challenges are also identified. 956 When a crisis management enterprise deploys IPv6, its goal is to 957 provide IPv6 958 connectivity on it's institutional fixed networks and on the mobile 959 wireless 960 services that are deployed to a crisis area. The new IPv6 service must 961 be added to an already existing IPv4 service, the introduction of 962 IPv6 must not interrupt this IPv4 service, and the IPv6 services must 963 be interoperable with existing IPv4 services. 965 Crisis management enterprises accessing IPv4 service across mobile 966 ground 967 networks, airborne networks, and satellites will find different ways to 968 add 969 IPv6 to this service based on their network architecture, funding, 970 and institutional goals. This document discusses a small set of 971 scenarios representing the architectures for IPv6 expected to be 972 dominant 973 in crisis management networks during the next decade. It evaluates the 974 relevance of the existing transition mechanisms in the context of 975 these deployment scenarios, and points out the lack of essential 976 functionality in these methods to the ISP's operation of an IPv6 977 service. 979 The document is focused on services that include both IPv6 and IPv4 980 and does cover issues surrounding accessing IPv4 services across 981 IPv6-only 982 networks. It is outside the scope of this document to describe detailed 983 implementation plans for IPv6 in defense networks 985 Scenarios for IPv6 Deployment in Crisis Management Networks: 987 Scenario 1: Limited IPv6 Deployment Network..................... 989 Sparse IPv6 dual-stack deployment in an existing IPv4 network 990 infrastructure. 991 Enterprise with an existing IPv4 network wants to deploy a set of 992 particular 993 IPv6 "applications" and have some ability to interoperate with other 994 institutions that are using IPv6 services. The IPv6 deployment is 995 limited 996 to the minimum required to operate this set of applications. 998 Assumptions: IPv6 software/hardware components for the application are 999 available, and platforms for the application are IPv6 capable. 1001 Requirements: Do not disrupt IPv4 infrastructure. 1003 Scenario 2: Dual Stack Network 1005 Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts 1006 and network infrastructure. Enterprise with an existing 1007 IPv4 network wants to deploy IPv6 in conjunction with their IPv4 1008 network in order to take advantage of emerging IPv6 network-centric 1009 capabilities and to be interoperable with other agencies, international 1010 partners, and commercial enterprises that are deploying an IPv6 1011 architecture. 1013 Assumptions: The IPv4 network infrastructure used has an 1014 equivalent capability in IPv6. 1016 Requirements: Do not disrupt existing IPv4 network infrastructure 1017 with IPv6. IPv6 should be equivalent or "better" than the network 1018 infrastructure in IPv4. It may not be feasible to deploy IPv6 on all 1019 parts of 1020 the network immediately. Dual stacked defense enterprise network 1021 must be interoperable with both IPv4 and IPv6 networks and 1022 applications. 1024 Scenario 3: ..............................IPv6 Dominant Network 1026 Enterprise has some limited IPv4-capable/only nodes/applications 1027 needing to 1028 communicate over the IPv6 infrastructure. Crisis management enterprise 1029 re-structuring an existing network, decides to pursue aggressive IPv6 1030 transition as an enabler for network-centric services and wants to run 1031 some native IPv6-only networks to eliminate cost/complexity of 1032 supporting a 1033 dual stack. Some legacy IPv4 capable nodes/applications within the 1034 enterprise 1035 will have slow technical refresh/replacement path and will need to 1036 communicate 1037 over the IPv6 dominant infrastructure for years 1038 until they are replaced. The IPv6 dominant enterprise network will need 1039 to be 1040 interoperable with it's own legacy networks, commercial networks, and 1041 the 1042 legacy networks of similar organizations that will remain IPv4 dominant 1043 during a long transition period. Reserve units, contractors, other 1044 agencies, 1045 and international partners may need IPv4 service across this 1046 enterprise's 1047 IPv6 dominant backbone. 1049 Assumptions: Required IPv6 network infrastructure is available, or 1050 available 1051 over some defined timeline, supporting the aggressive transition plan. 1053 Requirements: 1055 Reduce operation and maintenance requirements and increase 1056 net-centricity through aggressive IPv6 transition. 1058 Interoperation and coexistence with legacy IPv4 networks and 1059 applications is 1060 required. 1062 Legacy IPv4 nodes/applications/networks will need to be able to operate 1063 across the 1064 IPv6 backbone and need to be able to interoperate with the IPv6-dominant 1065 network's nodes/applications. 1067 Description of a Generic Crisis Management Network 1069 A generic network topology for a crisis management reflects the various 1070 ways 1071 a crisis management network can connect customers through their network 1072 infrastructure. Because the institution's existing wired and fixed site 1073 wireless 1074 infrastructure can be destroyed or unavailable in a crisis, the crisis 1075 management network must be able to deploy it's own mobile wireless 1076 network 1077 or connect through external wired and wireless networks provided by 1078 ISPs or 1079 partner organizations. This infrastructure lets us divide the basic 1080 areas 1081 for IPv4/IPv6 interoperability into three main areas: 1082 the customer applications, the local network, and the network backbone. 1084 The basic components in a crisis management network are depicted in 1085 Figure 1. 1087 ------------ ---------- ---- Wired Connection 1088 | Network and| | | .... Wireless Connection 1089 | Service |--| Backbone | 1090 | Operation | | | 1091 ------------ ---------- 1092 / | --------------------- 1093 / : _|Connection to | 1094 / : |Commercial Internet | 1095 / : --------------------- Network 1096 Backbone 1097 -------------- 1098 /------|-------------|-------------------------------- 1099 ---------- / ---------- ---------- 1100 | Home |/ | Wireless | External |............. 1101 | Base | | Mobile | |Untrusted |+--------- : 1102 | Network | | Network | |Network | | : 1103 ---------- ---------- ---------- | : 1104 | : : | : Local 1105 Network 1107 -----:------------:--------------------------------------------------- 1108 | : : | : Customer 1109 Apps 1110 +--------+ +--------+ +--------+ | : 1111 | | | | | | | : 1112 |Customer| |Customer| |Customer|+----------- :.... 1113 | | | | | |.............. 1114 +--------+ +--------+ +--------+ 1116 Figure 1: Crisis Management Network Topology. 1118 Stages of IPv6 Deployment: 1120 The stages are derived from the generic description of scenarios 1121 for crisis management networks in Section 2. Combinations of 1122 different building blocks that constitute an crisis network 1123 environment lead to a number of scenarios from which the network 1124 engineers can choose. The scenarios most relevant to this document 1125 are those that maximize the network's ability to offer IPv6 to its 1126 customers in the most efficient and feasible way. The assumption in 1127 the first three stages the goal is to offer both IPv4 and IPv6 to 1128 the customer, and that in the distant future all IPv4 services will 1129 be eventually switched to IPv6. This document will cover 1130 engineering the first four stages. 1132 The four most probable stages are: 1134 o Stage 1 Limited Launch 1135 o Stage 2 Dual Stack Dominance 1136 o Stage 3 IPv6 Dominance 1137 o Stage 4 IPv6 Transition Complete 1139 Generally, a crisis management network is able to entirely upgrade 1140 a current IPv4 network to provide IPv6 services via a dual-stack 1141 network in Stage 2 and then slowly progress to stages 3 and 4 as 1142 indicted in Figure 2. During stage 2, When most applications are 1143 IPv6 dominant, operational and maintenance costs can be reduced on 1144 some networks by moving to stage 3 and running backbone networks 1145 entirely on IPv6 while adding IPv4 backwards compatibility via v4 1146 in v6 tunneling or translation mechanisms to the existing 1147 configuration from stage 2. When designing a new network, if a new 1148 IPv6-only service is required, it can be implemented at a lower 1149 cost jumping directly to stage 3/4 if there are only limited/no 1150 legacy concerns. 1152 Tunnels Dominant dual Full dual Stack 1153 IPv4-only --> or limited --> stacking with --> everywhere, mostly --> 1154 V6 1155 dual stacks transition v6 apps, some 1156 Only 1157 Limited v6 mechanisms in v6 only nets with 1158 Applications backbone transition mechanisms 1159 pushed to legacy v4 1160 nets 1162 Figure 2: Transition Path. 1164 Stage 1 Scenario: Limited Launch 1166 The first stage begins with an IPv4-only network and IPv4 1167 customers. This is the most common case today and the natural 1168 starting point for the introduction of IPv6. During this stage the 1169 enterprise begins to connect individual IPv6 applications run on 1170 dual stacked hosts through host based tunneling using Tunnel 1171 Broker, ISATAP, Teredo. Some early adopter networks are created for 1172 pilot studies and networked together through configured tunnels and 1173 6to4. 1175 The immediate first step consists of obtaining a prefix allocation 1176 typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC, 1177 ARIN, LACNIC, RIPE, ...) according to allocation procedures. 1179 The crisis management enterprise will also need to establish IPv6 1180 connectivity between its home base networks and mobile wireless 1181 networks over it's backbone and negotiate IPv6 service with its 1182 service providers and with peer organizations; it is of utmost 1183 importance to require IPv6 capability or an upgrade plan when 1184 negotiating purchases of network applications and infrastructure. 1185 In the short term, network connections, especially legacy wireless 1186 networks, that cannot provide IPv6 services can provide IPv6 1187 services through the use of tunnels. However, the longer-term goal 1188 must be requiring and obtaining IPv6 native connectivity from the 1189 transit networks, because otherwise the quality of IPv6 1190 connectivity will likely be poor and the transition to stage 2 will 1191 be delayed. 1193 Stage 2 Scenario: Dual Stack Dominance 1195 Stage 2 occurs when most applications, local networks, and network 1196 backbones become dual-stacked so that native IPv6 connections are 1197 enabled. At this point there is a mix of IPv4 and IPv6 applications 1198 and services in use across the enterprise. The enterprise may be 1199 made IPv6-capable through either software upgrades, hardware 1200 upgrades, or a combination of both. Generally IPv6 is added during 1201 normal technical refresh as the enterprise buys new equipment that 1202 is IPv6 ready. 1204 Specialty legacy applications and wireless/satellite networks may 1205 be especially slow to transition to IPv6 capability due to upgrade 1206 costs so plans must be made for backwards compatibility for these 1207 systems. Since some new IPv6 services cannot be provided through 1208 IPv4, and some legacy network connections may not yet be upgraded, 1209 tunneling mechanisms have to be provided on the backbone to provide 1210 IPv6 connectivity through to customer IPv6 applications still 1211 relying on legacy IPv4-only networks. The tunnels may provide 1212 host-based tunneling for individual customers or site-to-site 1213 tunnels to connect small IPv6 domains through IPv4 only networks. 1214 If any new applications are IPv6-only rather than dual-stacked, and 1215 need to interact with IPv4-only legacy applications, translators 1216 will be used as a transition mechanism of last resort during this 1217 stage. 1219 Stage 3 Scenario: IPv6 Dominance 1221 Stage 3 occurs when the majority of network services are being 1222 provided by IPv6 so that most network traffic is dominantly IPv6 1223 and the net-centric benefits of IPv6 end-to-end communications, 1224 IPSEC based security, QOS, mobility, and autoconfiguration are 1225 realized. During this stage, some networks and applications will 1226 become native IPv6-only and will have to rely on transition 1227 mechanism for backwards compatibility with IPv4. The switch to 1228 native IPv6 may be pursued to lower the operations and maintenance 1229 cost of network operations and lower the performance overhead 1230 associated with running two stacks on networked systems. During 1231 this stage, IPv4 in IPv6 tunnels are used to provide IPv4 services 1232 to the remaining customers needing these services across IPv6 only 1233 backbones. At this stage requirements for IPv4 compatibility can be 1234 pushed out of the network backbone and to IPv4 end-user networks. 1235 DSTM, with or without tunnel brokers, can be used to provide host- 1236 based tunnels for IPv4 service on local networks that only support 1237 IPv6. Remaining IPv4 dominant networks requiring IPv4 service 1238 across IPv6-only backbones will have to connect through site-to- 1239 site tunnels. Since many new applications are IPv6-only rather than 1240 dual-stacked, legacy IPv4 applications may require translators for 1241 interoperability. 1243 Stage 4 Scenario: IPv6 Only In the future, if IPv6 becomes the only 1244 service required, IPv4 service can be dropped. This transition may 1245 be hastened by the desire to save operational and maintenance costs 1246 by dropping IPv4 services and only supporting one IP family. 1248 Security Concerns 1250 Adding security to IPv6 services requires developing new customer 1251 applications for IPSEC, new firewalls, guards, VPN/encrypters, and 1252 end-user security such as host-based firewalls and virus checkers 1253 for IPv6 attacks. Police, homeland defense, and military crisis 1254 management networks require especially high levels of security and 1255 should begin creation and implementation of their specialized 1256 security architectures as soon as they begin planning for IPv6 1257 transition. New IPv6 features such as MIPv6, stateless address 1258 auto-assignment, and ubiquitous end-user IPSEC will likely not be 1259 compatible with current information-assurance tools that are simply 1260 ported from IPv4 to a minimal IPv6 capability. A complete new 1261 security policy, architecture, and tools will most likely be 1262 required to realize the true net-centric benefits of IPv6 in crisis 1263 networks requiring high security. 1265 Intellectual Property and Copyright Statements 1267 Intellectual Property Statement 1269 The IETF takes no position regarding the validity or scope of any 1270 Intellectual Property Rights or other rights that might be claimed 1271 to pertain to the implementation or use of the technology described 1272 in this document or the extent to which any license under such 1273 rights might or might not be available; nor does it represent that 1274 it has made any independent effort to identify any such rights. 1275 Information on the procedures with respect to rights in RFC 1276 documents can be found in BCP 78 and BCP 79. 1278 Copies of IPR disclosures made to the IETF Secretariat and any 1279 assurances of licenses to be made available, or the result of an 1280 attempt made to obtain a general license or permission for the use 1281 of such proprietary rights by implementers or users of this 1282 specification can be obtained from the IETF on-line IPR repository 1283 at http://www.ietf.org/ipr. 1285 The IETF invites any interested party to bring to its attention any 1286 copyrights, patents or patent applications, or other proprietary 1287 rights that may cover technology that may be required to implement 1288 this standard. Please address the information to the IETF at 1289 ietf-ipr@ietf.org. 1291 Disclaimer of Validity 1293 This document and the information contained herein are provided on 1294 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1295 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1296 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1297 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1298 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1299 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1300 PARTICULAR PURPOSE. 1302 Copyright Statement 1304 Copyright (C) The Internet Society (2004). This document is 1305 subject to the rights, licenses and restrictions contained in BCP 1306 78, and except as set forth therein, the authors retain all their 1307 rights. 1309 Acknowledgment 1311 Funding for the RFC Editor function is currently provided by the 1312 Internet Society.