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

Versions: 00 01

   Internet Draft                                         M. Lind (ed.)
   <draft-lind-v6ops-isp-scenarios-00.txt>                  TeliaSonera
   Expires: December 2003                                     June 2003


             Scenarios for Introducing IPv6 into ISP Networks


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/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 different scenarios for the introduction of
   IPv6 in an IPv4 ISP network. The goal is the addition of a native
   IPv6 service to the already existing IPv4 service without
   interruption of the IPv4 service. During the IPv6 introduction the
   network can go through 4 different stages including the initial IPv4
   only stage. To move between the stages there will be some form of
   transition that can be defined in different transition scenarios.














Lind                   Expires - December 2003               [Page 1]


INTERNET DRAFT       ISP Networks IPv6 Scenarios            June 2003


Table of Contents

   1. Introduction...................................................2
   2. Scope..........................................................3
   3. Brief description of a generic ISP network.....................3
   4. Stages.........................................................4
      4.1 Assumptions................................................4
      4.2 Customer requirements and ISP offerings....................5
      4.3 Stage 1 û Launch...........................................5
      4.4 Stage 2a - Core............................................6
      4.5 Stage 2b - Access..........................................6
      4.6 Stage 3 û Complete.........................................6
      4.7 Future stages..............................................7
   5. Transition Scenarios...........................................7
   6. Security Considerations........................................8

1.   Introduction

   An ISP offering an IPv4 service will find that there are different
   ways to add IPv6 to this service. During the introduction of IPv6 the
   network will go through different stages of IPv6 maturity. In
   addition to this there has to be a transition between these stages to
   make them feasible to implement. In some cases it might not be
   possible to introduce IPv6 as a native part of the network, due to
   hardware limitations or similar. Instead some coexistence mechanism
   has to be used.
   This leaves two choices; a native IPv6 transport in a part of the
   network or some mechanism to transport IPv6 over the existing IPv4
   network. From the customer perspective this can be seen as the ISP
   offering a native IPv6 service or not depending on what is relevant
   in the access network. If the ISP is not offering native IPv6
   transport, then the service is limited in the sense that the customer
   has to have a dual stack network, or some kind of coexistence
   mechanism.
   In this document different transition scenarios and situations during
   the introduction of IPv6 are covered in a broader perspective and
   deals only with a generic view of how an ISP network is build. This
   should be seen as the starting point for further documentation of how
   the introduction of IPv6 can be done in an ISP network in companion.
   What also will be included in these documents are issues specific to
   different network configurations and special network equipment. This
   document should therefore be seen as the working frame for the
   transition steps of the IPv6 introduction that will be documented in
   companion documents.







Lind                   Expires - December 2003               [Page 2]


INTERNET DRAFT       ISP Networks IPv6 Scenarios            June 2003

2.   Scope

   The scope of the document is to describe different cases for the
   introduction of an IPv6 service in a generic IPv4 ISP network. This
   means that the document will be limited to services that include both
   IPv6 and IPv4 and will not cover issues surrounding an IPv6 only
   service. The scope also includes transition scenarios between the
   different stages. The different building blocks that will be
   considered are a customer network, an access network, a core network
   and exchange points. It is outside the scope of this document to
   describe different types of access or network technologies. It is
   also outside of the scope to propose different solutions. Solutions
   will be covered in a separate document.

3.   Brief description of a generic ISP network

   A generic ISP network topology can be divided into two main parts;
   core network and access network. The core network or the backbone is
   the part of the network that interconnects the different access
   networks and provides transport to the rest of the Internet via
   exchange points or other means. The core network can be built on
   different technologies but in this document the only interest is
   whether it is capable of carrying IPv6 traffic natively or not. The
   same applies to the access network. The access network provides
   connectivity to enterprise and private customers. Other ISPs might as
   well be customers and connected to the ISP's network.
     __________      _________
    |          |    |         |
    |Backoffice|----|  CORE   |
    |__________|    |_________|\
        .             / | \     \
        .            /  |  \     \_Peering( Direct & IX )
        .           /   |   \
        .          /    |    \
     ___.___      /  ___|___  \      _______
    |       |____/  |       |  \____|       |
    |Access1|       |Access2|       |Access3|
    |_______|       |_______|       |_______|
        |               |               |
        |               |               | ISP Network
    ----|---------------|---------------|-----------------
        |               |               | Customer Networks
     ___|____        ___|____        ___|____
    |        |      |        |      |        |
    |Customer|      |Customer|      |Customer|
    |________|      |________|      |________|
        Figure 1: ISP network topology


Lind                   Expires - December 2003               [Page 3]


