[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-v6ops-dc-ipv6

Network Working Group                                            Z. Chen
Internet-Draft                                             China Telecom
Intended status: Standards Track                                D. Lopez
Expires: September 6, 2012                                Telefonica I+D
                                                                 T. Tsou
                                               Huawei Technologies (USA)
                                                                 C. Zhou
                                                     Huawei Technologies
                                                          March 12, 2012

                          DC Migration to IPv6


   This document describes the issues, possible solutions, and
   opportunities in Data Center (DC) migration from IPv4 to IPv6.  It
   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 deployed on the DC

   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/.

   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 6, 2012.

Chen, et al.            Expires September 6, 2012               [Page 1]

Internet-Draft            DC Migration to IPv6                March 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Maturity Levels . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.  Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Packet Processiong  . . . . . . . . . . . . . . . . . . . . . . 8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Chen, et al.            Expires September 6, 2012               [Page 2]

Internet-Draft            DC Migration to IPv6                March 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

   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 September 6, 2012               [Page 3]

Internet-Draft            DC Migration to IPv6                March 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

Chen, et al.            Expires September 6, 2012               [Page 4]

Internet-Draft            DC Migration to IPv6                March 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), 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

2.  Maturity Levels

   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.  Intra-DC IPv4 infrastructure, with gateway routers (or even
       application gateways when services require so) connecting to the
       IPv6 and IPv4 Internet.  DC network scheme and addressing do not
       require any important change, if any.  Even at this level, some
       implicit advantages of IPv6 application come into play, even if
       they can only be applied at the ingress elements:

       *  Flow labels can be applied to enhance load-balancing.

       *  During VM migration, Mobile IP mechanisms can be applied to
          keep service availability during the transient state.

       *  VM migration among DCs are simplified in what relates to
          address management.

   2.  Intra-DC IPv6 infrastructure, including inter-DC links.  IPv6 is
       deployed up to whatever the layer in the interconnection scheme
       where L3 is applied to packet forwarding, and gateway routers run
       64NAT (or an equivalent mechanism) to connect to the IPv4
       Internet, or rely on Internet providers to do so.  While the
       previous level can be considered a degenerate case of this when
       L3 forwarding is only applied at the external gateways, it is
       important to note that this can only be the case if all L3 packet
       forwarding mechanisms are IPv6-based, including those applied to
       data paths (SAN, for example) or internal management interfaces.

       At this level, the advantages outlined above on flow labels and
       Mobile IP mechanisms are applicable to any L3-based mechanism.
       Itra- as well as inter-DC, they will translate into enhanced VM
       mobility, more effective load balancing, and higher service

Chen, et al.            Expires September 6, 2012               [Page 5]

Internet-Draft            DC Migration to IPv6                March 2012

       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.

   3.  Pervasive IPv6 infrastructure, including full IPv6 hypervisors,
       which perform the appropriate tunneling or NAT if required by
       internal applications running IPv4.  At this level, individual
       services could directly take advantage of the features provided
       by the IPv6 address space and protocols, and probably this would
       imply the usual paradigm of the hypervisor acting as a virtual L2
       switch could be extended.  Independent service mobility could be
       one of the additional functions facilitated at this level.

   Since current deployments and technology best practices are at level
   1, i.e.  IPv4-only DC infrastructures with mostly IPv4 Internet
   Service access, we will concentrate on the issues regarding this
   first maturity level in this memo.  Future documents or versions of
   this document will address in detail the aspects related to higher
   maturity levels.  Nevertheless, a great part of the technology
   proposed in this document could also be applied in these higher IPv6
   migration levels.

3.  Proposed Solution

   In the network topology of DC, the aggregation level provides traffic
   aggregation function for the access level models (e.g., switches).
   For the "Core-Edge" DC network, Firewall (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 Balance, SSL VPN, IPS and etc.) may be deployed in the
   aggregation level to alleviate the burden of the server and to
   guarantee deep security.  Figure 2 provides a typical Internet facing
   application scheme for the Data Center.

Chen, et al.            Expires September 6, 2012               [Page 6]

Internet-Draft            DC Migration to IPv6                March 2012

    |        Internet     |
        |  Gateway |
              .           Core Level
           | FW  |
              |           Aggregation Level
           | LB  |
           _ / \_
          /       \
    +--+--+     +--+--+
    | Web | ... | Web |
    +--+--+     +--+--+
       | \ __ _ _/ |
       | /       \ |
    +--+--+     +--+--+
    |Cache|     | DB  |
    +-----+     +-----+

                 Figure 2: Data Center Application Scheme

   In the first maturity level of Data Center migration mentioned above,
   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 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 the port translation.

Chen, et al.            Expires September 6, 2012               [Page 7]

Internet-Draft            DC Migration to IPv6                March 2012

                           |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 (load-balancer) can be considered
   dividing into two parts: dual-stack part which is facing the
   internet, IPv4 only part which contains the tradition LB function.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 the synchronization is not need
   between LB and DNS64 server.

   The dual-stack part of the LB has a private IPv4 address pool.  When
   IPv6 packets come from internet to DC, the dual-stack part does the
   one-on-one SIP (source IP address) mapping [as defined in [ID.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 part of the LB.

4.  Packet Processiong

5.  Security Considerations

   Come later.

Chen, et al.            Expires September 6, 2012               [Page 8]

Internet-Draft            DC Migration to IPv6                March 2012

6.  IANA Considerations


Authors' Addresses

   Zhonghua Chen
   China Telecom

   Email: 18918588897@189.cn

   Diego R. Lopez
   Telefonica I+D
   Don Ramon de la Cruz, 84
   Madrid  28006

   Phone: +34 913 129 041
   Email: diego@tid.es

   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA  95050

   Phone: +1 408 330 4424
   Email: Tina.Tsou.Zouting@huawei.com

   Cathy Zhou
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: cathy.zhou@huawei.com

Chen, et al.            Expires September 6, 2012               [Page 9]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/