IPv6 Operations Working Group
Internet Draft                                    Jim Bound (Editor)
Document: draft-ietf-v6ops-ent-scenarios-04.txt draft-ietf-v6ops-ent-scenarios-05.txt      Hewlett Packard
Obsoletes: draft-ietf-v6ops-ent-scenarios-03.txt draft-ietf-v6ops-ent-scenarios-04.txt
Expires: January 2005

                 IPv6 Enterprise Network Scenarios



Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10
   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of RFC2026.

   This document is a submission by the Internet Protocol IPv6
   Working Group which I am aware have been
   disclosed, and any of the Internet Engineering Task Force (IETF).
   Comments should which I become aware will be submitted to the ipng@sunroof.eng.sun.com
   mailing list. disclosed, in
   accordance with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as "work
   in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


 This document describes the scenarios for IPv6 deployment within
 enterprise networks.  It defines a small set of basic enterprise
 scenarios and includes pertinent questions to allow enterprise
 administrators to further refine their deployment scenarios.
 Enterprise deployment requirements are discussed in terms of
 coexistence with IPv4 nodes, networks and applications, and in
 terms of basic network infrastructure requirements for IPv6
 deployment.  The scenarios and requirements described in this
 document will be the basis for further analysis to determine what
 coexistence techniques and mechanisms are needed for enterprise
 IPv6 deployment.  The results of that analysis will be published in
 a separate document.

Table of Contents:

1.  Introduction................................................3
2.  Terminology.................................................5
3.  Base Scenarios..............................................6
3.1  Base Scenarios Defined.....................................7
3.2  Scenarios Network Infrastructure Components................8
3.3  Specific Scenario Examples................................10
3.4  Applicability Statement...................................12
4.  Network Infrastructure Component Requirements..............12
4.1  DNS.......................................................12
4.2  Routing...................................................13
4.3  Configuration of Hosts....................................13
4.4  Security..................................................13
4.5  Applications..............................................13
4.6  Network Management........................................14
4.7  Address Planning..........................................14
4.8 Multicast..................................................14
4.9 Multihoming................................................14
5.  Security Considerations....................................14
6.  References.................................................14
6.1  Normative References......................................15
6.2  Non-Normative References..................................15
Document Acknowledgments.......................................15
Author's Address...............................................16
Intellectual Property Statement................................17
Full and Copyright Statement.......................................18
Acknowledgement................................................18 Statements.................17

1.  Introduction

 This document describes the scenarios for IPv6 deployment within
 enterprise networks.  It defines a small set of basic enterprise
 scenarios and includes pertinent questions to allow enterprise
 administrators to further refine their deployment scenarios.
 Enterprise deployment requirements are discussed in terms of
 coexistence with IPv4 nodes, networks and applications, and in
 terms of basic network infrastructure requirements for IPv6
 deployment.  The scenarios and requirements described in this
 document will be the basis for further analysis to determine what
 coexistence techniques and mechanisms are needed for enterprise
 IPv6 deployment.  The results of that analysis will be published in
 a separate document.

 The audience for this document is the enterprise network team
 considering deployment of IPv6.  The document will be useful for
 enterprise teams that will have to determine the IPv6 transition
 strategy for their enterprise.  It is expected those teams include
 members from management, network operations, and engineering. The
 scenarios presented provide an example set of cases the enterprise
 can use to build an IPv6 network scenario.

 To frame the discussion, the document will describe a set of
 scenarios and network infrastructure for each scenario. It is
 impossible to define every possible enterprise scenario that will
 apply to IPv6 adoption and transition.

 Each enterprise will select the transition that best supports their
 business requirements. Any attempt to define a default or one-
 size-fits-all transition scenario, will simply not work. This
 document does not try to depict the drivers for adoption of IPv6 by
 an enterprise.

 While it is difficult to quantify all the scenarios for an
 enterprise network team to plan for IPv6, it is possible to depict
 a set of abstract scenarios that will assist with planning. The
 document presents three base scenarios as a general use case to be
 used as a model as input for the enterprise to define specific

 The first scenario assumes the enterprise decides to deploy IPv6 in
 conjunction with IPv4.  The second scenario assumes the enterprise
 decides to deploy IPv6 because of a specific set of applications
 the enterprise wants to use over an IPv6 network.  The third
 scenario assumes an enterprise is building a new network or re-
 structuring an existing network and decides to deploy IPv6 as the
 predominant protocol within the enterprise coexisting with IPv4.
 The document then briefly reviews a set of network infrastructure
 components that must be analyzed, which are common to most

 The document then provides three specific scenario examples using
 the network infrastructure components to depict the requirements.
 These are common enterprise deployment cases to depict the
 challenges for the enterprise to transition a network to IPv6.

 The document then discusses the issues of supporting legacy
 functions on the network, while the transition is in process, and
 the network infrastructure components required to be analyzed by
 the enterprise.  The interoperation with legacy functions within
 the enterprise will be required for all transition except possibly
 by a new network that will be IPv6 from inception.  The network
 infrastructure components will depict functions in their networks
 that require consideration for IPv6 deployment and transition.

 Using the scenarios, network infrastructure components, and
 examples in the document an enterprise can define its specific
 scenario requirements. Understanding the legacy functions and
 network infrastructure components required, the enterprise can
 determine the network operations required to deploy IPv6. The tools
 and mechanisms to support IPv6 deployment operations will require
 enterprise analysis.  The analysis to determine the tools and
 mechanisms to support the scenarios will be presented in subsequent

