Network Working Group Z. Chen
Internet-Draft China Telecom
Intended status: Standards Track D. Lopez
Expires: December 20, 2012 Telefonica I+D
T. Tsou
Huawei Technologies (USA)
C. Zhou
Huawei Technologies
June 19, 2012
A Reference Framework for DC Migration to IPv6
draft-lopez-v6ops-dc-ipv6-02
Abstract
This document is intended to provide a reference framework for
datacenter operators planning for a migration of their
infrastructures to IPv6. It aims to offer a scheme for evaluating
different products and architectures, and therefore it is also
addressed to manufacturers and solution providers, so they can use it
to gauge their solutions. We believe this will translate in a
smoother and faster transition of these infrastuctures into IPv6
The document focuses on the DC infrastructure itself, its operation,
and the aspects related to DC interconnection through IPv6. It does
not consider the particular mechanisms for making Internet services
provided by applications hosted in the DC available through IPv6
beyond the specific aspects related to how their deployment on the DC
infrastructure.
Apart from facilitating the migration procedure itself, the
mechanisms outlined here are intended to make this migration as
transparent as possible (if not completely transparent) to
applications and services running on the DC infrastructure, as well
as to take advantage of IPv6 features to simplify DC operations,
internally and across the Internet.
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/.
Chen, et al. Expires November 6, 2012 [Page 1]
Internet-Draft DC Migration to IPv6 May 2012
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 November 6, 2012.
Copyright Notice
Copyright (c) 2012 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.
Chen, et al. Expires November 6, 2012 [Page 2]
Internet-Draft DC Migration to IPv6 May 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Maturity Levels . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Maturity Level 1: Native IPv4 Infrastructure . . . . . . . 7
2.2. Maturity Level 2: Internal dual-stacks . . . . . . . . . . 7
2.3. Maturity Level 3: Pervasive IPv6 Infrastrcuture . . . . . 11
3. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Chen, et al. Expires November 6, 2012 [Page 3]
Internet-Draft DC Migration to IPv6 May 2012
1. Introduction
The need for considering the aspects related to IPv4-to-IPv6
migration for all devices and services connected to the Internet has
been widely mentioned elsewhere, and it is not our intention to make
an additional call on it. Just let us note that many of those
services are already or will soon be located in datacenters (DC),
what makes considering the issues associated to DC infrastructure
migration a key aspect both for these infrastructures themselves, and
for providing a simpler and clear path to service migration.
All issues discussed here are related to DC infrastructure migration,
and are intended to be orthogonal to whatever particular mechanisms
for making the services hosted in the DC available through IPv6
beyond the specific aspects related to their deployment on the
infrastructure. Those general mechanisms to service migration have
been discussed in depth elsewhere and are considered to be orthogonal
to the goal of this discussion. Though it is obvious that their
applicability in many cases would depend on the characteristics of
the supporting DC infrastructure, the migration procedures are
intended to keep services as independent as possible of these
processes.
Furthermore, the combination of the regularity and controlled
management in a DC interconnection fabric with IPv6 universal end-to-
end addressing should translate in simpler and faster VM migrations,
either intra- or inter-DC, and even inter-provider.
The diagram in Figure 1 depicts a generalized interconnection schema
in a DC.
Chen, et al. Expires November 6, 2012 [Page 4]
Internet-Draft DC Migration to IPv6 May 2012
| |
+-----+-----+ +-----+-----+
| Gateway | | Gateway | Internet Access
+-----+-----+ +-----+-----+
| |
+---+-----------+
| |
+---+---+ +---+---+
| Core0 | | CoreN | Core
+---+---+ +---+---+
/ \ / /
/ \-----\ /
/ /---/ \ /
+--------+ +--------+
+/-------+ | +/-------+ |
| Aggr01 | +-----| AggrN1 | + Aggregation
+---+---+/ +--------+/
/ \ / \
/ \ / \
+-----+ +-----+ +-----+ +-----+
| T11 |... | T1x | | T21 |... | T2y | Access
+-----+ +-----+ +-----+ +-----+
| HyV | | HyV | | HyV | | HyV | Physical Servers
+:::::+ +:::::+ +:::::+ +:::::+
| VMs | | VMs | | VMs | | VMs | Virtual Machines
+-----+ +-----+ +-----+ +-----+
. . . . . . . . . . . . . . . .
+-----+ +-----+ +-----+ +-----+
| HyV | | HyV | | HyV | | HyV |
+:::::+ +:::::+ +:::::+ +:::::+
| VMs | | VMs | | VMs | | VMs |
+-----+ +-----+ +-----+ +-----+
Figure 1: DC Interconnnection Schema
o Hypervisors provide connection services (among others) to virtual
machines running on physical servers.
o Access elements provide connectivity directly to/from physical
servers. The access elements are typically placed either top-of-
rack (ToR) or end-of-row(EoR).
o Aggregation elements group several (many) physical racks to
achieve local integration and provide as much structure as
possible to data paths.
o Core elements connect all aggregation elements acting as the DC
backbone.
Chen, et al. Expires November 6, 2012 [Page 5]
Internet-Draft DC Migration to IPv6 May 2012
o One or several gateways connecting the DC to the Internet and/or
other DCs through dedicated links.
In many actual deployments, depending on DC size and design
decisions, many of these elements may be combined (core and gateways
are provider by the same routers, or hypervisors act as access
elements) or virtualized to some extent, but this layered schema is
the one that best accommodates the different options to use L2 or L3
at any of the different DC interconnection layers, and will help us
in the discussion along the document.
2. Maturity Levels
The framework is structured along maturity levels, associated with
the degree of penetration of IPv6 into the DC communication fabric.
It is worth noting we are using these levels as a classification
mechanism, and they have not to be associated with any a succession
of steps from a v4-only infrastructure to full-fledged v6, but to
provide a framework that operators, users, and even manufacturers
could use to assess their plans and products.
There is no (explicit or implicit) requirement on starting at level
1, nor to follow them in successive order. According to their needs
and the available solutions, DC operators can choose to start or
remain at a certain level, and freely move from one to another as
they see fit, without contravening this document. In this respect,
the classification intends to support the planning in aspects such as
the adaptation of the different maturity levels to the evolution of
traffic patterns, or risk assessment in what relates to deploying new
components and incorporating change control, integration and testing
in highly-complex multi-vendor infrastructures.
Three main maturity levels can be considered when analyzing IPv6
deployment in the DC infrastructure, all compatible with the
availability of services running in the DC through IPv6:
1. Native IPv4 infrastructure, with gateway routers (or even
application gateways when services require so) performing the
adaptation to requests arriving from the IPv6 Internet.
2. Internal dual stacks, where native IPv6 and IPv4 are present in
the infrastructure, up to whatever the layer in the
interconnection scheme where L3 is applied to packet forwarding
3. Pervasive IPv6 infrastructure, including full IPv6 hypervisors,
which perform the appropriate tunneling or NAT if required by
internal applications running IPv4.
Chen, et al. Expires November 6, 2012 [Page 6]
Internet-Draft DC Migration to IPv6 May 2012
2.1. Maturity Level 1: Native IPv4 Infrastructure
This maturity level corresponds to the first step that many
datacenters may take (or have taken) in order to make their external
services accessible from the IPv6 Internet, and corresponds to IPv6
traffic patterns totally originated out of the DC or their tenants,
being a small percentage of the total external requests. In this
level, DC network scheme and addressing do not require any important
change, if any.
The translation of IPv6 requests into the internal infrastructure
format occurs at the outmost level of the DC Internet connection.
This can be typically achieved at the DC gateway routers, that
support the appropriate address translation mechanisms for those
services required to be accessed through native IPv6 requests. The
policies for applying adaptation can range from performing it only to
a limited set of specified services to providing a general
translation service for all public services. Finer mechanisms, based
on address ranges or more sophisticated dynamic policies are also
possible, as they are applied by a limited set of control elements.
This provides an additional level of control to the usage of IPv6
routable addresses in the DC environment, which can be especially
significant at the early deployment stages.
This model is also suitable to be applied in an "off-shore" mode by
the service provider connecting the DC infrastructure to the
Internet, as described in [I-D.sunq-v6ops-contents-transition]
Even at this level, some implicit advantages of IPv6 application come
into play, even if they can only be applied at the ingress elements:
o Flow labels can be applied to enhance load-balancing, as described
in [I-D.carpenter-v6ops-label-balance]. Incoming IPv6 requests
can take advantage of them, and the gateway systems use them as a
hint for applying load-balancing mechanisms at the IPv4 internal
accesses.
o During VM migration (intra- or even inter-DC), Mobile IP
mechanisms can be applied to keep service availability during the
transient state.
These advantages could potentially be employed to demonstrate the
value in considering a more comprehensive infrastructure migration.
2.2. Maturity Level 2: Internal dual-stacks
This level implies the need for dual-stack elements in some internal
parts of the DC infrastructure. This brings some degree of partition
Chen, et al. Expires November 6, 2012 [Page 7]
Internet-Draft DC Migration to IPv6 May 2012
in the infrastructure, either in a horizontal (when data paths or
management interfaces are migrated or left in IPv4 while the rest
migrate) or a vertical (per tenant or service group), or even both.
Although it may seem an artificial case, situations requiring this
maturity level can arise from differen requirements from the user
base, or the need for technology changes at different points of the
infrastructure, or even the goal of having the possibility of
experimenting new solutions in a controled real-operations
environment. This maturity level can accommodate different traffic
patterns, both internal and external, though it better fits to
scenarios of a clear differentiation of different types of traffic
(external vs internal, data vs management...), and/or a more or less
even distribution of external requests.
At this level, the advantages outlined above on load balancing based
on flow labels and Mobile IP mechanisms are applicable to any L3-
based mechanism (intra- as well as inter-DC). They will translate
into enhanced VM mobility, more effective load balancing, and higher
service availability. Furthermore, the simpler integration provided
by IPv6 to and from the L2 flat space to the structured L3 one can be
applied to achieve simpler deployments, as well as alleviating
encapsulation and fragmentation issues when traversing between L2 and
L3 spaces. With an appropriate prefix management, automatic address
assingment, discovery, and renumbering can be applied not only to
public service interfaces, but most notably to data and management
paths.
Other potential advantages include the application of multicast
scopes to limit broadcast floods, and the usage of specific security
headers to enhance tenant differentiation.
On the other hand, this level requires a much more careful planning
of addressing schemas and access control, according to security
levels. While at level 1 we were talking of relatively few global
routable addresses, at this one the advantages and risks of using
different kinds of addresses at each point of the IPv6-aware
infrastructure.
Chen, et al. Expires November 6, 2012 [Page 8]
Internet-Draft DC Migration to IPv6 May 2012
+---------------------+
| Internet |
+---------+-----------+
|
+-----+----+
| Gateway |
+-----+----+
.
. Core Level
.
+--+--+
| FW |
+--+--+
| Aggregation Level
+--+--+
| LB |
+--+--+
_ / \_
/ \
+--+--+ +--+--+
| Web | ... | Web |
+--+--+ +--+--+
| \ __ _ _/ |
| / \ |
+--+--+ +--+--+
|Cache| | DB |
+-----+ +-----+
Figure 2: Data Center Application Scheme
An initial approach corresponding to this maturity level relies on
taking advantage of specific elements at the aggregation layer
described in Figure 1, and make them able to provide dual-stack
gatewaying to the IPv4-based servers and data infrastructure.
Typically, firewalls (FW) is deployed as the security edge of the
whole service domain and provides safe access control of this service
domain from other function domains. In addition, some application
optimization devices and security devices (e.g.,Load Balancers, SSL
VPN, IPS and etc.) may be deployed in the aggregation level to
alleviate the burden of the server and to guarantee deep security, as
shown in Figure 2.
The load balncer (LB) or some other boxes could be upgraded to
support the data transmission. There may be two ways to achieve this
at the edge of the DC: Encapsulation and NAT. In the encapsulation
case, the LB function carries the IPv6 traffic over IPv4 using an
encapsulation (IPv6-in-IPv4). In the NAT case, there are already
Chen, et al. Expires November 6, 2012 [Page 9]
Internet-Draft DC Migration to IPv6 May 2012
some technologies to solve this problem. For example, DNS and NAT
device could be concatenated for IPv4/IPv6 translation, if IPv6 host
needs to visit IPv4 servers. However, this may require the
concatenation of multiple network devices, which means the NAT tables
needs to be synchronized at different devices. In this document, we
propose a simplified IPv4/IPv6 translation model, which could be
implemented in LB device. The mapping information of IPv4 and IPv6
will be generated automatically based on the information of LB. The
host IP address will be translated without port translation.
+----------+------------------------------+
|Dual Stack| IPv4-only +----------+ |
| | +----|Web Server| |
| +------|------+ / +----------+ |
+--------+ +-------+ | | | | / |
|Internet|--|Gateway|---|---+Load-Balancer+-- \ |
| | | | | | | | \ +----------+ |
+--------+ +-------+ | +------|------+ +----|Web Server| |
| | +----------+ |
+----------+------------------------------+
Figure 3: Dual Stack LB mechanism
As shown in Figure 3,the LB can be considered divided into two parts:
The dual-stack part facing the external border, and the IPv4-only
part which contains the traditional LB functions. The IPv4 DC is
allocated an IPv6 prefix which is for the VSIPv6 (Virtual Service
IPv6 Address). We suggest that the IPv6 prefix is not the well-known
prefix in order to avoid the IPv4 routings of the services in
different DCs spread to the IPv6 network. The VSIPv4 (Virtual
Service IPv4 Address) is embedded in VSIPv6 using the allocated IPv6
prefix. In this way, the LB has the stateless IP address mapping
between VSIPv6 and VSIPv4, and synchronization is not required
between LB and DNS64 server.
The dual-stack part of the LB has a private IPv4 address pool. When
IPv6 packets arrive, the dual-stack part does the one-on-one SIP
(source IP address) mapping (as defined in
[I-D.sunq-v6ops-contents-transition]) between IPv4 private address
and IPv6 SIP. Because there will be too many UDP/TCP sessions
between the DC and Internet, the IP addresses binding tables between
IPv6 and IPv4 are not session-based, but SIP-based. Thus, the dual-
stack part of LB builds IP binding stateful tables for the host IPv6
address and private IPv4 address of the pool. When the following
IPv6 packets of the host come from Internet to the LB, the dual stack
part does the IP address translation for the packets. Thus, the IPv6
packets were translated to IPv4 packets and sent to the IPv4 only
Chen, et al. Expires November 6, 2012 [Page 10]
Internet-Draft DC Migration to IPv6 May 2012
part of the LB.
2.3. Maturity Level 3: Pervasive IPv6 Infrastrcuture
We can consider a DC infrastructure at maturity level 3 when all
network layer elements, including hypervisors, are IPv6-aware and
apply it by default. Conversely with maturity level 1, access from
the IPv4 Internet is achieved, when required, by protocol translation
performed at the edge infrastructure elements, or even supplied by
the service provider as an additional network service.
This level can be of interest for new deployments willing to apply a
fresh start aligned with future IPv6 widespread usage, when a
relevant amount of requests are expected to be using IPv6, or to take
advantage of any of the potential benefits that an IPv6 support
infrastructure can provide. The potential advantages mentioned for
the previous levels (load balancing based on flow labels, mobility
mechanisms for transient states in VM or data migration, controled
multicast, and better mapping of L2 flat space on L3 constructs) can
be applied at any layer, even especially tailored for individual
services. Obviously, the need for a careful planning of address
space is even stronger here, though the centralized protocol
translation services should reduce the risk of translation errors
causing disruptions or security breaches.
[V6DCS] proposes an approach to a maturity level 3 DC deployment,
already demonstrated in practice, and claims the advantages of
achieving level 3 from the beginning, providing some rationale for it
based on simplifying the migration process. It relies on stateless
NAT64 ([RFC6052], [RFC6145]) to enable access from the IPv4 Internet.
3. Security Considerations
Need a further ellaboration, but addressing plan issues (on the
limits to public routable addresses for the whole infrastructure) and
the need for careful configuration of access control rules at the
translation points should be addressed. It must be noted that this
is specially sensitive in the cases of maturity level 2 (as the
translation points are potentially distributed) and when translation
is offered as an external service in maturity levels 1 and 3 (as
there can be operational mismatches).
4. IANA Considerations
None.
Chen, et al. Expires November 6, 2012 [Page 11]
Internet-Draft DC Migration to IPv6 May 2012
5. Acknowledgements
We would like to thank Tore Anderson and Ray Hunter for their
questions and comments.
6. Informative References
[I-D.carpenter-v6ops-label-balance]
Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6
Flow Label for Server Load Balancing",
draft-carpenter-v6ops-label-balance-02 (work in progress),
March 2012.
[I-D.sunq-v6ops-contents-transition]
Sun, Q., Liu, D., Zhao, Q., Liu, Q., Xie, C., Li, X., and
J. Qin, "Rapid Transition of IPv4 contents to be IPv6-
accessible", draft-sunq-v6ops-contents-transition-03 (work
in progress), March 2012.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[V6DCS] "The case for IPv6-only data centres", <https://
ripe64.ripe.net/presentations/
67-20120417-RIPE64-
The_Case_for_IPv6_Only_Data_Centres.pdf>.
Authors' Addresses
Zhonghua Chen
China Telecom
P.R.China
Phone:
Email: 18918588897@189.cn
Chen, et al. Expires November 6, 2012 [Page 12]
Internet-Draft DC Migration to IPv6 May 2012
Diego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 84
Madrid 28006
Spain
Phone: +34 913 129 041
Email: diego@tid.es
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: Tina.Tsou.Zouting@huawei.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathy.zhou@huawei.com
Chen, et al. Expires November 6, 2012 [Page 13]