Internet Engineering Task Force                            S. Matsushima
Internet-Draft                                          Softbank Telecom
Intended status: Informational                               Y. Yamazaki
Expires: September 30, 2011                              Softbank Mobile
                                                                  C. Sun
                                                            M. Yamanishi
                                                                 J. Jiao
                                                             Softbank BB
                                                          March 29, 2011


   Use case and consideration experiences of IPv4 to IPv6 transition
            draft-matsushima-v6ops-transition-experience-02

Abstract

   Service Providers will apply their use case when conducting IPv6
   transition and determine helpful solutions with the assistance of the
   IPv6 transition guideline document.  More than one solution is
   possible, and decisions must be made from not only the technical
   point of view, but also from the economic point of view.  This
   document describes the conclusions reached by one operator based on
   their considerations and their plans for IPv6 transition so as to
   assist others who may have similar circumstances.

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 September 30, 2011.

Copyright Notice

   Copyright (c) 2011 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



Matsushima, et al.     Expires September 30, 2011               [Page 1]


Internet-Draft  4rd transition considerations experience      March 2011


   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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Transition overview and current status  . . . . . . . . . . . . 3
   3.  Experience of IPv4-only Network and Assessment Approach . . . . 3
   4.  Considerations for IPv6-Only network  . . . . . . . . . . . . . 4
   5.  Considerations for Mobile network . . . . . . . . . . . . . . . 5
   6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Security considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8



























Matsushima, et al.     Expires September 30, 2011               [Page 2]


Internet-Draft  4rd transition considerations experience      March 2011


1.  Introduction

   IPv4 to IPv6 transition solutions are becoming more converged.  Given
   the variety of operators involved, various use-case scenarios exist
   and efforts are underway to clarify them.  Since the first group
   addressing IPv6 transition are technically inclined, the economic
   analyses needed for creating business plans are often delayed.  One
   key factor impacting the business plan is architecture.  The solution
   will be considered and then adopted so as to implement the most
   efficient architecture for each operator.  In other words, the
   Service Provider who wants to ensure long-term viability must place
   greater emphasis on the economic impact of IPv6 transition.  The
   author expect that IETF has great interest in this approach given its
   engineering and standardization work.  Moreover, sharing the
   considerations described in this document would be helpful to
   operators who are in similar circumstances.


2.  Transition overview and current status

   Various transition use-cases have been published.

   [I-D.huang-v6ops-v4v6tran-bb-usecase]
   [I-D.lee-v6ops-tran-cable-usecase]
   [I-D.tsou-v6ops-mobile-transition-guide] [I-D.sunq-v6ops-ivi-sp]

   IPv6 transition guideline document
   [I-D.arkko-ipv6-transition-guidelines] presents four deployment
   models.  As our ultimate goal is the IPv6 only network, our strategy
   to achieving it is: (1) provide IPv6 connectivity to the existing
   IPv4-Only network, (2) build new IPv6-Only network, (3) migrate our
   customers from the IPv4-Only network to the IPv6-Only network.  Along
   with the guideline, we had studied the "Crossing IPv4 Islands" model
   in the guideline to realize (1), while performing (2) in parallel.
   Subsequently, we started studying the "IPv6-Only Core Network" model
   to achieve (3).  Research into a deployment model for our mobile
   network is now in progress.


3.  Experience of IPv4-only Network and Assessment Approach

   Our starting point is ensuring that the IPv4-Only network can provide
   IPv6 connectivity.  Since our final goal is to build a IPv6-only
   network and migrate all customers to the network, we will not have to
   accommodate new customers beyond current capacity in the existing
   IPv4-only network.  This means two things for the IPv4-only network;
   one, "minimized additional resources will provided to keep the
   network" and two, "there is less need to conserve IPv4 addresses in



Matsushima, et al.     Expires September 30, 2011               [Page 3]


Internet-Draft  4rd transition considerations experience      March 2011


   the network".  As the guideline document pointed out, many "IPv6 over
   IPv4 tunneling" solutions have already been developed.  Our criterion
   for adopting the best solution involves not only technical pros/cons,
   but also the cost efficiency of providing IPv6 connectivity to all
   customers in the IPv4-only networks.

   When the total capital and operational expense of the system is
   represented as "Q", and the number of customers that can be served by
   the system as "T", the metric of cost efficiency, "S", is given by
   the following simple formula:

   S=Q/T

   We gathered the S values of all candidate products and solutions, and
   decided to adopt the solution that had the lowest S value.  Ignoring
   the price difference between the products, the stateful solutions
   have S values that are significantly different from those of the
   stateless solutions.  In stateful solutions, T is the total number of
   system capable sessions divided by the number of sessions per
   customer.  In stateless solutions, on the other hand, T is the total
   amount of system bandwidth capacity divided by the bandwidth
   consumption per customer.

   From our experience, S(A) < S(B), that is, S(A) is always more
   efficient than S(B) (note S(A) is stateless, S(B) is stateful).  We
   consequently adopt 6rd [RFC5969] for IPv4-only network.  As the
   guideline document points out, it is not productive to implement an
   optimal IPv6 transition system as a temporary solution with goal of
   rich functionality.  Many service providers hope that by allocating
   more resource they can increase network performance, bandwidth
   capacity, and the coverage of their network.  In other words, we, as
   a service provider, want to minimize the resources allocated to such
   temporary solutions.


