idnits 2.17.1 draft-anderson-v6ops-siit-dc-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6145]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 05, 2014) is 3492 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Anderson 3 Internet-Draft Redpill Linpro 4 Intended status: Standards Track October 05, 2014 5 Expires: April 08, 2015 7 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments 8 draft-anderson-v6ops-siit-dc-01 10 Abstract 12 This document describes SIIT-DC, an extension to Stateless IP/ICMP 13 Translation (SIIT) [RFC6145] that makes it ideally suited for use in 14 IPv6 data centre environments. SIIT-DC simultaneously facilitates 15 IPv6 deployment and IPv4 address conservation. The overall SIIT-DC 16 architecture is described, as well as guidelines for operators. 17 Finally, the normative implementation requirements are described, as 18 a list of additions and changes to SIIT [RFC6145]. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 08, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Motivation and Goals . . . . . . . . . . . . . . . . . . 3 56 1.1.1. Single Stack IPv6 Operation . . . . . . . . . . . . . 4 57 1.1.2. Stateless Operation . . . . . . . . . . . . . . . . . 4 58 1.1.3. IPv4 Address Conservation . . . . . . . . . . . . . . 4 59 1.1.4. No Loss of End User's IPv4 Source Address . . . . . . 5 60 1.1.5. Compatible with Standard IPv6 Implementations . . . . 5 61 1.1.6. No Architectural Dependency on IPv4 . . . . . . . . . 6 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 7 64 3.1. DNS Configuration . . . . . . . . . . . . . . . . . . . . 9 65 3.2. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9 66 4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 11 67 4.1. Application Support for NAT . . . . . . . . . . . . . . . 12 68 4.2. Application Support for IPv6 . . . . . . . . . . . . . . 12 69 4.3. Application Communication Pattern . . . . . . . . . . . . 12 70 4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 13 71 4.5. Routing Considerations . . . . . . . . . . . . . . . . . 13 72 4.6. Location of the SIIT-DC Gateways . . . . . . . . . . . . 14 73 4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 15 74 4.8. Packet Size and Fragmentation Considerations . . . . . . 15 75 4.8.1. IPv4/IPv6 Header Size Difference . . . . . . . . . . 16 76 4.8.2. IPv6 Atomic Fragments . . . . . . . . . . . . . . . . 16 77 4.8.3. Minimum Path MTU Difference Between IPv4 and IPv6 . . 16 78 5. Implementation Requirements . . . . . . . . . . . . . . . . . 18 79 5.1. Compliance with RFC6145 and RFC6052 . . . . . . . . . . . 18 80 5.2. Static Address Mapping Function . . . . . . . . . . . . . 18 81 5.3. Support for Increasing the IPv6 Path MTU . . . . . . . . 19 82 5.4. Loop Prevention Mechanism . . . . . . . . . . . . . . . . 19 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 84 7. Requirements Language . . . . . . . . . . . . . . . . . . . . 20 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 9.1. Mistaking the Translation Prefix for a Trusted Network . 20 88 9.2. Packets Looping Through the SIIT-DC Function . . . . . . 20 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 91 10.2. Informative References . . . . . . . . . . . . . . . . . 21 92 Appendix A. Complete SIIT-DC topology example . . . . . . . . . 23 93 Appendix B. Comparison to Other Deployment Approaches . . . . . 26 94 B.1. IPv4-only . . . . . . . . . . . . . . . . . . . . . . . . 26 95 B.2. IPv4-only + NAPT44 . . . . . . . . . . . . . . . . . . . 26 96 B.3. IPv4-only + NAT64 . . . . . . . . . . . . . . . . . . . . 28 97 B.4. Dual Stack . . . . . . . . . . . . . . . . . . . . . . . 29 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 100 1. Introduction 102 SIIT-DC is an extension of SIIT [RFC6145] that provides a network- 103 centric stateless translation service that allows a data centre 104 operator or Internet Content Provider (ICP) to run a data centre 105 network, servers, and applications using exclusively IPv6, while at 106 the same time ensuring that end users that have only IPv4 107 connectivity will be able to continue to access the services and 108 applications. 110 1.1. Motivation and Goals 112 Historically, dual stack [RFC4213] has been the recommended way to 113 transition from an IPv4-only environment to one capable of serving 114 IPv6 users. For data centre operators and Internet content 115 providers, dual stack operation has a number of disadvantages 116 compared to single stack operation. In particular, running two 117 protocols rather than one results in increased complexity and 118 operational overhead, with a very low expected return on investment 119 in the short to medium term, as there are practically no end-users 120 who have only connectivity to the IPv6 Internet. Furthermore, the 121 dual stack approach does not in any way help with the depletion of 122 the IPv4 address space. 124 Therefore, a better approach is needed. The design goals are: 126 o Promote the deployment of native IPv6 services (cf. [RFC6540]). 128 o Provide IPv4 service availability for legacy users with no loss of 129 performance or functionality. 131 o To ensure that that the legacy users' IPv4 addresses remain 132 available to the servers and applications. 134 o To conserve and maximise the utilisation of IPv4 addresses. 136 o To avoid introducing more complexity than absolutely necessary, 137 especially on the servers and applications. 139 o To be easy to scale and deploy in a fault-tolerant manner. 141 The following subsections elaborates on how SIIT-DC meets these 142 goals. 144 1.1.1. Single Stack IPv6 Operation 146 SIIT-DC allows an operator to build their applications on an 147 IPv6-only foundation. IPv4 end-user connectivity becomes a service 148 provided by the network, which systems administration and application 149 development staff do not need to concern themselves with. 151 Obviously, this will promote universal IPv6 deployment for all of the 152 provider's services and applications. 154 It is worth noting that SIIT-DC requires no special support or change 155 from the underlying IPv6 infrastructure, it will work with any kind 156 of IPv6 network. Traffic between IPv6-enabled end users and 157 IPv6-enabled services will always be native, and SIIT-DC will not be 158 involved in it at all. 160 1.1.2. Stateless Operation 162 Unlike other solutions that provide either dual stack availability to 163 single-stack services (e.g., Stateful NAT64 [RFC6146] and Layer-4/7 164 proxies), or that provide conservation of IPv4 addresses (e.g., 165 NAPT44 [RFC3022]), a SIIT-DC Gateway does not keep any state between 166 each packet in a single connection or flow. In this sense it 167 operates exactly like a normal IP router, and has similar scaling 168 properties - the limiting factors are packets per second and 169 bandwidth. The number of concurrent flows and flow initiation rates 170 are irrelevant for performance. 172 This not only allows individual SIIT-DC Gateways to easily attain 173 "line rate" performance, it also allows for per-packet load balancing 174 between multiple SIIT-DC Gateways using Equal-Cost Multipath Routing 175 [RFC2991]. Asymmetric routing is also acceptable, which makes it 176 easy to avoid sub-optimal traffic patterns; the prefixes involved may 177 be anycasted from all the SIIT-DC Gateways in the provider's network, 178 thus ensuring that the most optimal path through the network is used, 179 even where the optimal path in one direction differs from the optimal 180 path in the opposite direction. 182 Finally, stateless operation means that high availability is easily 183 achieved. If an SIIT-DC Gateway should fail, its traffic can be re- 184 routed onto another SIIT-DC Gateway using a standard IP routing 185 protocol. This does not impact existing flows any more than what any 186 other IP re-routing event would. 188 1.1.3. IPv4 Address Conservation 190 In most parts of the world, it is difficult or even impossible to 191 obtain generously sized IPv4 allocations from the Regional Internet 192 Registries. The resulting scarcity in turn impacts individual end 193 users and operators, which might be forced to purchase IPv4 addresses 194 from other operators in order to cover their needs. This process can 195 be risky to business continuity, in the case no suitable block for 196 sale can be located, and/or turn out to be prohibitively expensive. 197 Even so, a data centre operator will find that providing IPv4 service 198 is essential, as a large share of the Internet users still does not 199 have IPv6 connectivity. 201 A key goal of SIIT-DC is to help reduce a data centre operator's IPv4 202 address requirement to the absolute minimum, by allowing the operator 203 to remove them entirely from components that do not need to 204 communicate with endpoints in the IPv4 Internet. One example would 205 be servers that are operating in a supporting/backend role and only 206 communicates with to other servers (database servers, file servers, 207 and so on). Another example would be the network infrastructure 208 itself (router-to-router links, loopback addresses, and so on). 209 Furthermore, as LAN prefix sizes must always be rounded up to the 210 nearest power of two (or larger, if one reserves space for future 211 growth), even more IPv4 addresses will often end up being wasted 212 without even being used. 214 With SIIT-DC, the operator can remove these valuable IPv4 addresses 215 from his backend servers and network infrastructure, and reassign 216 them to the SIIT-DC service as IPv4 Service Addresses. There is no 217 requirement that IPv4 Service Addresses are assigned in an aggregated 218 manner, so there is nothing lost due to infrastructure overhead; 219 every single IPv4 address assigned to SIIT-DC can be used an IPv4 220 Service Address. 222 1.1.4. No Loss of End User's IPv4 Source Address 224 SIIT-DC will map the entire end-user's IPv4 source address into an 225 predefined IPv6 translation prefix. This ensures that there is no 226 loss of information; the end-user's IPv4 source address remains 227 available to the server/application, allowing it to perform tasks 228 like Geo-Location, logging, abuse handling, and so forth. 230 1.1.5. Compatible with Standard IPv6 Implementations 232 Except for the introduction of the SIIT-DC Gateways themselves, no 233 change to the network, servers, applications, or anything else is 234 required in order to support SIIT-DC. SIIT-DC is practically 235 invisibible from the point of view of the the IPv4 clients, the IPv6 236 servers, the IPv6 data centre network, and the IPv4 Internet. SIIT- 237 DC interoperates with all standards-compliant IPv4 or IPv6 stacks. 239 1.1.6. No Architectural Dependency on IPv4 241 SIIT-DC will allow an ICP or data centre operator to build 242 infrastructure and applications entirely on IPv6. This means that 243 when the day comes to discontinue support for IPv4, no change needs 244 to be made to the overall architecture - it's only a matter of 245 shutting off the SIIT-DC Gateways. Therefore, by deploying native 246 IPv6 along with SIIT-DC, operators will avoid future migration or 247 deployment projects relating to IPv6 roll-out and/or IPv4 sun- 248 setting. 250 2. Terminology 252 This document makes use of the following terms: 254 IPv4 Service Address A public IPv4 address with which IPv4-only 255 clients will communicate. This communication will be translated 256 to IPv6 by the SIIT-DC Gateway. 258 IPv4 Service Address Pool One or more IPv4 prefixes routed to the 259 SIIT-DC Gateway's IPv4 interface. IPv4 Service Addresses are 260 allocated from this pool. Note that this does not necessarily 261 have to be a "pool" per se, as it could also be one or more host 262 routes (whose prefix length is equal to /32). The primary purpose 263 of using a pool rather than host routes is to facilitate IPv4 264 route aggregation and ease provisioning of new IPv4 Service 265 Addresses. 267 IPv6 Service Address A public IPv6 address assigned to a server or 268 application in the IPv6 network. IPv6-only and dual stacked 269 clients communicates with this address directly without invoking 270 SIIT-DC. IPv4-only clients also communicates with this address 271 through the SIIT-DC Gateway and via an IPv4 Service Address. 273 SIIT-DC Host Agent A logical function very similar to an SIIT-DC 274 Gateway that resides on a server and provides virtual IPv4 275 connectivity to applications, by reversing the translations done 276 by the SIIT-DC Gateway. It is an optional component of the SIIT- 277 DC architecture, that may be used to increase application support. 278 See [I-D.anderson-v6ops-siit-dc-2xlat]. 280 SIIT-DC Gateway A device or a logical function that translates 281 between IPv4 and IPv6 in accordance with Section 5. 283 Static Address Mapping A bi-directional mapping between an IPv4 284 Service Address and an IPv6 Service Address configured in the 285 SIIT-DC Gateway. When translating between IPv4 and IPv6, the 286 SIIT-DC Gateway changes the address fields in the translated 287 packet's IP header according to any matching Static Address 288 Mapping. 290 Translation Prefix An IPv6 prefix into which the entire IPv4 address 291 space is mapped. This prefix is routed to the SIIT-DC Gateway's 292 IPv6 interface. It is either an Network-Specific Prefix or a 293 Well-Known Prefix as specified in [RFC6052]. When translating 294 between IPv4 and IPv6, the SIIT-DC Gateway prepends or strips the 295 Translation Prefix from the address fields in the translated 296 packet's IP header, unless a Static Address Mapping exists for the 297 IP address in question. 299 3. Architectural Overview 301 This section describes the basic SIIT-DC architecture. 303 SIIT-DC Architecture 305 +-------------------+ +----------------+ 306 | IPv6-capable user | | IPv4-only user | 307 | ================= | | ============== | 308 | | | | 309 +-<2001:db8::ab:cd>-+ +-<203.0.113.50>-+ 310 | | 311 (the IPv6 internet) (the IPv4 Internet) 312 | | 313 | +------------------<192.0.2.0/24>-+ 314 | | | 315 | | SIIT-DC Gateway | 316 | | =============== | 317 | | | 318 | | Translation Prefix: | 319 | | 2001:db8:46::/96 | 320 | | | 321 | | Static Address Mapping: | 322 | | 192.0.2.1 <=> 2001:db8:12:34::1 | 323 | | | 324 | +--------------<2001:db8:46::/96>-+ 325 | | 326 (the IPv6-only data centre network) 327 | | 328 | ------------------------------/ 329 |/ 330 | 331 +--<2001:db8:12:34::1>------------------------------+ 332 | | | 333 | | IPv6-only server | 334 | | ================ | 335 | | | 336 | +-[2001:db8:12:34::1]---------------------------+ | 337 | | AF_INET6 | | 338 | | | | 339 | | IPv6-only application | | 340 | | | | 341 | +-----------------------------------------------+ | 342 +---------------------------------------------------+ 344 Figure 1 346 In this example, 192.0.2.0/24 is allocated as an IPv4 Service Address 347 Pool. Individual IPv4 Service Addresses are assigned from this pool. 348 The provider must route this prefix to the SIIT-DC Gateway's IPv4 349 interface. Note that there are no restrictions on how many IPv4 350 Service Address Pools are used or their prefix length, as long as 351 they are all routed to the SIIT-DC Gateway's IPv4 interface. 353 The Static Address Mapping list is used when translating an IPv4 354 Service Address (here 192.0.2.1) to its corresponding IPv6 Service 355 Address (here 2001:db8:12:34::1) and vice versa. When the SIIT-DC 356 Gateway translates an IPv4 packet to IPv6, any IPv4 Service Address 357 found in the original IPv4 header will be replaced with the 358 corresponding IPv6 Service Address in the resulting IPv6 header, and 359 vice versa when translating an IPv6 packet to IPv4. 361 2001:db8:46::/96 is the Translation Prefix into which the entire IPv4 362 address space is mapped. It is used for translation of the end 363 user's IPv4 address to IPv6 and vice versa according to the algorithm 364 defined in Section 2.2 of RFC6052 [RFC6052]. This algorithmic 365 mapping has a lower precedence than the configured Static Address 366 Mappings. 368 The SIIT-DC Gateway itself can be either a separate device or a 369 logical function in another multi-purpose device, for example an IP 370 router. Any number of SIIT-DC Gateways may exist simultaneously in 371 an operators infrastructure, as long as they all have the same 372 translation prefix and list of Static Mappings configured. 374 3.1. DNS Configuration 376 The IPv6 Service Address of should be registered in DNS using an AAAA 377 record, while its corresponding IPv4 Service Address should be 378 registered using an A record. This results in the following DNS 379 records: 381 DNS Configuration for a SIIT-DC enabled service 383 app.domain.tld. IN AAAA 2001:db8:12:34::1 384 app.domain.tld. IN A 192.0.2.1 386 Figure 2 388 3.2. Packet Flow 390 In this example, "IPv4-only user" initiates a request to the 391 application running on the IPv6-only server. He starts by looking up 392 the IN A record of "app.domain.tld" in DNS, and attempts to connect 393 to this address on the service by transmitting the following IPv4 394 packet destined for the IPv4 Service Address: 396 Stage 1: Client -> Server, IPv4 398 +------------------------------------------------+ 399 | IP Version: 4 | 400 | Source Address: 203.0.113.50 | 401 | Destination Address: 192.0.2.1 | 402 | Protocol: TCP | 403 |------------------------------------------------| 404 | TCP SYN [...] | 405 +------------------------------------------------+ 407 Figure 3 409 This packet is then routed over the Internet to the (nearest) SIIT-DC 410 Gateway, which translates it into the following IPv6 packet and 411 forward it into the IPv6 network: 413 Stage 2: Client -> Server request, IPv4 415 +-------------------------------------------------+ 416 | IP Version: 6 | 417 | Source Address: 2001:db8:46::203.0.113.50 | 418 | Destination Address: 2001:db8:12:34::1 | 419 | Next Header: TCP | 420 |-------------------------------------------------| 421 | TCP SYN [...] | 422 +-------------------------------------------------+ 424 Figure 4 426 The destination address field was translated to the IPv6 Service 427 Address according to the configured Static Address Mapping, while the 428 source address was field translated according to the [RFC6052] 429 mapping using the Translation Prefix (because it did not match any 430 Static Address Mapping). The rest of the IP header was translated 431 according to [RFC6145]. The Layer 4 payload is copied verbatim, with 432 the exception of the TCP checksum being recalculated. 434 Note that the IPv6 address 2001:db8:46::203.0.113.50 may also be 435 expressed as 2001:db8:46::cb00:7132, cf. Section 2.2 of RFC2373 436 [RFC2373]. 438 Next, the application receives receives this IPv6 packet and responds 439 to it like it would with any other IPv6 packet: 441 Stage 3: Server -> Client response, IPv6 443 +-------------------------------------------------+ 444 | IP Version: 6 | 445 | Source Address: 2001:db8:12:34::1 | 446 | Destination Address: 2001:db8:46::203.0.113.50 | 447 | Next Header: TCP | 448 |-------------------------------------------------| 449 | TCP SYN+ACK [...] | 450 +-------------------------------------------------+ 452 Figure 5 454 The response packet is routed to the (nearest) SIIT-DC Gateway's IPv6 455 interface, which will translate it back to IPv4 as follows: 457 Stage 4: Server -> Client response, IPv4 459 +------------------------------------------------+ 460 | IP Version: 4 | 461 | Source Address: 192.0.2.2 | 462 | Destination Address: 203.0.113.50 | 463 | Protocol: TCP | 464 |------------------------------------------------| 465 | TCP SYN+ACK [...] | 466 +------------------------------------------------+ 468 Figure 6 470 This time, the source address matched the Static Address Mapping and 471 was translated accordingly, while the destination address did not, 472 and was therefore translated according to [RFC6052] by having the 473 Translation Prefix stripped. The rest of the packet was translated 474 according to [RFC6145]. 476 The resulting IPv4 packet is transmitted back to the end user over 477 the IPv4 Internet. Subsequent packets in the flow will follow the 478 exact same translation pattern. They may or may not cross the same 479 translators as earlier packets in the same flow. 481 The end user's IPv4 stack has no idea that it is communicating with 482 an IPv6 server, nor does the server's IPv6 stack have any idea that 483 is is communicating with an IPv4 client. To them, it's just plain 484 IPv4 or IPv6, respectively. However, the applications running on the 485 server may optionally be updated to recognise and strip the 486 Translation Prefix, so that the end user's IPv4 address may be used 487 for logging, Geo-Location, abuse handling, and so forth. 489 4. Deployment Guidelines 490 In this section, we list recommendations and guidelines for operators 491 who would like to deploy a SIIT-DC service in their data centre 492 network. 494 4.1. Application Support for NAT 496 Not all application protocols are able to operate in a network 497 environment where rewriting of IP addresses occur. An operator 498 should therefore carefully evaluate the applications he would like to 499 make available for IPv4 users through SIIT-DC, to ensure they do not 500 fall in this category. In general, if an application layer protocol 501 works correctly through standard NAT44 (see [RFC3235]), it will most 502 likely work correctly through SIIT-DC as well. 504 Higher-level protocols that embed IP addresses as part of their 505 payload are especially problematic, as noted in [RFC2663], [RFC2993], 506 and [RFC3022]. Such protocols will most likely not work through any 507 form of address translation, including SIIT-DC. One well-known 508 example of such a protocol is FTP [RFC0959]. 510 The SIIT-DC architecture may be extended with a Host Agent that 511 reverses the translation performed by the SIIT-DC Gateway before 512 passing the packets to the application software. This allows the 513 problematic application protocols described above to work correctly 514 in an SIIT-DC environment as well. See 515 [I-D.anderson-v6ops-siit-dc-2xlat] for a description of this 516 extension. 518 4.2. Application Support for IPv6 520 SIIT-DC requires that the application software supports IPv6 521 networking, and that it has no dependency on IPv4 networking. If 522 this is not the case, the approach described in 523 [I-D.anderson-v6ops-siit-dc-2xlat] may be used, as it provides the 524 application with seemingly native IPv4 connectivity. This allows 525 IPv4-only applications to work correctly in an otherwise IPv6-only 526 environment. 528 4.3. Application Communication Pattern 530 SIIT-DC is ideally suited for applications where IPv4-only nodes on 531 the Internet initiate traffic towards the IPv6-only services, which 532 in turn are only passively listening for inbound traffic and 533 responding as necessary. One well-known example of such a protocol 534 is HTTP [RFC2616]. This is due to the fact that in this case, an 535 IPv4 user looks exactly like an ordinary IPv6 user from the host and 536 application's point of view, and requires no special treatment. 538 It is possible to combine SIIT-DC with DNS64 [RFC6147] in order to 539 allow an IPv6-only application to initiate communication with 540 IPv4-only nodes through an SIIT-DC Gateway. However, in this case, 541 care must be taken so that all outgoing communication is sourced from 542 the IPv6 Service Address that has a Static Mapping configured on the 543 SIIT-DC Gateway. If another unmapped address is used, the SIIT-DC 544 Gateway will discard the packet. 546 An alternative approach to the above would be to make use of an SIIT- 547 DC Host Agent as described in [I-D.anderson-v6ops-siit-dc-2xlat]. 548 This provides the application with seemingly native IPv4 549 connectivity, which it may use for both inbound and outbound 550 communication without requiring the application to select a specific 551 source address for its outbound communications. 553 4.4. Choice of Translation Prefix 555 Either a Network-Specific Prefix (NSP) from the provider's own IPv6 556 address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96 557 (WKP) may be used. From a technical point of view, both should work 558 equally well, however as only a single WKP exists, if a provider 559 would like to deploy more than one instance of SIIT-DC in his 560 network, or Stateful NAT64 [RFC6146], an NSP must be used anyway for 561 all but one of those deployments. 563 Furthermore, the WKP cannot be used in inter-domain routing. By 564 using an NSP, a provider will have the possibility to provide SIIT-DC 565 service to other operators across Autonomous System borders. 567 For these reasons, this document recommends that an NSP is used. 568 Section 3.3 of [RFC6052] discusses the choice of translation prefix 569 in more detail. 571 The Translation Prefix may use any of the lengths described in 572 Section 2.2 of RFC6052 [RFC6052], but /96 has two distinct advantages 573 over the others. First, converting it to IPv4 can be done in a 574 single operation by simply stripping off the first 96 bits; second, 575 it allows for IPv4 addresses to be embedded directly into the text 576 representation of an IPv6 address using the familiar dotted quad 577 notation, e.g., "2001:db8::198.51.100.10" (cf. Section 2.4 of RFC6052 578 [RFC6052])), instead of being converted to hexadecimal notation. 579 This makes it easier to write IPv6 ACLs and similar that match 580 translated endpoints in the IPv4 Internet. Use of a /96 prefix 581 length is therefore recommended. 583 4.5. Routing Considerations 584 The prefixes that constitute the IPv4 Service Address Pool and the 585 IPv6 Translation Prefix may be routed to the SIIT-DC Gateway(s) as 586 any other IPv4 or IPv6 route in the provider's network. 588 If more than one SIIT-DC Gateway is being deployed, it is recommended 589 that a dynamic routing protocol (such as BGP, IS-IS, or OSPF) is 590 being used to advertise the routes within the provider's network. 591 This will ensure that the traffic that is to be translated will reach 592 the closest SIIT-DC Gateway, reducing or eliminating sub-optimal 593 traffic patterns, as well as provide high availability - if one SIIT- 594 DC Gateway fails, the dynamic routing protocol will automatically 595 redirect the traffic to the next-best translator. 597 4.6. Location of the SIIT-DC Gateways 599 The goal of SIIT-DC is to facilitate a true IPv6-only application and 600 network architecture, with the sole exception being the IPv4 601 interfaces of the SIIT-DC Gateways and the network infrastructure 602 required to connect them to the IPv4 Internet. Therefore, the SIIT- 603 DC Gateways should be located somewhere beween the IPv4 Internet and 604 the application delivery stack. This should be understood to include 605 all servers, load balancers, firewalls, intrusion detection systems, 606 and similar devices that are processing traffic to a greater extent 607 than merely forwarding it. 609 It is optimal to place the SIIT-DC Gateways as close as possible to 610 the direct path between the servers and the end users. If the 611 closest translator is located a long way from the optimal path, all 612 packets in both directions must make a detour. This would increase 613 the RTT between the server and the end user by by two times the extra 614 latency incurred by the detour, as well as cause unnecessary load on 615 the network links on the detour path. 617 Where possible, it is beneficial to implement the SIIT-DC Gateways as 618 a logical function within the routers would have handled the traffic 619 anyway, had the topology been dual stacked. This way, the 620 translation service would not need to be assigned separate networks 621 ports (which might become saturated and impact the service quality), 622 nor would it require extra rack space and energy. Some particularly 623 good choices of the location could be within a data centre's access 624 routers, or within the provider's border routers. When every single 625 application in the data centre or the provider's network eventually 626 runs on single-stack IPv6, there would no need to run IPv4 on the 627 inside of the SIIT-DC Gateway. This reduces complexity, and allows 628 the operator to reclaim IPv4 addresses from the network 629 infrastructure that may instead be used as IPv4 Service Address 630 Pools. 632 Finally, another possibility is that the data centre operator 633 outsources the SIIT-DC service to another entity, for example his 634 upstream ISP. Doing so allows the data centre operator to build a 635 true IPv6-only infrastructure. However, in this case, care must be 636 taken to ensure that the path between the data centre and the SIIT-DC 637 operator has a stable and known MTU, and that the SIIT-DC Gateways 638 are not too far away from the data centre (otherwise, translated 639 traffic could incur a latency penalty). 641 4.7. Migration from Dual Stack 643 While this document discusses the use of IPv6-only servers and 644 applications, there is no technical requirement that the servers are 645 IPv4 free. SIIT-DC works equally well for dual stacked servers, 646 which makes migration easy - after setting up the translation 647 function, the DNS A record for the service is updated to point to the 648 IPv4 address that will be translated to IPv6, the previously used 649 IPv4 service address may continue to be assigned to the server. This 650 makes roll-back to dual stack easy, as it is only a matter of 651 changing the DNS record back to what it was before. 653 For high-volume services migrating to SIIT-DC from dual stack, DNS 654 Round Robin may be used to gradually migrate the service's IPv4 655 traffic from its native IPv4 address(es) to the translated IPv4 656 Service Address(s). 658 4.8. Packet Size and Fragmentation Considerations 660 There are some key differences between IPv4 and IPv6 relating to 661 packet sizes and fragmentation that one should consider when 662 deploying SIIT-DC. They result in a few problematic corner cases, 663 which can be dealt with in a few different ways. The following 664 subsections will discuss these in detail, and provide operational 665 guidance. 667 In particular, the operator may find that relying on fragmentation in 668 the IPv6 domain is undesired or even operationally impossible 669 [I-D.taylor-v6ops-fragdrop]. For this reason, the recommendations in 670 this section seeks to minimise the use of IPv6 fragmentation. 672 Unless otherwise stated, the following subsections assume that the 673 MTU in both the IPv4 and IPv6 domains is 1500 bytes. 675 4.8.1. IPv4/IPv6 Header Size Difference 677 The IPv6 header is up to 20 bytes larger than the IPv4 header. This 678 means that a full-size 1500 bytes large IPv4 packet cannot be 679 translated to IPv6 without being fragmented, otherwise it would 680 likely have resulted in a 1520 bytes large IPv6 packet. 682 If the transport protocol used is TCP, this is generally not a 683 problem, as the IPv6 server will advertise a TCP MSS of 1440 bytes. 684 This causes the client to never send larger packets than what can be 685 translated to a single full-size IPv6 packet, eliminating any need 686 for fragmentation. 688 For other transport protocols, full-size IPv4 packets with the DF 689 flag cleared will need to be fragmented by the SIIT-DC Gateway. The 690 only way to avoid this is to increase the Path MTU between the SIIT- 691 DC Gateway and the servers to 1520 bytes. Note that the servers' MTU 692 SHOULD NOT be increased accordingly, as that would cause them to 693 undergo Path MTU Discovery for most native IPv6 destinations. 694 However, the servers would need to be able to accept and process 695 incoming packets larger than their own MTU. If the server's IPv6 696 implementation allows the MTU to be set differently for specific 697 destinations, it could be increased to 1520 for destinations within 698 the Translation Prefix specifically. 700 4.8.2. IPv6 Atomic Fragments 702 In keeping with the fifth paragraph of Section 4 of RFC6145 703 [RFC6145], an SIIT-DC Gateway will by default add an IPv6 704 Fragmentation header to the resulting IPv6 packet when translating an 705 IPv4 packet with the Don't Fragment flag set to 0. 707 This happens even though the resulting IPv6 packet isn't actually 708 fragmented into several pieces, resulting in an IPv6 Atomic Fragment 709 [RFC6946]. These Atomic Fragments are generally not useful in a data 710 centre environment, and it is therefore recommended that this 711 behaviour is disabled in the SIIT-DC Gateways. To this end, 712 Section 4 of RFC6145 [RFC6145] notes that the "translator MAY provide 713 a configuration function that allows the translator not to include 714 the Fragment Header for the non-fragmented IPv6 packets". 716 Note that [I-D.gont-6man-deprecate-atomfrag-generation] seeks to 717 update [RFC6145], making the functionality described above as the 718 standard and only mode of operation. 720 4.8.3. Minimum Path MTU Difference Between IPv4 and IPv6 721 Section 5 of RFC2460 [RFC2460] specifies that the minimum IPv6 link 722 MTU is 1280 bytes. Therefore, an IPv6 node can reasonably assume 723 that if it transmits an IPv6 packet that is 1280 bytes or smaller, it 724 is guaranteed to reach its destination without requiring 725 fragmentation or invoking the Path MTU Discovery algorithm [RFC1981]. 726 However, this assumption fails if the destination is an IPv4 node 727 reached through a protocol translator such as an SIIT-DC Gateway, as 728 the minimum IPv4 link MTU is 68 bytes. See Section 3.2 of RFC791 729 [RFC0791]. 731 Section 5.1 of RFC6145 [RFC6145] specifies that an SIIT-DC Gateway 732 should set the IPv4 Don't Fragment flag to 1 when it translates an 733 unfragmented IPv6 packet to IPv4. This means that when the path to 734 the destination IPv4 node contains an IPv4 link with an MTU smaller 735 than 1260 bytes (which corresponds to an IPv6 MTU smaller than 1280 736 bytes, cf. Section 4.8.1), the Path MTU Discovery algorithm will be 737 invoked, even if the original IPv6 packet was only 1280 bytes large. 738 This happens as a result of the IPv4 router connecting to the IPv4 739 link with the small MTU returning an ICMPv4 Need To Fragment error 740 with an MTU value smaller than 1260, which in turns is translated by 741 the SIIT-DC Gateway to an ICMPv6 Packet Too Big error with an MTU 742 value smaller than 1280 which is then transmitted to the origin IPv6 743 node. 745 When an IPv6 node receives an ICMPv6 Packet Too Big error indicating 746 an MTU value smaller than 1280, the last paragraph of Section 5 of 747 RFC2460 [RFC2460] gives it two choices on how to proceed: 749 o It may reduce its Path MTU value to the value indicated in the 750 Packet Too Big, i.e., limit the size of subsequent packets 751 transmitted to that destination to the indicated value. This 752 approach causes no problems for the SIIT-DC function, as it simply 753 allows Path MTU Discovery to work transparently across the SIIT-DC 754 Gateway. 756 o It may reduce its Path MTU value to exactly 1280, and in addition 757 include a Fragmentation header in subsequent packets sent to that 758 destination. In other words, the IPv6 node will start emitting 759 Atomic Fragments. The Fragmentation header signals to the the 760 SIIT-DC Gateway that the Don't Fragment flag should be set to 0 in 761 the resulting IPv4 packet, and it also provides the Identification 762 value. 764 If the use of the IPv6 Fragmentation header is problematic, and the 765 operator has IPv6 nodes that implement the second option above, the 766 operator should consider enabling the functionality described as the 767 "second approach" in Section 6 of RFC6145 [RFC6145]. This 768 functionality changes the SIIT-DC Gateway's behaviour as follows: 770 o When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big, 771 the resulting packet will never contain an MTU value lower than 772 1280. This prevents the IPv6 nodes from generating Atomic 773 Fragments. 775 o When translating IPv6 packets smaller than or equal to 1280 bytes, 776 the Don't Fragment flag in the resulting IPv4 packet will be set 777 to 0. This ensures that in the eventuality that the path contains 778 an IPv4 link with an MTU smaller than 1260, the IPv4 router 779 connected to that link will have the responsibility to fragment 780 the packet before forwarding it towards its destination. 782 In summary, this approach could be seen as prompting the IPv4 783 protocol itself to provide the "link-specific fragmentation and 784 reassembly at a layer below IPv6" required for links that "cannot 785 convey a 1280-octet packet in one piece", to paraphrase Section 5 of 786 RFC2460 [RFC2460]. Note that 787 [I-D.gont-6man-deprecate-atomfrag-generation] seeks to update 788 [RFC6145], making the approach described above as the standard and 789 only mode of operation. 791 5. Implementation Requirements 793 This normative section specifies the SIIT-DC protocol that is 794 implemented by an SIIT-DC Gateway. Because SIIT-DC builds on and 795 closely resembles SIIT [RFC6145], this section should be read as a 796 set of additions and changes that are applied to an implementation 797 already compliant to SIIT [RFC6145]. Each of the following 798 subsections discuss how the requirement relates to with any 799 corresponding requirements in SIIT [RFC6145]. 801 5.1. Compliance with RFC6145 and RFC6052 803 Unless otherwise stated in the following sections, an SIIT-DC 804 implementation MUST comply fully with [RFC6145]. It must also 805 implement the algorithmic address mapping defined in [RFC6052]. 807 5.2. Static Address Mapping Function 809 The implementation MUST allow the operator to configure an arbitrary 810 number of Static Address Mappings which override the default 811 [RFC6052] algorithm. It SHOULD be possible to specify a single bi- 812 directional mapping that will be used in both the IPv4=>IPv6 and 813 IPv6=>IPv4 directions, but it MAY additionally (or alternatively) 814 support unidirectional mappings. 816 An example of such a bidirectional Static Address Mapping would be: 818 o 192.0.2.1 <=> 2001:db8:12:34::1 820 To accomplish the same using unidirectional mappings, the following 821 two mappings must instead be configured: 823 o 192.0.2.1 => 2001:db8:12:34::1 825 o 2001:db8:12:34::1 => 192.0.2.1 827 In both cases, if the SIIT-DC Gateway receives an IPv6 packet that 828 has the value 2001:db8:12:34::1 in either the source or destination 829 field of the IPv6 header, it MUST rewrite this field to 192 0.2.1 830 when translating to IPv4. Similarly, if the SIIT-DC Gateway receives 831 an IPv4 packet that has the value 192.0.2.1 as the either the source 832 or destination field of the IPv4 header, it MUST rewrite this field 833 to 2001:db8:12:34::1 when translating to IPv6. For all IPv4 or IPv6 834 source or destination field values for which there are no matching 835 Static Address Mapping, [RFC6052] compliant mapping MUST be used 836 instead. 838 Relation to [RFC6145]: The Static Address Mapping is a novel feature 839 feature that is not discussed in [RFC6145]. It conflicts with 840 [RFC6145]'s requirement that all addresses must be translated 841 according to the [RFC6052] algorithm. 843 5.3. Support for Increasing the IPv6 Path MTU 845 The SIIT-DC Gateway MUST provide a configuration function for the 846 network administrator to adjust the threshold of the minimum IPv6 MTU 847 to a value that reflects the real value of the minimum IPv6 MTU in 848 the network (greater than 1280 bytes). This will help reduce the 849 chance of including the Fragment Header in the resulting IPv6 850 packets. 852 Relation to [RFC6145]: This strengthens the corresponding "MAY" 853 requirement located in Section 4 of RFC6145 [RFC6145] to a "MUST". 855 5.4. Loop Prevention Mechanism 857 As noted in Section 9.2, there is a potential for packets looping 858 through the SIIT-DC function if it receives an IPv4 packet for which 859 there is no Static Address Mapping. It is therefore RECOMMENDED that 860 the implementation has a mechanism that automatically prevents this 861 behaviour. One way this could be accomplished would be to discard 862 any IPv4 packets that would be translated into an IPv6 packet that 863 would be routed straight back into the SIIT-DC function. 865 If such a mechanism isn't provided, the implementation MUST provide a 866 way to manually filter or null-route the destination addresses that 867 would otherwise cause loops. 869 Relation to [RFC6145]: This security consideration applies only when 870 an SIIT-DC Gateway translates a packet in "pure" SIIT [RFC6145] mode 871 (i.e., when both address fields are translated according to 872 [RFC6052]). This consideration is in other words not specific to 873 SIIT-DC, it is inherited from [RFC6145]. In spite of this, [RFC6145] 874 does not describe this consideration or any methods of prevention. 875 The requirements in this section is therefore novel to SIIT-DC, even 876 though they apply equally to [RFC6145]. 878 6. Acknowledgements 880 The author would like to thank the following individuals for their 881 contributions, suggestions, corrections, and criticisms: Fred Baker, 882 Cameron Byrne, Brian E Carpenter, Ross Chandler, Dagfinn Ilmari 883 Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed. 885 7. Requirements Language 887 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 888 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 889 document are to be interpreted as described in [RFC2119]. 891 8. IANA Considerations 893 This draft makes no request of the IANA. The RFC Editor may remove 894 this section prior to publication. 896 9. Security Considerations 898 9.1. Mistaking the Translation Prefix for a Trusted Network 900 If a Network-Specific Prefix from the provider's own address space is 901 chosen for the translation prefix, as is recommended, care must be 902 taken if the translation service is used in front of services that 903 have application-level ACLs that distinguish between the operator's 904 own networks and the Internet at large, as the translated IPv4 end 905 users on the Internet will appear to be located within the provider's 906 own IPv6 address space. It is therefore important that the 907 translation prefix is treated the same as the Internet at large, 908 rather than as a trusted network. 910 9.2. Packets Looping Through the SIIT-DC Function 911 If the SIIT-DC Gateway receives an IPv4 packet destined to an address 912 for which there is no Static Address Mapping, its destination address 913 will be rewritten according to [RFC6052], making the resulting IPv6 914 packet have a destination address within the translation prefix, 915 which is likely routed to back to the SIIT-DC function. This will 916 cause the packet to loop until its Time To Live / Hop Limit reaches 917 zero, potentially creating a Denial Of Service vulnerability. 919 To avoid this, it should be ensured that packets sent to IPv4 920 destinations addresses for which there are no Static Address 921 Mappings, or whose resulting IPv6 address does not have a more- 922 specific route to the IPv6 network, are immediately discarded. 924 10. References 926 10.1. Normative References 928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 929 Requirement Levels", BCP 14, RFC 2119, March 1997. 931 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 932 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 933 October 2010. 935 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 936 Algorithm", RFC 6145, April 2011. 938 10.2. Informative References 940 [I-D.anderson-v6ops-siit-dc-2xlat] 941 tore, t., "SIIT-DC: Dual Translation Mode", draft- 942 anderson-v6ops-siit-dc-2xlat-00 (work in progress), 943 September 2014. 945 [I-D.gont-6man-deprecate-atomfrag-generation] 946 Gont, F., Will, W., and t. tore, "Deprecating the 947 Generation of IPv6 Atomic Fragments", draft-gont-6man- 948 deprecate-atomfrag-generation-01 (work in progress), 949 August 2014. 951 [I-D.taylor-v6ops-fragdrop] 952 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 953 M., and T. Taylor, "Why Operators Filter Fragments and 954 What It Implies", draft-taylor-v6ops-fragdrop-02 (work in 955 progress), December 2013. 957 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 958 1981. 960 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 961 9, RFC 959, October 1985. 963 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 964 E. Lear, "Address Allocation for Private Internets", BCP 965 5, RFC 1918, February 1996. 967 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 968 for IP version 6", RFC 1981, August 1996. 970 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 971 Architecture", RFC 2373, July 1998. 973 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 974 (IPv6) Specification", RFC 2460, December 1998. 976 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 977 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 978 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 980 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 981 Translator (NAT) Terminology and Considerations", RFC 982 2663, August 1999. 984 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 985 Multicast Next-Hop Selection", RFC 2991, November 2000. 987 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 988 November 2000. 990 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 991 Address Translator (Traditional NAT)", RFC 3022, January 992 2001. 994 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 995 Application Design Guidelines", RFC 3235, January 2002. 997 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 998 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1000 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 1001 October 2005. 1003 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1004 NAT64: Network Address and Protocol Translation from IPv6 1005 Clients to IPv4 Servers", RFC 6146, April 2011. 1007 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1008 Beijnum, "DNS64: DNS Extensions for Network Address 1009 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1010 April 2011. 1012 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1013 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1014 RFC 6540, April 2012. 1016 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 1017 6946, May 2013. 1019 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 1020 Deployment Options and Experience", RFC 7269, June 2014. 1022 Appendix A. Complete SIIT-DC topology example 1024 This figure shows a more complete SIIT-DC topology, in order to 1025 better demonstrate the beneficial properties it has. In particular, 1026 it tries to highlight the following: 1028 o Stateless operation: Any number of SIIT-DC Gateways may be 1029 deployed side-by side, or indeed anywhere in the IPv6 network, as 1030 any standard routing mechanism may be used to direct traffic to 1031 them (shown here with BGP on the IPv4 side and ECMP on the IPv6 1032 side). This in turn leads to high availability, should one of the 1033 SIIT-DC Gateways fail or become unavailable, those standard 1034 routing mechanisms will ensure that traffic is automatically 1035 redirect one of the remaining SIIT-DC Gateways. 1037 o IPv4 address conservation: Even though the to customers in the 1038 example have several hundred servers, most of them are not used 1039 for externally available services, and thus do not require an IPv4 1040 address. The network between the servers and the SIIT-DC Gateways 1041 require no IPv4 addresses, either. Furthermore, the IPv4 1042 addresses that are used do not have to be assigned to customers in 1043 the form of aggregated blocks or prefixes; which makes it easy to 1044 achieve 100% effective utilisation of the IPv4 service address 1045 pools. 1047 o Application support: The translation-friendly applications HTTP 1048 and SMTP will work through SIIT-DC without requiring any special 1049 customisation. Furthermore, translation-unfriendly applications 1050 such as FTP will also work if an host agent in present, cf. 1051 [I-D.anderson-v6ops-siit-dc-2xlat]. 1053 o Native IPv6 as the foundation: Every server, application, and 1054 network component has access to native and untranslated IPv6 1055 connectivity to each other and to the Internet. Traffic through 1056 the SIIT-DC Gateways will diminish over time as IPv6 is deployed 1057 throughout the Internet. Eventually they may be shut down 1058 entirely, which causes no disruption to the application stacks' 1059 ability to deliver their services over native IPv6. 1061 Example data centre topology using SIIT-DC 1062 /--------------------------------\ /---------------\ 1063 | IPv4 Internet | | IPv6 Internet | 1064 \-+----------------------------+-/ \--------+------/ 1065 | | | 1066 | <----------[BGP]---------> | | 1067 | | | 1068 +---------<192.0.2.0/24>----------+ +---<192.0.2.0/24>---+ | 1069 | | | | | 1070 | SIIT-DC Gateway 1 | | SIIT-DC Gateway 2 | | 1071 | ================= | | ================= | | 1072 | | | | | 1073 | Translation Prefix: | | | | 1074 | 2001:db8:46::/96 | | | | 1075 | | | | | 1076 | Static Address Mappings: | | Exactly the same | | 1077 | 192.0.2.1 <=> 2001:db8:12:34::1 | | configuration as | | 1078 | 192.0.2.2 <=> 2001:db8:12:34::2 | | SIIT-DC Gateway 1 | | 1079 | 192.0.2.3 <=> 2001:db8:fe:dc::1 | | | | 1080 | 192.0.2.4 <=> 2001:db8:12:34::4 | | | | 1081 | [...] | | | | 1082 | | | | | 1083 +--------<2001:db8:46::/96>-------+ +-<2001:db8:46::/96>-+ | 1084 | | | 1085 | <---------[ECMP]---------> | | 1086 | | | 1087 /-----------------+----------------------------+-\ | 1088 | IPv6 data centre network +----------+ 1089 \-+-----------------------------------+----------/ 1090 | | 1091 | Customer A's server LAN | Customer B's server LAN 1092 | 2001:db8:12:34::/64 | 2001:db8:fe:dc::/64 1093 | | 1094 | | 1095 +-- www ::1 (IPv6+SIIT-DC) +-- www ::1 (IPv6+SIIT-DC) 1096 | | 1097 | +-- file01 ::f:01 (IPv6) 1098 +-- mta ::2 (IPv6+SIIT-DC) | [...] 1099 | +-- file99 ::f:99 (IPv6) 1100 +-- ftp ::3 (IPv6) 1101 | ::4 (SIIT-DC/Host Agent) 1102 | 1103 +-- app01 ::a:01 (IPv6) 1104 | [...] 1105 +- app99 ::a:99 (IPv6) 1106 | 1107 +-- db01 ::d:01 (IPv6) 1108 | [..] 1109 +-- db99 ::d:99 (IPv6) 1110 Figure 7 1112 Appendix B. Comparison to Other Deployment Approaches 1114 There are a number of alternative deployment strategies a data centre 1115 operator may follow. They each have different properties and helps 1116 solve a different set of challenges. This section aims to compare 1117 the SIIT-DC approach with each of the most common ones, by 1118 highlighting the benefits and disadvantages of each. 1120 B.1. IPv4-only 1122 At the time of writing, IPv4-only operation remains the status quo 1123 for most operators. As such, it is well understood and supported. 1124 An operator can reasonably expect everything to work correctly in an 1125 IPv4-only environment. 1127 Benefits of IPv4-only operation compared to SIIT-DC include: 1129 o No translation occurs, the end-to-end principle is intact. 1131 o Compatible with all common application protocols. 1133 o Compatible with IPv4-only devices. 1135 o Compatible with IPv4-only application software, without requiring 1136 a host agent. 1138 Disadvantages of IPv4-only operation compared to SIIT-DC include: 1140 o Does not provide any form of IPv6 connectivity. 1142 o Does not alleviate IPv4 address scarcity. 1144 B.2. IPv4-only + NAPT44 1146 An operator who would otherwise chose a traditional IPv4-only 1147 approach, but cannot due to having insufficient public IPv4 addresses 1148 available, could chose to deploy using a combination of private IPv4 1149 addresses [RFC1918] and NAPT44 [RFC3022] devices which will translate 1150 between a smaller number of public IPv4 addresses and the private 1151 addresses assigned to the servers that provide public services to the 1152 Internet. 1154 Benefits of IPv4-only + NAPT44 operation compared to SIIT-DC include: 1156 o Compatible with IPv4-only devices. 1158 o Compatible with IPv4-only application software, without requiring 1159 a host agent. 1161 Disadvantages of IPv4-only + NAPT44 operation compared to SIIT-DC 1162 include: 1164 o Does not provide any form of IPv6 availability. 1166 o Requires network devices that track all flow state, which may 1167 create a performance bottleneck and be an easy target for Denial 1168 of Service attacks. 1170 o Limits routing flexibility (prevents closest exit routing), as 1171 outbound traffic must pass across the same NAPT44 device that 1172 handled the inbound traffic. 1174 o Limited potential for horizontal scaling, as packets cannot be 1175 load-balanced across multiple NAT devices. 1177 o Depending on whether or not the NAPT44 device rewrites source 1178 addresses in order to attract the return traffic to itself: 1180 o 1182 * Obscures the true source address of the user from the server/ 1183 application, preventing it from e.g. performing geo-location 1184 lookups, or: 1186 * Requires an IPv4 default route to be pointed to the NAPT44 1187 device, also attracting native traffic that does not need to 1188 undergo translation. 1190 In addition, application compatibility is a consideration with both 1191 NAPT44 and SIIT-DC, but the exact nature depends from application to 1192 application, so it is hard to objectively quantify if there is a 1193 clear advantage to either approach here. Some translation-unfriendly 1194 application protocols may work without host modifications through the 1195 use of Application Layer Gateway support in the NAPT44 device (e.g., 1196 FTP [RFC0959]), or in the SIIT-DC architecture when a host agent is 1197 being used [I-D.anderson-v6ops-siit-dc-2xlat]. Other application 1198 protocols might not work with NAPT44 at all, but will work in the 1199 SIIT-DC if a host agent is being used (e.g., FTP/TLS [RFC4217]). 1201 In summary, the most accurate statement would be to say that an 1202 NAPT44 architecture is more compatible with translation-unfriendly 1203 protocols than plain SIIT-DC, while SIIT-DC is more compatible than 1204 NAPT44 if a host agent is used. 1206 For a more complete discussion of potential issues with running 1207 NAPT44, see Architectural Implications of NAT [RFC2993]. 1209 B.3. IPv4-only + NAT64 1211 An operator who would otherwise chose a traditional IPv4-only 1212 approach, but would in addition like to provide service availability 1213 for IPv6 end users, could use Stateful NAT64 [RFC6146] to accomplish 1214 this. In a sense, this would be the mirror image of an SIIT-DC 1215 architecture: The infrastructure and servers remains single-stacked, 1216 while connectivity to the other IP stack is provided through a 1217 translation system. Further information about operating Stateful 1218 NAT64 is found in [RFC7269]. 1220 Note that Stateful NAT64 can be deployed with or without NAPT44. 1221 With the exception that IPv6 service availability is being provided, 1222 the discussion in the previous two sections fully applies to an 1223 IPv4-only environment that includes NAT64. 1225 Benefits of IPv4-only + NAT64 operation compared to SIIT-DC include: 1227 o Compatible with IPv4-only devices. 1229 o Compatible with IPv4-only application software, without requiring 1230 a host agent. 1232 Disadvantages of IPv4-only + NAT64 operation compared to SIIT-DC 1233 include: 1235 o Does not alleviate IPv4 address scarcity (assuming NAPT44 isn't 1236 used). 1238 o Requires network devices that track all flow state, which may 1239 create a performance bottleneck and be an easy target for Denial 1240 of Service attacks. 1242 o Limits routing flexibility (prevents closest exit routing), as 1243 outbound traffic must pass across the same NAT64 device that 1244 handled the inbound traffic. 1246 o Limited potential for horizontal scaling, as packets cannot be 1247 load-balanced across multiple NAT devices. 1249 o Obscures the true source address of the user from the server/ 1250 application, preventing it from e.g. performing geo-location 1251 lookups. 1253 o The traffic levels on the Stateful NAT64 routers will increase 1254 over time, in lockstep with the increased deployment of IPv6 in 1255 the Internet. For this reason, Section 3.2 of RFC7269 [RFC7269] 1256 notes that the use of Stateful NAT64 in a data centre environment 1257 "is only reasonable at an early stage". With SIIT-DC, the inverse 1258 is true; the traffic levels on the SIIT-DC Gateways will decrease 1259 over time, as end users will prefer to use native IPv6 once it is 1260 available to them. 1262 B.4. Dual Stack 1264 Dual Stack [RFC4213] could be used both with or without NAPT44 to 1265 handle IPv4. In general, the benefits and disadvantages are equal to 1266 the corresponding IPv4-only option, except for the fact that Dual 1267 Stack does provides IPv6 connectivity. Therefore, his section only 1268 lists the benefits and disadvantages which are unique to a Dual Stack 1269 environment. 1271 Benefits of Dual Stack operation compared to SIIT-DC include: 1273 o No translation occurring, the end-to-end principle is intact 1274 (assuming NAPT44 isn't used). 1276 o Compatible with all common application protocols (assuming NAPT44 1277 isn't used). 1279 o Compatible with IPv4-only devices. 1281 o Compatible with IPv4-only application software, without requiring 1282 a host agent. 1284 Disadvantages of Dual Stack operation compared to SIIT-DC include: 1286 o Does not alleviate IPv4 address scarcity (assuming NAPT44 isn't 1287 used). 1289 o Increases the complexity of the infrastructure, as many things 1290 must done twice (once for IPv4 and once for IPv6). Examples of 1291 things that must be duplicated in this manner under Dual Stack 1292 include: Firewall rules/ACLs, IGP topology, monitoring, 1293 troubleshooting. 1295 o Encourages software developers, systems administrators, etc. to 1296 build architectures that cannot operate correctly without IPv4. 1297 This in turn makes it difficult to make use of Dual Stack as a 1298 short term transitional stage, rather than a near-permanent end 1299 state. 1301 o Increases the amount of things that can encounter failures, and 1302 increases the time required to locate and fix such failures. This 1303 reduces reliability. 1305 Author's Address 1307 Tore Anderson 1308 Redpill Linpro 1309 Vitaminveien 1A 1310 0485 Oslo 1311 NORWAY 1313 Phone: +47 959 31 212 1314 Email: tore@redpill-linpro.com