INTERNET DRAFT       ISP Networks IPv6 Scenarios            June 2003


   It doesn't matter if these customer networks have a single node or a
   large routed network. What is of interest is if routing information
   is exchanged or not since it will affect the ISP's network. The
   existence of customer placed equipment will also affect how a service
   can be delivered. In addition to the ISP's actual network components
   there are a lot of support and backend systems that have to be
   considered.

4.   Stages

   The stages here are snapshots of an ISP's network with respect to
   IPv6 maturity. Since an ISP's network is constantly evolving, a stage
   is a measure of how far an ISP has come in turn of implementing
   necessary functionality to offer IPv6 to the customers.

   It is possible to freely transition between different stages.
   However, a network segment can only be in one stage at a time but an
   ISP network as a whole can be in different stages. There are
   different transition paths between the first and final stage. The
   transition between two stages does not have to be immediate but can
   occur gradually.

   Each stage has different IPv6 properties. An ISP can therefore, based
   on the requirements it has, decide into which stage it will transform
   its network.

4.1    Assumptions

   The stages are derived from the generic description of an ISP network
   in section 3. A combination of different building blocks that
   constitute an ISP environment will lead to a number of scenarios,
   which an ISP can choose from. The scenarios of most relevance to this
   document are considered to be the ones that in the most efficient and
   feasible way maximizes the ability for an ISP to offer IPv6 to its
   customers.

   The most predominant case today is considered to be an operator with
   a core and access IPv4 network delivering IPv4 service to a customer
   that is running IPv4 as well. At some point in the future, it is
   expected that the customer will want to have an IPv6 service, in
   addition to the already existing IPv4 service. The challenge for the
   ISP is to deliver the requested IPv6 service over the existing
   infrastructure and at the same time keep the IPv4 service intact. The
   next step, which is not covered in this document, will be to remove
   the IPv4 service when there no longer is a demand for it or deliver
   the IPv4 service over an IPv6 only network.





Lind                   Expires - December 2003               [Page 4]


INTERNET DRAFT       ISP Networks IPv6 Scenarios            June 2003

4.2    Customer requirements and ISP offerings

   Looking at the scenarios from the end customer's perspective there
   might be a demand for three different services; the customer might
   demand IPv4 service, IPv6 service or both services. This can lead to
   two scenarios depending on the stage the ISP's network is in.

   If an ISP only offer IPv4 or IPv6 service and a customer wants to
   connect a device or network that only supports one service and if
   that service is not offered, it will lead to a dead-end. If the
   customer or ISP instead connects a dual stack device it is possible
   to circumvent the lack of the missing service in the access network
   by using some kind of coexistence mechanism. This scenario will only
   be considered in the perspective of the ISP offering a mechanism to
   bridge the access and reach the IPv6 core.

   In the case where the customer connects a single stack device to a
   corresponding single stack access network, there will be no problem
   from the customer's perspective. The same is valid if a single stack
   device is connected to a dual stack access network. Therefore,
   neither of these cases need further be explored in this document but
   can be seen as a part of a full dual stack case.

   After eliminating a number of cases explained above, there are four
   stages that are most probable and where an ISP will find its network
   in. Which stage a network is in; depend on whether or not some part
   of the network previously has been upgraded to support IPv6 or if it
   is easier to enable IPv6 in one part or another. For instance,
   routers in the core might have IPv6 support or might be easily
   upgradeable, while the hardware in the access might have to be
   completely replaced in order to handle IPv6 traffic.

   Note that in every stage except Stage 1, the ISP can offer both IPv4
   and IPv6 services to the customer.

   The four most probable stages are:
      Stage 1  û Launch
      Stage 2a û Core
      Stage 2b û Access
      Stage 3  û Complete

4.3    Stage 1 û Launch

   The first stage is an IPv4 only ISP with an IPv4 customer. This is
   the most common case today and has to be the starting point for the
   introduction of IPv6. From this stage, an ISP can move (transition)
   to any other stage with the goal to offer IPv6 to its customer.





Lind                   Expires - December 2003               [Page 5]


INTERNET DRAFT       ISP Networks IPv6 Scenarios            June 2003

   Customer    Access      Core     Exchange
    ------     ------     ------     ------
   |      |   |      |   |      |   |      |
   | IPv4 |---| IPv4 |---| IPv4 |---| IPv4 |
   |      |   |      |   |      |   |      |
    ------     ------     ------     ------
       Figure 2. IPv4 network

4.4    Stage 2a - Core

   Stage 2a is an ISP with an access network that is IPv4 only and a
   core that is IPv4 and IPv6. In this stage the customer should have
   support for both IPv4 and IPv6 and use a coexistence mechanism to be
   able to run the IPv6 service. To offer the IPv6 service, the ISP also
   has to connect to an IPv6 exchange point or somehow else exchange
   IPv6 traffic with other ISPs.

   Customer    Access      Core     Exchange
    ------     ------     ------     ------
   |      |   |      |   |      |   | IPv4 |
   | Dual |---| IPv4 |---| Dual |---|   +  |
   |      |   |      |   |      |   | IPv6 |
    ------     ------     ------     ------
       Figure 3. Upgraded core

