idnits 2.17.1 draft-ietf-v6ops-ent-scenarios-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 756. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 762. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 778), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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 18 longer pages, the longest (page 15) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 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 -- 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) -- 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' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Operations Working Group 2 Internet Draft Jim Bound (Editor) 3 Document: draft-ietf-v6ops-ent-scenarios-05.txt Hewlett Packard 4 Obsoletes: draft-ietf-v6ops-ent-scenarios-04.txt 5 Expires: January 2005 7 IPv6 Enterprise Network Scenarios 9 11 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been 14 disclosed, and any of which I become aware will be disclosed, in 15 accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as "work 26 in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 10, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document describes the scenarios for IPv6 deployment within 43 enterprise networks. It defines a small set of basic enterprise 44 scenarios and includes pertinent questions to allow enterprise 45 administrators to further refine their deployment scenarios. 46 Enterprise deployment requirements are discussed in terms of 47 coexistence with IPv4 nodes, networks and applications, and in 48 terms of basic network infrastructure requirements for IPv6 49 deployment. The scenarios and requirements described in this 50 document will be the basis for further analysis to determine what 51 coexistence techniques and mechanisms are needed for enterprise 52 IPv6 deployment. The results of that analysis will be published in 53 a separate document. 55 Table of Contents: 57 1. Introduction................................................3 58 2. Terminology.................................................5 59 3. Base Scenarios..............................................6 60 3.1 Base Scenarios Defined.....................................7 61 3.2 Scenarios Network Infrastructure Components................8 62 3.3 Specific Scenario Examples................................10 63 3.4 Applicability Statement...................................12 64 4. Network Infrastructure Component Requirements..............12 65 4.1 DNS.......................................................12 66 4.2 Routing...................................................13 67 4.3 Configuration of Hosts....................................13 68 4.4 Security..................................................13 69 4.5 Applications..............................................13 70 4.6 Network Management........................................14 71 4.7 Address Planning..........................................14 72 4.8 Multicast..................................................14 73 4.9 Multihoming................................................14 74 5. Security Considerations....................................14 75 6. References.................................................14 76 6.1 Normative References......................................15 77 6.2 Non-Normative References..................................15 78 Document Acknowledgments.......................................15 79 Author's Address...............................................16 80 Intellectual Property and Copyright Statements.................17 81 1. Introduction 83 This document describes the scenarios for IPv6 deployment within 84 enterprise networks. It defines a small set of basic enterprise 85 scenarios and includes pertinent questions to allow enterprise 86 administrators to further refine their deployment scenarios. 87 Enterprise deployment requirements are discussed in terms of 88 coexistence with IPv4 nodes, networks and applications, and in 89 terms of basic network infrastructure requirements for IPv6 90 deployment. The scenarios and requirements described in this 91 document will be the basis for further analysis to determine what 92 coexistence techniques and mechanisms are needed for enterprise 93 IPv6 deployment. The results of that analysis will be published in 94 a separate document. 96 The audience for this document is the enterprise network team 97 considering deployment of IPv6. The document will be useful for 98 enterprise teams that will have to determine the IPv6 transition 99 strategy for their enterprise. It is expected those teams include 100 members from management, network operations, and engineering. The 101 scenarios presented provide an example set of cases the enterprise 102 can use to build an IPv6 network scenario. 104 To frame the discussion, the document will describe a set of 105 scenarios and network infrastructure for each scenario. It is 106 impossible to define every possible enterprise scenario that will 107 apply to IPv6 adoption and transition. 109 Each enterprise will select the transition that best supports their 110 business requirements. Any attempt to define a default or one- 111 size-fits-all transition scenario, will simply not work. This 112 document does not try to depict the drivers for adoption of IPv6 by 113 an enterprise. 115 While it is difficult to quantify all the scenarios for an 116 enterprise network team to plan for IPv6, it is possible to depict 117 a set of abstract scenarios that will assist with planning. The 118 document presents three base scenarios as a general use case to be 119 used as a model as input for the enterprise to define specific 120 scenarios. 122 The first scenario assumes the enterprise decides to deploy IPv6 in 123 conjunction with IPv4. The second scenario assumes the enterprise 124 decides to deploy IPv6 because of a specific set of applications 125 the enterprise wants to use over an IPv6 network. The third 126 scenario assumes an enterprise is building a new network or re- 127 structuring an existing network and decides to deploy IPv6 as the 128 predominant protocol within the enterprise coexisting with IPv4. 129 The document then briefly reviews a set of network infrastructure 130 components that must be analyzed, which are common to most 131 enterprises. 133 The document then provides three specific scenario examples using 134 the network infrastructure components to depict the requirements. 135 These are common enterprise deployment cases to depict the 136 challenges for the enterprise to transition a network to IPv6. 138 The document then discusses the issues of supporting legacy 139 functions on the network, while the transition is in process, and 140 the network infrastructure components required to be analyzed by 141 the enterprise. The interoperation with legacy functions within 142 the enterprise will be required for all transition except possibly 143 by a new network that will be IPv6 from inception. The network 144 infrastructure components will depict functions in their networks 145 that require consideration for IPv6 deployment and transition. 147 Using the scenarios, network infrastructure components, and 148 examples in the document an enterprise can define its specific 149 scenario requirements. Understanding the legacy functions and 150 network infrastructure components required, the enterprise can 151 determine the network operations required to deploy IPv6. The tools 152 and mechanisms to support IPv6 deployment operations will require 153 enterprise analysis. The analysis to determine the tools and 154 mechanisms to support the scenarios will be presented in subsequent 155 document(s). 157 2. Terminology 159 Enterprise Network - A network that has multiple internal links, 160 one or more router connections, to one or 161 more Providers and is actively managed by a 162 network operations entity. 164 Provider - An entity that provides services and 165 connectivity to the Internet or 166 other private external networks for the 167 enterprise network. 169 IPv6 Capable - A node or network capable of supporting both 170 IPv6 and IPv4. 172 IPv4 only - A node or network capable of supporting only 173 IPv4. 175 IPv6 only - A node or network capable of supporting only 176 IPv6. This does not imply an IPv6 only 177 stack, in this document. 179 3. Base Scenarios 181 Three base scenarios are defined to capture the essential 182 abstraction set for the enterprise. Each scenario has assumptions 183 and requirements. This is not an exhaustive set of scenarios, but a 184 base set of general cases. 186 Below we use the term network infrastructure to mean the software, 187 network operations and configuration, and the methods used to 188 operate a network in an enterprise. 190 At this time it is assumed for the base scenarios that any IPv6 191 node is IPv6 capable. 193 3.1 Base Scenarios Defined 195 Scenario 1: Wide-scale/total dual-stack deployment of IPv4 196 and IPv6 capable hosts and network infrastructure. 197 Enterprise with an existing IPv4 network wants to 198 deploy IPv6 in conjunction with their IPv4 network. 200 Assumptions: The IPv4 network infrastructure used has an 201 equivalent capability in IPv6. 203 Requirements: Do not disrupt existing IPv4 network 204 infrastructure assumptions with IPv6. IPv6 205 should be equivalent or "better" than the 206 network infrastructure in IPv4, however, it 207 is understood that IPv6 is not required to 208 solve current network infrastructure problems, 209 not solved by IPv4. It may also not be feasible 210 to deploy IPv6 on all parts of the network 211 immediately. 213 Scenario 2: Sparse IPv6 dual-stack deployment in IPv4 network 214 infrastructure. Enterprise with an existing IPv4 215 network wants to deploy a set of particular IPv6 216 "applications" (application is voluntarily loosely 217 defined here, e.g. peer to peer). The IPv6 218 deployment is limited to the minimum required to 219 operate this set of applications. 221 Assumptions: IPv6 software/hardware components for the 222 application are available, and platforms for the 223 application are IPv6 capable. 225 Requirements: Do not disrupt IPv4 infrastructure. 227 Scenario 3: IPv6-only network infrastructure with some 228 IPv4-capable nodes/applications needing to 229 communicate over the IPv6 infrastructure. 230 Enterprise deploying a new network or 231 re-structuring an existing network, decides IPv6 232 is the basis for most network communication. 233 Some IPv4 capable nodes/applications will need 234 to communicate over that infrastructure. 236 Assumptions: Required IPv6 network infrastructure is available, 237 or available over some defined timeline, 238 supporting the enterprise plan. 240 Requirements: Interoperation and Coexistence with IPv4 network 241 network infrastructure and applications are 242 required for communications. 244 3.2 Scenarios Network Infrastructure Components 246 This section defines the network infrastructure that exists for the 247 above enterprise scenarios. This is not an exhaustive list, but a 248 base list that can be expanded by the enterprise for specific 249 deployment scenarios. The network infrastructure components are 250 presented as functions that the enterprise must analyze as part of 251 defining their specific scenario. The analysis of these functions 252 will identify actions that are required to deploy IPv6. 254 Network Infrastructure Component 1 255 Enterprise Provider Requirements 256 - Is external connectivity required? 257 - One site vs. multiple sites and are they within 258 different geographies? 259 - Leased lines or VPNs? 260 - If multiple sites, how is the traffic exchanged 261 securely? 262 - How many global IPv4 addresses are available to the 263 enterprise? 264 - What is the IPv6 address assignment plan available 265 from the provider? 266 - What prefix delegation is required by the Enterprise? 267 - Will the enterprise be multihomed? 268 - What multihoming techniques are available from the 269 provider? 270 - Will clients within the enterprise be multihomed? 271 - Does the provider offer any IPv6 services? 272 - What site external IPv6 routing protocols are required? 273 - Is there an external data-center to the enterprise, 274 such as servers located at the Provider? 275 - Is IPv6 available using the same access links as IPv4, 276 or different ones? 278 Network Infrastructure Component 2 279 Enterprise Application Requirements 280 - List of applications in use? 281 - Which applications must be moved to support IPv6 first? 282 - Can the application be upgraded to IPv6? 283 - Will the application have to support both IPv4 and IPv6? 284 - Do the enterprise platforms support both IPv4 and IPv6? 285 - Do the applications have issues with NAT v4-v4 and 286 NAT v4-v6? 287 - Do the applications need globally routable IP addresses? 288 - Do the applications care about dependency between IPv4 289 and IPv6 addresses? 290 - Are applications run only on the internal enterprise 291 network? 293 Network Infrastructure Component 3 294 Enterprise IT Department Requirements 295 - Who "owns"/"operates" the network: in house, or 296 outsourced? 297 - Is working remotely (e.g., through VPNs) supported? 298 - Is inter-site communications required? 299 - Is network mobility used or required for IPv6? 300 - What are the requirements of the IPv6 address plan? 301 - Is there a detailed asset management database, including 302 hosts, IP/MAC addresses, etc.? 303 - What is the enterprise' approach to numbering 304 geographically separate sites which have their own 305 Service Providers? 306 - What will be the internal IPv6 address assignment 307 procedure? 308 - What site internal IPv6 routing protocols are required? 309 - What will be the IPv6 Network Management 310 policy/procedure? 311 - What will be the IPv6 QOS policy/procedure? 312 - What will be the IPv6 Security policy/procedure? 313 - What is the IPv6 training plan to educate the enterprise? 314 - What network operations software will be impacted by IPv6? 315 - DNS 316 - Management (SNMP & ad-hoc tools) 317 - Enterprise Network Servers Applications 318 - Mail Servers 319 - High Availability Software for Nodes 320 - Directory Services 321 - Are all these software functions upgradeable to IPv6? 322 - If not upgradeable, then what are the workarounds? 323 - Do any of the software functions store, display, or 324 allow input of IP addresses? 325 - Other services (e.g. NTP, etc.........) 326 - What network hardware will be impacted by IPv6? 327 - Routers/switches 328 - Printers/Faxes 329 - Firewalls 330 - Intrusion Detection 331 - Load balancers 332 - VPN Points of Entry/Exit 333 - Security Servers and Services 334 - Network Interconnect for Platforms 335 - Intelligent Network Interface Cards 336 - Network Storage Devices 337 - Are all these hardware functions upgradeable to IPv6? 338 - If not, what are the workarounds? 339 - Do any of the hardware functions store, display, or 340 allow input of IP addresses? 341 - Are the nodes moving within the enterprise network? 342 - Are the nodes moving outside and inside the enterprise 343 network? 345 Network Infrastructure Component 4 346 Enterprise Network Management System 347 - Performance Management Required? 348 - Network Management Applications Required? 349 - Configuration Management Required? 350 - Policy Management and Enforcement Required? 351 - Security Management Required? 352 - Management of Transition Tools and Mechanisms? 353 - What new considerations does IPv6 create for Network 354 Management? 356 Network Infrastructure Component 5 357 Enterprise Network Interoperation and Coexistence 358 - What platforms are required to be IPv6 capable? 359 - What network ingress and egress points to the site 360 are required to be IPv6 capable? 361 - What transition mechanisms are needed to support 362 IPv6 network operations? 363 - What policy/procedures are required to support the 364 transition to IPv6? 365 - What policy/procedures are required to support 366 interoperation with legacy nodes and applications? 368 3.3 Specific Scenario Examples 370 This section presents a set of base scenario examples and is not an 371 exhaustive list of examples. These examples were selected to 372 provide further clarity for base scenarios within an enterprise of 373 a less abstract nature. The example networks may use the scenarios 374 depicted in 3.1 and the infrastructure components in 3.2, but there 375 is no direct implications specifically within these example 376 networks. Section 3.1, 3.2, and 3.3 should be used in unison for 377 enterprise IPv6 deployment planning and analysis. 379 Example Network A: 381 A distributed network across a number of geographically 382 separated campuses. 384 - External network operation. 385 - External connectivity required. 386 - Multiple sites connected by leased lines. 387 - Provider independent IPv4 addresses. 388 - ISP does not offer IPv6 service. 389 - Private Leased Lines no Service Provider Used 391 Applications run by the enterprise: 393 - Internal Web/Mail. 394 - File servers. 395 - Java applications. 396 - Collaborative development tools. 397 - Enterprise Resource Applications. 398 - Multimedia Applications. 399 - Financial Enterprise Applications. 400 - Data Warehousing Applications. 402 Internal network operation: 404 - In house operation of the network. 405 - DHCP (v4) is used for all desktops, servers use 406 static address configuration. 407 - The DHCP server updates naming records for dynamic 408 desktops uses dynamic DNS. 409 - A web based tool is used to enter name to address 410 mappings for statically addressed servers. 411 - Network management is done using SNMP. 412 - All routers and switches are upgradeable to IPv6. 413 - Existing firewalls can be upgraded to support IPv6 414 rules. 415 - Load balancers do not support IPv6, upgrade path 416 unclear. 417 - Peer-2-Peer Application and Security supported. 418 - IPv4 Private address space is used within the 419 enterprise. 421 Example Network B: 423 A bank running a large network supporting online 424 transaction processing (OLTP) across a distributed 425 multi-sited network, with access to a central database 426 on an external network from the OLTP network. 428 - External connectivity not required. 429 - Multiple sites connected by VPN. 430 - Multiple sites connected by Native IP protocol. 431 - Private address space used with NAT. 432 - Connections to private exchanges. 434 Applications in the enterprise: 435 - ATM transaction application. 436 - ATM management application. 437 - Financial Software and Database. 438 - Part of the workforce is mobile and requires 439 access to the enterprise from outside networks. 441 Internal Network Operation: 442 - Existing firewalls can be upgraded to support 443 IPv6 rules. 444 - Load balancers do not support IPv6, upgrade 445 path unclear. 446 - Identifying and managing each node's IP address. 448 Example Network C: 450 A Security Defense, Emergency, or other Mission 451 Critical network operation: 453 - External network required at secure specific points. 454 - Network is its own Internet. 455 - Network must be able to absorb ad-hoc creation of 456 sub-networks. 457 - Entire parts of the network are completely mobile. 458 - All nodes on the network can be mobile 459 (including routers) 460 - Network high-availability is mandatory. 461 - Network must be able to be managed from ad-hoc 462 location. 463 - All nodes must be able to be configured from stateless 464 mode. 466 Applications run by the Enterprise: 468 - Multimedia streaming of audio, video, and data for 469 all nodes. 470 - Data computation and analysis on stored and created 471 data. 473 - Transfer of data coordinate points to sensor devices. 474 - Data and Intelligence gathering applications from all 475 nodes. 477 Internal Network Operations: 478 - All packets must be secured end-2-end with encryption. 479 - Intrusion Detection exists on all network entry points. 480 - Network must be able to bolt on to the Internet to share 481 bandwidth as required from Providers. 482 - VPNs can be used but NAT can never be used. 483 - Nodes must be able to access IPv4 legacy applications 484 over IPv6 network. 486 3.4 Applicability Statement 488 The specific network scenarios selected are chosen to depict a base 489 set of examples, and to support further analysis of enterprise 490 networks. This is not a complete set of network scenarios. 491 Regarding Example Network C, though this is a verifiable use case, 492 at this time the scenario defines an early adopter of enterprise 493 networks transitioning to IPv6 as a predominant protocol strategy 494 (e.g. IPv6 Routing, Applications, Security, and Operations), 495 viewing IPv4 as legacy operations immediately in the transition 496 strategy, and at this time may not be representative of many 497 initial enterprise IPv6 deployments. Each enterprise planning team 498 will need to make that determination as IPv6 deployment evolves. 500 4. Network Infrastructure Component Requirements 502 The enterprise will need to determine what network infrastructure 503 components require enhancements or to be added for deployment of 504 IPv6. This infrastructure will need to be analyzed and understood 505 as a critical resource to manage. The list in this section is not 506 exhaustive but are the essential network infrastructure components 507 to consider for the enterprise before they begin to define more 508 fine tuned requirements such as QOS, PKI, or Bandwidth requirements 509 for IPv6 as examples. The components are only identified here and 510 the details of the components will be discussed in the analysis 511 document for enterprise scenarios. Where there are references at 512 this time for a component they are provided. 514 4.1 DNS 516 DNS will now have to support both IPv4 and IPv6 DNS records and the 517 enterprise will need to determine how the DNS is to be managed and 518 accessed, and secured. The range of DNS operational issues are out 519 of scope for this work. Users need to consider all current DNS 520 IPv4 operations and determine if those operations are supported for 521 IPv6. However, DNS resolution and transport solutions for both IP 522 protocols are influenced by the chosen IPv6 deployment scenario. 523 Users need to consider all current DNS IPv4 operations and 524 determine if those operations are supported for IPv6 [DNSV6]. 526 4.2 Routing 528 Interior and Exterior routing will be required to support both IPv4 529 and IPv6 routing protocols, and the coexistence of IPv4 and IPv6 530 over the enterprise network. The enterprise will need to define 531 the IPv6 routing topology, any ingress and egress points to 532 provider networks, and transition mechanisms they wish to use for 533 IPv6 adoption. The enterprise will also need to determine what IPv6 534 transition mechanisms are supported by their upstream providers. 536 4.3 Configuration of Hosts 538 IPv6 introduces the concept of stateless autoconfiguration in 539 addition to stateful autoconfiguration, for the configuration of 540 hosts within the enterprise. The enterprise will have to determine 541 the best method of host configuration, for their network. The 542 enterprise will need to determine if they are to use stateless or 543 stateful autoconfiguration, and how autoconfiguration is to operate 544 for DNS updates. The enterprise will need to determine how prefix 545 delegation is done from their upstream provider and how those 546 prefixes are cascaded down to the enterprise IPv6 network. The 547 policy for DNS or choice of autoconfiguration is out of scope for 548 this document. [CONF, DHCPF, DHCPL] 550 4.4 Security 552 Current existing mechanisms used for IPv4 to provide security need 553 to be supported for IPv6 within the enterprise. IPv6 should create 554 no new security concerns for IPv4. The entire security 555 infrastructure currently used in the enterprise needs to be 556 analyzed against IPv6 deployment effect and determine what is 557 supported in IPv6. Users should review other security IPv6 network 558 infrastructure work in the IETF and within the industry on going at 559 this time. Users will have to work with their platform and 560 software providers to determine what IPv6 security network 561 infrastructure components are supported. The security filters and 562 firewall requirements for IPv6 need to be determined by the 563 enterprise. The policy choice of users for security is out of scope 564 for this document. 566 4.5 Applications 568 Existing applications will need to be ported or provide proxies to 569 support both IPv4 and IPv6 [APPS]. 571 4.6 Network Management 573 The addition of IPv6 network infrastructure components will need to 574 be managed by the enterprise network operations center. Users will 575 need to work with their network management platform providers to 576 determine what for IPv6 is supported during their planning for IPv6 577 adoption, and what tools are available in the market to monitor the 578 network. Network management will not need to support both IPv4 and 579 IPv6 and view nodes as dual stacks. 581 4.7 Address Planning 583 The address space within the enterprise will need to be defined and 584 coordinated with the routing topology of the enterprise network. 585 It is also important to identify the pool of IPv4 address space 586 available to the enterprise to assist with IPv6 transition methods. 588 4.8 Multicast 590 Enterprises utilizing IPv4 Multicast services will need to consider 591 how these services may be implemented operationally in an IPv6- 592 enabled environment. 594 4.9 Multihoming 596 At this time, current IPv6 allocation policies are mandating the 597 allocation of IPv6 address space from the upstream provider. If an 598 enterprise is multihomed, the enterprise will have to determine how 599 they wish to support multihoming. This also is an area of study 600 within the IETF and work in progress. 602 5. Security Considerations 604 This document lists scenarios for the deployment of IPv6 in 605 enterprise networks, and there are no security considerations 606 associated with making such a list. 608 There will be security considerations for the deployment of IPv6 in 609 each of these scenarios, but they will be addressed in the document 610 that includes the analysis of each scenario. 612 6. References 613 6.1 Normative References 615 [DNSV6] Durand, A., Ihren, J. and P. Savola, "Operational 616 Considerations and Issues with IPv6 DNS", Work in 617 Progress. 619 [CONF] Thomson, S., Narten, T., "IPv6 Stateless Autoconfiguration" 620 RFC 2462 December 1998. 622 [DHCPF] Droms, R., Bound, J., Volz, B., Lemon, T., et al. "Dynamic 623 Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 July 624 2003. 626 [DHCPL] Droms, R., "Stateless Dynamic Host Configuration Protocol 627 (DHCP) Service for IPv6" RFC 3756 April 2004. 629 [APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., Castro, E., 630 "Application Aspects of IPv6 Transition" Work in Progress. 632 6.2 Non-Normative References 634 None at this time. 636 Document Acknowledgments 638 The Authors would like to acknowledge contributions from the 639 following: IETF v6ops Working Group, Alan Beard, Brian Carpenter, 640 Alain Durand, Bob Hinden, and Pekka Savola. 642 Author's Address 644 Yanick Pouffary (Chair of Design Team) 645 HP Competency Center 646 950, Route des Colles, BP027, 647 06901 Sophia Antipolis CEDEX 648 FRANCE 649 Phone: + 33492956285 650 Email: Yanick.pouffary@hp.com 652 Jim Bound (Editor) 653 Hewlett Packard 654 110 Spitbrook Road 655 Nashua, NH 03062 656 USA 657 Phone: 603.884.0062 658 Email: jim.bound@hp.co 660 Marc Blanchet 661 Viagenie inc. 662 2875 boul. Laurier, bur. 300 663 Ste-Foy, Quebec, Canada, G1V 2M2 664 EMail: Marc.Blanchet@viagenie.qc.ca 666 Tony Hain 667 Cisco Systems 668 500 108th Ave. N.E. Suite 400 669 Bellevue, Wa. 98004 670 Email: alh-ietf@tndh.net 672 Paul Gilbert 673 Cisco Systems 674 1 Penn Plaza, 5th floor, 675 NY, NY 10119 676 USA 677 Phone: 212.714.4334 678 Email: pgilbert@cisco.com 680 Margaret Wasserman 681 ThinkMagic 682 One Broadway 683 Cambridge, MA 02142 684 (617) 758-4177 685 margaret@thingmagic.com 687 Jason Goldschmidt 688 Sun Microsystems 689 M/S UMPK17-103 690 17 Network Circle 691 Menlo Park, CA 94025 692 USA 693 Phone: (650)-786-3502 694 Fax: (650)-786-8250 695 Email:jason.goldschmidt@sun.com 697 Aldrin Isaac 698 Bloomberg L.P. 699 499 Park Avenue 700 New York, NY 10022 701 USA 702 Phone: 212.940.1812 703 Email: aisaac@bloomberg.com 705 Tim Chown 706 School of Electronics and Computer Science 707 University of Southampton 708 Southampton SO17 1BJ 709 United Kingdom 710 Email: tjc@ecs.soton.ac.uk 712 Jordi Palet Martinez 713 Consulintel 714 San Jose Artesano, 1 715 Madrid, SPAIN 716 Phone: +34 91 151 81 99 717 Fax: +34 91 151 81 98 718 Email: jordi.palet@consulintel.es 720 Fred Templin 721 Nokia 722 313 Fairchild Drive 723 Mountain View, CA 94043 724 USA 725 Phone: 650.625.2331 726 Email: ftemplin@iprg.nokia.com 728 Roy Brabson 729 IBM 730 PO BOX 12195 731 3039 Cornwallis Road 732 Research Triangle Park, NC 27709 733 USA 734 Phone: +1 919 254 7332 735 Email: rbrabson@us.ibm.com 736 fi 738 Intellectual Property and Copyright Statements 740 Intellectual Property Statement 742 The IETF takes no position regarding the validity or scope of any 743 Intellectual Property Rights or other rights that might be claimed to 744 pertain to the implementation or use of the technology described in 745 this document or the extent to which any license under such rights 746 might or might not be available; nor does it represent that it has 747 made any independent effort to identify any such rights. Information 748 on the procedures with respect to rights in RFC documents can be 749 found in BCP 78 and BCP 79. 751 Copies of IPR disclosures made to the IETF Secretariat and any 752 assurances of licenses to be made available, or the result of an 753 attempt made to obtain a general license or permission for the use of 754 such proprietary rights by implementers or users of this 755 specification can be obtained from the IETF on-line IPR repository at 756 http://www.ietf.org/ipr. 758 The IETF invites any interested party to bring to its attention any 759 copyrights, patents or patent applications, or other proprietary 760 rights that may cover technology that may be required to implement 761 this standard. Please address the information to the IETF at 762 ietf-ipr@ietf.org. 764 Disclaimer of Validity 766 This document and the information contained herein are provided on an 767 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 768 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 769 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 770 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 771 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 772 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 774 Copyright Statement 776 Copyright (C) The Internet Society (2004). This document is subject 777 to the rights, licenses and restrictions contained in BCP 78, and 778 except as set forth therein, the authors retain all their rights. 780 Acknowledgment 782 Funding for the RFC Editor function is currently provided by the 783 Internet Society.