idnits 2.17.1 draft-ietf-behave-address-format-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2765, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2010) is 5212 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) == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-04 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-03 -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Microsoft Corporation 4 Obsoletes: 2765 (if approved) C. Bao 5 Intended status: Standards Track CERNET Center/Tsinghua University 6 Expires: July 19, 2010 M. Bagnulo 7 UC3M 8 M. Boucadair 9 France Telecom 10 X. Li 11 CERNET Center/Tsinghua University 12 January 15, 2010 14 IPv6 Addressing of IPv4/IPv6 Translators 15 draft-ietf-behave-address-format-04.txt 17 Abstract 19 This document discusses the algorithmic translation of an IPv6 20 address to a corresponding IPv4 address, and vice versa, using only 21 statically configured information. It defines a well-known prefix 22 for use in algorithmic translations, while allowing organizations to 23 also use network-specific prefixes when appropriate. Algorithmic 24 translation is used in IPv4/IPv6 translators, as well as other types 25 of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on July 19, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3 69 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. IPv4-Embedded IPv6 Address Format . . . . . . . . . . . . . . 4 72 2.1. Address Translation Algorithms . . . . . . . . . . . . . . 6 73 2.2. Text Representation . . . . . . . . . . . . . . . . . . . 6 74 3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 7 75 3.1. Restrictions on the use of the Well-Known Prefix . . . . . 7 76 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 8 77 3.3. Choice of Prefix for Stateless Translation Deployments . . 8 78 3.4. Choice of Prefix for Stateful Translation Deployments . . 10 79 3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 11 80 3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 13 83 4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 13 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 86 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 89 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 This document is part of a series of IPv4/IPv6 translation documents. 95 A framework for IPv4/IPv6 translation is discussed in 96 [I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios 97 that will be used in this document. Other documents specify the 98 behavior of various types of translators and gateways, including 99 mechanisms for translating between IP headers and other types of 100 messages that include IP addresses. This document specifies how an 101 individual IPv6 address is translated to a corresponding IPv4 102 address, and vice versa, in cases where an algorithmic mapping is 103 used. While specific types of devices are used herein as examples, 104 it is the responsibility of the specification of such devices to 105 reference this document for algorithmic mapping of the addresses 106 themselves. 108 This document reserves a "Well-Known Prefix" for use in an 109 algorithmic mapping. The value of this IPv6 prefix is: 111 64:FF9B::/96 113 Section 2 describes the format of "IPv4-Embedded IPv6 addresses", 114 i.e., IPv6 addresses in which 32 bits contain an IPv4 address. This 115 format is common to both "IPv4-Converted" and "IPv4-Translatable" 116 IPv6 addresses. This section also defines the algorithms for 117 translating addresses, and the text representation of IPv4-Embedded 118 IPv6 addresses. 120 Section 3 discusses the choice of prefixes, the conditions of use of 121 the Well-Known Prefix and Network-Specific Prefixes, and the use of 122 IPv4-Embedded IPv6 addresses with stateless and stateful translation. 124 Section 4 discusses security concerns. 126 In some scenarios, a dual-stack host will unnecessarily send its 127 traffic through an IPv6/IPv4 translator. This can be caused by 128 host's default address selection algorithm [RFC3484], referrals, or 129 other reasons. Optimizing these scenarios for dual-stack hosts is 130 for future study. 132 1.1. Applicability Scope 134 This document is part of a series defining address translation 135 services. We understand that the address format could also be used 136 by other interconnection methods between IPv6 and IPv4, e.g., methods 137 based on encapsulation. If encapsulation methods are developed by 138 the IETF, we expect that their descriptions will document their 139 specific use of IPv4-Embedded IPv6 addresses. 141 1.2. Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 1.3. Terminology 149 This document makes use of the following terms: 151 IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6 152 packets, and vice versa. It may do "stateless" translation, 153 meaning that there is no per-flow state required, or "stateful" 154 translation where per-flow state is created when the first packet 155 in a flow is received. 156 Address translator: any entity that has to derive an IPv4 address 157 from an IPv6 address or vice versa. This applies not only to 158 devices that do IPv4/IPv6 packet translation, but also to other 159 entities that manipulate addresses, such as name resolution 160 proxies (e.g. DNS64 [I-D.ietf-behave-dns64]) and possibly other 161 types of Application Layer Gateways (ALGs). 162 Well-Known Prefix: the IPv6 prefix defined in this document for use 163 in an algorithmic mapping. 164 Network-Specific Prefix: an IPv6 prefix assigned by an organization 165 for use in algorithmic mapping. Options for the Network Specific 166 Prefix are discussed in Section 3.3 and Section 3.4. 167 IPv4-Embedded IPv6 addresses: IPv6 addresses in which 32 bits 168 contain an IPv4 address. Their format is described in Section 2. 169 IPv4-Converted IPv6 addresses: IPv6 addresses used to represent IPv4 170 nodes in an IPv6 network. They are a variant of IPv4-Embedded 171 IPv6 addresses, and follow the format described in Section 2. 172 IPv4-Translatable IPv6 addresses: IPv6 addresses assigned to IPv6 173 nodes for use with stateless translation. They are a variant of 174 IPv4-Embedded IPv6 addresses, and follow the format described in 175 Section 2. 177 2. IPv4-Embedded IPv6 Address Format 179 IPv4-Converted IPv6 addresses and IPv4-Translatable IPv6 addresses 180 follow the same format, described here as the IPv4-Embedded IPv6 181 address Format. IPv4-Embedded IPv6 addresses are composed of a 182 variable length prefix, the embedded IPv4 address, and a variable 183 length suffix, as presented in the following diagram, in which PL 184 designates the prefix length: 186 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 187 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 188 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 189 |32| prefix |v4(32) | u | suffix | 190 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 191 |40| prefix |v4(24) | u |(8)| suffix | 192 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 193 |48| prefix |v4(16) | u | (16) | suffix | 194 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 195 |56| prefix |(8)| u | v4(24) | suffix | 196 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 197 |64| prefix | u | v4(32) | suffix | 198 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 199 |96| prefix | v4(32) | 200 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 202 Figure 1 204 In these addresses, the prefix shall be either the "Well-Known 205 Prefix", or a "Network-Specific Prefix" unique to the organization 206 deploying the address translators. (The Well-Known prefic is 96 bits 207 long, and can only be used in the last form of the table.) 209 Various deployments justify different prefix lengths with Network- 210 Specific prefixes. The tradeoff between different prefix lengths are 211 discussed in Section 3.3 and Section 3.4. 213 Bits 64 to 71 of the address are reserved for compatibility with the 214 host identifier format defined in the IPv6 addressing architecture 215 [RFC4291]. These bits MUST be set to zero. When using a /96 216 Network-Specific Prefix, the administrators MUST ensure that the bits 217 64 to 71 are set to zero. A simple way to achieve that is to 218 construct the /96 Network-Specific Prefix by picking a /64 prefix, 219 and then adding four octets set to zero. 221 The IPv4 address is encoded following the prefix, most significant 222 bits first. Depending of the prefix length, the 4 octets of the 223 address may be separated by the reserved octet "u", whose 8 bits MUST 224 be set to zero. In particular: 225 o When the prefix is 32 bits long, the IPv4 address is encoded in 226 positions 32 to 63. 227 o When the prefix is 40 bits long, 24 bits of the IPv4 address are 228 encoded in positions 40 to 63, with the remaining 8 bits in 229 position 72 to 79. 230 o When the prefix is 48 bits long, 16 bits of the IPv4 address are 231 encoded in positions 48 to 63, with the remaining 16 bits in 232 position 72 to 87. 234 o When the prefix is 56 bits long, 8 bits of the IPv4 address are 235 encoded in positions 56 to 63, with the remaining 24 bits in 236 position 72 to 95. 237 o When the prefix is 64 bits long, the IPv4 address is encoded in 238 positions 72 to 103. 239 o When the prefix is 96 bits long, the IPv4 address is encoded in 240 positions 96 to 127. 242 There are no remaining bits, and thus no suffix, if the prefix is 96 243 bits long. In the other cases, the remaining bits of the address 244 constitute the suffix. These bits are reserved for future 245 extensions, and SHOULD be set to zero. 247 2.1. Address Translation Algorithms 249 IPv4-Embedded IPv6 addresses are composed according to the following 250 algorithm: 251 o Concatenate the prefix, the 32 bits of the IPv4 address and the 252 null suffix if needed to obtain a 128 bit address. 253 o If the prefix length is less than 96 bits, remove the last octet 254 and insert the null octet "u" at the appropriate position, as 255 documented in Figure 1. 257 The IPv4 addresses are extracted from the IPv4-Embedded IPv6 258 addresses according to the following algorithm: 259 o If the prefix is 96 bit long, extract the last 32 bits of the IPv6 260 address; 261 o for the other prefix lengths, extract the "u" octet to obtain a 262 120 bit sequence, then extract the 32 bits following the prefix. 264 2.2. Text Representation 266 IPv4-Embedded IPv6 addresses will be represented in text in 267 conformity with section 2.2 of [RFC4291]. IPv4-Embedded IPv6 268 addresses constructed using the Well-Known Prefix or a /96 Network- 269 Specific Prefix may be represented using the alternative form 270 presented in section 2.2 of [RFC4291], with the embedded IPv4 address 271 represented in dotted decimal notation. Examples of such 272 representations are presented in Table 1 and Table 2. 274 +-----------------------+------------+------------------------------+ 275 | Network-Specific | IPv4 | IPv4-Embedded IPv6 address | 276 | Prefix | address | | 277 +-----------------------+------------+------------------------------+ 278 | 2001:DB8::/32 | 192.0.2.33 | 2001:DB8:C000:221:: | 279 | 2001:DB8:100::/40 | 192.0.2.33 | 2001:DB8:1C0:2:21:: | 280 | 2001:DB8:122::/48 | 192.0.2.33 | 2001:DB8:122:C000:2:2100:: | 281 | 2001:DB8:122:300::/56 | 192.0.2.33 | 2001:DB8:122:3C0:0:221:: | 282 | 2001:DB8:122:344::/64 | 192.0.2.33 | 2001:DB8:122:344:C0:2:2100:: | 283 | 2001:DB8:122:344::/96 | 192.0.2.33 | 2001:DB8:122:344::192.0.2.33 | 284 +-----------------------+------------+------------------------------+ 286 Table 1: Text representation of IPv4-Embedded IPv6 addresses using 287 Network-Specific Prefixes 289 +-------------------+--------------+----------------------------+ 290 | Well Known Prefix | IPv4 address | IPv4-Embedded IPv6 address | 291 +-------------------+--------------+----------------------------+ 292 | 64:FF9B::/96 | 192.0.2.33 | 64:FF9B::192.0.2.33 | 293 +-------------------+--------------+----------------------------+ 295 Table 2: Text representation of IPv4-Embedded IPv6 addresses using 296 the Well-Known Prefix 298 The Network-Specific Prefix examples in Table 1 are derived from the 299 IPv6 prefix reserved for documentation in [RFC3849]. The IPv4 300 address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for 301 documentation in [RFC3330]. 303 3. Deployment Guidelines and Choices 305 3.1. Restrictions on the use of the Well-Known Prefix 307 The Well-Known Prefix MAY be used by organizations deploying 308 translation services, as explained in Section 3.4. 310 The Well-Known Prefix SHOULD NOT be used to construct IPv4- 311 Translatable addresses. The nodes served by IPv4-Translatable IPv6 312 addresses should be able to receive global IPv6 traffic bound to 313 their IPv4-Translatable IPv6 address without incurring intermediate 314 protocol translation. This is only possible if the specific prefix 315 used to build the IPv4-Translatable IPv6 addresses is advertized in 316 inter-domain routing, but the advertisement of more specific prefixes 317 derived from the Well-Known Prefix is not supported, as explained in 318 Section 3.2. Network-Specific Prefixes SHOULD be used in these 319 scenarios, as explained in Section 3.3. 321 The Well-Known Prefix MUST NOT be used to represent non global IPv4 322 addresses, such as those defined in [RFC1918]. 324 3.2. Impact on Inter-Domain Routing 326 The Well-Known Prefix MAY appear in inter-domain routing tables, if 327 service providers decide to provide IPv6-IPv4 interconnection 328 services to peers. Advertisement of the Well-Known Prefix SHOULD be 329 controlled either by upstream and/or downstream service providers 330 owing to inter-domain routing policies, e.g., through configuration 331 of BGP [RFC4271]. Organizations that advertize the Well-Known Prefix 332 in inter-domain routing MUST be able to provide IPv4/IPv6 translation 333 service. 335 When the IPv4/IPv6 translation relies on the Well-Known Prefix, 336 embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be 337 advertised in BGP (especially e-BGP) [RFC4271] because this leads to 338 importing the IPv4 routing table into the IPv6 one and therefore 339 induces scalability issues to the global IPv6 routing table. 340 Administrators of BGP nodes SHOULD configure filters that discard 341 advertisements of embedded IPv6 prefixes longer than the Well-Known 342 Prefix. 344 When the IPv4/IPv6 translation service relies on Network-Specific 345 Prefixes, the IPv4-Translatable IPv6 prefixes used in stateless 346 translation MUST be advertised with proper aggregation to the IPv6 347 Internet. Similarly, if translators are configured with multiple 348 Network-Specific Prefixes,these prefixes MUST be advertised to the 349 IPv6 Internet with proper aggregation. 351 3.3. Choice of Prefix for Stateless Translation Deployments 353 Organizations may deploy translation services using stateless 354 translation. In these deployments, internal IPv6 nodes are addressed 355 using IPv4-Translatable IPv6 addresses, which enable them to be 356 accessed by IPv4 nodes. The addresses of these external nodes are 357 then represented in IPv4-Converted IPv6 addresses. 359 Organizations deploying stateless IPv4/IPv6 translation SHOULD assign 360 a Network-Specific Prefix to their IPv4/IPv6 translation service. 361 IPv4-Translatable and IPv4-Converted IPv6 addresses MUST be 362 constructed as specified in Section 2. IPv4-Translatable IPv6 363 addresses MUST use the selected Network-Specific Prefix. Both types 364 of addresses SHOULD use the same prefix. 366 Using the same prefix ensures that IPv6 nodes internal to the 367 organization will use the most efficient paths to reach the nodes 368 served by IPv4-Translatable IPv6 addresses. Specifically, if a node 369 learns the IPv4 address of a target internal node without knowing 370 that this target is in fact located behind the same translator that 371 the node also uses, translation rules will ensure that the IPv6 372 address constructed with the Network-Specific prefix is the same as 373 the IPv4-Translatable IPv6 address assigned to the target. Standard 374 routing preference will then ensure that the IPv6 packets are 375 delivered directly, without requiring "hair-pinning" at the 376 translator. 378 The intra-domain routing protocol must be able to deliver packets to 379 the nodes served by IPv4-Translatable IPv6 addresses. This may 380 require routing on some or all of the embedded IPv4 address bits. 381 Security considerations detailed in Section 4 require that routers 382 check the validity of the IPv4-Translatable IPv6 source addresses, 383 using some form of reverse path check. 385 The management of stateless address translation can be illustrated 386 with a small example. We will consider an IPv6 network with the 387 prefix 2001:DB8:122::/48. The network administrator has selected the 388 Network-Specific prefix 2001:DB8:122:344::/64 for managing stateless 389 IPv4/IPv6 translation. The network is visible in IPv4 as the subnet 390 192.0.2.0/24. In this network, the host A is assigned the IPv4- 391 Translatable IPv6 address 2001:DB8:122:344:C0:2:2100::, which 392 corresponds to the IPv4 address 192.0.2.33. Host A's address is 393 configured either manually or through DHCPv6. 395 In this example, host A is not directly connected to the translator, 396 but instead to a link managed by a router R. The router R is 397 configured to forward to A the packets bound to 2001:DB8:122:344:C0: 398 2:2100::. To receive these packets, R will advertise reachability of 399 the prefix 2001:DB8:122:344:C0:2:2100::/104 in the intra-domain 400 routing protocol -- or perhaps a shorter prefix if many hosts on link 401 have IPv4-Translatable IPv6 addresses derived from the same IPv4 402 subnet. If a packet bound to 192.0.2.33 reaches the translator, the 403 destination address will be translated to 2001:DB8:122:344:C0:2: 404 2100::, and the packet will be routed towards R and then to A. 406 Let's suppose now that a host B of the same domain learns the IPv4 407 address of A, maybe through an application-specific referral. If B 408 has translation-aware software, B can compose a destination address 409 by combining the Network-Specific Prefix 2001:DB8:122:344::/64 and 410 the IPv4 address 192.0.2.33, resulting in the address 2001:DB8:122: 411 344:C0:2:2100::. The packet sent by B will be forwarded towards R, 412 and then to A, avoiding protocol translation. 414 Forwarding, and reverse path checks, should be performed on the 415 combination of the prefix and the IPv4 address. In theory, routers 416 should be able to route on prefixes of any length. However, routing 417 on prefixes larger than 64 bits may be slower on some routers. But 418 routing efficiency is not the only consideration in the choice of a 419 prefix length. Organizations also need to consider the availability 420 of prefixes, and the potential impact of all-zeroes identifiers. 422 If a /32 prefix is used, all the routing bits are contained in the 423 top 64 bits of the IPv6 address, leading to excellent routing 424 properties. These prefixes may however be hard to obtain, and 425 allocation of a /32 to a small set of IPv4-Translatable IPv6 426 addresses may be seen as wasteful. In addition, the /32 prefix and a 427 zero suffix leads to an all-zeroes interface identifier, an issue 428 that we discuss in Section 3.5. 430 Intermediate prefix lengths such as /40, /48 or /56 appear as 431 compromises. Only some of the IPv4 bits are part of the /64 432 prefixes. Reverse path checks, in particular, may have a limited 433 efficiency. Reverse path checks limited to the most significant bits 434 of the IPv4 address will reduce the possibility of spoofing external 435 IPv4 address, but would allow IPv6 nodes to spoof internal IPv4- 436 Translatable addresses. 438 We propose here a compromise, based on using no more than 1/256th of 439 an organization's allocation of IPv6 addresses for the IPv4/IPv6 440 translation service. For example, if the organization is an Internet 441 Service Provider with an allocated IPv6 prefix /32 or shorter, the 442 ISP could dedicate a /40 prefix to the translation service. An end 443 site with a /48 allocation could dedicate a /56 prefix to the 444 translation service, or possibly a /96 prefix if all IPv4- 445 Translatable IPv6 addresses are located on the same link. 447 The recommended prefix length is also a function of the deployment 448 scenario. The stateless translation can be used for Scenario 1, 449 Scenario 2, Scenario 5, and Scenario 6 defined in 450 [I-D.ietf-behave-v6v4-framework]. For different scenarios, the 451 prefix length recommendations are: 452 o For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario 453 2 (the IPv4 Internet to an IPv6 network), we recommend using a /40 454 prefix for an ISP holding a /32 allocation, and a /56 prefix for a 455 site holding a /48 allocation. 456 o For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 457 (an IPv4 network to an IPv6 network), we recommend using a /64 or 458 a /96 prefix. 460 3.4. Choice of Prefix for Stateful Translation Deployments 462 Organizations may deploy translation services based on stateful 463 translation technology. An organization may decide to use either a 464 Network-Specific Prefix or the Well-Known Prefix for its stateful 465 IPv4/IPv6 translation service. 467 When these services are used, IPv6 nodes are addressed through 468 standard IPv6 addresses, while IPv4 nodes are represented by IPv4- 469 Converted IPv6 addresses, as specified in Section 2. 471 The stateful nature of the translation creates a potential stability 472 issue when the organization deploys multiple translators. If several 473 translators use the same prefix, there is a risk that packets 474 belonging to the same connection may be routed to different 475 translators as the internal routing state changes. This issue can be 476 avoided either by assigning different prefixes to different 477 translators, or by ensuring that all translators using same prefix 478 coordinate their state. 480 Stateful translation can be used in scenarios defined in 481 [I-D.ietf-behave-v6v4-framework]. The Well Known Prefix SHOULD be 482 used in these scenarios, with two exceptions: 483 o In all scenarios, the translation MAY use a Network-Specific 484 Prefix, if deemed appropriate for management reasons. 485 o The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 486 Internet to an IPv4 network), as this would lead to using the 487 Well-Known Prefix with non-global IPv4 addresses. That means a 488 Network-Specific Prefix MUST be used in that scenario, for example 489 a /96 prefix compatible with the Well-Known prefix format. 491 3.5. Choice of Suffix 493 The address format described in Section 2 recommends a zero suffix. 494 Before making this recommendation, we considered different options: 495 checksum neutrality; the encoding of a port range; and a value 496 different than 0. 498 In the case of stateless translation, there would be no need for the 499 translator to recompute a one's complement checksum if both the IPv4- 500 Translatable and the IPv4-Converted IPv6 addresses were constructed 501 in a "checksum-neutral" manner, that is if the IPv6 addresses would 502 have the same one's complement checksum as the embedded IPv4 address. 503 In the case of stateful translation, checksum neutrality does not 504 eliminate checksum computation during translation, as only one of the 505 two addresses would be checksum neutral. We considered reserving 16 506 bits in the suffix to guarantee checksum neutrality, but declined 507 because it would not help with stateful translation, and because 508 checksum neutrality can also be achieved by an appropriate choice of 509 the Network-Specific Prefix, as was done for example with the Well- 510 Known Prefix. 512 There have been proposals to complement stateless translation with a 513 port-range feature. Instead of mapping an IPv4 address to exactly 514 one IPv6 prefix, the options would allow several IPv6 nodes to share 515 an IPv4 address, with each node managing a different range of ports. 516 If a port range extension is needed, it could be defined later, using 517 bits currently reserved as null in the suffix. 519 When a /32 prefix is used, an all-zero suffix results in an all-zero 520 interface identifier. We understand the conflict with Section 2.6.1 521 of RFC4291, which specifies that all zeroes are used for the subnet- 522 router anycast address. However, in our specification, there would 523 be only one node with an IPv4-Translatable IPv6 address in the /64 524 subnet, and the anycast semantic would not create confusion. We thus 525 decided to keep the null suffix for now. This issue does not exist 526 for prefixes larger than 32 bits, such as the /40, /56, /64 and /96 527 prefixes that we recommend in Section 3.3. 529 3.6. Choice of the Well-Known Prefix 531 Before making our recommendation of the Well-Known Prefix, we were 532 faced with three choices: 533 o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC 534 2765 Section 2.1; 535 o request IANA to allocate a /32 prefix, 536 o or request allocation of a new /96 prefix. 538 We weighted the pros and cons of these choices before settling on the 539 recommended /96 Well-Known Prefix. 541 The main advantage of the existing IPv4-mapped prefix is that it is 542 already defined. Reusing that prefix would require minimal 543 standardization efforts. However, being already defined is not just 544 an advantage, as there may be side effects of current 545 implementations. When presented with the IPv4-mapped prefix, current 546 versions of Windows and MacOS generate IPv4 packets, but will not 547 send IPv6 packets. If we used the IPv4-mapped prefix, these nodes 548 would not be able to support translation without modification. This 549 will defeat the main purpose of the translation techniques. We thus 550 eliminated the first choice, and decided to not reuse the IPv4-mapped 551 prefix, ::FFFF:0:0/96. 553 A /32 prefix would have allowed the embedded IPv4 address to fit 554 within the top 64 bits of the IPv6 address. This would have 555 facilitated routing and load balancing when an organization deploys 556 several translators. However, such destination-address based load 557 balancing may not be desirable. It is not compatible with STUN in 558 the deployments involving multiple stateful translators, each one 559 having a different pool of IPv4 addresses. STUN compatibility would 560 only be achieved if the translators managed the same pool of IPv4 561 addresses and were able to coordinate their translation state, in 562 which case there is no big advantage to using a /32 prefix rather 563 than a /96 prefix. 565 According to Section 2.2 of [RFC4291], in the legal textual 566 representations of IPv6 addresses, dotted decimal can only appear at 567 the end. The /96 prefix is compatible with that requirement. It 568 enables the dotted decimal notation without requiring an update to 569 [RFC4291]. This representation makes the address format easier to 570 use, and log files easier to read. 572 The prefix that we recommend has the particularity of being "checksum 573 neutral". The sum of the hexadecimal numbers "0064" and "FF9B" is 574 "FFFF", i.e. a value equal to zero in one's complement arithmetic. 575 An IPv4-Embedded IPv6 address constructed with this prefix will have 576 the same one's complement checksum as the embedded IPv4 address. 578 4. Security Considerations 580 4.1. Protection Against Spoofing 582 By and large, IPv4/IPv6 translators can be modeled as special 583 routers, are subject to the same risks, and can implement the same 584 mitigations. There is however a particular risk that directly 585 derives from the practice of embedding IPv4 addresses in IPv6: 586 address spoofing. 588 An attacker could use an IPv4-Embedded IPv6 address as the source 589 address of malicious packets. After translation, the packets will 590 appear as IPv4 packets from the specified source, and the attacker 591 may be hard to track. If left without mitigation, the attack would 592 allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. 594 The mitigation is to implement reverse path checks, and to verify 595 throughout the network that packets are coming from an authorized 596 location. 598 4.2. Secure Configuration 600 The prefixes and formats need to be the configured consistently among 601 multiple devices in the same network (e.g., nodes that need to prefer 602 native over translated addresses, DNS gateways, and IPv4/IPv6 603 translators). As such, the means by which they are learned/ 604 configured MUST be secure. Specifying a default prefix and/or format 605 in implementations provides one way to configure them securely. Any 606 alternative means of configuration is responsible for specifying how 607 to do so securely. 609 5. IANA Considerations 611 The Well Known Prefix falls into the range ::/8 reserved by the IETF. 612 The prefix definition does not require an IANA action. 614 6. Acknowledgements 616 Many people in the Behave WG have contributed to the discussion that 617 led to this document, including Andrew Sullivan, Andrew Yourtchenko, 618 Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, 619 Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus 620 Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip 621 Matthews, Remi Denis-Courmont, Remi Despres and William Waites. 623 Marcelo Bagnulo is partly funded by Trilogy, a research project 624 supported by the European Commission under its Seventh Framework 625 Program. 627 7. Contributors 629 The following individuals co-authored drafts from which text has been 630 incorporated, and are listed in alphabetical order. 632 Congxiao Bao 633 CERNET Center/Tsinghua University 634 Room 225, Main Building, Tsinghua University 635 Beijing, 100084 636 China 637 Phone: +86 62785983 638 Email: congxiao@cernet.edu.cn 640 Dave Thaler 641 Microsoft Corporation 642 One Microsoft Way 643 Redmond, WA 98052 644 USA 645 Phone: +1 425 703 8835 646 Email: dthaler@microsoft.com 648 Fred Baker 649 Cisco Systems 650 Santa Barbara, California 93117 651 USA 652 Phone: +1-408-526-4257 653 Fax: +1-413-473-2403 654 Email: fred@cisco.com 656 Hiroshi Miyata 657 Yokogawa Electric Corporation 658 2-9-32 Nakacho 659 Musashino-shi, Tokyo 180-8750 660 JAPAN 661 Email: h.miyata@jp.yokogawa.com 663 Marcelo Bagnulo 664 Universidad Carlos III de Madrid 665 Av. Universidad 30 666 Leganes, Madrid 28911 667 ESPANA 668 Email: marcelo@it.uc3m.es 670 Xing Li 671 CERNET Center/Tsinghua University 672 Room 225, Main Building, Tsinghua University 673 Beijing, 100084 674 China 675 Phone: +86 62785983 676 Email: xing@cernet.edu.cn 678 8. References 680 8.1. Normative References 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, March 1997. 685 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 686 Architecture", RFC 4291, February 2006. 688 8.2. Informative References 690 [I-D.ietf-behave-dns64] 691 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 692 "DNS64: DNS extensions for Network Address Translation 693 from IPv6 Clients to IPv4 Servers", 694 draft-ietf-behave-dns64-04 (work in progress), 695 December 2009. 697 [I-D.ietf-behave-v6v4-framework] 698 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 699 IPv4/IPv6 Translation", 700 draft-ietf-behave-v6v4-framework-03 (work in progress), 701 October 2009. 703 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 704 E. Lear, "Address Allocation for Private Internets", 705 BCP 5, RFC 1918, February 1996. 707 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 708 September 2002. 710 [RFC3484] Draves, R., "Default Address Selection for Internet 711 Protocol version 6 (IPv6)", RFC 3484, February 2003. 713 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 714 Reserved for Documentation", RFC 3849, July 2004. 716 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 717 Protocol 4 (BGP-4)", RFC 4271, January 2006. 719 Authors' Addresses 721 Christian Huitema 722 Microsoft Corporation 723 One Microsoft Way 724 Redmond, WA 98052-6399 725 U.S.A. 727 Email: huitema@microsoft.com 729 Congxiao Bao 730 CERNET Center/Tsinghua University 731 Room 225, Main Building, Tsinghua University 732 Beijing, 100084 733 China 735 Phone: +86 10-62785983 736 Email: congxiao@cernet.edu.cn 738 Marcelo Bagnulo 739 UC3M 740 Av. Universidad 30 741 Leganes, Madrid 28911 742 Spain 744 Phone: +34-91-6249500 745 Fax: 746 Email: marcelo@it.uc3m.es 747 URI: http://www.it.uc3m.es/marcelo 749 Mohamed Boucadair 750 France Telecom 751 3, Av Francois Chateaux 752 Rennes 350000 753 France 755 Email: mohamed.boucadair@orange-ftgroup.com 756 Xing Li 757 CERNET Center/Tsinghua University 758 Room 225, Main Building, Tsinghua University 759 Beijing, 100084 760 China 762 Phone: +86 10-62785983 763 Email: xing@cernet.edu.cn