2.  Terminology

 Enterprise Network - A network that has multiple internal links,
                      one or more router connections, to one or
                      more Providers and is actively managed by a
                      network operations entity.

 Provider           - An entity that provides services and
                      connectivity to the Internet or
                      other private external networks for the
                      enterprise network.

 IPv6 Capable       - A node or network capable of supporting both
                      IPv6 and IPv4.

 IPv4 only          - A node or network capable of supporting only

 IPv6 only          - A node or network capable of supporting only
                      IPv6.  This does not imply an IPv6 only
                      stack, in this document.

3.  Base Scenarios

 Three base scenarios are defined to capture the essential
 abstraction set for the enterprise. Each scenario has assumptions
 and requirements. This is not an exhaustive set of scenarios, but a
 base set of general cases.

 Below we use the term network infrastructure to mean the software,
 network operations and configuration, and the methods used to
 operate a network in an enterprise.

 At this time it is assumed for the base scenarios that any IPv6
 node is IPv6 capable.

3.1  Base Scenarios Defined

 Scenario 1:   Wide-scale/total dual-stack deployment of IPv4
               and IPv6 capable hosts and network infrastructure.
               Enterprise with an existing IPv4 network wants to
               deploy IPv6 in conjunction with their IPv4 network.

 Assumptions:  The IPv4 network infrastructure used has an
               equivalent capability in IPv6.

 Requirements: Do not disrupt existing IPv4 network
               infrastructure assumptions with IPv6. IPv6
               should be equivalent or "better" than the
               network infrastructure in IPv4, however, it
               is understood that IPv6 is not required to
               solve current network infrastructure problems,
               not solved by IPv4. It may also not be feasible
               to deploy IPv6 on all parts of the network

 Scenario 2:   Sparse IPv6 dual-stack deployment in IPv4 network
               infrastructure.  Enterprise with an existing IPv4
               network wants to deploy a set of particular IPv6
               "applications" (application is voluntarily loosely
               defined here, e.g. peer to peer). The IPv6
               deployment is limited to the minimum required to
               operate this set of applications.

 Assumptions:  IPv6 software/hardware components for the
               application are available, and platforms for the
               application are IPv6 capable.

 Requirements: Do not disrupt IPv4 infrastructure.

 Scenario 3:   IPv6-only network infrastructure with some
               IPv4-capable nodes/applications needing to
               communicate over the IPv6 infrastructure.
               Enterprise deploying a new network or
               re-structuring an existing network, decides IPv6
               is the basis for most network communication.
               Some IPv4 capable nodes/applications will need
               to communicate over that infrastructure.

 Assumptions:  Required IPv6 network infrastructure is available,
               or available over some defined timeline,
               supporting the enterprise plan.

 Requirements: Interoperation and Coexistence with IPv4 network
               network infrastructure and applications are
               required for communications.

