idnits 2.17.00 (12 Aug 2021) /tmp/idnits62822/draft-ietf-v6ops-siit-dc-2xlat-02.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 (October 12, 2015) is 2406 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-v6ops-siit-dc has been published as RFC 7755 == Outdated reference: draft-ietf-v6ops-siit-eam has been published as RFC 7757 -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 0 errors (**), 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: Informational S. Steffann 5 Expires: April 14, 2016 S.J.M. Steffann Consultancy 6 October 12, 2015 8 SIIT-DC: Dual Translation Mode 9 draft-ietf-v6ops-siit-dc-2xlat-02 11 Abstract 13 This document describes an extension of the Stateless IP/ICMP 14 Translation for IPv6 Internet Data Centre Environments architecture 15 (SIIT-DC), which allows applications, protocols, or nodes that are 16 incompatible with IPv6, and/or Network Address Translation to operate 17 correctly in an SIIT-DC environment. This is accomplished by 18 introducing a new component called an SIIT-DC Edge Relay, which 19 reverses the translations made by an SIIT-DC Border Relay. The 20 application and/or node is thus provided with seemingly native IPv4 21 connectivity that provides end-to-end address transparency. 23 The reader is expected to be familiar with the SIIT-DC architecture 24 described in I-D.ietf-v6ops-siit-dc. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 14, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 4 63 3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 5 64 3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 7 65 3.2.1. Edge Router "On A Stick" . . . . . . . . . . . . . . 8 66 3.2.2. Edge Router that Bridges IPv6 Packets . . . . . . . . 9 67 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 68 4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9 69 4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10 71 5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10 72 5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 10 73 5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 11 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 9.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 15 81 A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 16 82 A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where 88 IPv4-only users can access IPv6-only services through a stateless 89 translator called an SIIT-DC Border Relay (BR). This approach has 90 certain limitations, however. In particular, the following cases 91 will work poorly or not at all: 93 o Application protocols that do not support NAT (i.e., the lack of 94 end-to-end transparency of IP addresses). 96 o Nodes that cannot connect to IPv6 networks at all, or that can 97 only connect such networks if they also provide IPv4 connectivity 98 (i.e., dual-stacked networks). 100 o Application software which makes use of legacy IPv4-only APIs, or 101 otherwise makes assumptions that IPv4 connectivity is available. 103 By extending the SIIT-DC architecture with a new component called an 104 Edge Relay (ER), all of the above can be made to work correctly in an 105 otherwise IPv6-only network environment using SIIT-DC. 107 The purpose of the ER is to reverse the IPv4-to-IPv6 packet 108 translations previously done by the BR for traffic arriving from IPv4 109 clients and forward this as "native" IPv4 to the node or application. 110 In the reverse direction, IPv4 packets transmitted by the node or 111 application are intercepted by the ER, which translates them to IPv6 112 before they are forwarded to the BR, which in turn will reverse the 113 translations and forward them to the IPv4 client. The node or 114 application is thus provided with "virtual" IPv4 Internet 115 connectivity that retains end-to-end transparency for the IPv4 116 addresses. 118 2. Terminology 120 This document makes use of the following terms: 122 SIIT-DC Border Relay (BR) 123 A device or a logical function that performs stateless protocol 124 translation between IPv4 and IPv6. It MUST do so in accordance 125 with [RFC6145] and [I-D.ietf-v6ops-siit-eam]. 127 SIIT-DC Edge Relay (ER) 128 A device or logical function that provides "native" IPv4 129 connectivity to IPv4-only devices or application software. It is 130 very similar in function to a BR, but is typically located close 131 to the IPv4-only component(s) it is supporting rather than on the 132 IDC's outer network border. An ER may be either Node-Based 133 (Section 3.1) or Network-Based (Section 3.2). 135 IPv4 Service Address 136 An IPv4 address representing a node or service located in an IPv6 137 network. It is coupled with an IPv6 Service Address using an EAM. 138 Packets sent to this address is translated to IPv6 by the BR, and 139 possibly back to IPv4 by an ER, before reaching the node or 140 service. 142 IPv6 Service Address 143 An IPv6 address assigned to an application, node, or service; 144 either directly or indirectly (through an ER). It is coupled with 145 an IPv4 Service Address using an EAM. IPv4-only clients 146 communicates with the IPv6 Service Address through SIIT-DC. 148 Explicit Address Mapping (EAM) 149 A bi-directional coupling between an IPv4 Service Address and an 150 IPv6 Service Address configured in a BR or ER. When translating 151 between IPv4 and IPv6, the BR/ER changes the address fields in the 152 translated packet's IP header according to any matching EAM. The 153 EAM algorithm is specified in [I-D.ietf-v6ops-siit-eam]. 155 Translation Prefix 156 An IPv6 prefix into which the entire IPv4 address space is mapped, 157 according to the algorithm in [RFC6052]. The Translation Prefix 158 is routed to the BR's IPv6 interface. When translating between 159 IPv4 and IPv6, an BR/ER will insert/remove the Translation Prefix 160 into/from the address fields in the translated packet's IP header, 161 unless an EAM exists for the IP address that is being translated. 163 IPv4-converted IPv6 addresses 164 As defined in Section 1.3 of [RFC6052]. 166 IDC 167 Short for "Internet Data Centre"; a data centre whose main purpose 168 is to deliver services to the public Internet, the use case SIIT- 169 DC is primarily targeted at. IDCs are typically operated by 170 Internet Content Providers or Managed Services Providers. 172 SIIT 173 The Stateless IP/ICMP Translation algorithm, as specified in 174 [RFC6145]. 176 XLAT 177 Short for "Translation". Used in figures to indicate where a BR/ 178 ER uses SIIT [RFC6145] to translate IPv4 packets to IPv6 and vice 179 versa. 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 3. Edge Relay Description 186 An Edge Relay (ER) is at its core an implementation of the Stateless 187 IP/ICMP Translation algorithm [RFC6145] that supports Explicit 188 Address Mappings [I-D.ietf-v6ops-siit-eam]. It provides virtual IPv4 189 connectivity for nodes or applications which require this to operate 190 correctly in an SIIT-DC environment. 192 Packets from the IPv4 Internet destined for an IPv4 Service Address 193 is first translated to IPv6 by a BR. The resulting IPv6 packets are 194 subsequently forwarded to the ER that owns the IPv6 Service Address 195 the translated packets are addressed to. The ER then translates them 196 back to IPv4 before forwarding them to the IPv4 application or node. 197 In the other direction, the exact same translations happen, only in 198 reverse. This process provides end-to-end transparency of IPv4 199 addresses. 201 An ER may handle an arbitrary number of IPv4/IPv6 Service Addresses. 202 All the EAMs configured in the BR that involve the IPv4/IPv6 Service 203 Addresses handled by an ER MUST also be present in the ER's 204 configuration. 206 An ER may be implemented in two distinct ways; as a software-based 207 service residing inside an otherwise IPv6-only node, or as a network- 208 based service that provides an isolated IPv4 network segment to which 209 nodes that require IPv4 can connect. In both cases native IPv6 210 connectivity may be provided simultaneously with the virtual IPv4 211 connectivity. Thus, dual-stack connectivity is facilitated in case 212 the node or application support it. 214 The choice between a node- or network-based ER is made on a per- 215 service or per-node basis. An arbitrary number of each type of ER 216 may co-exist in an SIIT-DC architecture. 218 This section describes the different approaches and discusses which 219 approach fits best for the various use cases. 221 3.1. Node-Based Edge Relay 223 A Node-based Edge Relay 225 [IPv4 Internet] [IPv6 Internet] 226 | | 227 +-----|-----+ | 228 | (BR/XLAT) | | 229 +-----|-----+ | 230 | | +---------------+ 231 [IPv6-only IDC network] | +----------------+| 232 | | /--(ER/XLAT)--AF_INET Dual-stack || 233 \-------------------------+ | Application || 234 | \------------AF_INET6 Software || 235 | +----------------+| 236 +--------------------------------------+ 238 Figure 1 240 A node-based ER is typically implemented as a logical software 241 function that runs inside the operating system of an IPv6 node. It 242 provides applications running on the same node with IPv4 243 connectivity. Its IPv4 Service Address SHOULD be considered a 244 regular local address that allows application running on the same 245 node to use it with IPv4-only API calls, e.g., to create AF_INET 246 sockets that listen for and accept incoming connections to its IPv4 247 Service Address. An ER may accomplish this by creating a virtual 248 network adapter to which it assigns the IPv4 Service Address and 249 points a default IPv4 route. This approach is similar to the "Bump- 250 in-the-Stack" approach discussed in [RFC6535], however it does not 251 include an Extension Name Resolver. 253 As shown in Figure 1, if the application supports dual-stack 254 operation, IPv6 clients will be able to communicate with it directly 255 using native IPv6. Neither the BR nor the ER will intercept this 256 communication. Support for IPv6 in the application is however not a 257 requirement; the application may opt not to establish any IPv6 258 sockets. Foregoing IPv6 in this manner will simply preclude 259 connectivity to the service from IPv6-only clients; connectivity to 260 the service from IPv4 clients (through the BR) will continue work in 261 the same way. 263 The ER requires a dedicated IPv6 Service Address for each IPv4 264 Service Address it has configured. The IPv6 network MUST forward 265 traffic to these IPv6 Service Addresses to the node, whose operating 266 system MUST in turn forward them to the ER. This document does not 267 attempt to fully explore the multitude of ways this could be 268 accomplished, however considering that the IPv6 protocol is designed 269 for having multiple addresses assigned to a single node, one 270 particularly straight-forward way would be to assign the ER's IPv6 271 Service Addresses as secondary IPv6 addresses on the node itself so 272 that it the upstream router learns of their location using the IPv6 273 Neighbor Discovery Protocol [RFC4861]. 275 3.2. Network-Based Edge Relay 277 A Basic Network-based Edge Relay 279 [IPv4 Internet] [IPv6 Internet] 280 | | 281 +-----|-----+ | 282 | (BR/XLAT) | | 283 +-----|-----+ | 284 | | 285 [IPv6-only IDC network] +----+ 286 | | +----------------+| 287 +-----|-----+ [v4-only] | | IPv4-only || 288 | (ER/XLAT)-----[network]--------AF_INET Application || 289 +-----------+ [segment] | | Software || 290 | +----------------+| 291 +---------------------------+ 293 Figure 2 295 A network-based ER performs the exact same as a node-based ER does, 296 only that instead of assigning the IPv4 Service Addresses to an 297 internal-only virtual network adapter, traffic destined for them are 298 forwarded onto a network segment to which nodes that require IPv4 299 connectivity connect to. The ER also functions as the default IPv4 300 router for the nodes on this network segment. 302 Each node on the IPv4 network segment MUST acquire and assign an IPv4 303 Service Address to a local network interface. While this document 304 does not attempt to explore all the various methods by which this 305 could be accomplished, some examples are provided in Appendix A. 307 The basic ER illustrated in Figure 2 establishes an IPv4-only network 308 segment between itself and the IPv4-only nodes it serves. This is 309 fine if the nodes it provides IPv4 access have no support for IPv6 310 whatsoever; however if they are dual-stack capable, it is would not 311 be ideal to take away their IPv6 connectivity in this manner. While 312 it is RECOMMENDED to use a node-based ER in this case, appropriate 313 implementations of a node-based ER might not be available for every 314 node. If the application protocol in question does not work 315 correctly in a NAT environment, standard SIIT-DC cannot be used 316 either, which leaves a network-based ER is the only remaining 317 solution. The following subsections contains examples on how the ER 318 could be implemented in a way that provides IPv6 connectivity for 319 dual-stack capable nodes. 321 3.2.1. Edge Router "On A Stick" 323 A Network-based Edge Relay "On A Stick" 325 [IPv4 Internet] [IPv6 Internet] 326 | | 327 +-----|-----+ | 328 | (BR/XLAT) | | 329 +-----|-----+ | 330 | | 331 [IPv6-only IDC network] 332 | 333 | +-------------+ 334 | | _IPv6_ | 335 | | / \ | 336 +==== (ER/XLAT) | 337 | | \_ _/ | 338 | | IPv4 | +----+ 339 | +-------------+ | +----------------+| 340 | | /---AF_INET Dual-stack || 341 [Dual-stack network segment]----< | Application || 342 | \--AF_INET6 Software || 343 | +----------------+| 344 +----------------------------+ 346 Figure 3 348 The ER "On A Stick" approach illustrated in Figure 3 ensures that the 349 dual-stack capable node retains native IPv6 connectivity by 350 connecting the ER's IPv4 and IPv6 interfaces to the same network 351 segment, alternatively by using a single dual-stacked interface. 352 Native IPv6 traffic between the IDC network and the node bypasses the 353 ER entirely, while IPv4 traffic from the node will be routed directly 354 to the ER (because it acts as its default IPv4 router), where it is 355 translated to IPv6 before being transmitted to the upstream default 356 IPv6 router. The ER could attract inbound traffic to the IPv6 357 Service Addresses by responding to the upstream router's IPv6 358 Neighbor Discovery [RFC4861] messages for them. 360 3.2.2. Edge Router that Bridges IPv6 Packets 362 A Network-based Edge Relay containing an IPv6 Bridge 364 [IPv4 Internet] [IPv6 Internet] 365 | | 366 +-----|-----+ | 367 | (BR/XLAT) | | 368 +-----|-----+ | 369 | | 370 [IPv6-only IDC network] 371 | 372 +-----------|--------------+ 373 | ____/ \_IPv6_ | 374 | / \ | 375 | (IPv6 Bridge) (ER/XLAT) | 376 | \____ _ _/ | 377 | \ / IPv4 | +----+ 378 +-----------|--------------+ | +----------------+| 379 | | /---AF_INET Dual-stack || 380 [Dual-stack network segment]----< | Application || 381 | \--AF_INET6 Software || 382 | +----------------+| 383 +----------------------------+ 385 Figure 4 387 The ER illustrated in Figure 4 will transparently bridge IPv6 frames 388 between its upstream and downstream interfaces. IPv6 packets 389 addressed the ER's own IPv6 Service Addresses from the upstream IDC 390 network are intercepted (e.g., by responding to IPv6 Neighbor 391 Discovery [RFC4861] messages for them) and routed through the 392 translation function before being forwarded out its downstream 393 interface as IPv4 packets. The downstream network segment thus 394 becomes dual-stacked. 396 4. Deployment Considerations 398 4.1. IPv6 Path MTU 400 The IPv6 Path MTU between the ER and the BR will typically be larger 401 than the default value defined in Section 4 of [RFC6145] (1280 402 bytes), as it will typically contained within a single administrative 403 domain. Therefore, it is RECOMMENDED that the IPv6 Path MTU 404 configured in the ER is raised accordingly. It is RECOMMENDED that 405 the ER and the BR use identical configured IPv6 Path MTU values. 407 4.2. IPv4 MTU 409 In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the 410 IPv4 MTU used by applications or nodes is equal to the configured 411 IPv6 Path MTU - 20, so that an maximum-sized IPv4 packet can fit in 412 an unfragmented IPv6 packet. This ensures that the application may 413 do its part in avoiding IP-level fragmentation from occurring, e.g., 414 by segmenting/fragmenting outbound packets at the application layer, 415 and advertising the maximum size its peer may use for inbound packets 416 (e.g., through the use of the TCP MSS option). 418 A node-based ER could accomplish this by configuring this MTU value 419 on the virtual network adapter, while a network-based ER could do so 420 by advertising the MTU to its downstream nodes using the DHCPv4 421 Interface MTU Option [RFC2132]. 423 4.3. IPv4 Identification Header 425 If the generation of IPv6 Atomic Fragments is disabled, the value of 426 the IPv4 Identification header will be lost during the translation. 427 Conversely, enabling the generation of IPv6 Atomic Fragments will 428 ensure that the IPv4 Identification Header will carried end-to-end. 429 Note that for this to work bi-directionally, IPv6 Atomic Fragment 430 generation MUST be enabled on both the BR and the ER. 432 Apart from certain diagnostic tools, there are few (if any) 433 application protocols that make use of the IPv4 Identification 434 header. Therefore, the loss of the IPv4 Identification value will 435 therefore generally not cause any problems. 437 IPv6 Atomic Fragments and their impact on the IPv4 Identification 438 header is further discussed in Section 4.9.2 of 439 [I-D.ietf-v6ops-siit-dc]. 441 5. Intra-IDC IPv4 Communication 443 Although SIIT-DC is primarily intended to facilitate communication 444 between IPv4-only nodes on the Internet and services located in an 445 IPv6-only IDC network, an IPv4-only node or application located 446 behind an ER might need to communicate with other nodes or services 447 in the IDC. The IPv4-only node or application will need to so 448 through the ER, as it will typically be incapable to contact IPv6 449 destinations directly. The following subsections discusses various 450 methods on how to facilitate such communication. 452 5.1. Hairpinning by the SIIT-DC Border Relay 453 If the BR supports hairpinning as described in Section 4.2 of 454 [I-D.ietf-v6ops-siit-eam], the easiest solution is to make the target 455 service available through SIIT-DC in the normal way, that is, by 456 provisioning an EAM to the BR that assigns an IPv4 Service Address 457 with the target service's IPv6 Service Address. 459 This allows the IPv4-only node or application to transmit packets 460 destined for the target service's IPv4 Service Address, which the ER 461 will then translate to a corresponding IPv4-converted IPv6 address by 462 inserting the Translation Prefix [RFC6052]. When this IPv6 packet 463 reaches the BR, it will be hairpinned and transmitted back to the 464 target service's IPv6 Service Address (where it could possibly pass 465 through another ER before reaching the target service). Return 466 traffic from the target service will be hairpinned in the same 467 fashion. 469 Hairpinned IPv4-IPv4 packet flow 471 +-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]-------------+ 472 | SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: | 473 | DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:46::192.0.2.2 |---\ 474 +---------------+ +----------------------------+ | 475 (XLAT#2) 476 +-[Pkt#4: IPv4]-+ +--[Pkt#3: IPv6]-------------+ ( @ BR ) 477 | SRC 192.0.2.1 | (XLAT#3) | SRC 2001:db8:46::192.0.2.1 | | 478 | DST 192.0.2.2 |<--(@ ER B)--| DST 2001:db8:b:: |<--/ 479 +---------------+ +----------------------------+ 481 Figure 5 483 Figure 5 illustrates the flow of a hairpinned packet sent from the 484 IPv4-only node/app behind ER A towards an IPv6-only node/app behind 485 ER B. ER A is configured with the EAM {192.0.2.1,2001:db8:a::}, ER B 486 with {192.0.2.2,2001:db8:b::}. The BR is configured with both EAMs, 487 and supports hairpinning. Note that if the target service had not 488 been located behind an ER, the third and final translation (XLAT#3) 489 would not have happened, i.e., the target service/node would have 490 received and responded to packet #3 directly. 492 If the IPv4-only nodes/services do not need connectivity with the 493 public IPv4 Internet, private IPv4 addresses [RFC1918] could be used 494 as their IPv4 Service Addresses in order to conserve the IDC 495 operator's pool of public IPv4 addresses. 497 5.2. Additional EAMs Configured in Edge Relay 499 If the BR does not support hairpinning, or if the hairpinning 500 solution is not desired for some other reason, intra-IDC IPv4 traffic 501 may be facilitated by configuring additional EAMs on the ER for each 502 service the IPv4-only node or application needs to communicate with. 503 This makes the IPv6 traffic between the ER and the target service's 504 IPv6 Service Address follow the direct path through the IPv6 network. 505 The traffic does not pass the BR, which means that this solution 506 might yield better latency than the hairpinning approach. 508 The additional EAM configured in the ER consists of the target's IPv6 509 Service Address and an IPv4 Service Address. The IPv4-only node or 510 application will contact the target's assigned IPv4 Service Address 511 using its own IPv4 Service Address as the source. The ER will then 512 proceed to translate this to an IPv6 packet with the local 513 application/node's own IPv6 Service Address as source and the target 514 service's IPv6 Service Address as the destination, and forward this 515 to the IPv6 network. Replies from the target service will undergo 516 these translations in reverse. 518 If the target service is also located behind another ER, that other 519 ER MUST also be provisioned with an additional EAM that contains the 520 origin IPv4-only application/node's IPv4 and IPv6 Service Addresses. 521 Otherwise, the target service's ER will be unable to translate the 522 source address of the incoming packets. 524 Non-hairpinned IPv4-IPv4 packet flow 526 +-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]---+ 527 | SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: | 528 | DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:b:: | 529 +---------------+ +------------------+ 530 | 531 +-[Pkt#3: IPv4]-+ | 532 | SRC 192.0.2.1 | (XLAT#2) | 533 | DST 192.0.2.2 |<-------(@ ER B)------/ 534 +---------------+ 536 Figure 6 538 Figure 6 illustrates the flow of a packet carrying intra-IDC IPv4 539 traffic between two IPv4-only nodes/applications that are both 540 located behind ERs. Both ER A and ER B are configured with two EAMs: 541 {192.0.2.1,2001:db8:a::} and {192.0.2.2,2001:db8:b::}. The packet 542 will follow the regular routing path through the IPv6 IDC network; 543 the BR is not involved and the packet will not be hairpinned. 545 The above approach is not mutually exclusive with the hairpinning 546 approach described in Section 5.1: If both EAMs above are also 547 configured on the BR, both 192.0.2.1 and 192.0.2.2 would be reachable 548 from other IPv4-only services/nodes using the hairpinning approach. 549 They would also be reachable from the IPv4 Internet. 551 Note that if the target service in this example was not located 552 behind an ER, but instead was a native IPv6 service listening on 553 2001:db8:b::, the second translation step in Figure 6 would not 554 occur; the target service would receive and respond to packet #2 555 directly. 557 As with the hairpinning approach, if the IPv4-only nodes/services do 558 not need connectivity to/from the public IPv4 Internet, private IPv4 559 addresses [RFC1918] could be used as their IPv4 Service Addresses. 560 Alternatively, in the case where the target service is on native 561 IPv6, the target's assigned IPv4 Service Address has only local 562 significance behind the ER. It could therefore be assigned from the 563 IPv4 Service Continuity Prefix [RFC7335]. 565 6. Acknowledgements 567 The author would like to especially thank the authors of 464XLAT 568 [RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne. 569 The architecture described by this document is merely an adaptation 570 of their work to a data centre environment, and could not have 571 happened without them. 573 The author would like also to thank the following individuals for 574 their contributions, suggestions, corrections, and criticisms: Fred 575 Baker, Tobias Brox, Olafur Gudmundsson, Christer Holmberg, Ray 576 Hunter, Shucheng LIU (Will), Andrew Yourtchenko. 578 7. IANA Considerations 580 This draft makes no request of the IANA. 582 8. Security Considerations 584 This section discusses security considerations specific to the use of 585 an ER. See the Security Considerations section in 586 [I-D.ietf-v6ops-siit-dc] for security considerations applicable to 587 the SIIT-DC architecture in general. 589 If the ER receives an IPv4 packet from the application/node from a 590 source address it does not have an EAM for, both the source and 591 destination addresses will be rewritten according to [RFC6052]. 592 After undergoing the reverse translation in the BR, the resulting 593 IPv4 packet routed to the IPv4 network will have a spoofed IPv4 594 source address. The ER SHOULD therefore ensure that ingress 595 filtering [RFC2827] is used on the ER's IPv4 interface, so that such 596 packets are immediately discarded. 598 If the ER receives an IPv6 packet with both the source and 599 destination address equal to one of its local IPv6 Service Addresses, 600 the resulting packet would appear to the IPv4-only application/node 601 as locally generated, as both the source address and the destination 602 address will be the same address. This could trick the application 603 into believing the packet came from a trusted source (itself). To 604 prevent this, the ER SHOULD discard any received IPv6 packets that 605 have a source address that is either 1) equal to any of its local 606 IPv6 Service Addresses, or 2) after translation from IPv6 to IPv4, 607 equal to any of its local IPv4 Service Addresses. 609 9. References 611 9.1. Normative References 613 [I-D.ietf-v6ops-siit-dc] 614 Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for 615 IPv6 Data Centre Environments", draft-ietf-v6ops-siit- 616 dc-02 (work in progress), August 2015. 618 [I-D.ietf-v6ops-siit-eam] 619 Anderson, T. and A. Leiva, "Explicit Address Mappings for 620 Stateless IP/ICMP Translation", draft-ietf-v6ops-siit- 621 eam-01 (work in progress), June 2015. 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 625 RFC2119, March 1997, 626 . 628 9.2. Informative References 630 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 631 Converting Network Protocol Addresses to 48.bit Ethernet 632 Address for Transmission on Ethernet Hardware", STD 37, 633 RFC 826, DOI 10.17487/RFC0826, November 1982, 634 . 636 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 637 and E. Lear, "Address Allocation for Private Internets", 638 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 639 . 641 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 642 2131, DOI 10.17487/RFC2131, March 1997, 643 . 645 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 646 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 647 . 649 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 650 Defeating Denial of Service Attacks which employ IP Source 651 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 652 May 2000, . 654 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 655 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 656 DOI 10.17487/RFC4861, September 2007, 657 . 659 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 660 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 661 DOI 10.17487/RFC6052, October 2010, 662 . 664 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 665 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 666 . 668 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 669 Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/ 670 RFC6535, February 2012, 671 . 673 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 674 "Default Address Selection for Internet Protocol Version 6 675 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 676 . 678 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 679 Combination of Stateful and Stateless Translation", RFC 680 6877, DOI 10.17487/RFC6877, April 2013, 681 . 683 [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, DOI 684 10.17487/RFC7335, August 2014, 685 . 687 Appendix A. Examples: Network-Based IPv4 Connectivity 688 A.1. Subnet with IPv4 Service Addresses 690 One relatively straight-forward way to provide IPv4 connectivity 691 between the ER and the IPv4 node(s) it serves is to ensure the IPv4 692 Service Address(es) can be enclosed within a larger IPv4 prefix. The 693 ER may then claim one address in this prefix for itself, and use it 694 to provide an IPv4 default router address. The ER may then proceed 695 to assign the IPv4 Service Address(es) to its downstream node(s) 696 using DHCPv4 [RFC2131]. For example, if the IPv4 Service Addresses 697 are 192.0.2.26 and 192.0.2.27, the ER would configure the address 698 192.0.2.25/29 on its IPv4-facing interface and would add the two IPv4 699 Service Addresses to its DHCPv4 pool. 701 One disadvantage of this method is that IPv4 communication between 702 the IPv4 node(s) behind the ER and other services made available 703 through SIIT-DC becomes impossible, if those other services are 704 assigned IPv4 Service Addresses that also are covered by the same 705 IPv4 prefix (e.g., 192.0.2.28). This happens because the IPv4 nodes 706 will mistakenly believe they have an on-link route to the entire 707 prefix, and attempt to resolve the addresses using ARP [RFC0826], 708 instead of sending them to the ER for translation to IPv6. This 709 problem could however be overcome by avoiding assigning IPv4 Service 710 Addresses which overlaps with an IPv4 prefix handled by an ER (at the 711 expense of wasting some potential IPv4 Service Addresses), or by 712 ensuring that the overlapping IPv6 Service Addresses are only 713 assigned to services which do not need to communicate with the IPv4 714 node(s) behind the ER. A third way to avoid this problem is 715 discussed in Appendix A.2. 717 A.2. Subnet with Unrouted IPv4 Addresses 719 In order to avoid the problem discussed in Appendix A.1, a private 720 unrouted IPv4 network that does not encompass the IPv4 Service 721 Address(es) could be used to provide connectivity between the ER and 722 the IPv4-only node(s) it serves. An IPv4-only node must then assign 723 its IPv4 Service Address as secondary local address, while the ER 724 routes each of the IPv4 Service Addresses to its assigned node using 725 that node's private on-link IPv4 address as the next-hop. This 726 approach would ensure there are no overlaps with IPv4 Service 727 addresses elsewhere in the infrastructure, but on the other hand it 728 would preclude the use of DHCPv4 [RFC2131] for assigning the IPv4 729 Service Addresses. 731 This approach creates a need to ensure that the IPv4 application is 732 selecting the IPv4 Service Address (as opposed to its private on-link 733 IPv4 address) as its source address when initiating outbound 734 connections. This could be accomplished by altering the Default 735 Address Selection Policy Table [RFC6724] on the IPv4 node. 737 Authors' Addresses 739 Tore Anderson 740 Redpill Linpro 741 Vitaminveien 1A 742 0485 Oslo 743 Norway 745 Phone: +47 959 31 212 746 Email: tore@redpill-linpro.com 747 URI: http://www.redpill-linpro.com 749 Sander Steffann 750 S.J.M. Steffann Consultancy 751 Tienwoningenweg 46 752 Apeldoorn, Gelderland 7312 DN 753 The Netherlands 755 Email: sander@steffann.nl