idnits 2.17.00 (12 Aug 2021) /tmp/idnits17512/draft-ietf-v6ops-siit-eam-03.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-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2015) is 2398 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: draft-ietf-v6ops-siit-dc has been published as RFC 7755 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 Updates: 6145 (if approved) A. Leiva Popper 5 Intended status: Standards Track NIC Mexico 6 Expires: April 22, 2016 October 20, 2015 8 Explicit Address Mappings for Stateless IP/ICMP Translation 9 draft-ietf-v6ops-siit-eam-03 11 Abstract 13 This document extends the Stateless IP/ICMP Translation Algorithm 14 (SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally 15 updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP 16 translation between arbitrary (non-IPv4-translatable) IPv6 endpoints 17 and IPv4. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 22, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Explicit Address Mapping Algorithm . . . . . . . . . . . . . 5 57 3.1. Explicit Address Mapping Table . . . . . . . . . . . . . 5 58 3.2. Explicit Address Mapping Specification . . . . . . . . . 6 59 3.3. IP Address Translation Procedure . . . . . . . . . . . . 7 60 3.3.1. Address Translation Steps: IPv4 to IPv6 . . . . . . . 7 61 3.3.2. Address Translation Steps: IPv6 to IPv4 . . . . . . . 7 62 4. Hairpinning of IPv6 Traffic . . . . . . . . . . . . . . . . . 8 63 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Recommendation . . . . . . . . . . . . . . . . . . . . . 9 65 4.2.1. Simple Hairpinning Support . . . . . . . . . . . . . 9 66 4.2.2. Intrinsic Hairpinning Support . . . . . . . . . . . . 9 67 5. Overlapping Explicit Address Mappings . . . . . . . . . . . . 10 68 6. Lack of Checksum Neutrality . . . . . . . . . . . . . . . . . 11 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 10.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 13 76 A.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 A.2. IVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 A.3. SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 Appendix B. Example IP Address Translations . . . . . . . . . . 15 80 B.1. Hairpinning Examples . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 The Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145] 86 specifies that when translating IPv4 addresses to IPv6 and vice 87 versa, all addresses must be translated using the algorithm specified 88 in [RFC6052]. This document specifies an alternative to the 90 [RFC6052] algorithm, where IP addresses are translated according to a 91 table of Explicit Address Mappings configured on the stateless 92 translator. This removes the previous constraint that IPv6 nodes 93 that communicate with IPv4 nodes through SIIT must be configured with 94 IPv4-translatable IPv6 addresses. 96 Translation using the Explicit Address Mapping Table does not replace 97 [RFC6052]. For most use cases, it is expected that both algorithms 98 are used in concert. The Explicit Address Mapping algorithm is used 99 only when a mapping matching the address to be translated exists. If 100 no matching mapping exists, the [RFC6052] algorithm will be used 101 instead. Thus, when translating an individual IP packet, an SIIT 102 implementation might translate one of the two IP address fields 103 according to an EAM, while the other IP address field is translated 104 according to [RFC6052]. 106 1.1. Terminology 108 This document makes use of the following terms: 110 EAM 111 An Explicit Address Mapping, as specified in Section 3.2. 113 EAMT 114 The Explicit Address Mapping Table, as specified in Section 3.1. 116 Inner (header or address) 117 Refers to an IP header located inside the payload of an ICMP error 118 packet, or to an IP address within that header. Compare "Outer". 120 Outer (header or address) 121 Refers to the first IP header in a packet, or to an IP address 122 within that header. In other words, an IP header or address that 123 is NOT "Inner". If a reference is made to an IP header or address 124 without the "Inner" or "Outer" qualifier, it should be considered 125 as "Outer". 127 SIIT 128 The Stateless IP/ICMP Translation algorithm, as specified in 129 [RFC6145]. 131 XLAT 132 Short for "translation". 134 IPv4-converted IPv6 addresses 135 As defined in Section 1.3 of [RFC6052]. 137 IPv4-translatable IPv6 addresses 138 As defined in Section 1.3 of [RFC6052]. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2. Problem Statement 146 Section 3.2.1 of [RFC6144] notes that "stateless translation 147 mechanisms typically put constraints on what IPv6 addresses can be 148 assigned to IPv6 nodes that want to communicate with IPv4 149 destinations using an algorithmic mapping". In practice, this means 150 that the IPv6 nodes must be configured with IPv4-translatable IPv6 151 addresses. For the reasons discussed below, some environments may 152 find that the use of IPv4-translatable IPv6 addresses is not desired 153 or even possible. 155 Limited availability: 156 The number of IPv4-translatable IPv6 addresses available to an 157 operator is equal to the number of IPv4 addresses that is assigned 158 to the SIIT function. IPv4 addresses are scarce, and as a result 159 an operator might not have enough IPv4-translatable IPv6 addresses 160 to number the entire IPv6 infrastructure. 162 Restricted format: 163 IPv4-translatable IPv6 addresses must conform to the format 164 specified in Section 2.2 of [RFC6052]. This format is not 165 compatible with other common IPv6 address formats, such as the 166 EUI-64 based IPv6 address format used by IPv6 Stateless Address 167 Autoconfiguration [RFC4862]. 169 An operator could overcome the above two problems by building an IPv6 170 network using regular (non-IPv4-translatable) IPv6 addresses, and 171 assign IPv4-translatable IPv6 addresses as secondary addresses on the 172 nodes that want to communicate with IPv4 nodes through SIIT only. 173 However, doing so may result in a new set of undesired consequences: 175 Routing complexity: 176 The IPv4-translatable IPv6 addresses must be routed throughout the 177 IPv6 network separately from the primary (non-IPv4-translatable) 178 IPv6 addresses used by the nodes. It might be impossible to 179 aggregate these routes, as two adjacent IPv4-translatable IPv6 180 addresses might not be assigned to two adjacent IPv6 nodes. As a 181 result, in order to support SIIT, the IPv6 network might need to 182 carry a large number of extraneous routes. These routes must be 183 separately injected into the IPv6 routing topology somehow. Any 184 intermediate devices in the IPv6 network such as a firewall might 185 require special configuration in order to treat the 186 IPv4-translatable IPv6 address the same as the primary IPv6 187 address, for example by requiring that any ACL entries involving 188 the primary IPv6 address of a node must be duplicated. 190 Operational complexity: 191 The IPv4-translatable IPv6 addresses not only have to be assigned 192 to the IPv6 nodes participating in SIIT; all applications and 193 services on those nodes must also be configured to use them. For 194 example, if the IPv6 node is a load balancer, it might require a 195 separate Virtual Server definition using the IPv4-translatable 196 IPv6 address in addition to one using the service's primary IPv6 197 address. A web server might require specific configuration to 198 listen for connections on both the IPv4-translatable and the 199 primary IPv6 address. A High-Availability cluster service must be 200 set up to fail over both addresses between cluster nodes, and 201 depending on how the IPv6 network learns the location of the 202 IPv4-translatable IPv6 address, the fail-over mechanism used for 203 the two addresses might be completely different. Service 204 monitoring must be done for both the IPv4-translatable and the 205 primary IPv6 address, and any trouble-shooting procedures must be 206 extended to involve both addresses. Finally, the Default Address 207 Selection Policy Table [RFC6724] on the IPv6 nodes might need to 208 be altered in order to ensure that outbound sessions towards the 209 IPv4 Internet are sourced from an IPv4-translatable IPv6 address. 211 In short, the use of IPv4-translatable IPv6 addresses in parallel 212 with regular IPv6 addresses is in many ways analogous to the use of 213 Dual Stack [RFC4213]. While no actual IPv4 packets are used, the 214 IPv4-translatable IPv6 addresses creates a secondary "stack" in the 215 infrastructure that must be treated and operated separately from the 216 primary one. This increases the complexity of the overall 217 infrastructure, in turn increasing operational overhead, and reducing 218 reliability. An operator who for such reasons finds the use Dual 219 Stack unappealing, might feel the same way about using SIIT with 220 IPv4-translatable IPv6 addresses. 222 3. Explicit Address Mapping Algorithm 224 This normative section defines the EAM algorithm, and formally 225 updates Section 4.1 and Section 5.1 of [RFC6145]. Specifically, when 226 the EAM algorithm is applied, it supplants [RFC6145]'s requirement 227 that a translator operating in the stateless mode must translate the 228 Source Address and Destination Address IP header fields according to 229 Section 2.3 of [RFC6052]. 231 3.1. Explicit Address Mapping Table 232 An SIIT implementation includes an EAMT, a conceptual table in which 233 each row represents an EAM. Each EAM describes a mapping between 234 IPv4 and IPv6 prefixes/addresses. An operator populates the EAMT to 235 provide the mappings between the two address families. 237 The EAMT consists of the following columns: 239 o IPv4 Prefix 241 o IPv6 Prefix 243 SIIT implementations MAY include other columns in order to support 244 proprietary extensions to the EAM algorithm. 246 Throughout this document, figures representing the EAMT contain an 247 Index column using the pound sign as the header. This column is not 248 a required part of this specification; it is included only as a 249 convenience to the reader. 251 3.2. Explicit Address Mapping Specification 253 An EAM consists of an IPv4 Prefix and an IPv6 Prefix. The prefix 254 length MAY be omitted, in which case the implementation MUST assume 255 it to be 32 for IPv4 and 128 for IPv6. Figure 1 illustrates an EAMT 256 containing examples of valid EAMs. 258 Example EAMT 260 +---+----------------+----------------------+ 261 | # | IPv4 Prefix | IPv6 Prefix | 262 +---+----------------+----------------------+ 263 | 1 | 192.0.2.1 | 2001:db8:aaaa:: | 264 | 2 | 192.0.2.2/32 | 2001:db8:bbbb::b/128 | 265 | 3 | 192.0.2.16/28 | 2001:db8:cccc::/124 | 266 | 4 | 192.0.2.128/26 | 2001:db8:dddd::/64 | 267 | 5 | 192.0.2.192/31 | 64:ff9b::/127 | 268 +---+----------------+----------------------+ 270 Figure 1 272 An EAM's IPv4 Prefix value MUST have an identical or smaller number 273 of suffix bits than its corresponding IPv6 Prefix value. 275 Unless otherwise specified in Section 4, an SIIT implementation MUST 276 individually translate each IP address it encounters in the packet's 277 IP headers (including any IP headers contained within ICMP errors) 278 according to Section 3.3. 280 3.3. IP Address Translation Procedure 282 This section describes step-by-step how an SIIT implementation 283 translates addresses between IPv4 and IPv6. Only the outcome of the 284 algorithm described should be considered normative, that is, an SIIT 285 implementation may implement the exact procedure differently than 286 what is described here, but the outcome of the algorithm MUST be the 287 same. 289 For concrete examples of IP addresses translations, refer to 290 Appendix B. 292 3.3.1. Address Translation Steps: IPv4 to IPv6 294 1. The IPv4 Prefix column of the EAMT is searched for the EAM entry 295 that shares the longest common prefix with the IPv4 address being 296 translated. The IPv4 Prefix and IPv6 Prefix values of the EAM 297 entry found is from now on referred to as EAM4 and EAM6, 298 respectively. 300 2. If no matching EAM entry is found, the EAM algorithm is aborted. 301 The SIIT implementation MUST proceed to translate the address in 302 accordance with [RFC6145] (and its updates). 304 3. The prefix bits of EAM4 are removed from IPv4 address being 305 translated. The remaining suffix bits from the IPv4 address 306 being translated are stored in a temporary buffer. 308 4. The prefix bits of EAM6 are prepended to the temporary buffer. 310 5. If the temporary buffer at this point does not contain a 128-bit 311 value, it is padded with trailing zeroes so that it reaches a 312 length of 128 bits. 314 6. The contents of the temporary buffer is the translated IPv6 315 address. 317 3.3.2. Address Translation Steps: IPv6 to IPv4 319 1. The IPv6 Prefix column of the EAMT is searched for the EAM entry 320 that shares the longest common prefix with the IPv6 address being 321 translated. The IPv4 Prefix and IPv6 Prefix values of the EAM 322 entry found is from now on referred to as EAM4 and EAM6, 323 respectively. 325 2. If no matching EAM entry is found, the EAM algorithm is aborted. 326 The SIIT implementation MUST proceed to translate the address in 327 accordance with [RFC6145] (and its updates). 329 3. The prefix bits of EAM6 are removed from IPv6 address being 330 translated. The remaining suffix bits from the IPv6 address 331 being translated are stored in a temporary buffer. 333 4. The prefix bits of EAM4 are prepended to the temporary buffer. 335 5. If the temporary buffer at this point does not contain a 32-bit 336 value, any trailing bits are discarded so that the buffer is 337 reduced to a length of 32 bits. 339 6. The contents of the temporary buffer is the translated IPv4 340 address. 342 4. Hairpinning of IPv6 Traffic 344 4.1. Problem Statement 346 Two IPv6 nodes that are both covered by EAMs might in certain 347 circumstances attempt to communicate through a stateless translator, 348 rather than using native IPv6 directly. This happens if one of the 349 nodes initiate traffic towards the IPv4-converted IPv6 address whose 350 embedded IPv4 address matches an EAM that covers the other node. 351 Special consideration is required in order to make this communication 352 pattern work in a bi-directional fashion. This is illustrated by the 353 example below. 355 Assume that a stateless translator is configured with an [RFC6052] 356 translation prefix of 64:ff9b::/96 and the EAMT shown in Figure 1. 357 The IPv6 node 2001:db8:aaaa:: transmits an IPv6 packet towards 358 64:ff9b::192.0.2.2, which reaches the translator and is being 359 translated into an IPv4 packet with source address 192.0.2.1 and 360 destination address 192.0.2.2. This destination address is found in 361 the EAMT, so the packet loops back into the translation function, and 362 is translated back to an IPv6 packet with source address 363 2001:db8:aaaa:: and destination address 2001:db8:bbbb::b. 365 While this packet will reach its destination just fine, a problem 366 will occur when 2001:db8:bbbb::b responds to it. The response packet 367 will have a source address of 2001:db8:bbbb::b and a destination 368 address of 2001:db8:aaaa::, and will be routed directly to its 369 destination without being subjected to any form of translation. 370 Because the source address of this response packet (2001:db8:bbbb::b) 371 is not equal to the destination address of the initial outgoing 372 packet (64:ff9b::192.0.2.2), the packet will most likely be discarded 373 by 2001:db8:aaaa:: and bi-directional communication will most likely 374 fail. 376 The above scenario could be made to work by ensuring that the 377 stateless translator is hairpinning the traffic in both directions. 378 Section 4.2 describes how this is accomplished. The resulting 379 address translations are demonstrated step-by-step in Appendix B.1. 381 4.2. Recommendation 383 An SIIT implementation SHOULD include a feature that ensures that 384 hairpinned IPv6 traffic is supported. The feature SHOULD be enabled 385 by default. The following two subsections describe two alternate 386 ways to implement this feature. An implementation MAY support both 387 approaches. 389 4.2.1. Simple Hairpinning Support 391 When the simple hairpinning feature is enabled, the translator 392 employs the following rules when translating from IPv4 to IPv6: 394 1. If the packet is not an ICMPv4 error: The EAM algorithm MUST NOT 395 be used in order to translate the source address in the IPv4 396 header. 398 2. If the packet is an ICMPv4 error: The EAM algorithm MUST NOT be 399 used when translating the destination address in the inner IPv4 400 header. 402 3. If the packet is an ICMPv4 error whose outer IPv4 source address 403 is equal to its inner IPv4 destination address: The EAM algorithm 404 MUST NOT be used in order to translate the source address in the 405 outer IPv4 header. 407 Rule #2 and #3 are cumulative. 409 The addresses in question MUST instead be translated according to 410 [RFC6145], as if they did not match any EAM. 412 4.2.2. Intrinsic Hairpinning Support 414 When the intrinsic hairpinning feature is enabled, the translator 415 employs the following rules when receiving an IPv6 packet: 417 If all the conditions in either of the two sets below is true, the 418 packet is to be hairpinned. The implementation MUST immediately 419 (i.e., prior to forwarding it to the IPv4 network) translate the 420 packet back to IPv6. During the second translation pass, the 421 behaviour specified in Section 4.2.1 MUST be applied, and the Hop 422 Limit field SHOULD NOT be decremented. 424 Condition set A: 426 A1. The packet is not an ICMPv4 error 428 A2. The destination address was translated using the [RFC6052] 429 algorithm 431 A3. The destination address is found in the EAMT 433 Condition set B: 435 B1. The packet is an ICMPv4 error 437 B2. The inner source address was translated using the [RFC6052] 438 algorithm 440 B3. The inner source address is found in the EAMT 442 5. Overlapping Explicit Address Mappings 444 The algorithm specified in Section 3 relies on making a lookup in the 445 EAMT in order to find the EAM entry that shares the longest common 446 prefix with the address being translated. Operators should note that 447 configuring EAMs with overlapping or identical IPv4 or IPv6 Prefixes 448 in the EAMT may create configurations where the IPv4-to-IPv6 and IPv6 449 -to-IPv4 address translations will not be symmetric. This may in 450 some cases make bi-directional communication impossible. 452 The example EAMT in Figure 2 could be thought of as implementing IVI 453 (Appendix A.2) (EAM #1), but additionally with a single exception in 454 the style of SIIT-DC (Appendix A.3) (EAM #2). The IPv4 Prefixes of 455 the two EAMs overlap, while the IPv6 Prefixes do not. This results 456 in a situation where the IPv6 address 2001:db8:ffc6:3364:4000:: will 457 be translated (according to EAM #1) to the IPv4 address 458 198.51.100.64. However, when this IPv4 address is translated back to 459 IPv6, it will be translated (according to EAM #2) to the IPv6 address 460 2001:db8::abcd. Because the IPv4-to-IPv6 translation in this example 461 does not mirror the corresponding IPv6-to-IPv4 translation, bi- 462 directional communication involving the IPv6 address 463 2001:db8:ffc6:3364:4000:: might fail. In order to help avoid such 464 situations, implementations MAY warn the operator when a new EAM that 465 overlaps with a previously existing one is inserted into the EAMT. 467 EAMT containing overlapping IPv4 Prefixes 469 +---+------------------+--------------------+ 470 | # | IPv4 Prefix | IPv6 Prefix | 471 +---+------------------+--------------------+ 472 | 1 | 0.0.0.0/0 | 2001:db8:ff00::/40 | 473 | 2 | 198.51.100.64/32 | 2001:db8::abcd/128 | 474 +---+------------------+--------------------+ 476 Figure 2 478 In Figure 3, the IPv6 Prefixes of the two EAMs are identical. The 479 behaviour of the stateless translator when translating an IPv6 packet 480 that contains the address 2001:db8::1 to IPv4 is in this case 481 unspecified. In order to prevent this situation from occurring, 482 implementations MAY refuse to insert a new EAM, whose IPv4 or IPv6 483 Prefix value is identical to that of an already existing EAM, into 484 the EAMT. 486 EAMT containing identical IPv6 prefixes 488 +---+-----------------+-----------------+ 489 | # | IPv4 Prefix | IPv6 Prefix | 490 +---+-----------------+-----------------+ 491 | 1 | 198.51.100.8/32 | 2001:db8::1/128 | 492 | 2 | 198.51.100.9/32 | 2001:db8::1/128 | 493 +---+-----------------+-----------------+ 495 Figure 3 497 6. Lack of Checksum Neutrality 499 When one or both of the address fields in an IP/ICMP packet are 500 translated according to EAM, the translation can not be relied upon 501 to be checksum neutral, even if the well-known prefix 64:ff9b::/96 is 502 used. This consideration is discussed in more detail in Section 4.1 503 of [RFC6052]. 505 7. Security Considerations 507 The EAM algorithm does not introduce any new security issues beyond 508 those that are already discussed in Section 7 of [RFC6145]. 510 8. IANA Considerations 512 This draft makes no request of the IANA. 514 9. Acknowledgements 515 This document was conceived due to comments made by Dave Thaler in 516 the v6ops session at IETF 91 as well as e-mail discussions between 517 Fred Baker and the author. 519 Valuable reviews, suggestions, and other feedback was given by Fred 520 Baker, Mohamed Boucadair, Cameron Byrne, Brian E Carpenter, Brian 521 Haberman, Ray Hunter, Alvaro Retana, Michael Richardson, Dan 522 Romascanu, Hemant Singh, and Andrew Yourtchenko. 524 10. References 526 10.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 530 RFC2119, March 1997, 531 . 533 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 534 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 535 DOI 10.17487/RFC6052, October 2010, 536 . 538 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 539 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 540 . 542 10.2. Informative References 544 [I-D.ietf-v6ops-siit-dc] 545 Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for 546 IPv6 Data Centre Environments", draft-ietf-v6ops-siit- 547 dc-03 (work in progress), October 2015. 549 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 550 for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/ 551 RFC4213, October 2005, 552 . 554 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 555 Address Autoconfiguration", RFC 4862, DOI 10.17487/ 556 RFC4862, September 2007, 557 . 559 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 560 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 561 April 2011, . 563 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 564 China Education and Research Network (CERNET) IVI 565 Translation Design and Deployment for the IPv4/IPv6 566 Coexistence and Transition", RFC 6219, DOI 10.17487/ 567 RFC6219, May 2011, 568 . 570 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 571 "Default Address Selection for Internet Protocol Version 6 572 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 573 . 575 [RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. 576 Huston, "Stateless Source Address Mapping for ICMPv6 577 Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012, 578 . 580 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 581 Combination of Stateful and Stateless Translation", RFC 582 6877, DOI 10.17487/RFC6877, April 2013, 583 . 585 [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, DOI 586 10.17487/RFC7335, August 2014, 587 . 589 Appendix A. Use Cases 591 The following subsections lists some use cases that at the time of 592 writing leverage SIIT with the EAM algorithm. 594 A.1. 464XLAT 596 When the CLAT component in the 464XLAT [RFC6877] architecture does 597 not have a dedicated IPv6 prefix assigned, it may instead use "one 598 interface IPv6 address that is claimed by the CLAT". This IPv6 599 address might not be IPv4-translatable. If this is the case, the 600 CLAT essentially implements the EAM algorithm using an EAMT as 601 follows (assuming the CLAT's IPv4 address is picked from the IPv4 602 Service Continuity Prefix [RFC7335]): 604 Example EAMT for an 464XLAT CLAT 606 +---+--------------+-------------------------------+ 607 | # | IPv4 Prefix | IPv6 Prefix | 608 +---+--------------+-------------------------------+ 609 | 1 | 192.0.0.1/32 | CLAT_claimed_IPv6_address/128 | 610 +---+--------------+-------------------------------+ 611 Figure 4 613 In this particular use case, the EAM algorithm is used to translate 614 IPv6 destination addresses to IPv4, and conversely, IPv4 source 615 addresses to IPv6. Other addresses are translated using [RFC6052]. 617 A.2. IVI 619 IVI [RFC6219] describes a stateless translation model that embeds 620 IPv4 addresses in a 40-bit translation prefix where bits 33-40 are 621 required to be 1. The embedded IPv4 address is located in bits 41-72 622 of the IPv6 address. Bits 73-128 are required to be 0. 624 The location of the eight least significant IPv4 address bits makes 625 the IVI address mapping differ from [RFC6052]. 627 Example EAMT for IVI 629 +---+-------------+--------------------+ 630 | # | IPv4 Prefix | IPv6 Prefix | 631 +---+-------------+--------------------+ 632 | 1 | 0.0.0.0/0 | 2001:db8:ff00::/40 | 633 +---+-------------+--------------------+ 635 Figure 5 637 In this particular use case, all addresses are translated according 638 to the EAM algorithm. In other words, [RFC6052] mapping is not used 639 at all. 641 A.3. SIIT-DC 643 SIIT-DC [I-D.ietf-v6ops-siit-dc] describes the use of SIIT to 644 facilitate connectivity from the IPv4 Internet to services hosted in 645 an IPv6-only data centre. In order to avoid the constraints relating 646 to the use of IPv4-translatable IPv6 addresses discussed in Section 2 647 the stateless IPv4/IPv6 translators are provisioned with an EAMT 648 containing one entry per IPv6-only service that are to be made 649 available from the IPv4 Internet, for example (assuming 650 2001:db8:aaaa::1 and 2001:db8:bbbb::1 are assigned to load balancers 651 or servers that provides the IPv6-only services in question): 653 Example EAMT for SIIT-DC 655 +---+----------------+----------------------+ 656 | # | IPv4 Prefix | IPv6 Prefix | 657 +---+----------------+----------------------+ 658 | 1 | 203.0.113.1/32 | 2001:db8:aaaa::1/128 | 659 | 2 | 203.0.113.2/32 | 2001:db8:bbbb::1/128 | 660 +---+----------------+----------------------+ 662 Figure 6 664 In this particular use case, the EAM algorithm is used to translate 665 IPv4 destination addresses to IPv6, and conversely, IPv6 source 666 addresses to IPv4. Other addresses are translated using [RFC6052]. 668 Appendix B. Example IP Address Translations 670 Figure 7 demonstrates how a set of example IP addresses are 671 translated given the example EAMT in Figure 1. Implementors may use 672 the examples given to develop test cases to validate correct 673 operation. Note that the address translations are bidirectional, so 674 a single row in the table describes two address translations: IPv4 to 675 IPv6, and IPv6 to IPv4. 677 It is also assumed that the [RFC6052] translation prefix is 678 configured to be 64:ff9b::/96. 680 Example IP Address Translations 682 +--------------+------------------------+-----------------------+ 683 | IPv4 Address | IPv6 Address | Comment | 684 +--------------+------------------------+-----------------------+ 685 | 192.0.2.1 | 2001:db8:aaaa:: | According to EAM #1 | 686 | 192.0.2.2 | 2001:db8:bbbb::b | According to EAM #2 | 687 | 192.0.2.16 | 2001:db8:cccc:: | According to EAM #3 | 688 | 192.0.2.24 | 2001:db8:cccc::8 | According to EAM #3 | 689 | 192.0.2.31 | 2001:db8:cccc::f | According to EAM #3 | 690 | 192.0.2.128 | 2001:db8:dddd:: | According to EAM #4 | 691 | 192.0.2.152 | 2001:db8:dddd:0:6000:: | According to EAM #4 | 692 | 192.0.2.183 | 2001:db8:dddd:0:dc00:: | According to EAM #4 | 693 | 192.0.2.191 | 2001:db8:dddd:0:fc00:: | According to EAM #4 | 694 | 192.0.2.193 | 64:ff9b::1 | According to EAM #5 | 695 | 192.0.2.200 | 64:ff9b::c000:2c8 | According to RFC 6052 | 696 +--------------+------------------------+-----------------------+ 698 Figure 7 700 B.1. Hairpinning Examples 701 The following examples show how hairpinned IPv6 packets between the 702 IPv6 nodes 2001:db8:aaaa:: and 2001:db8:bbbb::b are translated 703 according to Section 4. As in Appendix B, the EAMT in Figure 1 is 704 used and the [RFC6052] translation prefix is 64:ff9b::/96. In 705 addition, the [RFC6791] pool is assumed to contain only the single 706 address 198.51.100.1. 708 Hairpinning of a normal IPv6 packet 710 +--------------+--------------------+---------------------+ 711 | XLAT Stage | Source Address | Destination Address | 712 +--------------+--------------------+---------------------+ 713 | Initial | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | 714 +--------------+--------------------+---------------------+ 715 | Intermediate | 192.0.2.1 | 192.0.2.2 | 716 +--------------+--------------------+---------------------+ 717 | Final | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | 718 +--------------+--------------------+---------------------+ 720 Figure 8 722 Figure 8 illustrates how a normal (i.e., not an ICMP error) IPv6 723 packet sent from 2001:db8:aaaa:: towards 64:ff9b::192.0.2.2 is is 724 hairpinned. In this example, rule #1 in Section 4.2.1 was applied in 725 order to disable the EAM algorithm when translating the intermediate 726 IPv4 source address to IPv6. 728 Hairpinning of a router-originated ICMPv6 error 730 +--------------+-------+-----------------------+--------------------+ 731 | XLAT Stage | Loc. | Source Address | Destination Addr. | 732 +--------------+-------+-----------------------+--------------------+ 733 | Initial | Outer | 2001:db8::1234 | 64:ff9b::192.0.2.1 | 734 | | Inner | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | 735 +--------------+-------+-----------------------+--------------------+ 736 | Intermediate | Outer | 198.51.100.1 | 192.0.2.1 | 737 | | Inner | 192.0.2.1 | 192.0.2.2 | 738 +--------------+-------+-----------------------+--------------------+ 739 | Final | Outer | 64:ff9b::198.51.100.1 | 2001:db8:aaaa:: | 740 | | Inner | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | 741 +--------------+-------+-----------------------+--------------------+ 743 Figure 9 745 Figure 9 illustrates the hairpinning of an ICMPv6 error sent by an 746 arbitrary IPv6 router (2001:db8::1234) in response to the packet 747 Figure 8. In this example, rule #2 in Section 4.2.1 was applied in 748 order to disable the EAM algorithm when translating the intermediate 749 inner IPv4 destination address to IPv6. 751 Hairpinning of a host-originated ICMPv6 error 753 +--------------+-------+--------------------+--------------------+ 754 | XLAT Stage | Loc. | Source Address | Destination Addr. | 755 +--------------+-------+--------------------+--------------------+ 756 | Initial | Outer | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 | 757 | | Inner | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | 758 +--------------+-------+--------------------+--------------------+ 759 | Intermediate | Outer | 192.0.2.2 | 192.0.2.1 | 760 | | Inner | 192.0.2.1 | 192.0.2.2 | 761 +--------------+-------+--------------------+--------------------+ 762 | Final | Outer | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: | 763 | | Inner | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | 764 +--------------+-------+--------------------+--------------------+ 766 Figure 10 768 Figure 10 illustrates the hairpinning of an ICMPv6 error sent by the 769 original destination host itself in response to the packet Figure 8. 770 In this example, rules #2 and #3 in Section 4.2.1 were both applied 771 in order to disable the EAM algorithm when translating the 772 intermediate inner IPv4 destination address and the intermediate 773 outer IPv4 destination address to IPv6. 775 Hairpinning of normal response packet 777 +--------------+--------------------+---------------------+ 778 | XLAT Stage | Source Address | Destination Address | 779 +--------------+--------------------+---------------------+ 780 | Initial | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 | 781 +--------------+--------------------+---------------------+ 782 | Intermediate | 192.0.2.2 | 192.0.2.1 | 783 +--------------+--------------------+---------------------+ 784 | Final | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: | 785 +--------------+--------------------+---------------------+ 787 Figure 11 789 Figure 11 illustrates how 2001:db8:bbbb::b's response to the packet 790 in Figure 8 is hairpinned in the exact same fashion as the initial 791 packet. Again, rule #1 in Section 4.2.1 was applied in order to 792 disable the EAM algorithm when translating the intermediate IPv4 793 source address to IPv6. The example is included in order to 794 illustrate how the addresses in the packet initially sent by 795 2001:db8:aaaa:: matches those in the translated response packet sent 796 by 2001:db8:bbbb::b, thus facilitating bi-directional communication. 798 Authors' Addresses 800 Tore Anderson 801 Redpill Linpro 802 Vitaminveien 1A 803 0485 Oslo 804 Norway 806 Phone: +47 959 31 212 807 Email: tore@redpill-linpro.com 808 URI: http://www.redpill-linpro.com 810 Alberto Leiva Popper 811 NIC Mexico 812 Av. Eugenio Garza Sada 427 L4-6 813 Monterrey, Nuevo Leon 64840 814 Mexico 816 Email: ydahhrk@gmail.com 817 URI: http://www.nicmexico.mx/