idnits 2.17.1 draft-ietf-v6ops-entnet-scenarios-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 16) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 53 instances of too long lines in the document, the longest one being 47 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 459 has weird spacing: '...v6 node wants...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7740 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2462' on line 534 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6ops Working Group Enterprise Network Scenarios Design Team 4 INTERNET-DRAFT: draft-ietf-v6ops-entnet-scenarios-00.txt 5 OBSOLETES : draft-pouffary-v6ops-ent-v6net-03.txt 7 Yanick Pouffary (Chair) 8 Jim Bound (Editor) 9 Enterprise Networks Scenarios Design Team 10 See Acknowledgements Section 12 February 2003 14 IPv6 Enterprise Networks Scenarios 16 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Abstract 41 IPv6 will be deployed in Enterprise networks. This scenario has 42 requirements for the adoption of IPv6. This document will focus upon 43 and define: a set of technology scenarios that shall exist for the 44 enterprise network, the set of transition variables, transition 45 methods, and tools required by different scenarios. The document 46 using these definitions will define the points of transition for an 47 Enterprise network. 49 Table of Contents: 51 1. Introduction.................................................4 52 2. Requirements.................................................5 53 3. Terminology..................................................6 54 4. Enterprise Network Assumptions...............................7 55 5. Enterprise Network Scenarios Overview........................9 56 6. Enterprise Points of Transition Methods.....................11 57 6.1 M1: IPv4 Tunnels to Encapsulate IPv6....................11 58 6.2 M2: IPv6 Tunnels to Encapsulate IPv4....................11 59 6.3 M3: IPv6 NAT to Communicate with IPv4...................11 60 6.4 M4: IPv6 Native LANs....................................12 61 6.5 M5: IPv6 Native Routing Domains.........................12 62 6.6 M6: Dual Stack Nodes supporting IPv6 and IPv4...........12 63 7. Enterprise Network Infrastructure Points of Transition......13 64 7.1 DNS.....................................................13 65 7.2 Routing.................................................13 66 7.3 Autoconfiguration.......................................13 67 7.4 Security................................................13 68 7.5 Applications and APIs...................................14 69 7.6 IPv6 Address Scoping....................................14 70 7.7 Network Management......................................14 71 7.8 Address Planning........................................14 72 8. Enterprise Tools Requirements...............................15 73 8.1 Routing Configuration...................................15 74 8.2 DNS Configuration.......................................15 75 8.3 IPv6 Address Allocation and Configuration...............15 76 8.4 IPv4 Address Allocation and Configuration...............15 77 8.5 VPN/Tunnel Configuration................................15 78 8.6 Mobile Node IPv4/IPv6 Interoperation Configuration......15 79 9. Enterprise Network Scenarios in Depth.......................16 80 10. Enteprise Network Scenarios Matrix Graph...................16 81 11. Applicability Statement....................................16 82 12. Security Section...........................................16 83 Acknowledgments................................................16 84 References.....................................................16 85 Design Team' Addresses.........................................17 86 1. Introduction 88 IPv6 will be deployed in Enterprise networks. This scenario has 89 requirements for the adoption of IPv6. This document will focus upon 90 and define: a set of technology scenarios that shall exist for the 91 enterprise network, the set of transition variables, transition 92 methods, and tools required by different scenarios. The document 93 using these definitions will define the points of transition for an 94 Enterprise network. 96 The audience for this document is the enterprise network team 97 considering deployment of IPv6. It is needed to clearly state the 98 problem space so there is a common understanding of the need for 99 transition tools in general. Specifically it is intended to show that 100 the enterprise brings an important set of cases that the transition 101 tools have to address. It will attempt to describe common 102 environments and the issues that are important to a transition. 104 To frame the discussion, it will focus on administrative policy 105 rather than size, and break that down by services available within 106 the enterprise. The business value and high level motivation for each 107 technical approach will be touched on in terms of cost/benefit 108 aspects. This value is expected to affect the order of deployment an 109 enterprise will take, so the document will try to order approaches 110 according to value. 112 While it is difficult to quantify all the potential motivations for 113 enterprise network teams to move to IPv6, there are some cases where 114 an abstract description is possible. 116 The primary case is the detrimental affect on the basic business 117 processes caused by a lack of available IPv4 addresses. This may be 118 through IPv4-NAT breaking applications or security technologies, or 119 the simple inability to achieve a viable business model with current 120 allocation policies. With a simpler end-to-end approach to 121 accomplishing the business goal, IPv6 provides strong motivations to 122 move. 124 Another related motivator is avoiding the significant and frequently 125 hidden burden on IT of continually balancing the available IPv4 126 address pool against the number of devices attached to a particular 127 network of subnets. This is generally a problem with fast growing 128 satellite offices, but also occurs as business priorities cause rapid 129 reorganization. Using the autoconfiguration capabilities of IPv6, the 130 effort aligns with the need for new independently routed segments, 131 rather than the shifting number of devices that may be attached to 132 any given network segment. 134 A slightly different motivator is the case of the enterprise that 135 develops products for other enterprises, where the consuming 136 enterprise has an insufficient pool of IPv4 addresses. While on the 137 surface this is another shortage motivator, the real business 138 motivator is for the supplier to avoid having to build and 139 continually update their product to work despite the presence of 140 IPv4-NAT. The NAT-traversal problem requires both substantial 141 resources to develop the work-around, as well as provide the 142 additional infrastructure components. Each of these raise the cost to 143 develop the product, therefore make it less competitive than a 144 comparable IPv6 based product. 146 Another case to consider are new enterprise networks that want to 147 begin their operations with IPv6 from day one. 149 2. Requirements 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 152 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in 154 RFC 2119. 156 3. Terminology 158 Enterprise Network - An Enterprise Network is a network 159 that has multiple links, a router 160 conection to a Provider, and is actively 161 managed by a network operations entity. 163 Provider - A Provider is an entity that provides 164 services and connectivity to the Internet 165 or other private external networks for 166 the Enterprise Network. 168 Edge - The Edge is the ingress and egress points 169 connecting to the Internet, Extranet, or 170 to another private external network. 172 Administrative Domain - An Administrative Domain are the 173 ingress and egress points connecting 174 nodes across the Enterprise 175 Network, behind the Edges. 177 Extranet - An Extranet is any Enterprise Network 178 owned network components at the Edge, but 179 not part of the Administrative Domain. 181 Border Router - An Enterprise Network Border Router is a 182 a router that is configured at the Edges. 184 Internal Router - An Enterprise Network Internal Router is 185 a router that is not configured at an 186 Edge, but within the Administrative Domain. 188 Mobile - An Enterprise Network condition when a 189 node changes its network location, or 190 is not attached to the Administrative 191 Domain. 193 Mobile Node - An Enterprise Network Mobile Node is any 194 node that is Mobile within or not 195 within the enterprise, or as remote 196 telecommuting node. 198 Points of Transtion - An Enterprise Network Point of Transition 199 is a general abstraction to note functions 200 that must be defined for the transition to 201 IPv6. 203 Internet Network Provider - A Provider for connectivity and services 204 to the public Internet. 206 Private Network Provider - A Provider for connectivity and services 207 to a private Internet. 209 Dual Stack IPv4/IPv6 Node - A node that supports IPv4 and IPv6. 211 IPv4 ONLY Node - A node that only supports IPv4. 213 IPv6 ONLY Node - A node that only supports IPv6 215 4. Enterprise Network Assumptions 217 In this section assumptions about the enterprise network for this 218 document are provided. 220 Each network will need to select the method to best suit their 221 business requirements. Any attempt to define a default or one- 222 size-fits-all set of variables and methods for all scenarios would 223 result in failure. 225 Every node that can be addressed by another node must be in a 226 registered name service, managing this name service is a 227 significant scaling challenge for the Enterprise. 229 Applications that support multiple users on multiple nodes 230 (multi-Party) require globally consistent addresses for peer-to- 231 peer communications. 233 Bi-directional communication between two nodes across Service 234 Provider networks is often used as a crude level of authenticity, 235 having the IP addresses in the IP header be the same as from where 236 the nodes data packet came from provides a rudimentary component 237 of security. 239 Enterprise Networks will vary in size and network complexity from 240 a small office to a large manufacturing operation with multiple 241 sites, across a wide geography 243 Points of Transition will need to be defined for the following: 245 - Routers 246 - Non Router Nodes 247 - Network Topology 248 - Network Applications 249 - Network Management and Tools 250 - Network Security 251 - Network Mobility 252 - Network VPNs 253 - Network Telecommuter Work Force 254 - Network Inter Site Communications 256 This document will identify those Points of Transition and discuss 257 them within a set of scenarios. This document will not provide 258 solutions. A set of suggested solutions will be provided in a follow 259 on document to this work. 261 Enterprise Networks will vary how they approach the transition to 262 IPv6 depending on a set of transition variables (V1..VN): 264 V1: IPv4 NAT and Firewall uses IPv4 private addresses. 265 V2: IPv4 Firewall uses IPv4 global routable addresses. 266 V3: Applications must be able to communicate between remote 267 Administrative Domains. 268 V4: The methods and security used to access the Administrative 269 Domain for Telecommuters and Mobile Nodes. 270 V5: IPv6 software upgrades are not available for existing 271 routers and nodes. 273 V6: Source code for applications have been lost or cannot be 274 upgraded to IPv6. 275 V7: New business function being defined and can exist without 276 extensive access to legacy IPv4 networks and nodes. 277 V8: Mission critical applications must be able to interoperate 278 with legacy IPv4 nodes. 279 V9: Legacy IPv4 nodes can be upgraded to support dual stack 280 IPv4 and IPv6. 281 V10: Legacy IPv4 nodes cannot be upgraded to support dual stack 282 IPv4 and IPv6. 283 V11: What sections of the network for an existing network or 284 new network will move towards IPv6 deployment first, second, ...., 285 last, and at what rate. 286 V12: What are the network security requirements for the Enterprise 287 Network. 288 V13: Provider does not support IPv6. 290 The transition variables are the parameters to the first function to 291 determine the functions for a scenario. Once the transition variables 292 are understood then the next step is to select transition methods as 293 follows (M1..MN): 295 M1: IPv4 Tunnels to Encapsulate IPv6 296 M2: IPv6 Tunnels to Encapsulate IPv4 297 M3: IPv6 NAT to Communicate with IPv4 298 M4: IPv6 Native LANs 299 M5: IPv6 Native Routing Domains 300 M6: Dual Stack Nodes supporting IPv6 and IPv4 301 M7: IPv6 Tunnels to Encapsulate IPv6 303 This document will define a list of sets for transition variables, 304 methods, and tool requirements, which will provide a three 305 dimensional system for analysis that can be used to extrapolate a set 306 of solutions. Where the X axis is the transition variables (V#), the 307 Y axis the transition method (M#), and the Z axis the tools 308 requirement set (section 8) to support X and Y conditions. 310 This point on the graph will be an transtion strategy. After the 311 document describes the scenarios in depth (section 9) the graph will 312 be depicted in a matrix for readers of this document (section 10) 314 5. Enterprise Network Scenarios Overview 316 It would be impossible for any one document to describe all the 317 potential scenarios as networks deploy IPv6. Attempting to break the 318 problem space down and cover the high level perspectives, this 319 document will separate the scenarios by administrative scope and 320 policy. Within each, the various ISP service offerings produce 15 321 cases to describe. Finally, we find there are 27 cases when the 322 additional characteristic of host and application-first versus 323 network-first approaches are considered. 325 The 15 above is 5 cases x 3 offerings. The 27 comes from the doubling 326 by discussing network vs. application first, minus the 3 offerings 327 from set D because it has to be done all at once. Another way to 328 describe the table is scenarios x offerings x order = (4 x 3 x 2) + 329 (1 x 3 x 1). 331 Without looking for a one-size-fits-all, to simplify the document we 332 will assume a single motivating application. The multi-party peer-to- 333 peer conferencing application they are deploying to improve 334 productivity requires unambiguous addresses. The IPv6 enabled 335 application needs to communicate with each party as a peer, while 336 other applications on those systems still need access to IPv4 based 337 services. 339 Critical issues for each: 341 Addressing : Dynamic vs. control w/administrative burden 342 DNS : Dynamic vs. control w/administrative burden 343 Public visibility of the name space. 344 AAA : Internal & external 345 Mobility of road warrior and telecommuters 346 Applications: What applications are needed 347 PMTUD : Support for discovery vs. traditional ICMP aversion 348 Mobility : Requirements for nodes 349 Management : Network and tools management 351 Trust system between host & network management teams: 353 Dual-stack vs. IPv6-only 354 IPv6-only is a restricted capability subset 355 Routing 356 Architectural concept of tunneling over foo vs. native service 358 Scenario set A: 360 Single geographic region, single administration & policy 361 ISP offering - IPv4-only IPv4 & IPv6 IPv6-only 362 Deployment order - Hosts & Apps first Network first 364 Scenario set B: 366 Multiple geographic regions, single administration & policy 367 ISP offering - IPv4-only IPv4 & IPv6 IPv6-only 368 Deployment order - Hosts & Apps first Network first 370 Scenario set C: 372 Multiple geographic regions, multiple administrations & policy 373 ISP offering - IPv4-only IPv4 & IPv6 IPv6-only 374 Deployment order - Hosts & Apps first Network first 376 Scenario set D: 378 New enterprise, looking to avoid a transition 379 ISP offering - IPv4-only IPv4 & IPv6 IPv6-only 380 Deployment order - All at once by definition 382 Scenario set E: 384 Enterprise Services for remote users 385 ISP offering - IPv4-only IPv4 & IPv6 IPv6-only 386 Deployment order - Hosts & Apps first Network first 388 Scenario #1 390 An enterprise has an existing IPv4 network and is adding IPv6 between 391 geographic sites. Set A and B. 393 Scenario #2 395 An enterprise deploys wireless services where groups of access points 396 end up on different subnets. Set A and B. 398 Scenario #3 400 A multi-site enterprise has deployed IPv4-NAT with overlapping 401 private address ranges between the sites. Set A and B. 403 Scenario #4 405 A global enterprise interacts with a public and private Internet as a 406 cohesive unit, but is composed of several administratively distinct 407 business units. Set C. 409 Scenario #5 411 Two large enterprises using IPv4-NAT merge with the consequence that 412 large segments of private network address space overlap. Set C. 414 Scenario #6 416 A new Enterprise providing location based services for over a wide 417 geography enables mobile devices for their Account Teams to access 418 network data and services. Set D. 420 Scenario #6 (subset of all scenarios) 422 Enterprise employees telecommute to work from home, or during 423 business travel. Set E. 425 6. Enterprise Points of Transition Methods 427 The Enterprise network will have varying points of transition that 428 will require different points of interoperability with IPv6 and IPv4. 429 These points of transition are the fulcrum of the template to define 430 what is required for Enterprise networks within the focus of this 431 document. 433 6.1 M1: IPv4 Tunnels to Encapsulate IPv6 435 This Point of Transition exists for the following conditions: 437 1. Two Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6, 438 but an IPv4 Internal Router is between them. These nodes could also 439 be Mobile nodes too and in a remote location. 440 2. Two Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6, 441 but they are in a remote Administrative Domain and geography, and 442 packets must be sent to a Provider. These nodes could also be Mobile 443 nodes and in a remote location. 444 3. Two Mobile Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6, 445 and both are on remote IPv4 network. 446 4. Two Mobile Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6, 447 and both are on remote IPv6 network. 449 It is important to realize in this scenario the transit providers 450 could be IPv4-ONLY. 452 6.2 M2: IPv6 Tunnels to Encapsulate IPv4 454 This Point of Transition exists for the following conditions: 456 1. A Dual Stacked IPv4/IPv6 node wants to communicate to a legacy IPv4 457 service and is on a Native IPv6 link and Routing Domain. Enterpise 458 policy is that IPv6 should be used to encapsulate IPv4. 459 2. A Dual Stacked IPv4/IPv6 node wants to communicate to a legcy IPv4 460 service and is on a Native IPv6 link and Routing Domain. Enterprise 461 policy is IPv4 should be used for this communications. 462 3. Same conditions above but for Mobile node. 464 6.3 M3: IPv6 NAT to Communicate with IPv4 466 This Point of Transition exists for the following conditions: 468 1. A Dual Stacked IPv4/IPv6 node wants to communicate with a legacy IPv4 469 ONLY service or node. Enterprise policy is that IPv6 NAT should be 470 used for this communications. 471 2. An IPv6 ONLY node wants to communicate with a legacy IPv4 ONLY node 472 or service. Same policy as above. 473 3. Same conditions above but for Mobile IPv6 ONLY node. 475 Using NAT for this point of transition will preclude end-2-end 476 security, applications, and remove some benefits from the IPv6 477 protocol. 479 1. The Design Team highly recommends that network not adopt the policy 480 in reference "1" above. 481 2. IPv6 ONLY nodes should not be deployed in a network until they will 482 not require access to any legacy IPv4. This means that applications 483 and infrastructure has been ported or moved to IPv6. Until that 484 time nodes for transition should be Dual Stacked IPv4/IPv6 nodes. 485 This means networks that want to use IPv6 ONLY nodes will be required 486 to move applications and infrastructure to IPv6 first. 488 6.4 M4: IPv6 Native LANs 490 This Point of Transtion exists when the policy wants to support the 491 deployment of Native IPv6 LANs. This condition will be driven by the 492 transition variables V1-V14 stated in Section 4. 494 6.5 M5: IPv6 Native Routing Domains 496 This Point of Transition exists when the policy is to deploy IPv6 497 Native Routing Domains. This condition will be driven by the 498 variables V1-14 stated in Section 4. 500 6.6 M6: Dual Stack Nodes supporting IPv6 and IPv4 502 This Point of Transition is a method to deploy IPv6 and a method for 503 transition. A network that deploys Dual Stacked IPv4/IPv6 nodes as 504 they adopt IPv6 are more assured that IPv6 and IPv4 interoperation 505 will be possible between the two nodes or services. It also means 506 for many legacy IPv4 nodes that they can be upgraded to support IPv4 507 and IPv6, but not turn on IPv6 until the IPv6 operational network has 508 been verified to be interoperable and secure. It also means that 509 both IPv4 and IPv6 can be supported by the nodes that transition to 510 IPv6 and then will be able to communicate with IPv4 nodes using an 511 IPv4 network infrastructure. 513 7. Enterprise Network Infrastructure Points of Transition 515 The Enterprise will be required to determine what network 516 infrastructure will be affected by transtion to IPv6. This 517 infrastructure must be analyzed and understood as a critical resource 518 to manage. 520 Each topic below in this section will be discussed and the issues 521 facing transition for these network infrastructure parts will be 522 discussed. 524 7.1 DNS 526 This will be discussed in a future draft. 528 7.2 Routing 530 This will be discussed in a future draft. 532 7.3 Autoconfiguration 534 IPv6 introduces the concept of autoconfiguration [RFC2462]. 535 Autoconfiguration removes the need for DHCP to dynamically assign 536 addresses to nodes. Though DHCPv6 can be used to administrate 537 addresses that are assigned to nodes. 539 When preforming stateless autoconfiguration, an EUI-64 is generated 540 by the IPv6 node, on a per-interface basis, to form the entire 128 541 bit IPV6 address. The EUI-64 is derived from the MAC address of the 542 interface that being autoconfigured. This mechanism proves a large 543 amount of flexibility when joining new nodes to an IPv6 network. 544 Since the address is tied to the MAC address of a given interface, 545 swapping said interface device would change the address of the node. 546 This presents a problem for nodes, such as servers and routers, that 547 require a stable IP address. 549 It is suggested that nodes which require such stability, in their IP 550 address, make use of either stateful autoconfiguration or fixed 551 interface-id autoconfiguration. The later involves using a fixed 64 552 bit token, instead of the EUI-64. Determining the value of this 553 token should be considered when establishing an address plan." 555 7.4 Security 557 This will be discussed in a future draft. 559 7.5 Applications and APIs 561 This will be discussed in a future draft. 563 7.6 IPv6 Address Scoping 565 This will be discussed in a future draft. 567 7.7 Network Management 569 This will be discussed in a future draft. 571 7.8 Address Planning 573 This will be discussed in a future draft. 575 8. Enterprise Tools Requirements 577 This section will identify the tools requirements for an EN 578 transitioning to IPv6 so the configuration issues for the EN are 579 documented for the document. 581 8.1 Routing Configuration 583 This will be discussed in a future draft. 585 8.2 DNS Configuration 587 This will be discussed in a future draft. 589 8.3 IPv6 Address Allocation and Configuration 591 This will be discussed in a future draft. 593 8.4 IPv4 Address Allocation and Configuration 595 This will be discussed in a future draft. 597 8.5 VPN/Tunnel Configuration 599 This will be discussed in a future draft. 601 8.6 Mobile Node IPv4/IPv6 Interoperation Configuration 603 This will be discussed in a future draft. 605 9. Enterprise Network Scenarios in Depth 607 This section will discuss the Scenarios in depth and identify the 608 transition methods options and tools requirements from previous 609 sections. 611 This will be done in a future draft. 613 10. Enteprise Network Scenarios Matrix Graph 615 This section will provide a set of matrices from the scenarios, 616 transition variables, methods, and tools to define and determine 617 common points of transition across the Scenarios. 619 This will be done in future draft. 621 11. Applicability Statement 623 This will be done in a future draft as we get more working group discussion. 625 12. Security Section 627 The first iteration of this section will be done in a future draft. 629 Acknowledgments 631 Enterprise Network Scenarios Design Team: 633 Yanick Pouffary (Chair) - Hewlett Packard 634 Jim Bound (Editor) - Hewlett Packard 635 Yurie Rich - Native6 Group 636 Marc Blanchet - Hexago 637 Tony Hain - Cisco 638 Paul Gilbert - Cisco 639 Scott Hahn - Intel 640 Margaret Wasserman - Windriver 641 Jason Goldschmidt - Sun Microsystems 642 Mathew Lehman - Microsoft 643 Aldrin Isaac - Bloomberg 645 The Design Team would also like to acknowledge the input from the 646 following: IETF V6OPS Working Group, Tim Chown, Alain Durand, and Bob Hinden. 648 References 650 These will be provided as the drafts mature and we reference related 651 work in the IETF and in the Industry. 653 Design Team' Addresses 655 Send email to ent-v6net@viagenie.qc.ca to contact the design team and send comments on the draft to v6ops@ops.ietf.org. 657 Authors contact info will be provided in a future draft.