Network Working Group C. Xie
Internet-Draft Q. Sun
Intended status: Informational China Telecom
Expires: January 2, 2015 JF. Tremblay
Viagenie
July 1, 2014
Use case of IPv6 transition in APONF
draft-sun-aponf-openv6-use-cases-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 software defined unifying approach
would provide a unified way to deploy IPv6 in a cost-effective,
flexible manner.
This document describes use cases of IPv6 transition (Openv6) and
also requirements in APONF architecture.
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 January 2, 2015.
Xie, et al. Expires January 2, 2015 [Page 1]
Internet-Draft Use case of IPv6 transition in aponf July 2014
Copyright Notice
Copyright (c) 2014 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. IPv6 transition 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 . . . . . . . . . . . . 4
3.4. Virtualized Computing Resource Management . . . . . . . . 5
3.5. Transition Function Openness to Third-party Applications 5
3.6. ISP Customers Opt-out for Transition Mechanisms . . . . . 6
3.6.1. Failure Modes for Transition Mechanisms . . . . . . . 6
3.6.2. Failure Modes for Native Deployments . . . . . . . . 6
3.6.3. Application-driven Opt-out Mechanism for ISPs . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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.
This document describes use cases of IPv6 transition (Openv6) and
also requirements in APONF architecture.
Xie, et al. Expires January 2, 2015 [Page 2]
Internet-Draft Use case of IPv6 transition in aponf July 2014
2. Terminology
3. IPv6 transition 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.[Reference-Mark]
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,
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 requirements are:
1. The Transition Data Plane should be flexible to deal with
different scenarios and different mechanisms.
Xie, et al. Expires January 2, 2015 [Page 3]
Internet-Draft Use case of IPv6 transition in aponf July 2014
2. The Transition Control Plane should be able to notify the
Transition Data Plane with its desired scenario. It is also have
the ability to collect the current status from the running
Transition Devices.
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 issues. Operators will need to offer 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 (even in the same device).
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 requirements in multiple transition co-existence mainly lie
in two aspects:
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.
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
Xie, et al. Expires January 2, 2015 [Page 4]
Internet-Draft Use case of IPv6 transition in aponf July 2014
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 major requirements are:
The management plane should have the ability to configure the
address pools for different mechanisms centralized.
The management plane should be able to send the address pool
information to the transition devices.
3.4. Virtualized Computing Resource Management
Many IPv6 transition mechanisms (e.g. DS-Lite, CGN, etc.) would need
to consume a lot of computing resources to maintain a large number of
session tables. However, since the number of concurrent subscribers
may vary during different periods of time, it will be more flexible
to manage the computing resouces centrally. For example, we may add
more computing resources when current resouces are not enough and
release back to the resource pool if not necessary.
The major reuiqrements are :
The management plane is able to allocate and withdrawn the
computing resource for certain v6transition traffic.
The management plane is able to request more resources for certain
v6transition traffic.
3.5. Transition Function Openness to Third-party Applications
In migration from IPv4 to IPv6, some transition functionalities may
be opened to Third-party ICPs. For example, the NAT traversal
functionality may be opened to Content Providers as a value-added
service. IPv4/IPv6 translation functionality can also be opened to
Content Providers in order to support IPv6 client communicating with
IPv4 peer. It is also possible that one day, OTT providers may rent
Xie, et al. Expires January 2, 2015 [Page 5]
Internet-Draft Use case of IPv6 transition in aponf July 2014
CGN functionality from operators to provide IPv6 access for end-host
subscribers.
Therefore, transition functions are required to have an interface for
third-party applications.
3.6. ISP Customers Opt-out for Transition Mechanisms
While deploying transition scenarios detailed in section 3.1, such as
6RD, DS-Lite, NAT444 or NAT64, ISPs may not be able to reach 100%
end-user coverage for a specific mechanism. Some failure modes exist
for diverse end-user equipment, mechanisms and applications,
depending if the deployment is done over a very homogenous or diverse
user base and device population. Failure modes may also exist for
dual - stack deployments or native IPv6 without transition
mechanisms.
3.6.1. Failure Modes for Transition Mechanisms
Device-based failure may be caused by inexistent or partial
implementations in user CPE devices (aka home routers). For example,
some off-the-shelf home routers implement 6RD partially, sometimes
with or without DHCPv4 option 212 support. In the former case, 6RD
failure may result from wrong 6RD parameters entered manually by a
user. In the latter case, failure may happen from partial
implementations of the 6RD specifications [RFC5969] for example those
without support for values of IPv4MaskLen larger than zero or when
the IPv6 MTU is not reduced in IPv6 Router Advertisements (RA).
For DS-Lite and NAT444, failure modes are usually application-related
and are introduced through the presence of the additional IPv4
Network Address Translation (NAT) function in the provider network.
These application may not support the interaction of with the ISP NAT
device such as Port Control Protocol [RFC6887].
For NAT64 deployments, failure modes are also often application-based
or destination-specific and therefore can't be detected at the time
of provisioning. Such cases includes the presence of IPv4-only
applications on the end-host (a mobile UE for example) without the
presence of of a local CLAT/646XLAT implementation [RFC6877]. Other
failure modes may be present if the DNS64 function shows difficulties
for the synthesis of an IPv4-only server entry.
3.6.2. Failure Modes for Native Deployments
Failure modes for native deployments include those for IPv6-only
deployments and dual-stack deployments. Reasons for failures are
various and include improper implementations of DHCPv6 and DHCPv6-PD
Xie, et al. Expires January 2, 2015 [Page 6]
Internet-Draft Use case of IPv6 transition in aponf July 2014
in customer-grade home routers, improper or absent handling of IPv6
DNS in Router Advertisement or local DHCPv6, absent or defective
DHCPv6 server implementation on the LAN side, etc. For example,
early DHCPv6-PD implementations did not support delegated prefixes
shorter than a /64 and would show erratic behaviour (such as RAs with
prefixes advertisements longer than /64 on the LAN) or failure to
operate in IPv6.
Such defective implementations exist now in customer-grade equipment
that may not be updated by newer software versions during their
lifetime, if a newer non-defective firmware exists at all. These
defective implementation may lead to invalid IPv6 configurations on
hosts, causing delays or application breakage, especially if Happy
Eyeballs [RFC6555] type fallback is not implemented.
3.6.3. Application-driven Opt-out Mechanism for ISPs
In the cases mentioned above, it may be optimal for the ISP to allow
the user or the application to opt-out dynamically from the
transition mechanism or request access to the original native version
of the access provisioning (such as standard NAT44, native IPv6 or
through dual-stack IPv6). Whether the access to such a feature is
linked to the ISP billing scheme, such as a specific tier or paid
add-on service, is out-of scope for the present document but could be
considered by the ISP.
For example, customers who host PC or console-based gaming servers
and are affected by the deployment of mechanisms such as NAT444 or
DS-Lite could choose to get a public address for their server based
on a specific time-frame and other application-based requirements
such as required latency, QoS and bandwidth. Other examples include
real-time chat or video-conferencing applications that could signal
their requirements to the network, which would then select an optimal
transition mechanism based on them.
4. Security Considerations
5. Acknowledgements
N/A.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Xie, et al. Expires January 2, 2015 [Page 7]
Internet-Draft Use case of IPv6 transition in aponf July 2014
6.2. Informative References
[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.
[RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
"Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674,
July 2012.
Authors' Addresses
Chongfeng Xie
China Telecom
No.118 Xizhimennei street, Xicheng District
Beijing 100035
P.R. China
Email: xiechf@ctbri.com.cn
Xie, et al. Expires January 2, 2015 [Page 8]
Internet-Draft Use case of IPv6 transition in aponf July 2014
Qiong Sun
China Telecom
No.118 Xizhimennei street, Xicheng District
Beijing 100035
P.R. China
Email: sunqiong@ctbri.com.cn
JF Tremblay
Viagenie
Email: jean-francois.tremblay@viagenie.ca
Xie, et al. Expires January 2, 2015 [Page 9]