IPv6 Operational Guidelines for Datacenters
draft-lopez-v6ops-dc-ipv6-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Diego R. Lopez , Zhonghua Chen , Tina Tsou (Ting ZOU) , Cathy Zhou , Arturo L. Servin | ||
| Last updated | 2013-02-05 | ||
| Replaced by | draft-ietf-v6ops-dc-ipv6 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lopez-v6ops-dc-ipv6-04
Network Working Group D. Lopez
Internet-Draft Telefonica I+D
Intended status: Standards Track Z. Chen
Expires: August 9, 2013 China Telecom
T. Tsou
Huawei Technologies (USA)
C. Zhou
Huawei Technologies
A. Servin
LACNIC
February 5, 2013
IPv6 Operational Guidelines for Datacenters
draft-lopez-v6ops-dc-ipv6-04
Abstract
This document is intended to provide operational guidelines for
datacenter operators planning to deploy IPv6 in their
infrastructures. It aims to offer a reference framework 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 IPv6 transition for datacenters of these
infrastuctures.
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 transition to IPv6, the mechanisms
outlined here are intended to make this transition 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
Lopez, et al. Expires August 9, 2013 [Page 1]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
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 August 9, 2013.
Copyright Notice
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.
Lopez, et al. Expires August 9, 2013 [Page 2]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture and Transition Stages . . . . . . . . . . . . . . 4
2.1. General Architecture . . . . . . . . . . . . . . . . . . . 5
2.2. Experimental Stage. Native IPv4 Infrastructure . . . . . . 7
2.2.1. Off-shore v6 Access . . . . . . . . . . . . . . . . . 8
2.3. Dual Stack Stage. Internal Adaptation . . . . . . . . . . 8
2.3.1. Dual-stack at the Aggregation Layer . . . . . . . . . 10
2.3.2. Dual-stack Extended OS/Hypervisor . . . . . . . . . . 12
2.4. IPv6-Only Stage. Pervasive IPv6 Infrastructure . . . . . . 12
3. Other Operational Considerations . . . . . . . . . . . . . . . 13
3.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Management Systems and Applications . . . . . . . . . . . 14
3.3. Monitoring and Logging . . . . . . . . . . . . . . . . . . 14
3.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
4.1. Neighbor Discovery Protocol attacks . . . . . . . . . . . 15
4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Edge filtering . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Final Security Remarks . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Lopez, et al. Expires August 9, 2013 [Page 3]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
1. Introduction
The need for considering the aspects related to IPv4-to-IPv6
transition 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
transition a key aspect both for these infrastructures themselves,
and for providing a simpler and clear path to service transition.
All issues discussed here are related to DC infrastructure
transition, 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. General mechanisms related to service transition
have been discussed in depth elsewhere (see, for example
[I-D.ietf-v6ops-icp-guidance] and
[I-D.ietf-v6ops-enterprise-incremental-ipv6]) and are considered to
be independent to the goal of this discussion. The applicability of
these general mechanisms for service transition will, in many cases,
depend on the supporting DC's infrastructure characteristics.
However, this document intends to keep both problems (service vs.
infrastructure transition) as different issues.
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.
2. Architecture and Transition Stages
This document presents a transition framework structured along
transition stages and operational guidance associated with the degree
of penetration of IPv6 into the DC communication fabric. It is worth
noting we are using these stages as a classification mechanism, and
they have not to be associated with any 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 the
stage describe in first place, 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 stage, and
freely move from one to another as they see fit, without contravening
this document. In this respect, the classification intends to
Lopez, et al. Expires August 9, 2013 [Page 4]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
support the planning in aspects such as the adaptation of the
different transition stages 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 transition stages can be considered when analyzing IPv6
deployment in the DC infrastructure, all compatible with the
availability of services running in the DC through IPv6:
o Experimental. The DC keeps a native IPv4 infrastructure, with
gateway routers (or even application gateways when services
require so) performing the adaptation to requests arriving from
the IPv6 Internet.
o Dual stack. 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.
o IPv6-Only. The DC has a fully pervasive IPv6 infrastructure,
including full IPv6 hypervisors, which perform the appropriate
tunneling or NAT if required by internal applications running
IPv4.
2.1. General Architecture
The diagram in Figure 1 depicts a generalized interconnection schema
in a DC.
Lopez, et al. Expires August 9, 2013 [Page 5]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
| |
+-----+-----+ +-----+-----+
| 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.
Lopez, et al. Expires August 9, 2013 [Page 6]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
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, some 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.2. Experimental Stage. Native IPv4 Infrastructure
This transition stage corresponds to the first step that many
datacenters may take (or have taken) in order to make their external
services initially accessible from the IPv6 Internet and/or to
evaluate the possibilities around it, and corresponds to IPv6 traffic
patterns totally originated out of the DC or their tenants, being a
small percentage of the total external requests. At this stage, DC
network scheme and addressing do not require any important change, if
any.
It is important to remark that in no case this can be considered a
permanent stage in the transition, or even a long-term solution for
incorporating IPv6 into the DC infrastructure. This stage is only
recommended for experimentation or early evaluation purposes.
The translation of IPv6 requests into the internal infrastructure
addressing 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.
More granular mechanisms, based on address ranges or more
sophisticated dynamic policies are also possible, as they are applied
by a limited set of control elements. These provide an additional
level of control to the usage of IPv6 routable addresses in the DC
environment, which can be especially significant in the
experimentation or early deployment phases this stage is applicable
to.
Even at this stage, 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.ietf-6man-flow-ecmp]. If the incoming IPv6 requests are
Lopez, et al. Expires August 9, 2013 [Page 7]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
adequately labeled the gateway systems can use the flow labels as
a hint for applying load-balancing mechanisms when translating the
requests towards the IPv4 internal network.
o During VM migration (intra- or even inter-DC), Mobile IP
mechanisms can be applied to keep service availability during the
transient state.
2.2.1. Off-shore v6 Access
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].
When this off-shore mode is applied, the original source address will
be hidden to the DC infrastructure, and therefore identification
techniques based on it, such as geolocation or reputation evaluation,
will be hampered. Unless there is a specific trust link between the
DC operator and the ISP, and the DC operator is able to access
equivalent identification interfaces provided by the ISP as an
additional service, the off-shore experimental stage cannot be
considered applicable when source address identification is required.
2.3. Dual Stack Stage. Internal Adaptation
This stage requires dual-stack elements in some internal parts of the
DC infrastructure. This brings some degree of partition 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
stage can arise from different 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 controlled real-operations
environment, at the price of the additional complexity of dealing
with a double protocol stack, as noted in
[I-D.ietf-v6ops-icp-guidance] and elsewhere.
This transition stage 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. A common scenario would include
native dual stack servers for certain services combined with single
stack ones for others (web server in dual stack and database servers
only supporting v4, for example).
Lopez, et al. Expires August 9, 2013 [Page 8]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
At this stage, 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
assignment, 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 stage requires a much more careful planning
of addressing (refer to ([RFC5375]) schemas and access control,
according to security levels. While the experimental stage implies
relatively few global routable addresses, this one brings the
advantages and risks of using different kinds of addresses at each
point of the IPv6-aware infrastructure.
Lopez, et al. Expires August 9, 2013 [Page 9]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
2.3.1. Dual-stack at the Aggregation Layer
+---------------------+
| Internet |
+---------+-----------+
|
+-----+----+
| Gateway |
+-----+----+
.
. Core Level
.
+--+--+
| FW |
+--+--+
| Aggregation Level
+--+--+
| LB |
+--+--+
_ / \_
/ \
+--+--+ +--+--+
| Web | ... | Web |
+--+--+ +--+--+
| \ __ _ _/ |
| / \ |
+--+--+ +--+--+
|Cache| | DB |
+-----+ +-----+
Figure 2: Data Center Application Scheme
An initial approach corresponding to this transition stage 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) are 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 based on 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 balancer (LB) or some other boxes could be upgraded to
support the data transmission. There may be two ways to achieve this
Lopez, et al. Expires August 9, 2013 [Page 10]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
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. As described below, a
simplified IPv4/IPv6 translation model can be applied, which could be
implemented in the LB device. The mapping information of IPv4 and
IPv6 will be generated automatically based on the information of the
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
Lopez, et al. Expires August 9, 2013 [Page 11]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
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.
2.3.2. Dual-stack Extended OS/Hypervisor
Another option for deploying a infrastructure at the dual-stack stage
would bring dual-stack much closer to the application servers, by
requiring hypervisors, VMs and applications in the v6-capable zone of
the DC to be able to operate in dual stack. This way, incoming
connections would be dealt in a seamless manner, while for outgoing
ones an OS-specific replacement for system calls like gethostbyname()
and getaddrinfo() would accept a character string (an IPv4 literal,
an IPv6 literal, or a domain name) and would return a connected
socket or an error message, having executed a happy eyeballs
algorithm ([RFC6555]).
If these hypothetical system call replacements were smart enough,
they would allow the transparent interoperation of DCs with different
levels of v6 penetration, either horizontal (internal data paths are
not migrated, for example) or vertical (per tenant or service group).
This approach requires, on the other hand, all the involved DC
infrastructure to become dual-stack, as well as some degree of
explicit application adaptation.
2.4. IPv6-Only Stage. Pervasive IPv6 Infrastructure
We can consider a DC infrastructure at the final stage when all
network layer elements, including hypervisors, are IPv6-aware and
apply it by default. Conversely with the experimental stage, 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.
There are different drivers that could motivate DC managers to
transition to this stage. In principle the scarcity of IPv4
addresses may require to reclaim IPv4 resources from portions of the
network infrastructure which no longer need them. Furthermore, the
unavailability of IPv4 address would make dual-stack environments not
possible anymore and require careful assessments to be performed to
assess where to use the remaining IPv4 resources.
Another important motivation to move DC operations from dual-stack to
IPv6-only is the saving in costs and operational activities that
managing a single-stack network could bring in comparison with
managing two stacks. Today, besides of learning to manage two
different stacks, network and system administrators are required to
Lopez, et al. Expires August 9, 2013 [Page 12]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
duplicate other tasks such as IP address management, firewall
configuration, system security hardening and monitoring among others.
These activities are not just costly for the DC management staff,
they may also lead to configuration errors and security holes.
This stage can be also 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. Other, and probably more compelling in
many cases, drivers for this stage may be either a lack of enough
IPv4 resources (whether private or globally unique) or a need to
reclaim IPv4 resources from portions of the network which no longer
need them. In these circumstances, a careful evaluation of what
still needs to speak IPv4 and what does not will need to happen to
ensure judicious use of the remaining IPv4 resources.
The potential advantages mentioned for the previous stages (load
balancing based on flow labels, mobility mechanisms for transient
states in VM or data migration, controlled 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 next generation DC deployment,
already demonstrated in practice, and claims the advantages of
materializing the stage from the beginning, providing some rationale
for it based on simplifying the transition process. It relies on
stateless NAT64 ([RFC6052], [RFC6145]) to enable access from the IPv4
Internet.
3. Other Operational Considerations
This section discusses operational considerations related to
addressing and management issues in V6 DC infrastructures.
3.1. Addressing
There are different considerations related on IPv6 addressing topics
in DC. Many of these considerations are already documented in a
variety of IETF documents and in general the recommendations and best
practices mentioned on them apply in IPv6 DC environments. However
we would like to point out some topics that we consider specifically
worth mentioning.
Lopez, et al. Expires August 9, 2013 [Page 13]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
The first question that DC managers often have is the type of IPv6
address to use; that is Provider Aggregated (PA), Provider
Independent (PI) or Unique Local IPv6 Addresses (ULAs) [RFC4193]
Related to the use of PA vs. PI, we concur with
[I-D.ietf-v6ops-icp-guidance] and
[I-D.ietf-v6ops-enterprise-incremental-ipv6] that PI provides
independence from the ISP and decreases renumbering issues, it may
bring up other considerations as a fee for the allocation, a request
process and allocation maintenance to the Regional Internet Registry,
etc. In this respect, there is not a specific recommendation to use
either PI vs. PA as it would depend also on business and management
factors rather than pure technical ones.
ULAs should be used only in DC infrastructure that does not require
access to the public Internet; such devices may be databases servers,
application-servers, and management interfaces of webservers and
network devices among others. This practice may decrease the
renumbering issues when PA addressing is used, as only public faced
devices would require an address change. Let us remark that,
although ULAs may provide some security, the main motivation for its
use should be exclusively address management.
Address plans should follow the principles of being hierarchical and
able to aggregate address space. We recommend at least to have a /48
for each data-center. If the DC provides services that require
subassigment of address space we do not offer a single recommendation
(i.e. request a /40 prefix from an RIR or ISP and assign /48 prefixes
to customers), as this may depend on other no technical factors.
Instead we refer the reader to [RFC6177].
For point-to-point links please refer to the recommendations in
[RFC6164].
3.2. Management Systems and Applications
Data-centers may use Internet Protocol address management (IPAM)
software, provisioning systems and other variety of software to
document and operate their IP infrastructure. It is important that
these systems are prepared and possibly modified to support IPv6 in
their data models. In general, if IPv6 support for these
applications has not been previously done, changes may take some time
as they may be not just adding more space in input fields but also
modifying data models and data migration.
3.3. Monitoring and Logging
Monitoring and logging are critical operations in any network
environment and they should be carried at the same level for IPv6 and
Lopez, et al. Expires August 9, 2013 [Page 14]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
IPv4. Monitoring and management operations in V6 DC are by no means
different than any other IPv6 networks environments. It is important
to consider that the collection of information from network devices
is orthogonal to the information collected. For example it is
possible to collect data from IPv6 MIBs using IPv4 transport.
Similarly it is possible to collect IPv6 data generated by Netflow9/
IPFIX agents in IPv4 transport. In this way the important issue to
address is that agents (i.e. network devices) are able to collect
data specific to IPv6.
3.4. Costs
It is very possible that moving from a single stack v4 data-center
infrastructure to any of the transition stages described in this
document may incur in capital expenditures. This may include but it
is not confined to routers, load-balancers, firewalls and software
upgrades among others. However the cost that most concern us is
operational. Moving the DC infrastructure operations from a single-
stack to a dual-stack may infer in a variety of extra costs such as
application development and testing, operational troubleshooting and
service deployment. At the same time, this extra cost may be seeing
as saving when moving from a dual-stack DC to an IPv6-Only DC.
Depending of the complexity of the DC network, provisioning and other
factors we estimate that the extra costs (and later savings) may be
around between 15 to 20%.
4. Security Considerations
A thorough collection of operational security aspects for IPv6
network is made in [I-D.ietf-opsec-v6] . Most of them, with the
probable exception of those specific to residential users, are
applicable in the environment we consider in this document.
4.1. Neighbor Discovery Protocol attacks
The first important issue that the V6 DC manager should be aware is
the attacks against Neighbor Discovery Protocol [RFC6583]. This
attack is similar to ARP attacks [RFC4732] in IPv4 but exacerbated by
the fact that the common size of an IPv6 subnet is /64. In principle
an attacker would be able to fill the Neighbor Cache of the local
router and starve its memory and processing resources by sending
multiple ND packets requesting information of non-existing hosts.
The result would be the inability of the router to respond to ND
requests, to update its Neighbor Cache and even to forward packets.
The attack does need to be launched with malicious purposes; it could
be just the result of bad stack implementation behavior.
Lopez, et al. Expires August 9, 2013 [Page 15]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
[RFC6583] mentions some options to mitigate the effects of the
attacks against NDP. For example filtering unused space, minimizing
subnet size when possible, tuning rate limits in the NDP queue and to
rely in router vendor implementations to better handle resources and
to prioritize NDP requests.
4.2. Addressing
Other important security considerations in V6 DC are related to
addressing. Because of the large address space is commonly thought
that IPv6 is not vulnerable to reconnaissance techniques such as
scanning. Although that may be true to force brute attacks,
[I-D.ietf-opsec-ipv6-host-scanning] shows some techniques that may be
employed to speed up and improve results in order to discover IPv6
address in a subnet. The use of virtual machines and SLACC aggravate
this problem due the fact that they tend to use automatically-
generated MAC address according to well-known patterns.
To mitigate address-scanning attacks it is recommended to avoid using
SLAAC and, if used, stable privacy-enhanced addresses
[I-D.ietf-6man-stable-privacy-addresses] should be the method of
address generation. Also, for manually assigned addresses try to
avoid IID low-byte address (i.e. from 0 to 256), IPv4-based addresses
and wordy addresses especially for infrastructure without a fully
qualified domain name.
In spite of the use of manually assigned addresses is the preferred
method for V6 DC, SLACC and DHCPv6 may be also used for some special
reasons. However we recommend paying special attention to RA
[RFC6104] and DHCP [I-D.gont-opsec-dhcpv6-shield] hijack attacks. In
these kinds of attacks the attacker deploys rogue routers sending RA
messages or rogue DHCP servers to inject bogus information and
possibly to perform a man in the middle attack. In order to mitigate
this problem it is necessary to apply some techniques in access
switches such as RA-Guard [RFC6105] at least.
Another topic that we would like to mention related to addressing is
the use of ULAs. As we previously mentioned, although ULAs may be
used to hide host from the outside world we do not recommend to rely
on them as a security tool but better as a tool to make renumbering
easier.
4.3. Edge filtering
In order to avoid being used as a source of amplification attacks is
it important to follow the rules of BCP38 [RFC2827] on ingress
filtering. At the same time it is important to filter-in on the
network border all the unicast traffic and routing announcement that
Lopez, et al. Expires August 9, 2013 [Page 16]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
should not be routed in the Internet, commonly known as "bogus
prefixes".
4.4. Final Security Remarks
Finally, let us just emphasize the need for a careful configuration
of access control rules at the translation points. This latter one
is specially sensitive in infrastructures at the dual-stack stage, as
the translation points are potentially distributed, and when protocol
translation is offered as an external service, since there can be
operational mismatches.
5. IANA Considerations
None.
6. Acknowledgements
We would like to thank Tore Anderson, Wes George, Ray Hunter, Joel
Jaeggli, Fred Baker, Lorenzo Colitti, Dan York, Carlos Martinez, Lee
Howard and Alejandro Acosta for their questions, suggestions and
comments.
7. Informative References
[I-D.gont-opsec-dhcpv6-shield]
Gont, F. and W. Liu, "DHCPv6-Shield: Protecting Against
Rogue DHCPv6 Servers", draft-gont-opsec-dhcpv6-shield-01
(work in progress), October 2012.
[I-D.ietf-6man-flow-ecmp]
Carpenter, B. and S. Amante, "Using the IPv6 flow label
for equal cost multipath routing and link aggregation in
tunnels", draft-ietf-6man-flow-ecmp-05 (work in progress),
July 2011.
[I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", draft-ietf-6man-stable-privacy-addresses-03
(work in progress), January 2013.
[I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-00 (work in
Lopez, et al. Expires August 9, 2013 [Page 17]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
progress), December 2012.
[I-D.ietf-opsec-v6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks",
draft-ietf-opsec-v6-01 (work in progress), November 2012.
[I-D.ietf-v6ops-enterprise-incremental-ipv6]
Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
Guidelines",
draft-ietf-v6ops-enterprise-incremental-ipv6-01 (work in
progress), September 2012.
[I-D.ietf-v6ops-icp-guidance]
Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content and Application Service Providers",
draft-ietf-v6ops-icp-guidance-05 (work in progress),
January 2013.
[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.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
and C. Hahn, "IPv6 Unicast Address Assignment
Considerations", RFC 5375, December 2008.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", RFC 6104, February 2011.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Lopez, et al. Expires August 9, 2013 [Page 18]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
Router Links", RFC 6164, April 2011.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, March 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012.
[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
Diego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 84
Madrid 28006
Spain
Phone: +34 913 129 041
Email: diego@tid.es
Zhonghua Chen
China Telecom
P.R.China
Phone:
Email: 18918588897@189.cn
Lopez, et al. Expires August 9, 2013 [Page 19]
Internet-Draft IPv6 Op Guidelines for DCs February 2013
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
Arturo Servin
LACNIC
Rambla Republica de Mexico 6125
Montevideo 11300
Uruguay
Phone: +598 2604 2222
Email: aservin@lacnic.net
Lopez, et al. Expires August 9, 2013 [Page 20]