idnits 2.17.1 draft-ietf-v6ops-dc-ipv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 3, 2014) is 3725 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-opsec-dhcpv6-shield-02 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-ipv6-host-scanning-03 == Outdated reference: A later version (-27) exists of draft-ietf-opsec-v6-04 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-00 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-enterprise-incremental-ipv6-05 -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops D. Lopez 3 Internet-Draft Telefonica I+D 4 Intended status: Informational Z. Chen 5 Expires: August 7, 2014 China Telecom 6 T. Tsou 7 Huawei Technologies (USA) 8 C. Zhou 9 Huawei Technologies 10 A. Servin 11 LACNIC 12 February 3, 2014 14 IPv6 Operational Guidelines for Datacenters 15 draft-ietf-v6ops-dc-ipv6-01 17 Abstract 19 This document is intended to provide operational guidelines for 20 datacenter operators planning to deploy IPv6 in their 21 infrastructures. It aims to offer a reference framework for 22 evaluating different products and architectures, and therefore it is 23 also addressed to manufacturers and solution providers, so they can 24 use it to gauge their solutions. We believe this will translate in a 25 smoother and faster IPv6 transition for datacenters of these 26 infrastuctures. 28 The document focuses on the DC infrastructure itself, its operation, 29 and the aspects related to DC interconnection through IPv6. It does 30 not consider the particular mechanisms for making Internet services 31 provided by applications hosted in the DC available through IPv6 32 beyond the specific aspects related to how their deployment on the 33 Data Center (DC) infrastructure. 35 Apart from facilitating the transition to IPv6, the mechanisms 36 outlined here are intended to make this transition as transparent as 37 possible (if not completely transparent) to applications and services 38 running on the DC infrastructure, as well as to take advantage of 39 IPv6 features to simplify DC operations, internally and across the 40 Internet. 42 Status of this Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on August 7, 2014. 59 Copyright Notice 61 Copyright (c) 2014 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Architecture and Transition Stages . . . . . . . . . . . . . . 4 78 2.1. General Architecture . . . . . . . . . . . . . . . . . . . 5 79 2.2. Experimental Stage. Native IPv4 Infrastructure . . . . . . 7 80 2.2.1. Off-shore v6 Access . . . . . . . . . . . . . . . . . 8 81 2.3. Dual Stack Stage. Internal Adaptation . . . . . . . . . . 8 82 2.3.1. Dual-stack at the Aggregation Layer . . . . . . . . . 10 83 2.3.2. Dual-stack Extended OS/Hypervisor . . . . . . . . . . 12 84 2.4. IPv6-Only Stage. Pervasive IPv6 Infrastructure . . . . . . 12 85 2.4.1. Overlay and Chaining Support . . . . . . . . . . . . . 14 86 2.5. Other Operational Considerations . . . . . . . . . . . . . 15 87 2.5.1. Addressing . . . . . . . . . . . . . . . . . . . . . . 15 88 2.5.2. Management Systems and Applications . . . . . . . . . 16 89 2.5.3. Monitoring and Logging . . . . . . . . . . . . . . . . 16 90 2.5.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 17 91 2.6. Security Considerations . . . . . . . . . . . . . . . . . 17 92 2.6.1. Neighbor Discovery Protocol attacks . . . . . . . . . 17 93 2.6.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 18 94 2.6.3. Edge filtering . . . . . . . . . . . . . . . . . . . . 18 95 2.6.4. Final Security Remarks . . . . . . . . . . . . . . . . 19 96 2.7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19 97 2.8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19 98 3. Informative References . . . . . . . . . . . . . . . . . . . . 19 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 101 1. Introduction 103 The need for considering the aspects related to IPv4-to-IPv6 104 transition for all devices and services connected to the Internet has 105 been widely mentioned elsewhere, and it is not our intention to make 106 an additional call on it. Just let us note that many of those 107 services are already or will soon be located in Data Centers (DC), 108 what makes considering the issues associated to DC infrastructure 109 transition a key aspect both for these infrastructures themselves, 110 and for providing a simpler and clear path to service transition. 112 All issues discussed here are related to DC infrastructure 113 transition, and are intended to be orthogonal to whatever particular 114 mechanisms for making the services hosted in the DC available through 115 IPv6 beyond the specific aspects related to their deployment on the 116 infrastructure. General mechanisms related to service transition 117 have been discussed in depth elsewhere (see, for example [RFC6883] 118 and [I-D.ietf-v6ops-enterprise-incremental-ipv6]) and are considered 119 to be independent to the goal of this discussion. The applicability 120 of these general mechanisms for service transition will, in many 121 cases, depend on the supporting DC's infrastructure characteristics. 122 However, this document intends to keep both problems (service vs. 123 infrastructure transition) as different issues. 125 Furthermore, the combination of the regularity and controlled 126 management in a DC interconnection fabric with IPv6 universal end-to- 127 end addressing should translate in simpler and faster VM migrations, 128 either intra- or inter-DC, and even inter-provider. 130 2. Architecture and Transition Stages 132 This document presents a transition framework structured along 133 transition stages and operational guidance associated with the degree 134 of penetration of IPv6 into the DC communication fabric. It is worth 135 noting we are using these stages as a classification mechanism, and 136 they have not to be associated with any a succession of steps from a 137 v4-only infrastructure to full-fledged v6, but to provide a framework 138 that operators, users, and even manufacturers could use to assess 139 their plans and products. 141 There is no (explicit or implicit) requirement on starting at the 142 stage describe in first place, nor to follow them in successive 143 order. According to their needs and the available solutions, DC 144 operators can choose to start or remain at a certain stage, and 145 freely move from one to another as they see fit, without contravening 146 this document. In this respect, the classification intends to 147 support the planning in aspects such as the adaptation of the 148 different transition stages to the evolution of traffic patterns, or 149 risk assessment in what relates to deploying new components and 150 incorporating change control, integration and testing in highly- 151 complex multi-vendor infrastructures. 153 Three main transition stages can be considered when analyzing IPv6 154 deployment in the DC infrastructure, all compatible with the 155 availability of services running in the DC through IPv6: 157 o Experimental. The DC keeps a native IPv4 infrastructure, with 158 gateway routers (or even application gateways when services 159 require so) performing the adaptation to requests arriving from 160 the IPv6 Internet. 162 o Dual stack. Native IPv6 and IPv4 are present in the 163 infrastructure, up to whatever the layer in the interconnection 164 scheme where L3 is applied to packet forwarding. 166 o IPv6-Only. The DC has a fully pervasive IPv6 infrastructure, 167 including full IPv6 hypervisors, which perform the appropriate 168 tunneling or NAT if required by internal applications running 169 IPv4. 171 2.1. General Architecture 173 The diagram in Figure 1 depicts a generalized interconnection schema 174 in a DC. 176 | | 177 +-----+-----+ +-----+-----+ 178 | Gateway | | Gateway | Internet / Remote Access 179 +-----+-----+ +-----+-----+ Modules 180 | | 181 +---+-----------+ 182 | | 183 +---+---+ +---+---+ 184 | Core0 | | CoreN | Core 185 +---+---+ +---+---+ 186 / \ / / 187 / \-----\ / 188 / /---/ \ / 189 +--------+ +--------+ 190 +/-------+ | +/-------+ | 191 | Aggr01 | +-----| AggrN1 | + Aggregation 192 +---+---+/ +--------+/ 193 / \ / \ 194 / \ / \ 195 +-----+ +-----+ +-----+ +-----+ 196 | T11 |... | T1x | | T21 |... | T2y | Access 197 +-----+ +-----+ +-----+ +-----+ 198 | HyV | | HyV | | HyV | | HyV | Physical Servers 199 +:::::+ +:::::+ +:::::+ +:::::+ 200 | VMs | | VMs | | VMs | | VMs | Virtual Machines 201 +-----+ +-----+ +-----+ +-----+ 202 . . . . . . . . . . . . . . . . 203 +-----+ +-----+ +-----+ +-----+ 204 | HyV | | HyV | | HyV | | HyV | 205 +:::::+ +:::::+ +:::::+ +:::::+ 206 | VMs | | VMs | | VMs | | VMs | 207 +-----+ +-----+ +-----+ +-----+ 209 Figure 1: DC Interconnnection Schema 211 o Hypervisors provide connection services (among others) to virtual 212 machines running on physical servers. 214 o Access elements provide connectivity directly to/from physical 215 servers. The access elements are typically placed either top-of- 216 rack (ToR) or end-of-row(EoR). 218 o Aggregation elements group several (many) physical racks to 219 achieve local integration and provide as much structure as 220 possible to data paths. 222 o Core elements connect all aggregation elements acting as the DC 223 backbone. 225 o One or several gateways connecting the DC to the Internet, Branch 226 Offices, Partners, Third-Parties, and/or other DCs. The 227 interconnectivity to other DC may be in the form of VPNs, WAN 228 links, metro links or any other form of interconnection. 230 In many actual deployments, depending on DC size and design 231 decisions, some of these elements may be combined (core and gateways 232 are provider by the same routers, or hypervisors act as access 233 elements) or virtualized to some extent, but this layered schema is 234 the one that best accommodates the different options to use L2 or L3 235 at any of the different DC interconnection layers, and will help us 236 in the discussion along the document. 238 2.2. Experimental Stage. Native IPv4 Infrastructure 240 This transition stage corresponds to the first step that many 241 datacenters may take (or have taken) in order to make their external 242 services initially accessible from the IPv6 Internet and/or to 243 evaluate the possibilities around it, and corresponds to IPv6 traffic 244 patterns totally originated out of the DC or their tenants, being a 245 small percentage of the total external requests. At this stage, DC 246 network scheme and addressing do not require any important change, if 247 any. 249 It is important to remark that in no case this can be considered a 250 permanent stage in the transition, or even a long-term solution for 251 incorporating IPv6 into the DC infrastructure. This stage is only 252 recommended for experimentation or early evaluation purposes. 254 The translation of IPv6 requests into the internal infrastructure 255 addressing format occurs at the outmost level of the DC Internet 256 connection. This can be typically achieved at the DC gateway 257 routers, that support the appropriate address translation mechanisms 258 for those services required to be accessed through native IPv6 259 requests. The policies for applying adaptation can range from 260 performing it only to a limited set of specified services to 261 providing a general translation service for all public services. 262 More granular mechanisms, based on address ranges or more 263 sophisticated dynamic policies are also possible, as they are applied 264 by a limited set of control elements. These provide an additional 265 level of control to the usage of IPv6 routable addresses in the DC 266 environment, which can be especially significant in the 267 experimentation or early deployment phases this stage is applicable 268 to. 270 Even at this stage, some implicit advantages of IPv6 application come 271 into play, even if they can only be applied at the ingress elements: 273 o Flow labels can be applied to enhance load distribution, as 274 described in [RFC7098]. If the incoming IPv6 requests are 275 adequately labeled the gateway systems can use the flow labels as 276 a hint for applying load-balancing mechanisms when translating the 277 requests towards the IPv4 internal network. 279 o During VM migration (intra- or even inter-DC), Mobile IPv6 280 mechanisms can be applied to keep service availability during the 281 transient state. 283 2.2.1. Off-shore v6 Access 285 This model is also suitable to be applied in an "off-shore" mode by 286 the service provider connecting the DC infrastructure to the 287 Internet, as described in [I-D.sunq-v6ops-contents-transition]. 289 When this off-shore mode is applied, the original source address will 290 be hidden to the DC infrastructure, and therefore identification 291 techniques based on it, such as geolocation or reputation evaluation, 292 will be hampered. Unless there is a specific trust link between the 293 DC operator and the ISP, and the DC operator is able to access 294 equivalent identification interfaces provided by the ISP as an 295 additional service, the off-shore experimental stage cannot be 296 considered applicable when source address identification is required. 298 2.3. Dual Stack Stage. Internal Adaptation 300 This stage requires dual-stack elements in some internal parts of the 301 DC infrastructure. This brings some degree of partition in the 302 infrastructure, either in a horizontal (when data paths or management 303 interfaces are migrated or left in IPv4 while the rest migrate) or a 304 vertical (per tenant or service group), or even both. 306 Although it may seem an artificial case, situations requiring this 307 stage can arise from different requirements from the user base, or 308 the need for technology changes at different points of the 309 infrastructure, or even the goal of having the possibility of 310 experimenting new solutions in a controlled real-operations 311 environment, at the price of the additional complexity of dealing 312 with a double protocol stack, as noted in [RFC6883] and elsewhere. 314 This transition stage can accommodate different traffic patterns, 315 both internal and external, though it better fits to scenarios of a 316 clear differentiation of different types of traffic (external vs. 317 internal, data vs management...), and/or a more or less even 318 distribution of external requests. A common scenario would include 319 native dual stack servers for certain services combined with single 320 stack ones for others (web server in dual stack and database servers 321 only supporting v4, for example). 323 At this stage, the advantages outlined above on load balancing based 324 on flow labels and Mobile IP mechanisms are applicable to any L3- 325 based mechanism (intra- as well as inter-DC). They will translate 326 into enhanced VM mobility, more effective load balancing, and higher 327 service availability. Furthermore, the simpler integration provided 328 by IPv6 to and from the L2 flat space to the structured L3 one can be 329 applied to achieve simpler deployments, as well as alleviating 330 encapsulation and fragmentation issues when traversing between L2 and 331 L3 spaces. With an appropriate prefix management, automatic address 332 assignment, discovery, and renumbering can be applied not only to 333 public service interfaces, but most notably to data and management 334 paths. Other potential advantages include the application of 335 multicast scopes to limit broadcast floods, and the usage of specific 336 security headers to enhance tenant differentiation. 338 In general, all these advantages are especially significative to 339 overlay techniques applied to support multi-tenancy and inter-DC 340 operation. 342 On the other hand, this stage requires a much more careful planning 343 of addressing (please refer to ([RFC5375]) schemas and access 344 control, according to security levels. While the experimental stage 345 implies relatively few global routable addresses, this one brings the 346 advantages and risks of using different kinds of addresses at each 347 point of the IPv6-aware infrastructure. 349 2.3.1. Dual-stack at the Aggregation Layer 351 +---------------------+ 352 | Internet / External | 353 +---------+-----------+ 354 | 355 +-----+----+ 356 | Gateway | 357 +-----+----+ 358 . 359 . Core Level 360 . 361 +--+--+ 362 | FW | 363 +--+--+ 364 | Aggregation Level 365 +--+--+ 366 | MB | 367 +--+--+ 368 _ / \_ 369 / \ 370 +--+--+ +--+--+ 371 | Web | ... | Web | 372 +--+--+ +--+--+ 373 | \ __ _ _/ | 374 | / \ | 375 +--+--+ +--+--+ 376 |Cache| | DB | 377 +-----+ +-----+ 379 Figure 2: Data Center Application Scheme 381 An initial approach corresponding to this transition stage relies on 382 taking advantage of specific elements at the aggregation layer 383 described in Figure 1, and make them able to provide dual-stack 384 gatewaying to the IPv4-based servers and data infrastructure. 386 Typically, firewalls (FW) are deployed as the security edge of the 387 whole service domain and provides safe access control of this service 388 domain from other function domains. In addition, some application 389 optimization based on devices and security devices (generally known 390 as middleboxes, e.g. Load Balancers, SSL VPN, IPS and etc.) may be 391 deployed in the aggregation level to alleviate the burden of the 392 server and to guarantee deep security, as shown in Figure 2. The 393 choice of a particular kind of middlebox for this dual-stack approach 394 shall be based on the nature of the services and the deployment of 395 the middleboxes in the DC infrastructure. 397 The middlebox could be upgraded to support the data transmission. 398 There may be two ways to achieve this at the edge of the DC: 399 Encapsulation and NAT. In the encapsulation case, the middlebox 400 function carries the IPv6 traffic over IPv4 using an encapsulation 401 (IPv6-in-IPv4). In the NAT case, there are already some technologies 402 to solve this problem. For example, DNS and NAT devices could be 403 concatenated for IPv4/IPv6 translation if IPv6 host needs to visit 404 IPv4 servers. However, this may require the concatenation of 405 multiple network devices, which means the NAT tables needs to be 406 synchronized at different devices. As described below, a simplified 407 IPv4/IPv6 translation model can be applied, which could be 408 implemented in the device. The mapping information of IPv4 and IPv6 409 will be generated automatically based on the information of the 410 middlebox. The host IP address will be translated without port 411 translation. 413 +----------+------------------------------+ 414 |Dual Stack| IPv4-only +----------+ | 415 | | +----|Web Server| | 416 | +------|------+ / +----------+ | 417 +--------+ +-------+ | | | | / | 418 |Internet|--|Gateway|---|---+Load-Balancer+-- \ | 419 | | | | | | | | \ +----------+ | 420 +--------+ +-------+ | +------|------+ +----|Web Server| | 421 | | +----------+ | 422 +----------+------------------------------+ 424 Figure 3: Dual Stack middlebox (Load-Balancer) mechanism 426 As shown in Figure 3,the middlebox (a load-balancer, LB, in this 427 case) can be considered divided into two parts: The dual-stack part 428 facing the external border, and the IPv4-only part which contains the 429 traditional LB functions. The IPv4 DC is allocated an IPv6 prefix 430 which is for the VSIPv6 (Virtual Service IPv6 Address). We suggest 431 that the IPv6 prefix is not the well-known prefix in order to avoid 432 the IPv4 routings of the services in different DCs spread to the IPv6 433 network. The VSIPv4 (Virtual Service IPv4 Address) is embedded in 434 VSIPv6 using the allocated IPv6 prefix. In this way, the LB has the 435 stateless IP address mapping between VSIPv6 and VSIPv4, and 436 synchronization is not required between LB and DNS64 server. 438 The dual-stack part of the LB has a private IPv4 address pool. When 439 IPv6 packets arrive, the dual-stack part does the one-on-one SIP 440 (source IP address) mapping (as defined in 441 [I-D.sunq-v6ops-contents-transition]) between IPv4 private address 442 and IPv6 SIP. Because there will be too many UDP/TCP sessions 443 between the DC and Internet, the IP addresses binding tables between 444 IPv6 and IPv4 are not session-based, but SIP-based. Thus, the dual- 445 stack part of LB builds IP binding stateful tables for the host IPv6 446 address and private IPv4 address of the pool. When the following 447 IPv6 packets of the host come from Internet to the LB, the dual stack 448 part does the IP address translation for the packets. Thus, the IPv6 449 packets were translated to IPv4 packets and sent to the IPv4 only 450 part of the LB. 452 2.3.2. Dual-stack Extended OS/Hypervisor 454 Another option for deploying a infrastructure at the dual-stack stage 455 would bring dual-stack much closer to the application servers, by 456 requiring hypervisors, VMs and applications in the v6-capable zone of 457 the DC to be able to operate in dual stack. This way, incoming 458 connections would be dealt in a seamless manner, while for outgoing 459 ones an OS-specific replacement for system calls like gethostbyname() 460 and getaddrinfo() would accept a character string (an IPv4 literal, 461 an IPv6 literal, or a domain name) and would return a connected 462 socket or an error message, having executed a happy eyeballs 463 algorithm ([RFC6555]). 465 If these hypothetical system call replacements were smart enough, 466 they would allow the transparent interoperation of DCs with different 467 levels of v6 penetration, either horizontal (internal data paths are 468 not migrated, for example) or vertical (per tenant or service group). 469 This approach requires, on the other hand, all the involved DC 470 infrastructure to become dual-stack, as well as some degree of 471 explicit application adaptation. 473 2.4. IPv6-Only Stage. Pervasive IPv6 Infrastructure 475 We can consider a DC infrastructure at the final stage when all 476 network layer elements, including hypervisors, are IPv6-aware and 477 apply it by default. Conversely with the experimental stage, access 478 from the IPv4 Internet is achieved, when required, by protocol 479 translation performed at the edge infrastructure elements, or even 480 supplied by the service provider as an additional network service. 482 There are different drivers that could motivate DC managers to 483 transition to this stage. In principle the scarcity of IPv4 484 addresses may require to reclaim IPv4 resources from portions of the 485 network infrastructure which no longer need them. Furthermore, the 486 unavailability of IPv4 address would make dual-stack environments not 487 possible anymore and careful assessments will be perfumed to asses 488 where to use the remaining IPv4 resources. 490 Another important motivation to move DC operations from dual-stack to 491 IPv6-only is to save costs and operation activities that managing a 492 single-stack network could bring in comparison with managing two 493 stacks. Today, besides of learning to manage two different stacks, 494 network and system administrators require to duplicate other tasks 495 such as IP address management, firewalls configuration, system 496 security hardening and monitoring among others. These activities are 497 not just costly for the DC management, they may also may lead to 498 configuration errors and security holes. In particular, a few 499 activities have special impact on costs for dual-stacked 500 infrastructures: 502 o Development. When a new device or app version is released, it 503 must be tested three times: IPv4, dual-stack, and IPv6-only. 504 Though this does not imply a triple the effort once the 505 development environment is set up, a general estimate is that it 506 implies a 10% additional cost. 508 o Test. Everything QA procedure must be performed at least twice 509 and in many cases three times, with an estimate 10% incremental 510 effort. 512 o Operation and troubleshooting. While for L1/L2 problems we would 513 be talking of 1% incremental effort (in a few words, once ping6 514 works, checking ping is very little effort), for L3 problems a 515 rough estimate would an increment of 5%. 517 o Application development. Many applications would require to keep 518 two branches, with a 10-30% additional cost. The estimate here 519 implies a higher range, as applications cover a wide variety of 520 cases. 522 o Addition on new L3 devices, that should handle IPv4 and IPv6 523 flows, and provide higher performance to deal with both at the 524 same time. It comes with a cost increment of 5-10%. 526 o Network management. The incremental costs of managing two L3 527 network plane would come at around a 10% incremental cost. 529 In summary, a full dual-stack datacenter would come at an additional 530 5-10% operating cost than a single-stack one. 532 This stage can be also of interest for new deployments willing to 533 apply a fresh start aligned with future IPv6 widespread usage, when a 534 relevant amount of requests are expected to be using IPv6, or to take 535 advantage of any of the potential benefits that an IPv6 support 536 infrastructure can provide. Other, and probably more compelling in 537 many cases, drivers for this stage may be either a lack of enough 538 IPv4 resources (whether private or globally unique) or a need to 539 reclaim IPv4 resources from portions of the network which no longer 540 need them. In these circumstances, a careful evaluation of what 541 still needs to speak IPv4 and what does not will need to happen to 542 ensure judicious use of the remaining IPv4 resources. 544 The potential advantages mentioned for the previous stages (load 545 distribution based on flow labels, mobility mechanisms for transient 546 states in VM or data migration, controlled multicast, and better 547 mapping of L2 flat space on L3 constructs) can be applied at any 548 layer, even especially tailored for individual services. Obviously, 549 the need for a careful planning of address space is even stronger 550 here, though the centralized protocol translation services should 551 reduce the risk of translation errors causing disruptions or security 552 breaches. 554 [V6DCS] proposes an approach to a next generation DC deployment, 555 already demonstrated in practice, and claims the advantages of 556 materializing the stage from the beginning, providing some rationale 557 for it based on simplifying the transition process. It relies on 558 stateless NAT64 ([RFC6052], [RFC6145]) to enable access from the IPv4 559 Internet. 561 2.4.1. Overlay and Chaining Support 563 A DC infrastructure in this final stage is in the position of 564 providing a much better support to requirements that have been 565 recently formulated, mostly in the scope of other recently created 566 IETF working groups. 568 In particular, support for highly scalable VPN and multi-tenancy 569 according to the key requirements defined in 570 [I-D.ietf-nvo3-overlay-problem-statement]: 572 o Traffic isolation, so that a tenant's traffic is not visible to 573 any other tenant. 575 o Address independence, so that one tenant's addressing scheme does 576 not collide with other tenant's addressing schemes or with 577 addresses used within the data center itself. 579 o Support the placement and migration of VMs anywhere within the 580 data center, without being limited by DC network constraints such 581 as the IP subnet boundaries of the underlying DC network. 583 With a pervasive IPv6 infrastructure, these goals can be achieved by 584 means of native addressing and direct interaction of the applications 585 with the network infrastructure of the datacenter, and across 586 multiple datacenters connected via WAN links. Virtual networks can 587 be constructed by a natural consequence of addressing rules, traffic 588 isolation guaranteed by routing mechanisms, and migration directly 589 supported by signaling protocols. 591 On the other hand, service chaining is consolidating as a technique 592 for dynamically structuring network services, adapting them to user 593 requirements, provider policies, and network state. In this model, 594 service functions, whether physical or virtualized, are not required 595 to reside on the direct data path and traffic is instead steered 596 through required service functions, wherever they are deployed 597 [I-D.ietf-sfc-problem-statement]. 599 Service function chaining requires packets in a given flow intended 600 to follow a particular path to be tagged by a classifier, so 601 intermediate service nodes in the path can route them accordingly. 602 The usage of flow labels can greatly simplify this classification and 603 allow a much simpler deployment of service function chains. 604 Furthermore, it offers much richer possibilities for network 605 architects building chains and paths inside them as well as to 606 application developers willing to get advantage of service chaining, 607 since it provides the possibility of providing rich metadata for any 608 given flow, in a generalization of the use cases described in 609 [RFC6294] and [RFC7098]. 611 2.5. Other Operational Considerations 613 In this section we review some operation considerations related 614 addressing and management issues in V6 DC infrastructure. 616 2.5.1. Addressing 618 There are different considerations related on IPv6 addressing topics 619 in DC. Many of these considerations are already documented in a 620 variety of IETF documents and in general the recommendations and best 621 practices mentioned on them apply in IPv6 DC environments. However 622 we would like to point out some topics that we consider important to 623 mention. 625 The first question that DC managers often have is the type of IPv6 626 address to use; that is Provider Aggregated (PA), Provider 627 Independent (PI) or Unique Local IPv6 Addresses (ULAs) [RFC4193] 628 Related to the use of PA vs. PI, we concur with [RFC6883] and 629 [I-D.ietf-v6ops-enterprise-incremental-ipv6] that PI provides 630 independence from the ISP and decreases renumbering issues, it may 631 bring up other considerations as a fee for the allocation, a request 632 process and allocation maintenance to the Regional Internet Registry, 633 etc. In this respect, there is not a specific recommendation to use 634 either PI vs. PA as it would depend also on business and management 635 factors rather than pure technical. 637 ULAs should be used only in DC infrastructure that does not require 638 access to the public Internet; such devices may be databases servers, 639 application-servers, and management interfaces of webservers and 640 network devices among others. This practice may decrease the 641 renumbering issues when PA addressing is used, as only public faced 642 devices would require an address change. Also we would like to know 643 that although ULAs may provide some security the main motivation for 644 it used should be address management. 646 Another topic to discuss is the length of prefixes within the DC. In 647 general we recommend the use of subnets of 64 bits for each VLAN or 648 network segment used in the DC. Although subnet with prefixes longer 649 than 64 bits may work, it is necessary that the reader understands 650 that this may break stateless autoconfiguration and at least manual 651 configuration must be employed. For details please read [RFC5375]. 653 Address plans should follow the principles of being hierarchical and 654 able to aggregate address space. We recommend at least to have a /48 655 for each data-center. If the DC provides services that require 656 subassigment of address space we do not offer a single recommendation 657 (i.e. request a /40 prefix from an RIR or ISP and assign /48 prefixes 658 to customers), as this may depend on other no technical factors. 659 Instead we refer the reader to [RFC6177]. 661 For point-to-point links please refer to the recommendations in 662 [RFC6164]. 664 2.5.2. Management Systems and Applications 666 Data-centers may use Internet Protocol address management (IPAM) 667 software, provisioning systems and other variety of software to 668 document and operate. It is important that these systems are 669 prepared and possibly modified to support IPv6 in their data models. 670 In general, if IPv6 support for these applications has not been 671 previously done, changes may take sometime as they may be not just 672 adding more space in input fields but also modifying data models and 673 data migration. 675 2.5.3. Monitoring and Logging 677 Monitoring and logging are critical operations in any network 678 environment and they should be carried at the same level for IPv6 and 679 IPv4. Monitoring and management operations in V6 DC are by no means 680 different than any other IPv6 networks environments. It is important 681 to consider that the collection of information from network devices 682 is orthogonal to the information collected. For example it is 683 possible to collect data from IPv6 MIBs using IPv4 transport. 684 Similarly it is possible to collect IPv6 data generated by Netflow9/ 685 IPFIX agents in IPv4 transport. In this way the important issue to 686 address is that agents (i.e. network devices) are able to collect 687 data specific to IPv6. 689 And as final note on monitoring, although IPv6 MIBs are supported by 690 SNMP versions 1 and 2, we recommend to use SNMP version 3 instead. 692 2.5.4. Costs 694 It is very possible that moving from a single stack data-center 695 infrastructure to any of the IPv6 stages described in this document 696 may incur in capital expenditures. This may include but it is not 697 confined to routers, load-balancers, firewalls and software upgrades 698 among others. However the cost that most concern us is operational. 699 Moving the DC infrastructure operations from a single-stack to a 700 dual-stack may infer in a variety of extra costs such as application 701 development and testing, operational troubleshooting and service 702 deployment. At the same time, this extra cost may be seeing as 703 saving when moving from a dual-stack DC to an IPv6-Only DC. 705 Depending of the complexity of the DC network, provisioning and other 706 factors we estimate that the extra costs (and later savings) may be 707 around between 15 to 20%. 709 2.6. Security Considerations 711 A thorough collection of operational security aspects for IPv6 712 network is made in [I-D.ietf-opsec-v6]. Most of them, with the 713 probable exception of those specific to residential users, are 714 applicable in the environment we consider in this document. 716 2.6.1. Neighbor Discovery Protocol attacks 718 The first important issue that V6 DC manager should be aware is the 719 attacks against Neighbor Discovery Protocol [RFC6583]. This attack 720 is similar to ARP attacks [RFC4732] in IPv4 but exacerbated by the 721 fact that the common size of an IPv6 subnet is /64. In principle an 722 attacker would be able to fill the Neighbor Cache of the local router 723 and starve its memory and processing resources by sending multiple ND 724 packets requesting information of non-existing hosts. The result 725 would be the inability of the router to respond to ND requests, to 726 update its Neighbor Cache and even to forward packets. The attack 727 does need to be launched with malicious purposes; it could be just 728 the result of bad stack implementation behavior. 730 R[RFC6583] mentions some options to mitigate the effects of the 731 attacks against NDP. For example filtering unused space, minimizing 732 subnet size when possible, tuning rate limits in the NDP queue and to 733 rely in router vendor implementations to better handle resources and 734 to prioritize NDP requests. 736 2.6.2. Addressing 738 Other important security considerations in V6 DC are related to 739 addressing. Because of the large address space is commonly thought 740 that IPv6 is not vulnerable to reconnaissance techniques such as 741 scanning. Although that may be true to force brute attacks, 742 [I-D.ietf-opsec-ipv6-host-scanning] shows some techniques that may be 743 employed to speed up and improve results in order to discover IPv6 744 address in a subnet. The use of virtual machines and SLACC aggravate 745 this problem due the fact that they tent to use automatically- 746 generated MAC address well known patterns. 748 To mitigate address-scanning attacks it is recommended to avoid using 749 SLAAC and if used stable privacy-enhanced addresses 750 [I-D.ietf-6man-stable-privacy-addresses] should be the method of 751 address generation. Also, for manually assigned addresses try to 752 avoid IID low-byte address (i.e. from 0 to 256), IPv4-based addresses 753 and wordy addresses especially for infrastructure without a fully 754 qualified domain name. 756 In spite of the use of manually assigned addresses is the preferred 757 method for V6 DC, SLACC and DHCPv6 may be also used for some special 758 reasons. However we recommend paying special attention to RA 759 [RFC6104] and DHCP [I-D.ietf-opsec-dhcpv6-shield] hijack attacks. In 760 these kinds of attacks the attacker deploys rogue routers sending RA 761 messages or rogue DHCP servers to inject bogus information and 762 possibly to perform a man in the middle attack. In order to mitigate 763 this problem it is necessary to apply some techniques in access 764 switches such as RA-Guard [RFC6105] at least. 766 Another topic that we would like to mention related to addressing is 767 the use of ULAs. As we previously mentioned, although ULAs may be 768 used to hide host from the outside world we do not recommend to rely 769 on them as a security tool but better as a tool to make renumbering 770 easier. 772 2.6.3. Edge filtering 774 In order to avoid being used as a source of amplification attacks is 775 it important to follow the rules of BCP38 on ingress filtering. At 776 the same time it is important to filter-in on the network border all 777 the unicast traffic and routing announcement that should not be 778 routed in the Internet, commonly known as "bogus prefixes". 780 2.6.4. Final Security Remarks 782 Finally, let us just emphasize the need for careful configuration of 783 access control rules at the translation points. This latter one is 784 specially sensitive in infrastructures at the dual-stack stage, as 785 the translation points are potentially distributed, and when protocol 786 translation is offered as an external service, since there can be 787 operational mismatches. 789 2.7. IANA Considerations 791 None. 793 2.8. Acknowledgements 795 We would like to thank Tore Anderson, Wes George, Ray Hunter, Joel 796 Jaeggli, Fred Baker, Lorenzo Colitti, Dan York, Carlos Martinez, Lee 797 Howard, Alejandro Acosta, Alexis Munoz, Nicolas Fiumarelli, Santiago 798 Aggio and Hans Velez for their questions, suggestions, reviews and 799 comments. 801 3. Informative References 803 [I-D.ietf-6man-stable-privacy-addresses] 804 Gont, F., "A Method for Generating Semantically Opaque 805 Interface Identifiers with IPv6 Stateless Address 806 Autoconfiguration (SLAAC)", 807 draft-ietf-6man-stable-privacy-addresses-17 (work in 808 progress), January 2014. 810 [I-D.ietf-nvo3-overlay-problem-statement] 811 Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., 812 and M. Napierala, "Problem Statement: Overlays for Network 813 Virtualization", 814 draft-ietf-nvo3-overlay-problem-statement-04 (work in 815 progress), July 2013. 817 [I-D.ietf-opsec-dhcpv6-shield] 818 Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: 819 Protecting Against Rogue DHCPv6 Servers", 820 draft-ietf-opsec-dhcpv6-shield-02 (work in progress), 821 February 2014. 823 [I-D.ietf-opsec-ipv6-host-scanning] 824 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 825 Networks", draft-ietf-opsec-ipv6-host-scanning-03 (work in 826 progress), January 2014. 828 [I-D.ietf-opsec-v6] 829 Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational 830 Security Considerations for IPv6 Networks", 831 draft-ietf-opsec-v6-04 (work in progress), October 2013. 833 [I-D.ietf-sfc-problem-statement] 834 Quinn, P. and T. Nadeau, "Service Function Chaining 835 Problem Statement", draft-ietf-sfc-problem-statement-00 836 (work in progress), January 2014. 838 [I-D.ietf-v6ops-enterprise-incremental-ipv6] 839 Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 840 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 841 Guidelines", 842 draft-ietf-v6ops-enterprise-incremental-ipv6-05 (work in 843 progress), January 2014. 845 [I-D.sunq-v6ops-contents-transition] 846 Sun, Q., Liu, D., Zhao, Q., Liu, Q., Xie, C., Li, X., and 847 J. Qin, "Rapid Transition of IPv4 contents to be IPv6- 848 accessible", draft-sunq-v6ops-contents-transition-03 (work 849 in progress), March 2012. 851 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 852 Addresses", RFC 4193, October 2005. 854 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 855 Service Considerations", RFC 4732, December 2006. 857 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 858 and C. Hahn, "IPv6 Unicast Address Assignment 859 Considerations", RFC 5375, December 2008. 861 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 862 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 863 October 2010. 865 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 866 Problem Statement", RFC 6104, February 2011. 868 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 869 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 870 February 2011. 872 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 873 Algorithm", RFC 6145, April 2011. 875 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 876 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 877 Router Links", RFC 6164, April 2011. 879 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 880 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 882 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 883 the IPv6 Flow Label", RFC 6294, June 2011. 885 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 886 Dual-Stack Hosts", RFC 6555, April 2012. 888 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 889 Neighbor Discovery Problems", RFC 6583, March 2012. 891 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 892 Content Providers and Application Service Providers", 893 RFC 6883, March 2013. 895 [RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 896 Flow Label for Load Balancing in Server Farms", RFC 7098, 897 January 2014. 899 [V6DCS] "The case for IPv6-only data centres", . 904 Authors' Addresses 906 Diego R. Lopez 907 Telefonica I+D 908 Don Ramon de la Cruz, 84 909 Madrid 28006 910 Spain 912 Phone: +34 913 129 041 913 Email: diego@tid.es 915 Zhonghua Chen 916 China Telecom 917 P.R.China 919 Phone: 920 Email: 18918588897@189.cn 921 Tina Tsou 922 Huawei Technologies (USA) 923 2330 Central Expressway 924 Santa Clara, CA 95050 925 USA 927 Phone: +1 408 330 4424 928 Email: Tina.Tsou.Zouting@huawei.com 930 Cathy Zhou 931 Huawei Technologies 932 Bantian, Longgang District 933 Shenzhen 518129 934 P.R. China 936 Phone: 937 Email: cathy.zhou@huawei.com 939 Arturo Servin 940 LACNIC 941 Rambla Republica de Mexico 6125 942 Montevideo 11300 943 Uruguay 945 Phone: +598 2604 2222 946 Email: aservin@lacnic.net