idnits 2.17.1 draft-ietf-behave-address-format-10.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 4 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 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 (August 16, 2010) is 4964 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) -- Looks like a reference, but probably isn't: '1' on line 674 -- Looks like a reference, but probably isn't: '5' on line 674 == Missing Reference: 'TBD' is mentioned on line 676, but not defined == Missing Reference: 'RFC-ietf-behave-address-format' is mentioned on line 678, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-10 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-09 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 8 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 Updates: 4291 (if approved) C. Huitema 5 Intended status: Standards Track Microsoft Corporation 6 Expires: February 17, 2011 M. Bagnulo 7 UC3M 8 M. Boucadair 9 France Telecom 10 X. Li 11 CERNET Center/Tsinghua University 12 August 16, 2010 14 IPv6 Addressing of IPv4/IPv6 Translators 15 draft-ietf-behave-address-format-10.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 February 17, 2011. 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 . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . 5 68 2.3. Address Translation Algorithms . . . . . . . . . . . . . . 6 69 2.4. Text Representation . . . . . . . . . . . . . . . . . . . 7 70 3. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 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 4. Design choices . . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.1. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 12 77 4.2. Choice of the Well-Known Prefix . . . . . . . . . . . . . 12 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 5.1. Protection Against Spoofing . . . . . . . . . . . . . . . 14 80 5.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 14 81 5.3. Firewall Configuration . . . . . . . . . . . . . . . . . . 14 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 84 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 This document is part of a series of IPv4/IPv6 translation documents. 93 A framework for IPv4/IPv6 translation is discussed in 94 [I-D.ietf-behave-v6v4-framework], including a taxonomy of scenarios 95 that will be used in this document. Other documents specify the 96 behavior of various types of translators and gateways, including 97 mechanisms for translating between IP headers and other types of 98 messages that include IP addresses. This document specifies how an 99 individual IPv6 address is translated to a corresponding IPv4 100 address, and vice versa, in cases where an algorithmic mapping is 101 used. While specific types of devices are used herein as examples, 102 it is the responsibility of the specification of such devices to 103 reference this document for algorithmic mapping of the addresses 104 themselves. 106 Section 2 describes the prefixes and the format of "IPv4-Embedded 107 IPv6 addresses", i.e., IPv6 addresses in which 32 bits contain an 108 IPv4 address. This format is common to both "IPv4-converted" and 109 "IPv4-Translatable" IPv6 addresses. This section also defines the 110 algorithms for translating addresses, and the text representation of 111 IPv4-Embedded IPv6 addresses. 113 Section 3 discusses the choice of prefixes, the conditions in which 114 they can be used, and the use of IPv4-Embedded IPv6 addresses with 115 stateless and stateful translation. 117 Section 4 provides a summary of the discussions behind two specific 118 design decisions, the choice of a null suffix and the specific value 119 of the selected prefix. 121 Section 5 discusses security concerns. 123 In some scenarios, a dual-stack host will unnecessarily send its 124 traffic through an IPv6/IPv4 translator. This can be caused by 125 host's default address selection algorithm [RFC3484], referrals, or 126 other reasons. Optimizing these scenarios for dual-stack hosts is 127 for future study. 129 1.1. Applicability Scope 131 This document is part of a series defining address translation 132 services. We understand that the address format could also be used 133 by other interconnection methods between IPv6 and IPv4, e.g., methods 134 based on encapsulation. If encapsulation methods are developed by 135 the IETF, we expect that their descriptions will document their 136 specific use of IPv4-Embedded IPv6 addresses. 138 1.2. Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 1.3. Terminology 146 This document makes use of the following terms: 148 Address translator: any entity that has to derive an IPv4 address 149 from an IPv6 address or vice versa. This applies not only to 150 devices that do IPv4/IPv6 packet translation, but also to other 151 entities that manipulate addresses, such as name resolution 152 proxies (e.g. DNS64 [I-D.ietf-behave-dns64]) and possibly other 153 types of Application Layer Gateways (ALGs). 154 IPv4-converted IPv6 addresses: IPv6 addresses used to represent IPv4 155 nodes in an IPv6 network. They are a variant of IPv4-Embedded 156 IPv6 addresses, and follow the format described in Section 2.2. 157 IPv4-Embedded IPv6 addresses: IPv6 addresses in which 32 bits 158 contain an IPv4 address. Their format is described in 159 Section 2.2. 160 IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6 161 packets, and vice versa. It may do "stateless" translation, 162 meaning that there is no per-flow state required, or "stateful" 163 translation where per-flow state is created when the first packet 164 in a flow is received. 165 IPv4-Translatable IPv6 addresses: IPv6 addresses assigned to IPv6 166 nodes for use with stateless translation. They are a variant of 167 IPv4-Embedded IPv6 addresses, and follow the format described in 168 Section 2.2. 169 Network-Specific Prefix: an IPv6 prefix assigned by an organization 170 for use in algorithmic mapping. Options for the Network Specific 171 Prefix are discussed in Section 3.3 and Section 3.4. 172 Well-Known Prefix: the IPv6 prefix defined in this document for use 173 in an algorithmic mapping. 175 2. IPv4-Embedded IPv6 Address Prefix and Format 177 2.1. Well Known Prefix 179 This document reserves a "Well-Known Prefix" for use in an 180 algorithmic mapping. The value of this IPv6 prefix is: 182 64:ff9b::/96 184 2.2. IPv4-Embedded IPv6 Address Format 186 IPv4-converted IPv6 addresses and IPv4-Translatable IPv6 addresses 187 follow the same format, described here as the IPv4-Embedded IPv6 188 address Format. IPv4-Embedded IPv6 addresses are composed of a 189 variable length prefix, the embedded IPv4 address, and a variable 190 length suffix, as presented in the following diagram, in which PL 191 designates the prefix length: 193 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 194 |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------| 195 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 196 |32| prefix |v4(32) | u | suffix | 197 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 198 |40| prefix |v4(24) | u |(8)| suffix | 199 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 200 |48| prefix |v4(16) | u | (16) | suffix | 201 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 202 |56| prefix |(8)| u | v4(24) | suffix | 203 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 204 |64| prefix | u | v4(32) | suffix | 205 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 206 |96| prefix | v4(32) | 207 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 209 Figure 1 211 In these addresses, the prefix shall be either the "Well-Known 212 Prefix", or a "Network-Specific Prefix" unique to the organization 213 deploying the address translators. The prefixes can only have one of 214 the following lengths: 32, 40, 48, 56, 64 or 96. (The Well-Known 215 Prefix is 96 bits long, and can only be used in the last form of the 216 table.) 218 Various deployments justify different prefix lengths with Network- 219 Specific prefixes. The tradeoff between different prefix lengths are 220 discussed in Section 3.3 and Section 3.4. 222 Bits 64 to 71 of the address are reserved for compatibility with the 223 host identifier format defined in the IPv6 addressing architecture 224 [RFC4291]. These bits MUST be set to zero. When using a /96 225 Network-Specific Prefix, the administrators MUST ensure that the bits 226 64 to 71 are set to zero. A simple way to achieve that is to 227 construct the /96 Network-Specific Prefix by picking a /64 prefix, 228 and then adding four octets set to zero. 230 The IPv4 address is encoded following the prefix, most significant 231 bits first. Depending of the prefix length, the 4 octets of the 232 address may be separated by the reserved octet "u", whose 8 bits MUST 233 be set to zero. In particular: 234 o When the prefix is 32 bits long, the IPv4 address is encoded in 235 positions 32 to 63. 236 o When the prefix is 40 bits long, 24 bits of the IPv4 address are 237 encoded in positions 40 to 63, with the remaining 8 bits in 238 position 72 to 79. 239 o When the prefix is 48 bits long, 16 bits of the IPv4 address are 240 encoded in positions 48 to 63, with the remaining 16 bits in 241 position 72 to 87. 242 o When the prefix is 56 bits long, 8 bits of the IPv4 address are 243 encoded in positions 56 to 63, with the remaining 24 bits in 244 position 72 to 95. 245 o When the prefix is 64 bits long, the IPv4 address is encoded in 246 positions 72 to 103. 247 o When the prefix is 96 bits long, the IPv4 address is encoded in 248 positions 96 to 127. 250 There are no remaining bits, and thus no suffix, if the prefix is 96 251 bits long. In the other cases, the remaining bits of the address 252 constitute the suffix. These bits are reserved for future 253 extensions, and SHOULD be set to zero. Address translators who 254 receive IPv4 embedded IPv6 addresses where these bits are not zero 255 SHOULD ignore the bits' value and proceed as if the bits' value was 256 zero. (Future extensions may specify a different behavior.) 258 2.3. Address Translation Algorithms 260 IPv4-Embedded IPv6 addresses are composed according to the following 261 algorithm: 262 o Concatenate the prefix, the 32 bits of the IPv4 address and the 263 suffix if needed to obtain a 128 bit address. 264 o If the prefix length is less than 96 bits, insert the null octet 265 "u" at the appropriate position (bits 64 to 71), thus causing the 266 least significant octet to be excluded, as documented in Figure 1. 268 The IPv4 addresses are extracted from the IPv4-Embedded IPv6 269 addresses according to the following algorithm: 270 o If the prefix is 96 bit long, extract the last 32 bits of the IPv6 271 address; 272 o for the other prefix lengths, remove the "u" octet to obtain a 120 273 bit sequence (effectively shifting bits 72-127 to positions 64- 274 119), then extract the 32 bits following the prefix. 276 2.4. Text Representation 278 IPv4-Embedded IPv6 addresses will be represented in text in 279 conformity with section 2.2 of [RFC4291]. IPv4-Embedded IPv6 280 addresses constructed using the Well-Known Prefix or a /96 Network- 281 Specific Prefix may be represented using the alternative form 282 presented in section 2.2 of [RFC4291], with the embedded IPv4 address 283 represented in dotted decimal notation. Examples of such 284 representations are presented in Table 1 and Table 2. 286 +-----------------------+------------+------------------------------+ 287 | Network-Specific | IPv4 | IPv4-Embedded IPv6 address | 288 | Prefix | address | | 289 +-----------------------+------------+------------------------------+ 290 | 2001:db8::/32 | 192.0.2.33 | 2001:db8:c000:221:: | 291 | 2001:db8:100::/40 | 192.0.2.33 | 2001:db8:1c0:2:21:: | 292 | 2001:db8:122::/48 | 192.0.2.33 | 2001:db8:122:c000:2:2100:: | 293 | 2001:db8:122:300::/56 | 192.0.2.33 | 2001:db8:122:3c0:0:221:: | 294 | 2001:db8:122:344::/64 | 192.0.2.33 | 2001:db8:122:344:c0:2:2100:: | 295 | 2001:db8:122:344::/96 | 192.0.2.33 | 2001:db8:122:344::192.0.2.33 | 296 +-----------------------+------------+------------------------------+ 298 Table 1: Text representation of IPv4-Embedded IPv6 addresses using 299 Network-Specific Prefixes 301 +-------------------+--------------+----------------------------+ 302 | Well Known Prefix | IPv4 address | IPv4-Embedded IPv6 address | 303 +-------------------+--------------+----------------------------+ 304 | 64:ff9b::/96 | 192.0.2.33 | 64:ff9b::192.0.2.33 | 305 +-------------------+--------------+----------------------------+ 307 Table 2: Text representation of IPv4-Embedded IPv6 addresses using 308 the Well-Known Prefix 310 The Network-Specific Prefix examples in Table 1 are derived from the 311 IPv6 prefix reserved for documentation in [RFC3849]. The IPv4 312 address 192.0.2.33 is part of the subnet 192.0.2.0/24 reserved for 313 documentation in [RFC5735]. The representation of IPv6 addresses is 314 compatible with [I-D.ietf-6man-text-addr-representation]. 316 3. Deployment Guidelines 318 3.1. Restrictions on the use of the Well-Known Prefix 320 The Well-Known Prefix MUST NOT be used to represent non global IPv4 321 addresses, such as those defined in [RFC1918] or listed in section 3 322 of [RFC5735]. Address translators MUST NOT translate packets in 323 which an address is composed of the Well-Known Prefix and a non 324 global IPv4 address, they MUST drop these packets. 326 The Well-Known Prefix SHOULD NOT be used to construct IPv4- 327 Translatable IPv6 addresses. The nodes served by IPv4-Translatable 328 IPv6 addresses should be able to receive global IPv6 traffic bound to 329 their IPv4-Translatable IPv6 address without incurring intermediate 330 protocol translation. This is only possible if the specific prefix 331 used to build the IPv4-Translatable IPv6 addresses is advertized in 332 inter-domain routing, but the advertisement of more specific prefixes 333 derived from the Well-Known Prefix is not supported, as explained in 334 Section 3.2. Network-Specific Prefixes SHOULD be used in these 335 scenarios, as explained in Section 3.3. 337 The Well-Known Prefix MAY be used by organizations deploying 338 translation services, as explained in Section 3.4. 340 3.2. Impact on Inter-Domain Routing 342 The Well-Known Prefix MAY appear in inter-domain routing tables, if 343 service providers decide to provide IPv6-IPv4 interconnection 344 services to peers. Advertisement of the Well-Known Prefix SHOULD be 345 controlled either by upstream and/or downstream service providers 346 according to inter-domain routing policies, e.g., through 347 configuration of BGP [RFC4271]. Organizations that advertize the 348 Well-Known Prefix in inter-domain routing MUST be able to provide 349 IPv4/IPv6 translation service. 351 When the IPv4/IPv6 translation relies on the Well-Known Prefix, IPv4 352 Embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be 353 advertised in BGP (especially e-BGP) [RFC4271] because this leads to 354 importing the IPv4 routing table into the IPv6 one and therefore 355 introduces scalability issues to the global IPv6 routing table. 356 Administrators of BGP nodes SHOULD configure filters that discard 357 advertisements of embedded IPv6 prefixes longer than the Well-Known 358 Prefix. 360 When the IPv4/IPv6 translation service relies on Network-Specific 361 Prefixes, the IPv4-Translatable IPv6 prefixes used in stateless 362 translation MUST be advertised with proper aggregation to the IPv6 363 Internet. Similarly, if translators are configured with multiple 364 Network-Specific Prefixes, these prefixes MUST be advertised to the 365 IPv6 Internet with proper aggregation. 367 3.3. Choice of Prefix for Stateless Translation Deployments 369 Organizations may deploy translation services using stateless 370 translation. In these deployments, internal IPv6 nodes are addressed 371 using IPv4-Translatable IPv6 addresses, which enable them to be 372 accessed by IPv4 nodes. The addresses of these external IPv4 nodes 373 are then represented in IPv4-converted IPv6 addresses. 375 Organizations deploying stateless IPv4/IPv6 translation SHOULD assign 376 a Network-Specific Prefix to their IPv4/IPv6 translation service. 377 IPv4-Translatable and IPv4-converted IPv6 addresses MUST be 378 constructed as specified in Section 2.2. IPv4-Translatable IPv6 379 addresses MUST use the selected Network-Specific Prefix. Both IPv4- 380 Translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD 381 use the same prefix. 383 Using the same prefix ensures that IPv6 nodes internal to the 384 organization will use the most efficient paths to reach the nodes 385 served by IPv4-Translatable IPv6 addresses. Specifically, if a node 386 learns the IPv4 address of a target internal node without knowing 387 that this target is in fact located behind the same translator that 388 the node also uses, translation rules will ensure that the IPv6 389 address constructed with the Network-Specific prefix is the same as 390 the IPv4-Translatable IPv6 address assigned to the target. Standard 391 routing preference (more specific wins) will then ensure that the 392 IPv6 packets are delivered directly, without requiring that 393 translators receive the packets and then return them in the direction 394 they came from. 396 The intra-domain routing protocol must be able to deliver packets to 397 the nodes served by IPv4-Translatable IPv6 addresses. This may 398 require routing on some or all of the embedded IPv4 address bits. 399 Security considerations detailed in Section 5 require that routers 400 check the validity of the IPv4-Translatable IPv6 source addresses, 401 using some form of reverse path check. 403 The management of stateless address translation can be illustrated 404 with a small example: 406 We will consider an IPv6 network with the prefix 2001:db8: 407 122::/48. The network administrator has selected the Network- 408 Specific prefix 2001:db8:122:344::/64 for managing stateless IPv4/ 409 IPv6 translation. The IPv4-Translatable address block for IPv4 410 subnet 192.0.2.0/24 is 2001:db8:122:344:c0:2::/96. In this 411 network, the host A is assigned the IPv4-Translatable IPv6 address 412 2001:db8:122:344:c0:2:2100::, which corresponds to the IPv4 413 address 192.0.2.33. Host A's address is configured either 414 manually or through DHCPv6. 416 In this example, host A is not directly connected to the 417 translator, but instead to a link managed by a router R. The 418 router R is configured to forward to A the packets bound to 2001: 420 db8:122:344:c0:2:2100::. To receive these packets, R will 421 advertise reachability of the prefix 2001:db8:122:344:c0:2:2100::/ 422 104 in the intra-domain routing protocol -- or perhaps a shorter 423 prefix if many hosts on link have IPv4-Translatable IPv6 addresses 424 derived from the same IPv4 subnet. If a packet bound to 425 192.0.2.33 reaches the translator, the destination address will be 426 translated to 2001:db8:122:344:c0:2:2100::, and the packet will be 427 routed towards R and then to A. 429 Let's suppose now that a host B of the same domain learns the IPv4 430 address of A, maybe through an application-specific referral. If 431 B has translation-aware software, B can compose a destination 432 address by combining the Network-Specific Prefix 2001:db8:122: 433 344::/64 and the IPv4 address 192.0.2.33, resulting in the address 434 2001:db8:122:344:c0:2:2100::. The packet sent by B will be 435 forwarded towards R, and then to A, avoiding protocol translation. 437 Forwarding, and reverse path checks, are more efficient when 438 performed on the combination of the prefix and the IPv4 address. In 439 theory, routers are able to route on prefixes of any length, but in 440 practice there may be routers for which routing on prefixes larger 441 than 64 bits is slower. But routing efficiency is not the only 442 consideration in the choice of a prefix length. Organizations also 443 need to consider the availability of prefixes, and the potential 444 impact of all-zeroes identifiers. 446 If a /32 prefix is used, all the routing bits are contained in the 447 top 64 bits of the IPv6 address, leading to excellent routing 448 properties. These prefixes may however be hard to obtain, and 449 allocation of a /32 to a small set of IPv4-Translatable IPv6 450 addresses may be seen as wasteful. In addition, the /32 prefix and a 451 zero suffix leads to an all-zeroes interface identifier, an issue 452 that we discuss in Section 4.1. 454 Intermediate prefix lengths such as /40, /48 or /56 appear as 455 compromises. Only some of the IPv4 bits are part of the /64 456 prefixes. Reverse path checks, in particular, may have a limited 457 efficiency. Reverse path checks limited to the most significant bits 458 of the IPv4 address will reduce the possibility of spoofing external 459 IPv4 addresses, but would allow IPv6 nodes to spoof internal IPv4- 460 Translatable IPv6 addresses. 462 We propose here a compromise, based on using no more than 1/256th of 463 an organization's allocation of IPv6 addresses for the IPv4/IPv6 464 translation service. For example, if the organization is an Internet 465 Service Provider with an allocated IPv6 prefix /32 or shorter, the 466 ISP could dedicate a /40 prefix to the translation service. An end 467 site with a /48 allocation could dedicate a /56 prefix to the 468 translation service, or possibly a /96 prefix if all IPv4- 469 Translatable IPv6 addresses are located on the same link. 471 The recommended prefix length is also a function of the deployment 472 scenario. The stateless translation can be used for Scenario 1, 473 Scenario 2, Scenario 5, and Scenario 6 defined in 474 [I-D.ietf-behave-v6v4-framework]. For different scenarios, the 475 prefix length recommendations are: 476 o For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario 477 2 (the IPv4 Internet to an IPv6 network), an ISP holding a /32 478 allocation SHOULD use a /40 prefix , and a site holding a /48 479 allocation SHOULD use a /56 prefix. 480 o For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 481 (an IPv4 network to an IPv6 network), the deployment SHOULD use a 482 /64 or a /96 prefix. 484 3.4. Choice of Prefix for Stateful Translation Deployments 486 Organizations may deploy translation services based on stateful 487 translation technology. An organization may decide to use either a 488 Network-Specific Prefix or the Well-Known Prefix for its stateful 489 IPv4/IPv6 translation service. 491 When these services are used, IPv6 nodes are addressed through 492 standard IPv6 addresses, while IPv4 nodes are represented by IPv4- 493 converted IPv6 addresses, as specified in Section 2.2. 495 The stateful nature of the translation creates a potential stability 496 issue when the organization deploys multiple translators. If several 497 translators use the same prefix, there is a risk that packets 498 belonging to the same connection may be routed to different 499 translators as the internal routing state changes. This issue can be 500 avoided either by assigning different prefixes to different 501 translators, or by ensuring that all translators using same prefix 502 coordinate their state. 504 Stateful translation can be used in scenarios defined in 505 [I-D.ietf-behave-v6v4-framework]. The Well Known Prefix SHOULD be 506 used in these scenarios, with two exceptions: 507 o In all scenarios, the translation MAY use a Network-Specific 508 Prefix, if deemed appropriate for management reasons. 509 o The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 510 Internet to an IPv4 network), as this would lead to using the 511 Well-Known Prefix with non-global IPv4 addresses. That means a 512 Network-Specific Prefix MUST be used in that scenario, for example 513 a /96 prefix. 515 4. Design choices 517 The prefix that we have chosen reflects two design choices, the null 518 suffix and the specific value of the Well Known Prefix. We provide 519 here a summary of the discussions leading to those two choices. 521 4.1. Choice of Suffix 523 The address format described in Section 2.2 recommends a zero suffix. 524 Before making this recommendation, we considered different options: 525 checksum neutrality; the encoding of a port range; and a value 526 different than 0. 528 In the case of stateless translation, there would be no need for the 529 translator to recompute a one's complement checksum if both the IPv4- 530 Translatable and the IPv4-converted IPv6 addresses were constructed 531 in a "checksum-neutral" manner, that is if the IPv6 addresses would 532 have the same one's complement checksum as the embedded IPv4 address. 533 In the case of stateful translation, checksum neutrality does not 534 eliminate checksum computation during translation, as only one of the 535 two addresses would be checksum neutral. We considered reserving 16 536 bits in the suffix to guarantee checksum neutrality, but declined 537 because it would not help with stateful translation, and because 538 checksum neutrality can also be achieved by an appropriate choice of 539 the Network-Specific Prefix, i.e. selecting a prefix whose one's 540 complement checksum equals either 0 or 0xffff. 542 There have been proposals to complement stateless translation with a 543 port-range feature. Instead of mapping an IPv4 address to exactly 544 one IPv6 prefix, the options would allow several IPv6 nodes to share 545 an IPv4 address, with each node managing a different range of ports. 546 If a port range extension is needed, it could be defined later, using 547 bits currently reserved as null in the suffix. 549 When a /32 prefix is used, an all-zero suffix results in an all-zero 550 interface identifier. We understand the conflict with Section 2.6.1 551 of RFC4291, which specifies that all zeroes are used for the subnet- 552 router anycast address. However, in our specification, there would 553 be only one node with an IPv4-Translatable IPv6 address in the /64 554 subnet, and the anycast semantic would not create confusion. We thus 555 decided to keep the null suffix for now. This issue does not exist 556 for prefixes larger than 32 bits, such as the /40, /56, /64 and /96 557 prefixes that we recommend in Section 3.3. 559 4.2. Choice of the Well-Known Prefix 561 Before making our recommendation of the Well-Known Prefix, we were 562 faced with three choices: 564 o reuse the IPv4-mapped prefix, ::ffff:0:0/96, as specified in RFC 565 2765 Section 2.1; 566 o request IANA to allocate a /32 prefix, 567 o or request allocation of a new /96 prefix. 569 We weighted the pros and cons of these choices before settling on the 570 recommended /96 Well-Known Prefix. 572 The main advantage of the existing IPv4-mapped prefix is that it is 573 already defined. Reusing that prefix would require minimal 574 standardization efforts. However, being already defined is not just 575 an advantage, as there may be side effects of current 576 implementations. When presented with the IPv4-mapped prefix, current 577 versions of Windows and MacOS generate IPv4 packets, but will not 578 send IPv6 packets. If we used the IPv4-mapped prefix, these nodes 579 would not be able to support translation without modification. This 580 will defeat the main purpose of the translation techniques. We thus 581 eliminated the first choice, and decided to not reuse the IPv4-mapped 582 prefix, ::ffff:0:0/96. 584 A /32 prefix would have allowed the embedded IPv4 address to fit 585 within the top 64 bits of the IPv6 address. This would have 586 facilitated routing and load balancing when an organization deploys 587 several translators. However, such destination-address based load 588 balancing may not be desirable. It is not compatible with STUN 589 [RFC5389] in the deployments involving multiple stateful translators, 590 each one having a different pool of IPv4 addresses. STUN 591 compatibility would only be achieved if the translators managed the 592 same pool of IPv4 addresses and were able to coordinate their 593 translation state, in which case there is no big advantage to using a 594 /32 prefix rather than a /96 prefix. 596 According to Section 2.2 of [RFC4291], in the legal textual 597 representations of IPv6 addresses, dotted decimal can only appear at 598 the end. The /96 prefix is compatible with that requirement. It 599 enables the dotted decimal notation without requiring an update to 600 [RFC4291]. This representation makes the address format easier to 601 use, and log files easier to read. 603 The prefix that we recommend has the particularity of being "checksum 604 neutral". The sum of the hexadecimal numbers "0064" and "ff9b" is 605 "ffff", i.e. a value equal to zero in one's complement arithmetic. 606 An IPv4-Embedded IPv6 address constructed with this prefix will have 607 the same one's complement checksum as the embedded IPv4 address. 609 5. Security Considerations 611 5.1. Protection Against Spoofing 613 IPv4/IPv6 translators can be modeled as special routers, are subject 614 to the same risks, and can implement the same mitigations. (The 615 discussion of generic threats to routers and their mitigations is 616 beyond the scope of this document.) There is however a particular 617 risk that directly derives from the practice of embedding IPv4 618 addresses in IPv6: address spoofing. 620 An attacker could use an IPv4-Embedded IPv6 address as the source 621 address of malicious packets. After translation, the packets will 622 appear as IPv4 packets from the specified source, and the attacker 623 may be hard to track. If left without mitigation, the attack would 624 allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. 626 The mitigation is to implement reverse path checks, and to verify 627 throughout the network that packets are coming from an authorized 628 location. 630 5.2. Secure Configuration 632 The prefixes used for address translation are used by IPv6 nodes to 633 send packets to IPv6/IPv4 translators. Attackers could attempt to 634 fool nodes, DNS gateways, and IPv4/IPv6 translators into using wrong 635 values for these parameters, resulting in network disruption, denial 636 of service, and possible information disclosure. To mitigate such 637 attacks, network administrators need to ensure that prefixes are 638 configured in a secure way. 640 The mechanisms for achieving secure configuration of prefixes are 641 beyond the scope of this document. 643 5.3. Firewall Configuration 645 Many firewalls and other security devices filter traffic based on 646 IPv4 addresses. Attackers could attempt to fool these firewalls by 647 sending IPv6 packets to or from IPv6 addresses that translate to the 648 filtered IPv4 addresses. If the attack is successful, traffic that 649 was previously blocked might be able to pass through the firewalls 650 disguised as IPv6 packets. In all such scenarios, administrators 651 should assure that packets that send to or from IPv4 embedded IPv6 652 addresses are subject to the same filtering as those directly sent to 653 or from the embedded IPv4 addresses. 655 The mechanisms for configuring firewalls and security devices to 656 achieve this filtering are beyond the scope of this document. 658 6. IANA Considerations 660 Upon approval of this document, IANA will make the following changes 661 in the "Internet Protocol Version 6 Address Space" registry located 662 at http://www.iana.org/assignments/ipv6-address-space: 664 OLD: 666 IPv6 Prefix Allocation Reference Note 667 ----------- ---------------- ------------ ---------------- 668 0000::/8 Reserved by IETF [RFC4291] [1][5] 670 NEW: 672 IPv6 Prefix Allocation Reference Note 673 ----------- ---------------- ------------ ---------------- 674 0000::/8 Reserved by IETF [RFC4291] [1][5][TBD] 676 [TBD] The "Well Known Prefix" 64:ff9b::/96 used in an algorithmic 677 mapping between IPv4 to IPv6 addresses is defined out of the 678 0000::/8 address block, per [RFC-ietf-behave-address-format]. 680 7. Acknowledgements 682 Many people in the Behave WG have contributed to the discussion that 683 led to this document, including Andrew Sullivan, Andrew Yourtchenko, 684 Ari Keranen, Brian Carpenter, Charlie Kaufman, Dan Wing, Dave Thaler, 685 David Harrington, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, Iljitsch 686 van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus 687 Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip 688 Matthews, Remi Denis-Courmont, Remi Despres and William Waites. 690 Marcelo Bagnulo is partly funded by Trilogy, a research project 691 supported by the European Commission under its Seventh Framework 692 Program. 694 8. Contributors 696 The following individuals co-authored drafts from which text has been 697 incorporated, and are listed in alphabetical order. 699 Congxiao Bao 700 CERNET Center/Tsinghua University 701 Room 225, Main Building, Tsinghua University 702 Beijing, 100084 703 China 704 Phone: +86 62785983 705 Email: congxiao@cernet.edu.cn 707 Dave Thaler 708 Microsoft Corporation 709 One Microsoft Way 710 Redmond, WA 98052 711 USA 712 Phone: +1 425 703 8835 713 Email: dthaler@microsoft.com 715 Fred Baker 716 Cisco Systems 717 Santa Barbara, California 93117 718 USA 719 Phone: +1-408-526-4257 720 Fax: +1-413-473-2403 721 Email: fred@cisco.com 723 Hiroshi Miyata 724 Yokogawa Electric Corporation 725 2-9-32 Nakacho 726 Musashino-shi, Tokyo 180-8750 727 JAPAN 728 Email: h.miyata@jp.yokogawa.com 730 Marcelo Bagnulo 731 Universidad Carlos III de Madrid 732 Av. Universidad 30 733 Leganes, Madrid 28911 734 ESPANA 735 Email: marcelo@it.uc3m.es 737 Xing Li 738 CERNET Center/Tsinghua University 739 Room 225, Main Building, Tsinghua University 740 Beijing, 100084 741 China 742 Phone: +86 62785983 743 Email: xing@cernet.edu.cn 745 9. References 747 9.1. Normative References 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, March 1997. 752 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 753 Architecture", RFC 4291, February 2006. 755 9.2. Informative References 757 [I-D.ietf-6man-text-addr-representation] 758 Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 759 Address Text Representation", 760 draft-ietf-6man-text-addr-representation-07 (work in 761 progress), February 2010. 763 [I-D.ietf-behave-dns64] 764 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 765 "DNS64: DNS extensions for Network Address Translation 766 from IPv6 Clients to IPv4 Servers", 767 draft-ietf-behave-dns64-10 (work in progress), July 2010. 769 [I-D.ietf-behave-v6v4-framework] 770 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 771 IPv4/IPv6 Translation", 772 draft-ietf-behave-v6v4-framework-09 (work in progress), 773 May 2010. 775 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 776 E. Lear, "Address Allocation for Private Internets", 777 BCP 5, RFC 1918, February 1996. 779 [RFC3484] Draves, R., "Default Address Selection for Internet 780 Protocol version 6 (IPv6)", RFC 3484, February 2003. 782 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 783 Reserved for Documentation", RFC 3849, July 2004. 785 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 786 Protocol 4 (BGP-4)", RFC 4271, January 2006. 788 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 789 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 790 October 2008. 792 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 793 BCP 153, RFC 5735, January 2010. 795 Authors' Addresses 797 Congxiao Bao 798 CERNET Center/Tsinghua University 799 Room 225, Main Building, Tsinghua University 800 Beijing, 100084 801 China 803 Phone: +86 10-62785983 804 Email: congxiao@cernet.edu.cn 806 Christian Huitema 807 Microsoft Corporation 808 One Microsoft Way 809 Redmond, WA 98052-6399 810 U.S.A. 812 Email: huitema@microsoft.com 814 Marcelo Bagnulo 815 UC3M 816 Av. Universidad 30 817 Leganes, Madrid 28911 818 Spain 820 Phone: +34-91-6249500 821 Fax: 822 Email: marcelo@it.uc3m.es 823 URI: http://www.it.uc3m.es/marcelo 825 Mohamed Boucadair 826 France Telecom 827 3, Av Francois Chateaux 828 Rennes 350000 829 France 831 Email: mohamed.boucadair@orange-ftgroup.com 832 Xing Li 833 CERNET Center/Tsinghua University 834 Room 225, Main Building, Tsinghua University 835 Beijing, 100084 836 China 838 Phone: +86 10-62785983 839 Email: xing@cernet.edu.cn