IPv6 Operations Working Group
Internet Draft                                        Jim Bound (Editor)
Document: draft-ietf-v6ops-ent-scenarios-00.txt draft-ietf-v6ops-ent-scenarios-01.txt          Hewlett Packard
Obsoletes: draft-pouffary-v6ops-ent-v6net-03.txt draft-ietf-v6ops-ent-scenarios-00.txt
Expires: April July 2004

                   IPv6 Enterprise Network Scenarios

                <draft-ietf-v6ops-ent-scenarios-00.txt>

                <draft-ietf-v6ops-ent-scenarios-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   This document is a submission by the Internet Protocol IPv6 Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the ipng@sunroof.eng.sun.com mailing list.

   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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes the scenarios for IPv6 deployment within
   Enterprise
   enterprise networks.  It will focus upon an Enterprise enterprise set of network
   base scenarios with assumptions, coexistence with legacy IPv4 nodes,
   networks, and applications, and network infrastructure requirements.
   These requirements will be used to provide analysis to determine a
   set of Enterprise enterprise solutions in a later document.

Table of Contents:

1.  Introduction................................................3
2.  Terminology.................................................5
3.  Base Scenarios..............................................6
3.1  Base Scenarios Defined.....................................6
3.2  Scenarios Characteristics..................................6 Network Infrastructure Components................7
3.3  Base  Specific Scenario Examples.....................................8 Examples.................................8
4.  Support for Legacy IPv4 Nodes and Applications..............9 Applications.............10
4.1  IPv4 Tunnels to Encapsulate IPv6...........................9 IPv6..........................10
4.2  IPv6 Tunnels to Encapsulate IPv4..........................10
4.3  IPv6 only communicating with IPv4..............................10 IPv4.........................11
5.  Network Infrastructure Requirements........................10 Component Requirements..............11
5.1  DNS.......................................................10  DNS.......................................................11
5.2  Routing...................................................10  Routing...................................................11
5.3  Autoconfiguration.........................................11  Autoconfiguration.........................................12
5.4  Security..................................................11  Security..................................................12
5.5  Applications..............................................11  Applications..............................................12
5.6  Network Management........................................11 Management........................................12
5.7  Address Planning..........................................11 Planning..........................................12
5.8 Multicast..................................................13
5.9 Multihoming................................................13
6.  Security Considerations....................................12 Considerations....................................13
7.  References.................................................12  References.................................................13
7.1  Normative References......................................12 References......................................14
7.2  Non-Normative References..................................12 References..................................14
Document Acknowledgments.......................................12 Acknowledgments.......................................14
Authors-Design Team Contact Information........................13 Information........................15
Intellectual Property Statement................................14 Statement................................16
Full Copyright Statement.......................................14
Acknowledgement................................................15 Statement.......................................17
Acknowledgement................................................17

1.  Introduction

   This document describes the scenarios for IPv6 deployment within
   Enterprise
   enterprise networks.  It will focus upon an Enterprise enterprise set of network
   base scenarios with assumptions, coexistence with legacy IPv4 nodes,
   networks, and applications, and network infrastructure requirements.
   These requirements will be used to provide analysis to determine a
   set of Enterprise enterprise solutions in a later document.

   The audience for this document is the enterprise network team
   considering deployment of IPv6.  The document will be useful for
   Enterprise
   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 enterprise
   can use to build an IPv6 network scenario.

   To frame the discussion, the document will describe a set of
   scenarios and characteristics network infrastructure for each scenario. It is
   impossible to define every possible Enterprise 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.
   enterprise.

   While it is difficult to quantify all the potential motivations scenarios for an enterprise
   network teams to move team to plan for IPv6, there are some cases where
   an abstract description it is possible. possible to depict a set of
   abstract scenarios that will assist with planning. The document
   presents three
   example motivations base scenarios as a general use case. This model can case to be used to
   define additional abstractions, as a
   model as input for the Enterprise enterprise to define
   scenarios to fit their requirements. specific scenarios.

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

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

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

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

