[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 draft-pouffary-v6ops-ent-v6net

V6ops Working Group             Enterprise Network Scenarios Design Team

INTERNET-DRAFT: draft-ietf-v6ops-entnet-scenarios-00.txt
OBSOLETES     : draft-pouffary-v6ops-ent-v6net-03.txt

                                                 Yanick Pouffary (Chair)
                                                 Jim Bound (Editor)
                               Enterprise Networks Scenarios Design Team
                                            See Acknowledgements Section

                                                           February 2003






                  IPv6 Enterprise Networks Scenarios

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


Status of this Memo

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

   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/1id-abstracts.html

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




















draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003   [Page 1]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


Abstract

   IPv6 will be deployed in Enterprise networks. This scenario has
   requirements for the adoption of IPv6.  This document will focus upon
   and define: a set of technology scenarios that shall exist for the
   enterprise network, the set of transition variables, transition
   methods, and tools required by different scenarios. The document
   using these definitions will define the points of transition for an
   Enterprise network.



















































draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003   [Page 2]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


Table of Contents:

1. Introduction.................................................4
2. Requirements.................................................5
3. Terminology..................................................6
4. Enterprise Network Assumptions...............................7
5. Enterprise Network Scenarios Overview........................9
6. Enterprise Points of Transition Methods.....................11
   6.1 M1: IPv4 Tunnels to Encapsulate IPv6....................11
   6.2 M2: IPv6 Tunnels to Encapsulate IPv4....................11
   6.3 M3: IPv6 NAT to Communicate with IPv4...................11
   6.4 M4: IPv6 Native LANs....................................12
   6.5 M5: IPv6 Native Routing Domains.........................12
   6.6 M6: Dual Stack Nodes supporting IPv6 and IPv4...........12
7. Enterprise Network Infrastructure Points of Transition......13
   7.1 DNS.....................................................13
   7.2 Routing.................................................13
   7.3 Autoconfiguration.......................................13
   7.4 Security................................................13
   7.5 Applications and APIs...................................14
   7.6 IPv6 Address Scoping....................................14
   7.7 Network Management......................................14
   7.8 Address Planning........................................14
8. Enterprise Tools Requirements...............................15
   8.1 Routing Configuration...................................15
   8.2 DNS Configuration.......................................15
   8.3 IPv6 Address Allocation and Configuration...............15
   8.4 IPv4 Address Allocation and Configuration...............15
   8.5 VPN/Tunnel Configuration................................15
   8.6 Mobile Node IPv4/IPv6 Interoperation Configuration......15
9. Enterprise Network Scenarios in Depth.......................16
10. Enteprise Network Scenarios Matrix Graph...................16
11. Applicability Statement....................................16
12. Security Section...........................................16
Acknowledgments................................................16
References.....................................................16
Design Team' Addresses.........................................17























draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003   [Page 3]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


1. Introduction

   IPv6 will be deployed in Enterprise networks. This scenario has
   requirements for the adoption of IPv6.  This document will focus upon
   and define: a set of technology scenarios that shall exist for the
   enterprise network, the set of transition variables, transition
   methods, and tools required by different scenarios. The document
   using these definitions will define the points of transition for an
   Enterprise network.

   The audience for this document is the enterprise network team
   considering deployment of IPv6. It is needed to clearly state the
   problem space so there is a common understanding of the need for
   transition tools in general. Specifically it is intended to show that
   the enterprise brings an important set of cases that the transition
   tools have to address. It will attempt to describe common
   environments and the issues that are important to a transition.

   To frame the discussion, it will focus on administrative policy
   rather than size, and break that down by services available within
   the enterprise. The business value and high level motivation for each
   technical approach will be touched on in terms of cost/benefit
   aspects. This value is expected to affect the order of deployment an
   enterprise will take, so the document will try to order approaches
   according to value.

   While it is difficult to quantify all the potential motivations for
   enterprise network teams to move to IPv6, there are some cases where
   an abstract description is possible.

   The primary case is the detrimental affect on the basic business
   processes caused by a lack of available IPv4 addresses. This may be
   through IPv4-NAT breaking applications or security technologies, or
   the simple inability to achieve a viable business model with current
   allocation policies. With a simpler end-to-end approach to
   accomplishing the business goal, IPv6 provides strong motivations to
   move.

   Another related motivator is avoiding the significant and frequently
   hidden burden on IT of continually balancing the available IPv4
   address pool against the number of devices attached to a particular
   network of subnets. This is generally a problem with fast growing
   satellite offices, but also occurs as business priorities cause rapid
   reorganization. Using the autoconfiguration capabilities of IPv6, the
   effort aligns with the need for new independently routed segments,
   rather than the shifting number of devices that may be attached to
   any given network segment.

   A slightly different motivator is the case of the enterprise that
   develops products for other enterprises, where the consuming
   enterprise has an insufficient pool of IPv4 addresses. While on the
   surface this is another shortage motivator, the real business
   motivator is for the supplier to avoid having to build and
   continually update their product to work despite the presence of
   IPv4-NAT. The NAT-traversal problem requires both substantial
   resources to develop the work-around, as well as provide the
   additional infrastructure components. Each of these raise the cost to
   develop the product, therefore make it less competitive than a


draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003   [Page 4]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


   comparable IPv6 based product.

   Another case to consider are new enterprise networks that want to
   begin their operations with IPv6 from day one.



2. Requirements

         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
         NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
         "OPTIONAL" in this document are to be interpreted as described in
         RFC 2119.















































draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003   [Page 5]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


3. Terminology

  Enterprise Network               - An Enterprise Network is a network
                                     that has multiple links, a router
                                     conection to a Provider, and is actively
                                     managed by a network operations entity.

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

  Edge                             - The Edge is the ingress and egress points
                                     connecting to the Internet, Extranet, or
                                     to another private external network.

  Administrative Domain            - An Administrative Domain are the
                                     ingress and egress points connecting
                                     nodes across the Enterprise
                                     Network, behind the Edges.

  Extranet                         - An Extranet is any Enterprise Network
                                     owned network components at the Edge, but
                                     not part of the Administrative Domain.

  Border Router                    - An Enterprise Network Border Router is a
                                     a router that is configured at the Edges.

  Internal Router                  - An Enterprise Network Internal Router is
                                     a router that is not configured at an
                                     Edge, but within the Administrative Domain.

  Mobile                           - An Enterprise Network condition when a
                                     node changes its network location, or
                                     is not attached to the Administrative
                                     Domain.

  Mobile Node                     - An Enterprise Network Mobile Node is any
                                    node that is Mobile within or not
                                    within the enterprise, or as remote
                                    telecommuting node.

  Points of Transtion            - An Enterprise Network Point of Transition
                                   is a general abstraction to note functions
                                   that must be defined for the transition to
                                   IPv6.

  Internet Network Provider     - A Provider for connectivity and services
                                  to the public Internet.

  Private Network Provider      - A Provider for connectivity and services
                                  to a private Internet.

  Dual Stack IPv4/IPv6 Node     - A node that supports IPv4 and IPv6.

  IPv4 ONLY Node                - A node that only supports IPv4.

  IPv6 ONLY Node                - A node that only supports IPv6


draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003   [Page 6]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


4. Enterprise Network Assumptions

   In this section assumptions about the enterprise network for this
   document are provided.

      Each network will need to select the method to best suit their
      business requirements. Any attempt to define a default or one-
      size-fits-all set of variables and methods for all scenarios would
      result in failure.

      Every node that can be addressed by another node must be in a
      registered name service, managing this name service is a
      significant scaling challenge for the Enterprise.

      Applications that support multiple users on multiple nodes
      (multi-Party) require globally consistent addresses for peer-to-
      peer communications.

      Bi-directional communication between two nodes across Service
      Provider networks is often used as a crude level of authenticity,
      having the IP addresses in the IP header be the same as from where
      the nodes data packet came from provides a rudimentary component
      of security.

      Enterprise Networks will vary in size and network complexity from
      a small office to a large manufacturing operation with multiple
      sites, across a wide geography

   Points of Transition will need to be defined for the following:


        - Routers
        - Non Router Nodes
        - Network Topology
        - Network Applications
        - Network Management and Tools
        - Network Security
        - Network Mobility
        - Network VPNs
        - Network Telecommuter Work Force
        - Network Inter Site Communications

   This document will identify those Points of Transition and discuss
   them within a set of scenarios.  This document will not provide
   solutions. A set of suggested solutions will be provided in a follow
   on document to this work.

   Enterprise Networks will vary how they approach the transition to
   IPv6 depending on a set of transition variables (V1..VN):

        V1:  IPv4 NAT and Firewall uses IPv4 private addresses.
        V2:  IPv4 Firewall uses IPv4 global routable addresses.
        V3:  Applications must be able to communicate between remote
             Administrative Domains.
        V4:  The methods and security used to access the Administrative
             Domain for Telecommuters and Mobile Nodes.
        V5:  IPv6 software upgrades are not available for existing
             routers and nodes.


draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003   [Page 7]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


        V6:  Source code for applications have been lost or cannot be
             upgraded to IPv6.
        V7:  New business function being defined and can exist without
             extensive access to legacy IPv4 networks and nodes.
        V8:  Mission critical applications must be able to interoperate
             with legacy IPv4 nodes.
        V9:  Legacy IPv4 nodes can be upgraded to support dual stack
             IPv4 and IPv6.
        V10: Legacy IPv4 nodes cannot be upgraded to support dual stack
             IPv4 and IPv6.
        V11: What sections of the network for an existing network or
             new network will move towards IPv6 deployment first, second, ....,
             last, and at what rate.
        V12: What are the network security requirements for the Enterprise
             Network.
        V13: Provider does not support IPv6.

   The transition variables are the parameters to the first function to
   determine the functions for a scenario. Once the transition variables
   are understood then the next step is to select transition methods as
   follows (M1..MN):

        M1:  IPv4 Tunnels to Encapsulate IPv6
        M2:  IPv6 Tunnels to Encapsulate IPv4
        M3:  IPv6 NAT to Communicate with IPv4
        M4:  IPv6 Native LANs
        M5:  IPv6 Native Routing Domains
        M6:  Dual Stack Nodes supporting IPv6 and IPv4
        M7:  IPv6 Tunnels to Encapsulate IPv6

   This document will define a list of sets for transition variables,
   methods, and tool requirements, which will provide a three
   dimensional system for analysis that can be used to extrapolate a set
   of solutions.  Where the X axis is the transition variables (V#), the
   Y axis the transition method (M#), and the Z axis the tools
   requirement set (section 8) to support X and Y conditions.

   This point on the graph will be an transtion strategy. After the
   document describes the scenarios in depth (section 9) the graph will
   be depicted in a matrix for readers of this document (section 10)




















draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003   [Page 8]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


5. Enterprise Network Scenarios Overview


   It would be impossible for any one document to describe all the
   potential scenarios as networks deploy IPv6. Attempting to break the
   problem space down and cover the high level perspectives, this
   document will separate the scenarios by administrative scope and
   policy. Within each, the various ISP service offerings produce 15
   cases to describe. Finally, we find there are 27 cases when the
   additional characteristic of host and application-first versus
   network-first approaches are considered.

   The 15 above is 5 cases x 3 offerings. The 27 comes from the doubling
   by discussing network vs. application first, minus the 3 offerings
   from set D because it has to be done all at once.  Another way to
   describe the table is scenarios x offerings x order = (4 x 3 x 2) +
   (1 x 3 x 1).

   Without looking for a one-size-fits-all, to simplify the document we
   will assume a single motivating application. The multi-party peer-to-
   peer conferencing application they are deploying to improve
   productivity requires unambiguous addresses. The IPv6 enabled
   application needs to communicate with each party as a peer, while
   other applications on those systems still need access to IPv4 based
   services.

   Critical issues for each:

        Addressing  : Dynamic vs. control w/administrative burden
        DNS         : Dynamic vs. control w/administrative burden
                       Public visibility of the name space.
        AAA         : Internal & external
                       Mobility of road warrior and telecommuters
        Applications: What applications are needed
        PMTUD       : Support for discovery vs. traditional ICMP aversion
        Mobility    : Requirements for nodes
        Management  : Network and tools management

   Trust system between host & network management teams:

        Dual-stack vs. IPv6-only
        IPv6-only is a restricted capability subset
        Routing
        Architectural concept of tunneling over foo vs. native service

   Scenario set A:

       Single geographic region, single administration & policy
       ISP offering -       IPv4-only       IPv4 & IPv6     IPv6-only
       Deployment order -   Hosts & Apps first      Network first

   Scenario set B:

      Multiple geographic regions, single administration & policy
      ISP offering -       IPv4-only       IPv4 & IPv6     IPv6-only
      Deployment order -   Hosts & Apps first      Network first

   Scenario set C:


draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003   [Page 9]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


      Multiple geographic regions, multiple administrations & policy
      ISP offering -       IPv4-only       IPv4 & IPv6     IPv6-only
      Deployment order -   Hosts & Apps first      Network first

   Scenario set D:

      New enterprise, looking to avoid a transition
      ISP offering -       IPv4-only       IPv4 & IPv6     IPv6-only
      Deployment order -   All at once by definition

   Scenario set E:

      Enterprise Services for remote users
      ISP offering -       IPv4-only       IPv4 & IPv6     IPv6-only
      Deployment order -   Hosts & Apps first      Network first

   Scenario #1

   An enterprise has an existing IPv4 network and is adding IPv6 between
   geographic sites.  Set A and B.

   Scenario #2

   An enterprise deploys wireless services where groups of access points
   end up on different subnets.  Set A and B.

   Scenario #3

   A multi-site enterprise has deployed IPv4-NAT with overlapping
   private address ranges between the sites.  Set A and B.

   Scenario #4

   A global enterprise interacts with a public and private Internet as a
   cohesive unit, but is composed of several administratively distinct
   business units. Set C.

   Scenario #5

   Two large enterprises using IPv4-NAT merge with the consequence that
   large segments of private network address space overlap.  Set C.

   Scenario #6

   A new Enterprise providing location based services for over a wide
   geography enables mobile devices for their Account Teams to access
   network data and services.   Set D.

   Scenario #6 (subset of all scenarios)

   Enterprise employees telecommute to work from home, or during
   business travel.  Set E.








draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003  [Page 10]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


6. Enterprise Points of Transition Methods

   The Enterprise network will have varying points of transition that
   will require different points of interoperability with IPv6 and IPv4.
   These points of transition are the fulcrum of the template to define
   what is required for Enterprise networks within the focus of this
   document.



6.1 M1: IPv4 Tunnels to Encapsulate IPv6

   This Point of Transition exists for the following conditions:

       1. Two Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6,
          but an IPv4 Internal Router is between them.  These nodes could also
          be Mobile nodes too and in a remote location.
       2. Two Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6,
          but they are in a remote Administrative Domain and geography, and
          packets must be sent to a Provider.  These nodes could also be Mobile
          nodes and in a remote location.
       3. Two Mobile Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6,
          and both are on remote IPv4 network.
       4. Two Mobile Dual Stacked IPv4/IPv6 nodes want to communicate using IPv6,
          and both are on remote IPv6 network.

   It is important to realize in this scenario the transit providers
   could be IPv4-ONLY.



6.2 M2: IPv6 Tunnels to Encapsulate IPv4

   This Point of Transition exists for the following conditions:

       1. A Dual Stacked IPv4/IPv6 node wants to communicate to a legacy IPv4
          service and is on a Native IPv6 link and Routing Domain.  Enterpise
          policy is that IPv6 should be used to encapsulate IPv4.
       2. A Dual Stacked IPv4/IPv6 node  wants to communicate to a legcy IPv4
          service and is on a Native IPv6 link and Routing Domain. Enterprise
          policy is IPv4 should be used for this communications.
       3. Same conditions above but for Mobile node.



6.3 M3: IPv6 NAT to Communicate with IPv4

   This Point of Transition exists for the following conditions:


      1. A Dual Stacked IPv4/IPv6 node wants to communicate with a legacy IPv4
         ONLY service or node.  Enterprise policy is that IPv6 NAT should be
         used for this communications.
      2. An IPv6 ONLY node wants to communicate with a legacy IPv4 ONLY node
         or service.  Same policy as above.
      3. Same conditions above but for Mobile IPv6 ONLY node.

   Using NAT for this point of transition will preclude end-2-end


draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003  [Page 11]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


   security, applications, and remove some benefits from the IPv6
   protocol.

      1. The Design Team highly recommends that network not adopt the policy
         in reference "1" above.
      2. IPv6 ONLY nodes should not be deployed in a network until they will
         not require access to any legacy IPv4.  This means that applications
         and infrastructure has been ported or moved to IPv6.  Until that
         time nodes for transition should be Dual Stacked IPv4/IPv6 nodes.
         This means networks that want to use IPv6 ONLY nodes will be required
         to move applications and infrastructure to IPv6 first.



6.4 M4: IPv6 Native LANs

   This Point of Transtion exists when the policy wants to support the
   deployment of Native IPv6 LANs.  This condition will be driven by the
   transition variables V1-V14 stated in Section 4.



6.5 M5: IPv6 Native Routing Domains

   This Point of Transition exists when the policy is to deploy IPv6
   Native Routing Domains.  This condition will be driven by the
   variables V1-14 stated in Section 4.



6.6 M6: Dual Stack Nodes supporting IPv6 and IPv4

   This Point of Transition is a method to deploy IPv6 and a method for
   transition.  A network that deploys Dual Stacked IPv4/IPv6 nodes as
   they adopt IPv6 are more assured that IPv6 and IPv4 interoperation
   will be possible between the two nodes or services.  It also means
   for many legacy IPv4 nodes that they can be upgraded to support IPv4
   and IPv6, but not turn on IPv6 until the IPv6 operational network has
   been verified to be interoperable and secure.  It also means that
   both IPv4 and IPv6 can be supported by the nodes that transition to
   IPv6 and then will be able to communicate with IPv4 nodes using an
   IPv4 network infrastructure.


















draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003  [Page 12]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


7. Enterprise Network Infrastructure Points of Transition

   The Enterprise will be required to determine what network
   infrastructure will be affected by transtion to IPv6. This
   infrastructure must be analyzed and understood as a critical resource
   to manage.

   Each topic below in this section will be discussed and the issues
   facing transition for these network infrastructure parts will be
   discussed.



7.1 DNS

This will be discussed in a future draft.



7.2 Routing

This will be discussed in a future draft.



7.3 Autoconfiguration

   IPv6 introduces the concept of autoconfiguration [RFC2462].
   Autoconfiguration removes the need for DHCP to dynamically assign
   addresses to nodes.  Though DHCPv6 can be used to administrate
   addresses that are assigned to nodes.

   When preforming stateless autoconfiguration, an EUI-64 is generated
   by the IPv6 node, on a per-interface basis, to form the entire 128
   bit IPV6 address.  The EUI-64 is derived from the MAC address of the
   interface that being autoconfigured.  This mechanism proves a large
   amount of flexibility when joining new nodes to an IPv6 network.
   Since the address is tied to the MAC address of a given interface,
   swapping said interface device would change the address of the node.
   This presents a problem for nodes, such as servers and routers, that
   require a stable IP address.

   It is suggested that nodes which require such stability, in their IP
   address, make use of either stateful autoconfiguration or fixed
   interface-id autoconfiguration.  The later involves using a fixed 64
   bit token, instead of the EUI-64.  Determining the value of this
   token should be considered when establishing an address plan."



7.4 Security

This will be discussed in a future draft.







draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003  [Page 13]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


7.5 Applications and APIs

This will be discussed in a future draft.



7.6 IPv6 Address Scoping

This will be discussed in a future draft.



7.7 Network Management

This will be discussed in a future draft.



7.8 Address Planning

This will be discussed in a future draft.







































draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003  [Page 14]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


8. Enterprise Tools Requirements

   This section will identify the tools requirements for an EN
   transitioning to IPv6 so the configuration issues for the EN are
   documented for the document.



8.1 Routing Configuration

This will be discussed in a future draft.



8.2 DNS Configuration

This will be discussed in a future draft.



8.3 IPv6 Address Allocation and Configuration

This will be discussed in a future draft.



8.4 IPv4 Address Allocation and Configuration

This will be discussed in a future draft.



8.5 VPN/Tunnel Configuration

This will be discussed in a future draft.



8.6 Mobile Node IPv4/IPv6 Interoperation Configuration

This will be discussed in a future draft.



















draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003  [Page 15]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


9. Enterprise Network Scenarios in Depth

   This section will discuss the Scenarios in depth and identify the
   transition methods options and tools requirements from previous
   sections.

   This will be done in a future draft.



10. Enteprise Network Scenarios Matrix Graph

   This section will provide a set of matrices from the scenarios,
   transition variables, methods, and tools to define and determine
   common points of transition across the Scenarios.

   This will be done in future draft.



11. Applicability Statement

This will be done in a future draft as we get more working group discussion.



12. Security Section

The first iteration of this section will be done in a future draft.



Acknowledgments

Enterprise Network Scenarios Design Team:

Yanick Pouffary (Chair) -  Hewlett Packard
Jim Bound (Editor) - Hewlett Packard
Yurie Rich - Native6 Group
Marc Blanchet - Hexago
Tony Hain - Cisco
Paul Gilbert - Cisco
Scott Hahn - Intel
Margaret Wasserman - Windriver
Jason Goldschmidt - Sun Microsystems
Mathew Lehman - Microsoft
Aldrin Isaac - Bloomberg

The Design Team would also like to acknowledge the input from the
following: IETF V6OPS Working Group, Tim Chown, Alain Durand, and Bob Hinden.



References


   These will be provided as the drafts mature and we reference related
   work in the IETF and in the Industry.






draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003  [Page 16]


INTERNET-DRAFT  draft-ietf-v6ops-entnet-scenarios-00.txt   February 2003


Design Team' Addresses

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

Authors contact info will be provided in a future draft.






















































draft-ietf-v6ops-entnet-scenarios-00.txt    Expires July 2003  [Page 17]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/