3.2  Scenarios Network Infrastructure Components

 This section defines the network infrastructure that exists for the
 above enterprise scenarios.  This is not an exhaustive list, but a
 base list that can be expanded by the enterprise for specific
 deployment scenarios. The network infrastructure components are
 presented as functions that the enterprise must analyze as part of
 defining their specific scenario. The analysis of these functions
 will identify actions that are required to deploy IPv6.

 Network Infrastructure Component 1
  Enterprise Provider Requirements
   - Is external connectivity required?
   - One site vs. multiple sites and are they within
     different geographies?
   - Leased lines or VPNs?
   - If multiple sites, how is the traffic exchanged
   - How many global IPv4 addresses are available to the
   - What is the IPv6 address assignment plan available
     from the provider?
   - What prefix delegation is required by the Enterprise?
   - Will the enterprise be multihomed?
   - What multihoming techniques are available from the
   - Will clients within the enterprise be multihomed?
   - Does the provider offer any IPv6 services?
   - What site external IPv6 routing protocols are required?
   - Is there an external data-center to the enterprise,
     such as servers located at the Provider?
   - Is IPv6 available using the same access links as IPv4,
     or different ones?

 Network Infrastructure Component 2
  Enterprise Application Requirements
   - List of applications in use?
   - Which applications must be moved to support IPv6 first?
   - Can the application be upgraded to IPv6?
   - Will the application have to support both IPv4 and IPv6?
   - Do the enterprise platforms support both IPv4 and IPv6?
   - Do the applications have issues with NAT v4-v4 and
     NAT v4-v6?
   - Do the applications need globally routable IP addresses?
   - Do the applications care about dependency between IPv4
     and IPv6 addresses?
   - Are applications run only on the internal enterprise

 Network Infrastructure Component 3
  Enterprise IT Department Requirements
   - Who "owns"/"operates" the network: in house, or
   - Is working remotely (e.g., through VPNs) supported?
   - Is inter-site communications required?
   - Is network mobility used or required for IPv6?
   - What are the requirements of the IPv6 address plan?
   - Is there a detailed asset management database, including
     hosts, IP/MAC addresses, etc.?
   - What is the enterprise' approach to numbering
     geographically separate sites which have their own
     Service Providers?
   - What will be the internal IPv6 address assignment
   - What site internal IPv6 routing protocols are required?
   - What will be the IPv6 Network Management
   - What will be the IPv6 QOS policy/procedure?
   - What will be the IPv6 Security policy/procedure?
   - What is the IPv6 training plan to educate the enterprise?
   - What network operations software will be impacted by IPv6?
    - DNS
    - Management (SNMP & ad-hoc tools)
    - Enterprise Network Servers Applications
    - Mail Servers
    - High Availability Software for Nodes
    - Directory Services
    - Are all these software functions upgradeable to IPv6?
    - If not upgradeable, then what are the workarounds?
    - Do any of the software functions store, display, or
      allow input of IP addresses?
    - Other services (e.g. NTP, etc.........)
   - What network hardware will be impacted by IPv6?
    - Routers/switches
    - Printers/Faxes
    - Firewalls
    - Intrusion Detection
    - Load balancers
    - VPN Points of Entry/Exit
    - Security Servers and Services
    - Network Interconnect for Platforms
    - Intelligent Network Interface Cards
    - Network Storage Devices
    - Are all these hardware functions upgradeable to IPv6?
    - If not, what are the workarounds?
    - Do any of the hardware functions store, display, or
      allow input of IP addresses?
   - Are the nodes moving within the enterprise network?
   - Are the nodes moving outside and inside the enterprise

 Network Infrastructure Component 4
  Enterprise Network Management System
   - Performance Management Required?
   - Network Management Applications Required?
   - Configuration Management Required?
   - Policy Management and Enforcement Required?
   - Security Management Required?
   - Management of Transition Tools and Mechanisms?
   - What new considerations does IPv6 create for Network

 Network Infrastructure Component 5
  Enterprise Network Interoperation and Coexistence
   - What platforms are required to be IPv6 capable?
   - What network ingress and egress points to the site
     are required to be IPv6 capable?
   - What transition mechanisms are needed to support
     IPv6 network operations?
   - What policy/procedures are required to support the
     transition to IPv6?
   - What policy/procedures are required to support
     interoperation with legacy nodes and applications?

