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

Versions: 00 draft-ietf-v6ops-v4v6tran-framework

V6OPS                                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                                  S. Jiang
Expires: February 19, 2011                  Huawei Technologies Co., Ltd
                                                            V. Kuarsingh
                                                   Rogers Communications
                                                         August 18, 2010

             Framework for IP Version Transition Scenarios


   This document sets out a framework for the presentation of scenarios
   and recommendations for a variety of approaches to the transition
   from IPv4 to IPv6, given the necessity for a long period of co-
   existence of the two protocols.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on February 19, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Carpenter, et al.       Expires February 19, 2011               [Page 1]

Internet-Draft       Transition Scenarios Framework          August 2010

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Document Topics . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Change log  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6

Carpenter, et al.       Expires February 19, 2011               [Page 2]

Internet-Draft       Transition Scenarios Framework          August 2010

1.  Introduction

   This document sets out a framework for the presentation of scenarios
   and recommendations for a variety of approaches to the transition
   from IPv4 to IPv6, given the necessity for a long period of co-
   existence of the two protocols.  A general "call to arms" for
   transition is found in [RFC5211], and a recommendation for four
   principal scenarios is given in
   [I-D.arkko-ipv6-transition-guidelines].  A report on experience and
   plans of various Internet Service Providers (ISPs) is given in
   [I-D.ietf-v6ops-isp-scenarios].  However, it is clear that operators
   require more detailed technical recommendations than are available so
   far.  A companion document [reference TBD] provides a technical
   problem statement.  Unfortunately, the number of different
   combinations of existing IPv4 deployment models, customer profiles
   and requirements, and possible coexistence and transition models, is
   enormous, so it is quite impracticable to produce either a set of
   recommendations for each case, or a recommended "one size fits all"
   model.  That is why this document proposes a set of topics or
   dimensions, as a framework for a reasonable number of recommendation

   The reader is assumed to be familiar with IPv6.  The IETF's view of
   core IPv6 requirements is to be found in [RFC4294] (currently being
   updated as [I-D.ietf-6man-node-req-bis]).  However, this does not
   give a complete view of mechanisms an ISP may need to deploy, since
   it considers the requirements for an individual node, not for a
   network or service infrastructure as a whole.

   [RFC4029] discussed scenarios for introducing IPv6 into ISP networks,
   as the problem was viewed some years ago.  Its end goal was simply a
   dual-stack ISP backbone.  Today's view is that this is insufficient,
   as it does not allow for prolonged interworking between IPv6-only and
   legacy (IPv4-only) hosts.  Indeed, the end goal today might be an
   IPv6-only ISP backbone, with some form of legacy IPv4 support

   Although the basic IPv6 standards are stable, considerable work
   continues in several IETF working groups, on issues such as
   multihoming, tunneling, and IP layer interworking between IPv6-only
   and IPv4-only hosts.  However, operators faced with IPv4 address
   exhaustion in the coming few years need immediate guidance.

2.  Document Topics

   On the assumption that a series of documents are produced describing
   and recommending transition scenarios, there are two basic

Carpenter, et al.       Expires February 19, 2011               [Page 3]

