Network Working Group Q. Sun
Internet-Draft China Telecom
Intended status: Informational W. Liu
Expires: April 24, 2014 C. Zhou
Huawei Technologies
October 21, 2013
Problem Statement for Openv6 Scheme
draft-sun-openv6-problem-statement-00
Abstract
The IPv6 transition has been an ongoing process throughout the world
due to the exhaustion of the IPv4 address space. However, this
transition leads to costly end-to-end network upgrades and poses new
challenges of managing a large number of devices with a variety of
transitioning protocols. While IPv6 transition tools exist, there
are still new issues exist. Operators may need various types of IPv6
transition technologies depending on performance requirements,
deployment scenarios, etc.
To address these difficulties, a unifying approach would provide a
unified way to deploy IPv6 in a cost-effective, flexible manner.
This document describes issues for deploying multiple transition
technologies during the whole IPv6 transition period. It also
discusses potential technical gaps to achieve this work.
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 April 24, 2014.
Copyright Notice
Sun, et al. Expires April 24, 2014 [Page 1]
Internet-Draft Openv6 Problem Statement October 2013
Copyright (c) 2013 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Unified Openv6 Use case . . . . . . . . . . . . . . . . . . . 3
3.1. Evolve from one Scenario to Another . . . . . . . . . . . 3
3.2. Multiple Transition Mechanisms Co-Exist . . . . . . . . . 4
3.3. Scattered Address Pool Management . . . . . . . . . . . . 5
3.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5
4. Coexistence of IPv6 Transition Technologies . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The exhaustion of the IPv4 address space has been a practical problem
that providers are facing today. Network address migration to IPv6
is ongoing or upcoming throughout the world. However, IPv6 requires
costly end-to-end network upgrades and different network scenarios
will co-exist during IPv6 transition. Therefore, operators have to
upgrade network devices to support different transition tools, or buy
new devices for different scenarios.
Sun, et al. Expires April 24, 2014 [Page 2]
Internet-Draft Openv6 Problem Statement October 2013
It is more efficient to unify the transition technologies thanks to a
Transition Data Plane (TDP). The TDP deals with flow-table mapping
and is unaware of specific transition technologies. The service-
awareness is provided by a Transition Management Server (TMS). The
TMS uses IPv6 Transition Service Modules (ITSM) to know the
characteristics of each technology. Finally, the TMS provides a
Northbound Interface (NBI) that enables the ITSM to manipulate the
traffic for different scenarios. This approach unifies the variety
of IPv6 transition mechanisms in a cost-effective, flexible manner.
This document describes issues arising from deploying multiple
transition technologies during the whole IPv6 transition period. It
also discusses potential technical gaps for the unified solution.
2. Terminology
3. Unified Openv6 Use case
3.1. Evolve from one Scenario to Another
During the IPv6 transition period, the network needs three stages of
IPv4-only, dual-stack and IPv6-only. The networks should support
both IPv4 services and IPv6 services at each
stage.[One-vision-for-IPv6]
There are multiple IPv6 transition technologies for different network
scenarios (e.g. IPv4 network for IPv4/IPv6 user access, IPv6 network
for IPv4/IPv6 user access, IPv4 servers for IPv6 visitors, etc.).
Different network scenarios will co-exist during IPv6 transition
which means the IPv6 transition device should support multiple IPv6
transition technologies. The following are possible scenarios in the
whole IPv6 transition period.
1)Scenario 1: IPv6 host visit IPv6 servers via IPv4 access network
2)Scenario 2: IPv4 host visit IPv4 servers via IPv4 NAT Dual-stack
network
3)Scenario 3: IPv6 host visit IPv6 servers via IPv6 network
4)Scenario 4: IPv4 host visit IPv4 servers via IPv6 access network
5)Scenario 5: IPv6 host visit IPv6 servers via IPv4 access network
6)Scenario 6: IPv4 host and IPv6 host interaction
It is not necessary that every operator will go through each scenario
one by one. For example, some operators may start from scenario 1,
Sun, et al. Expires April 24, 2014 [Page 3]
Internet-Draft Openv6 Problem Statement October 2013
and some may start directly from scenario 2 or scenario 4. However,
since the final stage (target) is the IPv6-only access network, one
still need to undergo multiple scenarios from the long term.
In such a case, the operator should either upgrade existing devices
to support new features, or replace them with new ones. In
particular, when the operator's network consists of devices from
different vendors, it is hard to guarantee that all the legacy
devices can be upgraded at the same time. This is costly and
complicated.
The issues are:
1. How to manipulate Transition Data Plane(TDP) with different
modes?
2. How to identify the capabilities of different transition
devices ?
3. How does the Transition Data Plane (TDP) identify different
modes in the unified platform ?
3.2. Multiple Transition Mechanisms Co-Exist
In transition from one scenario to another, different transition
mechanisms may have different impacts on user experience. For
example, DS-Lite would have some impact due to address sharing
compared to 6rd mechanisms, and NAT64 would have extra impact due to
ALG issue. Operators may prepare a fallback mechanism to guarantee
the same level of user experience when there are complaints from
subscribers. Therefore, it is required to support multiple
transition mechanisms in the same area.
Another use case is that multiple scenarios may exist in the same
stage. For example, if there are both IPv6-only devices and
IPv4-only host in the same area with limited public IPv4 address,
both NAT64 and NAT44 (or DS-Lite) are required to achieve IPv4
service connectivity.
Current implementations normally use a separate instance for each
mechanism,, and additional policies need to be applied when running
multiple mechanisms in one device. Some have a limitation on the
number of policies which can be configured in one device, while some
have restrictions regarding the resource occupation (e.g. one
transition instance will occupy a static amount of memory). The
major challenges of IPv6 deployment mainly lie in two aspects:
Sun, et al. Expires April 24, 2014 [Page 4]
Internet-Draft Openv6 Problem Statement October 2013
The need to implement different IPv6 transition technologies in
the same hardware and the need to support this by upgrading
network devices as little as possible.
The need to hop over legacy infrastructures which are not IPv6
enabled, costly or impossible to upgrade.
The issues are:
1. How to support multiple transition mechanisms in a cost-
efficient and flexible way ?
2. How to easily identify the transition type of different
subscribers ?
3.3. Scattered Address Pool Management
When operators are facing with address shortage problem, the
remaining IPv4 address pools are usually quite scattered. It is
quite complicated for an operator to manage scattered address pools
in many transition devices. The situation will become even worse
when multiple transition mechanisms in the same device need to be
configured with different address pools. Besides, since the
occupation of the address pools may vary during different transition
periods, (e.g. when there is not many IPv6-enabled services and
IPv6-enabled devices, IPv4 traffic will still occupy a great portion
of the total traffic, while in the later stage of IPv6 transition,
IPv4 traffic will decrease and the amount of IPv4 address pools will
decrease accordingly.
The ideal way is to manage the address pools centrally. Different
transition mechanisms can require the address pools on-demand. For
example, when one transition mechanism is running out of the current
address pools,it may request a additional address pool. It can also
release the address pools that it is not using anymore. In this way,
operators do not need to configure the address pools one by one
manually and it also helps using the address pools more efficiently.
The issues are:
1. How to configure the address pools for different mechanisms ?
2. How to collect the current status of address pool usage ?
3.4. Extensibility
In migration from IPv4 to IPv6, different scenarios usually need
different solutions. Although IETF has already invented some
Sun, et al. Expires April 24, 2014 [Page 5]
Internet-Draft Openv6 Problem Statement October 2013
mechanisms including DS-Lite[RFC6333], XLate[RFC6146], BIH[RFC6535],
NAT64[RFC6146], etc., However, the current solutions have solved the
following scenarios only in a limited way:
*IPv4 client communicates to IPv6 server
*IPv4 client communicates to IPv6 peer
It is possible that new technologies will be invented in the future.
In addition, some mechanism are still evolving from a session-based
solution (e.g. DS-Lite) to a more scalable way (e.g. lw4over6, MAP).
It might be possible that operators who have already deployed one
solution may upgrade to a better one in the future. Besides, IPv6
transition can also be regarded as a virtualized network function
which can be offered to a third-party.
Therefore, it is required to offer an open and programmable way to
easily add new features without modifying existing device hardware.
The issues are :
1. How to add a new module to the transition data plane ?
2. How to offer the capability for the possible future technologies?
4. Coexistence of IPv6 Transition Technologies
The different network environments (architecture, scale, services
deployed, varying IP traffic) cause a variety of IPv6 transition
technologies for different operators. This section analyzes the
current and future coexistence of IPv6 transition technologies
situation as well as the issues behind it.
Since IPv6 was proposed, there have been a couple of RFCs and on-
going documents in IETF, as listed in the table below.
+----------+---------+----------------------------------------------+
| status | number | documents |
+----------+---------+----------------------------------------------+
| RFC | 8 or | [RFC5571], [RFC6333], [RFC6674], [RFC5969], |
| | more | [RFC6219], [RFC6535], [RFC6654], [RFC6145], |
| | | ... |
| WG draft | 6 or | [I-D.ietf-softwire-4rd], [I-D.ietf-softwire- |
| | more | map], [I-D.ietf-softwire-map-t], [I-D.ietf- |
| | | softwire-public-4over6], [I-D.ietf-softwire- |
| | | lw4over6], [I-D.ietf-v6ops-464xlat], ... |
| Active | several | ... |
| draft | | |
Sun, et al. Expires April 24, 2014 [Page 6]
Internet-Draft Openv6 Problem Statement October 2013
+----------+---------+----------------------------------------------+
Table 1: A Table of IPv6 Transition Technologies @ IETF
The situation described above depicts the difficulty of selecting
appropriate IPv6 transition technologies for the carriers. Moreover,
according to [SD-NAT], there are multiple stages during the whole
IPv6 transition period, and a variety of technologies and equipments
are used during different IPv6 transition stages. To protect the
user experience and the early investment, an operator will not
upgrade its network directly to the final stage of IPv6 transition.
During different IPv6 transition stages, an operator needs different
technologies in different stages. Thus, a method that is able to
implement different IPv6 transition technologies in the same hardware
is crucial, to avoid repeated investments.
5. Security Considerations
6. Acknowledgements
N/A.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[I-D.ietf-softwire-4rd]
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd)", draft-ietf-softwire-4rd-07 (work in
progress), October 2013.
[I-D.ietf-softwire-lw4over6]
Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
I. Farrer, "Lightweight 4over6: An Extension to the DS-
Lite Architecture", draft-ietf-softwire-lw4over6-01 (work
in progress), July 2013.
[I-D.ietf-softwire-map-t]
Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work
in progress), September 2013.
Sun, et al. Expires April 24, 2014 [Page 7]
Internet-Draft Openv6 Problem Statement October 2013
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-08
(work in progress), August 2013.
[I-D.ietf-softwire-public-4over6]
Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
IPv4 over IPv6 Access Network", draft-ietf-softwire-
public-4over6-10 (work in progress), July 2013.
[I-D.ietf-v6ops-464xlat]
Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", draft-
ietf-v6ops-464xlat-10 (work in progress), February 2013.
[One-vision-for-IPv6]
Mark Townsley, "One vision for IPv6", .
[RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B.,
Toutain, L., and J. Tremblay, "Softwire Hub and Spoke
Deployment Framework with Layer Two Tunneling Protocol
Version 2 (L2TPv2)", RFC 5571, June 2009.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", RFC
5969, August 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
China Education and Research Network (CERNET) IVI
Translation Design and Deployment for the IPv4/IPv6
Coexistence and Transition", RFC 6219, May 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.
[RFC6654] Tsou, T., Zhou, C., Taylor, T., and Q. Chen, "Gateway-
Initiated IPv6 Rapid Deployment on IPv4 Infrastructures
(GI 6rd)", RFC 6654, July 2012.
Sun, et al. Expires April 24, 2014 [Page 8]
Internet-Draft Openv6 Problem Statement October 2013
[RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
"Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674,
July 2012.
[RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
"Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674,
July 2012.
[SD-NAT] Alain Durand, "SD-NAT", ,
<http://www.ietf.org/proceedings/82/slides/behave-10.pdf>.
Authors' Addresses
Qiong Sun
China Telecom
No.118 Xizhimennei street, Xicheng District
Beijing 100035
P.R. China
Email: sunqiong@ctbri.com.cn
Will(Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: cathy.zhou@huawei.com
Sun, et al. Expires April 24, 2014 [Page 9]