3.3  Specific Scenario Examples

 This section presents a set of base scenario examples and is not an
 exhaustive list of examples.  These examples were selected to
 provide further clarity for base scenarios within an enterprise of
 a less abstract nature.  The example networks may use the scenarios
 depicted in 3.1 and the infrastructure components in 3.2, but there
 is no direct implications specifically within these example
 networks.  Section 3.1, 3.2, and 3.3 should be used in unison for
 enterprise IPv6 deployment planning and analysis.

 Example Network A:

 A distributed network across a number of geographically
 separated campuses.

   - External network operation.
   - External connectivity required.
   - Multiple sites connected by leased lines.
   - Provider independent IPv4 addresses.
   - ISP does not offer IPv6 service.
   - Private Leased Lines no Service Provider Used

 Applications run by the enterprise:

   - Internal Web/Mail.
   - File servers.
   - Java applications.
   - Collaborative development tools.
   - Enterprise Resource Applications.
   - Multimedia Applications.
   - Financial Enterprise Applications.
   - Data Warehousing Applications.

 Internal network operation:

   - In house operation of the network.
   - DHCP (v4) is used for all desktops, servers use
     static address configuration.
   - The DHCP server updates naming records for dynamic
     desktops uses dynamic DNS.
   - A web based tool is used to enter name to address
     mappings for statically addressed servers.
   - Network management is done using SNMP.
   - All routers and switches are upgradeable to IPv6.
   - Existing firewalls can be upgraded to support IPv6
   - Load balancers do not support IPv6, upgrade path
   - Peer-2-Peer Application and Security supported.
   - IPv4 Private address space is used within the

 Example Network B:

 A bank running a large network supporting online
 transaction processing (OLTP) across a distributed
 multi-sited network, with access to a central database
 on an external network from the OLTP network.

   - External connectivity not required.
   - Multiple sites connected by VPN.
   - Multiple sites connected by Native IP protocol.
   - Private address space used with NAT.
   - Connections to private exchanges.

 Applications in the enterprise:
   - ATM transaction application.
   - ATM management application.
   - Financial Software and Database.
   - Part of the workforce is mobile and requires
     access to the enterprise from outside networks.

 Internal Network Operation:
   - Existing firewalls can be upgraded to support
     IPv6 rules.
   - Load balancers do not support IPv6, upgrade
     path unclear.
   - Identifying and managing each node's IP address.

 Example Network C:

 A Security Defense, Emergency, or other Mission
 Critical network operation:

   - External network required at secure specific points.
   - Network is its own Internet.
   - Network must be able to absorb ad-hoc creation of
   - Entire parts of the network are completely mobile.
   - All nodes on the network can be mobile
     (including routers)
   - Network high-availability is mandatory.
   - Network must be able to be managed from ad-hoc
   - All nodes must be able to be configured from stateless

 Applications run by the Enterprise:

   - Multimedia streaming of audio, video, and data for
     all nodes.
   - Data computation and analysis on stored and created

   - Transfer of data coordinate points to sensor devices.
   - Data and Intelligence gathering applications from all

 Internal Network Operations:
   - All packets must be secured end-2-end with encryption.
   - Intrusion Detection exists on all network entry points.
   - Network must be able to bolt on to the Internet to share
     bandwidth as required from Providers.
   - VPNs can be used but NAT can never be used.
   - Nodes must be able to access IPv4 legacy applications
     over IPv6 network.

3.4  Applicability Statement

 The specific network scenarios selected are chosen to depict a base
 set of examples, and to support further analysis of enterprise
 networks.  This is not a complete set of network scenarios.
 Regarding Example Network C, though this is a verifiable use case,
 at this time the scenario defines an early adopter of enterprise
 networks transitioning to IPv6 as a predominant protocol strategy
 (e.g.  IPv6 Routing, Applications, Security, and Operations),
 viewing IPv4 as legacy operations immediately in the transition
 strategy, and at this time may not be representative of many
 initial enterprise IPv6 deployments. Each enterprise planning team
 will need to make that determination as IPv6 deployment evolves.

