idnits 2.17.1 draft-ietf-v6ops-ent-scenarios-03.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: ---------------------------------------------------------------------------- ** 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 16 longer pages, the longest (page 6) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 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 "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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: 6 errors (**), 0 flaws (~~), 5 warnings (==), 4 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-03.txt Hewlett Packard 4 Obsoletes: draft-ietf-v6ops-ent-scenarios-02.txt 5 Expires: December 2004 7 IPv6 Enterprise Network Scenarios 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 This document is a submission by the Internet Protocol IPv6 Working 17 Group of the Internet Engineering Task Force (IETF). Comments should 18 be submitted to the ipng@sunroof.eng.sun.com mailing list. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document describes the scenarios for IPv6 deployment within 39 enterprise networks. It will focus upon an enterprise set of network 40 base scenarios with assumptions, coexistence with legacy IPv4 nodes, 41 networks, and applications, and network infrastructure requirements. 42 These requirements will be used to provide analysis to determine a 43 set of enterprise solutions in a later document. 45 Table of Contents: 47 1. Introduction................................................3 48 2. Terminology.................................................5 49 3. Base Scenarios..............................................6 50 3.1 Base Scenarios Defined.....................................6 51 3.2 Scenarios Network Infrastructure Components................7 52 3.3 Specific Scenario Examples.................................9 53 4. Network Infrastructure Component Requirements..............10 54 4.1 DNS.......................................................11 55 4.2 Routing...................................................11 56 4.3 Configuration of Hosts....................................11 57 4.4 Security..................................................11 58 4.5 Applications..............................................12 59 4.6 Network Management........................................12 60 4.7 Address Planning..........................................12 61 4.8 Multicast..................................................12 62 4.9 Multihoming................................................12 63 5. Security Considerations....................................13 64 6. References.................................................13 65 6.1 Normative References......................................13 66 6.2 Non-Normative References..................................13 67 Document Acknowledgments.......................................13 68 Authors Addresses .............................................14 69 Intellectual Property Statement................................15 70 Full Copyright Statement.......................................16 71 Acknowledgement................................................16 72 1. Introduction 74 This document describes the scenarios for IPv6 deployment within 75 enterprise networks. It will focus upon an enterprise set of network 76 base scenarios with assumptions, coexistence with legacy IPv4 nodes, 77 networks, and applications, and network infrastructure requirements. 78 These requirements will be used to provide analysis to determine a 79 set of enterprise solutions in a later document. 81 The audience for this document is the enterprise network team 82 considering deployment of IPv6. The document will be useful for 83 enterprise teams that will have to determine the IPv6 transition 84 strategy for their enterprise. It is expected those teams include 85 members from management, network operations, and engineering. The 86 scenarios presented provide an example set of cases the enterprise 87 can use to build an IPv6 network scenario. 89 To frame the discussion, the document will describe a set of 90 scenarios and network infrastructure for each scenario. It is 91 impossible to define every possible enterprise scenario that will 92 apply to IPv6 adoption and transition. 94 Each enterprise will select the transition that best supports their 95 business requirements. Any attempt to define a default or one-size- 96 fits-all transition scenario, will simply not work. This document 97 does not try to depict the drivers for adoption of IPv6 by an 98 enterprise. 100 While it is difficult to quantify all the scenarios for an enterprise 101 network team to plan for IPv6, it is possible to depict a set of 102 abstract scenarios that will assist with planning. The document 103 presents three base scenarios as a general use case to be used as a 104 model as input for the enterprise to define specific scenarios. 106 The first scenario assumes the enterprise decides to deploy IPv6 in 107 conjunction with IPv4. The second scenario assumes the enterprise 108 decides to deploy IPv6 because of a specific set of applications the 109 enterprise wants to use over an IPv6 network. The third scenario 110 assumes an enterprise is building a new network or re-structuring an 111 existing network and decides to deploy IPv6 as the predominant 112 protocol within the enterprise coexisting with IPv4. The document 113 then defines a set of network infrastructure components that must be 114 analyzed. 116 The document then provides three specific scenario examples using the 117 network infrastructure components to depict the requirements. These 118 are common enterprise deployment cases to depict the challenges for 119 the enterprise to transition a network to IPv6. 121 The document then discusses the issues of supporting legacy functions 122 on the network, while the transition is in process, and the network 123 infrastructure components required to be analyzed by the enterprise. 124 The interoperation with legacy functions within the enterprise will 125 be required for all transition except possibly by a new network that 126 will be IPv6 from inception. The network infrastructure components 127 will depict functions in their networks that require consideration 128 for IPv6 deployment and transition. 130 Using the scenarios, network infrastructure components, and examples 131 in the document an enterprise can define its specific scenario 132 requirements. Understanding the legacy functions and network 133 infrastructure components required, the enterprise can determine the 134 network operations required to deploy IPv6. The tools and mechanisms 135 to support IPv6 deployment operations will require enterprise 136 analysis. The analysis to determine the tools and mechanisms to 137 support the scenarios will be presented in subsequent document(s). 139 2. Terminology 141 Enterprise Network - A network that has multiple internal links, 142 one or more router connections, to one or 143 more 144 Providers and is actively managed by a 145 network 146 operations entity. 148 Provider - An entity that provides services and 149 connectivity to the Internet or 150 other private external networks for the 151 enterprise network. 153 IPv6 Capable - A node or network capable of supporting both 154 IPv6 and IPv4. 156 IPv4 only - A node or network capable of supporting only 157 IPv4. 159 IPv6 only - A node or network capable of supporting only 160 IPv6. This does not imply an IPv6 only 161 stack, in this document. 163 3. Base Scenarios 165 Three base scenarios are defined to capture the essential abstraction 166 set for the enterprise. Each scenario has assumptions and 167 requirements. This is not an exhaustive set of scenarios, but a base 168 set of general cases. 170 Below we use the term network infrastructure to mean the software, 171 network operations and configuration, and the methods used to operate 172 a network in an enterprise. 174 3.1 Base Scenarios Defined 176 Scenario 1: Enterprise with an existing IPv4 network wants to deploy 177 IPv6 in conjunction with their IPv4 network. 179 Assumptions: The IPv4 network infrastructure used has an equivalent 180 capability in IPv6. 182 Requirements: Do not disrupt existing IPv4 network infrastructure 183 assumptions with IPv6. IPv6 should be equivalent or 184 "better" than the network infrastructure in IPv4, 185 however, it is understood that IPv6 is not required 186 to 187 solve current network infrastructure problems, 188 not solved by IPv4. It may also not be feasible to 189 deploy IPv6 on all parts of the network immediately. 191 Scenario 2: Enterprise with an existing IPv4 network wants to deploy 192 a 193 set of particular IPv6 "applications" (application is 194 voluntarily loosely defined here, e.g. peer to peer). 195 The IPv6 deployment is limited to the minimum required 196 to 197 operate this set of applications. 199 Assumptions: IPv6 software/hardware components for the application 200 are available, and platforms for the application 201 are IPv6 capable. 203 Requirements: Do not disrupt IPv4 infrastructure. 205 Scenario 3: Enterprise deploying a new network or re-structuring an 206 existing network, decides IPv6 is the basis for 207 most network communication, to coexist with IPv4. 209 Assumptions: Required IPv6 network infrastructure is available, or 210 available over some defined timeline, supporting the 211 enterprise plan. 213 Requirements: Interoperation and Coexistence with IPv4 network 214 network infrastructure and applications are required 215 for 216 communications. 218 3.2 Scenarios Network Infrastructure Components 220 This section defines the network infrastructure that exist for the 221 above enterprise scenarios. This is not an exhaustive list, but a 222 base list that can be expanded by the enterprise for specific 223 deployment scenarios. The network infrastructure components are 224 presented as functions that the enterprise must analyze as part of 225 defining their specific scenario. The analysis of these functions 226 will identify actions that are required to deploy IPv6. 228 Network Infrastructure Component 1 229 Enterprise Provider Requirements 230 - Is external connectivity required? 231 - One site vs. multiple sites and are they within different 232 geographies? 233 - Leased lines or VPNS? 234 - If multiple sites, how is the traffic exchanged securely? 235 - How many global IPv4 addresses are available to the 236 enterprise? 237 - What is the IPv6 address assignment plan available 238 from the provider? 239 - What prefix delegation is required by the Enterprise? 240 - Will the enterprise be multihomed? 241 - What multihoming techniques are available from the provider? 242 - Will clients within the enterprise be multihomed? 243 - Does the provider offer any IPv6 services? 244 - What site external IPv6 routing protocols are required? 245 - Is there an external data-center to the enterprise, such as 246 servers located at the Provider? 247 - Is IPv6 available using the same access links as IPv4, 248 or differently? 250 Network Infrastructure Component 2 251 Enterprise Application Requirements 252 - List of applications in use? 253 - Which applications must be moved to support IPv6 first? 254 - Can the application be upgraded to IPv6? 255 - Will the application have to support both IPv4 and IPv6? 256 - Do the enterprise platforms support both IPv4 and IPv6? 257 - Do the applications have issues with NAT v4-v4 and NAT v4-v6? 258 - Do the applications need globally routable IP addresses? 259 - Do the applications care about dependency between IPv4 and IPv6 260 addresses? 261 - Are applications run only on the internal enterprise network? 263 Network Infrastructure Component 3 264 Enterprise IT Department Requirements 265 - Who "owns"/"operates" the network: in house, or outsourced? 266 - Is working remotely (e.g., through VPNs) supported? 267 - Is inter-site communications required? 268 - Is network mobility used or required for IPv6? 269 - What are the requirements of the IPv6 address plan? 270 - Is there a detailed asset management database, including 271 hosts, IP/MAC addresses, etc.? 272 - What is the enterprise' approach to numbering geographically 273 separate sites which have their own Service Providers? 274 - What will be the internal IPv6 address assignment procedure? 275 - What site internal IPv6 routing protocols are required? 276 - What will be the IPv6 Network Management policy/procedure? 277 - What will be the IPv6 QOS policy/procedure? 278 - What will be the IPv6 Security policy/procedure? 279 - What is the IPv6 training plan to educate the enterprise? 280 - What network operations software will be impacted by IPv6? 281 - DNS 282 - Management (SNMP & ad-hoc tools) 283 - Enterprise Network Servers Applications 284 - Mail Servers 285 - High Availability Software for Nodes 286 - Directory Services 287 - Are all these software functions upgradeable to IPv6? 288 - If not upgradeable, then what are the workarounds? 289 - Do any of the software functions store, display, or 290 allow input of IP addresses? 291 - Other services (e.g. NTP, etc.........) 292 - What network hardware will be impacted by IPv6 293 - Routers/switches 294 - Printers/Faxes 295 - Firewalls 296 - Intrusion Detection 297 - Load balancers 298 - VPN Points of Entry/Exit 299 - Security Servers and Services 300 - Network Interconnect for Platforms 301 - Intelligent Network Interface Cards 302 - Network Storage Devices 303 - Are all these hardware functions upgradeable to IPv6? 304 - If not, what are the workarounds? 305 - Do any of the hardware functions store, display, or 306 allow input of IP addresses? 307 - Are the nodes moving within the enterprise network? 308 - Are the nodes moving outside and inside the enterprise 309 network? 311 Network Infrastructure Component 4 312 Enterprise Network Management System 313 - Performance Management Required? 314 - Network Management Applications Required? 315 - Configuration Management Required? 316 - Policy Management and Enforcement Required? 317 - Security Management Required? 318 - Management of Transition Tools and Mechanisms? 319 - What new considerations does IPv6 create for Network 320 Management? 322 Network Infrastructure Component 5 323 Enterprise Network Interoperation and Coexistence 324 - What platforms are required to be IPv6 capable? 325 - What network ingress and egress points to the site are 326 required to be IPv6 capable? 327 - What transition mechanisms are needed to support IPv6 328 network operations? 329 - What policy/procedures are required to support the 330 transition to IPv6? 331 - What policy/procedures are required to support 332 interoperation with legacy nodes and applications? 334 3.3 Specific Scenario Examples 336 This section presents a set of base scenario examples and is not an 337 exhaustive list of examples. These examples were selected to provide 338 further clarity for base scenarios within an enterprise of a less 339 abstract nature. 341 Example Network A: 343 A distributed network across a number of geographically separated 344 campuses. 346 - External network operation. 347 - External connectivity required. 348 - Multiple sites connected by leased lines. 349 - Provider independent IPv4 addresses. 350 - ISP does not offer IPv6 service. 351 - Private Leased Lines no Service Provider Used 353 Applications run by the enterprise: 355 - Internal Web/Mail. 356 - File servers. 357 - Java applications. 358 - Collaborative development tools. 359 - Enterprise Resource Applications. 360 - Multimedia Applications. 361 - Financial Enterprise Applications. 362 - Data Warehousing Applications. 364 Internal network operation: 366 - In house operation of the network. 367 - DHCP (v4) is used for all desktops, servers use static address 368 configuration. 369 - The DHCP server updates naming records for dynamic desktops uses 370 dynamic DNS. 371 - A web based tool is used to enter name to address mappings for 372 statically addressed servers. 373 - Network management is done using SNMP. 374 - All routers and switches are upgradeable to IPv6. 375 - Existing firewalls can be upgraded to support IPv6 rules. 376 - Load balancers do not support IPv6, upgrade path unclear. 377 - Peer-2-Peer Application and Security supported. 378 - IPv4 Private address space is used within the enterprise. 380 Example Network B: 382 A bank running a large network supporting online transaction 383 processing (OLTP) across a distributed multi-sited network, with 384 access 385 to a central database on an external network from the OLTP network: 387 - External connectivity not required. 388 - Multiple sites connected by VPN. 389 - Multiple sites connected by Native IP protocol. 390 - Private address space used with NAT. 391 - Connections to private exchanges. 393 Applications in the enterprise: 394 - ATM transaction application. 395 - ATM management application. 396 - Financial Software and Database. 397 - Part of the workforce is mobile and requires access to the 398 enterprise from outside networks. 400 Internal Network Operation: 401 - Existing firewalls can be upgraded to support IPv6 rules. 402 - Load balancers do not support IPv6, upgrade path unclear. 403 - Identifying and managing each nodes IP address. 405 Example Network C: 407 A Security Defense Network Operation: 409 - External network required at secure specific points. 410 - Network is its own Internet. 411 - Network must be able to absorb ad-hoc creation of sub-Networks. 412 - Entire parts of the Network are completely mobile. 413 - All nodes on the network can be mobile (including routers) 414 - Network True High-Availability is mandatory. 415 - Network must be able to be managed from ad-hoc location. 416 - All nodes must be able to be configured from stateless mode. 418 Applications run by the Enterprise: 419 - Multimedia streaming of audio, video, and data for all nodes. 420 - Data computation and analysis on stored and created data. 421 - Transfer of data coordinate points to sensor devices. 422 - Data and Intelligence gathering applications from all nodes. 424 Internal Network Operations: 425 - All packets must be secured end-2-end with encryption. 426 - Intrusion Detection exists on all network entry points. 427 - Network must be able to bolt on to the Internet to share 428 bandwidth as required from Providers. 429 - VPNs can be used but NAT can never be used. 430 - Nodes must be able to access IPv4 legacy applications over IPv6 431 network. 433 4. Network Infrastructure Component Requirements 435 The enterprise will need to determine what network infrastructure 436 components require enhancements or to be added for deployment of 437 IPv6. This infrastructure will need to be analyzed and understood as 438 a critical resource to manage. The list in this section is not 439 exhaustive but are the essential network infrastructure components to 440 consider for the enterprise before they begin to define more fine 441 tuned requirements such as QOS, PKI, or Bandwidth requirements for 442 IPv6 as examples. The components are only identified here and the 443 details of the components will be discussed in the analysis document 444 for enterprise scenarios. Where there are references at this time 445 for a component they are provided. 447 4.1 DNS 449 DNS will now have to support both IPv4 and IPv6 DNS records and the 450 enterprise will need to determine how the DNS is to be managed and 451 accessed, and secured. The range of DNS operational issues are out 452 of scope for this work. Users need to consider all current DNS IPv4 453 operations and determine if those operations are supported for IPv6. 454 However, DNS resolution and transport solutions for both IP protocols 455 are influenced by the chosen IPv6 deployment scenario. Users need to 456 consider all current DNS IPv4 operations and determine if those 457 operations are supported for IPv6 [DNSV6]. 459 4.2 Routing 461 Interior and Exterior routing will be required to support both IPv4 462 and IPv6 routing protocols, and the coexistence of IPv4 and IPv6 over 463 the enterprise network. The enterprise will need to define the IPv6 464 routing topology, any ingress and egress points to provider networks, 465 and transition mechanisms they wish to use for IPv6 adoption. The 466 enterprise will also need to determine what IPv6 transition 467 mechanisms are supported by their upstream providers. 469 4.3 Configuration of Hosts 471 IPv6 introduces the concept of stateless autoconfiguration in 472 addition to stateful autoconfiguration, for the configuration of 473 Hosts within the enterprise. The enterprise will have to determine 474 the best method of host configuration, for their network. The 475 enterprise will need to determine if they are to use stateless or 476 stateful autoconfiguration, and how autoconfiguration is to operate 477 for DNS updates. The enterprise will need to determine how prefix 478 delegation is done from their upstream provider and how those 479 prefixes are cascaded down to the enterprise IPv6 network. The 480 policy for DNS or choice of autoconfiguration is out of scope for 481 this document. [CONF, DHCPF, DHCPL] 483 4.4 Security 485 Current existing mechanisms used for IPv4 to provide security need to 486 be supported for IPv6 within the enterprise. IPv6 should create no 487 new security concerns for IPv4. The entire security infrastructure 488 currently used in the enterprise needs to be analyzed against IPv6 489 deployment effect and determine what is supported in IPv6. Users 490 should review other security IPv6 network infrastructure work in the 491 IETF and within the industry on going at this time. Users will have 492 to work with their platform and software providers to determine what 493 IPv6 security network infrastructure components are supported. The 494 security filters and firewall requirements for IPv6 need to be 495 determined by the enterprise. The policy choice of users for security 496 is out of scope for this document. 498 4.5 Applications 500 Existing applications will need to be ported or provide proxies to 501 support both IPv4 and IPv6 [APPS]. 503 4.6 Network Management 505 The addition of IPv6 network infrastructure components will need to 506 be managed by the enterprise network operations center. Users will 507 need to work with their network management platform providers to 508 determine what for IPv6 is supported during their planning for IPv6 509 adoption, and what tools are available in the market to monitor the 510 network. Network management will not need to support both IPv4 and 511 IPv6 and view nodes as dual stacks. 513 4.7 Address Planning 515 The address space within the enterprise will need to be defined and 516 coordinated with the routing topology of the enterprise network. It 517 is also important to identify the pool of IPv4 address space 518 available to the enterprise to assist with IPv6 transition methods. 520 4.8 Multicast 522 Enterprises utilizing IPv4 Multicast services will need to consider 523 how these services may be implemented operationally in an IPv6- 524 enabled environment. 526 4.9 Multihoming 528 At this time, current IPv6 allocation policies are mandating the 529 allocation of IPv6 address space from the upstream provider. If an 530 enterprise is multihomed, the enterprise will have to determine how 531 they wish to support multihoming. This also is an area of study 532 within the IETF and work in progress. 534 5. Security Considerations 536 This document lists scenarios for the deployment of IPv6 in 537 enterprise networks, and there are no security considerations 538 associated with making such a list. 540 There will security considerations for the deployment of IPv6 in each 541 of these scenarios, but they will be addressed in the document that 542 includes the analysis of each scenario. 544 6. References 546 6.1 Normative References 548 [DNSV6] Durand, A., Ihren, J. and P. Savola, "Operational 549 Considerations and Issues with IPv6 DNS", Work in 550 Progress. 552 [CONF] Thomson, S., Narten, T., "IPv6 Stateless Autoconfiguration" 553 RFC 2462 December 1998. 555 [DHCPF] Droms, R., Bound, J., Volz, B., Lemon, T., et al. "Dynamic 556 Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 July 557 2003. 559 [DHCPL] Droms, R., "Stateless Dynamic Host Configuration Protocol 560 (DHCP) Service for IPv6" RFC 3756 April 2004. 562 [APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., Castro, E., 563 "Application Aspects of 564 IPv6 Transition" Work in Progress. 566 6.2 Non-Normative References 568 None at this time. 570 Document Acknowledgments 572 The Authors would like to acknowledge contributions from the 573 following: IETF v6ops Working Group, Alan Beard, Brian Carpenter, 574 Alain Durand, Bob Hinden, and Pekka Savola. 576 Authors Addresses 578 Yanick Pouffary (Chair of Design Team) 579 HP Competency Center 580 950, Route des Colles, BP027, 581 06901 Sophia Antipolis CEDEX 582 FRANCE 583 Phone: + 33492956285 584 Email: Yanick.pouffary@hp.com 586 Jim Bound (Editor) 587 Hewlett Packard 588 110 Spitbrook Road 589 Nashua, NH 03062 590 USA 591 Phone: 603.884.0062 592 Email: jim.bound@hp.co 594 Marc Blanchet 595 Viagenie inc. 596 2875 boul. Laurier, bur. 300 597 Ste-Foy, Quebec, Canada, G1V 2M2 598 EMail: Marc.Blanchet@viagenie.qc.ca 600 Tony Hain 601 Cisco Systems 602 500 108th Ave. N.E. Suite 400 603 Bellevue, Wa. 98004 604 Email: alh-ietf@tndh.net 606 Paul Gilbert 607 Cisco Systems 608 1 Penn Plaza, 5th floor, 609 NY, NY 10119 610 USA 611 Phone: 212.714.4334 612 Email: pgilbert@cisco.com 614 Margaret Wasserman 615 Nokia 616 5 Wayside Road 617 Burlington, MA 01803 618 US 619 Phone: +1 781 993 4900 620 EMail: margaret.wasserman@nokia.com 621 URI: http://www.nokia.com/ 623 Jason Goldschmidt 624 Sun Microsystems 625 M/S UMPK17-103 626 17 Network Circle 627 Menlo Park, CA 94025 628 USA 629 Phone: (650)-786-3502 630 Fax: (650)-786-8250 631 Email:jason.goldschmidt@sun.com 633 Aldrin Isaac 634 Bloomberg L.P. 635 499 Park Avenue 636 New York, NY 10022 637 USA 638 Phone: 212.940.1812 639 Email: aisaac@bloomberg.com 641 Tim Chown 642 School of Electronics and Computer Science 643 University of Southampton 644 Southampton SO17 1BJ 645 United Kingdom 646 Email: tjc@ecs.soton.ac.uk 648 Jordi Palet Martinez 649 Consulintel 650 San Jose Artesano, 1 651 Madrid, SPAIN 652 Phone: +34 91 151 81 99 653 Fax: +34 91 151 81 98 654 Email: jordi.palet@consulintel.es 656 Fred Templin 657 Nokia 658 313 Fairchild Drive 659 Mountain View, CA 94043 660 USA 661 Phone: 650.625.2331 662 Email: ftemplin@iprg.nokia.com 664 Roy Brabson 665 IBM 666 PO BOX 12195 667 3039 Cornwallis Road 668 Research Triangle Park, NC 27709 669 USA 670 Phone: +1 919 254 7332 671 Email: rbrabson@us.ibm.com 673 Intellectual Property Statement 675 The IETF takes no position regarding the validity or scope of any 676 intellectual property or other rights that might be claimed to 677 pertain to the implementation or use of the technology described in 678 this document or the extent to which any license under such rights 679 might or might not be available; neither does it represent that it 680 has made any effort to identify any such rights. Information on the 681 IETF's procedures with respect to rights in standards-track and 682 standards-related documentation can be found in BCP-11. Copies of 683 claims of rights made available for publication and any assurances of 684 licenses to be made available, or the result of an attempt made to 685 obtain a general license or permission for the use of such 686 proprietary rights by implementors or users of this specification can 687 be obtained from the IETF Secretariat. 689 The IETF invites any interested party to bring to its attention any 690 copyrights, patents or patent applications, or other proprietary 691 rights which may cover technology that may be required to practice 692 this standard. Please address the information to the IETF Executive 693 Director. 695 Full Copyright Statement 697 Copyright (C) The Internet Society (2002). All Rights Reserved. 699 This document and translations of it may be copied and furnished to 700 others, and derivative works that comment on or otherwise explain it 701 or assist in its implementation may be prepared, copied, published 702 and distributed, in whole or in part, without restriction of any 703 kind, provided that the above copyright notice and this paragraph are 704 included on all such copies and derivative works. However, this 705 document itself may not be modified in any way, such as by removing 706 the copyright notice or references to the Internet Society or other 707 Internet organizations, except as needed for the purpose of 708 developing Internet standards in which case the procedures for 709 copyrights defined in the Internet Standards process must be 710 followed, or as required to translate it into languages other than 711 English. 713 The limited permissions granted above are perpetual and will not be 714 revoked by the Internet Society or its successors or assigns. 716 This document and the information contained herein is provided on an 717 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 718 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 719 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 720 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 721 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 723 Acknowledgement 725 Funding for the RFC Editor function is currently provided by the 726 Internet Society.