2.  Terminology

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

   Provider              - A Provider is an An entity that provides services and
                           connectivity to the Internet or
                           other private external networks for the
                           Enterprise Network.

   IPv6/IPv4
                           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
                           IPv4.

   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. 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.

3.1  Base Scenarios Defined

   Scenario 1: Enterprise with an existing IPv4 network wants to deploy
               IPv6 in parallel conjunction with their IPv4 network.

**Note To V6ops WG: Would a network topology map be useful here?

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

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

    Scenario 2: 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.

**Note To V6ops WG: Would a network topology map be useful here?

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

     Requirements: Don't break disrupt IPv4 network operations. infrastructure.

   Scenario 3: Enterprise deploying a new network or re-structuring an
               existing network, decides IPv6 is the basis for
               most network
               communication.

**Note To V6ops WG: Would a network topology map be useful here? communication, to coexist with IPv4.

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

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

3.2  Scenarios Characteristics Network Infrastructure Components

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

   Characteristic 1 - Providers for External

   Network Operation Infrastructure Component 1
    Enterprise Provider Requirements
       - Is external connectivity required?
       - One site vs. multiple sites?
       - Leased lines or VPN?
       - How many global IPv4 existing addresses are available to the
         enterprise?
       - What is the IPv6 address ownership (Provider based addresses vs.
     Provider independent addresses)? plan available
         from the provider?
       - Multi-homing? Will clients be Multihomed?
       - Do ISPs Does the provider offer any IPv6 services?
       - What site external IPv6 service? routing protocols are required?
       - Is there an external data-center?

   Characteristic

   Network Infrastructure Component 2 -
    Enterprise Application Analysis Requirements
       - List of applications in use?
       - Which applications must be moved to support IPv6 first?
       - Can the application be upgraded to IPv6?
       - Can Will the application have to support both IPv4 and IPv6?

   Characteristic 3
       - 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 stable IP addresses?
       - Do the applications care about dependency between IPv4 and IPv6
         addresses?

   Network Infrastructure Component 3
    Enterprise IT Department Operations Analysis Requirements
       - Who "owns"/"operate" "owns"/"operates" the network: in house, or outsourced?
       - Is a Tele-commuter work force supported?
       - Is inter-site communications required?
       - Is network mobility used? used or required for IPv6?
       - IPv4 addressing What are the requirements of the IPv6 address plan?
       - IPv4 addressing What will be the internal IPv6 address assignment procedure (DHCP vs. manual)?
   - Internal IPv4 routing protocols used? procedure?
       - External IPv4 What site internal IPv6 routing protocols used? are required?
       - IPv4 What will be the IPv6 Network Management policy/procedure?
       - IPv4 QoS What will be the IPv6 QOS policy/procedure?
       - IPv4 What will be the IPv6 Security policy/procedure?
       - List of "network operation" What is the IPv6 training plan to educate the enterprise?
       - What network operations software that may 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 store, display, or
           allow input of IP addresses?
         - List of "network operation" Other services (e.g. NTP, etc.........)
       - What network hardware that may will be impacted by IPv6
           - Routers/switches
           - Printers/Faxes
           - Firewalls
           - Intrusion Detection
           - Load balancers
           - VPN Points of Entry/Exit
           - Security Servers
     - Printers 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 store, display, or
             allow input of IP addresses?

   Characteristics 4
           - Are the nodes moving within the enterprise network?
           - Are the nodes moving outside and inside the enterprise
             network?

   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
         Management?

