idnits 2.17.1 draft-ietf-behave-address-format-02.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 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 191: '... [RFC4291]. These bits MUST be set to zero. When using a /96 prefix,...' RFC 2119 keyword, line 192: '...e administrators MUST ensure that the ...' RFC 2119 keyword, line 199: '... reserved octet "u", whose 8 bits MUST...' RFC 2119 keyword, line 220: '... extensions, and SHOULD be set to a ze...' RFC 2119 keyword, line 255: '...ell-Known Prefix MAY be used by organi...' (19 more instances...) -- 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 (December 14, 2009) is 5247 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) == Unused Reference: 'RFC2026' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC2765' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC2766' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'RFC3493' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 639, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-02 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-03 -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 6 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: June 17, 2010 M. Bagnulo 7 UC3M 8 M. Boucadair 9 France Telecom 10 X. Li 11 CERNET Center/Tsinghua University 12 December 14, 2009 14 IPv6 Addressing of IPv4/IPv6 Translators 15 draft-ietf-behave-address-format-02.txt 17 Abstract 19 This document discusses the algorithmic translated to a corresponding 20 IPv4 address, and vice versa, using only statically configured 21 information. It defines a Well-Known Prefix for use in algorithmic 22 translations, while allowing organizations to also use Network 23 Specific Prefixes when appropriate. Algorithmic translation is used 24 in IPv4/IPv6 translators, as well as other types of proxies and 25 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 June 17, 2010. 50 Copyright Notice 52 Copyright (c) 2009 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. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. IPv4 Embedded IPv6 Address Format . . . . . . . . . . . . . . 4 71 2.1. Text Representation . . . . . . . . . . . . . . . . . . . 5 72 3. Deployment Guidelines and Choices . . . . . . . . . . . . . . 6 73 3.1. Deployment Using the Well-Known Prefix . . . . . . . . . . 6 74 3.2. Impact on Inter-Domain Routing . . . . . . . . . . . . . . 6 75 3.3. Choice of Prefix for Stateless Translation Deployments . . 7 76 3.4. Choice of Prefix for Stateful Translation Deployments . . 8 77 3.5. Choice of Suffix . . . . . . . . . . . . . . . . . . . . . 9 78 3.6. Choice of the Well-Known Prefix . . . . . . . . . . . . . 10 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 4.1. Protection Against Spoofing . . . . . . . . . . . . . . . 11 81 4.2. Secure Configuration . . . . . . . . . . . . . . . . . . . 11 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 84 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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 This document reserves a "Well-Known Prefix" for use in an 107 algorithmic mapping. The value of this IPv6 prefix is: 109 64:FF9B::/96 111 Section 2 describes the format of "IPv4 Embedded IPv6 addresses", 112 i.e. - IPv6 addresses in which 32 bits contain an IPv4 address. 114 Section 3 discusses the choice of prefixes, the use of the Well-Known 115 Prefix, and the use of embedded addresses with stateless and stateful 116 translation. 118 Section 4 discusses security concerns. 120 1.1. Applicability Scope 122 This document is part of a series defining address translation 123 services. We understand that the address format could also be used 124 by other interconnection methods between IPv6 and IPv4, e.g. methods 125 based on encapsulation. If encapsulation methods are developed by 126 the IETF, we expect that their descriptions will document their 127 specific use of IPv4 Embedded IPv6 Addresses. 129 1.2. Notations 131 This document makes use of the following terms: 133 IPv4/IPv6 translator: an entity that translates IPv4 packets to IPv6 134 packets, and vice versa. It may do "stateless" translation, 135 meaning that there is no per-flow state required, or "stateful" 136 translation where per-flow state is created when the first packet 137 in a flow is received. 139 Address translator: any entity that has to derive an IPv4 address 140 from an IPv6 address or vice versa. This applies not only to 141 devices that do IPv4/IPv6 packet translation, but also to other 142 entities that manipulate addresses, such as name resolution 143 proxies (e.g. DNS64 [I-D.ietf-behave-dns64]) and possibly other 144 types of Application Layer Gateways (ALGs). 145 Well-Known Prefix: the IPv6 prefix defined in this document for use 146 in an algorithmic mapping. 147 Network Specific Prefix: an IPv6 prefix assigned by an organization 148 for use in algorithmic mapping. Options for the Network Specific 149 Prefix are discussed in Section 3.3 and Section 3.4. 150 IPv4 Embedded IPv6 addresses: IPv6 addresses in which 32 bits 151 contain an IPv4 address. These addresses can be used to represent 152 IPv4 hosts to hosts in an IPv6 network. Their format is described 153 in Section 2. 154 IPv4-translatable IPv6 addresses: IPv6 addresses assigned to IPv6 155 hosts for use with stateless translation. They are a variant of 156 embedded addresses, and follow the format described in Section 2. 158 2. IPv4 Embedded IPv6 Address Format 160 IPv4 Embedded IPv6 Addresses are composed of a variable length 161 prefix, the embedded IPv4 address, and a variable length suffix, as 162 presented in the following diagram, in which PL designates the prefix 163 length: 165 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 166 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 167 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 168 |32| prefix |v4(32) | u | suffix | 169 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 170 |40| prefix |v4(24) | u |(8)| suffix | 171 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 172 |48| prefix |v4(16) | u | (16) | suffix | 173 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 174 |56| prefix |(8)| u | v4(24) | suffix | 175 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 176 |64| prefix | u | v4(32) | suffix | 177 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 178 |96| prefix | v4(32) | 179 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 181 In these addresses, the prefix shall be either the "Well-Known 182 Prefix", or a "Network Specific Prefix" unique to the organization 183 deploying the address translators. 185 Various deployments justify different prefix lengths. The tradeoff 186 between different prefix lengths are discussed in Section 3.3 and 187 Section 3.4. 189 Bits 64 to 71 of the address are reserved for compatibility with the 190 host identifier format defined in the IPv6 addressing architecture 191 [RFC4291]. These bits MUST be set to zero. When using a /96 prefix, 192 the administrators MUST ensure that the bits 64 to 71 are set to 193 zero. A simple way to achieve that is to construct the /96 Network 194 Specific Prefix by picking a /64 prefix, and then adding four octets 195 set to zero. 197 The IPv4 address is encoded following the prefix, most significant 198 bits first. Depending of the prefix length, the 4 octets of the 199 address may be separated by the reserved octet "u", whose 8 bits MUST 200 be set to zero. In particular: 201 o When the prefix is 32 bits long, the IPv4 address is encoded in 202 positions 32 to 63. 203 o When the prefix is 40 bits long, 24 bits of the IPv4 address are 204 encoded in positions 40 to 63, with the remaining 8 bits in 205 position 72 to 79. 206 o When the prefix is 48 bits long, 16 bits of the IPv4 address are 207 encoded in positions 48 to 63, with the remaining 16 bits in 208 position 72 to 87. 209 o When the prefix is 56 bits long, 8 bits of the IPv4 address are 210 encoded in positions 56 to 63, with the remaining 24 bits in 211 position 72 to 95. 212 o When the prefix is 64 bits long, the IPv4 address is encoded in 213 positions 72 to 103. 214 o When the prefix is 96 bits long, the IPv4 address is encoded in 215 positions 96 to 127. 217 There are no remaining bits, and thus no suffix, if the prefix is 96 218 bits long. In the other cases, the remaining bits of the address 219 constitute the suffix. These bits are reserved for future 220 extensions, and SHOULD be set to a zero. 222 2.1. Text Representation 224 IPv4 embedded IPv6 addresses will be represented in text in 225 conformity with section 2.2 of [RFC4291]. IPv4 embedded IPv6 226 addresses constructed using the Well Known Prefix or a /96 Network 227 Specific Prefix may be represented using the alternative form 228 presented in section 2.2 of [RFC4291], with the embedded IPv4 address 229 represented in dotted decimal notation. Examples of such 230 representations are presented in Table 1. 232 +-----------------------+------------+------------------------------+ 233 | Prefix | IPv4 | IPv4 embedded IPv6 address | 234 | | address | | 235 +-----------------------+------------+------------------------------+ 236 | 2001:DB8:100::/32 | 13.1.68.3 | 2001:DB8:D01:4403:: | 237 | 2001:DB8:100::/40 | 13.1.68.3 | 2001:DB8:10D:0144:3:: | 238 | 2001:DB8:102::/48 | 13.1.68.3 | 2001:DB8:102:D01:44:300:: | 239 | 2001:DB8:102::/48 | 13.1.68.3 | 2001:DB8:102:D01:44:300:: | 240 | 2001:DB8:102:300::/56 | 13.1.68.3 | 2001:DB8:102:30D:1:4403:: | 241 | 2001:DB8:102:304::/64 | 13.1.68.3 | 2001:DB8:102:304:D:144:300:: | 242 | 2001:DB8:102:304::/96 | 13.1.68.3 | 2001:DB8:102:304::13.1.68.3 | 243 | 64:FF9B::/96 | 13.1.68.3 | 64:FF9B::13.1.68.3 | 244 +-----------------------+------------+------------------------------+ 246 Table 1: Text representation of IPv4 embedded IPv6 addresses 248 The Network Specific Prefixes in Table 1 are derived from the IPv6 249 Prefix reserved for doocumentation in [RFC3849]. 251 3. Deployment Guidelines and Choices 253 3.1. Deployment Using the Well-Known Prefix 255 The Well-Known Prefix MAY be used by organizations deploying 256 translation services. 258 The Well-Known Prefix SHOULD NOT be used to construct IPv4 259 translatable addresses. The host served by IPv4 translatable IPv6 260 addresses should be able to receive IPv6 traffic bound to their IPv4 261 translatable IPv6 address without incurring intermediate protocol 262 translation. This is only possible if the specific prefix used to 263 build the IPv4 translatable IPv6 addresses is advertized in inter- 264 domain routing, and this kind of specific prefix advertisement is not 265 supported with the Well-Known Prefix, as explained in Section 3.2. 267 The Well-Known Prefix MUST NOT be used to represent non global IPv4 268 addresses, such as those defined in [RFC1918]. Doing so would 269 introduce ambiguous IPv6 addresses. 271 3.2. Impact on Inter-Domain Routing 273 The Well-Known Prefix MAY appear in inter-domain routing tables, if 274 service providers decide to provide IPv6-IPv4 interconnection 275 services to peers. Advertisement of the Well-Known Prefix SHOULD be 276 controlled either by upstream and/or downstream service providers 277 owing to inter-domain routing policies, e.g., through configuration 278 of BGP [RFC4271]. Organizations that advertize the Well-Known Prefix 279 in inter-domain routing MUST be able to provide IPv4/IPv6 address 280 translation service. 282 When the IPv4/IPv6 translation relies on the Well-Known Prefix, 283 embedded IPv6 prefixes longer than the Well-Known Prefix MUST NOT be 284 advertised in BGP (especially e-BGP) [RFC4271] because this leads to 285 importing IPv4 routing table into IPv6 one and therefore induces 286 scalability issues to the global IPv6 routing table. Adjacent BGP 287 speakers MUST ignore advertisements of embedded IPv6 prefixes longer 288 than the Well-Known Prefix. BGP speakers SHOULD be able to be 289 configured with the default Well-Known Prefix. 291 When the IPv4/IPv6 translation service relies on Network Specific 292 Prefixes and stateless translation is used, the IPv4-translatable 293 IPv6 prefixes MUST be advertised with proper aggregation to the IPv6 294 Internet. Similarly, if translators are configured with multiple 295 Network Specific Prefixes, these prefixes MUST be advertised to the 296 IPv6 Internet with proper aggregation. 298 3.3. Choice of Prefix for Stateless Translation Deployments 300 Organization may deploy translation services using stateless 301 translation. In these deployments, internal IPv6 hosts are addressed 302 using "IPv4 translatable" IPv6 addresses, which enable them to be 303 accessed by IPv4 hosts. The addresses of these external hosts are 304 then represented in "IPv4 Embedded" IPv6 addresses. 306 Organizations deploying stateless IPv4/IPv6 translation SHOULD assign 307 a Network Specific Prefix to their IPv4/IPv6 translation service. 308 "IPv4 translatable" and "IPv4 Embedded" addresses MUST be constructed 309 as specified in Section 2. IPv4 translatable IPv6 addresses MUST use 310 the selected Network Specific Prefix. Both types of addresses SHOULD 311 use the same prefix. Using the same prefix ensures that internal 312 IPv6 hosts will use the most efficient paths to reach the hosts 313 served by "IPv4 translatable" addresses. 315 The intra-domain routing protocol must be able to deliver packets to 316 the hosts served by IPv4 translatable IPv6 addresses. This may 317 require routing on some or all of the embedded IPv4 address bits. 318 Security considerations detailed in Section 4 require that routers 319 check the validity of the IPv4 translatable IPv6 source addresses, 320 using some form of reverse path check. 322 Forwarding, and reverse path checks, should be performed on the 323 combination of the "prefix" and the IPv4 address. In theory, routers 324 should be able to route on prefixes of any length. However, routing 325 on prefixes larger than 64 bits may be slower. But routing 326 efficiency is not the only consideration in the choice of a prefix 327 length. Organizations also need to consider the availability of 328 prefixes, and the potential impact of all-zeroes identifiers. 330 If a /32 prefix is used, all the routing bits are contained in the 331 top 64 bits of the IPv6 address, leading to excellent routing 332 properties. These prefixes may however be hard to obtain, and 333 allocation of a /32 to a small set of IPv4 translatable addresses may 334 be seen as wasteful. In addition, the /32 prefix and a zero suffix 335 leads to an all-zeroes interface identifier, an issue that we discuss 336 in Section 3.5. 338 Intermediate prefix lengths such as /40, /48 or /56 appear as 339 compromises. Only some of the IPv4 bits are part of the /64 340 prefixes. Reverse path checks, in particular, may have a limited 341 efficiency. Reverse checks limited to the most significant bits of 342 the IPv4 address will reduce the possibility of spoofing external 343 IPv4 address, but would allow IPv6 hosts to spoof internal IPv4 344 translatable addresses. 346 We propose here a compromise, based on using no more than 1/256th of 347 an organization's allocation of IPv6 addresses for the IPv4/IPv6 348 translation service. For example, if the organization is an ISP, 349 with an allocated IPv6 prefix /32 or shorter, the ISP could dedicate 350 a /40 prefix to the translation service. An end site with a /48 351 allocation could dedicate a /56 prefix to the translation service, or 352 possibly a /96 prefix if all IPv4 Translatable IPv4 Addresses are 353 located on the same link. 355 The recommended prefix length is also a function of the deployment 356 scenario. The stateless translation can be used for Scenario 1, 357 Scenario 2, Scenario and Scenario 6 defined in 358 [I-D.ietf-behave-v6v4-framework]. For different scenarios, the 359 prefix length recommendations are: 360 o For scenario 1 (an IPv6 network to the IPv4 Internet) and scenario 361 2 (the IPv4 Internet to an IPv6 network), we recommend using a /40 362 prefix for an ISP holding a /32 allocation, and a /56 prefix for a 363 site holding a /48 allocation. 364 o For scenario 5 (an IPv6 network to an IPv4 network) and scenario 6 365 (an IPv4 network to an IPv6 network), we recommend using a /64 or 366 a /96 prefix. 368 3.4. Choice of Prefix for Stateful Translation Deployments 370 Organizations may deploy translation services based on stateful 371 translation technology. An organization may decide to use either a 372 Network Specific Prefix or the Well-Known Prefix for its stateful 373 IPv4/IPv6 translation service. 375 When these services are used, IPv6 hosts are addressed through 376 standard IPv6 addresses, while IPv4 hosts are represented by IPv4 377 embedded addresses, as specified in Section 2. 379 The stateful nature of the translation creates a potential stability 380 issue when the organization deploys multiple translators. If several 381 translators use the same prefix, there is a risk that packets 382 belonging to the same connection may be routed to different 383 translators as the internal routing state changes. This issue can be 384 mitigated either by assigning different prefixes to different 385 translators, or by ensuring that all translators using same prefix 386 coordinate their state. 388 Stateful translation can be used in scenarios defined in 389 [I-D.ietf-behave-v6v4-framework]. The Well Known Prefix SHOULD be 390 used in most scenarios, with two exceptions: 391 o In all scenarios, the translation MAY use a Network Specific 392 Prefix, if deemed appropriate for management reasons. 393 o The Well-Known Prefix MUST NOT be used for scenario 3 (the IPv6 394 Internet to an IPv4 network), as this would lead to using the 395 Well-Known Prefix with non global IPv4 addresses. That means a 396 Network Specific Prefix MUST be used in that scenario, for example 397 a /96 prefix compatible with the Well Known prefix format. 399 3.5. Choice of Suffix 401 The address format described in Section 2 recommends a zero suffix. 402 Before making this recommendation, we considered different options: 403 checksum neutrality; the encoding of a port range; and a value 404 different than 0. 406 The "neutrality checksum" option would give a chosen value to 16 of 407 the suffix bits to ensure that the "IPv4 embedded" IPv6 address has 408 the same 16 bit 1's complement checksum as the embedded IPv4 address. 409 There have been discussion of this checksum in the working group 410 mailing list, and some push to standardize a checksum format. 411 However, we observed that a neutral checksum alone does not eliminate 412 checksums computation during stateful translation, as only one of the 413 two addresses would be checksum neutral. In the case of stateless 414 translation, translators may want to recompute the checksum anyhow, 415 to verify the validity of the translated datagrams. In the case of 416 stateful translation, the Well Known Prefix was chosen to provide 417 checksum neutrality. We thus chose the simplest alternative, to not 418 specify a neutrality checksum. 420 There have been proposals to complement stateless translation with a 421 port-range feature. Instead of mapping an IPv4 address to exactly 422 one IPv6 prefix, the options would allow several IPv6 hosts to share 423 an IPv4 address, with each host managing a different range of ports. 424 But these schemes are not yet specified in work group documents. If 425 a port range extension is needed, it could be defined later, using 426 bits currently reserved as null in the suffix. 428 When a /32 prefix is used, an all-zero suffix results in an all-zero 429 interface identifier. We understand the conflict with Section 2.6.1 430 of RFC4291, which specifies that all zeroes are used for the subnet- 431 router anycast address. However, in our specification, there would 432 be only one IPv4 translatable node in the /64 subnet, and the anycast 433 semantic would not create confusion. We thus decided to keep the 434 null suffix for now. (This issue does not exist for prefixes larger 435 than 32 bits, such as the /40, /56, /64 and /96 prefixes that we 436 recommend in Section 3.3.) 438 3.6. Choice of the Well-Known Prefix 440 Before making our recommendation of the Well-Known Prefix, we were 441 faced with three choices: 442 o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC 443 2765 Section 2.1; 444 o request IANA to allocate a /32 prefix, 445 o or request allocation of a new /96 prefix. 447 We weighted the pros and cons of these choices before settling on the 448 recommended /96 Well-Known Prefix. 450 The main advantage of the existing IPv4-mapped prefix is that it is 451 already defined. Reusing that prefix will require minimal 452 standardization efforts. However, being already defined is not just 453 and advantage, as there may be side effects of current 454 implementations. When presented with the IPv4-mapped prefix, current 455 versions of Windows and MacOS generate IPv4 packets, but will not 456 send IPv6 packets. If we used the IPv4-mapped prefix, these hosts 457 would not be able to support translation without modification. This 458 will defeat the main purpose of the translation techniques. We thus 459 eliminated the first choice, and decided to not reuse the IPv4-mapped 460 prefix, ::FFFF:0:0/96. 462 A /32 prefix would have allowed the embedded IPv4 address to fit 463 within the top 64 bits of the IPv6 address. This would have 464 facilitated routing and load balancing when an organization deploys 465 several translators. However, such destination-address based load 466 balancing may not be desirable. It is not compatible with STUN in 467 the deployments involving multiple stateful translators, each one 468 having a different pool of IPv4 addresses. STUN compatibility would 469 only be achieved if the translators managed the same pool of IPv4 470 addresses and were able to coordinate their translation state, in 471 which case there is no big advantage to using a /32 prefix rather 472 than a /96 prefix. 474 According to Section 2.2 of [RFC4291], in the legal textual 475 representations of IPv6 addresses, dotted decimal can only appear at 476 the end. The /96 prefix is compatible with that requirement. It 477 enables the dotted decimal notation without requiring an update to 478 [RFC4291]. This representation makes the address format easier to 479 use, and log files easier to read. 481 The prefix that we recommend has the particularity of being "checksum 482 neutral". The sum of the hexadecimal numbers "0064" and "FF9B" is 483 "FFFF", i.e. a value equal to zero in complement to 1 arithmetic. An 484 IPv4 embedded IPv6 address constructed with this prefix will have the 485 same complement to 1 checksum as the embedded IPv4 address. 487 4. Security Considerations 489 4.1. Protection Against Spoofing 491 By and large, address translators can be modeled as special routers, 492 are subject to the same risks, and can implement the same 493 mitigations. There is however a particular risk that directly 494 derives from the practice of embedding IPv4 addresses in IPv6: 495 address spoofing. 497 An attacker could use an IPv4 embedded address as the source address 498 of malicious packets. After translation, the packets will appear as 499 IPv4 packets from the specified source, and the attacker may be hard 500 to track. If left without mitigation, the attack would allow 501 malicious IPv6 nodes to spoof arbitrary IPv4 addresses. 503 The mitigation is to implement reverse path checks, and to verify 504 throughout the network that packets are coming from an authorized 505 location. 507 4.2. Secure Configuration 509 The prefixes and formats need to be the configured consistently among 510 multiple devices in the same network (e.g., hosts that need to prefer 511 native over translated addresses, DNS gateways, and IPv4/IPv6 512 translators). As such, the means by which they are learned/ 513 configured MUST be secure. Specifying a default prefix and/or format 514 in implementations provides one way to configure them securely. Any 515 alternative means of configuration is responsible for specifying how 516 to do so securely. 518 5. IANA Considerations 520 The Well Known Prefix falls into the range ::/8 reserved by the IETF. 521 The prefix definition does not require an IANA action. 523 6. Acknowledgements 525 Many people in the Behave WG have contributed to the discussion that 526 led to this document, including Andrew Sullivan, Andrew Yourtchenko, 527 Brian Carpenter, Dan Wing, Ed Jankiewicz, Fred Baker, Hiroshi Miyata, 528 Iljitsch van Beijnum, John Schnizlein, Keith Moore, Kevin Yin, Magnus 529 Westerlund, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip 530 Matthews, Remi Denis-Courmont, Remi Despres and William Waites. 532 Marcelo Bagnulo is partly funded by Trilogy, a research project 533 supported by the European Commission under its Seventh Framework 534 Program. 536 7. Contributors 538 The following individuals co-authored drafts from which text has been 539 incorporated, and are listed in alphabetical order. 541 Congxiao Bao 542 CERNET Center/Tsinghua University 543 Room 225, Main Building, Tsinghua University 544 Beijing, 100084 545 China 546 Phone: +86 62785983 547 Email: congxiao@cernet.edu.cn 549 Dave Thaler 550 Microsoft Corporation 551 One Microsoft Way 552 Redmond, WA 98052 553 USA 554 Phone: +1 425 703 8835 555 Email: dthaler@microsoft.com 557 Fred Baker 558 Cisco Systems 559 Santa Barbara, California 93117 560 USA 561 Phone: +1-408-526-4257 562 Fax: +1-413-473-2403 563 Email: fred@cisco.com 565 Hiroshi Miyata 566 Yokogawa Electric Corporation 567 2-9-32 Nakacho 568 Musashino-shi, Tokyo 180-8750 569 JAPAN 570 Email: h.miyata@jp.yokogawa.com 572 Marcelo Bagnulo 573 Universidad Carlos III de Madrid 574 Av. Universidad 30 575 Leganes, Madrid 28911 576 ESPANA 577 Email: marcelo@it.uc3m.es 579 Xing Li 580 CERNET Center/Tsinghua University 581 Room 225, Main Building, Tsinghua University 582 Beijing, 100084 583 China 584 Phone: +86 62785983 585 Email: xing@cernet.edu.cn 587 8. References 589 8.1. Normative References 591 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 592 3", BCP 9, RFC 2026, October 1996. 594 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 595 Architecture", RFC 4291, February 2006. 597 8.2. Informative References 599 [I-D.ietf-behave-dns64] 600 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 601 "DNS64: DNS extensions for Network Address Translation 602 from IPv6 Clients to IPv4 Servers", 603 draft-ietf-behave-dns64-02 (work in progress), 604 October 2009. 606 [I-D.ietf-behave-v6v4-framework] 607 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 608 IPv4/IPv6 Translation", 609 draft-ietf-behave-v6v4-framework-03 (work in progress), 610 October 2009. 612 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 613 E. Lear, "Address Allocation for Private Internets", 614 BCP 5, RFC 1918, February 1996. 616 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 617 (SIIT)", RFC 2765, February 2000. 619 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 620 Translation - Protocol Translation (NAT-PT)", RFC 2766, 621 February 2000. 623 [RFC3484] Draves, R., "Default Address Selection for Internet 624 Protocol version 6 (IPv6)", RFC 3484, February 2003. 626 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 627 Stevens, "Basic Socket Interface Extensions for IPv6", 628 RFC 3493, February 2003. 630 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 631 Reserved for Documentation", RFC 3849, July 2004. 633 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 634 Protocol 4 (BGP-4)", RFC 4271, January 2006. 636 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 637 Address Autoconfiguration", RFC 4862, September 2007. 639 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 640 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 641 October 2008. 643 Authors' Addresses 645 Christian Huitema 646 Microsoft Corporation 647 One Microsoft Way 648 Redmond, WA 98052-6399 649 U.S.A. 651 Email: huitema@microsoft.com 653 Congxiao Bao 654 CERNET Center/Tsinghua University 655 Room 225, Main Building, Tsinghua University 656 Beijing, 100084 657 China 659 Phone: +86 10-62785983 660 Email: congxiao@cernet.edu.cn 662 Marcelo Bagnulo 663 UC3M 664 Av. Universidad 30 665 Leganes, Madrid 28911 666 Spain 668 Phone: +34-91-6249500 669 Fax: 670 Email: marcelo@it.uc3m.es 671 URI: http://www.it.uc3m.es/marcelo 672 Mohamed Boucadair 673 France Telecom 674 3, Av Francois Chateaux 675 Rennes 350000 676 France 678 Email: mohamed.boucadair@orange-ftgroup.com 680 Xing Li 681 CERNET Center/Tsinghua University 682 Room 225, Main Building, Tsinghua University 683 Beijing, 100084 684 China 686 Phone: +86 10-62785983 687 Email: xing@cernet.edu.cn