4.  Considerations for IPv6-Only network

   Our considerations suggest that a stateless solution should be
   adopted for the IPv6-only network to minimize overall resource
   allocation and to allocate resources to the more productive areas.
   In one of IPv6-only network deployment scenario, routing and
   addressing lie outside our control except for our own prefix, which
   is assigned to the customers who connect to the network.  It seems
   like relation of operators among wholesale and retail.  In that
   network, it is difficult to avoid assigning well known and other
   operator owned IPv4 prefixes if the stateless solution uses the 32bit
   IPv4 address to IPv6 address mapping technique.  The solution must
   meet the requirements of: (1) The routing path for IPv4 should match



Matsushima, et al.     Expires September 30, 2011               [Page 4]


Internet-Draft  4rd transition considerations experience      March 2011


   the optimized IPv6 routing path, (2) It should be capable to share
   one IPv4 address among customers since the number of IPv4 addresses
   is insufficient, (3) It must be stateless.  We will adopt the
   solution that satisfies these three requirements.  According to
   [I-D.sun-intarea-4rd-applicability], there are significant
   characteristics in particular these three requirements are satisfied.
   It is noted that since some customers require a service which no
   address sharing, a non-address sharing solution is also needed, but
   this does not need to be the same as the address sharing solution.

   The guideline document describes that Dual-Stack-lite
   [I-D.ietf-softwire-dual-stack-lite] is recommended only as a
   transition solution on the way to the IPv6-only network.  Compared to
   other deployment scenarios such as crossing IPv4 island and IPv6-only
   deployment, there are several candidate solutions for each deployment
   model but only one solution for the scenario.  It is noted that the
   solutions not mentioned in the guideline are discussed in
   [I-D.dec-stateless-4v6], which adopt 4rd [I-D.despres-intarea-4rd]
   and dIVI [I-D.xli-behave-divi].


5.  Considerations for Mobile network

   We believe that the requirements explained in the previous section
   should be applied to the mobile network as well.  [TR23.975], has
   clarified the IPv6-only deployment model in the guideline as a IPv6
   transition scenario.  As [I-D.arkko-ipv6-only-experience] pointed
   out, the operators' policy of service quality assurance may require
   the solution of avoiding the IPv4 referral issue
   [I-D.ietf-behave-v4v6-bih]

   It is interesting that stateless address mapping techniques exist for
   both encapsulation/decapsulation and translation in the case of IPv4
   crossing IPv6-only network model.  This means that, the requirements
   listed in previous section could be achieved for the mobile network.


6.  Conclusions

   One of most significant areas that remain to be investigated is the
   physical resources of our network.  We also need to minimize the
   investments needed to secure the IP transition (i.e. the temporary
   solutions) because we believe that the ultimate goal of the
   transition must be the long-term viability of the Internet and also
   the provision of our services.  To ensure that, our considerations
   yielded the conclusion that the stateless solution should be
   specified for all deployment models in the guideline document.  It is
   recommended that IETF standardize on stateless solutions for not only



Matsushima, et al.     Expires September 30, 2011               [Page 5]


Internet-Draft  4rd transition considerations experience      March 2011


   the IPv4-only network, but also both the IPv6-only network and Ipv6-
   only deployment models in the guideline.


7.  Security considerations

   A stateless solution without the appropriate implementation and
   operation techniques would be vulnerable to denial of service
   attacks, routing loops, spoofing, and other such malicious acts.  To
   eliminate these security vulnerabilities, a stateless solution, like
   6rd, which is capable of validating consistency of IPv6 source
   address with IPv4 source address, can be used to avoid these
   vulnerabilities, based on its address mapping rule.  If a stateless
   solution supports IPv4 address sharing, it must take into account the
   issues described in [I-D.ietf-intarea-shared-addressing-issues].  If
   an operator is concerned about the unnecessary bandwidth consumption
   created by unwanted packets from the outside, one recommended
   solution is to implement appropriate firewall protection for not only
   v4v6 transition solution, but also both native IPv4 and IPv6
   networks.


8.  Acknowledgements

   The authors would like to thank the guideline document of IPv6
   transition [I-D.arkko-ipv6-transition-guidelines], which guides us
   through the transition way, and has motivated the authors to write
   this document.  We also would like to thank Miwa Fujii for her
   helpful suggestions and supports to share our experience with many
   people.


9.  References