4.5    Stage 2b - Access

   Stage 2b is an ISP with a core network that is IPv4 and an access
   that is IPv4 and IPv6. Since the service to the customer is native
   IPv6 there is no requirement for the customer to support both IPv4
   and IPv6. This is the biggest difference in comparison to the
   previous stage. The need to exchange IPv6 traffic or similar still
   exists but might be more complicated than in the previous case since
   the core isn't IPv6 enabled.

   Customer    Access      Core     Exchange
    ------     ------     ------     ------
   |      |   |      |   |      |   | IPv4 |
   | Dual |---| Dual |---| IPv4 |---|   +  |
   |      |   |      |   |      |   | IPv6 |
    ------     ------     ------     ------
      Figure 4. Upgraded access

4.6    Stage 3 û Complete

   Stage 3 can be said to be the final step in introducing IPv6, at
   least in the scope of this document. This is an all over IPv6 service
   with native support for IPv6 and IPv4 in both core and access
   networks. This stage is identical to the previous stage in the



Lind                   Expires - December 2003               [Page 6]


INTERNET DRAFT       ISP Networks IPv6 Scenarios            June 2003

   customer's perspective since the access network hasn't changed. The
   connection to the IPv6 exchange point is identical to stage 2.

   Customer    Access      Core     Exchange
    ------     ------     ------     ------
   |      |   |      |   |      |   | IPv4 |
   | Dual |---| Dual |---| Dual |---|   +  |
   |      |   |      |   |      |   | IPv6 |
    ------     ------     ------     ------
       Figure 5. Completely upgraded network

4.7    Future stages

   After a while the ISP might want to transition to a service that is
   IPv6 only, at least in certain parts of the network. This transition
   creates a lot of new cases in which to factor in how to maintain the
   IPv4 service. Providing an IPv6 only service is not much different
   than the dual IPv4/IPv6 service described in stage 3 except from the
   need to phase out the IPv4 service. The delivery of IPv4 services
   over an IPv6 network and the phase out will be left for a future
   document.

5.   Transition Scenarios

   Given the different stages it is clear that the ISP has to be able to
   transition from one stage to another. The initial stage, in this
   document, is the IPv4 only service and network. The end stage is the
   dual IPv4/IPv6 service and network. As mentioned in the scope, this
   document does not cover the IPv6 only service and network and its
   implications on IPv4 customers. This has nothing to do with the
   usability of an IPv6 only service.

   The transition starts out with the IPv4 ISP and then moves to one of
   three choices. These choices are the different transition scenarios.
   One way would be to upgrade the core first which leads to stage 2a.
   Another way to go could be to upgrade the access network which leads
   to stage 2b. The final possibility is to introduce IPv6 in the whole
   network at once which would lead to stage 3.

   The choice is dependent on many different issues. For example it
   might not be possible to upgrade the core or the access network
   without large investments in new equipment which could lead to any of
   the two first choices. In another case it might be easier to take the
   direct step to a complete IPv6/IPv4 network due to routing protocol
   issues or similar.

   If a partially upgraded network (stage 2a or 2b) was chosen as the
   first step, a second step remains before the network is all over
   native IPv6/IPv4. This is the transition to an all over dual stack



Lind                   Expires - December 2003               [Page 7]


INTERNET DRAFT       ISP Networks IPv6 Scenarios            June 2003

   network. This step is perhaps not necessary for stage 2b with an
   already native IPv6 service to the customer but might still occur
   when the timing is right. For stage 2a it is more obvious that a
   transition to a dual stack network is necessary since it has to be
   done to offer a native IPv6 service.

6.   Security Considerations

   This document describes different cases for the introduction of IPv6
   in an IPv4 ISP network. Solutions are described in other documents
   hence this document has no security considerations.

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 (2003). 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



Lind                   Expires - December 2003               [Page 8]


INTERNET DRAFT       ISP Networks IPv6 Scenarios            June 2003

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

   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.

Acknowledgements

   This draft has benefited from input by Jordi Palet, Suresh Satapati,
   Myung-Ki Shin, Vladmir Ksinant, Alain Baudot, Soohong Daniel Park,
   Cleve Mickles, Pekka Savola and Margaret Wasserman.

Authors' Addresses

   Mikael Lind
   TeliaSonera
   Vitsandsgatan 9B
   SE-12386 Farsta
   Email: mikael.lind@teliasonera.com

   Jasminko Mulahusic
   TeliaSonera
   Vitsandsgatan 9B
   SE-12386 Farsta
   Email: jasminko.mulahusic@teliasonera.com




















Lind                   Expires - December 2003               [Page 9]


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