idnits 2.17.1 draft-thaler-behave-translator-addressing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 222: '...ases, an IPv6-only node SHOULD be able...' RFC 2119 keyword, line 238: '... SHOULD be able to distinguish a nat...' RFC 2119 keyword, line 438: '...y the translator SHOULD be configurabl...' RFC 2119 keyword, line 439: '... policies consistent with [RFC3484], and SHOULD default to having the...' RFC 2119 keyword, line 443: '...ress translators MUST be configurable ...' (15 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 (July 7, 2009) is 5400 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 862, but no explicit reference was found in the text == Unused Reference: 'I-D.wing-behave-nat64-referrals' is defined on line 882, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-wing-behave-nat64-referrals-00 -- 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: 3 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler, Ed. 3 Internet-Draft Microsoft 4 Obsoletes: 2765 (if approved) July 7, 2009 5 Intended status: Standards Track 6 Expires: January 8, 2010 8 IPv6 Addressing of IPv6/IPv4 Translators 9 draft-thaler-behave-translator-addressing-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 8, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document discusses how an individual IPv6 address can be 48 algorithmically translated to a corresponding IPv4 address, and vice 49 versa, using only statically configured information. This technique 50 is used in IPv6/IPv4 translators, as well as other types of proxies 51 and gateways (e.g., for DNS) used in IPv6/IPv4 scenarios. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. IPv6 Addresses Assigned to IPv6 Hosts . . . . . . . . . . 4 57 1.2. IPv6 Addresses Used For IPv4 Hosts . . . . . . . . . . . . 5 58 2. Prefix Selection . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1.1. IPv6 Routing System Scalability . . . . . . . . . . . 6 61 2.1.2. Native Connectivity Preference for Dual-Stack Nodes . 6 62 2.1.3. Referral Support . . . . . . . . . . . . . . . . . . . 7 63 2.1.4. Support for Multiple IPv6/IPv4 Translators . . . . . . 7 64 2.1.5. Appropriate Prefix Length . . . . . . . . . . . . . . 8 65 2.1.6. Uniqueness . . . . . . . . . . . . . . . . . . . . . . 8 66 2.2. Types of Prefixes . . . . . . . . . . . . . . . . . . . . 9 67 2.2.1. Network-Specific Prefix . . . . . . . . . . . . . . . 9 68 2.2.2. Well-Known Prefix . . . . . . . . . . . . . . . . . . 9 69 2.3. Scenario-Specific Discussion and Recommendations . . . . . 10 70 2.3.1. Connecting the IPv6 Internet to the IPv4 Internet . . 10 71 2.3.2. Connecting an IPv6 network to the IPv4 Internet . . . 10 72 2.3.3. Connecting an IPv4 network to the IPv6 Internet . . . 12 73 2.3.4. Connecting between an IPv4 network and an IPv6 74 network . . . . . . . . . . . . . . . . . . . . . . . 12 75 3. IPv6 Address Format and Translation Algorithms . . . . . . . . 12 76 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 13 77 3.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 15 78 3.2.1. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . 15 79 3.2.2. IPv4-Translatable Addresses . . . . . . . . . . . . . 15 80 3.2.3. Zero-Pad And Embed . . . . . . . . . . . . . . . . . . 15 81 3.2.4. Compensation-Pad And Embed . . . . . . . . . . . . . . 16 82 3.2.5. Embed And Zero-Pad . . . . . . . . . . . . . . . . . . 16 83 3.2.6. Preconfigured Mapping Table . . . . . . . . . . . . . 17 84 3.3. Scenario-Specific Discussion and Recommendations . . . . . 17 85 3.3.1. Connecting the IPv6 Internet to the IPv4 Internet . . 17 86 3.3.2. Connecting an IPv6 network to the IPv4 Internet . . . 17 87 3.3.3. Connecting an IPv4 network to the IPv6 Internet . . . 18 88 3.3.4. Connecting between an IPv4 network and an IPv6 89 network . . . . . . . . . . . . . . . . . . . . . . . 18 90 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 93 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 This document is part of a series of IPv6/IPv4 translation documents. 102 A framework for IPv6/IPv4 translation is discussed in 103 [I-D.baker-behave-v4v6-framework], including a taxonomy of scenarios 104 that will be used in this document. Other documents specify the 105 behavior of various types of translators and gateways, including 106 mechanisms for translating between IP headers and other types of 107 messages that include IP addresses. This document specifies how an 108 individual IPv6 address is translated to a corresponding IPv4 109 address, and vice versa, in cases where an algorithmic mapping is 110 used. While specific types of devices are used herein as examples, 111 it is the responsibility of the specification of such devices to 112 reference this document for algorithmic mapping of the addresses 113 themselves. 115 In this document, an "IPv6/IPv4 translator" is an entity that 116 translates IPv6 packets to IPv4 packets, and vice versa. It may do 117 "stateless" translation, meaning that there is no per-flow state 118 required, or "stateful" translation where per-flow state is created 119 when the first packet in a flow is received. 121 In this document, an "address translator" is any entity that has to 122 derive an IPv6 address from an IPv4 address or vice versa. This 123 applies not only to devices that do IPv6/IPv4 packet translation, but 124 also to other entities that manipulate addresses, such as name 125 resolution proxies (e.g., DNS64 [I-D.bagnulo-behave-dns64]) and 126 possibly other types of Application Layer Gateways (ALGs). 128 [OPEN ISSUE: addressing for encapsulation mechanisms such as Dual- 129 Stack Lite, including use of port ranges, is currently treated as out 130 of scope for this document. Should such addressing be in scope?] 132 In choosing a mapping between IPv6 and IPv4 addresses for a given 133 scenario, there are two separate choices to make: choosing an IPv6 134 prefix, and choosing an algorithm for constructing the remainder of 135 the IPv6 address. These two topics are covered in Section 2 and 136 Section 3, respectively. 138 Algorithmic derivation of an IPv6 address from an IPv4 address, or 139 vice versa, is used with two different classes of IPv6 addresses, 140 discussed in Section 1.1 and Section 1.2. 142 1.1. IPv6 Addresses Assigned to IPv6 Hosts 144 In an IPv6 network, IPv6 addresses are assigned to IPv6 hosts, and 145 these IPv6 addresses need to be translated to IPv4 addresses that can 146 be used by IPv4 hosts. Such IPv4 addresses are not assigned to a 147 host, but packets destined to such addresses are routed to an 148 appropriate IPv6/IPv4 translator that handles a set of such IPv4 149 addresses. Thus stateless address translation mechanisms typically 150 put constraints on what IPv6 addresses can be assigned to IPv6 hosts 151 that want to communicate with IPv4 destinations using an algorithmic 152 mapping (although such hosts may have other IPv6 addresses used for 153 other purposes). Without such constraints, stateful translation on 154 such addresses must be done instead, which typically only supports 155 initiation from the IPv6 side, and does not result in stable 156 addresses that can be used in DNS and other protocols and 157 applications that do not deal well with highly dynamic addresses. 159 IPv6 addresses assigned to IPv6 hosts for use with stateless 160 translation are referred to as "IPv4-translatable" IPv6 addresses in 161 [RFC2765] although that term is also used to refer to a specific 162 address format (defined in [RFC2765] section 2.1) and hence we avoid 163 the use of this term herein except when referring to the specific 164 address format. 166 1.2. IPv6 Addresses Used For IPv4 Hosts 168 In an IPv4 network, IPv4 addresses are assigned to IPv4 hosts, and 169 these IPv4 addresses need to be translated to IPv6 addresses that can 170 be used by IPv6 hosts. Such IPv6 addresses are not assigned to a 171 host, but packets destined to such addresses are routed to an 172 appropriate IPv6/IPv4 translator that handles a set of such IPv6 173 addresses. Typically there are no additional constraints put on the 174 IPv4 addresses. Unlike the addresses discussed in Section 1.1, 175 algorithmic mapping of IPv6 addresses used for IPv4 hosts is used 176 with both stateful and stateless translation. 178 IPv6 addresses used for IPv4 hosts are referred to as "IPv4-mapped" 179 IPv6 addresses in [RFC2765] although that term is also used to refer 180 to a specific address format (defined in [RFC2765] section 2.1) and 181 hence we avoid the use of this term herein except when referring to 182 the specific address format. 184 2. Prefix Selection 186 This section discusses the choice of IPv6 prefixes for use with the 187 two classes of addresses outlined above. 189 2.1. Requirements 191 There are a number of important requirements to be considered. 193 2.1.1. IPv6 Routing System Scalability 195 One critical issue to consider when understanding the impact of the 196 prefix used is related to the scalability of the IPv6 routing system. 197 Since a goal of translation is to enable IPv4 only-hosts and IPv6- 198 only nodes to communicate, the IPv6 addresses used for IPv4 hosts 199 need to be routable within the IPv6 network served by the IPv6/IPv4 200 translator. This implies that a prefix covering such addresses must 201 be covered by one or more routes in the IPv6 network. In some 202 scenarios a single IPv6 route may suffice, whereas other scenarios 203 may require multiple more specific routes. It is important, however, 204 to avoid injecting an IPv6 route for every IPv4 route in the 205 Internet. 207 2.1.2. Native Connectivity Preference for Dual-Stack Nodes 209 When dual stack nodes are involved in communication, a potential 210 issue arises if they prefer translated IPv6/IPv4 connectivity over 211 native IPv4 or IPv6 connectivity. 213 For communication initiated from an IPv6-only node towards a dual- 214 stack node, there are two possibilities: communicating to the native 215 IPv6 address of the destination, or communicating via an IPv6/IPv4 216 translator to the IPv4 address of the destination (by using an IPv6 217 address that is translated to the IPv4 address). In some cases this 218 may be solved by having the IPv6-only node only learn the native IPv6 219 address and not the algorithmically derived one (e.g., by using a 220 normal DNS resolver), but this is not possible in general due to the 221 variety of mechanisms for learning the destination addresses (e.g., 222 referrals). To cover those cases, an IPv6-only node SHOULD be able 223 to distinguish a native IPv6 address from an IPv6 address used for an 224 IPv4 host. 226 For communication initiated from a dual-stack node toward an IPv4- 227 only node, there are two possibilities: communicating to the native 228 IPv4 address of the destination, or communicating via an IPv6/IPv4 229 translator to the IPv4 address of the destination (by using an IPv6 230 address that is translated to the IPv4 address). In some cases this 231 may be solved by having the dual-stack node only learn the native 232 IPv4 address and not the algorithmically derived one, but this is not 233 possible in general due to the variety of mechanisms for learning the 234 destination addresses. Normally it is desirable for a dual-stack 235 node to prefer an IPv6 destination address over an IPv4 destination 236 address, but in this case the IPv6 destination address is worse 237 because it will be translated. Hence in general, a dual-stack node 238 SHOULD be able to distinguish a native IPv6 address from an IPv6 239 address used for an IPv4 host, so that the former can be preferred 240 over an IPv4 destination address but not the latter. 242 [RFC3484] today provides the ability for IPv6-capable hosts to be 243 configured with prefixes used for address sorting sufficient to solve 244 the native connectivity preference issue. However the gap today is 245 that this requires manual configuration of all such hosts, which is 246 not practical. 248 2.1.3. Referral Support 250 A referral operation is when a host A passes the IP address of a Host 251 B to a third Host C as application data. The Host C may then 252 initiate communication towards Host B using the IP address received. 254 At this point in time, there are several widely-available protocols 255 that operate on the IPv4 Internet and perform referrals, including 256 HTTP, DNS, SIP, and BitTorrent. The analysis in [I-D.wing-behave- 257 nat64-referrals] of SIP (which does referrals between IPv4 and IPv6) 258 shows that SIP needs to refer IPv4 addresses, not IPv6 addresses. 259 Thus, it doesn't matter what IPv6 prefix is used because an IPv6 260 address isn't referred. 262 [EDITOR'S NOTE: The wing document discusses BitTorrent but the text 263 pulled above from draft-xli-behave-v4v6prefix section 5.1.2.1 only 264 summarizes SIP. Furthermore, it doesn't cover other widely-deployed 265 protocols that do referrals such as HTTP or DNS and hence is 266 inconclusive. Finally, it's unclear whether it applies to IPv6 267 addresses of IPv4 hosts or of IPv6 hosts, or both. Hence, referral 268 support is still considered an OPEN ISSUE. Another OPEN ISSUE is 269 whether to incorporate text from draft-wing-behave-nat64-referrals 270 into this document.] 272 2.1.4. Support for Multiple IPv6/IPv4 Translators 274 For IPv6 addresses assigned to IPv6 hosts, the choice of translator 275 used in the IPv4-to-IPv6 direction is determined by the IPv4 address 276 it is mapped to, rather than by the choice of IPv6 prefix. 278 For IPv6 addresses used for IPv4 hosts, the choice of translator used 279 in the IPv6-to-IPv4 direction is determined by the IPv6 address, but 280 is somewhat orthogonal to the choice of prefix. In general, it is 281 possible to use a single IPv6 prefix for multiple IPv6/IPv4 282 translators, or different prefixes for different IPv6/IPv4 283 translators. Using different prefixes can be achieved by inserting 284 additional subnet bits after the a common prefix such that each IPv6/ 285 IPv4 translator uses a separate range of subnets. Often only the 286 common prefix needs to be configured (as opposed to each more- 287 specific prefix) in other types of address translators such as DNS64 288 devices. 290 2.1.5. Appropriate Prefix Length 292 This section discusses several issues related to prefix length 293 selection. 295 2.1.5.1. Routing Policy 297 [EDITOR'S NOTE: The text below needs to be rewritten somewhat. It's 298 currently hard to follow, and is missing justification for its 299 statements.] 301 The major issue for selecting the prefix length is the routing 302 policy. If IPv4/IPv6 translation is implemented within a subnet, 303 then a /96 should be fine. However, if IPv4/IPv6 translation is 304 implemented in an ISP's backbone, then the minimum prefix should be 305 /64 and in some cases should be /48. 307 2.1.5.2. Forwarding Efficiency 309 According to current specifications [EDITOR'S NOTE: need reference], 310 routers must handle routes containing prefixes of any valid length, 311 from 0 to 128. However, some users have reported that routers 312 exhibit worse performance when routing using prefixes longer than 80 313 bits. This implies that using routes with prefixes of 80 bits or 314 fewer would result in better performance in some cases. 316 2.1.5.3. EUI-64 Format 318 The use of a prefix length longer than 64 bits may affect the 319 Interface Identifier format. Specifically, [RFC4291] section 2.5.1 320 requires that for all unicast addresses, except those that start with 321 the binary value 000, Interface IDs are required to be 64 bits long 322 and to be constructed in Modified EUI-64 format. While any method 323 can be used to construct a Modified EUI-64, the format requires the 324 71st bit (the universal/local bit) to be set with specific meaning, 325 and hence it is not available for use by an address format unless the 326 prefix starts with binary 000. 328 Furthermore, for IPv6 addresses assigned to IPv6 hosts, the prefix 329 must be 64 bits or less in order to work with stateless address 330 autoconfiguration [RFC4862] on most links. 332 2.1.6. Uniqueness 334 An IPv6 address used for an IPv4 host must be unique (i.e., not 335 ambiguously map to multiple possible IPv4 hosts) within the IPv6 336 network that can use that address. For example, since private IPv4 337 addresses can be reused within multiple IPv4 networks, an IPv6 338 network that connects to multiple such IPv4 networks cannot rely on 339 the IPv4 address itself providing uniqueness. 341 2.2. Types of Prefixes 343 A prefix may be intended for use in IPv6 addresses assigned to IPv6 344 hosts, or for use in IPv6 addresses used for IPv4 hosts. In either 345 case, there are two types of prefixes that can be used. 347 2.2.1. Network-Specific Prefix 349 IPv6 prefixes are assigned to a network operator by its regional 350 internet registrar (RIR). From an IPv6 prefix assigned to the 351 operator, the operator chooses a longer prefix for use by the 352 operator's translator(s). Hence a given IPv4 address would have 353 different IPv6 representations in different networks that use 354 different prefixes. A network-specific prefix is also known as a 355 Local Internet Registry (LIR) prefix. 357 If the network operator is an ISP that has been allocated a /32 or 358 shorter, then it may be possible for the ISP to allocate a fairly 359 short prefix such as a /40. However, if the network operator is an 360 end site with a /48, then the prefixes for the translator would be 361 much longer, such as a /56. Using a /56 prefix still leaves 24 bits 362 that can be used (without routing on prefixes longer than 80 bits) 363 for routes via different translators. However, since a prefix that 364 originates from an RIR will not start with binary 000, the use of the 365 71st bit cannot be used by any format with a network-specific prefix. 367 2.2.2. Well-Known Prefix 369 A well-known prefix is an IPv6 prefix assigned by IANA for use in an 370 algorithmic mapping. Hence a given IPv4 address would have the same 371 IPv6 representation in all networks that use the same well-known 372 prefix. 374 Rather than requiring manual configuration of the IPv6 prefixes in 375 each device in a network (and for each network to which a given 376 device can connect), a well-known prefix can be implemented by 377 default until there exists a protocol to learn the policies. Using a 378 network-specific prefix allows no such factory defaults. 380 Another benefit of a well-known prefix over a network-specific prefix 381 is that a short prefix length can be used, allowing greater 382 flexibility in the choice of format and support for multiple 383 translators, while not requiring routing on prefixes longer than 80 384 bits. 386 Finally, a well-known prefix can start with binary 000, allowing the 387 use of all subsequent bits. 389 Two examples of well-known prefixes, as specified in [RFC2765] 390 section 2.1, are: 391 o IPv4-mapped: This prefix is 0:0:0:0:0:ffff::/96, and addresses in 392 this prefix are used for IPv4 hosts. 393 o IPv4-translatable: This prefix is 0:0:0:0:ffff:0::/96, and 394 addresses in this prefix are assigned to IPv6 hosts. However, 395 since this prefix is longer than /64, this prefix does not work 396 with stateless address autoconfiguration. Hence some other 397 mechanism for configuring IPv6 hosts must be used with this 398 prefix. 400 Note that both of the above prefixes start with binary 000, and hence 401 there is no issue with the 71st bit. 403 2.3. Scenario-Specific Discussion and Recommendations 405 In this section we discuss four topologies in which IPv6/IPv4 406 translation is interesting. In each topology, initiating 407 communication can be attempted from either the IPv6 side or the IPv4 408 side, though it may or may not be supported. 410 2.3.1. Connecting the IPv6 Internet to the IPv4 Internet 412 This scenario need not be supported for communication initiated from 413 either side. 415 ________ ________ 416 / \ +----------+ / \ 417 | IPv4 |--|IPv6/IPv4 |--| IPv6 | 418 \Internet/ |Translator| \Internet/ 419 -------- +----------+ -------- 421 2.3.2. Connecting an IPv6 network to the IPv4 Internet 423 [EDITOR'S NOTE: draft-xli-behave-v4v6-prefix-00 section 5.1.1.2 was 424 hard to follow, and contained some statements that got significant 425 pushback on the list. This section tries to take these into account, 426 but there may still be some points missing.] 428 The figure below shows an IPv6 network connected to the IPv6 429 Internet, and also to the IPv4 network via an IPv6/IPv4 translator. 431 ________ _______ ________ 432 / \ +----------+ / An \ / \ 433 | IPv4 |--|IPv6/IPv4 |--| IPv6 |---| IPv6 | 434 \Internet/ |Translator| \Network/ \Internet/ 435 -------- +----------+ ------- -------- 437 For the IPv6 prefix used for IPv4 hosts, all IPv6-capable devices 438 served by the translator SHOULD be configurable with preference 439 policies consistent with [RFC3484], and SHOULD default to having the 440 Well-Known Mapped Prefix defined in Section 5 in this table, with a 441 lower preference than either native IPv4 or native IPv6 addresses. 443 Similarly, all address translators MUST be configurable with the IPv6 444 prefix to use for IPv4 hosts, and SHOULD use the Well-Known Mapped 445 Prefix unless configured with a network-specific prefix. 447 When any well-known prefix is used by a given network, it MUST NOT be 448 advertised into the IPv6 Internet, to prevent pollution of the global 449 IPv6 routing table by elements of the IPv4 routing table. Therefore, 450 a site which also has a native IPv6 connection MUST NOT advertise a 451 well-known prefix on that connection, and native IPv6 network 452 operators MUST filter out and discard any prefix routing 453 advertisements for the well-known prefix. 455 Furthermore, to avoid being used as transit, the IPv6 network should 456 not advertise into the IPv6 Internet the IPv6 prefix used for IPv4 457 hosts, regardless of whether it is network-specific or well-known. 458 This is easy to ensure when the IPv6 prefix used for IPv4 hosts is 459 disjoint from the IPv6 prefix used for IPv6 hosts. 461 For the IPv6 prefix used to assign addresses to IPv6 hosts, the use 462 differs between stateless and stateful translation. 464 2.3.2.1. Stateful Translation 466 When stateful translation is used, the choice of IPv6 prefix for 467 addresses assigned to IPv6 hosts is unaffected, since algorithmic 468 mapping is not used for these addresses. 470 2.3.2.2. Stateless Translation 472 "An IPv6 network" will advertise to the IPv6/IPv4 translator the 473 prefix for IPv6 addresses assigned to IPv6 hosts (and similarly the 474 IPv6/IPv4 translator will advertise into "an IPv6 network" the IPv6 475 prefix used for IPv4 hosts). 477 On the other side, towards the IPv6 Internet, the IPv6 network 478 advertises into the IPv6 Internet an IPv6 prefix for IPv6 addresses 479 assigned to IPv6 hosts. This prefix, used to be reachable from the 480 IPv6 Internet, may or may not be the same as the prefix used to 481 assign to hosts IPv6 addresses that are reachable from the IPv4 482 Internet, but it seems simplest to only require one prefix (and hence 483 one global IPv6 address per host). 485 2.3.3. Connecting an IPv4 network to the IPv6 Internet 487 For this scenario, shown in the following figure, only stateful 488 translation can be used in general, and an algorithmic mapping is not 489 relevant for IPv6 addresses assigned to IPv6 hosts since they are not 490 under the control of the same organization as the translator. (Note 491 that algorithmic mapping can be used if communication with only a 492 small subset of the IPv6 Internet is supported. That scenario is 493 covered in Section 2.3.4.) 495 ________ _______ ________ 496 / \ +----------+ / An \ / \ 497 | IPv6 |--|IPv6/IPv4 |--| IPv4 |---| IPv4 | 498 \Internet/ |Translator| \Network/ \Internet/ 499 -------- +----------+ ------- -------- 501 For IPv6 addresses used for the IPv4 hosts, the following 502 considerations apply. If the IPv4 network uses private IPv4 503 addresses, a well-known prefix will not work since there is no 504 distinction among IPv4 networks using the same private IPv4 address 505 block. Therefore, a network-specific prefix MUST be used. If the 506 IPv4 network uses public IPv4 addresses, it will inject a route into 507 the IPv6 routing table pointing to its translator(s). Hence the 508 routing scalability requirement requires that an IPv6 network- 509 specific prefix again MUST be used. 511 2.3.4. Connecting between an IPv4 network and an IPv6 network 513 TO BE FILLED IN 515 ________ _______ _______ ________ 516 / \ / An \ +----------+ / An \ / \ 517 | IPv4 |---| IPv4 |--|IPv6/IPv4 |--| IPv6 |---| IPv6 | 518 \Internet/ \Network/ |Translator| \Network/ \Internet/ 519 -------- ------- +----------+ ------- -------- 521 3. IPv6 Address Format and Translation Algorithms 523 There are multiple mechanisms used today to algorithmically map 524 between an IPv6 address and an IPv4 address, and more may be defined 525 over time. In this section, we first present a set of requirements 526 for such mechanisms, and then evaluate a number of existing 527 mechanisms. 529 3.1. Requirements 530 1. An algorithm MUST be one-to-one and reversible. 531 2. Unless the prefix starts with binary 000, an address format MUST 532 NOT use the 71st bit for any purpose other than indicating 533 universal/local as specified in [RFC4291], 534 3. An address format SHOULD provide support for multiple IPv6/IPv4 535 translators using different routes advertised into the IPv6 536 network (and different routes advertised into the IPv4 network). 537 4. An address format intended to be used with a stateless translator 538 SHOULD be checksum-neutral. That is, the IPv6 address and its 539 corresponding IPv4 address should result in the same one's 540 complement checksum to avoid having to parse or modify the 541 transport header. Simply relying on an administrator to choose a 542 checksum-neutral prefix is tricky and hence error-prone. An 543 algorithm that automatically compensates no matter what the 544 administrator types is less harmful that one that does not. Note 545 that checksum-neutral translation only benefits stateless 546 translators that maintain a one-to-one mapping between an IPv4 547 address and an IPv6 address, since otherwise it has to have 548 transport-specific behavior anyway. 549 5. For ease of readability and debugging, an address format that is 550 not designed to intentionally hide the IPv4 address SHOULD allow 551 accepting and/or displaying an embedded IPv4 address in dotted- 552 decimal form. This is done today for a variety of address 553 formats (e.g., IPv4-mapped and IPv4-translatable addresses as 554 discussed below, IPv4-compatible addresses which were deprecated 555 by [RFC4291] Section 2.5.5.1, and ISATAP [RFC5214] addresses). 556 Per [RFC4291] Section 2.2, this can only be done when the 557 embedded IPv4 address appears in the low-order 32 bits. It is 558 not done when an IPv4 address is embedded elsewhere in the 559 address (as in a 6to4 address). Displaying an address using 560 dotted-decimal can only be done when some other portion of the 561 IPv6 address is used to indicate displaying the low-order 32 bits 562 in dotted-decimal form. 563 6. When the IPv4 network is a private network for which the topology 564 is considered sensitive information, the algorithm SHOULD provide 565 a way to hide the details of the internal IPv4 subnetting scheme. 566 Note that there may be other mechanisms of discovering the 567 topology beyond merely inspecting addresses, so while this is not 568 sufficient in itself, it is a necessary component of any larger 569 solution. Also note that providing this capability conflicts 570 with requirement 3. 571 7. An algorithm MAY provide the ability to hide an IPv4 address from 572 "helpful" IPv4 NATs. Consider the scenarios depicted below with 573 IPv4 NATs that attempt to be "helpful" by looking for the NAT's 574 public IPv4 address in inbound application payloads and then 575 translating it to a private IPv4 address, and similarly 576 translating a private IPv4 address to the NAT's public IPv4 577 address in outbound payloads. While this can break applications 578 since the same bytes that appear in the IPv4 address can appear 579 normally in the payload purely by coincidence, the fact remains 580 that many NATs have been observed to do this in an attempt to 581 make other protocols work. 583 In the first scenario (an IPv6 address assigned to an IPv6 host), 584 an IPv4 NAT has IPv4 public address Y, and an address translator 585 uses IPv4 address X to map to an IPv6 address assigned to the 586 IPv6 host. If the IPv6 host sends an application payload that 587 includes an IPv6 address that directly embeds X (e.g., 588 ::ffff:0:X) then this may be translated by the IPv4 NAT to 589 ::ffff:0:Y, and similarly if the IPv4 host sends an application 590 payload that includes ::ffff:0:Y then this may be translated by 591 the IPv4 NAT to ::ffff:0:X. This may or may not be desirable. 593 ________ 594 X Y / IPv4 \ 595 IPv6 ---- IPv6/IPv4 ------- "Helpful" ---| Internet |- IPv4 596 Host Translator IPv4 NAT \________/ Host 598 In the second scenario (an IPv6 address used for an IPv4 host), 599 the IPv4 NAT has public address Y, and the IPv4 host behind it 600 has address Z. If the IPv6 host sends an application payload that 601 includes an IPv6 address that directly embeds Y (e.g., ::ffff:Y) 602 then this may be translated by the IPv4 NAT to ::ffff:Z, and 603 similarly if the IPv4 host sends an application payload that 604 includes ::ffff:Z then this may be translated by the IPv4 NAT to 605 ::ffff:Y. This may or may not be desirable. 607 ________ 608 / IPv4 \ Y Z 609 IPv6 ---- IPv6/IPv4 --| Internet |----- "Helpful" --- IPv4 610 Host Translator \________/ IPv4 NAT Host 612 As a result, protocols such as Teredo [RFC4380] and STUN 613 [RFC5389] today avoid such problems by obscuring the IPv4 address 614 using XOR. 616 Note that providing this capability conflicts with requirement 3, 617 but anything that meets requirement 4 will also meet this 618 requirement. 620 3.2. Mechanisms 622 In this section we discuss a number of mechanisms for algorithmic 623 mapping. [EDITOR'S NOTE: currently the subsections are ordered from 624 most specific to most general. Would the opposite order be more or 625 less readable?] 627 3.2.1. IPv4-Mapped IPv6 Addresses 629 IPv4-mapped IPv6 addresses are defined in [RFC4291] Section 2.5.5.2 630 as IPv6 addresses used for IPv4 hosts, using the format ::ffff: 631 a.b.c.d, where a.b.c.d is the corresponding IPv4 address. IPv4- 632 mapped IPv6 addresses are used both on the wire ([RFC2765]) when 633 translation is done in the network, as well as within hosts (e.g., 634 [RFC3493]) when translation is done in the end system. This format 635 was designed to be checksum-neutral, and obviously uses a well-known 636 prefix. It is widely deployed in host operating systems today. 638 3.2.2. IPv4-Translatable Addresses 640 IPv4-translatable addresses (also known as IPv4-translated addresses) 641 are defined in [RFC2765] Section 2.1 as addresses assigned to IPv6 642 hosts, using the format ::ffff:0:a.b.c.d, where a.b.c.d is a 643 corresponding IPv4 address used by a translator. IPv4-translatable 644 addresses are used on the wire ([RFC2765]) when translation is done 645 in the network. Hypothetically they could be used within hosts when 646 translation is done in the end system, but there is no specification 647 of this at present. This format was also designed to be checksum- 648 neutral, and obviously uses a well-known-prefix. It is not known to 649 be widely deployed today. 651 OPEN ISSUE: Should IPv4-translatable addresses be deprecated by this 652 document, or should it continue to be used as the well-known default 653 prefix for this purpose? For now, we assume it will continue to be 654 used as the well-known default prefix for this purpose. 656 3.2.3. Zero-Pad And Embed 658 In this mechanism, the IPv4 address is placed in the last 32-bits, 659 after a 96-bit configured prefix. That is, a well-known or network- 660 specific prefix is zero-padded to 96 bits. This is referred to as 661 PREFIX::/96 in the deprecated [RFC2766], resulting in addresses of 662 the form PREFIX::a.b.c.d, where a.b.c.d is the corresponding IPv4 663 address. Note that typically the dotted-decimal form can only be 664 used for input and in documentation, but not display since display 665 would require the PREFIX to be known to all displaying systems to 666 indicate the use of dotted-decimal. 668 | 96 bits | 32 bits | 669 +-------------------------------------------+---------------------+ 670 | PREFIX | IPv4 address | 671 +-------------------------------------------+---------------------+ 673 This format is not checksum-neutral unless the PREFIX is checksum- 674 neutral. Hence, a well-known prefix can ensure checksum neutrality, 675 but using this format with network-specific prefixes in general 676 cannot. 678 The universal/local bit in the Modified EUI-64 occurs in the prefix 679 and MUST be set to zero unless the IPv4 address is known to be global 680 (but can be set to zero even if it is known to be global). 682 Note that IPv4-mapped and IPv4-translatable addresses are a special 683 case of this mechanism, where the PREFIX is well-known. 685 3.2.4. Compensation-Pad And Embed 687 This potential mechanism is the same as Zero-Pad And Embed 688 (Section 3.2.3), except that it provides checksum neutrality and 689 hence benefits stateless IPv6/IPv4 translators. A configured well- 690 known or network-specific PREFIX::/80 is followed by 16 bits that 691 result in the first 96 bits being checksum-neutral. 693 | 80 bits | 16 | 32 bits | 694 +--------------------------------------+----+---------------------+ 695 | PREFIX |comp| IPv4 address | 696 +--------------------------------------+----+---------------------+ 698 The universal/local bit in the Modified EUI-64 occurs in the prefix 699 and MUST be set to zero unless the IPv4 address is known to be global 700 (but can be set to zero even if it is known to be global). 702 3.2.5. Embed And Zero-Pad 704 In this mechanism (often referred to as "IVI"), the IPv4 address is 705 embedded immediately after a routable prefix, and then zero-padded at 706 the end. 708 | n bits | 32 bits | 96-n bits | 709 +--------------------------+---------------------+----------------+ 710 | PREFIX | IPv4 address | Zero | 711 +--------------------------+---------------------+----------------+ 713 [EDITOR'S NOTE: draft-baker-behave-v4v6-framework disallowed PREFIX 714 being 64-95 bits long, without explanation. IPv6 addresses used for 715 IPv4 hosts should be fine to use prefixes of other lengths. Hence 716 suggested clarifying text below. For IPv6 addresses assigned to IPv6 717 hosts, kept the restriction though I do not understand why this is 718 needed and hence still consider this an OPEN ISSUE.] 720 The IPv4 address is intended to straddle the boundary between the 721 prefix used in routable tables and the bits in the host portion. For 722 IPv6 addresses assigned to IPv6 hosts, this would require a PREFIX of 723 length 32..63 bits. For IPv6 addresses used for IPv4 hosts, any 724 PREFIX length is sufficient. 726 However, if the PREFIX is a network-specific prefix, rather than a 727 well-known prefix, this mechanism requires the prefix to be less than 728 38 bits (so that the IPv4 address would end prior to the universal/ 729 local bit), or at least 71 bits (so that the IPv4 address would begin 730 after the universal/local bit). 732 Note that Zero-Pad and Embed can be considered to be a special case 733 of this mechanism, where the PREFIX is 96 bits and the SUFFIX is 0 734 bits. 736 3.2.6. Preconfigured Mapping Table 738 In this, the most general, mechanism, an IPv6/IPv4 address translator 739 is preconfigured with a mapping table including all legal pairs. Any 740 IPv6 and IPv4 addresses can be used. This mechanism is not checksum- 741 neutral. Since the IPv4 address is not embedded in any way, it need 742 not reveal any details of the IPv4 topology, and minimizes issues 743 with "helpful" IPv4 NATs. 745 3.3. Scenario-Specific Discussion and Recommendations 747 In this section we discuss four topologies in which IPv6/IPv4 748 translation is interesting. In each topology, initiating 749 communication can be attempted from either the IPv6 side or the IPv4 750 side. 752 3.3.1. Connecting the IPv6 Internet to the IPv4 Internet 754 This scenario need not be supported. 756 3.3.2. Connecting an IPv6 network to the IPv4 Internet 758 Since the IPv4 network is the Internet, there is negligible value in 759 trying to hide the topology details of the IPv4 network and hence 760 requirement 4 does not apply. The other requirements all apply 761 normally. 763 TO BE FILLED IN 765 3.3.3. Connecting an IPv4 network to the IPv6 Internet 767 In this scenario, only stateful translation can be used and hence 768 requirement 2 does not apply. The other requirements all apply 769 normally. 771 TO BE FILLED IN 773 3.3.4. Connecting between an IPv4 network and an IPv6 network 775 Typically the IPv4 network and the IPv6 network are managed by the 776 same organization in this scenario, and hence it is not necessary to 777 hide the topology details of the IPv4 network and requirement 4 does 778 not apply in this case. The other requirements all apply normally. 780 TO BE FILLED IN 782 4. Security Considerations 784 The prefix and format need to be the same among multiple devices in 785 the same network (e.g., hosts that need to prefer native over 786 translated addresses, DNS gateways, and IPv6/IPv4 translators). As 787 such, the means by which they are learned/configured must be secure. 788 Specifying a default prefix and/or format in implementations provides 789 one way to configure them securely. Any alternative means of 790 configuration is responsible for specifying how to do so securely. 792 5. IANA Considerations 794 A future version of this memo will request an IPv6 prefix assignment 795 as a Well-Known Mapped Prefix, that is used for IPv4 hosts, and which 796 must start with binary 000. 798 [EDITOR'S NOTE: 0/8 is reserved by the IETF (and not allocated by 799 IANA), so all that is needed is to specify the prefix herein since it 800 is an allocation from IETF not from IANA.] 802 OPEN ISSUE: The prefix length of this block has not yet been 803 determined. Some possibilities are /16, /32, /48 or /96. 805 6. Acknowledgements 807 Many people in the Behave WG have contributed to the discussion that 808 led to this document, including Andrew Sullivan, Andrew Yourtchenko, 809 Brian Carpenter, Congxiao Bao, Dan Wing, Ed Jankiewicz, Fred Baker, 810 Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Keith Moore, 811 Kevin Yin, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret 812 Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis- 813 Courmont, Remi Despres, William Waites and Xing Li. 815 7. Contributors 817 The following individuals co-authored drafts from which text has been 818 incorporated, and are listed in alphabetical order. 820 Congxiao Bao 821 CERNET Center/Tsinghua University 822 Room 225, Main Building, Tsinghua University 823 Beijing, 100084 824 China 825 Phone: +86 62785983 826 Email: congxiao@cernet.edu.cn 828 Fred Baker 829 Cisco Systems 830 Santa Barbara, California 93117 831 USA 832 Phone: +1-408-526-4257 833 Fax: +1-413-473-2403 834 Email: fred@cisco.com 836 Hiroshi Miyata 837 Yokogawa Electric Corporation 838 2-9-32 Nakacho 839 Musashino-shi, Tokyo 180-8750 840 JAPAN 841 Email: h.miyata@jp.yokogawa.com 843 Marcelo Bagnulo 844 Universidad Carlos III de Madrid 845 Av. Universidad 30 846 Leganes, Madrid 28911 847 ESPANA 848 Email: marcelo@it.uc3m.es 850 Xing Li 851 CERNET Center/Tsinghua University 852 Room 225, Main Building, Tsinghua University 853 Beijing, 100084 854 China 855 Phone: +86 62785983 856 Email: xing@cernet.edu.cn 858 8. References 860 8.1. Normative References 862 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 863 3", BCP 9, RFC 2026, October 1996. 865 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 866 Architecture", RFC 4291, February 2006. 868 8.2. Informative References 870 [I-D.bagnulo-behave-dns64] 871 Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and 872 M. Endo, "DNS64: DNS extensions for Network Address 873 Translation from IPv6 Clients to IPv4 Servers", 874 draft-bagnulo-behave-dns64-02 (work in progress), 875 March 2009. 877 [I-D.baker-behave-v4v6-framework] 878 Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 879 Translation", draft-baker-behave-v4v6-framework-02 (work 880 in progress), February 2009. 882 [I-D.wing-behave-nat64-referrals] 883 Wing, D., "Referrals Across a NAT64", 884 draft-wing-behave-nat64-referrals-00 (work in progress), 885 March 2009. 887 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 888 (SIIT)", RFC 2765, February 2000. 890 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 891 Translation - Protocol Translation (NAT-PT)", RFC 2766, 892 February 2000. 894 [RFC3484] Draves, R., "Default Address Selection for Internet 895 Protocol version 6 (IPv6)", RFC 3484, February 2003. 897 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 898 Stevens, "Basic Socket Interface Extensions for IPv6", 899 RFC 3493, February 2003. 901 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 902 Network Address Translations (NATs)", RFC 4380, 903 February 2006. 905 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 906 Address Autoconfiguration", RFC 4862, September 2007. 908 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 909 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 910 March 2008. 912 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 913 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 914 October 2008. 916 Author's Address 918 Dave Thaler (editor) 919 Microsoft Corporation 920 One Microsoft Way 921 Redmond, WA 98052 922 USA 924 Phone: +1 425 703 8835 925 Email: dthaler@microsoft.com