Internet-Draft       Transition Scenarios Framework          August 2010

   1.  The documents will not be primary protocol specifications,
       because those are the outcome of IETF working groups chartered to
       work on specific protocol mechanisms.
   2.  The documents are addressed to service providers who have taken
       the decision to support IPv6, have acquired basic knowledge and
       skills, have determined how they will obtain upstream IPv6
       connectivity, and are ready to write their operational plan for

   The documents should each cover some or all of the following aspects
   or dimensions:
   o  For the convenience of readers, each document should briefly
      describe its network model in the Abstract (or Introduction) for
      quick reference.
   o  The documents should explain how certain technology components fit
      together in a given transition and co-existence scenario.
   o  They will present major generic network models, and their subsets,
      which exist (or are firmly planned) today, including network
      topologies and/or architectures.
   o  They should specify their scope: the range of technologies that
      they do or do not apply to (e.g. specific access network
      technologies, core network technologies and topologies, mobile vs
      fixed hosts, business vs private customers, etc.).
   o  They should develop analysis criteria on how to recognize
      appropriate transition technologies for existing provider networks
      within their scope.  This should include information related to
      deployed protocols and functions which may assist or hinder
      various transition technologies from being deployed.
   o  If multiple transition technologies are needed for provider
      environments where access networks differ and have various
      capabilities, the documents should show how these technologies can
      be deployed simultaneously.
   o  They should describe how multiple technologies can co-exist, if
      necessary, during all stages of migration (e.g., moving from IPv4
      Only to Dual-Stack to DS-Lite to NAT64).
   o  They should cover considerations for legacy operation while moving
      to IPv6 and its transition technologies.  Many operators will have
      large quantities of IPv4-only equipment which cannot feasibly be
      upgraded until the end of its economic life, or which is under
      customer control.
   o  They should cover considerations which apply when retro-fitting
      various technologies to existing networks.  Included in this would
      be impacts on ancillary protocols, routing platforms/systems,
      security policies, provisioning systems, network services (i.e.
      DHCP, DNS etc), law enforcement procedures and more.

Carpenter, et al.       Expires February 19, 2011               [Page 4]

Internet-Draft       Transition Scenarios Framework          August 2010

   o  They should quantify scaling characteristics of deployment modes
      for each technology model and intersections during co-existence
      (e.g. if some of the Network is DS-Lite and some is classical Dual
      Stack; peak load on NAT64; etc.).
   o  The documents should include security considerations for their
      specific transition scenario(s).

   A desirable outcome would be a set of Best Current Practice (BCP) or
   advisory (Informational) documents for a range of generic deployment
   models and how they fit into a network, including key services such
   as subscriber authentication, DHCP, and DNS.  However, it must not be
   forgotten that every service provider is different and such documents
   can never replace specific deployment plans drawn up by each
   individual service provider.

3.  Security Considerations

   Service providers will insist on having security for IPv6 services,
   and for all transition technologies, that is at least as good as for
   IPv4 services in all respects.  Particular attention must be paid to
   security exposures that are specific to transition and coexistence
   mechanisms.  Thus, all recommendations for transition scenarios must
   include security aspects.

4.  IANA Considerations

   This document makes no request of the IANA.

5.  Acknowledgements

   Useful comments and contributions were made by ... and others.

   This document was produced using the xml2rfc tool [RFC2629].

6.  Change log

   draft-carpenter-v4v6tran-framework-00: original version, 2010-08-18

7.  Informative References

              Arkko, J. and F. Baker, "Guidelines for Using IPv6
              Transition Mechanisms",

Carpenter, et al.       Expires February 19, 2011               [Page 5]

Internet-Draft       Transition Scenarios Framework          August 2010

              draft-arkko-ipv6-transition-guidelines-03 (work in
              progress), July 2010.

              Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements RFC 4294-bis",
              draft-ietf-6man-node-req-bis-05 (work in progress),
              July 2010.

              Carpenter, B. and S. Jiang, "Emerging Service Provider
              Scenarios for IPv6 Deployment",
              draft-ietf-v6ops-isp-scenarios-00 (work in progress),
              April 2010.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC4029]  Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
              Savola, "Scenarios and Analysis for Introducing IPv6 into
              ISP Networks", RFC 4029, March 2005.

   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
              April 2006.

   [RFC5211]  Curran, J., "An Internet Transition Plan", RFC 5211,
              July 2008.

Authors' Addresses

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland,   1142
   New Zealand

   Email: brian.e.carpenter@gmail.com

Carpenter, et al.       Expires February 19, 2011               [Page 6]

Internet-Draft       Transition Scenarios Framework          August 2010

   Sheng Jiang
   Huawei Technologies Co., Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing
   P.R. China

   Email: shengjiang@huawei.com

   Victor Kuarsingh
   Rogers Communications

   Email: Victor.Kuarsingh@rci.rogers.com

Carpenter, et al.       Expires February 19, 2011               [Page 7]

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