3.3  Base Scenario Examples

   This section presents a set of Base Scenario Examples and is not

   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 of Base Scenarios for base scenarios within an Enterprise enterprise of a less
   abstract nature.

   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 to update 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 rules.
     - Load balancers do not support IPv6, upgrade path unclear.
     - Peer-2-Peer Application and Security supported.
     - IPv4 Private address space is used within the enterprise.

   Example Network B:

   A bank running a large ATM network supporting an order of magnitude
   number of transactions per second, online transaction
   processing (OLTP) across a distributed multi-sited network, with access
   to a central database on an external network from the ATM 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 nodes IP address.

   Example Network C:

   A Security Defense Network Operation:

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

   Applications run by the Enterprise:
     - Multimedia streaming of audio, video, and data for all nodes.
     - Data computation and analysis on stored and created data.
     - Transfer of data coordinate points to sensor devices.
     - Data and Intelligence gathering applications from all nodes.

   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.

4.  Support for Legacy IPv4 Nodes and Applications

   The Enterprise enterprise network will have to support the coexistence of IPv6
   and IPv4, to support legacy IPv4 applications and nodes. This means
   that some set of nodes will have to be IPv6 capable. The
   Enterprise enterprise
   user has the following choices for that coexistence to consider
   today.

4.1  IPv4 Tunnels to Encapsulate IPv6

   IPv6/IPv4

   IPv6 capable nodes want to communicate using IPv6, but an IPv4
   Internal router is between them. These nodes could also be Mobile
   nodes on a visited network.

4.2  IPv6 Tunnels to Encapsulate IPv4

   An IPv4/IPv6 node IPv6 capable node, on an IPv6 link within an IPv6 routing domain,
   wants to communicate with a legacy IPv4 node and is
   on an IPv6 only link and routing domain. application.

4.3  IPv6 only communicating with IPv4

   An IPv6 only capable node wants to communicate with an IPv4 only node.

   In cases where service, but
   the node is operating as IPv6 host cannot be a dual stack, in only.  In order to continue support of for
   communications with IPv4 nodes services an IPv4/v6 IPv6 to IPv4 translator or IPv6
   proxy is required.  Introduction of such translator will software may prevent usage
   of end-to-end security and application applications carrying embedded IP
   addressing information.

   **Note to V6ops WG: Should we discuss porting  Bi-directional establishment of applications too in
   the legacy section? connections
   might be difficult to achieve.

5.  Network Infrastructure Component Requirements

   The Enterprise 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.

5.1  DNS

   DNS will now have to support both IPv4 and IPv6 DNS records and the
   Enterprise
   enterprise will need to determine how the DNS is to be managed and
   accessed, and secured.

   **Note to V6ops WG: Should we get into other  The range of DNS issues?

5.2  Routing

   Interior and Exterior routing will be required to support both IPv4
   and IPv6 routing protocols, and the coexistence operational issues are out
   of scope for this work.  Users need to consider all current DNS IPv4
   operations and IPv6 over 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.

5.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, and any ingress and egress points to provider
   networks. networks,
   and transition mechanisms they wish to use for IPv6 adoption. The
   enterprise will also need to define points of determine what IPv6 transition mechanism to use within that
   mechanisms are supported by their upstream providers.

   The choice of interior routing topology.

   IPv6/IPv4 protocols have an impact on how the
   routing tables will be handled: some such as OSPF will have the
   ships-in-the-night, others such as ISIS are integrated. This has an
   impact on the topology and the management of the network.

   IPv6 capable routers should be monitored to ensure the router has
   sufficient storage for both IPv6 and IPv4 route tables.  Existing
   network design principles to limit the number of routes in the
   network, such as prefix aggregation, become more critical with the
   addition of IPv6 to an existing IPv4 network.

   **Note to V6ops WG: Above is example of additional text we could add
   to each component we list here.  Are there other Routing issues?

5.3  Autoconfiguration

   IPv6 introduces the concept of stateless autoconfiguration in
   addition to statefull stateful autoconfiguration.  The enterprise will have to
   determine the best method of autoconfiguration, for their network.

   **Note
   The enterprise will need to V6ops WG: Should we get into other determine if they are to use stateless or
   stateful autoconfiguration, and how autoconfiguration
   issues? 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.

