<?xml version="1.0" encoding="UTF-8"?>

<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->

<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
     (which supports the latest, sometimes undocumented and under-tested, features.) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!-- You need one entry like the following for each RFC referenced -->

<!ENTITY RFC2119 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2629 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY RFC4294 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4294.xml'>
<!ENTITY RFC4029 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4029.xml'>
<!ENTITY RFC4779 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4779.xml'>
<!ENTITY RFC4798 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4798.xml'>
<!ENTITY RFC5154 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5154.xml'>
<!ENTITY RFC5211 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5211.xml'>
<!ENTITY RFC4942 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4942.xml'>
<!ENTITY RFC4864 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4864.xml'>
<!ENTITY RFC5181 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5181.xml'>
<!ENTITY RFC5121 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5121.xml'>
<!ENTITY RFC5006 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5006.xml'>
<!ENTITY RFC4659 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4659.xml'>
<!ENTITY RFC6036 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6036.xml'>
<!ENTITY RFC6180 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6180.xml'>


<!-- You need one entry like the following for each I-D referenced -->


<!ENTITY DRAFT-nodereq SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-node-req-bis.xml">
<!ENTITY DRAFT-cpesec SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-cpe-simple-security.xml">
<!ENTITY DRAFT-cpereq SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-cpe-router.xml">
<!ENTITY DRAFT-wimax SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-16ng-ip-over-ethernet-over-802-dot-16.xml">
<!ENTITY DRAFT-dslite SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-dual-stack-lite.xml">
<!ENTITY DRAFT-cgn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nishitani-cgn.xml">

]> <!-- Closing the DOCTYPE declaration -->


<?rfc toc="yes"?>            <!-- You want a table of contents -->
<?rfc symrefs="yes"?>        <!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>       <!-- This sorts the references -->
<?rfc iprnotified="no" ?>    <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>


<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-ietf-v6ops-v4v6tran-framework-02" category="info">  


<front>
<title abbrev="Transition Scenarios Framework">Framework for IP Version Transition Scenarios</title>


<author initials="B. E." surname="Carpenter" fullname="Brian Carpenter">
    <organization abbrev="Univ. of Auckland"></organization>
    <address>
      <postal>
        <street>Department of Computer Science</street>
        <street>University of Auckland</street>
        <street>PB 92019</street>
        <city>Auckland</city>
        <region></region>
        <code>1142</code>
        <country>New Zealand</country>
      </postal>
      
      <email>brian.e.carpenter@gmail.com</email>
    </address>
</author>


   <author fullname="Sheng Jiang" initials="S.J." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>
      <address>
        <postal>
          <street>Huawei Building, No.3 Xinxi Rd.,</street>
          <city>Shang-Di Information Industry Base, Hai-Dian District, Beijing</city>
          <country>P.R. China</country>
        </postal>
        <email>jiangsheng@huawei.com</email>
      </address>
    </author>


  <author fullname="Victor Kuarsingh" initials="V." surname="Kuarsingh">
      <organization>Rogers Communications</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <country>Canada</country>
        </postal>
        <email>Victor.Kuarsingh@rci.rogers.com</email>
      </address>
    </author>


 
<date day="26" month="July" year="2011" />

<area>Operations</area>
<workgroup>V6OPS</workgroup>

 


<abstract>

<t>This document sets out a framework agreed by the V6OPS WG 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. </t>
    
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction">

<t>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 <xref target="RFC5211"/>,
and a recommendation for four principal scenarios is given in
<xref target="RFC6180"/>. A report on experience and plans
of various Internet Service Providers (ISPs) is given in
<xref target="RFC6036"/>. 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. 
[This was draft-lee-v4v6tran-problem which seems to be dead.] -->
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 documents. </t>

<t>The reader is assumed to be familiar with IPv6. The IETF's 
view of core IPv6 requirements is to be found in <xref target="RFC4294"/>
(currently being updated as <xref target="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.  </t>

<t><xref target="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 <xref target="RFC6180"/>. </t>

<t>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.  These operators cannot avoid the need for general skills 
acquisition, or the need to write their own detailed deployment plan, but 
they also need guidance for generic scenarios similar to their actual situation.
They cannot obtain such guidance from individual protocol specifications developed
by the IETF, so there is a need for additional documents.</t>

<t>This draft is maintained as a "living document" of the V6OPS WG,
because it is not considered necessary to archive it as an RFC. </t>


</section> <!-- intro -->

<!--  <section title="Normative Notation">
 <t>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 <xref target="RFC2119"/>.</t>
 </section> -->

<section anchor="frame" title="Document Topics">
<t>On the assumption that a series of documents are produced describing and recommending
transition scenarios, there are two basic conditions:</t>

<t><list style="numbers">
<t>The documents will not be primary protocol specifications, because those are 
the outcome of IETF working groups chartered to work on specific protocol mechanisms.</t>
<t>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 transition.</t>
</list></t>

<t>The documents should describe scenarios for real transition to IPv6, not life
extensions to IPv4 or other matters best handled in other working groups.
They should each cover some or all of the following aspects or dimensions: </t>

<t><list style="symbols">
<t>For the convenience of readers, each document should briefly describe its
network model in the Abstract (or Introduction) for quick reference.</t>
<t>The documents should explain how certain technology components fit together
in a given transition and co-existence scenario. </t>
<t>They will present major generic network models, and their subsets, which exist (or are firmly planned) today, including network topologies and/or architectures. </t>
<t>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.). </t>
<t>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. </t>
<t>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. </t>
<t>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). </t>
<t>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. </t> 
<t>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. </t>
<t>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.). </t>
<t>The documents should include security considerations for their specific transition scenario(s).</t>
</list></t>
 
<t>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. </t>



</section> <!-- frame -->




<section anchor="security" title="Security Considerations">

<t>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 any security aspects that are specific to that scenario.
</t>
   
</section> <!-- security -->


<section anchor="iana" title="IANA Considerations">
   <t>This document makes no request of the IANA.</t>
</section> <!-- iana -->


<section anchor="ack" title="Acknowledgements">


<t>Useful comments and contributions were made by Randy Bush and other members of the V6OPS WG.
</t>

<t>This document was produced using the xml2rfc tool
<xref target="RFC2629"/>.</t>

</section> <!-- ack -->


<section anchor ="changes" title="Change log">
<t>draft-ietf-v6ops-v4v6tran-framework-02: updated as living document for WG, 2011-07-26</t>
<t>draft-ietf-v6ops-v4v6tran-framework-01: small addition following WGLC, 2011-02-02</t>
<t>draft-ietf-v6ops-v4v6tran-framework-00: adopted by WG at IETF 79, 2010-12-01</t>
<t>draft-carpenter-v4v6tran-framework-00: original version, 2010-08-18</t>

</section> <!-- changes -->

</middle>

<back>

<!-- <references title="Normative References">

&RFC2119;

</references> -->

<references title="Informative References">

&RFC2629;
&RFC4029;
&RFC4294;
&RFC5211;
&RFC6036;
&RFC6180;
&DRAFT-nodereq;
    
</references>


</back>
</rfc>

