draft-ietf-v6ops-dc-ipv6-00.txt   draft-ietf-v6ops-dc-ipv6-01.txt 
v6ops D. Lopez v6ops D. Lopez
Internet-Draft Telefonica I+D Internet-Draft Telefonica I+D
Intended status: Informational Z. Chen Intended status: Informational Z. Chen
Expires: February 13, 2014 China Telecom Expires: August 7, 2014 China Telecom
T. Tsou T. Tsou
Huawei Technologies (USA) Huawei Technologies (USA)
C. Zhou C. Zhou
Huawei Technologies Huawei Technologies
A. Servin A. Servin
LACNIC LACNIC
August 12, 2013 February 3, 2014
IPv6 Operational Guidelines for Datacenters IPv6 Operational Guidelines for Datacenters
draft-ietf-v6ops-dc-ipv6-00 draft-ietf-v6ops-dc-ipv6-01
Abstract Abstract
This document is intended to provide operational guidelines for This document is intended to provide operational guidelines for
datacenter operators planning to deploy IPv6 in their datacenter operators planning to deploy IPv6 in their
infrastructures. It aims to offer a reference framework for infrastructures. It aims to offer a reference framework for
evaluating different products and architectures, and therefore it is evaluating different products and architectures, and therefore it is
also addressed to manufacturers and solution providers, so they can also addressed to manufacturers and solution providers, so they can
use it to gauge their solutions. We believe this will translate in a use it to gauge their solutions. We believe this will translate in a
smoother and faster IPv6 transition for datacenters of these smoother and faster IPv6 transition for datacenters of these
skipping to change at page 2, line 12 skipping to change at page 2, line 12
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 13, 2014. This Internet-Draft will expire on August 7, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture and Transition Stages . . . . . . . . . . . . . . 4 2. Architecture and Transition Stages . . . . . . . . . . . . . . 4
2.1. General Architecture . . . . . . . . . . . . . . . . . . . 5 2.1. General Architecture . . . . . . . . . . . . . . . . . . . 5
2.2. Experimental Stage. Native IPv4 Infrastructure . . . . . . 7 2.2. Experimental Stage. Native IPv4 Infrastructure . . . . . . 7
2.2.1. Off-shore v6 Access . . . . . . . . . . . . . . . . . 8 2.2.1. Off-shore v6 Access . . . . . . . . . . . . . . . . . 8
2.3. Dual Stack Stage. Internal Adaptation . . . . . . . . . . 8 2.3. Dual Stack Stage. Internal Adaptation . . . . . . . . . . 8
2.3.1. Dual-stack at the Aggregation Layer . . . . . . . . . 10 2.3.1. Dual-stack at the Aggregation Layer . . . . . . . . . 10
2.3.2. Dual-stack Extended OS/Hypervisor . . . . . . . . . . 12 2.3.2. Dual-stack Extended OS/Hypervisor . . . . . . . . . . 12
2.4. IPv6-Only Stage. Pervasive IPv6 Infrastructure . . . . . . 12 2.4. IPv6-Only Stage. Pervasive IPv6 Infrastructure . . . . . . 12
3. Other Operational Considerations . . . . . . . . . . . . . . . 13 2.4.1. Overlay and Chaining Support . . . . . . . . . . . . . 14
3.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Other Operational Considerations . . . . . . . . . . . . . 15
3.2. Management Systems and Applications . . . . . . . . . . . 14 2.5.1. Addressing . . . . . . . . . . . . . . . . . . . . . . 15
3.3. Monitoring and Logging . . . . . . . . . . . . . . . . . . 15 2.5.2. Management Systems and Applications . . . . . . . . . 16
3.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.3. Monitoring and Logging . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 2.5.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Neighbor Discovery Protocol attacks . . . . . . . . . . . 16 2.6. Security Considerations . . . . . . . . . . . . . . . . . 17
4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 16 2.6.1. Neighbor Discovery Protocol attacks . . . . . . . . . 17
4.3. Edge filtering . . . . . . . . . . . . . . . . . . . . . . 17 2.6.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 18
4.4. Final Security Remarks . . . . . . . . . . . . . . . . . . 17 2.6.3. Edge filtering . . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 2.6.4. Final Security Remarks . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 2.7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19
7. Informative References . . . . . . . . . . . . . . . . . . . . 17 2.8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Informative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The need for considering the aspects related to IPv4-to-IPv6 The need for considering the aspects related to IPv4-to-IPv6
transition for all devices and services connected to the Internet has transition for all devices and services connected to the Internet has
been widely mentioned elsewhere, and it is not our intention to make 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 an additional call on it. Just let us note that many of those
services are already or will soon be located in Data Centers (DC), services are already or will soon be located in Data Centers (DC),
what makes considering the issues associated to DC infrastructure what makes considering the issues associated to DC infrastructure
transition a key aspect both for these infrastructures themselves, transition a key aspect both for these infrastructures themselves,
and for providing a simpler and clear path to service transition. and for providing a simpler and clear path to service transition.
All issues discussed here are related to DC infrastructure All issues discussed here are related to DC infrastructure
transition, and are intended to be orthogonal to whatever particular transition, and are intended to be orthogonal to whatever particular
mechanisms for making the services hosted in the DC available through mechanisms for making the services hosted in the DC available through
IPv6 beyond the specific aspects related to their deployment on the IPv6 beyond the specific aspects related to their deployment on the
infrastructure. General mechanisms related to service transition infrastructure. General mechanisms related to service transition
have been discussed in depth elsewhere (see, for example have been discussed in depth elsewhere (see, for example [RFC6883]
[I-D.ietf-v6ops-icp-guidance] and and [I-D.ietf-v6ops-enterprise-incremental-ipv6]) and are considered
[I-D.ietf-v6ops-enterprise-incremental-ipv6]) and are considered to to be independent to the goal of this discussion. The applicability
be independent to the goal of this discussion. The applicability of of these general mechanisms for service transition will, in many
these general mechanisms for service transition will, in many cases, cases, depend on the supporting DC's infrastructure characteristics.
depend on the supporting DC's infrastructure characteristics.
However, this document intends to keep both problems (service vs. However, this document intends to keep both problems (service vs.
infrastructure transition) as different issues. infrastructure transition) as different issues.
Furthermore, the combination of the regularity and controlled Furthermore, the combination of the regularity and controlled
management in a DC interconnection fabric with IPv6 universal end-to- management in a DC interconnection fabric with IPv6 universal end-to-
end addressing should translate in simpler and faster VM migrations, end addressing should translate in simpler and faster VM migrations,
either intra- or inter-DC, and even inter-provider. either intra- or inter-DC, and even inter-provider.
2. Architecture and Transition Stages 2. Architecture and Transition Stages
skipping to change at page 8, line 5 skipping to change at page 8, line 5
sophisticated dynamic policies are also possible, as they are applied sophisticated dynamic policies are also possible, as they are applied
by a limited set of control elements. These provide an additional by a limited set of control elements. These provide an additional
level of control to the usage of IPv6 routable addresses in the DC level of control to the usage of IPv6 routable addresses in the DC
environment, which can be especially significant in the environment, which can be especially significant in the
experimentation or early deployment phases this stage is applicable experimentation or early deployment phases this stage is applicable
to. to.
Even at this stage, some implicit advantages of IPv6 application come Even at this stage, some implicit advantages of IPv6 application come
into play, even if they can only be applied at the ingress elements: 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 o Flow labels can be applied to enhance load distribution, as
in [I-D.ietf-6man-flow-ecmp]. If the incoming IPv6 requests are described in [RFC7098]. If the incoming IPv6 requests are
adequately labeled the gateway systems can use the flow labels as adequately labeled the gateway systems can use the flow labels as
a hint for applying load-balancing mechanisms when translating the a hint for applying load-balancing mechanisms when translating the
requests towards the IPv4 internal network. requests towards the IPv4 internal network.
o During VM migration (intra- or even inter-DC), Mobile IP o During VM migration (intra- or even inter-DC), Mobile IPv6
mechanisms can be applied to keep service availability during the mechanisms can be applied to keep service availability during the
transient state. transient state.
2.2.1. Off-shore v6 Access 2.2.1. Off-shore v6 Access
This model is also suitable to be applied in an "off-shore" mode by This model is also suitable to be applied in an "off-shore" mode by
the service provider connecting the DC infrastructure to the the service provider connecting the DC infrastructure to the
Internet, as described in [I-D.sunq-v6ops-contents-transition]. Internet, as described in [I-D.sunq-v6ops-contents-transition].
When this off-shore mode is applied, the original source address will When this off-shore mode is applied, the original source address will
skipping to change at page 8, line 44 skipping to change at page 8, line 44
infrastructure, either in a horizontal (when data paths or management infrastructure, either in a horizontal (when data paths or management
interfaces are migrated or left in IPv4 while the rest migrate) or a interfaces are migrated or left in IPv4 while the rest migrate) or a
vertical (per tenant or service group), or even both. vertical (per tenant or service group), or even both.
Although it may seem an artificial case, situations requiring this Although it may seem an artificial case, situations requiring this
stage can arise from different requirements from the user base, or stage can arise from different requirements from the user base, or
the need for technology changes at different points of the the need for technology changes at different points of the
infrastructure, or even the goal of having the possibility of infrastructure, or even the goal of having the possibility of
experimenting new solutions in a controlled real-operations experimenting new solutions in a controlled real-operations
environment, at the price of the additional complexity of dealing environment, at the price of the additional complexity of dealing
with a double protocol stack, as noted in with a double protocol stack, as noted in [RFC6883] and elsewhere.
[I-D.ietf-v6ops-icp-guidance] and elsewhere.
This transition stage can accommodate different traffic patterns, This transition stage can accommodate different traffic patterns,
both internal and external, though it better fits to scenarios of a both internal and external, though it better fits to scenarios of a
clear differentiation of different types of traffic (external vs. clear differentiation of different types of traffic (external vs.
internal, data vs management...), and/or a more or less even internal, data vs management...), and/or a more or less even
distribution of external requests. A common scenario would include distribution of external requests. A common scenario would include
native dual stack servers for certain services combined with single native dual stack servers for certain services combined with single
stack ones for others (web server in dual stack and database servers stack ones for others (web server in dual stack and database servers
only supporting v4, for example). only supporting v4, for example).
skipping to change at page 9, line 18 skipping to change at page 9, line 17
on flow labels and Mobile IP mechanisms are applicable to any L3- on flow labels and Mobile IP mechanisms are applicable to any L3-
based mechanism (intra- as well as inter-DC). They will translate based mechanism (intra- as well as inter-DC). They will translate
into enhanced VM mobility, more effective load balancing, and higher into enhanced VM mobility, more effective load balancing, and higher
service availability. Furthermore, the simpler integration provided service availability. Furthermore, the simpler integration provided
by IPv6 to and from the L2 flat space to the structured L3 one can be 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 applied to achieve simpler deployments, as well as alleviating
encapsulation and fragmentation issues when traversing between L2 and encapsulation and fragmentation issues when traversing between L2 and
L3 spaces. With an appropriate prefix management, automatic address L3 spaces. With an appropriate prefix management, automatic address
assignment, discovery, and renumbering can be applied not only to assignment, discovery, and renumbering can be applied not only to
public service interfaces, but most notably to data and management public service interfaces, but most notably to data and management
paths. 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.
Other potential advantages include the application of multicast In general, all these advantages are especially significative to
scopes to limit broadcast floods, and the usage of specific security overlay techniques applied to support multi-tenancy and inter-DC
headers to enhance tenant differentiation. operation.
On the other hand, this stage requires a much more careful planning On the other hand, this stage requires a much more careful planning
of addressing (please refer to ([RFC5375]) schemas and access of addressing (please refer to ([RFC5375]) schemas and access
control, according to security levels. While the experimental stage control, according to security levels. While the experimental stage
implies relatively few global routable addresses, this one brings the implies relatively few global routable addresses, this one brings the
advantages and risks of using different kinds of addresses at each advantages and risks of using different kinds of addresses at each
point of the IPv6-aware infrastructure. point of the IPv6-aware infrastructure.
2.3.1. Dual-stack at the Aggregation Layer 2.3.1. Dual-stack at the Aggregation Layer
skipping to change at page 10, line 22 skipping to change at page 10, line 22
| Gateway | | Gateway |
+-----+----+ +-----+----+
. .
. Core Level . Core Level
. .
+--+--+ +--+--+
| FW | | FW |
+--+--+ +--+--+
| Aggregation Level | Aggregation Level
+--+--+ +--+--+
| LB | | MB |
+--+--+ +--+--+
_ / \_ _ / \_
/ \ / \
+--+--+ +--+--+ +--+--+ +--+--+
| Web | ... | Web | | Web | ... | Web |
+--+--+ +--+--+ +--+--+ +--+--+
| \ __ _ _/ | | \ __ _ _/ |
| / \ | | / \ |
+--+--+ +--+--+ +--+--+ +--+--+
|Cache| | DB | |Cache| | DB |
skipping to change at page 10, line 45 skipping to change at page 10, line 45
Figure 2: Data Center Application Scheme Figure 2: Data Center Application Scheme
An initial approach corresponding to this transition stage relies on An initial approach corresponding to this transition stage relies on
taking advantage of specific elements at the aggregation layer taking advantage of specific elements at the aggregation layer
described in Figure 1, and make them able to provide dual-stack described in Figure 1, and make them able to provide dual-stack
gatewaying to the IPv4-based servers and data infrastructure. gatewaying to the IPv4-based servers and data infrastructure.
Typically, firewalls (FW) are deployed as the security edge of the Typically, firewalls (FW) are deployed as the security edge of the
whole service domain and provides safe access control of this service whole service domain and provides safe access control of this service
domain from other function domains. In addition, some application domain from other function domains. In addition, some application
optimization based on devices and security devices (e.g. Load optimization based on devices and security devices (generally known
Balancers, SSL VPN, IPS and etc.) may be deployed in the aggregation as middleboxes, e.g. Load Balancers, SSL VPN, IPS and etc.) may be
level to alleviate the burden of the server and to guarantee deep deployed in the aggregation level to alleviate the burden of the
security, as shown in Figure 2. server and to guarantee deep security, as shown in Figure 2. The
choice of a particular kind of middlebox for this dual-stack approach
shall be based on the nature of the services and the deployment of
the middleboxes in the DC infrastructure.
The load balancer (LB) or some other boxes could be upgraded to The middlebox could be upgraded to support the data transmission.
support the data transmission. There may be two ways to achieve this There may be two ways to achieve this at the edge of the DC:
at the edge of the DC: Encapsulation and NAT. In the encapsulation Encapsulation and NAT. In the encapsulation case, the middlebox
case, the LB function carries the IPv6 traffic over IPv4 using an function carries the IPv6 traffic over IPv4 using an encapsulation
encapsulation (IPv6-in-IPv4). In the NAT case, there are already (IPv6-in-IPv4). In the NAT case, there are already some technologies
some technologies to solve this problem. For example, DNS and NAT to solve this problem. For example, DNS and NAT devices could be
device could be concatenated for IPv4/IPv6 translation if IPv6 host concatenated for IPv4/IPv6 translation if IPv6 host needs to visit
needs to visit IPv4 servers. However, this may require the IPv4 servers. However, this may require the concatenation of
concatenation of multiple network devices, which means the NAT tables multiple network devices, which means the NAT tables needs to be
needs to be synchronized at different devices. As described below, a synchronized at different devices. As described below, a simplified
simplified IPv4/IPv6 translation model can be applied, which could be IPv4/IPv6 translation model can be applied, which could be
implemented in the LB device. The mapping information of IPv4 and implemented in the device. The mapping information of IPv4 and IPv6
IPv6 will be generated automatically based on the information of the will be generated automatically based on the information of the
LB. The host IP address will be translated without port translation. middlebox. The host IP address will be translated without port
translation.
+----------+------------------------------+ +----------+------------------------------+
|Dual Stack| IPv4-only +----------+ | |Dual Stack| IPv4-only +----------+ |
| | +----|Web Server| | | | +----|Web Server| |
| +------|------+ / +----------+ | | +------|------+ / +----------+ |
+--------+ +-------+ | | | | / | +--------+ +-------+ | | | | / |
|Internet|--|Gateway|---|---+Load-Balancer+-- \ | |Internet|--|Gateway|---|---+Load-Balancer+-- \ |
| | | | | | | | \ +----------+ | | | | | | | | | \ +----------+ |
+--------+ +-------+ | +------|------+ +----|Web Server| | +--------+ +-------+ | +------|------+ +----|Web Server| |
| | +----------+ | | | +----------+ |
+----------+------------------------------+ +----------+------------------------------+
Figure 3: Dual Stack LB mechanism Figure 3: Dual Stack middlebox (Load-Balancer) mechanism
As shown in Figure 3,the LB can be considered divided into two parts: As shown in Figure 3,the middlebox (a load-balancer, LB, in this
The dual-stack part facing the external border, and the IPv4-only case) can be considered divided into two parts: The dual-stack part
part which contains the traditional LB functions. The IPv4 DC is facing the external border, and the IPv4-only part which contains the
allocated an IPv6 prefix which is for the VSIPv6 (Virtual Service traditional LB functions. The IPv4 DC is allocated an IPv6 prefix
IPv6 Address). We suggest that the IPv6 prefix is not the well-known which is for the VSIPv6 (Virtual Service IPv6 Address). We suggest
prefix in order to avoid the IPv4 routings of the services in that the IPv6 prefix is not the well-known prefix in order to avoid
different DCs spread to the IPv6 network. The VSIPv4 (Virtual the IPv4 routings of the services in different DCs spread to the IPv6
Service IPv4 Address) is embedded in VSIPv6 using the allocated IPv6 network. The VSIPv4 (Virtual Service IPv4 Address) is embedded in
prefix. In this way, the LB has the stateless IP address mapping VSIPv6 using the allocated IPv6 prefix. In this way, the LB has the
between VSIPv6 and VSIPv4, and synchronization is not required stateless IP address mapping between VSIPv6 and VSIPv4, and
between LB and DNS64 server. synchronization is not required between LB and DNS64 server.
The dual-stack part of the LB has a private IPv4 address pool. When 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 IPv6 packets arrive, the dual-stack part does the one-on-one SIP
(source IP address) mapping (as defined in (source IP address) mapping (as defined in
[I-D.sunq-v6ops-contents-transition]) between IPv4 private address [I-D.sunq-v6ops-contents-transition]) between IPv4 private address
and IPv6 SIP. Because there will be too many UDP/TCP sessions and IPv6 SIP. Because there will be too many UDP/TCP sessions
between the DC and Internet, the IP addresses binding tables between between the DC and Internet, the IP addresses binding tables between
IPv6 and IPv4 are not session-based, but SIP-based. Thus, the dual- 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 stack part of LB builds IP binding stateful tables for the host IPv6
address and private IPv4 address of the pool. When the following address and private IPv4 address of the pool. When the following
skipping to change at page 12, line 44 skipping to change at page 12, line 47
apply it by default. Conversely with the experimental stage, access apply it by default. Conversely with the experimental stage, access
from the IPv4 Internet is achieved, when required, by protocol from the IPv4 Internet is achieved, when required, by protocol
translation performed at the edge infrastructure elements, or even translation performed at the edge infrastructure elements, or even
supplied by the service provider as an additional network service. supplied by the service provider as an additional network service.
There are different drivers that could motivate DC managers to There are different drivers that could motivate DC managers to
transition to this stage. In principle the scarcity of IPv4 transition to this stage. In principle the scarcity of IPv4
addresses may require to reclaim IPv4 resources from portions of the addresses may require to reclaim IPv4 resources from portions of the
network infrastructure which no longer need them. Furthermore, the network infrastructure which no longer need them. Furthermore, the
unavailability of IPv4 address would make dual-stack environments not unavailability of IPv4 address would make dual-stack environments not
possible anymore and careful assessments will be performed to assess possible anymore and careful assessments will be perfumed to asses
where to use the remaining IPv4 resources. where to use the remaining IPv4 resources.
Another important motivation to move DC operations from dual-stack to Another important motivation to move DC operations from dual-stack to
IPv6-only is to save costs and operational activities that managing a IPv6-only is to save costs and operation activities that managing a
single-stack network could bring in comparison with managing two single-stack network could bring in comparison with managing two
stacks. Today, besides of learning to manage two different stacks, stacks. Today, besides of learning to manage two different stacks,
network and system administrators require to duplicate other tasks network and system administrators require to duplicate other tasks
such as IP address management, firewalls configuration, system such as IP address management, firewalls configuration, system
security hardening and monitoring among others. These activities are security hardening and monitoring among others. These activities are
not just costly for the DC management, they may also lead to not just costly for the DC management, they may also may lead to
configuration errors and security holes. configuration errors and security holes. In particular, a few
activities have special impact on costs for dual-stacked
infrastructures:
o Development. When a new device or app version is released, it
must be tested three times: IPv4, dual-stack, and IPv6-only.
Though this does not imply a triple the effort once the
development environment is set up, a general estimate is that it
implies a 10% additional cost.
o Test. Everything QA procedure must be performed at least twice
and in many cases three times, with an estimate 10% incremental
effort.
o Operation and troubleshooting. While for L1/L2 problems we would
be talking of 1% incremental effort (in a few words, once ping6
works, checking ping is very little effort), for L3 problems a
rough estimate would an increment of 5%.
o Application development. Many applications would require to keep
two branches, with a 10-30% additional cost. The estimate here
implies a higher range, as applications cover a wide variety of
cases.
o Addition on new L3 devices, that should handle IPv4 and IPv6
flows, and provide higher performance to deal with both at the
same time. It comes with a cost increment of 5-10%.
o Network management. The incremental costs of managing two L3
network plane would come at around a 10% incremental cost.
In summary, a full dual-stack datacenter would come at an additional
5-10% operating cost than a single-stack one.
This stage can be also of interest for new deployments willing to This stage can be also of interest for new deployments willing to
apply a fresh start aligned with future IPv6 widespread usage, when a 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 relevant amount of requests are expected to be using IPv6, or to take
advantage of any of the potential benefits that an IPv6 support advantage of any of the potential benefits that an IPv6 support
infrastructure can provide. Other, and probably more compelling in infrastructure can provide. Other, and probably more compelling in
many cases, drivers for this stage may be either a lack of enough many cases, drivers for this stage may be either a lack of enough
IPv4 resources (whether private or globally unique) or a need to IPv4 resources (whether private or globally unique) or a need to
reclaim IPv4 resources from portions of the network which no longer reclaim IPv4 resources from portions of the network which no longer
need them. In these circumstances, a careful evaluation of what need them. In these circumstances, a careful evaluation of what
still needs to speak IPv4 and what does not will need to happen to still needs to speak IPv4 and what does not will need to happen to
ensure judicious use of the remaining IPv4 resources. ensure judicious use of the remaining IPv4 resources.
The potential advantages mentioned for the previous stages (load The potential advantages mentioned for the previous stages (load
balancing based on flow labels, mobility mechanisms for transient distribution based on flow labels, mobility mechanisms for transient
states in VM or data migration, controlled multicast, and better states in VM or data migration, controlled multicast, and better
mapping of L2 flat space on L3 constructs) can be applied at any mapping of L2 flat space on L3 constructs) can be applied at any
layer, even especially tailored for individual services. Obviously, layer, even especially tailored for individual services. Obviously,
the need for a careful planning of address space is even stronger the need for a careful planning of address space is even stronger
here, though the centralized protocol translation services should here, though the centralized protocol translation services should
reduce the risk of translation errors causing disruptions or security reduce the risk of translation errors causing disruptions or security
breaches. breaches.
[V6DCS] proposes an approach to a next generation DC deployment, [V6DCS] proposes an approach to a next generation DC deployment,
already demonstrated in practice, and claims the advantages of already demonstrated in practice, and claims the advantages of
materializing the stage from the beginning, providing some rationale materializing the stage from the beginning, providing some rationale
for it based on simplifying the transition process. It relies on for it based on simplifying the transition process. It relies on
stateless NAT64 ([RFC6052], [RFC6145]) to enable access from the IPv4 stateless NAT64 ([RFC6052], [RFC6145]) to enable access from the IPv4
Internet. Internet.
3. Other Operational Considerations 2.4.1. Overlay and Chaining Support
In this section we review some operational considerations related A DC infrastructure in this final stage is in the position of
providing a much better support to requirements that have been
recently formulated, mostly in the scope of other recently created
IETF working groups.
In particular, support for highly scalable VPN and multi-tenancy
according to the key requirements defined in
[I-D.ietf-nvo3-overlay-problem-statement]:
o Traffic isolation, so that a tenant's traffic is not visible to
any other tenant.
o Address independence, so that one tenant's addressing scheme does
not collide with other tenant's addressing schemes or with
addresses used within the data center itself.
o Support the placement and migration of VMs anywhere within the
data center, without being limited by DC network constraints such
as the IP subnet boundaries of the underlying DC network.
With a pervasive IPv6 infrastructure, these goals can be achieved by
means of native addressing and direct interaction of the applications
with the network infrastructure of the datacenter, and across
multiple datacenters connected via WAN links. Virtual networks can
be constructed by a natural consequence of addressing rules, traffic
isolation guaranteed by routing mechanisms, and migration directly
supported by signaling protocols.
On the other hand, service chaining is consolidating as a technique
for dynamically structuring network services, adapting them to user
requirements, provider policies, and network state. In this model,
service functions, whether physical or virtualized, are not required
to reside on the direct data path and traffic is instead steered
through required service functions, wherever they are deployed
[I-D.ietf-sfc-problem-statement].
Service function chaining requires packets in a given flow intended
to follow a particular path to be tagged by a classifier, so
intermediate service nodes in the path can route them accordingly.
The usage of flow labels can greatly simplify this classification and
allow a much simpler deployment of service function chains.
Furthermore, it offers much richer possibilities for network
architects building chains and paths inside them as well as to
application developers willing to get advantage of service chaining,
since it provides the possibility of providing rich metadata for any
given flow, in a generalization of the use cases described in
[RFC6294] and [RFC7098].
2.5. Other Operational Considerations
In this section we review some operation considerations related
addressing and management issues in V6 DC infrastructure. addressing and management issues in V6 DC infrastructure.
3.1. Addressing 2.5.1. Addressing
There are different considerations related on IPv6 addressing topics There are different considerations related on IPv6 addressing topics
in DC. Many of these considerations are already documented in a in DC. Many of these considerations are already documented in a
variety of IETF documents and in general the recommendations and best variety of IETF documents and in general the recommendations and best
practices mentioned on them apply in IPv6 DC environments. However practices mentioned on them apply in IPv6 DC environments. However
we would like to point out some topics that we consider important to we would like to point out some topics that we consider important to
mention. mention.
The first question that DC managers often have is the type of IPv6 The first question that DC managers often have is the type of IPv6
address to use; that is Provider Aggregated (PA), Provider address to use; that is Provider Aggregated (PA), Provider
Independent (PI) or Unique Local IPv6 Addresses (ULAs) [RFC4193] Independent (PI) or Unique Local IPv6 Addresses (ULAs) [RFC4193]
Related to the use of PA vs. PI, we concur with Related to the use of PA vs. PI, we concur with [RFC6883] and
[I-D.ietf-v6ops-icp-guidance] and
[I-D.ietf-v6ops-enterprise-incremental-ipv6] that PI provides [I-D.ietf-v6ops-enterprise-incremental-ipv6] that PI provides
independence from the ISP and decreases renumbering issues, it may independence from the ISP and decreases renumbering issues, it may
bring up other considerations as a fee for the allocation, a request bring up other considerations as a fee for the allocation, a request
process and allocation maintenance to the Regional Internet Registry, process and allocation maintenance to the Regional Internet Registry,
etc. In this respect, there is not a specific recommendation to use 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 either PI vs. PA as it would depend also on business and management
factors rather than pure technical. factors rather than pure technical.
ULAs should be used only in DC infrastructure that does not require ULAs should be used only in DC infrastructure that does not require
access to the public Internet; such devices may be databases servers, access to the public Internet; such devices may be databases servers,
application-servers, and management interfaces of webservers and application-servers, and management interfaces of webservers and
network devices among others. This practice may decrease the network devices among others. This practice may decrease the
renumbering issues when PA addressing is used, as only public faced renumbering issues when PA addressing is used, as only public faced
devices would require an address change. Also we would like to know devices would require an address change. Also we would like to know
that although ULAs may provide some security, the main motivation for that although ULAs may provide some security the main motivation for
its use should be address management. it used should be address management.
Another topic to discuss is the length of prefixes within the DC. In Another topic to discuss is the length of prefixes within the DC. In
general we recommend the use of subnets of 64 bits for each vlan or general we recommend the use of subnets of 64 bits for each VLAN or
network segment used in the DC. Although subnet with prefixes longer network segment used in the DC. Although subnet with prefixes longer
than 64 bits may work, it is necessary that the reader understand than 64 bits may work, it is necessary that the reader understands
that this may break stateless autoconfiguration and at least manual that this may break stateless autoconfiguration and at least manual
configuration must be employed. For details please read [RFC5375]. configuration must be employed. For details please read [RFC5375].
Address plans should follow the principles of being hierarchical and Address plans should follow the principles of being hierarchical and
able to aggregate address space. We recommend at least to have a /48 able to aggregate address space. We recommend at least to have a /48
for each data-center. If the DC provides services that require for each data-center. If the DC provides services that require
subassigment of address space we do not offer a single recommendation 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 (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. to customers), as this may depend on other no technical factors.
Instead we refer the reader to [RFC6177]. Instead we refer the reader to [RFC6177].
For point-to-point links please refer to the recommendations in For point-to-point links please refer to the recommendations in
[RFC6164]. [RFC6164].
3.2. Management Systems and Applications 2.5.2. Management Systems and Applications
Data-centers may use Internet Protocol address management (IPAM) Data-centers may use Internet Protocol address management (IPAM)
software, provisioning systems and other variety of software to software, provisioning systems and other variety of software to
document and operate. It is important that these systems are document and operate. It is important that these systems are
prepared and possibly modified to support IPv6 in their data models. prepared and possibly modified to support IPv6 in their data models.
In general, if IPv6 support for these applications has not been In general, if IPv6 support for these applications has not been
previously done, changes may take sometime as they may be not just previously done, changes may take sometime as they may be not just
adding more space in input fields but also modifying data models and adding more space in input fields but also modifying data models and
data migration. data migration.
3.3. Monitoring and Logging 2.5.3. Monitoring and Logging
Monitoring and logging are critical operations in any network Monitoring and logging are critical operations in any network
environment and they should be carried at the same level for IPv6 and environment and they should be carried at the same level for IPv6 and
IPv4. Monitoring and management operations in V6 DC are by no means IPv4. Monitoring and management operations in V6 DC are by no means
different than any other IPv6 networks environments. It is important different than any other IPv6 networks environments. It is important
to consider that the collection of information from network devices to consider that the collection of information from network devices
is orthogonal to the information collected. For example it is is orthogonal to the information collected. For example it is
possible to collect data from IPv6 MIBs using IPv4 transport. possible to collect data from IPv6 MIBs using IPv4 transport.
Similarly it is possible to collect IPv6 data generated by Netflow9/ Similarly it is possible to collect IPv6 data generated by Netflow9/
IPFIX agents in IPv4 transport. In this way the important issue to IPFIX agents in IPv4 transport. In this way the important issue to
address is that agents (i.e. network devices) are able to collect address is that agents (i.e. network devices) are able to collect
data specific to IPv6. data specific to IPv6.
And as final note on monitoring, although IPv6 MIBs are supported by And as final note on monitoring, although IPv6 MIBs are supported by
SNMP versions 1 and 2, we recommend to use SNMP version 3 instead. SNMP versions 1 and 2, we recommend to use SNMP version 3 instead.
3.4. Costs 2.5.4. Costs
It is very possible that moving from a single stack data-center It is very possible that moving from a single stack data-center
infrastructure to any of the IPv6 stages described in this document infrastructure to any of the IPv6 stages described in this document
may incur in capital expenditures. This may include but it is not may incur in capital expenditures. This may include but it is not
confined to routers, load-balancers, firewalls and software upgrades confined to routers, load-balancers, firewalls and software upgrades
among others. However the cost that most concern us is operational. among others. However the cost that most concern us is operational.
Moving the DC infrastructure operations from a single-stack to a Moving the DC infrastructure operations from a single-stack to a
dual-stack may infer in a variety of extra costs such as application dual-stack may infer in a variety of extra costs such as application
development and testing, operational troubleshooting and service development and testing, operational troubleshooting and service
deployment. At the same time, this extra cost may be seeing as 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. saving when moving from a dual-stack DC to an IPv6-Only DC.
Depending of the complexity of the DC network, provisioning and other Depending of the complexity of the DC network, provisioning and other
factors we estimate that the extra costs (and later savings) may be factors we estimate that the extra costs (and later savings) may be
around between 15 to 20%. around between 15 to 20%.
4. Security Considerations 2.6. Security Considerations
A thorough collection of operational security aspects for IPv6 A thorough collection of operational security aspects for IPv6
network is made in [I-D.ietf-opsec-v6] . Most of them, with the network is made in [I-D.ietf-opsec-v6]. Most of them, with the
probable exception of those specific to residential users, are probable exception of those specific to residential users, are
applicable in the environment we consider in this document. applicable in the environment we consider in this document.
4.1. Neighbor Discovery Protocol attacks 2.6.1. Neighbor Discovery Protocol attacks
The first important issue that V6 DC managers should be aware is the The first important issue that V6 DC manager should be aware is the
attacks against Neighbor Discovery Protocol [RFC6583]. This attack attacks against Neighbor Discovery Protocol [RFC6583]. This attack
is similar to ARP attacks [RFC4732] in IPv4 but exacerbated by the 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 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 attacker would be able to fill the Neighbor Cache of the local router
and starve its memory and processing resources by sending multiple ND and starve its memory and processing resources by sending multiple ND
packets requesting information of non-existing hosts. The result packets requesting information of non-existing hosts. The result
would be the inability of the router to respond to ND requests, to would be the inability of the router to respond to ND requests, to
update its Neighbor Cache and even to forward packets. The attack update its Neighbor Cache and even to forward packets. The attack
does need to be launched with malicious purposes; it could be just does need to be launched with malicious purposes; it could be just
the result of bad stack implementation behavior. the result of bad stack implementation behavior.
[RFC6583] mentions some options to mitigate the effects of the R[RFC6583] mentions some options to mitigate the effects of the
attacks against NDP. For example filtering unused space, minimizing attacks against NDP. For example filtering unused space, minimizing
subnet size when possible, tuning rate limits in the NDP queue and to subnet size when possible, tuning rate limits in the NDP queue and to
rely in router vendor implementations to better handle resources and rely in router vendor implementations to better handle resources and
to prioritize NDP requests. to prioritize NDP requests.
4.2. Addressing 2.6.2. Addressing
Other important security considerations in V6 DC are related to Other important security considerations in V6 DC are related to
addressing. Because of the large address space is commonly thought addressing. Because of the large address space is commonly thought
that IPv6 is not vulnerable to reconnaissance techniques such as that IPv6 is not vulnerable to reconnaissance techniques such as
scanning. Although that may be true to force brute attacks, scanning. Although that may be true to force brute attacks,
[I-D.ietf-opsec-ipv6-host-scanning] shows some techniques that may be [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 employed to speed up and improve results in order to discover IPv6
address in a subnet. The use of virtual machines and SLACC aggravate address in a subnet. The use of virtual machines and SLACC aggravate
this problem due the fact that they tend to use automatically- this problem due the fact that they tent to use automatically-
generated MAC address well known patterns. generated MAC address well known patterns.
To mitigate address-scanning attacks it is recommended to avoid using To mitigate address-scanning attacks it is recommended to avoid using
SLAAC and if used stable privacy-enhanced addresses SLAAC and if used stable privacy-enhanced addresses
[I-D.ietf-6man-stable-privacy-addresses] should be the method of [I-D.ietf-6man-stable-privacy-addresses] should be the method of
address generation. Also, for manually assigned addresses try to address generation. Also, for manually assigned addresses try to
avoid IID low-byte address (i.e. from 0 to 256), IPv4-based addresses avoid IID low-byte address (i.e. from 0 to 256), IPv4-based addresses
and wordy addresses especially for infrastructure without a fully and wordy addresses especially for infrastructure without a fully
qualified domain name. qualified domain name.
In spite of the use of manually assigned addresses is the preferred 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 method for V6 DC, SLACC and DHCPv6 may be also used for some special
reasons. However we recommend paying special attention to RA reasons. However we recommend paying special attention to RA
[RFC6104] and DHCP [I-D.gont-opsec-dhcpv6-shield] hijack attacks. In [RFC6104] and DHCP [I-D.ietf-opsec-dhcpv6-shield] hijack attacks. In
these kinds of attacks the attacker deploys rogue routers sending RA these kinds of attacks the attacker deploys rogue routers sending RA
messages or rogue DHCP servers to inject bogus information and messages or rogue DHCP servers to inject bogus information and
possibly to perform a man in the middle attack. In order to mitigate possibly to perform a man in the middle attack. In order to mitigate
this problem it is necessary to apply some techniques in access this problem it is necessary to apply some techniques in access
switches such as RA-Guard [RFC6105] at least. switches such as RA-Guard [RFC6105] at least.
Another topic that we would like to mention related to addressing is Another topic that we would like to mention related to addressing is
the use of ULAs. As we previously mentioned, although ULAs may be 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 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 on them as a security tool but better as a tool to make renumbering
easier. easier.
4.3. Edge filtering 2.6.3. Edge filtering
In order to avoid being used as a source of amplification attacks is In order to avoid being used as a source of amplification attacks is
it important to follow the rules of BCP38 [RFC2827] on ingress it important to follow the rules of BCP38 on ingress filtering. At
filtering. At the same time it is important to filter-in on the the same time it is important to filter-in on the network border all
network border all the unicast traffic and routing announcement that the unicast traffic and routing announcement that should not be
should not be routed in the Internet, commonly known as "bogus routed in the Internet, commonly known as "bogus prefixes".
prefixes".
4.4. Final Security Remarks 2.6.4. Final Security Remarks
Finally, let us just emphasize the need for careful configuration of Finally, let us just emphasize the need for careful configuration of
access control rules at the translation points. This latter one is access control rules at the translation points. This latter one is
specially sensitive in infrastructures at the dual-stack stage, as specially sensitive in infrastructures at the dual-stack stage, as
the translation points are potentially distributed, and when protocol the translation points are potentially distributed, and when protocol
translation is offered as an external service, since there can be translation is offered as an external service, since there can be
operational mismatches. operational mismatches.
5. IANA Considerations 2.7. IANA Considerations
None. None.
6. Acknowledgements 2.8. Acknowledgements
We would like to thank Tore Anderson, Wes George, Ray Hunter, Joel We would like to thank Tore Anderson, Wes George, Ray Hunter, Joel
Jaeggli, Fred Baker, Lorenzo Colitti, Dan York, Carlos Martinez, Lee Jaeggli, Fred Baker, Lorenzo Colitti, Dan York, Carlos Martinez, Lee
Howard, Alejandro Acosta, Alexis Munoz, Nicolas Fiumarelli, Santiago Howard, Alejandro Acosta, Alexis Munoz, Nicolas Fiumarelli, Santiago
Aggio and Hans Velez for their questions, suggestions, reviews and Aggio and Hans Velez for their questions, suggestions, reviews and
comments. comments.
7. Informative References 3. Informative References
[I-D.gont-opsec-dhcpv6-shield] [I-D.ietf-6man-stable-privacy-addresses]
Gont, F. and W. Liu, "DHCPv6-Shield: Protecting Against Gont, F., "A Method for Generating Semantically Opaque
Rogue DHCPv6 Servers", draft-gont-opsec-dhcpv6-shield-01 Interface Identifiers with IPv6 Stateless Address
(work in progress), October 2012. Autoconfiguration (SLAAC)",
draft-ietf-6man-stable-privacy-addresses-17 (work in
progress), January 2014.
[I-D.ietf-6man-flow-ecmp] [I-D.ietf-nvo3-overlay-problem-statement]
Carpenter, B. and S. Amante, "Using the IPv6 flow label Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L.,
for equal cost multipath routing and link aggregation in and M. Napierala, "Problem Statement: Overlays for Network
tunnels", draft-ietf-6man-flow-ecmp-05 (work in progress), Virtualization",
July 2011. draft-ietf-nvo3-overlay-problem-statement-04 (work in
progress), July 2013.
[I-D.ietf-6man-stable-privacy-addresses] [I-D.ietf-opsec-dhcpv6-shield]
Gont, F., "A method for Generating Stable Privacy-Enhanced Gont, F., Will, W., and G. Velde, "DHCPv6-Shield:
Addresses with IPv6 Stateless Address Autoconfiguration Protecting Against Rogue DHCPv6 Servers",
(SLAAC)", draft-ietf-6man-stable-privacy-addresses-11 draft-ietf-opsec-dhcpv6-shield-02 (work in progress),
(work in progress), August 2013. February 2014.
[I-D.ietf-opsec-ipv6-host-scanning] [I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-03 (work in
progress), July 2013. progress), January 2014.
[I-D.ietf-opsec-v6] [I-D.ietf-opsec-v6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", Security Considerations for IPv6 Networks",
draft-ietf-opsec-v6-03 (work in progress), July 2013. draft-ietf-opsec-v6-04 (work in progress), October 2013.
[I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-00
(work in progress), January 2014.
[I-D.ietf-v6ops-enterprise-incremental-ipv6] [I-D.ietf-v6ops-enterprise-incremental-ipv6]
Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
Guidelines", Guidelines",
draft-ietf-v6ops-enterprise-incremental-ipv6-03 (work in draft-ietf-v6ops-enterprise-incremental-ipv6-05 (work in
progress), July 2013. progress), January 2014.
[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] [I-D.sunq-v6ops-contents-transition]
Sun, Q., Liu, D., Zhao, Q., Liu, Q., Xie, C., Li, X., and Sun, Q., Liu, D., Zhao, Q., Liu, Q., Xie, C., Li, X., and
J. Qin, "Rapid Transition of IPv4 contents to be IPv6- J. Qin, "Rapid Transition of IPv4 contents to be IPv6-
accessible", draft-sunq-v6ops-contents-transition-03 (work accessible", draft-sunq-v6ops-contents-transition-03 (work
in progress), March 2012. 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 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006. Service Considerations", RFC 4732, December 2006.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
and C. Hahn, "IPv6 Unicast Address Assignment and C. Hahn, "IPv6 Unicast Address Assignment
Considerations", RFC 5375, December 2008. Considerations", RFC 5375, December 2008.
skipping to change at page 19, line 33 skipping to change at page 21, line 10
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
Router Links", RFC 6164, April 2011. Router Links", RFC 6164, April 2011.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, March 2011. Assignment to End Sites", BCP 157, RFC 6177, March 2011.
[RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for
the IPv6 Flow Label", RFC 6294, June 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012. Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content Providers and Application Service Providers",
RFC 6883, March 2013.
[RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6
Flow Label for Load Balancing in Server Farms", RFC 7098,
January 2014.
[V6DCS] "The case for IPv6-only data centres", <https:// [V6DCS] "The case for IPv6-only data centres", <https://
ripe64.ripe.net/presentations/ ripe64.ripe.net/presentations/
67-20120417-RIPE64- 67-20120417-RIPE64-
The_Case_for_IPv6_Only_Data_Centres.pdf>. The_Case_for_IPv6_Only_Data_Centres.pdf>.
Authors' Addresses Authors' Addresses
Diego R. Lopez Diego R. Lopez
Telefonica I+D Telefonica I+D
Don Ramon de la Cruz, 84 Don Ramon de la Cruz, 84
 End of changes. 54 change blocks. 
129 lines changed or deleted 223 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/