5.4  Security

   Current existing mechanisms used for IPv4 to provide security need to
   be supported for IPv6 within the Enterprise. enterprise.  IPv6 should create no
   new security concerns for IPv4.

   **Note  The entire security infrastructure
   currently used in the enterprise needs to V6ops WG: Should we get into be analyzed against IPv6
   deployment effect and determine what is supported in IPv6.  Users
   should review other security issues? 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 requirments for IPv6 need to be
   determined by the enterprise. The policy choice of users for security
   is out of scope for this document.

5.5  Applications

   Existing applications will need to be ported or proxyed to support
   both IPv4 and IPv6.

   **Note to V6ops WG: Should we get into other application issues?

5.6  Network Management

   The addition of IPv6 and points of transition network infrastructure components will need to
   be managed by the Enterprise enterprise network operations center.  This  Users will affect many
   components of the
   need to work with their network management platform providers to
   determine what for IPv6 is supported during their planning for IPv6
   adoption, and software required on nodes.

   **Note what tools are available in the market to V6ops WG: Should we get into other Management issues? monitor the
   network.

5.7  Address Planning

   The address space within the Enterprise enterprise will need to be defined and
   coordinated with the routing topology of the Enterprise enterprise network.

   **Note  It
   is also important to V6ops WG: Should we get into other Address Planning issues?

   **Note identify the pool of IPv4 address space
   available to V6ops WG: What other components the enterprise to assist with IPv6 transition methods.

5.8 Multicast

   Enterprises utilising IPv4 Multicast services will need to consider
   how these services may be presented in an IPv6-enabled environment.
   First, the Multicast routing protocols will need to be considered;
   those such as PIM-SM may operate similarly under either protocol, but
   in IPv6 will need to support the Multicast Listener Discovery
   protocol.

   Nodes wishing to utilise Source Specific Multicast (SSM) will need to
   support Multicast Listener Discovery protocol v2 (MLDv2).  In
   addition, applications written for PIM-SM may need to be modified to
   use SSM.

   For inter-domain multicast, IPv6 has no equivalent of Multicast
   Source Discovery Protocol (MSDP);  alternative methods are we missing? being
   designed within the IETF, e.g. by embedding the Rendezvous Point
   address in the multicast group address.

   For inter-domain use, sites may choose to migrate IPv4 multicast
   applications to SSM, for which no reverse path discovery method is
   required.

5.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.

6.  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 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.

7.  References

7.1  Normative References

   None at this time.

7.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, and Bob Hinden.

Authors-Design Team Contact Information

Send email to ent-v6net@viagenie.qc.ca to contact the design team and send comments on the draft to v6ops@ops.ietf.org.

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

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

   Marc Blanchet
   Hexago
   2875 boul. Laurier, bur. 300
   Ste-Foy, Quebec, Canada, G1V 2M2
   EMail: Marc.Blanchet@hexago.com

   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
   USA
   Phone: 212.714.4334
   Email: pgilbert@cisco.com

   Margaret Wasserman
   Wind River
   10 Tara Blvd, Suite 330
   Nashua, NH 03062 USA
   USA
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   US
   Phone: 603.897.2067
   Email: mrw@windriver.com +1 781 993 4900
   EMail: margaret.wasserman@nokia.com
   URI:   http://www.nokia.com/

   Jason Goldschmidt
   Sun Microsystems
   M/S UMPK17-103
   17 Network Circle
   Menlo Park, CA 94025
   USA
   Phone:   (650)-786-3502
   Fax:  (650)-786-8250
   Email:jason.goldschmidt@sun.com

   Aldrin Isaac
   Bloomberg L.P.
   499 Park Avenue
   New York, NY 10022
   USA
   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
   Consulintel
   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
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   USA
   Phone: 650.625.2331
   Email: ftemplin@iprg.nokia.com

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

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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 does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 or users of this specification can
   be obtained from the IETF Secretariat.

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

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 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
   English.

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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