idnits 2.17.1 draft-ietf-v6ops-siit-eam-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-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 (May 09, 2015) is 3275 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-siit-dc-00 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: November 10, 2015 May 09, 2015 8 Explicit Address Mappings for Stateless IP/ICMP Translation 9 draft-ietf-v6ops-siit-eam-00 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 November 10, 2015. 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 . . . . . . . . . . . . . 6 57 3.1. Explicit Address Mapping Table . . . . . . . . . . . . . 6 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 . . . . . . . 8 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 . . . . . . . . . . . . 10 67 5. Lack of Checksum Neutrality . . . . . . . . . . . . . . . . . 10 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 12 75 A.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 A.2. IVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 A.3. SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 Appendix B. Example IP Address Translations . . . . . . . . . . 14 79 B.1. Hairpinning Examples . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 The Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145] 85 specifies that when translating IPv4 addresses to IPv6 and vice 86 versa, all addresses must be translated using the algorithm specified 87 in [RFC6052]. This document specifies an alternative to the 88 [RFC6052] algorithm, where IP addresses are translated according to a 89 table of Explicit Address Mappings configured on the stateless 90 translator. This removes the previous constraint that IPv6 nodes 91 that communicate with IPv4 nodes through SIIT must be configured with 92 IPv4-translatable IPv6 addresses. 94 The Explicit Address Mapping Table does not replace [RFC6052]. For 95 most use cases, it is expected that both algorithms are used in 96 concert. The Explicit Address Mapping algorithm is used only when a 97 mapping matching the address to be translated exists. If no matching 98 mapping exists, the [RFC6052] algorithm will be used instead. Thus, 99 when translating an individual IP packet, an SIIT implementation 100 might translate one of the two IP address fields according to an EAM, 101 while the other IP address field is translated according to 102 [RFC6052]. 104 1.1. Terminology 106 This document makes use of the following terms: 108 EAM 109 An Explicit Address Mapping, as specified in Section 3.2. 111 EAMT 112 The Explicit Address Mapping Table, as specified in Section 3.1. 114 Inner (header or address) Refers to an IP header located inside the 115 payload of an ICMP error packet, or to an IP address within that 116 header. Compare "Outer". 118 Outer (header or address) Refers to the first IP header in a packet, 119 or to an IP address within that header. In other words, an IP 120 header or address that is NOT "Inner". If a reference is made to 121 an IP header or address without the "Inner" or "Outer" qualifier, 122 it should be considered as "Outer". 124 SIIT 125 The Stateless IP/ICMP Translation algorithm, as specified in 126 [RFC6145]. 128 XLAT 129 Short for "translation". 131 IPv4-converted IPv6 addresses 132 As defined in Section 1.3 of [RFC6052]. 134 IPv4-translatable IPv6 addresses 135 As defined in Section 1.3 of [RFC6052]. 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 2. Problem Statement 143 Section 3.2.1 of [RFC6144] notes that "stateless translation 144 mechanisms typically put constraints on what IPv6 addresses can be 145 assigned to IPv6 nodes that want to communicate with IPv4 146 destinations using an algorithmic mapping". In practice, this means 147 that the IPv6 nodes must be configured with IPv4-translatable IPv6 148 addresses. For the reasons discussed below, some environments may 149 find that the use of IPv4-translatable IPv6 addresses is not desired 150 or even possible. 152 Limited availability: 153 The number of IPv4-translatable IPv6 addresses available to an 154 operator is equal to the number of IPv4 addresses he assigns to 155 the SIIT function. IPv4 addresses are scarce, and as a result an 156 operator might not have enough IPv4-translatable IPv6 addresses to 157 number his entire IPv6 infrastructure. 159 Restricted format: 160 IPv4-translatable IPv6 addresses must conform to the format 161 specified in Section 2.2 of [RFC6052]. This format is not 162 compatible with other common IPv6 address formats, such as the 163 EUI-64 based IPv6 address format used by IPv6 Stateless Address 164 Autoconfiguration [RFC4862]. 166 An operator could overcome the above two problems by building an IPv6 167 network using regular (non-IPv4-translatable) IPv6 addresses, and 168 assign IPv4-translatable IPv6 addresses as secondary addresses on the 169 nodes that want to communicate with IPv4 nodes through SIIT only. 170 However, doing so may result in a new set of undesired properties: 172 Routing complexity: 174 The IPv4-translatable IPv6 addresses must be routed throughout the 175 IPv6 network separately from the primary (non-IPv4-translatable) 176 IPv6 addresses used by the nodes. It might be impossible to 177 aggregate these routes, as two adjacent IPv4-translatable IPv6 178 addresses might not be assigned to two adjacent IPv6 nodes. As a 179 result, in order to support SIIT, the IPv6 network might need to 180 carry a large number of extraneous routes. These routes must be 181 separately injected into the IPv6 routing topology somehow. Any 182 intermediate devices in the IPv6 network such as a firewall might 183 require special configuration in order to treat the 184 IPv4-translatable IPv6 address the same as the primary IPv6 185 address, for example by requiring that any ACL entries involving 186 the primary IPv6 address of a node must be duplicated. 188 Operational complexity: 189 The IPv4-translatable IPv6 addresses must not only be assigned to 190 the IPv6 nodes participating in SIIT; all applications and 191 services on those nodes must also be configured to use them. For 192 example, if the IPv6 node is a load balancer, it might require a 193 separate Virtual Server definition using the IPv4-translatable 194 IPv6 address in addition to one using the service's primary IPv6 195 address. A web server might require specific configuration to 196 listen for connections on both the IPv4-translatable and the 197 primary IPv6 address. A High-Availability cluster service must be 198 set up to fail over both addresses between cluster nodes, and 199 depending on how the IPv6 network learns the location of the 200 IPv4-translatable IPv6 address, the fail-over mechanism used for 201 the two addresses might be completely different. Service 202 monitoring must be done for both the IPv4-translatable and the 203 primary IPv6 address, and any trouble-shooting procedures must be 204 extended to involve both addresses. 206 In short, the use of IPv4-translatable IPv6 addresses in parallel 207 with regular IPv6 addresses is in many ways analogous to the use of 208 Dual Stack [RFC4213]. While no actual IPv4 packets are used, the 209 IPv4-translatable IPv6 addresses creates a secondary "stack" in the 210 infrastructure that must be treated and operated separately from the 211 primary one. This increases the complexity of the overall 212 infrastructure, in turn increasing operational overhead, and reducing 213 reliability. An operator who for such reasons finds the use Dual 214 Stack unappealing, might feel the same way about using SIIT with 215 IPv4-translatable IPv6 addresses. 217 3. Explicit Address Mapping Algorithm 219 This normative section defines the EAM algorithm. SIIT 220 implementations are REQUIRED to support the specifications herein. 222 3.1. Explicit Address Mapping Table 224 An SIIT implementation MUST include an Explicit Address Mapping Table 225 (EAMT). By default, the EAMT SHOULD be empty. The operator MUST be 226 able to populate the EAMT using the implementation's normal 227 configuration interfaces. The implementation MAY additionally 228 support other ways of populating the EAMT. 230 The EAMT consists of the following columns: 232 o IPv4 Prefix 234 o IPv6 Prefix 236 SIIT implementations MAY include other columns in order to support 237 proprietary extensions to the EAM algorithm. 239 Throughout this document, figures representing the EAMT contain an 240 Index column using the pound sign as the header. This column is not 241 a required part of this specification; it is included only as a 242 convenience to the reader. 244 3.2. Explicit Address Mapping Specification 246 An EAM consists of an IPv4 Prefix and an IPv6 Prefix. The prefix 247 length MAY be omitted, in which case the implementation MUST assume 248 it to be 32 for IPv4 and 128 for IPv6. Figure 1 illustrates an EAMT 249 containing examples of valid EAMs. 251 Example EAMT 253 +---+----------------+----------------------+ 254 | # | IPv4 Prefix | IPv6 Prefix | 255 +---+----------------+----------------------+ 256 | 1 | 192.0.2.1 | 2001:db8:aaaa:: | 257 | 2 | 192.0.2.2/32 | 2001:db8:bbbb::b/128 | 258 | 3 | 192.0.2.16/28 | 2001:db8:cccc::/124 | 259 | 4 | 192.0.2.128/26 | 2001:db8:dddd::/64 | 260 | 5 | 192.0.2.192/31 | 64:ff9b::/127 | 261 +---+----------------+----------------------+ 263 Figure 1 265 An EAM's IPv4 Prefix value MUST have an identical or smaller number 266 of suffix bits than its corresponding IPv6 Prefix value. 268 Overlapping EAMs SHOULD be considered an error, and attempts to 269 insert them into the EAMT SHOULD be blocked. The behaviour of an 270 SIIT implementation when overlapping EAMs are present in the EAMT is 271 left undefined. 273 When translating a packet between IPv4 and IPv6, an SIIT 274 implementation MUST individually translate each IP address it 275 encounters in the packet's IP headers (including any IP headers 276 contained within ICMP errors) according to Section 3.3. See 277 Section 4 for certain exceptions to this rule. 279 3.3. IP Address Translation Procedure 281 This section describes step-by-step how an SIIT implementation 282 translates addresses between IPv4 and IPv6. Only the outcome of the 283 algorithm described should be considered normative, that is, an SIIT 284 implementation MAY implement the exact procedure differently than 285 what is described here, but the outcome of the algorithm MUST be the 286 same. 288 For concrete examples of IP addresses translations, refer to 289 Appendix B. 291 3.3.1. Address Translation Steps: IPv4 to IPv6 293 1. The EAMT is searched for an EAM entry containing an IPv4 Prefix 294 identical to that of the IPv4 address being translated. The IPv4 295 Prefix and IPv6 Prefix values of the EAM entry found is from now 296 on referred to as EAM4 and EAM6, respectively. 298 2. If no matching EAM entry is found, the EAM algorithm is aborted. 299 The SIIT implementation MUST proceed to translate the address in 300 accordance with [RFC6145] (and its updates). 302 3. The prefix bits of EAM4 are removed from IPv4 address being 303 translated. The remaining suffix bits from the IPv4 address 304 being translated are stored in a temporary buffer. 306 4. The prefix bits of EAM6 are prepended to the temporary buffer. 308 5. If the temporary buffer at this point does not contain a 128-bit 309 value, it is padded with trailing zeroes so that it reaches a 310 length of 128 bits. 312 6. The contents of the temporary buffer is the translated IPv6 313 address. 315 3.3.2. Address Translation Steps: IPv6 to IPv4 317 1. The EAMT is searched for an EAM entry containing an IPv6 Prefix 318 identical to that of the IPv6 address being translated. The IPv4 319 Prefix and IPv6 Prefix values of the EAM entry found is from now 320 on referred to as EAM4 and EAM6, respectively. 322 2. If no matching EAM entry is found, the EAM algorithm is aborted. 323 The SIIT implementation MUST proceed to translate the address in 324 accordance with [RFC6145] (and its updates). 326 3. The prefix bits of EAM6 are removed from IPv6 address being 327 translated. The remaining suffix bits from the IPv6 address 328 being translated are stored in a temporary buffer. 330 4. The prefix bits of EAM4 are prepended to the temporary buffer. 332 5. If the temporary buffer at this point does not contain a 32-bit 333 value, any trailing bits are discarded so that the buffer is 334 reduced to a length of 32 bits. 336 6. The contents of the temporary buffer is the translated IPv4 337 address. 339 4. Hairpinning of IPv6 Traffic 341 4.1. Problem Statement 343 Two IPv6 nodes that are both covered by EAMs might in certain 344 circumstances attempt to communicate through a stateless translator, 345 rather than using native IPv6 directly. This happens if one of the 346 nodes initiate traffic towards the IPv4-converted IPv6 address whose 347 embedded IPv4 address matches an EAM that covers the other node. 348 Special consideration is required in order to make this communication 349 pattern work in a bi-directional fashion. This is illustrated by the 350 example below. 352 Assume that a stateless translator is configured with an [RFC6052] 353 translation prefix of 64:ff9b::/96 and the EAMT shown in Figure 1. 354 The IPv6 node 2001:db8:aaaa:: transmits an IPv6 packet towards 355 64:ff9b::192.0.2.2, which reaches the translator and is being 356 translated into an IPv4 packet with source address 192.0.2.1 and 357 destination address 192.0.2.2. This destination address is found in 358 the EAMT, so the packet loops back into the translation function, and 359 is translated back to an IPv6 packet with source address 360 2001:db8:aaaa:: and destination address 2001:db8:bbbb::b. 362 While this packet will reach its destination just fine, a problem 363 will occur when 2001:db8:bbbb::b responds to it. The response packet 364 will have a source address of 2001:db8:bbbb::b and a destination 365 address of 2001:db8:aaaa::, and will be routed directly to its 366 destination without being subjected to any form of translation. 367 Because the source address of this response packet (2001:db8:bbbb::b) 368 is not equal to the destination address of the initial outgoing 369 packet (64:ff9b::192.0.2.2), the packet will most likely be discarded 370 by 2001:db8:aaaa:: and bi-directional communication will most likely 371 fail. 373 The above scenario could be made to work by ensuring that the 374 stateless translator is hairpinning the traffic in both directions. 375 Section 4.2 describes how this is accomplished. The resulting 376 address translations are demonstrated step-by-step in Appendix B.1. 378 4.2. Recommendation 380 An SIIT implementation SHOULD include a feature that ensures that 381 hairpinned IPv6 traffic is supported. The feature SHOULD be enabled 382 by default. The following two subsections describe two alternate 383 ways to implement this feature. An implementation MAY support both 384 approaches. 386 4.2.1. Simple Hairpinning Support 388 When the simple hairpinning feature is enabled, the translator MUST 389 behave according to the following rules when translating from IPv4 to 390 IPv6: 392 1. If the packet is not an ICMPv4 error: The EAM algorithm MUST NOT 393 be used in order to translate the source address in the IPv4 394 header. 396 2. If the packet is an ICMPv4 error: The EAM algorithm MUST NOT be 397 used when translating the destination address in the inner IPv4 398 header. 400 3. If the packet is an ICMPv4 error whose outer IPv4 source address 401 is equal to its inner IPv4 destination address: The EAM algorithm 402 MUST NOT be used in order to translate the source address in the 403 IPv4 header. 405 Rule #2 and #3 are cumulative. 407 The addresses in question MUST instead be translated according to 408 [RFC6145], as if they did not match any EAM. 410 4.2.2. Intrinsic Hairpinning Support 412 When the intrinsic hairpinning feature is enabled, the translator 413 behaves as follows when receiving an IPv6 packet: 415 If all the conditions in either of the two sets below is true, the 416 packet is to be hairpinned. The implementation MUST immediately 417 (i.e., prior to forwarding it to the IPv4 network) translate the 418 packet back to IPv6. During the second translation pass, the 419 behaviour specified in Section 4.2.1 MUST be applied, and the Hop 420 Limit field SHOULD NOT be decremented. 422 Condition set A: 424 A1. The packet is not an ICMPv4 error 426 A2. The destination address was translated using the [RFC6052] 427 algorithm 429 A3. The destination address is found in the EAMT 431 Condition set B: 433 B1. The packet is an ICMPv4 error 435 B2. The inner source address was translated using the [RFC6052] 436 algorithm 438 B3. The inner source address is found in the EAMT 440 5. Lack of Checksum Neutrality 442 When one or both of the address fields in an IP/ICMP packet are 443 translated according to EAM, the translation can not be relied upon 444 to be checksum neutral, even if the well-known prefix 64:ff9b::/96 is 445 used. This consideration is discussed in more detail in Section 4.1 446 of [RFC6052]. 448 6. Security Considerations 450 The EAM algorithm does not introduce any new security issues beyond 451 those that are already discussed in Section 7 of [RFC6145]. 453 7. IANA Considerations 455 This draft makes no request of the IANA. The RFC Editor may remove 456 this section prior to publication. 458 8. Acknowledgements 460 This document was conceived due to comments made by Dave Thaler in 461 the v6ops session at IETF 91 as well as e-mail discussions between 462 Fred Baker and the author. 464 Valuable reviews, suggestions, and other feedback was given by 465 Mohamed Boucadair, Cameron Byrne, Brian E Carpenter, Michael 466 Richardson, and Andrew Yourtchenko. 468 9. References 470 9.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 476 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 477 October 2010. 479 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 480 Algorithm", RFC 6145, April 2011. 482 9.2. Informative References 484 [I-D.ietf-v6ops-siit-dc] 485 tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 486 Data Centre Environments", draft-ietf-v6ops-siit-dc-00 487 (work in progress), December 2014. 489 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 490 for IPv6 Hosts and Routers", RFC 4213, October 2005. 492 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 493 Address Autoconfiguration", RFC 4862, September 2007. 495 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 496 IPv4/IPv6 Translation", RFC 6144, April 2011. 498 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 499 China Education and Research Network (CERNET) IVI 500 Translation Design and Deployment for the IPv4/IPv6 501 Coexistence and Transition", RFC 6219, May 2011. 503 [RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. 504 Huston, "Stateless Source Address Mapping for ICMPv6 505 Packets", RFC 6791, November 2012. 507 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 508 Combination of Stateful and Stateless Translation", RFC 509 6877, April 2013. 511 [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, 512 August 2014. 514 Appendix A. Use Cases 516 The following subsections lists some use cases that at the time of 517 writing leverage SIIT with the EAM algorithm. 519 A.1. 464XLAT 521 When the CLAT component in the 464XLAT [RFC6877] architecture does 522 not have a dedicated IPv6 prefix assigned, it may instead use "one 523 interface IPv6 address that is claimed by the CLAT". This IPv6 524 address might not be IPv4-translatable. If this is the case, the 525 CLAT essentially implements the EAM algorithm using an EAMT as 526 follows (assuming the CLAT's IPv4 address is picked from the IPv4 527 Service Continuity Prefix [RFC7335]): 529 Example EAMT for an 464XLAT CLAT 531 +---+--------------+-------------------------------+ 532 | # | IPv4 Prefix | IPv6 Prefix | 533 +---+--------------+-------------------------------+ 534 | 1 | 192.0.0.1/32 | CLAT_claimed_IPv6_address/128 | 535 +---+--------------+-------------------------------+ 537 Figure 2 539 In this particular use case, the EAM algorithm is used to translate 540 IPv6 destination addresses to IPv4, and conversely, IPv4 source 541 addresses to IPv6. Other addresses are translated using [RFC6052]. 542 Note that this is the exact opposite of the SIIT-DC use case 543 (Appendix A.3). 545 A.2. IVI 547 IVI [RFC6219] describes a stateless translation model that embeds 548 IPv4 addresses in a 40-bit translation prefix where bits 33-40 are 549 required to be 1. The embedded IPv4 address is located in bits 41-72 550 of the IPv6 address. Bits 73-128 are required to be 0. 552 The location of the eight least significant IPv4 address bits makes 553 the IVI address mapping differ from [RFC6052]. 555 Example EAMT for IVI 557 +---+-------------+--------------------+ 558 | # | IPv4 Prefix | IPv6 Prefix | 559 +---+-------------+--------------------+ 560 | 1 | 0.0.0.0/0 | 2001:db8:ff00::/40 | 561 +---+-------------+--------------------+ 563 Figure 3 565 In this particular use case, all addresses are translated according 566 to the EAM algorithm. In other words, [RFC6052] mapping is not used 567 at all. 569 A.3. SIIT-DC 571 SIIT-DC [I-D.ietf-v6ops-siit-dc] describes the use of SIIT to 572 facilitate connectivity from the IPv4 Internet to services hosted in 573 an IPv6-only data centre. In order to avoid the constraints relating 574 to the use of IPv4-translatable IPv6 addresses discussed in Section 2 575 the stateless IPv4/IPv6 translators are provisioned with an EAMT 576 containing one entry per IPv6-only service that are to be made 577 available from the IPv4 Internet, for example (assuming 578 2001:db8:aaaa::1 and 2001:db8:bbbb::1 are assigned to load balancers 579 or servers that provides the IPv6-only services in question): 581 Example EAMT for SIIT-DC 583 +---+--------------+----------------------+ 584 | # | IPv4 Prefix | IPv6 Prefix | 585 +---+--------------+----------------------+ 586 | 1 | 192.0.2.1/32 | 2001:db8:aaaa::1/128 | 587 | 2 | 192.0.2.2/32 | 2001:db8:bbbb::1/128 | 588 +---+--------------+----------------------+ 590 Figure 4 592 In this particular use case, the EAM algorithm is used to translate 593 IPv4 destination addresses to IPv6, and conversely, IPv6 source 594 addresses to IPv4. Other addresses are translated using [RFC6052]. 595 Note that this is the exact opposite of the 464XLAT use case 596 (Appendix A.1). 598 Appendix B. Example IP Address Translations 600 Figure 5 demonstrates how a set of example IP addresses are 601 translated given the example EAMT in Figure 1. Implementors may use 602 the examples given to develop test cases to validate correct 603 operation. Note that the address translations are bidirectional, so 604 a single row in the table describes two address translations: IPv4 to 605 IPv6, and IPv6 to IPv4. 607 It is also assumed that the [RFC6052] translation prefix is 608 configured to be 64:ff9b::/96. 610 Example IP Address Translations 612 +--------------+------------------------+-----------------------+ 613 | IPv4 Address | IPv6 Address | Comment | 614 +--------------+------------------------+-----------------------+ 615 | 192.0.2.1 | 2001:db8:aaaa:: | According to EAM #1 | 616 | 192.0.2.2 | 2001:db8:bbbb::b | According to EAM #2 | 617 | 192.0.2.16 | 2001:db8:cccc:: | According to EAM #3 | 618 | 192.0.2.24 | 2001:db8:cccc::8 | According to EAM #3 | 619 | 192.0.2.31 | 2001:db8:cccc::f | According to EAM #3 | 620 | 192.0.2.128 | 2001:db8:dddd:: | According to EAM #4 | 621 | 192.0.2.152 | 2001:db8:dddd:0:6000:: | According to EAM #4 | 622 | 192.0.2.183 | 2001:db8:dddd:0:dc00:: | According to EAM #4 | 623 | 192.0.2.191 | 2001:db8:dddd:0:fc00:: | According to EAM #4 | 624 | 192.0.2.193 | 64:ff9b::1 | According to EAM #5 | 625 | 192.0.2.200 | 64:ff9b::c000:2c8 | According to RFC 6052 | 626 +--------------+------------------------+-----------------------+ 628 Figure 5 630 B.1. Hairpinning Examples 632 The following examples show how hairpinned IPv6 packets between the 633 IPv6 nodes 2001:db8:aaaa:: and 2001:db8:bbbb::b are translated 634 according to Section 4. As in Appendix B, the EAMT in Figure 1 is 635 used and the [RFC6052] translation prefix is 64:ff9b::/96. In 636 addition, the [RFC6791] pool is assumed to contain only the single 637 address 198.51.100.1. 639 Hairpinning of a normal IPv6 packet 641 +--------------+--------------------+---------------------+ 642 | XLAT Stage | Source Address | Destination Address | 643 +--------------+--------------------+---------------------+ 644 | Initial | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | 645 +--------------+--------------------+---------------------+ 646 | Intermediate | 192.0.2.1 | 192.0.2.2 | 647 +--------------+--------------------+---------------------+ 648 | Final | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | 649 +--------------+--------------------+---------------------+ 651 Figure 6 653 Figure 6 illustrates how a normal (i.e., not an ICMP error) IPv6 654 packet sent from 2001:db8:aaaa:: towards 64:ff9b::192.0.2.2 is is 655 hairpinned. In this example, rule #1 in Section 4.2.1 was applied in 656 order to disable the EAM algorithm when translating the intermediate 657 IPv4 source address to IPv6. 659 Hairpinning of a host-originated ICMPv6 error 661 +--------------+-------+-----------------------+--------------------+ 662 | XLAT Stage | Loc. | Source Address | Destination Addr. | 663 +--------------+-------+-----------------------+--------------------+ 664 | Initial | Inner | 2001:db8::1234 | 64:ff9b::192.0.2.1 | 665 | | Outer | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | 666 +--------------+-------+-----------------------+--------------------+ 667 | Intermediate | Inner | 198.51.100.1 | 192.0.2.1 | 668 | | Outer | 192.0.2.1 | 192.0.2.2 | 669 +--------------+-------+-----------------------+--------------------+ 670 | Final | Inner | 64:ff9b::198.51.100.1 | 2001:db8:aaaa:: | 671 | | Outer | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | 672 +--------------+-------+-----------------------+--------------------+ 674 Figure 7 676 Figure 7 illustrates the hairpinning of an ICMPv6 error sent by an 677 arbitrary IPv6 router (2001:db8::1234) in response to the packet 678 Figure 6. In this example, rule #2 in Section 4.2.1 was applied in 679 order to disable the EAM algorithm when translating the intermediate 680 inner IPv4 source address to IPv6. 682 Hairpinning of a host-originated ICMPv6 error 684 +--------------+-------+-----------------------+--------------------+ 685 | XLAT Stage | Loc. | Source Address | Destination Addr. | 686 +--------------+-------+-----------------------+--------------------+ 687 | Initial | Inner | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 | 688 | | Outer | 64:ff9b::192.0.2.1 | 2001:db8:bbbb::b | 689 +--------------+-------+-----------------------+--------------------+ 690 | Intermediate | Inner | 192.0.2.2 | 192.0.2.1 | 691 | | Outer | 192.0.2.1 | 192.0.2.2 | 692 +--------------+-------+-----------------------+--------------------+ 693 | Final | Inner | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: | 694 | | Outer | 2001:db8:aaaa:: | 64:ff9b::192.0.2.2 | 695 +--------------+-------+-----------------------+--------------------+ 697 Figure 8 699 Figure 8 illustrates the hairpinning of an ICMPv6 error sent by the 700 original destination host itself in response to the packet Figure 6. 701 In this example, rules #2 and #3 in Section 4.2.1 were both applied 702 in order to disable the EAM algorithm when translating the 703 intermediate inner IPv4 destination address and the intermediate 704 outer IPv4 destination address to IPv6. 706 Hairpinning of normal response packet 708 +--------------+--------------------+---------------------+ 709 | XLAT Stage | Source Address | Destination Address | 710 +--------------+--------------------+---------------------+ 711 | Initial | 2001:db8:bbbb::b | 64:ff9b::192.0.2.1 | 712 +--------------+--------------------+---------------------+ 713 | Intermediate | 192.0.2.2 | 192.0.2.1 | 714 +--------------+--------------------+---------------------+ 715 | Final | 64:ff9b::192.0.2.2 | 2001:db8:aaaa:: | 716 +--------------+--------------------+---------------------+ 718 Figure 9 720 Figure 9 illustrates how 2001:db8:bbbb::b's response to the packet in 721 Figure 6 is hairpinned in the exact same fashion as the initial 722 packet. Again, rule #1 in Section 4.2.1 was applied in order to 723 disable the EAM algorithm when translating the intermediate IPv4 724 source address to IPv6. The example is included in order to 725 illustrate how the addresses in the packet initially sent by 726 2001:db8:aaaa:: matches those in the translated response packet sent 727 by 2001:db8:bbbb::b, thus facilitating bi-directional communication. 729 Authors' Addresses 731 Tore Anderson 732 Redpill Linpro 733 Vitaminveien 1A 734 0485 Oslo 735 Norway 737 Phone: +47 959 31 212 738 Email: tore@redpill-linpro.com 739 URI: http://www.redpill-linpro.com 741 Alberto Leiva Popper 742 NIC Mexico 743 Av. Eugenio Garza Sada 427 L4-6 744 Monterrey, Nuevo Leon 64840 745 Mexico 747 Email: ydahhrk@gmail.com 748 URI: http://www.nicmexico.mx/