idnits 2.17.1 draft-anderson-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 2 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 (January 08, 2015) is 3390 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) Summary: 1 error (**), 0 flaws (~~), 3 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) January 08, 2015 5 Intended status: Standards Track 6 Expires: July 12, 2015 8 Explicit Address Mappings for Stateless IP/ICMP Translation 9 draft-anderson-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 July 12, 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 . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . 6 60 3.3.1. Address Translation Steps: IPv4 to IPv6 . . . . . . . 7 61 3.3.2. Address Translation Steps: IPv6 to IPv4 . . . . . . . 7 62 4. Lack of Checksum Neutrality . . . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 8.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 9 70 A.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 A.2. IVI . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 A.3. SIIT-DC . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Appendix B. Example IP Address Translations . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145] 79 specifies that when translating IPv4 addresses to IPv6 and vice 80 versa, all addresses must be translated using the algorithm specified 81 in [RFC6052]. This document specifies an alternative to the 82 [RFC6052] algorithm, where IP addresses are translated according to a 83 table of Explicit Address Mappings configured on the stateless 84 translator. This removes the previous constraint that IPv6 nodes 85 that communicate with IPv4 nodes through SIIT must be configured with 86 IPv4-translatable IPv6 addresses. 88 The Explicit Address Mapping Table does not replace [RFC6052]. For 89 most use cases, it is expected that both algorithms are used in 90 concert. The Explicit Address Mapping algorithm is used only when a 91 mapping matching the address to be translated exists. If no matching 92 mapping exists, the [RFC6052] algorithm will be used instead. Thus, 93 when translating an individual IP packet, an SIIT implementation 94 might translate one of the two IP address fields according to an EAM, 95 while the other IP address field is translated according to 96 [RFC6052]. 98 1.1. Terminology 100 This document makes use of the following terms: 102 EAM 103 An Explicit Address Mapping, as specified in Section 3.2. 105 EAMT 106 The Explicit Address Mapping Table, as specified in Section 3.1. 108 SIIT 109 The Stateless IP/ICMP Translation algorithm, as specified in 110 [RFC6145]. 112 IPv4-converted IPv6 addresses 113 As defined in Section 1.3 of [RFC6052]. 115 IPv4-translatable IPv6 addresses 116 As defined in Section 1.3 of [RFC6052]. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2. Problem Statement 124 Section 3.2.1 of [RFC6144] notes that "stateless translation 125 mechanisms typically put constraints on what IPv6 addresses can be 126 assigned to IPv6 nodes that want to communicate with IPv4 127 destinations using an algorithmic mapping". In practice, this means 128 that the IPv6 nodes must be configured with IPv4-translatable IPv6 129 addresses. For the reasons discussed below, some environments may 130 find that the use of IPv4-translatable IPv6 addresses is not desired 131 or even possible. 133 Limited availability: 134 The number of IPv4-translatable IPv6 addresses available to an 135 operator is equal to the number of IPv4 addresses he assigns to 136 the SIIT function. IPv4 addresses are scarce, and as a result an 137 operator might not have enough IPv4-translatable IPv6 addresses to 138 number his entire IPv6 infrastructure. 140 Restricted format: 141 IPv4-translatable IPv6 addresses must conform to the format 142 specified in Section 2.2 of [RFC6052]. This format is not 143 compatible with other common IPv6 address formats, such as the 144 EUI-64 based IPv6 address format used by IPv6 Stateless Address 145 Autoconfiguration [RFC4862]. 147 An operator could overcome the above two problems by building an IPv6 148 network using regular (non-IPv4-translatable) IPv6 addresses, and 149 assign IPv4-translatable IPv6 addresses as secondary addresses on the 150 nodes that want to communicate with IPv4 nodes through SIIT only. 151 However, doing so may result in a new set of undesired properties: 153 Routing complexity: 154 The IPv4-translatable IPv6 addresses must be routed throughout the 155 IPv6 network separately from the primary (non-IPv4-translatable) 156 IPv6 addresses used by the nodes. It might be impossible to 157 aggregate these routes, as two adjacent IPv4-translatable IPv6 158 addresses might not be assigned to two adjacent IPv6 nodes. As a 159 result, in order to support SIIT, the IPv6 network might need to 160 carry a large number of extraneous routes. These routes must be 161 separately injected into the IPv6 routing topology somehow. Any 162 intermediate devices in the IPv6 network such as a firewall might 163 require special configuration in order to treat the 164 IPv4-translatable IPv6 address the same as the primary IPv6 165 address, for example by requiring that any ACL entries involving 166 the primary IPv6 address of a node must be duplicated. 168 Operational complexity: 170 The IPv4-translatable IPv6 addresses must not only be assigned to 171 the IPv6 nodes participating in SIIT; all applications and 172 services on those nodes must also be configured to use them. For 173 example, if the IPv6 node is a load balancer, it might require a 174 separate Virtual Server definition using the IPv4-translatable 175 IPv6 address in addition to one using the service's primary IPv6 176 address. A web server might require specific configuration to 177 listen for connections on both the IPv4-translatable and the 178 primary IPv6 address. A High-Availability cluster service must be 179 set up to fail over both addresses between cluster nodes, and 180 depending on how the IPv6 network learns the location of the 181 IPv4-translatable IPv6 address, the fail-over mechanism used for 182 the two addresses might be completely different. Service 183 monitoring must be done for both the IPv4-translatable and the 184 primary IPv6 address, and any trouble-shooting procedures must be 185 extended to involve both addresses. 187 In short, the use of IPv4-translatable IPv6 addresses in parallel 188 with regular IPv6 addresses is in many ways analogous to the use of 189 Dual Stack [RFC4213]. While no actual IPv4 packets are used, the 190 IPv4-translatable IPv6 addresses creates a secondary "stack" in the 191 infrastructure that must be treated and operated separately from the 192 primary one. This increases the complexity of the overall 193 infrastructure, in turn increasing operational overhead, and reducing 194 reliability. An operator who for such reasons finds the use Dual 195 Stack unappealing, might feel the same way about using SIIT with 196 IPv4-translatable IPv6 addresses. 198 3. Explicit Address Mapping Algorithm 200 This normative section defines the EAM algorithm. SIIT 201 implementations are REQUIRED to support the specifications herein. 203 3.1. Explicit Address Mapping Table 205 An SIIT implementation MUST include an Explicit Address Mapping Table 206 (EAMT). By default, the EAMT SHOULD be empty. The operator MUST be 207 able to populate the EAMT using the implementation's normal 208 configuration interfaces. The implementation MAY additionally 209 support other ways of populating the EAMT. 211 The EAMT consists of the following columns: 213 IPv4 Prefix 215 IPv6 Prefix 217 SIIT implementations MAY include other columns in order to support 218 proprietary extensions to the EAM algorithm. 220 Throughout this document, figures representing the EAMT contain an 221 Index column using the pound sign as the header. This column is not 222 a required part of this specification; it is included only as a 223 convenience to the reader. 225 3.2. Explicit Address Mapping Specification 227 An EAM consists of an IPv4 Prefix and an IPv6 Prefix. The prefix 228 length MAY be omitted, in which case the implementation MUST assume 229 it to be 32 for IPv4 and 128 for IPv6. Figure 1 illustrates an EAMT 230 containing examples of valid EAMs. 232 Example EAMT 234 +---+----------------+----------------------+ 235 | # | IPv4 Prefix | IPv6 Prefix | 236 +---+----------------+----------------------+ 237 | 1 | 192.0.2.1 | 2001:db8:aaaa:: | 238 | 2 | 192.0.2.2/32 | 2001:db8:bbbb::b/128 | 239 | 3 | 192.0.2.16/28 | 2001:db8:cccc::/124 | 240 | 4 | 192.0.2.128/26 | 2001:db8:dddd::/64 | 241 | 5 | 192.0.2.192/31 | 64:ff9b::/127 | 242 +---+----------------+----------------------+ 244 Figure 1 246 An EAM's IPv4 Prefix value MUST have an identical or smaller number 247 of suffix bits than its corresponding IPv6 Prefix value. 249 Overlapping EAMs SHOULD be considered an error, and attempts to 250 insert them into the EAMT SHOULD be blocked. The behaviour of an 251 SIIT implementation when overlapping EAMs are present in the EAMT is 252 left undefined. 254 When translating a packet between IPv4 and IPv6, an SIIT 255 implementation MUST individually translate each IP address it 256 encounters in the packet's IP headers (including any IP headers 257 contained within ICMP errors) according to Section 3.3. 259 3.3. IP Address Translation Procedure 261 This section describes step-by-step how an SIIT implementation 262 translates addresses between IPv4 and IPv6. Only the outcome of the 263 algorithm described should be considered normative, that is, an SIIT 264 implementation MAY implement the exact procedure differently than 265 what is described here, but the outcome of the algorithm MUST be the 266 same. 268 For concrete examples of IP addresses translations, refer to 269 Appendix B. 271 3.3.1. Address Translation Steps: IPv4 to IPv6 273 1. The EAMT is searched for an EAM entry containing an IPv4 Prefix 274 identical to that of the IPv4 address being translated. The IPv4 275 Prefix and IPv6 Prefix values of the EAM entry found is from now 276 on referred to as EAM4 and EAM6, respectively. 278 2. If no matching EAM entry is found, the EAM algorithm is aborted. 279 The SIIT implementation MUST proceed to translate the address in 280 accordance with [RFC6145] (and its updates). 282 3. The prefix bits of EAM4 are removed from IPv4 address being 283 translated. The remaining suffix bits from the IPv4 address 284 being translated are stored in a temporary buffer. 286 4. The prefix bits of EAM6 are prepended to the temporary buffer. 288 5. If the temporary buffer at this point does not contain a 128-bit 289 value, it is padded with trailing zeroes so that it reaches a 290 length of 128 bits. 292 6. The contents of the temporary buffer is the translated IPv6 293 address. 295 3.3.2. Address Translation Steps: IPv6 to IPv4 297 1. The EAMT is searched for an EAM entry containing an IPv6 Prefix 298 identical to that of the IPv6 address being translated. The IPv4 299 Prefix and IPv6 Prefix values of the EAM entry found is from now 300 on referred to as EAM4 and EAM6, respectively. 302 2. If no matching EAM entry is found, the EAM algorithm is aborted. 303 The SIIT implementation MUST proceed to translate the address in 304 accordance with [RFC6145] (and its updates). 306 3. The prefix bits of EAM6 are removed from IPv6 address being 307 translated. The remaining suffix bits from the IPv6 address 308 being translated are stored in a temporary buffer. 310 4. The prefix bits of EAM4 are prepended to the temporary buffer. 312 5. If the temporary buffer at this point does not contain a 32-bit 313 value, any trailing bits are discarded so that the buffer is 314 reduced to a length of 32 bits. 316 6. The contents of the temporary buffer is the translated IPv4 317 address. 319 4. Lack of Checksum Neutrality 321 When one or both of the address fields in an IP/ICMP packet are 322 translated according to EAM, the translation can not be relied upon 323 to be checksum neutral, even if the well-known prefix 64:ff9b::/96 is 324 used. This consideration is discussed in more detail in Section 4.1 325 of [RFC6052]. 327 5. Security Considerations 329 The EAM algorithm does not introduce any new security issues beyond 330 those that are already discussed in Section 7 of [RFC6145]. 332 6. IANA Considerations 334 This draft makes no request of the IANA. The RFC Editor may remove 335 this section prior to publication. 337 7. Acknowledgements 339 This document was conceived due to comments made by Dave Thaler in 340 the v6ops session at IETF 91 as well as e-mail discussions between 341 Fred Baker and the author. 343 Valuable reviews, suggestions, and other feedback was given by 344 Cameron Byrne, Brian E Carpenter, Alberto Leiva, and Andrew 345 Yourtchenko. 347 8. References 349 8.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, March 1997. 354 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 355 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 356 October 2010. 358 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 359 Algorithm", RFC 6145, April 2011. 361 8.2. Informative References 363 [I-D.anderson-v6ops-siit-dc] 364 tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 365 Data Centre Environments", draft-anderson-v6ops-siit-dc-01 366 (work in progress), October 2014. 368 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 369 for IPv6 Hosts and Routers", RFC 4213, October 2005. 371 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 372 Address Autoconfiguration", RFC 4862, September 2007. 374 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 375 IPv4/IPv6 Translation", RFC 6144, April 2011. 377 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 378 China Education and Research Network (CERNET) IVI 379 Translation Design and Deployment for the IPv4/IPv6 380 Coexistence and Transition", RFC 6219, May 2011. 382 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 383 Combination of Stateful and Stateless Translation", RFC 384 6877, April 2013. 386 [RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, 387 August 2014. 389 Appendix A. Use Cases 391 The following subsections lists some use cases that at the time of 392 writing leverage SIIT with the EAM algorithm. 394 A.1. 464XLAT 396 When the CLAT component in the 464XLAT [RFC6877] architecture does 397 not have a dedicated IPv6 prefix assigned, it may instead use "one 398 interface IPv6 address that is claimed by the CLAT". This IPv6 399 address might not be IPv4-translatable. If this is the case, the 400 CLAT essentially implements the EAM algorithm using an EAMT as 401 follows (assuming the CLAT's IPv4 address is picked from the IPv4 402 Service Continuity Prefix [RFC7335]): 404 Example EAMT for an 464XLAT CLAT 406 +---+--------------+-------------------------------+ 407 | # | IPv4 Prefix | IPv6 Prefix | 408 +---+--------------+-------------------------------+ 409 | 1 | 192.0.0.1/32 | CLAT_claimed_IPv6_address/128 | 410 +---+--------------+-------------------------------+ 412 Figure 2 414 In this particular use case, the EAM algorithm is used to translate 415 IPv6 destination addresses to IPv4, and conversely, IPv4 source 416 addresses to IPv6. Other addresses are translated using [RFC6052]. 417 Note that this is the exact opposite of the SIIT-DC use case 418 (Appendix A.3). 420 A.2. IVI 422 IVI [RFC6219] describes a stateless translation model that embeds 423 IPv4 addresses in a 40-bit translation prefix where bits 33-40 are 424 required to be 1. The embedded IPv4 address is located in bits 41-72 425 of the IPv6 address. Bits 73-128 are required to be 0. 427 The location of the eight least significant IPv4 address bits makes 428 the IVI address mapping differ from [RFC6052]. 430 Example EAMT for IVI 432 +---+-------------+--------------------+ 433 | # | IPv4 Prefix | IPv6 Prefix | 434 +---+-------------+--------------------+ 435 | 1 | 0.0.0.0/0 | 2001:db8:ff00::/40 | 436 +---+-------------+--------------------+ 438 Figure 3 440 In this particular use case, all addresses are translated according 441 to the EAM algorithm. In other words, [RFC6052] mapping is not used 442 at all. 444 A.3. SIIT-DC 445 SIIT-DC [I-D.anderson-v6ops-siit-dc] describes the use of SIIT to 446 facilitate connectivity from the IPv4 Internet to services hosted in 447 an IPv6-only data centre. In order to avoid the constraints relating 448 to the use of IPv4-translatable IPv6 addresses discussed in Section 2 449 the stateless IPv4/IPv6 translators are provisioned with an EAMT 450 containing one entry per IPv6-only service that are to be made 451 available from the IPv4 Internet, for example (assuming 452 2001:db8:aaaa::1 and 2001:db8:bbbb::1 are assigned to load balancers 453 or servers that provides the IPv6-only services in question): 455 Example EAMT for SIIT-DC 457 +---+--------------+----------------------+ 458 | # | IPv4 Prefix | IPv6 Prefix | 459 +---+--------------+----------------------+ 460 | 1 | 192.0.2.1/32 | 2001:db8:aaaa::1/128 | 461 | 2 | 192.0.2.2/32 | 2001:db8:bbbb::1/128 | 462 +---+--------------+----------------------+ 464 Figure 4 466 In this particular use case, the EAM algorithm is used to translate 467 IPv4 destination addresses to IPv6, and conversely, IPv6 source 468 addresses to IPv4. Other addresses are translated using [RFC6052]. 469 Note that this is the exact opposite of the 464XLAT use case 470 (Appendix A.1). 472 Appendix B. Example IP Address Translations 474 Figure 5 demonstrates how a set of example IP addresses are 475 translated given the example EAMT in Figure 1. Implementors may use 476 the examples given to develop test cases to validate correct 477 operation. Note that the address translations are bidirectional, so 478 a single row in the table describes two address translations: IPv4 to 479 IPv6, and IPv6 to IPv4. 481 It is also assumed that the [RFC6052] translation prefix is 482 configured to be 64:ff9b::/96. 484 Example IP Address Translations 486 +--------------+------------------------+-----------------------+ 487 | IPv4 Address | IPv6 Address | Comment | 488 +--------------+------------------------+-----------------------+ 489 | 192.0.2.1 | 2001:db8:aaaa:: | According to EAM #1 | 490 | 192.0.2.2 | 2001:db8:bbbb::b | According to EAM #2 | 491 | 192.0.2.16 | 2001:db8:cccc:: | According to EAM #3 | 492 | 192.0.2.24 | 2001:db8:cccc::8 | According to EAM #3 | 493 | 192.0.2.31 | 2001:db8:cccc::f | According to EAM #3 | 494 | 192.0.2.128 | 2001:db8:dddd:: | According to EAM #4 | 495 | 192.0.2.152 | 2001:db8:dddd:0:6000:: | According to EAM #4 | 496 | 192.0.2.183 | 2001:db8:dddd:0:dc00:: | According to EAM #4 | 497 | 192.0.2.191 | 2001:db8:dddd:0:fc00:: | According to EAM #4 | 498 | 192.0.2.193 | 64:ff9b::1 | According to EAM #5 | 499 | 192.0.2.200 | 64:ff9b::c000:2c8 | According to RFC 6052 | 500 +--------------+------------------------+-----------------------+ 502 Figure 5 504 Author's Address 506 Tore Anderson 507 Redpill Linpro 508 Vitaminveien 1A 509 0485 Oslo 510 Norway 512 Phone: +47 959 31 212 513 Email: tore@redpill-linpro.com 514 URI: http://www.redpill-linpro.com