idnits 2.17.1 draft-ietf-v6ops-siit-dc-2xlat-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 25, 2015) is 3377 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) == Missing Reference: 'XLAT' is mentioned on line 402, but not defined == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-siit-dc-00 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-siit-dc (ref. 'I-D.ietf-v6ops-siit-dc') -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 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 January 25, 2015 5 Expires: July 29, 2015 7 SIIT-DC: Dual Translation Mode 8 draft-ietf-v6ops-siit-dc-2xlat-00 10 Abstract 12 This document describes an extension of the Stateless IP/ICMP 13 Translation for IPv6 Data Centre Environments architecture (SIIT-DC), 14 which allows applications, protocols, or nodes that are incompatible 15 with IPv6, SIIT-DC and/or Network Address Translation in general to 16 operate correctly in an SIIT-DC environment. This is accomplished by 17 introducing a new component called an Edge Translator, which reverses 18 the translations made by an SIIT-DC Gateway. The application or 19 device is thus provided with seemingly native IPv4 connectivity. 21 The reader is expected to be familiar with the SIIT-DC architecture 22 described in I-D.ietf-v6ops-siit-dc. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 29, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Edge Translator Description . . . . . . . . . . . . . . . . . 4 61 3.1. Host-Based Edge Translator . . . . . . . . . . . . . . . 5 62 3.2. Network-Based Edge Translator . . . . . . . . . . . . . . 6 63 4. Detailed Topology Example . . . . . . . . . . . . . . . . . . 9 64 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 65 5.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 12 66 5.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5.3. IPv4 Identification Header . . . . . . . . . . . . . . . 12 68 6. Intra-DC IPv4 Communication . . . . . . . . . . . . . . . . . 13 69 6.1. Between IPv4-Only and IPv6-Only Services . . . . . . . . 13 70 6.2. Between Two IPv4-Only Services . . . . . . . . . . . . . 15 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 9.1. Address Spoofing . . . . . . . . . . . . . . . . . . . . 18 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 77 10.2. Informative References . . . . . . . . . . . . . . . . . 19 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 80 1. Introduction 82 SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where 83 IPv4-only users can access IPv6-only services through a stateless 84 translator called an SIIT-DC Gateway. This approach has certain 85 limitations, however. In particular, the following cases will work 86 poorly or not at all: 88 o Application protocols that do not support NAT (i.e., the lack of 89 end-to-end transparency of IP addresses). 91 o Devices which cannot connect to IPv6 networks at all, or which can 92 only connect such networks if they also provide IPv4 connectivity 93 (i.e., dual-stacked networks). 95 o Application software which makes use of legacy IPv4-only APIs, or 96 otherwise makes assumptions that IPv4 connectivity is available. 98 By extending the SIIT-DC architecture with a new component called an 99 Edge Translator (ET), all of the above can be made to work correctly 100 in an otherwise IPv6-only network environment using SIIT-DC. 102 The purpose of the Edge Translator is to reverse the IPv4-to-IPv6 103 packet translations previously done by the SIIT-DC Gateway for 104 traffic arriving from IPv4 clients and forward this as "native" IPv4 105 to the application software or device. In the reverse direction, 106 IPv4 packets transmitted by the application software or device is 107 intercepted by the Edge Translator, which will translate them to IPv6 108 before they are forwarded to the SIIT-DC Gateway, which in turn will 109 reverse the translations and forward them to the IPv4 End User. In 110 short, the device or application software is provided with "virtual" 111 IPv4 Internet connectivity that retains end-to-end transparency for 112 the IPv4 addresses. 114 2. Terminology 116 This document makes use of the following terms: 118 Edge Translator (ET) 119 A device or logical function that provides "native" IPv4 120 connectivity to IPv4-only devices or application software. It is 121 very similar in function to an SIIT-DC Gateway, but is typically 122 located close to the IPv4-only component(s) it is supporting 123 rather than on the network border. 125 IPv4 Service Address 126 A public IPv4 address with which IPv4-only clients will 127 communicate. This communication will be translated to IPv6 by the 128 SIIT-DC Gateway and back to IPv4 again by the Edge Translator. 130 SIIT-DC Gateway 131 A device or a logical function that translates between IPv4 and 132 IPv6 in accordance with [I-D.ietf-v6ops-siit-dc]. 134 Static Address Mapping 135 A bi-directional mapping between an IPv4 Service Address and an 136 IPv6 Service Address configured in the SIIT-DC Gateway. When 137 translating between IPv4 and IPv6, the SIIT-DC Gateway changes the 138 address fields in the translated packet's IP header according to 139 any matching Static Address Mapping. 141 Translation Prefix 142 An IPv6 prefix into which the entire IPv4 address space is mapped. 143 This prefix is routed to the SIIT-DC Gateway's IPv6 interface. It 144 is either an Network-Specific Prefix or a Well-Known Prefix as 145 specified in [RFC6052]. When translating between IPv4 and IPv6, 146 the SIIT-DC Gateway will prepend or strip the Translation Prefix 147 from the address fields in the translated packet's IP header, 148 unless a Static Address Mapping exists for the IP address in 149 question. 151 XLAT 152 Used in figures to indicate where the Stateless IP/ICMP 153 Translation [RFC6145] algorithm is used to translate IPv4 packets 154 to IPv6 and vice versa. 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 3. Edge Translator Description 162 An Edge Translator (ET) is at its core an implementation of the 163 Stateless IP/ICMP Translation algorithm [RFC6145], with the Static 164 Address Mapping extension described in Section 5.2 of 165 [I-D.ietf-v6ops-siit-dc]. It provides virtual IPv4 connectivity for 166 application software or devices which require this to operate 167 correctly in an SIIT-DC environment. 169 Inbound IPv4 packets destined for an IPv4 Service Address is first 170 translated to IPv6 by an SIIT-DC Gateway. The resulting IPv6 packets 171 are subsequently forwarded to the ET handling the IPv6 Service 172 Address they are addressed to. The ET then translates them back to 173 IPv4 before forwarding them to the IPv4 application software or 174 device. In the other direction, the exact same translations happen, 175 only in reverse. This process provides end-to-end transparency of 176 IPv4 addresses. 178 An ET may handle an arbitrary number of IPv4 Service Addresses. All 179 the Static Address Mappings configured in the SIIT-DC Gateway(s) that 180 involve the IPv4 Service Addresses handled by an ET MUST be 181 duplicated in that ET's configuration. 183 An ET may be implemented in two distinct ways; as a software-based 184 service residing inside an otherwise IPv6-only host, or as a network- 185 based service that provides an isolated IPv4 network segment to which 186 devices which require IPv4 can connect. In both cases native IPv6 187 connectivity may be provided simultaneously with the virtual IPv4 188 connectivity. Thus, dual-stack connectivity is facilitated in case 189 the device or application software support it. 191 The choice between a host- or network-based ET is made on a per- 192 service or -device basis. An arbitrary number of each type of ET may 193 co-exist in an SIIT-DC architecture. 195 This section describes the different approaches and discusses which 196 approach fits best for the various use cases. 198 3.1. Host-Based Edge Translator 200 Overview of a Host-based Edge Translator 202 [IPv4 Internet] [IPv6 Internet] 203 | | 204 +--|----+ | 205 | [XLAT] | | 206 +--|----------------+ | 207 | | 208 [IPv6-only data centre network] 209 | 210 +--|-----------------+ 211 | | +----------------+| 212 | +--[ET/XLAT]--AF_INET Dual-stack || 213 | | | Application || 214 | \------------AF_INET6 Software || 215 | +----------------+| 216 +--------------------------------------+ 218 Figure 1 220 A host-based Edge Translator is typically implemented as a logical 221 software function that runs inside the operating system of a host or 222 server. It provides software applications running on the same host 223 with IPv4 connectivity. The IPv4 Service Address it handles is 224 considered local, allowing application software running on the same 225 host to use traditional IPv4-only API calls, e.g., to create AF_INET 226 sockets that listens for and accepts incoming connections to its IPv4 227 Service Address. An ET could accomplish this by creating an virtual 228 network adapter to which it assigns the IPv4 Service Address and 229 points a default IPv4 route. 231 As shown in Figure 1, if the application software supports dual-stack 232 operation, IPv6 clients will be able to communicate with it directly 233 using native IPv6. Neither the SIIT-DC Gateway nor the ET will 234 intercept this communication. Support for IPv6 in the application 235 software is however not a requirement; the application software may 236 opt not to establish any IPv6 sockets. Foregoing IPv6 in this manner 237 will simply preclude connectivity to the service from IPv6-only 238 clients; connectivity to the service from IPv4 clients (through the 239 SIIT-DC Gateway) will work in the exact same manner in both cases. 241 The ET requires a dedicated IPv6 Service Address for each IPv4 242 Service Address it has configured. The IPv6 network must forward 243 traffic to these IPv6 Service Addresses to the host, whose operating 244 system must in turn forward them to the ET. This document does not 245 explore the multitude of ways this could be accomplished, however 246 considering that the IPv6 protocol is designed for having multiple 247 addresses assigned to a single node, one particularly straight- 248 forward way would be to assign the ET's IPv6 Service Addresses as 249 secondary IPv6 addresses on the host itself so that it the upstream 250 router learns of their location using the IPv6 Neighbor Discovery 251 Protocol [RFC4861]. 253 3.2. Network-Based Edge Translator 255 Overview of a Basic Network-based Edge Translator 257 [IPv4 Internet] [IPv6 Internet] 258 | | 259 +--|----+ | 260 | [XLAT] | | 261 +--|----------------+ | 262 | | 263 [IPv6-only data centre network] 264 | 265 +--|----+ 266 | [XLAT] | 267 +--|--------+ 268 | 269 [Isolated IPv4-only network segment] 270 | 271 +--|------+ 272 | | +----------------+| 273 | \--AF_INET IPv4-only || 274 | | Application || 275 | | Software || 276 | +----------------+| 277 +---------------------------+ 279 Figure 2 281 A network-based Edge Translator performs the exact same as a host- 282 based ET does, only that instead of assigning the IPv4 Service 283 Addresses to an internal-only virtual network adapter, traffic 284 destined for them are forwarded onto a network segment to which hosts 285 that require IPv4 connectivity connect to. The ET also functions as 286 the default IPv4 router for the hosts on this network segment. 288 Each host on the IPv4 network segment must acquire and assign an IPv4 289 Service Address to a local network interface. This document does not 290 attempt to explore all the various methods by which this can be 291 accomplished, however one relatively straight-forward possibility 292 would be to ensure the IPv4 Service Address(es) can be enclosed in an 293 IPv4 prefix. The ET will then claim one address in this prefix for 294 itself (used as the IPv4 default router address), and could assign 295 the IPv4 Service Address(es) to the host(s) using DHCPv4. For 296 example, if the IPv4 Service Addresses are 192.0.2.26 and 192.0.2.27, 297 the ET would configure the address 192.0.2.25/29 on its IPv4-facing 298 interface and would add the two IPv4 Service Addresses to its DHCPv4 299 pool. 301 One disadvantage of this method is that IPv4 communication between 302 the IPv4 hosts and other services made available through SIIT-DC 303 using the method described in Section 6 becomes impossible, if those 304 other services are assigned IPv4 Service Addresses that also are 305 covered by the same IPv4 prefix (e.g., 192.0.2.28). This is because 306 the IPv4 nodes will mistakenly believe they have an on-link route to 307 the entire prefix, and attempt to resolve the addresses using ARP 308 (instead of forwarding them to the ET for translation to IPv6). This 309 problem could however be overcome by avoiding assigning IPv4 Service 310 Addresses which overlaps with an IPv4 prefix handled by an ET (at the 311 expense of wasting some potential IPv4 Service Addresses), or by 312 ensuring that they are only assigned to services which do not need to 313 communicate with the IPv4 host(s) behind the ET. 315 Another way to avoid the problem is to use a private unrouted IPv4 316 network that does not encompass the IPv4 Service Addresses as the 317 IPv4, and instead assign the IPv4 Service Addresses as secondary 318 addresses on the servers. The ET must then route each IPv4 Service 319 Address to its respective server using the server's private on-link 320 IPv4 address as the next-hop. This approach would ensure there are 321 no overlaps, but on the other hand it would preclude the use of 322 DHCPv4 for assigning the IPv4 Service Addresses, as well as create a 323 need to ensure that the IPv4 application software is selecting the 324 IPv4 Service Address (as opposed to its private on-link IPv4 address) 325 as its source address when initiating outbound connections. 327 The basic ET illustrated in Figure 2 establishes an IPv4-only network 328 segment behind itself. This is fine if the devices it provides IPv4 329 access have no support for IPv6 whatsoever; however if they are dual- 330 stack capable, it is would not be ideal to take away their IPv6 331 connectivity. While it is recommended to use a host-based ET in this 332 case, appropriate implementations of a host-based ET might not be 333 available for every device. If the application protocol does not 334 work correctly in a NAT environment, standard SIIT-DC cannot be used 335 either. Thus, a network-based ET is the only solution. 337 The operator could avoid breaking the hosts' IPv4 connectivity by 338 connecting the ET's IPv4 and IPv6 interfaces to the same network 339 segment, or by using a single dual-stacked interface instead. The 340 latter alternative is shown in Figure 3. This could be thought of as 341 an "ET on a stick". IPv6 traffic between the network and the hosts 342 will bypass the ET entirely. IPv4 traffic from the hosts will be 343 routed directly to the ET (because it's their default IPv4 router), 344 and translated to IPv6 before its being transmitted to the upstream 345 default IPv6 router. The ET could attract inbound traffic to its 346 IPv6 Service Addresses by responding to the upstream router's IPv6 347 Neighbor Discovery [RFC4861] messages for them. 349 A Network-based Edge Translator "on a stick" 351 [IPv4 Internet] [IPv6 Internet] 352 | | 353 +--|----+ | 354 | [XLAT] | | 355 +--|----------------+ | 356 | | 357 [IPv6-only data centre network] 358 | 359 | +--------+ 360 | | ____ | 361 | | / \ | 362 +==== [XLAT] | 363 | | \____/ | 364 | | | 365 | +------------+ 366 | 367 [Dual-stack network segment] 368 | 369 +--|------+ 370 | | +----------------+| 371 | +---AF_INET Dual-stack || 372 | | | Application || 373 | \--AF_INET6 Software || 374 | +----------------+| 375 +----------------------------+ 377 Figure 3 379 Yet another variation would be to implement the ET so that it 380 transparently passes IPv6 traffic between its downstream and upstream 381 network ports unmodified, e.g., using Layer-2 bridging. Packets sent 382 to its own IPv6 Service Addresses from the upstream network are 383 intercepted (e.g, by responding to IPv6 Neighbor Discovery [RFC4861] 384 messages for them) and routed through the translation function, and 385 forwarded out its downstream interface. The downstream network 386 segment is thus becomes dual-stacked. This model is shown in Figure 387 4. 389 A Transparent Network-based Edge Translator 391 [IPv4 Internet] [IPv6 Internet] 392 | | 393 +--|----+ | 394 | [XLAT] | | 395 +--|----------------+ | 396 | | 397 [IPv6-only data centre network] 398 | 399 +--|----+ 400 | |\_____________ | 401 | | \ | 402 | [Bridged IPv6] [XLAT] | 403 | | _____________/ | 404 | |/ | 405 +--|---------------------+ 406 | 407 [Dual-stack network segment] 408 | 409 +--|------+ 410 | | +----------------+| 411 | +---AF_INET Dual-stack || 412 | | | Application || 413 | \--AF_INET6 Software || 414 | +----------------+| 415 +----------------------------+ 417 Figure 4 419 4. Detailed Topology Example 421 The following figure shows how an application (that is presumably 422 incompatible with standard SIIT-DC) is being made available to the 423 IPv4 Internet on the IPv4 address 192.0.2.4. The application will be 424 able to know that this is its local address and thus be able to 425 provide correct references to it in application payload. 427 The figure also shows how the same application is available over IPv6 428 on its IPv6 Service Address 2001:db8:12:34::3. This is included in 429 order to illustrate how native IPv6 connectivity is not impacted by 430 the Edge Translator, and also to illustrate how the address assigned 431 to the ET (2001:db8:12:34::4) is separate from the primary IPv6 432 address of the server. It is however important to note that the 433 application in question does not have to be dual-stack capable at 434 all. IPv4-only applications would also be able to operate behind an 435 ET in the exact same manner. 437 Note that the figure below could be considered a more detailed view 438 of Customer A's FTP server from the example topology figure in 439 Appendix A of [I-D.ietf-v6ops-siit-dc]. Both figures intentionally 440 use the exact same example IP addresses and prefixes. 442 SIIT-DC Host Architecture with Edge Translation 444 +-------------------+ +----------------+ 445 | IPv6-capable user | | IPv4-only user | 446 | ================= | | ============== | 447 | | | | 448 +-<2001:db8::ab:cd>-+ +-<203.0.113.50>-+ 449 | | 450 (the IPv6 internet) (the IPv4 Internet) 451 | | 452 | +------------------<192.0.2.0/24>-+ 453 | | | 454 | | SIIT-DC Gateway | 455 | | =============== | 456 | | | 457 | | Translation Prefix: | 458 | | 2001:db8:46::/96 | 459 | | | 460 | | Static Address Mapping: | 461 | | 192.0.2.4 <=> 2001:db8:12:34::4 | 462 | | | 463 | +--------------<2001:db8:46::/96>-+ 464 | | 465 (the IPv6-only data centre network) 466 | | 467 +--<2001:db8:12:34::3>-------<2001:db8:12:34::4>---+ 468 | | | | 469 | | IPv6-only server | | 470 | | ================ | | 471 | | | | 472 | | +-------------<2001:db8:12:34::4>-+ | 473 | | | | | 474 | | | Edge Translator | | 475 | | | =============== | | 476 | | | | | 477 | | | Translation Prefix: | | 478 | | | 2001:db8:46::/96 | | 479 | | | | | 480 | | | Static Address Mapping: | | 481 | | | 192.0.2.4 <=> 2001:db8:12:34::4 | | 482 | | | | | 483 | | +---------------------<192.0.2.4>-+ | 484 | | | | 485 | +-[2001:db8:12:34::3]--------------[192.0.2.4]-+ | 486 | | AF_INET6 AF_INET | | 487 | | | | 488 | | Dual-stacked application | | 489 | | | | 490 | +----------------------------------------------+ | 491 +--------------------------------------------------+ 492 Figure 5 494 5. Deployment Considerations 496 5.1. IPv6 Path MTU 498 The IPv6 Path MTU between the Edge Translator and the SIIT-DC Gateway 499 will typically be larger than the default value defined in Section 4 500 of [RFC6145] (1280), as it will typically contained within a single 501 administrative domain. Therefore, it is recommended that the IPv6 502 Path MTU configured in the ET is raised accordingly. It is 503 RECOMMENDED that the ET and the SIIT-DC Gateway use identical 504 configured IPv6 Path MTU values. 506 5.2. IPv4 MTU 508 In order to avoid IPv6 fragmentation, an Edge Translator should 509 ensure that the IPv4 MTU used by applications or hosts is equal to 510 the configured IPv6 Path MTU - 20, so that an maximum-sized IPv4 511 packet can fit in an unfragmented IPv6 packet. This ensures that the 512 application may do its part in avoiding IP-level fragmentation from 513 occurring, e.g., by segmenting/fragmenting outbound packets at the 514 application layer, and advertising the maximum size its peer may use 515 for inbound packets (e.g., through the use of the TCP MSS option). 517 A host-based ET could accomplish this by configuring this MTU value 518 on the virtual network adapter, while a network-based ET could do so 519 by advertising the MTU to its downstream hosts using the DHCPv4 520 Interface MTU Option [RFC2132]. 522 5.3. IPv4 Identification Header 524 If the generation of IPv6 Atomic Fragments is disabled, the value of 525 the IPv4 Identification header will be lost during the translation. 526 Conversely, enabling the generation of IPv6 Atomic Fragments will 527 ensure that the IPv4 Identification Header will carried end-to-end. 528 Note that for this to work bi-directionally, IPv6 Atomic Fragment 529 generation must be enabled on both the SIIT-DC Gateway(s) and on the 530 Edge Translator. 532 Note that apart from certain diagnostic tools, there are few (if any) 533 application protocols that make use of the IPv4 Identification 534 header. Therefore, the loss of the IPv4 Identification value will 535 therefore generally not cause any problems. 537 IPv6 Atomic Fragments and their impact on the IPv4 Identification 538 header is further discussed in Section 4.8.2 of 539 [I-D.ietf-v6ops-siit-dc]. 541 6. Intra-DC IPv4 Communication 543 While SIIT-DC is primarily intended to facilitate communication 544 between IPv4-only nodes on the Internet and services hosted in an 545 IPv6-only network, it is also possible to facilitate communication 546 between an IPv4-only service or application running behind an Edge 547 Translator and another service/application made available over IPv4 548 through SIIT-DC. This other service/application may be a IPv6-only 549 service, or it may also be an IPv4-only service running behind 550 another ET. 552 Facilitating such communication requires that another Static Address 553 Mapping is configured in the ET (one for each service it wants to 554 communicate to). If there are two ETs involved, both of them must be 555 configured in the same fashion for bi-directional communication to 556 work. The following two subsections contain examples that 557 demonstrate how this may be set up. 559 Note that for the intra-DC communication described in this section, 560 the SIIT-DC Gateway is not involved at all. Therefore there is no 561 requirement that the Static Address Mappings in question are also 562 configured on the SIIT-DC Gateway. It is also possible to use 563 private [RFC1918] IPv4 addresses, in order to reduce the need for 564 publicly routable IPv4 addresses. However, if the IPv4-only 565 application(s) are also to be made available to the IPv4 Internet 566 through an SIIT-DC Gateway, it is highly recommended that the Static 567 Address Mappings configured in the ET match those configured in the 568 SIIT-DC Gateway. Otherwise one end up in the situation where a 569 service is reached using different IPv4 addresses depending on 570 whether one connects to it from the IPv4 Internet or from another 571 IPv4-only application residing in the same data centre. While it may 572 still work, the overall architecture gets significantly more complex. 574 Finally, if both services/applications support IPv6, it is highly 575 recommended that IPv6 is used for all internal communications. The 576 approach described in this section should only be used if one or both 577 of the services or applications only supports IPv4, making native 578 IPv6 communication impossible. 580 6.1. Between IPv4-Only and IPv6-Only Services 582 This section demonstrates how an IPv4-only service/application "A" 583 running behind an ET can communicate with an IPv6-only service "B". 585 Intra-DC IPv4-only to IPv6-only Overview 587 /--------------------------------------\ 588 | IPv6-only data centre network | 589 \-+----------------------------------+-/ 590 | | 591 | | 592 +--<2001:db8:6::>----------------+ +--<2001:db8:7::>----------------+ 593 | | | | | | 594 | | IPv6-only server A | | | IPv6-only server B | 595 | | ================== | | | ================== | 596 | | | | | | 597 |+-<2001:db8:6::>---------------+| |+-[2001:db8:7::]---------------+| 598 || || || AF_INET6 || 599 || Edge Translator A || || || 600 || ================= || || IPv6-only application B || 601 || || |+------------------------------+| 602 || Static Address Mappings: || +--------------------------------+ 603 || 192.0.2.6 <=> 2001:db8:6:: || 604 || 192.0.2.7 <=> 2001:db8:7:: || 605 || || 606 |+-<192.0.2.6>------------------+| 607 | | | 608 |+-[192.0.2.6]------------------+| 609 || AF_INET || 610 || || 611 || IPv4-only application A || 612 |+------------------------------+| 613 +--------------------------------+ 615 Figure 6 617 In this example, the IPv4-only application on server "A" is listening 618 on the IPv4 address 192.0.2.6, which is made available to the IPv6 619 network on the IPv6 address 2001:db8:6:: (by the ET). The IPv6-only 620 application on server "B" is only listening on the IPv6 address 621 2001:db8:7::, and has no knowledge of IPv4. 623 In order to facilitate communication between the two application, 624 another Static Address Mapping must be configured in the ET on server 625 "A". This provides an IPv4 address (192.0.2.7) that the IPv4-only 626 application can communicate with, which represents the IPv6 address 627 used by application "B" (2001:db8:7::). 629 The following figure shows the packet translations step by step, for 630 a packet sent by the IPv4-only application "A" to the IPv6-only 631 application "B". For traffic in the opposite direction, you may read 632 the figure from the bottom up and swap the Src/Dst addresses. 634 Intra-DC IPv4-only to IPv6-only Packet Flow 636 (IPv4-only application A) --\ 637 | | 638 Src 192.0.2.6 | 639 Dst 192.0.2.7 | Packet forwarding/translations 640 | | happening inside server A 641 V | 642 [SIIT-DC ET A] | 643 | --/ 644 | --\ 645 Src 2001:db8:6:: | Actual IPv6 packets routed 646 Dst 2001:db8:7:: | through the IPv6 network 647 | --/ 648 V 649 (IPv6-only application B) 651 Figure 7 653 6.2. Between Two IPv4-Only Services 655 This section demonstrates how an IPv4-only service/application "A" 656 running behind an ET can communicate with an IPv4-only service/ 657 application "B" running behind another ET. 659 Intra-DC IPv4-only to IPv6-only Overview 661 /--------------------------------------\ 662 | IPv6-only data centre network | 663 \-+----------------------------------+-/ 664 | | 665 | | 666 +--<2001:db8:8::>----------------+ +--<2001:db8:9::>----------------+ 667 | | | | | | 668 | | IPv6-only server A | | | IPv6-only server B | 669 | | ================== | | | ================== | 670 | | | | | | 671 |+-<2001:db8:8::>---------------+| |+-<2001:db8:9::>---------------+| 672 || || || || 673 || Edge Translator A || || Edge Translator B || 674 || ================= || || ================= || 675 || || || || 676 || Static Address Mappings: || || Static Address Mappings: || 677 || 192.0.2.8 <=> 2001:db8:8:: || || 192.0.2.8 <=> 2001:db8:8:: || 678 || 192.0.2.9 <=> 2001:db8:9:: || || 192.0.2.9 <=> 2001:db8:9:: || 679 || || || || 680 |+-<192.0.2.8>------------------+| |+-<192.0.2.9>------------------+| 681 | | | | | | 682 |+-[192.0.2.8]------------------+| |+-[192.0.2.9]------------------+| 683 || AF_INET || || AF_INET || 684 || || || || 685 || IPv4-only application A || || IPv4-only application B || 686 |+------------------------------+| |+------------------------------+| 687 +--------------------------------+ +--------------------------------+ 689 Figure 8 691 In this example, the IPv4-only application on server "A" is listening 692 on the IPv4 address 192.0.2.8, which is made available to the IPv6 693 network on the IPv6 address 2001:db8:8:: (by the ET). In the same 694 fashion, the IPv4-only application on server "B" is listening on the 695 IPv4 address 192.0.2.9 and is made available by its ET on the IPv6 696 address 2001:db8:9::. 698 In order to facilitate communication between the two application, a 699 second Static Address Mapping must be configured in the ET on both 700 servers. This provides each application with an IPv4 address that 701 represents the other application. Thus bi-directional communication 702 between the two applications can commence. 704 The following figure shows the packet translations step by step, for 705 a packet sent by the IPv4-only application "A" to the IPv4-only 706 application "B". For traffic in the opposite direction, you may read 707 the figure from the bottom up and swap the Src/Dst addresses. 709 Intra-DC IPv4-only to IPv4-only Packet Flow 711 (IPv4-only application A) --\ 712 | | 713 Src 192.0.2.8 | 714 Dst 192.0.2.9 | Packet forwarding/translations 715 | | happening inside server A 716 V | 717 [SIIT-DC ET A] | 718 | --/ 719 | --\ 720 Src 2001:db8:8:: | Actual IPv6 packets routed 721 Dst 2001:db8:9:: | through the IPv6 network 722 | --/ 723 V --\ 724 [SIIT-DC ET B] | 725 | | 726 Src 192.0.2.8 | Packet forwarding/translations 727 Dst 192.0.2.9 | happening inside server B 728 | | 729 V | 730 (IPv4-only application B) --/ 732 Figure 9 734 7. Acknowledgements 736 The author would like to especially thank the authors of 464XLAT 737 [RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne. 738 The architecture described by this document is merely an adaptation 739 of their work to a data centre environment, and could not have 740 happened without them. 742 The author would like also to thank the following individuals for 743 their contributions, suggestions, corrections, and criticisms: Fred 744 Baker, Tobias Brox, Ray Hunter, Shucheng LIU (Will), Andrew 745 Yourtchenko. 747 8. IANA Considerations 749 This draft makes no request of the IANA. The RFC Editor may remove 750 this section prior to publication. 752 9. Security Considerations 754 This section discusses security considerations specific to the use of 755 an Edge Translator. See the Security Considerations section in 756 [I-D.ietf-v6ops-siit-dc] for additional security considerations 757 applicable to the SIIT-DC architecture in general. 759 9.1. Address Spoofing 761 If the ET receives an IPv4 packet from the application from a 762 different source address than the one it has a Static Address Mapping 763 for, the both the source and destination addresses will be rewritten 764 according to [RFC6052]. After undergoing the reverse translation in 765 the SIIT-DC Gateway, the resulting IPv4 packet routed to the IPv4 766 network will have a spoofed IPv4 source address. The ET should 767 therefore ensure that ingress filtering (cf. BCP38 [RFC2827]) is used 768 on the ET's IPv4 interface, so that such packets are immediately 769 discarded. 771 If the ET receives an IPv6 packet with both the source and 772 destination address equal to the one it has a Static Address Mapping 773 for, the resulting packet would appear to the application as locally 774 generated, as both the source address and the destination address 775 will be the same address as the one configured on the virtual IPv4 776 interface. This could trick the application into thinking this 777 packet came from a trusted source, and give elevated privileges 778 accordingly. To prevent this, the ET should discard any received 779 IPv6 packets that have a source address that is equal either to 780 either the IPv4 (after undergoing [RFC6052] translation) or the IPv6 781 address in the Static Address Mapping. 783 10. References 785 10.1. Normative References 787 [I-D.ietf-v6ops-siit-dc] 788 tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 789 Data Centre Environments", draft-ietf-v6ops-siit-dc-00 790 (work in progress), December 2014. 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, March 1997. 795 10.2. Informative References 797 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 798 E. Lear, "Address Allocation for Private Internets", BCP 799 5, RFC 1918, February 1996. 801 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 802 Extensions", RFC 2132, March 1997. 804 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 805 Defeating Denial of Service Attacks which employ IP Source 806 Address Spoofing", BCP 38, RFC 2827, May 2000. 808 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 809 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 810 September 2007. 812 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 813 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 814 October 2010. 816 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 817 Algorithm", RFC 6145, April 2011. 819 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 820 Combination of Stateful and Stateless Translation", RFC 821 6877, April 2013. 823 Author's Address 825 Tore Anderson 826 Redpill Linpro 827 Vitaminveien 1A 828 0485 Oslo 829 Norway 831 Phone: +47 959 31 212 832 Email: tore@redpill-linpro.com 833 URI: http://www.redpill-linpro.com