Internet Engineering Task Force S. Matsushima
Internet-Draft Y. Yamazaki
Intended status: Informational C. Sun
Expires: September 8, 2011 Softbank
March 7, 2011
Use Case and consideration of IPv4 IPv6 transition for Quadro play
operator in Japan
draft-matsushima-v6ops-transition-experience-00
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 8, 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
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
Matsushima, et al. Expires September 8, 2011 [Page 1]
Internet-Draft 4rd transition considerations experience March 2011
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 8, 2011 [Page 2]
Internet-Draft 4rd transition considerations experience March 2011
1. Introduction
IPv4 to IPv6 transition solutions are becoming more unified. 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 don't have to
accommodate new customers in the existing IPv4-only network. This
means two things for the IPv4-only network; one, "no additional
resources will provided to the network" and two, "there is less need
to conserve IPv4 addresses in the network". As the guideline
Matsushima, et al. Expires September 8, 2011 [Page 3]
Internet-Draft 4rd transition considerations experience March 2011
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 8, 2011 [Page 4]
Internet-Draft 4rd transition considerations experience March 2011
the optimized IPv6 routing path, (2) It should be possible 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. 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-softwire-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 tunneling and translation. 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
the IPv4-only network, but also both the IPv6-only network and Ipv6-
only deployment models in the guideline.
Matsushima, et al. Expires September 8, 2011 [Page 5]
Internet-Draft 4rd transition considerations experience March 2011
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 inspecting individual packets, 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 writers of the guideline document
of IPv6 transition [I-D.arkko-ipv6-transition-guidelines], which has
motivated the authors to write this document.
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.
[I-D.dec-stateless-4v6]
Dec, W., "Stateless 4via6 Address Sharing",
draft-dec-stateless-4v6-00 (work in progress), March 2011.
[I-D.despres-softwire-4rd]
Despres, R., "IPv4 Residual Deployment across IPv6-Service
networks (4rd) A NAT-less solution",
Matsushima, et al. Expires September 8, 2011 [Page 6]
Internet-Draft 4rd transition considerations experience March 2011
draft-despres-softwire-4rd-00 (work in progress),
October 2010.
[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-02 (work in progress),
January 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-03 (work in
progress), February 2011.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
Y., and R. Bush, "Dual-stack lite broadband deployments
post IPv4 exhaustion",
draft-ietf-softwire-dual-stack-lite-03 (work in progress),
February 2010.
[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.sunq-v6ops-ivi-sp]
Sun, Q., Wang, H., Li, X., Bao, C., and M. Feng,
"Considerations for Stateless Translation (IVI/dIVI) in
Large SP Network", draft-sunq-v6ops-ivi-sp-01 (work in
progress), October 2010.
[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),
Matsushima, et al. Expires September 8, 2011 [Page 7]
Internet-Draft 4rd transition considerations experience March 2011
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
Tokyo Shiodome Building
1-9-1,Higashi-Shibashi,Minato-Ku
Tokyo 105-7322
JAPAN
Email: satoru.matsushima at tm.softbank.co.jp
Yuji Yamazaki
Softbank
Tokyo Shiodome Building
1-9-1,Higashi-Shibashi,Minato-Ku
Tokyo 105-7322
JAPAN
Email: yuyamaza at bb.softbank.co.jp
Matsushima, et al. Expires September 8, 2011 [Page 8]
Internet-Draft 4rd transition considerations experience March 2011
Chunfa Sun
Softbank
Tokyo Shiodome Building
1-9-1,Higashi-Shibashi,Minato-Ku
Tokyo 105-7322
JAPAN
Email: c-sun at bb.softbank.co.jp
Matsushima, et al. Expires September 8, 2011 [Page 9]