idnits 2.17.1 draft-ietf-v6ops-siit-dc-00.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 : ---------------------------------------------------------------------------- == 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 (December 18, 2014) is 3417 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) == Outdated reference: A later version (-08) exists of draft-ietf-6man-deprecate-atomfrag-generation-00 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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 December 18, 2014 5 Expires: June 21, 2015 7 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments 8 draft-ietf-v6ops-siit-dc-00 10 Abstract 12 This document describes SIIT-DC, an extension to the Stateless IP/ 13 ICMP Translation (SIIT) algorithm, that makes it ideally suited for 14 use in IPv6 data centre environments. SIIT-DC simultaneously 15 facilitates IPv6 deployment and IPv4 address conservation. The 16 overall SIIT-DC architecture is described, as well as guidelines for 17 operators. Finally, the normative implementation requirements are 18 described, as a list of additions and changes to SIIT. 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 June 21, 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 . . . . . . . . . . . . . . 5 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 . . 17 78 5. Implementation Requirements . . . . . . . . . . . . . . . . . 18 79 5.1. Compliance with RFC6145 and RFC6052 . . . . . . . . . . . 18 80 5.2. Static Address Mapping Function . . . . . . . . . . . . . 19 81 5.3. Support for Increasing the IPv6 Path MTU . . . . . . . . 19 82 5.4. Loop Prevention Mechanism . . . . . . . . . . . . . . . . 20 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 . 21 88 9.2. Packets Looping Through the SIIT-DC Function . . . . . . 21 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 B.5. Partial Dual Stack (IPv6-only back-end) . . . . . . . . . 30 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 101 1. Introduction 103 SIIT-DC is an extension of SIIT [RFC6145] that provides a network- 104 centric stateless translation service that allows a data centre 105 operator or Internet Content Provider (ICP) to run a data centre 106 network, servers, and applications using exclusively IPv6, while at 107 the same time ensuring that end users that have only IPv4 108 connectivity will be able to continue to access the services and 109 applications. 111 1.1. Motivation and Goals 113 Historically, dual stack [RFC4213] [RFC6883] has been the recommended 114 way to transition from an IPv4-only environment to one capable of 115 serving IPv6 users. However, for data centre operators and Internet 116 content providers, dual stack operation has a number of disadvantages 117 compared to single stack operation. In particular, running two 118 protocols rather than one results in increased complexity and 119 operational overhead, with a very low expected return on investment 120 in the short to medium term while few end-users only have 121 connectivity to the IPv6 Internet. Furthermore, the dual stack 122 approach does not in any way help with the depletion of the IPv4 123 address space. 125 Therefore, some operators may prefer an approach in which they only 126 need to operate one protocol in the data centre as they prepare for 127 the future. The design goals are: 129 o Promote the deployment of native IPv6 services (cf. [RFC6540]). 131 o Provide IPv4 service availability for legacy users with no loss of 132 performance or functionality. 134 o To ensure that that the legacy users' IPv4 addresses remain 135 available to the servers and applications. 137 o To conserve and maximise the utilisation of IPv4 addresses. 139 o To avoid introducing more complexity than absolutely necessary, 140 especially on the servers and applications. 142 o To be easy to scale and deploy in a fault-tolerant manner. 144 The following subsections elaborates on how SIIT-DC meets these 145 goals. 147 1.1.1. Single Stack IPv6 Operation 149 SIIT-DC allows an operator to build their applications on an 150 IPv6-only foundation. IPv4 end-user connectivity becomes a service 151 provided by the network, which systems administration and application 152 development staff do not need to concern themselves with. 154 Obviously, this will promote universal IPv6 deployment for all of the 155 provider's services and applications. 157 It is worth noting that SIIT-DC requires no special support or change 158 from the underlying IPv6 infrastructure, it will work with any kind 159 of IPv6 network. Traffic between IPv6-enabled end users and 160 IPv6-enabled services will always be native, and SIIT-DC will not be 161 involved in it at all. 163 1.1.2. Stateless Operation 165 Unlike other solutions that provide either dual stack availability to 166 single-stack services (e.g., Stateful NAT64 [RFC6146] and Layer-4/7 167 proxies), or that provide conservation of IPv4 addresses (e.g., 168 NAPT44 [RFC3022]), a SIIT-DC Gateway does not keep any state between 169 each packet in a single connection or flow. In this sense it 170 operates exactly like a normal IP router, and has similar scaling 171 properties - the limiting factors are packets per second and 172 bandwidth. The number of concurrent flows and flow initiation rates 173 are irrelevant for performance. 175 This not only allows individual SIIT-DC Gateways to easily attain 176 "line rate" performance, it also allows for per-packet load balancing 177 between multiple SIIT-DC Gateways using Equal-Cost Multipath Routing 178 [RFC2991]. Asymmetric routing is also acceptable, which makes it 179 easy to avoid sub-optimal traffic patterns; the prefixes involved may 180 be anycasted from all the SIIT-DC Gateways in the provider's network, 181 thus ensuring that the most optimal path through the network is used, 182 even where the optimal path in one direction differs from the optimal 183 path in the opposite direction. 185 Finally, stateless operation means that high availability is easily 186 achieved. If an SIIT-DC Gateway should fail, its traffic can be re- 187 routed onto another SIIT-DC Gateway using a standard IP routing 188 protocol. This does not impact existing flows any more than what any 189 other IP re-routing event would. 191 1.1.3. IPv4 Address Conservation 193 In most parts of the world, it is difficult or even impossible to 194 obtain generously sized IPv4 allocations from the Regional Internet 195 Registries. The resulting scarcity in turn impacts individual end 196 users and operators, which might be forced to purchase IPv4 addresses 197 from other operators in order to cover their needs. This process can 198 be risky to business continuity, in the case no suitable block for 199 sale can be located, and/or turn out to be prohibitively expensive. 200 Even so, a data centre operator will find that providing IPv4 service 201 is essential, as a large share of the Internet users still does not 202 have IPv6 connectivity. 204 A key goal of SIIT-DC is to help reduce a data centre operator's IPv4 205 address requirement to the absolute minimum, by allowing the operator 206 to remove them entirely from components that do not need to 207 communicate with endpoints in the IPv4 Internet. One example would 208 be servers that are operating in a supporting/back-end role and only 209 communicates with to other servers (database servers, file servers, 210 and so on). Another example would be the network infrastructure 211 itself (router-to-router links, loopback addresses, and so on). 212 Furthermore, as LAN prefix sizes must always be rounded up to the 213 nearest power of two (or larger, if one reserves space for future 214 growth), even more IPv4 addresses will often end up being wasted 215 without even being used. 217 With SIIT-DC, the operator can remove these valuable IPv4 addresses 218 from his back-end servers and network infrastructure, and reassign 219 them to the SIIT-DC service as IPv4 Service Addresses. There is no 220 requirement that IPv4 Service Addresses are assigned in an aggregated 221 manner, so there is nothing lost due to infrastructure overhead; 222 every single IPv4 address assigned to SIIT-DC can be used an IPv4 223 Service Address. 225 1.1.4. No Loss of End User's IPv4 Source Address 227 SIIT-DC will map the entire end-user's IPv4 source address into an 228 predefined IPv6 translation prefix. This ensures that there is no 229 loss of information; the end-user's IPv4 source address remains 230 available to the server/application, allowing it to perform tasks 231 like Geo-Location, logging, abuse handling, and so forth. 233 1.1.5. Compatible with Standard IPv6 Implementations 235 Except for the introduction of the SIIT-DC Gateways themselves, no 236 change to the network, servers, applications, or anything else is 237 required in order to support SIIT-DC. SIIT-DC is practically 238 invisible from the point of view of the the IPv4 clients, the IPv6 239 servers, the IPv6 data centre network, and the IPv4 Internet. SIIT- 240 DC interoperates with all standards-compliant IPv4 or IPv6 stacks. 242 1.1.6. No Architectural Dependency on IPv4 244 SIIT-DC will allow an ICP or data centre operator to build 245 infrastructure and applications entirely on IPv6. This means that 246 when the day comes to discontinue support for IPv4, no change needs 247 to be made to the overall architecture - it's only a matter of 248 shutting off the SIIT-DC Gateways. Therefore, by deploying native 249 IPv6 along with SIIT-DC, operators will avoid future migration or 250 deployment projects relating to IPv6 roll-out and/or IPv4 sun- 251 setting. 253 2. Terminology 255 This document makes use of the following terms: 257 IPv4 Service Address A public IPv4 address with which IPv4-only 258 clients will communicate. This communication will be translated 259 to IPv6 by the SIIT-DC Gateway. 261 IPv4 Service Address Pool One or more IPv4 prefixes routed to the 262 SIIT-DC Gateway's IPv4 interface. IPv4 Service Addresses are 263 allocated from this pool. Note that this does not necessarily 264 have to be a "pool" per se, as it could also be one or more host 265 routes (whose prefix length is equal to /32). The primary purpose 266 of using a pool rather than host routes is to facilitate IPv4 267 route aggregation and ease provisioning of new IPv4 Service 268 Addresses. 270 IPv6 Service Address A public IPv6 address assigned to a server or 271 application in the IPv6 network. IPv6-only and dual stacked 272 clients communicates with this address directly without invoking 273 SIIT-DC. IPv4-only clients also communicates with this address 274 through the SIIT-DC Gateway and via an IPv4 Service Address. 276 SIIT-DC Host Agent A logical function very similar to an SIIT-DC 277 Gateway that resides on a server and provides virtual IPv4 278 connectivity to applications, by reversing the translations done 279 by the SIIT-DC Gateway. It is an optional component of the SIIT- 280 DC architecture, that may be used to increase application support. 281 See [I-D.anderson-v6ops-siit-dc-2xlat]. 283 SIIT-DC Gateway A device or a logical function that translates 284 between IPv4 and IPv6 in accordance with Section 5. 286 Static Address Mapping A bi-directional mapping between an IPv4 287 Service Address and an IPv6 Service Address configured in the 288 SIIT-DC Gateway. When translating between IPv4 and IPv6, the 289 SIIT-DC Gateway changes the address fields in the translated 290 packet's IP header according to any matching Static Address 291 Mapping. 293 Translation Prefix An IPv6 prefix into which the entire IPv4 address 294 space is mapped. This prefix is routed to the SIIT-DC Gateway's 295 IPv6 interface. It is either an Network-Specific Prefix or a 296 Well-Known Prefix as specified in [RFC6052]. When translating 297 between IPv4 and IPv6, the SIIT-DC Gateway prepends or strips the 298 Translation Prefix from the address fields in the translated 299 packet's IP header, unless a Static Address Mapping exists for the 300 IP address in question. 302 3. Architectural Overview 304 This section describes the basic SIIT-DC architecture. 306 SIIT-DC Architecture 308 +-------------------+ +----------------+ 309 | IPv6-capable user | | IPv4-only user | 310 | ================= | | ============== | 311 | | | | 312 +-<2001:db8::ab:cd>-+ +-<203.0.113.50>-+ 313 | | 314 (the IPv6 internet) (the IPv4 Internet) 315 | | 316 | +------------------<192.0.2.0/24>-+ 317 | | | 318 | | SIIT-DC Gateway | 319 | | =============== | 320 | | | 321 | | Translation Prefix: | 322 | | 2001:db8:46::/96 | 323 | | | 324 | | Static Address Mapping: | 325 | | 192.0.2.1 <=> 2001:db8:12:34::1 | 326 | | | 327 | +--------------<2001:db8:46::/96>-+ 328 | | 329 (the IPv6-only data centre network) 330 | | 331 | ------------------------------/ 332 |/ 333 | 334 +--<2001:db8:12:34::1>------------------------------+ 335 | | | 336 | | IPv6-only server | 337 | | ================ | 338 | | | 339 | +-[2001:db8:12:34::1]---------------------------+ | 340 | | AF_INET6 | | 341 | | | | 342 | | IPv6-only application | | 343 | | | | 344 | +-----------------------------------------------+ | 345 +---------------------------------------------------+ 347 Figure 1 349 In this example, 192.0.2.0/24 is allocated as an IPv4 Service Address 350 Pool. Individual IPv4 Service Addresses are assigned from this pool. 351 The provider must route this prefix to the SIIT-DC Gateway's IPv4 352 interface. Note that there are no restrictions on how many IPv4 353 Service Address Pools are used or their prefix length, as long as 354 they are all routed to the SIIT-DC Gateway's IPv4 interface. 356 The Static Address Mapping list is used when translating an IPv4 357 Service Address (here 192.0.2.1) to its corresponding IPv6 Service 358 Address (here 2001:db8:12:34::1) and vice versa. When the SIIT-DC 359 Gateway translates an IPv4 packet to IPv6, any IPv4 Service Address 360 found in the original IPv4 header will be replaced with the 361 corresponding IPv6 Service Address in the resulting IPv6 header, and 362 vice versa when translating an IPv6 packet to IPv4. 364 2001:db8:46::/96 is the Translation Prefix into which the entire IPv4 365 address space is mapped. It is used for translation of the end 366 user's IPv4 address to IPv6 and vice versa according to the algorithm 367 defined in Section 2.2 of RFC6052 [RFC6052]. This algorithmic 368 mapping has a lower precedence than the configured Static Address 369 Mappings. 371 The SIIT-DC Gateway itself can be either a separate device or a 372 logical function in another multi-purpose device, for example an IP 373 router. Any number of SIIT-DC Gateways may exist simultaneously in 374 an operators infrastructure, as long as they all have the same 375 translation prefix and list of Static Mappings configured. 377 3.1. DNS Configuration 379 The IPv6 Service Address of should be registered in DNS using an "IN 380 AAAA" record, while its corresponding IPv4 Service Address should be 381 registered using an "IN A" record. This results in the following DNS 382 records: 384 DNS Configuration for a SIIT-DC enabled service 386 www.example.com. IN AAAA 2001:db8:12:34::1 387 www.example.com. IN A 192.0.2.1 389 Figure 2 391 3.2. Packet Flow 393 In this example, "IPv4-only user" initiates a request to the 394 application running on the IPv6-only server. He starts by looking up 395 the "IN A" record of "www.example.org" in DNS, and attempts to 396 connect to this address on the service by transmitting the following 397 IPv4 packet destined for the IPv4 Service Address: 399 Stage 1: Client -> Server, IPv4 401 +------------------------------------------------+ 402 | IP Version: 4 | 403 | Source Address: 203.0.113.50 | 404 | Destination Address: 192.0.2.1 | 405 | Protocol: TCP | 406 |------------------------------------------------| 407 | TCP SYN [...] | 408 +------------------------------------------------+ 410 Figure 3 412 This packet is then routed over the Internet to the (nearest) SIIT-DC 413 Gateway, which translates it into the following IPv6 packet and 414 forward it into the IPv6 network: 416 Stage 2: Client -> Server request, IPv4 418 +-------------------------------------------------+ 419 | IP Version: 6 | 420 | Source Address: 2001:db8:46::203.0.113.50 | 421 | Destination Address: 2001:db8:12:34::1 | 422 | Next Header: TCP | 423 |-------------------------------------------------| 424 | TCP SYN [...] | 425 +-------------------------------------------------+ 427 Figure 4 429 The destination address field was translated to the IPv6 Service 430 Address according to the configured Static Address Mapping, while the 431 source address was field translated according to the [RFC6052] 432 mapping using the Translation Prefix (because it did not match any 433 Static Address Mapping). The rest of the IP header was translated 434 according to [RFC6145]. The Layer 4 payload is copied verbatim, with 435 the exception of the TCP checksum being recalculated. 437 Note that the IPv6 address 2001:db8:46::203.0.113.50 may also be 438 expressed as 2001:db8:46::cb00:7132, cf. Section 2.2 of RFC4291 439 [RFC4291]. 441 Next, the application receives receives this IPv6 packet and responds 442 to it like it would with any other IPv6 packet: 444 Stage 3: Server -> Client response, IPv6 446 +-------------------------------------------------+ 447 | IP Version: 6 | 448 | Source Address: 2001:db8:12:34::1 | 449 | Destination Address: 2001:db8:46::203.0.113.50 | 450 | Next Header: TCP | 451 |-------------------------------------------------| 452 | TCP SYN+ACK [...] | 453 +-------------------------------------------------+ 455 Figure 5 457 The response packet is routed to the (nearest) SIIT-DC Gateway's IPv6 458 interface, which will translate it back to IPv4 as follows: 460 Stage 4: Server -> Client response, IPv4 462 +------------------------------------------------+ 463 | IP Version: 4 | 464 | Source Address: 192.0.2.2 | 465 | Destination Address: 203.0.113.50 | 466 | Protocol: TCP | 467 |------------------------------------------------| 468 | TCP SYN+ACK [...] | 469 +------------------------------------------------+ 471 Figure 6 473 This time, the source address matched the Static Address Mapping and 474 was translated accordingly, while the destination address did not, 475 and was therefore translated according to [RFC6052] by having the 476 Translation Prefix stripped. The rest of the packet was translated 477 according to [RFC6145]. 479 The resulting IPv4 packet is transmitted back to the end user over 480 the IPv4 Internet. Subsequent packets in the flow will follow the 481 exact same translation pattern. They may or may not cross the same 482 translators as earlier packets in the same flow. 484 The end user's IPv4 stack has no idea that it is communicating with 485 an IPv6 server, nor does the server's IPv6 stack have any idea that 486 is is communicating with an IPv4 client. To them, it's just plain 487 IPv4 or IPv6, respectively. However, the applications running on the 488 server may optionally be updated to recognise and strip the 489 Translation Prefix, so that the end user's IPv4 address may be used 490 for logging, Geo-Location, abuse handling, and so forth. 492 4. Deployment Guidelines 493 In this section, we list recommendations and guidelines for operators 494 who would like to deploy a SIIT-DC service in their data centre 495 network. 497 4.1. Application Support for NAT 499 Not all application protocols are able to operate in a network 500 environment where rewriting of IP addresses occur. An operator 501 should therefore carefully evaluate the applications he would like to 502 make available for IPv4 users through SIIT-DC, to ensure they do not 503 fall in this category. In general, if an application layer protocol 504 works correctly through standard NAT44 (see [RFC3235]), it will most 505 likely work correctly through SIIT-DC as well. 507 Higher-level protocols that embed IP addresses as part of their 508 payload are especially problematic, as noted in [RFC2663], [RFC2993], 509 and [RFC3022]. Such protocols will most likely not work through any 510 form of address translation, including SIIT-DC. One well-known 511 example of such a protocol is FTP [RFC0959]. 513 The SIIT-DC architecture may be extended with a Host Agent that 514 reverses the translation performed by the SIIT-DC Gateway before 515 passing the packets to the application software. This allows the 516 problematic application protocols described above to work correctly 517 in an SIIT-DC environment as well. See 518 [I-D.anderson-v6ops-siit-dc-2xlat] for a description of this 519 extension. 521 4.2. Application Support for IPv6 523 SIIT-DC requires that the application software supports IPv6 524 networking, and that it has no dependency on IPv4 networking. If 525 this is not the case, the approach described in 526 [I-D.anderson-v6ops-siit-dc-2xlat] may be used, as it provides the 527 application with seemingly native IPv4 connectivity. This allows 528 IPv4-only applications to work correctly in an otherwise IPv6-only 529 environment. 531 4.3. Application Communication Pattern 533 SIIT-DC is ideally suited for applications where IPv4-only nodes on 534 the Internet initiate traffic towards the IPv6-only services, which 535 in turn are only passively listening for inbound traffic and 536 responding as necessary. One well-known example of such a protocol 537 is HTTP [RFC7230]. This is due to the fact that in this case, an 538 IPv4 user looks exactly like an ordinary IPv6 user from the host and 539 application's point of view, and requires no special treatment. 541 It is possible to combine SIIT-DC with DNS64 [RFC6147] in order to 542 allow an IPv6-only application to initiate communication with 543 IPv4-only nodes through an SIIT-DC Gateway. However, in this case, 544 care must be taken so that all outgoing communication is sourced from 545 the IPv6 Service Address that has a Static Mapping configured on the 546 SIIT-DC Gateway. If another unmapped address is used, the SIIT-DC 547 Gateway will discard the packet. 549 An alternative approach to the above would be to make use of an SIIT- 550 DC Host Agent as described in [I-D.anderson-v6ops-siit-dc-2xlat]. 551 This provides the application with seemingly native IPv4 552 connectivity, which it may use for both inbound and outbound 553 communication without requiring the application to select a specific 554 source address for its outbound communications. 556 4.4. Choice of Translation Prefix 558 Either a Network-Specific Prefix (NSP) from the provider's own IPv6 559 address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96 560 (WKP) may be used. From a technical point of view, both should work 561 equally well, however as only a single WKP exists, if a provider 562 would like to deploy more than one instance of SIIT-DC in his 563 network, or Stateful NAT64 [RFC6146], an NSP must be used anyway for 564 all but one of those deployments. 566 Furthermore, the WKP cannot be used in inter-domain routing. By 567 using an NSP, a provider will have the possibility to provide SIIT-DC 568 service to other operators across Autonomous System borders. 570 For these reasons, this document recommends that an NSP is used. 571 Section 3.3 of [RFC6052] discusses the choice of translation prefix 572 in more detail. 574 The Translation Prefix may use any of the lengths described in 575 Section 2.2 of RFC6052 [RFC6052], but /96 has two distinct advantages 576 over the others. First, converting it to IPv4 can be done in a 577 single operation by simply stripping off the first 96 bits; second, 578 it allows for IPv4 addresses to be embedded directly into the text 579 representation of an IPv6 address using the familiar dotted quad 580 notation, e.g., "2001:db8::198.51.100.10" (cf. Section 2.4 of RFC6052 581 [RFC6052])), instead of being converted to hexadecimal notation. 582 This makes it easier to write IPv6 ACLs and similar that match 583 translated endpoints in the IPv4 Internet. Use of a /96 prefix 584 length is therefore recommended. 586 4.5. Routing Considerations 587 The prefixes that constitute the IPv4 Service Address Pool and the 588 IPv6 Translation Prefix may be routed to the SIIT-DC Gateway(s) as 589 any other IPv4 or IPv6 route in the provider's network. 591 If more than one SIIT-DC Gateway is being deployed, it is recommended 592 that a dynamic routing protocol (such as BGP, IS-IS, or OSPF) is 593 being used to advertise the routes within the provider's network. 594 This will ensure that the traffic that is to be translated will reach 595 the closest SIIT-DC Gateway, reducing or eliminating sub-optimal 596 traffic patterns, as well as provide high availability - if one SIIT- 597 DC Gateway fails, the dynamic routing protocol will automatically 598 redirect the traffic to the next-best translator. 600 4.6. Location of the SIIT-DC Gateways 602 The goal of SIIT-DC is to facilitate a true IPv6-only application and 603 network architecture, with the sole exception being the IPv4 604 interfaces of the SIIT-DC Gateways and the network infrastructure 605 required to connect them to the IPv4 Internet. Therefore, the SIIT- 606 DC Gateways should be located somewhere between the IPv4 Internet and 607 the application delivery stack. This should be understood to include 608 all servers, load balancers, firewalls, intrusion detection systems, 609 and similar devices that are processing traffic to a greater extent 610 than merely forwarding it. 612 It is optimal to place the SIIT-DC Gateways as close as possible to 613 the direct path between the servers and the end users. If the 614 closest translator is located a long way from the optimal path, all 615 packets in both directions must make a detour. This would increase 616 the RTT between the server and the end user by by two times the extra 617 latency incurred by the detour, as well as cause unnecessary load on 618 the network links on the detour path. 620 Where possible, it is beneficial to implement the SIIT-DC Gateways as 621 a logical function within the routers would have handled the traffic 622 anyway, had the topology been dual stacked. This way, the 623 translation service would not need to be assigned separate networks 624 ports (which might become saturated and impact the service quality), 625 nor would it require extra rack space and energy. Some particularly 626 good choices of the location could be within a data centre's access 627 routers, or within the provider's border routers. When every single 628 application in the data centre or the provider's network eventually 629 runs on single-stack IPv6, there would no need to run IPv4 on the 630 inside of the SIIT-DC Gateway. This reduces complexity, and allows 631 the operator to reclaim IPv4 addresses from the network 632 infrastructure that may instead be used as IPv4 Service Address 633 Pools. 635 Finally, another possibility is that the data centre operator 636 outsources the SIIT-DC service to another entity, for example his 637 upstream ISP. Doing so allows the data centre operator to build a 638 true IPv6-only infrastructure. However, in this case, care must be 639 taken to ensure that the path between the data centre and the SIIT-DC 640 operator has a stable and known MTU, and that the SIIT-DC Gateways 641 are not too far away from the data centre (otherwise, translated 642 traffic could incur a latency penalty). 644 4.7. Migration from Dual Stack 646 While this document discusses the use of IPv6-only servers and 647 applications, there is no technical requirement that the servers are 648 IPv4 free. SIIT-DC works equally well for dual stacked servers, 649 which makes migration easy - after setting up the translation 650 function, the DNS "IN A" record for the service is updated to point 651 to the IPv4 address that will be translated to IPv6, the previously 652 used IPv4 service address may continue to be assigned to the server. 653 This makes roll-back to dual stack easy, as it is only a matter of 654 changing the DNS record back to what it was before. 656 It is also possible to use DNS Round Robin to gradually migrate a 657 dual-stacked service's IPv4 traffic from native to SIIT-DC. This is 658 done by configuring multiple DNS "IN A" records for the service's 659 hostname, and pointing one portion of them to the service's native 660 IPv4 addresses and another portion to IPv4 Service Addresses handled 661 by SIIT-DC. The distribution of "IN A" records determines how much 662 of the client traffic will pass through the SIIT-DC Gateway and how 663 much will remain native. This operator may then gradually increase 664 the share of SIIT-DC "IN A" DNS records until no native addresses 665 remain. 667 When all client traffic is handled by SIIT-DC, the operator may 668 proceed to remove the (now unused) IPv4 addresses assigned to the 669 servers in question. They could then potentially be recycled as 670 another IPv4 Service Address Pool assigned to SIIT-DC. 672 4.8. Packet Size and Fragmentation Considerations 674 There are some key differences between IPv4 and IPv6 relating to 675 packet sizes and fragmentation that one should consider when 676 deploying SIIT-DC. They result in a few problematic corner cases, 677 which can be dealt with in a few different ways. The following 678 subsections will discuss these in detail, and provide operational 679 guidance. 681 In particular, the operator may find that relying on fragmentation in 682 the IPv6 domain is undesired or even operationally impossible 684 [I-D.taylor-v6ops-fragdrop]. For this reason, the recommendations in 685 this section seeks to minimise the use of IPv6 fragmentation. 687 Unless otherwise stated, the following subsections assume that the 688 MTU in both the IPv4 and IPv6 domains is 1500 bytes. 690 4.8.1. IPv4/IPv6 Header Size Difference 692 The IPv6 header is up to 20 bytes larger than the IPv4 header. This 693 means that a full-size 1500 bytes large IPv4 packet cannot be 694 translated to IPv6 without being fragmented, otherwise it would 695 likely have resulted in a 1520 bytes large IPv6 packet. 697 If the transport protocol used is TCP, this is generally not a 698 problem, as the IPv6 server will advertise a TCP MSS of 1440 bytes. 699 This causes the client to never send larger packets than what can be 700 translated to a single full-size IPv6 packet, eliminating any need 701 for fragmentation. 703 For other transport protocols, full-size IPv4 packets with the DF 704 flag cleared will need to be fragmented by the SIIT-DC Gateway. The 705 only way to avoid this is to increase the Path MTU between the SIIT- 706 DC Gateway and the servers to 1520 bytes. Note that the servers' MTU 707 SHOULD NOT be increased accordingly, as that would cause them to 708 undergo Path MTU Discovery for most native IPv6 destinations. 709 However, the servers would need to be able to accept and process 710 incoming packets larger than their own MTU. If the server's IPv6 711 implementation allows the MTU to be set differently for specific 712 destinations, it could be increased to 1520 for destinations within 713 the Translation Prefix specifically. 715 4.8.2. IPv6 Atomic Fragments 717 In keeping with the fifth paragraph of Section 4 of RFC6145 718 [RFC6145], an SIIT-DC Gateway will by default add an IPv6 719 Fragmentation header to the resulting IPv6 packet when translating an 720 IPv4 packet with the Don't Fragment flag set to 0. 722 This happens even though the resulting IPv6 packet isn't actually 723 fragmented into several pieces, resulting in an IPv6 Atomic Fragment 724 [RFC6946]. These Atomic Fragments are generally not useful in a data 725 centre environment, and it is therefore recommended that this 726 behaviour is disabled in the SIIT-DC Gateways. To this end, 727 Section 4 of RFC6145 [RFC6145] notes that the "translator MAY provide 728 a configuration function that allows the translator not to include 729 the Fragment Header for the non-fragmented IPv6 packets". 731 Note that [I-D.ietf-6man-deprecate-atomfrag-generation] seeks to 732 update [RFC6145], making the functionality described above as the 733 standard and only mode of operation. 735 In IPv6, the Identification value is located inside the Fragmentation 736 header. That means that if the generation of IPv6 Atomic Fragments 737 is disabled, the IPv4 Identification value will be lost during 738 translation to IPv6. This could potentially confuse some diagnostic 739 tools. 741 4.8.3. Minimum Path MTU Difference Between IPv4 and IPv6 743 Section 5 of RFC2460 [RFC2460] specifies that the minimum IPv6 link 744 MTU is 1280 bytes. Therefore, an IPv6 node can reasonably assume 745 that if it transmits an IPv6 packet that is 1280 bytes or smaller, it 746 is guaranteed to reach its destination without requiring 747 fragmentation or invoking the Path MTU Discovery algorithm [RFC1981]. 748 However, this assumption fails if the destination is an IPv4 node 749 reached through a protocol translator such as an SIIT-DC Gateway, as 750 the minimum IPv4 link MTU is 68 bytes. See Section 3.2 of RFC791 751 [RFC0791]. 753 Section 5.1 of RFC6145 [RFC6145] specifies that an SIIT-DC Gateway 754 should set the IPv4 Don't Fragment flag to 1 when it translates a 755 non-fragmented IPv6 packet to IPv4. This means that when the path to 756 the destination IPv4 node contains an IPv4 link with an MTU smaller 757 than 1260 bytes (which corresponds to an IPv6 MTU smaller than 1280 758 bytes, cf. Section 4.8.1), the Path MTU Discovery algorithm will be 759 invoked, even if the original IPv6 packet was only 1280 bytes large. 760 This happens as a result of the IPv4 router connecting to the IPv4 761 link with the small MTU returning an ICMPv4 Need To Fragment error 762 with an MTU value smaller than 1260, which in turns is translated by 763 the SIIT-DC Gateway to an ICMPv6 Packet Too Big error with an MTU 764 value smaller than 1280 which is then transmitted to the origin IPv6 765 node. 767 When an IPv6 node receives an ICMPv6 Packet Too Big error indicating 768 an MTU value smaller than 1280, the last paragraph of Section 5 of 769 RFC2460 [RFC2460] gives it two choices on how to proceed: 771 o It may reduce its Path MTU value to the value indicated in the 772 Packet Too Big, i.e., limit the size of subsequent packets 773 transmitted to that destination to the indicated value. This 774 approach causes no problems for the SIIT-DC function, as it simply 775 allows Path MTU Discovery to work transparently across the SIIT-DC 776 Gateway. 778 o It may reduce its Path MTU value to exactly 1280, and in addition 779 include a Fragmentation header in subsequent packets sent to that 780 destination. In other words, the IPv6 node will start emitting 781 Atomic Fragments. The Fragmentation header signals to the the 782 SIIT-DC Gateway that the Don't Fragment flag should be set to 0 in 783 the resulting IPv4 packet, and it also provides the Identification 784 value. 786 If the use of the IPv6 Fragmentation header is problematic, and the 787 operator has IPv6 nodes that implement the second option above, the 788 operator should consider enabling the functionality described as the 789 "second approach" in Section 6 of RFC6145 [RFC6145]. This 790 functionality changes the SIIT-DC Gateway's behaviour as follows: 792 o When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big, 793 the resulting packet will never contain an MTU value lower than 794 1280. This prevents the IPv6 nodes from generating Atomic 795 Fragments. 797 o When translating IPv6 packets smaller than or equal to 1280 bytes, 798 the Don't Fragment flag in the resulting IPv4 packet will be set 799 to 0. This ensures that in the eventuality that the path contains 800 an IPv4 link with an MTU smaller than 1260, the IPv4 router 801 connected to that link will have the responsibility to fragment 802 the packet before forwarding it towards its destination. 804 In summary, this approach could be seen as prompting the IPv4 805 protocol itself to provide the "link-specific fragmentation and 806 reassembly at a layer below IPv6" required for links that "cannot 807 convey a 1280-octet packet in one piece", to paraphrase Section 5 of 808 RFC2460 [RFC2460]. Note that 809 [I-D.ietf-6man-deprecate-atomfrag-generation] seeks to update 810 [RFC6145], making the approach described above as the standard and 811 only mode of operation. 813 5. Implementation Requirements 815 This normative section specifies the SIIT-DC protocol that is 816 implemented by an SIIT-DC Gateway. Because SIIT-DC builds on and 817 closely resembles SIIT [RFC6145], this section should be read as a 818 set of additions and changes that are applied to an implementation 819 already compliant to SIIT [RFC6145]. Each of the following 820 subsections discuss how the requirement relates to with any 821 corresponding requirements in SIIT [RFC6145]. 823 5.1. Compliance with RFC6145 and RFC6052 824 Unless otherwise stated in the following sections, an SIIT-DC 825 implementation MUST comply fully with [RFC6145]. It must also 826 implement the algorithmic address mapping defined in [RFC6052]. 828 5.2. Static Address Mapping Function 830 The implementation MUST allow the operator to configure an arbitrary 831 number of Static Address Mappings which override the default 832 [RFC6052] algorithm. It SHOULD be possible to specify a single bi- 833 directional mapping that will be used in both the IPv4=>IPv6 and 834 IPv6=>IPv4 directions, but it MAY additionally (or alternatively) 835 support unidirectional mappings. 837 An example of such a bidirectional Static Address Mapping would be: 839 o 192.0.2.1 <=> 2001:db8:12:34::1 841 To accomplish the same using unidirectional mappings, the following 842 two mappings must instead be configured: 844 o 192.0.2.1 => 2001:db8:12:34::1 846 o 2001:db8:12:34::1 => 192.0.2.1 848 In both cases, if the SIIT-DC Gateway receives an IPv6 packet that 849 has the value 2001:db8:12:34::1 in either the source or destination 850 field of the IPv6 header, it MUST rewrite this field to 192 0.2.1 851 when translating to IPv4. Similarly, if the SIIT-DC Gateway receives 852 an IPv4 packet that has the value 192.0.2.1 as the either the source 853 or destination field of the IPv4 header, it MUST rewrite this field 854 to 2001:db8:12:34::1 when translating to IPv6. For all IPv4 or IPv6 855 source or destination field values for which there are no matching 856 Static Address Mapping, [RFC6052] compliant mapping MUST be used 857 instead. 859 Relation to [RFC6145]: The Static Address Mapping is a novel feature 860 feature that is not discussed in [RFC6145]. It conflicts with the 861 [RFC6145] requirement that all addresses must be translated according 862 to the [RFC6052] algorithm. 864 5.3. Support for Increasing the IPv6 Path MTU 866 The SIIT-DC Gateway MUST provide a configuration function for the 867 network administrator to adjust the threshold of the minimum IPv6 MTU 868 to a value that reflects the real value of the minimum IPv6 MTU in 869 the network (greater than 1280 bytes). This will help reduce the 870 chance of including the Fragment Header in the resulting IPv6 871 packets. 873 Relation to [RFC6145]: This strengthens the corresponding "MAY" 874 requirement located in Section 4 of RFC6145 [RFC6145] to a "MUST". 876 5.4. Loop Prevention Mechanism 878 As noted in Section 9.2, there is a potential for packets looping 879 through the SIIT-DC function if it receives an IPv4 packet for which 880 there is no Static Address Mapping. It is therefore RECOMMENDED that 881 the implementation has a mechanism that automatically prevents this 882 behaviour. One way this could be accomplished would be to discard 883 any IPv4 packets that would be translated into an IPv6 packet that 884 would be routed straight back into the SIIT-DC function. 886 If such a mechanism isn't provided, the implementation MUST provide a 887 way to manually filter or null-route the destination addresses that 888 would otherwise cause loops. 890 Relation to [RFC6145]: This security consideration applies only when 891 an SIIT-DC Gateway translates a packet in "pure" SIIT [RFC6145] mode 892 (i.e., when both address fields are translated according to 893 [RFC6052]). This consideration is in other words not specific to 894 SIIT-DC, it is inherited from [RFC6145]. In spite of this, [RFC6145] 895 does not describe this consideration or any methods of prevention. 896 The requirements in this section is therefore novel to SIIT-DC, even 897 though they apply equally to [RFC6145]. 899 6. Acknowledgements 901 The author would like to thank the following individuals for their 902 contributions, suggestions, corrections, and criticisms: Fred Baker, 903 Cameron Byrne, Brian E Carpenter, Ross Chandler, Dagfinn Ilmari 904 Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed, 905 Andrew Yourtchenko. 907 7. Requirements Language 909 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 910 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 911 document are to be interpreted as described in [RFC2119]. 913 8. IANA Considerations 915 This draft makes no request of the IANA. The RFC Editor may remove 916 this section prior to publication. 918 9. Security Considerations 919 9.1. Mistaking the Translation Prefix for a Trusted Network 921 If a Network-Specific Prefix from the provider's own address space is 922 chosen for the translation prefix, as is recommended, care must be 923 taken if the translation service is used in front of services that 924 have application-level ACLs that distinguish between the operator's 925 own networks and the Internet at large, as the translated IPv4 end 926 users on the Internet will appear to be located within the provider's 927 own IPv6 address space. It is therefore important that the 928 translation prefix is treated the same as the Internet at large, 929 rather than as a trusted network. 931 9.2. Packets Looping Through the SIIT-DC Function 933 If the SIIT-DC Gateway receives an IPv4 packet destined to an address 934 for which there is no Static Address Mapping, its destination address 935 will be rewritten according to [RFC6052], making the resulting IPv6 936 packet have a destination address within the translation prefix, 937 which is likely routed to back to the SIIT-DC function. This will 938 cause the packet to loop until its Time To Live / Hop Limit reaches 939 zero, potentially creating a Denial Of Service vulnerability. 941 To avoid this, it should be ensured that packets sent to IPv4 942 destinations addresses for which there are no Static Address 943 Mappings, or whose resulting IPv6 address does not have a more- 944 specific route to the IPv6 network, are immediately discarded. 946 10. References 948 10.1. Normative References 950 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 951 Requirement Levels", BCP 14, RFC 2119, March 1997. 953 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 954 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 955 October 2010. 957 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 958 Algorithm", RFC 6145, April 2011. 960 10.2. Informative References 962 [I-D.anderson-v6ops-siit-dc-2xlat] 963 tore, t., "SIIT-DC: Dual Translation Mode", draft- 964 anderson-v6ops-siit-dc-2xlat-00 (work in progress), 965 September 2014. 967 [I-D.ietf-6man-deprecate-atomfrag-generation] 968 Gont, F., Will, W., and t. tore, "Deprecating the 969 Generation of IPv6 Atomic Fragments", draft-ietf-6man- 970 deprecate-atomfrag-generation-00 (work in progress), 971 November 2014. 973 [I-D.taylor-v6ops-fragdrop] 974 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 975 M., and T. Taylor, "Why Operators Filter Fragments and 976 What It Implies", draft-taylor-v6ops-fragdrop-02 (work in 977 progress), December 2013. 979 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 980 1981. 982 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 983 9, RFC 959, October 1985. 985 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 986 E. Lear, "Address Allocation for Private Internets", BCP 987 5, RFC 1918, February 1996. 989 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 990 for IP version 6", RFC 1981, August 1996. 992 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 993 (IPv6) Specification", RFC 2460, December 1998. 995 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 996 Translator (NAT) Terminology and Considerations", RFC 997 2663, August 1999. 999 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 1000 Multicast Next-Hop Selection", RFC 2991, November 2000. 1002 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1003 November 2000. 1005 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1006 Address Translator (Traditional NAT)", RFC 3022, January 1007 2001. 1009 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 1010 Application Design Guidelines", RFC 3235, January 2002. 1012 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1013 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1015 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 1016 October 2005. 1018 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1019 Architecture", RFC 4291, February 2006. 1021 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1022 NAT64: Network Address and Protocol Translation from IPv6 1023 Clients to IPv4 Servers", RFC 6146, April 2011. 1025 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1026 Beijnum, "DNS64: DNS Extensions for Network Address 1027 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1028 April 2011. 1030 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1031 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1032 RFC 6540, April 2012. 1034 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 1035 Content Providers and Application Service Providers", RFC 1036 6883, March 2013. 1038 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 1039 6946, May 2013. 1041 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1042 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 1043 2014. 1045 [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 1046 Deployment Options and Experience", RFC 7269, June 2014. 1048 Appendix A. Complete SIIT-DC topology example 1050 This figure shows a more complete SIIT-DC topology, in order to 1051 better demonstrate the beneficial properties it has. In particular, 1052 it tries to highlight the following: 1054 o Stateless operation: Any number of SIIT-DC Gateways may be 1055 deployed side-by side, or indeed anywhere in the IPv6 network, as 1056 any standard routing mechanism may be used to direct traffic to 1057 them (shown here with BGP on the IPv4 side and ECMP on the IPv6 1058 side). This in turn leads to high availability, should one of the 1059 SIIT-DC Gateways fail or become unavailable, those standard 1060 routing mechanisms will ensure that traffic is automatically 1061 redirect one of the remaining SIIT-DC Gateways. 1063 o IPv4 address conservation: Even though the to customers in the 1064 example have several hundred servers, most of them are not used 1065 for externally available services, and thus do not require an IPv4 1066 address. The network between the servers and the SIIT-DC Gateways 1067 require no IPv4 addresses, either. Furthermore, the IPv4 1068 addresses that are used do not have to be assigned to customers in 1069 the form of aggregated blocks or prefixes; which makes it easy to 1070 achieve 100% effective utilisation of the IPv4 service address 1071 pools. 1073 o Application support: The translation-friendly applications HTTP 1074 and SMTP will work through SIIT-DC without requiring any special 1075 customisation. Furthermore, translation-unfriendly applications 1076 such as FTP will also work if an host agent in present, cf. 1077 [I-D.anderson-v6ops-siit-dc-2xlat]. 1079 o Native IPv6 as the foundation: Every server, application, and 1080 network component has access to native and untranslated IPv6 1081 connectivity to each other and to the Internet. Traffic through 1082 the SIIT-DC Gateways will diminish over time as IPv6 is deployed 1083 throughout the Internet. Eventually they may be shut down 1084 entirely, which causes no disruption to the application stacks' 1085 ability to deliver their services over native IPv6. 1087 Example data centre topology using SIIT-DC 1088 /--------------------------------\ /---------------\ 1089 | IPv4 Internet | | IPv6 Internet | 1090 \-+----------------------------+-/ \--------+------/ 1091 | | | 1092 | <----------[BGP]---------> | | 1093 | | | 1094 +---------<192.0.2.0/24>----------+ +---<192.0.2.0/24>---+ | 1095 | | | | | 1096 | SIIT-DC Gateway 1 | | SIIT-DC Gateway 2 | | 1097 | ================= | | ================= | | 1098 | | | | | 1099 | Translation Prefix: | | | | 1100 | 2001:db8:46::/96 | | | | 1101 | | | | | 1102 | Static Address Mappings: | | Exactly the same | | 1103 | 192.0.2.1 <=> 2001:db8:12:34::1 | | configuration as | | 1104 | 192.0.2.2 <=> 2001:db8:12:34::2 | | SIIT-DC Gateway 1 | | 1105 | 192.0.2.3 <=> 2001:db8:fe:dc::1 | | | | 1106 | 192.0.2.4 <=> 2001:db8:12:34::4 | | | | 1107 | [...] | | | | 1108 | | | | | 1109 +--------<2001:db8:46::/96>-------+ +-<2001:db8:46::/96>-+ | 1110 | | | 1111 | <---------[ECMP]---------> | | 1112 | | | 1113 /-----------------+----------------------------+-\ | 1114 | IPv6 data centre network +----------+ 1115 \-+-----------------------------------+----------/ 1116 | | 1117 | Customer A's server LAN | Customer B's server LAN 1118 | 2001:db8:12:34::/64 | 2001:db8:fe:dc::/64 1119 | | 1120 | | 1121 +-- www ::1 (IPv6+SIIT-DC) +-- www ::1 (IPv6+SIIT-DC) 1122 | | 1123 | +-- file01 ::f:01 (IPv6) 1124 +-- mta ::2 (IPv6+SIIT-DC) | [...] 1125 | +-- file99 ::f:99 (IPv6) 1126 +-- ftp ::3 (IPv6) 1127 | ::4 (SIIT-DC/Host Agent) 1128 | 1129 +-- app01 ::a:01 (IPv6) 1130 | [...] 1131 +- app99 ::a:99 (IPv6) 1132 | 1133 +-- db01 ::d:01 (IPv6) 1134 | [..] 1135 +-- db99 ::d:99 (IPv6) 1136 Figure 7 1138 Appendix B. Comparison to Other Deployment Approaches 1140 There are a number of alternative deployment strategies a data centre 1141 operator may follow. They each have different properties and helps 1142 solve a different set of challenges. This section aims to compare 1143 the SIIT-DC approach with each of the most common ones, by 1144 highlighting the benefits and disadvantages of each. 1146 B.1. IPv4-only 1148 At the time of writing, IPv4-only operation remains the status quo 1149 for most operators. As such, it is well understood and supported. 1150 An operator can reasonably expect everything to work correctly in an 1151 IPv4-only environment. 1153 Benefits of IPv4-only operation compared to SIIT-DC include: 1155 o No translation occurs, the end-to-end principle is intact. 1157 o Compatible with all common application protocols. 1159 o Compatible with IPv4-only devices. 1161 o Compatible with IPv4-only application software, without requiring 1162 a host agent. 1164 Disadvantages of IPv4-only operation compared to SIIT-DC include: 1166 o Does not provide any form of IPv6 connectivity. 1168 o Does not alleviate IPv4 address scarcity. 1170 B.2. IPv4-only + NAPT44 1172 An operator who would otherwise chose a traditional IPv4-only 1173 approach, but cannot due to having insufficient public IPv4 addresses 1174 available, could chose to deploy using a combination of private IPv4 1175 addresses [RFC1918] and NAPT44 [RFC3022] devices which will translate 1176 between a smaller number of public IPv4 addresses and the private 1177 addresses assigned to the servers that provide public services to the 1178 Internet. 1180 Benefits of IPv4-only + NAPT44 operation compared to SIIT-DC include: 1182 o Compatible with IPv4-only devices. 1184 o Compatible with IPv4-only application software, without requiring 1185 a host agent. 1187 Disadvantages of IPv4-only + NAPT44 operation compared to SIIT-DC 1188 include: 1190 o Does not provide any form of IPv6 availability. 1192 o Requires network devices that track all flow state, which may 1193 create a performance bottleneck and be an easy target for Denial 1194 of Service attacks. 1196 o Limits routing flexibility (prevents closest exit routing), as 1197 outbound traffic must pass across the same NAPT44 device that 1198 handled the inbound traffic. 1200 o Limited potential for horizontal scaling, as packets cannot be 1201 load-balanced across multiple NAT devices. 1203 o Depending on whether or not the NAPT44 device rewrites source 1204 addresses in order to attract the return traffic to itself: 1206 o 1208 * Obscures the true source address of the user from the server/ 1209 application, preventing it from e.g. performing geo-location 1210 lookups, or: 1212 * Requires an IPv4 default route to be pointed to the NAPT44 1213 device, also attracting native traffic that does not need to 1214 undergo translation. 1216 In addition, application compatibility is a consideration with both 1217 NAPT44 and SIIT-DC, but the exact nature depends from application to 1218 application, so it is hard to objectively quantify if there is a 1219 clear advantage to either approach here. Some translation-unfriendly 1220 application protocols may work without host modifications through the 1221 use of Application Layer Gateway support in the NAPT44 device (e.g., 1222 FTP [RFC0959]), or in the SIIT-DC architecture when a host agent is 1223 being used [I-D.anderson-v6ops-siit-dc-2xlat]. Other application 1224 protocols might not work with NAPT44 at all, but will work in the 1225 SIIT-DC if a host agent is being used (e.g., FTP/TLS [RFC4217]). 1227 In summary, the most accurate statement would be to say that an 1228 NAPT44 architecture is more compatible with translation-unfriendly 1229 protocols than plain SIIT-DC, while SIIT-DC is more compatible than 1230 NAPT44 if a host agent is used. 1232 For a more complete discussion of potential issues with running 1233 NAPT44, see Architectural Implications of NAT [RFC2993]. 1235 B.3. IPv4-only + NAT64 1237 An operator who would otherwise chose a traditional IPv4-only 1238 approach, but would in addition like to provide service availability 1239 for IPv6 end users, could use Stateful NAT64 [RFC6146] to accomplish 1240 this. In a sense, this would be the mirror image of an SIIT-DC 1241 architecture: The infrastructure and servers remains single-stacked, 1242 while connectivity to the other IP stack is provided through a 1243 translation system. Further information about operating Stateful 1244 NAT64 is found in [RFC7269]. 1246 Note that Stateful NAT64 can be deployed with or without NAPT44. 1247 With the exception that IPv6 service availability is being provided, 1248 the discussion in the previous two sections fully applies to an 1249 IPv4-only environment that includes NAT64. 1251 Benefits of IPv4-only + NAT64 operation compared to SIIT-DC include: 1253 o Compatible with IPv4-only devices. 1255 o Compatible with IPv4-only application software, without requiring 1256 a host agent. 1258 Disadvantages of IPv4-only + NAT64 operation compared to SIIT-DC 1259 include: 1261 o Does not alleviate IPv4 address scarcity (assuming NAPT44 isn't 1262 used). 1264 o Requires network devices that track all flow state, which may 1265 create a performance bottleneck and be an easy target for Denial 1266 of Service attacks. 1268 o Limits routing flexibility (prevents closest exit routing), as 1269 outbound traffic must pass across the same NAT64 device that 1270 handled the inbound traffic. 1272 o Limited potential for horizontal scaling, as packets cannot be 1273 load-balanced across multiple NAT devices. 1275 o Obscures the true source address of the user from the server/ 1276 application, preventing it from e.g. performing geo-location 1277 lookups. 1279 o The traffic levels on the Stateful NAT64 routers will increase 1280 over time, in lockstep with the increased deployment of IPv6 in 1281 the Internet. For this reason, Section 3.2 of RFC7269 [RFC7269] 1282 notes that the use of Stateful NAT64 in a data centre environment 1283 "is only reasonable at an early stage". With SIIT-DC, the inverse 1284 is true; the traffic levels on the SIIT-DC Gateways will decrease 1285 over time, as end users will prefer to use native IPv6 once it is 1286 available to them. 1288 B.4. Dual Stack 1290 Dual Stack [RFC4213] [RFC6883] could be used both with or without 1291 NAPT44 to handle IPv4. In general, the benefits and disadvantages 1292 are equal to the corresponding IPv4-only option, except for the fact 1293 that Dual Stack does provides IPv6 connectivity. Therefore, his 1294 section only lists the benefits and disadvantages which are unique to 1295 a Dual Stack environment. 1297 Benefits of Dual Stack operation compared to SIIT-DC include: 1299 o No translation occurring, the end-to-end principle is intact 1300 (assuming NAPT44 isn't used). 1302 o Compatible with all common application protocols (assuming NAPT44 1303 isn't used). 1305 o Compatible with IPv4-only devices. 1307 o Compatible with IPv4-only application software, without requiring 1308 a host agent. 1310 Disadvantages of Dual Stack operation compared to SIIT-DC include: 1312 o Does not alleviate IPv4 address scarcity (assuming NAPT44 isn't 1313 used). 1315 o Increases the complexity of the infrastructure, as many things 1316 must done twice (once for IPv4 and once for IPv6). Examples of 1317 things that must be duplicated in this manner under Dual Stack 1318 include: Firewall rules/ACLs, IGP topology, monitoring, 1319 troubleshooting. 1321 o Encourages software developers, systems administrators, etc. to 1322 build architectures that cannot operate correctly without IPv4. 1323 This in turn makes it difficult to make use of Dual Stack as a 1324 short term transitional stage, rather than a near-permanent end 1325 state. 1327 o Increases the amount of things that can encounter failures, and 1328 increases the time required to locate and fix such failures. This 1329 reduces reliability. 1331 B.5. Partial Dual Stack (IPv6-only back-end) 1333 It is possible to use the Dual Stack deployment strategy for front- 1334 end services only. That is, the front-end servers (or load 1335 balancers) that serves public Internet-available services are 1336 provisioned with both native IPv4 and native IPv6 connectivity on 1337 their Internet-facing interfaces, while the interfaces facing the 1338 back-end infrastructure are IPv6 only. All back-end servers that do 1339 not communicate directly with Internet clients are IPv6-only. All 1340 communication between back-end servers as well as all traffic between 1341 the back-end servers and the front-end servers will therefore use 1342 only IPv6. 1344 One variation of this approach is to have a two separate sets of 1345 front-end servers, where one set has IPv4-only Internet-facing 1346 interfaces, while the other set has IPv6-only Internet-facing 1347 interfaces. However, both sets must have IPv6-only interfaces facing 1348 the back-end infrastructure. 1350 Benefits of Partial Dual Stack operation compared to SIIT-DC include: 1352 o No translation occurring, the end-to-end principle is intact. 1354 o Compatible with all common application protocols. 1356 o Compatible with IPv4-only devices (front-end only). 1358 o Compatible with IPv4-only application software (front-end only). 1360 Disadvantages of Partial Dual Stack operation compared to SIIT-DC 1361 include: 1363 o Increases the complexity of the front-end infrastructure, as many 1364 things must done twice (once for IPv4 and once for IPv6). 1365 Examples of things that must be duplicated in this manner under 1366 Partial Dual Stack include: Firewall rules/ACLs, IGP topology, 1367 monitoring, troubleshooting. 1369 o Can not support any IPv4-only devices or application software in 1370 the back-end infrastructure. 1372 In addition, Partial Dual Stack will alleviate IPv4 address scarcity 1373 compared to the normal Dual Stack approach, but not quite to the same 1374 extent as SIIT-DC. This is primarily due to the data centre network 1375 infrastructure having to be dual-stacked in order to provide native 1376 IPv4 addressing to the front-end servers, and because the front-end 1377 server LANs must be rounded up in size to the nearest CIDR boundary 1378 which may result in IPv4 addresses being unused. However, depending 1379 on the exact circumstances, this difference in IPv4 address 1380 consumption between SIIT-DC and Partial Dual Stack may be negligible. 1382 Author's Address 1384 Tore Anderson 1385 Redpill Linpro 1386 Vitaminveien 1A 1387 0485 Oslo 1388 Norway 1390 Phone: +47 959 31 212 1391 Email: tore@redpill-linpro.com 1392 URI: http://www.redpill-linpro.com