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