4.  Network Infrastructure Component Requirements

 The enterprise will need to determine what network infrastructure
 components require enhancements or to be added for deployment of
 IPv6. This infrastructure will need to be analyzed and understood
 as a critical resource to manage.  The list in this section is not
 exhaustive but are the essential network infrastructure components
 to consider for the enterprise before they begin to define more
 fine tuned requirements such as QOS, PKI, or Bandwidth requirements
 for IPv6 as examples. The components are only identified here and
 the details of the components will be discussed in the analysis
 document for enterprise scenarios.  Where there are references at
 this time for a component they are provided.

4.1  DNS

 DNS will now have to support both IPv4 and IPv6 DNS records and the
 enterprise will need to determine how the DNS is to be managed and
 accessed, and secured.  The range of DNS operational issues are out
 of scope for this work.  Users need to consider all current DNS
 IPv4 operations and determine if those operations are supported for
 IPv6.  However, DNS resolution and transport solutions for both IP
 protocols are influenced by the chosen IPv6 deployment scenario.
 Users need to consider all current DNS IPv4 operations and
 determine if those operations are supported for IPv6 [DNSV6].

4.2  Routing

 Interior and Exterior routing will be required to support both IPv4
 and IPv6 routing protocols, and the coexistence of IPv4 and IPv6
 over the enterprise network.  The enterprise will need to define
 the IPv6 routing topology, any ingress and egress points to
 provider networks, and transition mechanisms they wish to use for
 IPv6 adoption. The enterprise will also need to determine what IPv6
 transition mechanisms are supported by their upstream providers.

4.3  Configuration of Hosts

 IPv6 introduces the concept of stateless autoconfiguration in
 addition to stateful autoconfiguration, for the configuration of
 hosts within the enterprise.  The enterprise will have to determine
 the best method of host configuration, for their network. The
 enterprise will need to determine if they are to use stateless or
 stateful autoconfiguration, and how autoconfiguration is to operate
 for DNS updates.  The enterprise will need to determine how prefix
 delegation is done from their upstream provider and how those
 prefixes are cascaded down to the enterprise IPv6 network.  The
 policy for DNS or choice of autoconfiguration is out of scope for
 this document. [CONF, DHCPF, DHCPL]

4.4  Security

 Current existing mechanisms used for IPv4 to provide security need
 to be supported for IPv6 within the enterprise.  IPv6 should create
 no new security concerns for IPv4.  The entire security
 infrastructure currently used in the enterprise needs to be
 analyzed against IPv6 deployment effect and determine what is
 supported in IPv6.  Users should review other security IPv6 network
 infrastructure work in the IETF and within the industry on going at
 this time.  Users will have to work with their platform and
 software providers to determine what IPv6 security network
 infrastructure components are supported. The security filters and
 firewall requirements for IPv6 need to be determined by the
 enterprise. The policy choice of users for security is out of scope
 for this document.

4.5  Applications

 Existing applications will need to be ported or provide proxies to
 support both IPv4 and IPv6 [APPS].

4.6  Network Management

 The addition of IPv6 network infrastructure components will need to
 be managed by the enterprise network operations center.  Users will
 need to work with their network management platform providers to
 determine what for IPv6 is supported during their planning for IPv6
 adoption, and what tools are available in the market to monitor the
 network.  Network management will not need to support both IPv4 and
 IPv6 and view nodes as dual stacks.

4.7  Address Planning

 The address space within the enterprise will need to be defined and
 coordinated with the routing topology of the enterprise network.
 It is also important to identify the pool of IPv4 address space
 available to the enterprise to assist with IPv6 transition methods.

4.8 Multicast

 Enterprises utilizing IPv4 Multicast services will need to consider
 how these services may be implemented operationally in an IPv6-
 enabled environment.

4.9 Multihoming

 At this time, current IPv6 allocation policies are mandating the
 allocation of IPv6 address space from the upstream provider. If an
 enterprise is multihomed, the enterprise will have to determine how
 they wish to support multihoming.  This also is an area of study
 within the IETF and work in progress.

5.  Security Considerations

 This document lists scenarios for the deployment of IPv6 in
 enterprise networks, and there are no security considerations
 associated with making such a list.

 There will be security considerations for the deployment of IPv6 in
 each of these scenarios, but they will be addressed in the document
 that includes the analysis of each scenario.

6.  References

6.1  Normative References

