idnits 2.17.1 draft-ietf-v6ops-ent-scenarios-02.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 17 longer pages, the longest (page 6) being 85 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. 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 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-02.txt Hewlett Packard 4 Obsoletes: draft-ietf-v6ops-ent-scenarios-01.txt 5 Expires: November 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.................................8 53 4. Support for Legacy IPv4 Nodes and Applications.............10 54 4.1 IPv4 Tunnels to Encapsulate IPv6..........................10 55 4.2 IPv6 Tunnels to Encapsulate IPv4..........................10 56 4.3 IPv6 only communicating with IPv4.........................11 57 5. Network Infrastructure Component Requirements..............11 58 5.1 DNS.......................................................11 59 5.2 Routing...................................................11 60 5.3 Autoconfiguration.........................................12 61 5.4 Security..................................................12 62 5.5 Applications..............................................12 63 5.6 Network Management........................................12 64 5.7 Address Planning..........................................12 65 5.8 Multicast..................................................13 66 5.9 Multihoming................................................13 67 6. Security Considerations....................................13 68 7. References.................................................13 69 7.1 Normative References......................................14 70 7.2 Non-Normative References..................................14 71 Document Acknowledgments.......................................14 72 Authors-Design Team Contact Information........................15 73 Intellectual Property Statement................................16 74 Full Copyright Statement.......................................17 75 Acknowledgement................................................17 76 1. Introduction 78 This document describes the scenarios for IPv6 deployment within 79 enterprise networks. It will focus upon an enterprise set of network 80 base scenarios with assumptions, coexistence with legacy IPv4 nodes, 81 networks, and applications, and network infrastructure requirements. 82 These requirements will be used to provide analysis to determine a 83 set of enterprise solutions in a later document. 85 The audience for this document is the enterprise network team 86 considering deployment of IPv6. The document will be useful for 87 enterprise teams that will have to determine the IPv6 transition 88 strategy for their enterprise. It is expected those teams include 89 members from management, network operations, and engineering. The 90 scenarios presented provide an example set of cases the enterprise 91 can use to build an IPv6 network scenario. 93 To frame the discussion, the document will describe a set of 94 scenarios and network infrastructure for each scenario. It is 95 impossible to define every possible enterprise scenario that will 96 apply to IPv6 adoption and transition. 98 Each enterprise will select the transition that best supports their 99 business requirements. Any attempt to define a default or one-size- 100 fits-all transition scenario, will simply not work. This document 101 does not try to depict the drivers for adoption of IPv6 by an 102 enterprise. 104 While it is difficult to quantify all the scenarios for an enterprise 105 network team to plan for IPv6, it is possible to depict a set of 106 abstract scenarios that will assist with planning. The document 107 presents three base scenarios as a general use case to be used as a 108 model as input for the enterprise to define specific scenarios. 110 The first scenario assumes the enterprise decides to deploy IPv6 in 111 conjunction with IPv4. The second scenario assumes the enterprise 112 decides to deploy IPv6 because of a specific set of applications the 113 enterprise wants to use over an IPv6 network. The third scenario 114 assumes an enterprise is building a new network or re-structuring an 115 existing network and decides to deploy IPv6 as the predominant 116 protocol within the enterprise coexisting with IPv4. The document 117 then defines a set of network infrastructure components that must be 118 analyzed. 120 The document then provides three specific scenario examples using the 121 network infrastructure components to depict the requirements. These 122 are common enterprise deployment cases to depict the challenges for 123 the enterprise to transition a network to IPv6. 125 The document then discusses the issues of supporting legacy functions 126 on the network, while the transition is in process, and the network 127 infrastructure components required to be analyzed by the enterprise. 128 The interoperation with legacy functions within the enterprise will 129 be required for all transition except possibly by a new network that 130 will be IPv6 from inception. The network infrastructure components 131 will depict functions in their networks that require consideration 132 for IPv6 deployment and transition. 134 Using the scenarios, network infrastructure components, and examples 135 in the document an enterprise can define its specific scenario 136 requirements. Understanding the legacy functions and network 137 infrastructure components required, the enterprise can determine the 138 network operations required to deploy IPv6. The tools and mechanisms 139 to support IPv6 deployment operations will require enterprise 140 analysis. The analysis to determine the tools and mechanisms to 141 support the scenarios will be presented in subsequent document(s). 143 2. Terminology 145 Enterprise Network - A network that has multiple internal links, 146 one or more router connections, to one or 147 more 148 Providers and is actively managed by a 149 network 150 operations entity. 152 Provider - An entity that provides services and 153 connectivity to the Internet or 154 other private external networks for the 155 enterprise network. 157 IPv6 Capable - A node or network capable of supporting both 158 IPv6 and IPv4. 160 IPv4 only - A node or network capable of supporting only 161 IPv4. 163 IPv6 only - A node or network capable of supporting only 164 IPv6. This does not imply an IPv6 only 165 stack, in this document. 167 3. Base Scenarios 169 Three base scenarios are defined to capture the essential abstraction 170 set for the enterprise. Each scenario has assumptions and 171 requirements. This is not an exhaustive set of scenarios, but a base 172 set of general cases. 174 Below we use the term network infrastructure to mean the software, 175 network operations and configuration, and the methods used to operate 176 a network in an enterprise. 178 3.1 Base Scenarios Defined 180 Scenario 1: Enterprise with an existing IPv4 network wants to deploy 181 IPv6 in conjunction with their IPv4 network. 183 Assumptions: The IPv4 network infrastructure used has an equivalent 184 capability in IPv6. 186 Requirements: Do not disrupt existing IPv4 network infrastructure 187 assumptions with IPv6. IPv6 should be equivalent or 188 "better" than the network infrastructure in IPv4, 189 however, it is understood that IPv6 is not required 190 to 191 solve current network infrastructure problems, 192 not solved by IPv4. It may also not be feasible to 193 deploy IPv6 on all parts of the network immediately. 195 Scenario 2: Enterprise with an existing IPv4 network wants to deploy 196 a 197 set of particular IPv6 "applications" (application is 198 voluntarily loosely defined here, e.g. peer to peer). 199 The IPv6 deployment is limited to the minimum required 200 to 201 operate this set of applications. 203 Assumptions: IPv6 software/hardware components for the application 204 are available, and platforms for the application 205 are IPv6 capable. 207 Requirements: Do not disrupt IPv4 infrastructure. 209 Scenario 3: Enterprise deploying a new network or re-structuring an 210 existing network, decides IPv6 is the basis for 211 most network communication, to coexist with IPv4. 213 Assumptions: Required IPv6 network infrastructure is available, or 214 available over some defined timeline, supporting the 215 enterprise plan. 217 Requirements: Interoperation and Coexistence with IPv4 network 218 network infrastructure and applications are required 219 for 220 communications. 222 3.2 Scenarios Network Infrastructure Components 224 This section defines the network infrastructure that exist for the 225 above enterprise scenarios. This is not an exhaustive list, but a 226 base list that can be expanded by the enterprise for specific 227 deployment scenarios. The network infrastructure components are 228 presented as functions that the enterprise must analyze as part of 229 defining their specific scenario. The analysis of these functions 230 will identify actions that are required to deploy IPv6. 232 Network Infrastructure Component 1 233 Enterprise Provider Requirements 234 - Is external connectivity required? 235 - One site vs. multiple sites? 236 - Leased lines or VPN? 237 - How many global IPv4 addresses are available to the 238 enterprise? 239 - What is the IPv6 address assignment plan available 240 from the provider? 241 - Will clients be Multihomed? 242 - Does the provider offer any IPv6 services? 243 - What site external IPv6 routing protocols are required? 244 - Is there an external data-center? 246 Network Infrastructure Component 2 247 Enterprise Application Requirements 248 - List of applications in use? 249 - Which applications must be moved to support IPv6 first? 250 - Can the application be upgraded to IPv6? 251 - Will the application have to support both IPv4 and IPv6? 252 - Do the enterprise platforms support both IPv4 and IPv6? 253 - Do the applications have issues with NAT v4-v4 and NAT v4-v6? 254 - Do the applications need globally routable IP addresses? 255 - Do the applications care about dependency between IPv4 and IPv6 256 addresses? 258 Network Infrastructure Component 3 259 Enterprise IT Department Requirements 260 - Who "owns"/"operates" the network: in house, or outsourced? 261 - Is a Tele-commuter work force supported? 262 - Is inter-site communications required? 263 - Is network mobility used or required for IPv6? 264 - What are the requirements of the IPv6 address plan? 265 - What will be the internal IPv6 address assignment procedure? 266 - What site internal IPv6 routing protocols are required? 267 - What will be the IPv6 Network Management policy/procedure? 268 - What will be the IPv6 QOS policy/procedure? 269 - What will be the IPv6 Security policy/procedure? 270 - What is the IPv6 training plan to educate the enterprise? 271 - What network operations software will be impacted by IPv6? 272 - DNS 273 - Management (SNMP & ad-hoc tools) 274 - Enterprise Network Servers Applications 275 - Mail Servers 276 - High Availability Software for Nodes 277 - Directory Services 278 - Are all these software functions upgradeable to IPv6? 279 - If not upgradeable, then what are the workarounds? 280 - Do any of the software functions store, display, or 281 allow input of IP addresses? 282 - Other services (e.g. NTP, etc.........) 283 - What network hardware will be impacted by IPv6 284 - Routers/switches 285 - Printers/Faxes 286 - Firewalls 287 - Intrusion Detection 288 - Load balancers 289 - VPN Points of Entry/Exit 290 - Security Servers and Services 291 - Network Interconnect for Platforms 292 - Intelligent Network Interface Cards 293 - Network Storage Devices 294 - Are all these hardware functions upgradeable to IPv6? 295 - If not, what are the workarounds? 296 - Do any of the hardware functions store, display, or 297 allow input of IP addresses? 298 - Are the nodes moving within the enterprise network? 299 - Are the nodes moving outside and inside the enterprise 300 network? 302 Network Infrastructure Component 4 303 Enterprise Network Management System 304 - Performance Management Required? 305 - Network Management Applications Required? 306 - Configuration Management Required? 307 - Policy Management and Enforcement Required? 308 - Security Management Required? 309 - Management of Transition Tools and Mechanisms? 310 - What new considerations does IPv6 create for Network 311 Management? 313 Network Infrastructure Component 5 314 Enterprise Network Interoperation and Coexistence 315 - What platforms are required to be IPv6 capable? 316 - What network ingress and egress points to the site are 317 required to be IPv6 capable? 318 - What transition mechanisms are needed to support IPv6 319 network operations? 320 - What policy/procedures are required to support the 321 transition to IPv6? 322 - What policy/procedures are required to support 323 interoperation with legacy nodes and applications? 325 3.3 Specific Scenario Examples 327 This section presents a set of base scenario examples and is not an 328 exhaustive list of examples. These examples were selected to provide 329 further clarity for base scenarios within an enterprise of a less 330 abstract nature. 332 Example Network A: 334 A distributed network across a number of geographically separated 335 campuses. 337 - External network operation. 338 - External connectivity required. 339 - Multiple sites connected by leased lines. 340 - Provider independent IPv4 addresses. 341 - ISP does not offer IPv6 service. 342 - Private Leased Lines no Service Provider Used 344 Applications run by the enterprise: 346 - Internal Web/Mail. 347 - File servers. 348 - Java applications. 349 - Collaborative development tools. 350 - Enterprise Resource Applications. 351 - Multimedia Applications. 352 - Financial Enterprise Applications. 353 - Data Warehousing Applications. 355 Internal network operation: 357 - In house operation of the network. 358 - DHCP (v4) is used for all desktops, servers use static address 359 configuration. 360 - The DHCP server to update naming records for dynamic desktops 361 uses 362 dynamic DNS. 363 - A web based tool is used to enter name to address mappings for 364 statically addressed servers. 365 - Network management is done using SNMP. 366 - All routers and switches are upgradeable to IPv6. 367 - Existing firewalls can be upgraded to support IPv6 rules. 368 - Load balancers do not support IPv6, upgrade path unclear. 369 - Peer-2-Peer Application and Security supported. 370 - IPv4 Private address space is used within the enterprise. 372 Example Network B: 374 A bank running a large network supporting online transaction 375 processing (OLTP) across a distributed multi-sited network, with 376 access 377 to a central database on an external network from the OLTP network: 379 - External connectivity not required. 380 - Multiple sites connected by VPN. 381 - Multiple sites connected by Native IP protocol. 382 - Private address space used with NAT. 383 - Connections to private exchanges. 385 Applications in the enterprise: 386 - ATM transaction application. 387 - ATM management application. 388 - Financial Software and Database. 389 - Part of the workforce is mobile and requires access to the 390 enterprise from outside networks. 392 Internal Network Operation: 393 - Existing firewalls can be upgraded to support IPv6 rules. 394 - Load balancers do not support IPv6, upgrade path unclear. 395 - Identifying and managing each nodes IP address. 397 Example Network C: 399 A Security Defense Network Operation: 401 - External network required at secure specific points. 402 - Network is its own Internet. 403 - Network must be able to absorb ad-hoc creation of sub-Networks. 404 - Entire parts of the Network are completely mobile. 405 - All nodes on the network can be mobile (including routers) 406 - Network True High-Availability is mandatory. 407 - Network must be able to be managed from ad-hoc location. 408 - All nodes must be able to be configured from stateless mode. 410 Applications run by the Enterprise: 411 - Multimedia streaming of audio, video, and data for all nodes. 412 - Data computation and analysis on stored and created data. 413 - Transfer of data coordinate points to sensor devices. 414 - Data and Intelligence gathering applications from all nodes. 416 Internal Network Operations: 417 - All packets must be secured end-2-end with encryption. 418 - Intrusion Detection exists on all network entry points. 419 - Network must be able to bolt on to the Internet to share 420 bandwidth as required from Providers. 421 - VPNs can be used but NAT can never be used. 422 - Nodes must be able to access IPv4 legacy applications over IPv6 423 network. 425 4. Support for Legacy IPv4 Nodes and Applications 427 The enterprise network will have to support the coexistence of IPv6 428 and IPv4, to support legacy IPv4 applications and nodes. This means 429 that some set of nodes will have to be IPv6 capable. The enterprise 430 user has the following choices for that coexistence to consider 431 today. 433 4.1 IPv4 Tunnels to Encapsulate IPv6 435 IPv6 capable nodes want to communicate using IPv6, but an IPv4 436 Internal router is between them. These nodes could also be Mobile 437 nodes on a visited network. 439 4.2 IPv6 Tunnels to Encapsulate IPv4 441 An IPv6 capable node, on an IPv6 link within an IPv6 routing domain, 442 wants to communicate with a legacy IPv4 application. 444 4.3 IPv6 only communicating with IPv4 446 An IPv6 capable node wants to communicate with an IPv4 service, but 447 the node is operating as IPv6 only. In order to continue support for 448 communications with IPv4 services an IPv6 to IPv4 translator or IPv6 449 proxy is required. Introduction of such software may prevent usage 450 of end-to-end security trust models and applications carrying 451 embedded IP addressing information. Bi-directional establishment of 452 connections might be difficult to achieve. 454 5. Network Infrastructure Component Requirements 456 The enterprise will need to determine what network infrastructure 457 components require enhancements or to be added for deployment of 458 IPv6. This infrastructure will need to be analyzed and understood as 459 a critical resource to manage. 461 5.1 DNS 463 DNS will now have to support both IPv4 and IPv6 DNS records and the 464 enterprise will need to determine how the DNS is to be managed and 465 accessed, and secured. The range of DNS operational issues are out 466 of scope for this work. Users need to consider all current DNS IPv4 467 operations and determine if those operations are supported for IPv6. 468 However, DNS resolution and transport solutions for both IP protocols 469 are influenced by the chosen IPv6 deployment scenario. Users need to 470 consider all current DNS IPv4 operations and determine if those 471 operations are supported for IPv6. 473 5.2 Routing 475 Interior and Exterior routing will be required to support both IPv4 476 and IPv6 routing protocols, and the coexistence of IPv4 and IPv6 over 477 the enterprise network. The enterprise will need to define the IPv6 478 routing topology, any ingress and egress points to provider networks, 479 and transition mechanisms they wish to use for IPv6 adoption. The 480 enterprise will also need to determine what IPv6 transition 481 mechanisms are supported by their upstream providers. 483 The choice of interior routing protocols have an impact on how the 484 routing tables will be handled: some such as OSPF will have the 485 ships-in-the-night paradigm, others such as ISIS are integrated. This 486 has an impact on the topology and the management of the network. 488 IPv6 capable routers should be monitored to ensure the router has 489 sufficient storage for both IPv6 and IPv4 route tables. Existing 490 network design principles to limit the number of routes in the 491 network, such as prefix aggregation, become more critical with the 492 addition of IPv6 to an existing IPv4 network. 494 5.3 Autoconfiguration 496 IPv6 introduces the concept of stateless autoconfiguration in 497 addition to stateful autoconfiguration. The enterprise will have to 498 determine the best method of autoconfiguration, for their network. 499 The enterprise will need to determine if they are to use stateless or 500 stateful autoconfiguration, and how autoconfiguration is to operate 501 for DNS updates. The enterprise will need to determine how prefix 502 delegation is done from their upstream provider and how those 503 prefixes are cascaded down to the enterprise IPv6 network. The 504 policy for DNS or choice of autoconfiguration is out of scope for 505 this document. 507 5.4 Security 509 Current existing mechanisms used for IPv4 to provide security need to 510 be supported for IPv6 within the enterprise. IPv6 should create no 511 new security concerns for IPv4. The entire security infrastructure 512 currently used in the enterprise needs to be analyzed against IPv6 513 deployment effect and determine what is supported in IPv6. Users 514 should review other security IPv6 network infrastructure work in the 515 IETF and within the industry on going at this time. Users will have 516 to work with their platform and software providers to determine what 517 IPv6 security network infrastructure components are supported. The 518 security filters and firewall requirments for IPv6 need to be 519 determined by the enterprise. The policy choice of users for security 520 is out of scope for this document. 522 5.5 Applications 524 Existing applications will need to be ported or proxyed to support 525 both IPv4 and IPv6. 527 5.6 Network Management 529 The addition of IPv6 network infrastructure components will need to 530 be managed by the enterprise network operations center. Users will 531 need to work with their network management platform providers to 532 determine what for IPv6 is supported during their planning for IPv6 533 adoption, and what tools are available in the market to monitor the 534 network. 536 5.7 Address Planning 538 The address space within the enterprise will need to be defined and 539 coordinated with the routing topology of the enterprise network. It 540 is also important to identify the pool of IPv4 address space 541 available to the enterprise to assist with IPv6 transition methods. 543 5.8 Multicast 545 Enterprises utilising IPv4 Multicast services will need to consider 546 how these services may be presented in an IPv6-enabled environment. 547 First, the Multicast routing protocols will need to be considered; 548 those such as PIM-SM may operate similarly under either protocol, but 549 in IPv6 nodes will need to support the Multicast Listener Discovery 550 protocol. 552 Nodes wishing to utilise Source Specific Multicast (SSM) will need to 553 support Multicast Listener Discovery protocol v2 (MLDv2). In 554 addition, applications written for PIM-SM may need to be modified to 555 use SSM. 557 For inter-domain multicast, IPv6 has no equivalent of Multicast 558 Source Discovery Protocol (MSDP); alternative methods are being 559 designed within the IETF, e.g. by embedding the Rendezvous Point 560 address in the multicast group address. 562 For inter-domain use, sites may choose to migrate IPv4 multicast 563 applications to SSM, for which no reverse path discovery method is 564 required. 566 5.9 Multihoming 568 At this time, current IPv6 allocation policies are mandating the 569 allocation of IPv6 address space from the upstream provider. If an 570 enterprise is multihomed, the enterprise will have to determine how 571 they wish to support multihoming. This also is an area of study 572 within the IETF and work in progress. 574 6. Security Considerations 576 This document lists scenarios for the deployment of IPv6 in 577 enterprise networks, and there are no security considerations 578 associated with making such a list. 580 There will security considerations for the deployment of IPv6 in each 581 of these scenarios, but they will be addressed in the document that 582 includes the analysis of each scenario. 584 7. References 585 7.1 Normative References 587 None at this time. 589 7.2 Non-Normative References 591 None at this time. 593 Document Acknowledgments 595 The Authors would like to acknowledge contributions from the 596 following: IETF v6ops Working Group, Alan Beard, Brian Carpenter, 597 Alain Durand, and Bob Hinden. 599 Authors-Design Team Contact Information 601 Send email to ent-v6net@viagenie.qc.ca to contact the design team and 602 send comments on the draft to v6ops@ops.ietf.org. 604 Yanick Pouffary (Chair of Design Team) 605 HP Competency Center 606 950, Route des Colles, BP027, 607 06901 Sophia Antipolis CEDEX 608 FRANCE 609 Phone: + 33492956285 610 Email: Yanick.pouffary@hp.com 612 Jim Bound (Editor) 613 Hewlett Packard 614 110 Spitbrook Road 615 Nashua, NH 03062 616 USA 617 Phone: 603.884.0062 618 Email: jim.bound@hp.co 620 Marc Blanchet 621 Viagenie inc. 622 2875 boul. Laurier, bur. 300 623 Ste-Foy, Quebec, Canada, G1V 2M2 624 EMail: Marc.Blanchet@viagenie.qc.ca 626 Tony Hain 627 Cisco Systems 628 500 108th Ave. N.E. Suite 400 629 Bellevue, Wa. 98004 630 Email: alh-ietf@tndh.net 632 Paul Gilbert 633 Cisco Systems 634 1 Penn Plaza, 5th floor, 635 NY, NY 10119 636 USA 637 Phone: 212.714.4334 638 Email: pgilbert@cisco.com 640 Margaret Wasserman 641 Nokia 642 5 Wayside Road 643 Burlington, MA 01803 644 US 645 Phone: +1 781 993 4900 646 EMail: margaret.wasserman@nokia.com 647 URI: http://www.nokia.com/ 649 Jason Goldschmidt 650 Sun Microsystems 651 M/S UMPK17-103 652 17 Network Circle 653 Menlo Park, CA 94025 654 USA 655 Phone: (650)-786-3502 656 Fax: (650)-786-8250 657 Email:jason.goldschmidt@sun.com 659 Aldrin Isaac 660 Bloomberg L.P. 661 499 Park Avenue 662 New York, NY 10022 663 USA 664 Phone: 212.940.1812 665 Email: aisaac@bloomberg.com 667 Tim Chown 668 School of Electronics and Computer Science 669 University of Southampton 670 Southampton SO17 1BJ 671 United Kingdom 672 Email: tjc@ecs.soton.ac.uk 674 Jordi Palet Martinez 675 Consulintel 676 San Jose Artesano, 1 677 Madrid, SPAIN 678 Phone: +34 91 151 81 99 679 Fax: +34 91 151 81 98 680 Email: jordi.palet@consulintel.es 682 Fred Templin 683 Nokia 684 313 Fairchild Drive 685 Mountain View, CA 94043 686 USA 687 Phone: 650.625.2331 688 Email: ftemplin@iprg.nokia.com 690 Roy Brabson 691 IBM 692 PO BOX 12195 693 3039 Cornwallis Road 694 Research Triangle Park, NC 27709 695 USA 696 Phone: +1 919 254 7332 697 Email: rbrabson@us.ibm.com 699 Intellectual Property Statement 701 The IETF takes no position regarding the validity or scope of any 702 intellectual property or other rights that might be claimed to 703 pertain to the implementation or use of the technology described in 704 this document or the extent to which any license under such rights 705 might or might not be available; neither does it represent that it 706 has made any effort to identify any such rights. Information on the 707 IETF's procedures with respect to rights in standards-track and 708 standards-related documentation can be found in BCP-11. Copies of 709 claims of rights made available for publication and any assurances of 710 licenses to be made available, or the result of an attempt made to 711 obtain a general license or permission for the use of such 712 proprietary rights by implementors or users of this specification can 713 be obtained from the IETF Secretariat. 715 The IETF invites any interested party to bring to its attention any 716 copyrights, patents or patent applications, or other proprietary 717 rights which may cover technology that may be required to practice 718 this standard. Please address the information to the IETF Executive 719 Director. 721 Full Copyright Statement 723 Copyright (C) The Internet Society (2002). All Rights Reserved. 725 This document and translations of it may be copied and furnished to 726 others, and derivative works that comment on or otherwise explain it 727 or assist in its implementation may be prepared, copied, published 728 and distributed, in whole or in part, without restriction of any 729 kind, provided that the above copyright notice and this paragraph are 730 included on all such copies and derivative works. However, this 731 document itself may not be modified in any way, such as by removing 732 the copyright notice or references to the Internet Society or other 733 Internet organizations, except as needed for the purpose of 734 developing Internet standards in which case the procedures for 735 copyrights defined in the Internet Standards process must be 736 followed, or as required to translate it into languages other than 737 English. 739 The limited permissions granted above are perpetual and will not be 740 revoked by the Internet Society or its successors or assigns. 742 This document and the information contained herein is provided on an 743 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 744 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 745 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 746 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 747 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 749 Acknowledgement 751 Funding for the RFC Editor function is currently provided by the 752 Internet Society.