9.1.  Normative References

   [I-D.arkko-ipv6-transition-guidelines]
              Arkko, J. and F. Baker, "Guidelines for Using IPv6
              Transition Mechanisms during IPv6 Deployment",
              draft-arkko-ipv6-transition-guidelines-14 (work in
              progress), December 2010.

9.2.  Informative References

   [I-D.arkko-ipv6-only-experience]
              Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", draft-arkko-ipv6-only-experience-02 (work in
              progress), October 2010.



Matsushima, et al.     Expires September 30, 2011               [Page 6]


Internet-Draft  4rd transition considerations experience      March 2011


   [I-D.dec-stateless-4v6]
              Dec, W., "Stateless 4Via6 Address Sharing",
              draft-dec-stateless-4v6-01 (work in progress), March 2011.

   [I-D.despres-intarea-4rd]
              Despres, R., Matsushima, S., Murakami, T., and O. Troan,
              "IPv4 Residual Deployment across IPv6-Service networks
              (4rd) ISP-NAT's made optional",
              draft-despres-intarea-4rd-01 (work in progress),
              March 2011.

   [I-D.huang-v6ops-v4v6tran-bb-usecase]
              Huang, C., Li, X., and L. Hu, "Use Case For IPv6
              Transition For a Large-Scale Broadband network",
              draft-huang-v6ops-v4v6tran-bb-usecase-01 (work in
              progress), October 2010.

   [I-D.ietf-behave-v4v6-bih]
              Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts
              Using "Bump-in-the-Host" (BIH)",
              draft-ietf-behave-v4v6-bih-03 (work in progress),
              March 2011.

   [I-D.ietf-intarea-shared-addressing-issues]
              Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing",
              draft-ietf-intarea-shared-addressing-issues-05 (work in
              progress), March 2011.

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work
              in progress), March 2011.

   [I-D.lee-v6ops-tran-cable-usecase]
              Lee, Y. and V. Kuarsingh, "IPv6 Transition Cable Access
              Network Use Cases", draft-lee-v6ops-tran-cable-usecase-00
              (work in progress), October 2010.

   [I-D.sun-intarea-4rd-applicability]
              Sun, C., Matsushima, S., and J. Jiao, "4rd Applicability
              Statement", draft-sun-intarea-4rd-applicability-01 (work
              in progress), March 2011.

   [I-D.sunq-v6ops-ivi-sp]
              Sun, Q., Xie, C., Li, X., Bao, C., and M. Feng,
              "Considerations for Stateless Translation (IVI/dIVI) in



Matsushima, et al.     Expires September 30, 2011               [Page 7]


Internet-Draft  4rd transition considerations experience      March 2011


              Large SP Network", draft-sunq-v6ops-ivi-sp-02 (work in
              progress), March 2011.

   [I-D.tsou-v6ops-mobile-transition-guide]
              ZOU), T. and T. Taylor, "IPv6 Transition Guide For A Large
              Mobile Operator",
              draft-tsou-v6ops-mobile-transition-guide-00 (work in
              progress), October 2010.

   [I-D.xli-behave-divi]
              Li, X., Bao, C., and H. Zhang, "Address-sharing stateless
              double IVI", draft-xli-behave-divi-01 (work in progress),
              October 2009.

   [I-D.ymbk-aplusp]
              Bush, R., "The A+P Approach to the IPv4 Address Shortage",
              draft-ymbk-aplusp-09 (work in progress), February 2011.

   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
              Framework", RFC 5565, June 2009.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.

   [TR23.975]
              "3GPP, IPv6 migration guidelines",
              <http://www.3gpp.org/ftp/specs/html-info/23975.htm>.


Authors' Addresses

   Satoru Matsushima
   Softbank Telecom
   Tokyo Shiodome Building
   1-9-1,Higashi-Shibashi,Minato-Ku
   Tokyo  105-7322
   JAPAN

   Email: satoru.matsushima@tm.softbank.co.jp











Matsushima, et al.     Expires September 30, 2011               [Page 8]


Internet-Draft  4rd transition considerations experience      March 2011


   Yuji Yamazaki
   Softbank Mobile
   Tokyo Shiodome Building
   1-9-1,Higashi-Shibashi,Minato-Ku
   Tokyo  105-7322
   JAPAN

   Email: yuyamaza@bb.softbank.co.jp


   Chunfa Sun
   Softbank BB
   Tokyo Shiodome Building
   1-9-1,Higashi-Shibashi,Minato-Ku
   Tokyo  105-7322
   JAPAN

   Email: c-sun@bb.softbank.co.jp


   Masato Yamanishi
   Softbank BB
   611 Wilshire Blvd., Suite 400
   Los Angeles, CA
   USA

   Email: myamanis@bb.softbank.co.jp


   Jie Jiao
   Softbank BB
   Tokyo Shiodome Building
   1-9-1,Higashi-Shibashi,Minato-Ku
   Tokyo  105-7322
   JAPAN

   Email: j-jiao@bb.softbank.co.jp














Matsushima, et al.     Expires September 30, 2011               [Page 9]