[DNSV6]  Durand, A., Ihren, J. and P. Savola, "Operational
         Considerations and Issues with IPv6 DNS", Work in

[CONF]   Thomson, S., Narten, T., "IPv6 Stateless Autoconfiguration"
         RFC 2462 December 1998.

[DHCPF]  Droms, R., Bound, J., Volz, B., Lemon, T., et al. "Dynamic
         Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 July

[DHCPL]  Droms, R., "Stateless Dynamic Host Configuration Protocol
         (DHCP) Service for IPv6" RFC 3756 April 2004.

[APPS]  Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., Castro, E.,
        "Application Aspects of IPv6 Transition" Work in Progress.

6.2  Non-Normative References

 None at this time.

Document Acknowledgments

 The Authors would like to acknowledge contributions from the
 following: IETF v6ops Working Group, Alan Beard, Brian Carpenter,
 Alain Durand, Bob Hinden, and Pekka Savola.

Author's Address

 Yanick Pouffary (Chair of Design Team)
 HP Competency Center
 950, Route des Colles, BP027,
 06901 Sophia Antipolis CEDEX
 Phone: + 33492956285
 Email: Yanick.pouffary@hp.com

 Jim Bound (Editor)
 Hewlett Packard
 110 Spitbrook Road
 Nashua, NH 03062
 Phone: 603.884.0062
 Email: jim.bound@hp.co

 Marc Blanchet
 Viagenie inc.
 2875 boul. Laurier, bur. 300
 Ste-Foy, Quebec, Canada, G1V 2M2
 EMail: Marc.Blanchet@viagenie.qc.ca

 Tony Hain
 Cisco Systems
 500 108th Ave. N.E. Suite 400
 Bellevue, Wa. 98004
 Email: alh-ietf@tndh.net

 Paul Gilbert
 Cisco Systems
 1 Penn Plaza, 5th floor,
 NY, NY 10119
 Phone: 212.714.4334
 Email: pgilbert@cisco.com

 Margaret Wasserman
 One Broadway
 Cambridge, MA 02142
 (617) 758-4177

 Jason Goldschmidt
 Sun Microsystems
 M/S UMPK17-103
 17 Network Circle
 Menlo Park, CA 94025
 Phone:   (650)-786-3502
 Fax:  (650)-786-8250

 Aldrin Isaac
 Bloomberg L.P.
 499 Park Avenue
 New York, NY 10022
 Phone: 212.940.1812
 Email: aisaac@bloomberg.com

 Tim Chown
 School of Electronics and Computer Science
 University of Southampton
 Southampton SO17 1BJ
 United Kingdom
 Email: tjc@ecs.soton.ac.uk

 Jordi Palet Martinez
 San Jose Artesano, 1
 Madrid, SPAIN
 Phone: +34 91 151 81 99
 Fax:   +34 91 151 81 98
 Email: jordi.palet@consulintel.es

 Fred Templin
 313 Fairchild Drive
 Mountain View, CA 94043
 Phone: 650.625.2331
 Email: ftemplin@iprg.nokia.com

 Roy Brabson
 PO BOX 12195
 3039 Cornwallis Road
 Research Triangle Park, NC 27709
 Phone: +1 919 254 7332
 Email: rbrabson@us.ibm.com

Intellectual Property and Copyright Statements

Intellectual Property Statement

 The IETF takes no position regarding the validity or scope of any
 intellectual property
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; neither nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the IETF's procedures with respect to rights in standards-track and
 standards-related documentation RFC documents can be
 found in BCP-11. BCP 78 and BCP 79.

 Copies of
 claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementors implementers or users of this
 specification can be obtained from the IETF Secretariat. on-line IPR repository at

 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 which that may cover technology that may be required to practice implement
 this standard.  Please address the information to the IETF Executive

Full Copyright Statement

 Copyright (C) The Internet Society (2002).  All Rights Reserved.

 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose at

Disclaimer of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than

 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns. Validity

 This document and the information contained herein is are provided on an


Copyright Statement

 Copyright (C) The Internet Society (2004).  This document is subject
 to the rights, licenses and restrictions contained in BCP 78, and
 except as set forth therein, the authors retain all their rights.


 Funding for the RFC Editor function is currently provided by the
 Internet Society.