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