Internet DRAFT - draft-sarikaya-softwire-dslite4cloud
draft-sarikaya-softwire-dslite4cloud
Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track October 17, 2011
Expires: April 19, 2012
Dual Stack Lite and 4rd for Migrating Cloud Networks to IPv6
draft-sarikaya-softwire-dslite4cloud-00.txt
Abstract
This document specifies how Dual Stack Lite or 4rd can be used to
support IPv4 users in a cloud network that is IPv6 based. The cloud
network is IPv6 only which simplifies the network operation and
management. IPv4 users are supported either one of the transition
technologies of DS-Lite or 4rd. This protocol is ideal for new cloud
deployments since no new public IPv4 addresses are needed.
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 19, 2012.
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
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
Sarikaya Expires April 19, 2012 [Page 1]
Internet-Draft DS Lite and 4rd for Cloud October 2011
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. DS-Lite Architecture . . . . . . . . . . . . . . . . . . . 4
4.2. 4rd Architecture . . . . . . . . . . . . . . . . . . . . . 5
5. DS-Lite Operation . . . . . . . . . . . . . . . . . . . . . . 7
5.1. DS-Lite for Datacenter Considerations . . . . . . . . . . 8
6. 4rd Operation . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. 4rd for Datacenter Considerations . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative references . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Sarikaya Expires April 19, 2012 [Page 2]
Internet-Draft DS Lite and 4rd for Cloud October 2011
1. Introduction
Data center/cloud networks are being increasingly used by telecom
operators as well as by enterprises. Currently these networks are
using IPv4 addressing. However due to the depletion of public IPv4
addresses this practice can not go on indefinitely.
In this document we argue that data center/cloud network should use
IPv6. If IPv6 is used then it becomes an issue how to support IPv4
users which we address in this document. For this purpose dual stack
lite [RFC6333] or 4rd [I-D.murakami-softwire-4rd],
[I-D.xli-behave-divi], [I-D.despres-softwire-4rd] can be used.
Dual stack lite has two elements: Basic Bridging BroadBand (B4)
element which receives privately addressed IPv4 packets from the
users and encapsulates them in IPv6 and sends them to the Dual Stack
Lite Address Family Transition Router (AFTR) element which is in
charge of a central Network Address Translation (NAT) for the whole
cloud network. Packets received from public IPv4 network by AFTR are
tunneled to the destination B4s after NAT operation in IPv6. B4
decapsulates the packet and delivers it to the user.
4rd has two elements: Customer Edge (CE) device/router receives
privately addressed IPv4 packets from the users and after a NAT
operation sends them to the Border Relay (BR) either encapsulated
using IPv4-in-IPv6 encapsulation or translated into IPv6. BR
decapsulates or translates the packet before sending to IPv4 network.
The operation is stateless and the next packet from CE may be sent to
another BR.
In current data center deployments IPv4 is being used and
[I-D.sakura-6rd-datacenter] describes how IPv6 service can be
supported. IPv6 Rapid Deployment (6rd) [RFC5969] is used where 6rd
CE is located at the servers and 6rd Border Relay is located at the
backbone network.
2. Terminology
This document uses the terminology defined in [RFC6333] and in
[RFC6333] or 4rd [I-D.murakami-softwire-4rd], [I-D.xli-behave-divi],
[I-D.despres-softwire-4rd].
3. Requirements
This section states requirements on data center/cloud network IPv4
and IPv6 support protocol.
Sarikaya Expires April 19, 2012 [Page 3]
Internet-Draft DS Lite and 4rd for Cloud October 2011
Data center/cloud network MUST support IPv6 natively due to the
depletion of public IPv4 addresses.
IPv4 support SHOULD enable direct routing among the geographically
distributed data centers of the same network.
IPv4 support SHOULD minimize the use of public IPv4 addresses.
Network address translation (NAT) could be used on the customer side.
4. Architecture
Data center/cloud networks consists of thosands of servers in one
center and usually an organization operates more than one data center
each connected by a backbone IP network. Each server runs multiple
Virtual Machines (VM) each with its own IP address. Data center
could be Layer-2 based or Layer-3 based.
Datacenter is Layer-3 based if packets are routed among the subnets,
e.g. in between the racks and switched in a subnet, e.g. inside a
rack. Layer-3 based datacenter networks scale well for address
resolution protocols like ARP but they make is difficult to move
Virtual Machines as some sort of tunneling would be needed
[I-D.wkumari-dcops-l3-vmmobility].
Datacenter is Layer-2 based if packets are switched inside a rack and
bridged among the racks, i.e. completely in Layer-2. From IP point
of view the nodes are connected to a single link. Layer-2 based
networks make it easy to move Virtual Machines from one server to
another but on the other hand they don't scale well for address
resolution protocols like ARP [I-D.narten-armd-problem-statement].
In this document we assume L2-based datacenter/cloud network and
design Dual Stack Lite protocol, see Figure 1 and 4rd, see Figure 2.
4.1. DS-Lite Architecture
Virtual Machines connect to the network using a virtual interface
supported by the guest operating system. These VMs are mapped to the
physical servers in the rack. In VM based data center/cloud networks
B4 for VMs are placed in the guest OS using operating system patch
similar to 6rd CE in [I-D.sakura-6rd-datacenter].
Some data center/cloud networks do not employ Virtual Machines.
These networks are server-based. In server-based data center/cloud
networks, B4 is placed in the access router. In the storage area
network B4 is also placed in the gateway router.
Sarikaya Expires April 19, 2012 [Page 4]
Internet-Draft DS Lite and 4rd for Cloud October 2011
AFTR is at the border of IPv6 backbone. At B4s IPv4 packets are
tunneled to AFTR and then AFTR decapsulates and performs the NAT
operation and sends out IPv4 packet to the public internet, see
Figure 1.
.--. .--.
_(. `) _(. `)
_( IPv6 `)_ _( IPv4 `)_
( Internet `) ( Internet `)
( ) ( )
`--(_______)---' `--(_______)---'
| |
\ +----------+
\ | AFTR |
\ +----------+
\ |
\ .--. |
+----------+ (. `) /
| Cloud | _( IPv6 `)/_ +----------+
| | ( Backbone `) |B4 on GW |
| Network |====( )====|----------|
+----------+ `--(_______)---' | Storage |
|| | Network |
|| +----------+
+-------------+
|Access Router|
|-------------|
| Aggregation |
| Switch |
+-------------+
|
[VM] B4|-|L2 Network |- [Server]
[VM] on | | |
[VM] guest OS | [Server] [Server]
Figure 1: Architecture of DS-Lite for Cloud
4.2. 4rd Architecture
In VM based data center/cloud networks Customer Edge router of 4rd
for VMs are placed in the guest OS using operating system patch
similar to 6rd CE in [I-D.sakura-6rd-datacenter].
Some data center/cloud networks do not employ Virtual Machines.
These networks are server-based. In server-based data center/cloud
networks, CE is placed in the access router. In the storage area
network CE is also placed in the gateway router.
Sarikaya Expires April 19, 2012 [Page 5]
Internet-Draft DS Lite and 4rd for Cloud October 2011
CEs assign private IPv4 addresses to the virtual machines or users
and perform NAT towards the backbone network. On the outgoing
interface, CEs may share public IPv4 addresses with port space
sharing if there are not enough public IPv4 addresses to assign to
the individual CEs. Public IPv4 address sharing is optional, CEs may
be configured with a unique IPv4 public address.
4rd Border Relay is at the border of IPv6 backbone. There could be
more than one BRs and they all can have a single anycast address
which CEs are configured with. At CEs IPv4 packets are sent
encapsulated with an IPv6 header. In case of translation, IPv4
packet is translated into an IPv6 packet [RFC6145] and then sent to
BR, see Figure 2.
At the BR, IPv6 packet is received. In case of encapsulation, the
packet is decapsulated and then sent to IPv4 network. In case of
translation, BR translates IPv6 packet into IPv4 packet [RFC6145] and
then sends it to IPv4 network.
Sarikaya Expires April 19, 2012 [Page 6]
Internet-Draft DS Lite and 4rd for Cloud October 2011
.--. .--.
_(. `) _(. `)
_( IPv6 `)_ _( IPv4 `)_
( Internet `) ( Internet `)
( ) ( )
`--(_______)---' `--(_______)---'
| |
\ +----------+
\ | BR |
\ +----------+
\ |
\ .--. |
+----------+ (. `) /
| Cloud | _( IPv6 `)/_ +----------+
| | ( Backbone `) |CE on GW |
| Network |====( )====|----------|
+----------+ `--(_______)---' | Storage |
|| | Network |
|| +----------+
+-------------+
|Access Router|
|-------------|
| Aggregation |
| Switch |
+-------------+
|
[VM] CE|-|L2 Network |- [Server]
[VM] on | | |
[VM] guest OS | [Server] [Server]
Figure 2: Architecture of 4rd for Cloud
5. DS-Lite Operation
AFTR IPv6 address must be provisioned in B4 elements. DHCPv6 can be
used for this purpose. B4 requests AFTR FQDN using the AFTR-Name
DHCPv6 Option defined in [RFC6334]. B4 gets IPv6 address from the
DNS using the AFTR-Name DHCPv6 Option and configures IPv4-in-IPv6
tunnel based on this address.
B4 operates its own DHCPv4 server and hands out private IPv4
addresses to the users. It is the default IPv4 router and advertizes
itself as the DNS server. It should also be DNS proxy and serves
IPv4 requests and sends the requests using IPv6 to the DNS servers.
B4 encapsulates IPv4 packets and sends them to AFTR. Fragmentation
and reassembly of these packets are as discussed in Section 5.3 of
Sarikaya Expires April 19, 2012 [Page 7]
Internet-Draft DS Lite and 4rd for Cloud October 2011
[RFC6333].
Users in the same data center may communicate with others in the same
center via certain applications like Skype. Local routing of IPv4
packets generated by such applications is needed at B4 to avoid a
round trip to AFTR.
AFTR receives IPv4 packets tunneled by B4s and decapsulates them.
AFTR performs NAT operation on IPv4 before forwarding it to public
IPv4 network. NAT binding table is extended with IPv6 source
address, i.e. WAN side address of the B4 which sent this packet.
For packets coming back from the Internet, AFTR does a reverse lookup
in the extended IPv4 NAT binding table and extracts IPv6 destination
address of the B4 and tunnels IPv4 packet to it.
5.1. DS-Lite for Datacenter Considerations
In DS-Lite B4 to B4 communication always goes through AFTR. This
could incur additional delays in datacenter/cloud networks because
such traffic is expected to be high, e.g. VMs/server may need
constant communication with the storage area network which is also
part of the same data center.
IPv6 hardware support in current switches is poor compared with IPv4.
Most commonly used switches reserve for IPv6 half of the memory
reserved for IPv4 and thus they are slow in processing IPv6 packets.
6. 4rd Operation
Instead of public IPv4 address sharing among the CEs of a data
center, each CE is assigned a unique public IPv4 address. This
simplifies port usage when doing NAT operation. IPv4 address is
derived from domain IPv4 prefix which is used by the BRs to receive
incoming traffic from IPv4 internet.
CEs configure their WAN interface (IPv6 backbone) using regular means
such as SLAAC, DHCPv6, etc. and get an IPv6 prefix assigned. Each CE
is configured with one or several mapping rules. Each CE uses a
reserved interface ID as part of its IPv6 source address to enable
marking 4rd traffic and also to effectively create a 4rd interface on
its WAN side.
On the LAN side (VMs or users), CE is dual stack and supports IPv4 by
assigning private IPv4 addresses. When CE receives an IPv4 packet it
performs NAT on the packet. CE looks up the destination IPv4 address
in the mapping rules. If the prefix matches domain IPv4 prefix then
Sarikaya Expires April 19, 2012 [Page 8]
Internet-Draft DS Lite and 4rd for Cloud October 2011
this packet sent to another CE. CE derives an IPv6 destination
address from IPv4 destination address. Otherwise this packet is sent
to BR. CE derives a BR anycast address as destination IPv6 address.
Next the packet is either encapsulated in IPv6 [RFC2473] or
translated from IPv4 to IPv6 packet [RFC6145].
BR receives IPv6 packet and checks to see if it is 4rd packet, either
using the interface ID of the source IPv6 address or looking up the
source IPv4 address in the mapping rules. BR decapsulates or
translates IPv6 packet and forwards resulting IPv4 packet using IPv4
interface.
For an incoming IPv4 packet BR checks if the destination IPv4 address
has a match in the mapping rules. Next, BR generates CE IPv6 address
from IPv4 destination address. BR either encapsulates IPv4 packet in
IPv6 and or translates it into IPv6 and then sends it to CE.
When CE receives an IPv6 packet it checks to see if IPv4 source
address matches a mapping rule, i.e. the packet is coming from
another CE or IPv6 source address matches BR IPv6 address, i.e. the
packet is coming from BR. CE decapsulates or translates the packet
to obtain IPv4 packet and then forwards it on the LAN interface.
6.1. 4rd for Datacenter Considerations
In 4rd CE to CE communication does not go through BR. This is a
significant advantage of 4rd over DS-Lite especially in data center
networks.
4rd CE and BR process each packet using 4rd mapping rules. There
could be over 1000 mapping rules. This per packet processing
naturally slows down users access to the internet especially at the
CEs which are much less resourceful than BRs.
7. Security Considerations
TBD.
8. IANA Considerations
TBD.
9. Acknowledgements
TBD.
Sarikaya Expires April 19, 2012 [Page 9]
Internet-Draft DS Lite and 4rd for Cloud October 2011
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[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.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011.
[I-D.murakami-softwire-4rd]
Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual
Deployment on IPv6 infrastructure - protocol
specification", draft-murakami-softwire-4rd-01 (work in
progress), September 2011.
[I-D.despres-softwire-4rd]
Despres, R., "IPv4 Residual Deployment across IPv6-Service
networks (4rd) A NAT-less solution",
draft-despres-softwire-4rd-00 (work in progress),
October 2010.
[I-D.xli-behave-divi]
Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-03
(work in progress), July 2011.
10.2. Informative references
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
Sarikaya Expires April 19, 2012 [Page 10]
Internet-Draft DS Lite and 4rd for Cloud October 2011
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[I-D.narten-armd-problem-statement]
Narten, T., "Problem Statement for ARMD",
draft-narten-armd-problem-statement-00 (work in progress),
July 2011.
[I-D.sakura-6rd-datacenter]
Tsuchiya, S., Townsley, M., and S. Ohkubo, "IPv6 Rapid
Deployment (6rd) in a Large Data Center",
draft-sakura-6rd-datacenter-01 (work in progress),
July 2011.
[I-D.wkumari-dcops-l3-vmmobility]
Kumari, W. and J. Halpern, "Virtual Machine mobility in L3
Networks.", draft-wkumari-dcops-l3-vmmobility-00 (work in
progress), August 2011.
[sourceforge]
Source Forge, "OpenWRT DS-Lite Software", February 2011.
Sarikaya Expires April 19, 2012 [Page 11]
Internet-Draft DS Lite and 4rd for Cloud October 2011
Author's Address
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 3
Plano, TX 75024
Email: sarikaya@ieee.org
Sarikaya Expires April 19, 2012 [Page 12]
