idnits 2.17.1 draft-ietf-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.i 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 236: '...ases, an IPv6-only node SHOULD be able...' RFC 2119 keyword, line 252: '... SHOULD be able to distinguish a nat...' RFC 2119 keyword, line 445: '...y the translator SHOULD be configurabl...' RFC 2119 keyword, line 446: '... preference policies consistent with [RFC3484], and SHOULD default to...' RFC 2119 keyword, line 451: '...ress translators MUST be configurable ...' (16 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 (August 21, 2009) is 5361 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 934, but no explicit reference was found in the text == Unused Reference: 'I-D.wing-behave-nat64-referrals' is defined on line 954, 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 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: February 22, 2010 M. Bagnulo 7 UC3M 8 M. Boucadair 9 France Telecom 10 X. Li 11 CERNET Center/Tsinghua University 12 August 21, 2009 14 IPv6 Addressing of IPv4/IPv6 Translators 15 draft-ietf-behave-translator-addressing-00.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 22, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This document discusses how an individual IPv6 address can be 54 algorithmically translated to a corresponding IPv4 address, and vice 55 versa, using only statically configured information. This technique 56 is used in IPv4/IPv6 translators, as well as other types of proxies 57 and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. IPv6 Addresses Assigned to IPv6 Hosts . . . . . . . . . . 4 63 1.2. IPv6 Addresses Used to Represent IPv4 Hosts . . . . . . . 5 64 2. Prefix Selection . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1.1. IPv6 Routing System Scalability . . . . . . . . . . . 6 67 2.1.2. Native Connectivity Preference for Dual-Stack Nodes . 6 68 2.1.3. Referral Support . . . . . . . . . . . . . . . . . . . 7 69 2.1.4. Support for Multiple IPv4/IPv6 Translators . . . . . . 7 70 2.1.5. Appropriate Prefix Length . . . . . . . . . . . . . . 8 71 2.1.6. Uniqueness . . . . . . . . . . . . . . . . . . . . . . 9 72 2.2. Types of Prefixes . . . . . . . . . . . . . . . . . . . . 9 73 2.2.1. Network-Specific Prefix . . . . . . . . . . . . . . . 9 74 2.2.2. Well-Known Prefix . . . . . . . . . . . . . . . . . . 9 75 2.3. Scenario-Specific Discussion and Recommendations . . . . . 10 76 2.3.1. Scenario 1: an IPv6 network to the IPv4 Internet . . . 10 77 2.3.2. Scenario 2: the IPv4 Internet to an IPv6 network . . . 12 78 2.3.3. Scenario 3: the IPv6 Internet to an IPv4 network . . . 12 79 2.3.4. Scenario 4: an IPv4 network to the IPv6 Internet . . . 12 80 2.3.5. Scenario 5: an IPv6 network to an IPv4 network . . . . 12 81 2.3.6. Scenario 6: an IPv4 network to an IPv6 network . . . . 13 82 2.3.7. Scenario 7: the IPv6 Internet to the IPv4 Internet . . 13 83 2.3.8. Scenario 8: the IPv4 Internet to the IPv6 Internet . . 13 84 3. IPv6 Address Format and Translation Algorithms . . . . . . . . 13 85 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 13 86 3.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 15 87 3.2.1. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . 15 88 3.2.2. IPv4-Translatable Addresses . . . . . . . . . . . . . 15 89 3.2.3. Zero-Pad And Embed . . . . . . . . . . . . . . . . . . 16 90 3.2.4. Compensation-Pad And Embed . . . . . . . . . . . . . . 16 91 3.2.5. Embed And Zero-Pad . . . . . . . . . . . . . . . . . . 17 92 3.2.6. Preconfigured Mapping Table . . . . . . . . . . . . . 18 93 3.3. Scenario-Specific Discussion and Recommendations . . . . . 18 94 3.3.1. Scenario 1: an IPv6 network to the IPv4 Internet . . . 18 95 3.3.2. Scenario 2: the IPv4 Internet to an IPv6 network . . . 18 96 3.3.3. Scenario 3: the IPv6 Internet to an IPv4 network . . . 18 97 3.3.4. Scenario 4: an IPv4 network to the IPv6 Internet . . . 18 98 3.3.5. Scenario 5: an IPv6 network to an IPv4 network . . . . 19 99 3.3.6. Scenario 6: an IPv4 network to an IPv6 network . . . . 19 100 3.3.7. Scenario 7: the IPv6 Internet to the IPv4 Internet . . 19 101 3.3.8. Scenario 8: the IPv4 Internet to the IPv6 Internet . . 19 102 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 103 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 104 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 105 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 108 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 111 1. Introduction 113 This document is part of a series of IPv4/IPv6 translation documents. 114 A framework for IPv4/IPv6 translation is discussed in 115 [I-D.baker-behave-v4v6-framework], including a taxonomy of scenarios 116 that will be used in this document. Other documents specify the 117 behavior of various types of translators and gateways, including 118 mechanisms for translating between IP headers and other types of 119 messages that include IP addresses. This document specifies how an 120 individual IPv6 address is translated to a corresponding IPv4 121 address, and vice versa, in cases where an algorithmic mapping is 122 used. While specific types of devices are used herein as examples, 123 it is the responsibility of the specification of such devices to 124 reference this document for algorithmic mapping of the addresses 125 themselves. 127 In this document, an "IPv4/IPv6 translator" is an entity that 128 translates IPv4 packets to IPv6 packets, and vice versa. It may do 129 "stateless" translation, meaning that there is no per-flow state 130 required, or "stateful" translation where per-flow state is created 131 when the first packet in a flow is received. 133 In this document, an "address translator" is any entity that has to 134 derive an IPv4 address from an IPv6 address or vice versa. This 135 applies not only to devices that do IPv4/IPv6 packet translation, but 136 also to other entities that manipulate addresses, such as name 137 resolution proxies (e.g., DNS64 [I-D.bagnulo-behave-dns64]) and 138 possibly other types of Application Layer Gateways (ALGs). 140 [OPEN ISSUE: addressing for encapsulation mechanisms such as Dual- 141 Stack Lite, including use of port ranges, is currently treated as out 142 of scope for this document. Should such addressing be in scope?] 144 In choosing a mapping between IPv4 and IPv6 addresses for a given 145 scenario, there are two separate choices to make: choosing an IPv6 146 prefix, and choosing an algorithm for constructing the remainder of 147 the IPv6 address. These two topics are covered in Section 2 and 148 Section 3, respectively. 150 Algorithmic derivation of an IPv4 address from an IPv6 address, or 151 vice versa, is used with two different classes of IPv6 addresses, 152 discussed in Section 1.1 and Section 1.2. 154 1.1. IPv6 Addresses Assigned to IPv6 Hosts 156 In an IPv6 network, IPv6 addresses are assigned to IPv6 hosts, and 157 these IPv6 addresses need to be translated to IPv4 addresses that can 158 be used by IPv4 hosts. Such IPv4 addresses are not assigned to a 159 host, but packets destined to such addresses must be routed to an 160 appropriate IPv4/IPv6 translator that handles a set of such IPv4 161 addresses. Thus, stateless address translation mechanisms typically 162 put constraints on what IPv6 addresses can be assigned to IPv6 hosts 163 that want to communicate with IPv4 destinations using an algorithmic 164 mapping (although such hosts may have other IPv6 addresses used for 165 other purposes such as link-local communication). Without such 166 constraints, stateful translation on such addresses must be done 167 instead, which typically only supports initiation from the IPv6 side, 168 and does not result in stable addresses that can be used in DNS and 169 other protocols and applications that do not deal well with highly 170 dynamic addresses. 172 IPv6 addresses assigned to IPv6 hosts for use with stateless 173 translation are referred to as "IPv4-translatable" IPv6 addresses in 174 [RFC2765] although that term is also used to refer to a specific 175 address format (defined in [RFC2765] section 2.1) and hence we avoid 176 the use of this term herein except when referring to the specific 177 IPv6 address format. 179 1.2. IPv6 Addresses Used to Represent IPv4 Hosts 181 In an IPv4 network, IPv4 addresses are assigned to IPv4 hosts, and 182 these IPv4 addresses need to be translated to IPv6 addresses that can 183 be used by IPv6 hosts. Such IPv6 addresses are not assigned to a 184 host, but packets destined to such addresses are routed to an 185 appropriate IPv4/IPv6 translator that handles a set of such IPv6 186 addresses. Typically, there are no additional constraints put on the 187 IPv4 addresses. Unlike the addresses discussed in Section 1.1, 188 algorithmic mapping of IPv6 addresses used to represent IPv4 hosts is 189 used with both stateful and stateless translation. 191 IPv6 addresses used to represent IPv4 hosts are referred to as "IPv4- 192 mapped" IPv6 addresses in [RFC2765] although that term is also used 193 to refer to a specific address format (defined in [RFC2765] section 194 2.1) and hence we avoid the use of this term herein except when 195 referring to the specific address format. 197 2. Prefix Selection 199 This section discusses the choice of IPv6 prefixes for use with the 200 two classes of addresses outlined above. 202 2.1. Requirements 204 There are a number of important requirements to be considered for 205 prefix selection. 207 2.1.1. IPv6 Routing System Scalability 209 One critical issue to consider to assess impact of the IPv6 prefix 210 used is related to the scalability of the IPv6 routing system. Since 211 a goal of translation is to enable IPv4-only hosts and IPv6-only 212 nodes to communicate, the IPv6 addresses used to represent IPv4 hosts 213 need to be routable within the IPv6 network served by the IPv4/IPv6 214 translator. This implies that a prefix covering such addresses must 215 be covered by one or more routes advertised in that IPv6 network. In 216 some scenarios a single IPv6 route may suffice, whereas other 217 scenarios may require multiple (more specific) routes. It is 218 important, however, to avoid injecting an IPv6 route for every IPv4 219 route in the Internet. 221 2.1.2. Native Connectivity Preference for Dual-Stack Nodes 223 When dual stack nodes are involved in communication, a potential 224 issue arises if they prefer translated IPv4/IPv6 connectivity over 225 native IPv4 or IPv6 connectivity. 227 For communication initiated from an IPv6-only node towards a dual- 228 stack node, there are two possibilities: communicating to the native 229 IPv6 address of the destination, or communicating via an IPv4/IPv6 230 translator to the IPv4 address of the destination (by using an IPv6 231 address that is translated to the IPv4 address). In some cases this 232 may be solved by having the IPv6-only node only learn the native IPv6 233 address and not the algorithmically derived one (e.g., by using a 234 normal DNS resolver), but this is not possible in general due to the 235 variety of mechanisms for learning the destination addresses (e.g., 236 referrals). To cover those cases, an IPv6-only node SHOULD be able 237 to distinguish a native IPv6 address from an IPv6 address used to 238 represent an IPv4 host. 240 For communication initiated from a dual-stack node toward an IPv4- 241 only node, there are two possibilities: communicating to the native 242 IPv4 address of the destination, or communicating via an IPv4/IPv6 243 translator to the IPv4 address of the destination (by using an IPv6 244 address that is translated to the IPv4 address). In some cases, this 245 may be solved by having the dual-stack node only learn the native 246 IPv4 address and not the algorithmically derived one, but this is not 247 possible in general due to the variety of mechanisms for learning the 248 destination addresses. Normally it is desirable for a dual-stack 249 node to prefer an IPv6 destination address over an IPv4 destination 250 address, but in this case the IPv6 destination address is worse 251 because it will be translated. Hence in general, a dual-stack node 252 SHOULD be able to distinguish a native IPv6 address from an IPv6 253 address used to represent an IPv4 host, so that the former can be 254 preferred over an IPv4 destination address but not the latter. 256 [RFC3484] today provides the ability for IPv6-capable hosts to be 257 configured with prefixes used for address sorting sufficient to solve 258 the native connectivity preference issue. However the gap today is 259 that this requires manual configuration of all such hosts, which is 260 not practical. 262 2.1.3. Referral Support 264 A referral operation is when a host A passes the IP address of a Host 265 B to a third Host C as application data. The Host C may then 266 initiate communication towards Host B using the IP address received. 268 At this point in time, there are several widely-available protocols 269 that operate on the IPv4 Internet and perform referrals, including 270 HTTP, DNS, SIP, and BitTorrent. The analysis in [I-D.wing-behave- 271 nat64-referrals] of SIP (which does referrals between IPv4 and IPv6) 272 shows that SIP needs to refer IPv4 addresses, not IPv6 addresses. 273 Thus, it doesn't matter what IPv6 prefix is used because an IPv6 274 address isn't referred. 276 [EDITOR'S NOTE: The wing document discusses BitTorrent but the text 277 pulled above from draft-xli-behave-v4v6prefix section 5.1.2.1 only 278 summarizes SIP. Furthermore, it doesn't cover other widely-deployed 279 protocols that do referrals such as HTTP or DNS and hence is 280 inconclusive. Finally, it's unclear whether it applies to IPv6 281 addresses of IPv4 hosts or of IPv6 hosts, or both. Hence, referral 282 support is still considered an OPEN ISSUE. Another OPEN ISSUE is 283 whether to incorporate text from draft-wing-behave-nat64-referrals 284 into this document. Other protocols are covered in I-D.carpenter- 285 behave-referral-object] 287 2.1.4. Support for Multiple IPv4/IPv6 Translators 289 For IPv6 addresses assigned to IPv6 hosts, the choice of translator 290 used in the IPv4-to-IPv6 direction is determined by the IPv4 address 291 it is mapped to, rather than by the choice of IPv6 prefix. 293 For IPv6 addresses used to represent IPv4 hosts, the choice of 294 translator used in the IPv6-to-IPv4 direction is determined by the 295 IPv6 address, but is somewhat orthogonal to the choice of prefix. In 296 general, it is possible to use a single IPv6 prefix for multiple 297 IPv4/IPv6 translators, or different prefixes for different IPv4/IPv6 298 translators. Using different prefixes can be achieved by inserting 299 additional subnet bits after a common prefix such that each IPv4/IPv6 300 translator uses a separate range of subnets. Often only the common 301 prefix needs to be configured (as opposed to each more-specific 302 prefix) in other types of address translators such as DNS64 devices. 304 If the translation is stateful, routing must be configured to ensure 305 that the return path flows through the same translator as the forward 306 path. (Stateless translation has no such requirement.) 308 2.1.5. Appropriate Prefix Length 310 This section discusses several issues related to prefix length 311 selection. 313 2.1.5.1. Routing Policy 315 [EDITOR'S NOTE: The text below needs to be rewritten somewhat. It's 316 currently hard to follow, and is missing justification for its 317 statements.] 319 The major issue for selecting the prefix length is the routing 320 policy. If IPv4/IPv6 translation is implemented within a subnet, 321 then a /96 should be fine. However, if IPv4/IPv6 translation is 322 implemented in an ISP's backbone, then the minimum prefix should be 323 /64 and in some cases should be /48. 325 2.1.5.2. Forwarding Efficiency 327 According to current specifications [EDITOR'S NOTE: need reference], 328 routers must handle routes containing prefixes of any valid length, 329 from 0 to 128. However, some users have reported that routers 330 exhibit worse performance when routing using prefixes longer than 80 331 bits. This implies that using routes with prefixes of 80 bits or 332 fewer would result in better performance in some cases. 334 2.1.5.3. EUI-64 Format 336 The use of a prefix length longer than 64 bits may affect the 337 Interface Identifier format. Specifically, [RFC4291] section 2.5.1 338 requires that for all unicast addresses, except those that start with 339 the binary value 000, Interface IDs are required to be 64 bits long 340 and to be constructed in Modified EUI-64 format. While any method 341 can be used to construct a Modified EUI-64, the format requires the 342 71st bit (the universal/local bit) to be set with specific meaning, 343 and hence it is not available for use by an address format unless the 344 prefix starts with binary 000. 346 Furthermore, for IPv6 addresses assigned to IPv6 hosts, the prefix 347 must be 64 bits or less in order to work with stateless address 348 autoconfiguration [RFC4862] on most links. 350 2.1.6. Uniqueness 352 An IPv6 address used to represent an IPv4 host must be unique (i.e., 353 not ambiguously map to multiple possible IPv4 hosts) within the IPv6 354 network that can use that address. For example, since private IPv4 355 addresses can be reused within multiple IPv4 networks, an IPv6 356 network that connects to multiple such IPv4 networks cannot rely on 357 the IPv4 address to provide uniqueness. 359 2.2. Types of Prefixes 361 A prefix may be intended for use in IPv6 addresses assigned to IPv6 362 hosts, or for use in IPv6 addresses used to represent IPv4 hosts. In 363 either case, there are two types of prefixes that can be used. 365 2.2.1. Network-Specific Prefix 367 IPv6 prefixes are assigned to a network operator by its regional 368 internet registrar (RIR). From an IPv6 prefix assigned to the 369 operator, the operator chooses a longer prefix for use by the 370 operator's translator(s). Hence a given IPv4 address would have 371 different IPv6 representations in different networks that use 372 different prefixes. A network-specific prefix is also known as a 373 Local Internet Registry (LIR) prefix. 375 If the network operator is an ISP that has been allocated a /32 or 376 shorter, then it may be possible for the ISP to allocate a fairly 377 short prefix such as a /40. However, if the network operator is an 378 end site with a /48, then the prefixes for the translator would be 379 much longer, such as a /56. Using a /56 prefix still leaves 24 bits 380 that can be used (without routing on prefixes longer than 80 bits) 381 for routes via different translators. However, since a prefix that 382 originates from an RIR will not start with binary 000, the use of the 383 71st bit cannot be used by any format with a network-specific prefix. 385 2.2.2. Well-Known Prefix 387 A well-known prefix is an IPv6 prefix assigned by IANA for use in an 388 algorithmic mapping. Hence a given IPv4 address would have the same 389 IPv6 representation in all networks that use the same well-known 390 prefix. 392 Rather than requiring manual configuration of the IPv6 prefixes in 393 each device in a network (and for each network to which a given 394 device can connect), a well-known prefix can be implemented by 395 default until there exists a protocol to learn the policies. Using a 396 network-specific prefix allows no such factory defaults. 398 Another benefit of a well-known prefix over a network-specific prefix 399 is that a short prefix length can be used, allowing greater 400 flexibility in the choice of format and support for multiple 401 translators, while not requiring routing on prefixes longer than 80 402 bits. 404 Finally, a well-known prefix can start with binary 000, allowing the 405 use of all subsequent bits. 407 Two examples of well-known prefixes, as specified in [RFC2765] 408 section 2.1, are: 409 o IPv4-mapped: This prefix is 0:0:0:0:0:ffff::/96, and addresses in 410 this prefix are used to represent IPv4 hosts. 411 o IPv4-translatable: This prefix is 0:0:0:0:ffff:0::/96, and 412 addresses in this prefix are assigned to IPv6 hosts. However, 413 since this prefix is longer than /64, this prefix does not work 414 with stateless address autoconfiguration. Hence some other 415 mechanism for configuring IPv6 hosts must be used with this 416 prefix. 418 Note that both of the above prefixes start with binary 000, and hence 419 there is no issue with the 71st bit. 421 2.3. Scenario-Specific Discussion and Recommendations 423 In this section we discuss four topologies in which IPv4/IPv6 424 translation is interesting. In each topology, initiating 425 communication can be attempted from either the IPv4 side or the IPv6 426 side, though it may or may not be supported. 428 2.3.1. Scenario 1: an IPv6 network to the IPv4 Internet 430 [EDITOR'S NOTE: draft-xli-behave-v4v6-prefix-00 section 5.1.1.2 was 431 hard to follow, and contained some statements that got significant 432 pushback on the list. This section tries to take these into account, 433 but there may still be some points missing.] 435 The figure below shows an IPv6 network connected to the IPv6 436 Internet, and also to the IPv4 network via an IPv4/IPv6 translator. 438 ________ _______ ________ 439 / \ +----------+ / An \ / \ 440 | IPv4 |--|IPv4/IPv6 |--| IPv6 |---| IPv6 | 441 \Internet/ |Translator| \Network/ \Internet/ 442 -------- +----------+ ------- -------- 444 For the IPv6 prefix used to represent IPv4 hosts, all IPv6-capable 445 devices served by the translator SHOULD be configurable with 446 preference policies consistent with [RFC3484], and SHOULD default to 447 having the Well-Known Mapped Prefix defined in Section 5 in this 448 table, with a lower preference than either native IPv4 or native IPv6 449 addresses. 451 Similarly, all address translators MUST be configurable with the IPv6 452 prefix to use to represent IPv4 hosts, and SHOULD use the Well-Known 453 Mapped Prefix unless configured with a network-specific prefix. 455 When any well-known prefix is used by a given network, it MUST NOT be 456 advertised into the IPv6 Internet, to prevent pollution of the global 457 IPv6 routing table by elements of the IPv4 routing table. Therefore, 458 a site which also has a native IPv6 connection MUST NOT advertise a 459 well-known prefix on that connection, and native IPv6 network 460 operators MUST filter out and discard any prefix routing 461 advertisements for the well-known prefix. 463 Furthermore, to avoid being used as transit, the IPv6 network MUST 464 NOT advertise into the IPv6 Internet the IPv6 prefix used to 465 represent IPv4 hosts, regardless of whether it is network-specific or 466 well-known. This is easy to ensure when the IPv6 prefix used to 467 represent IPv4 hosts is disjoint from the IPv6 prefix used to 468 represent IPv6 hosts. 470 For the IPv6 prefix used to assign addresses to IPv6 hosts, the use 471 differs between stateless and stateful translation. 473 2.3.1.1. Stateful Translation 475 When stateful translation is used, the choice of IPv6 prefix for 476 addresses assigned to IPv6 hosts is unaffected, since algorithmic 477 mapping is not used for these addresses. 479 2.3.1.2. Stateless Translation 481 "An IPv6 network" will advertise to the IPv4/IPv6 translator the 482 prefix for IPv6 addresses assigned to IPv6 hosts (and similarly the 483 IPv4/IPv6 translator will advertise into "an IPv6 network" the IPv6 484 prefix used to represent IPv4 hosts). 486 On the other side, towards the IPv6 Internet, the IPv6 network 487 advertises into the IPv6 Internet an IPv6 prefix for IPv6 addresses 488 assigned to IPv6 hosts. This prefix, used to be reachable from the 489 IPv6 Internet, may or may not be the same as the prefix used to 490 assign to hosts IPv6 addresses that are reachable from the IPv4 491 Internet, but it seems simplest to only require one prefix (and hence 492 one global IPv6 address per host). 494 2.3.2. Scenario 2: the IPv4 Internet to an IPv6 network 496 The considerations are the same as in scenario 1, except that 497 stateful translation only supports initiation from the IPv6 side, and 498 hence only stateless translation can be used in this scenario. 500 2.3.3. Scenario 3: the IPv6 Internet to an IPv4 network 502 For this scenario, shown in the following figure, only stateful 503 translation can be used in general, and an algorithmic mapping is not 504 relevant for IPv6 addresses assigned to IPv6 hosts since they are not 505 under the control of the same organization as the translator. (Note 506 that algorithmic mapping can be used if communication with only a 507 small subset of the IPv6 Internet is supported. That scenario is 508 covered in Section 2.3.6.) 510 ________ _______ ________ 511 / \ +----------+ / An \ / \ 512 | IPv6 |--|IPv4/IPv6 |--| IPv4 |---| IPv4 | 513 \Internet/ |Translator| \Network/ \Internet/ 514 -------- +----------+ ------- -------- 516 For IPv6 addresses used to represent the IPv4 hosts, the following 517 considerations apply. If the IPv4 network uses private IPv4 518 addresses, a well-known prefix will not work since there is no 519 distinction among IPv4 networks using the same private IPv4 address 520 block. Therefore, a network-specific prefix MUST be used. If the 521 IPv4 network uses public IPv4 addresses, it will inject a route into 522 the IPv6 routing table pointing to its translator(s). Hence the 523 routing scalability requirement requires that an IPv6 network- 524 specific prefix again MUST be used. 526 2.3.4. Scenario 4: an IPv4 network to the IPv6 Internet 528 The considerations are the same as in scenario 3, except that 529 stateful translation only supports initiation from the IPv6 side, and 530 hence only stateless translation can be used in this scenario. 532 2.3.5. Scenario 5: an IPv6 network to an IPv4 network 534 TO BE FILLED IN 536 ________ _______ _______ ________ 537 / \ / An \ +----------+ / An \ / \ 538 | IPv4 |---| IPv4 |--|IPv4/IPv6 |--| IPv6 |---| IPv6 | 539 \Internet/ \Network/ |Translator| \Network/ \Internet/ 540 -------- ------- +----------+ ------- -------- 542 2.3.6. Scenario 6: an IPv4 network to an IPv6 network 544 The considerations are the same as in scenario 5, except that 545 stateful translation only supports initiation from the IPv6 side, and 546 hence only stateless translation can be used in this scenario. 548 2.3.7. Scenario 7: the IPv6 Internet to the IPv4 Internet 550 This scenario need not be supported. 552 ________ ________ 553 / \ +----------+ / \ 554 | IPv4 |--|IPv4/IPv6 |--| IPv6 | 555 \Internet/ |Translator| \Internet/ 556 -------- +----------+ -------- 558 2.3.8. Scenario 8: the IPv4 Internet to the IPv6 Internet 560 This scenario need not be supported. 562 3. IPv6 Address Format and Translation Algorithms 564 There are multiple mechanisms used today to algorithmically map 565 between an IPv6 address and an IPv4 address, and more may be defined 566 over time. In this section, we first present a set of requirements 567 for such mechanisms, and then evaluate a number of existing 568 mechanisms. 570 3.1. Requirements 571 1. An algorithm MUST be one-to-one and reversible. 572 2. Unless the IPv6 prefix starts with binary 000, an address format 573 MUST NOT use the 71st bit for any purpose other than indicating 574 universal/local as specified in [RFC4291], 575 3. An IPv6 address format SHOULD provide support for multiple IPv4/ 576 IPv6 translators using different routes advertised into the IPv6 577 network (and different routes advertised into the IPv4 network). 578 4. An IPv6 address format intended to be used with a stateless 579 translator SHOULD be checksum-neutral. That is, the IPv6 address 580 and its corresponding IPv4 address should result in the same 581 one's complement checksum to avoid having to parse or modify the 582 transport header. Simply relying on an administrator to choose a 583 checksum-neutral prefix is tricky and hence error-prone. An 584 algorithm that automatically compensates no matter what the 585 administrator types is less harmful that one that does not. Note 586 that checksum-neutral translation only benefits stateless 587 translators that maintain a one-to-one mapping between an IPv4 588 address and an IPv6 address, since otherwise it has to have 589 transport-specific behavior anyway. 590 5. For ease of readability and debugging, an IPv6 address format 591 that is not designed to intentionally hide the IPv4 address 592 SHOULD allow accepting and/or displaying an embedded IPv4 address 593 in dotted-decimal form. This is done today for a variety of 594 address formats (e.g., IPv4-mapped and IPv4-translatable 595 addresses as discussed below, IPv4-compatible addresses which 596 were deprecated by [RFC4291] Section 2.5.5.1, and ISATAP 597 [RFC5214] addresses). Per [RFC4291] Section 2.2, this can only 598 be done when the embedded IPv4 address appears in the low-order 599 32 bits. It is not done when an IPv4 address is embedded 600 elsewhere in the address (as in a 6to4 address). Displaying an 601 address using dotted-decimal can only be done when some other 602 portion of the IPv6 address is used to indicate displaying the 603 low-order 32 bits in dotted-decimal form. 604 6. When the IPv4 network is a private network for which the topology 605 is considered sensitive information, the algorithm SHOULD provide 606 a way to hide the details of the internal IPv4 subnetting scheme. 607 Note that there may be other mechanisms of discovering the 608 topology beyond merely inspecting addresses, so while this is not 609 sufficient in itself, it is a necessary component of any larger 610 solution. Also note that providing this capability conflicts 611 with the requirement 5. 612 7. An algorithm MAY provide the ability to hide an IPv4 address from 613 "helpful" IPv4 NATs. Consider the scenarios depicted below with 614 IPv4 NATs that attempt to be "helpful" by looking for the NAT's 615 public IPv4 address in inbound application payloads and then 616 translating it to a private IPv4 address, and similarly 617 translating a private IPv4 address to the NAT's public IPv4 618 address in outbound payloads. While this can break applications 619 since the same bytes that appear in the IPv4 address can appear 620 normally in the payload purely by coincidence, the fact remains 621 that many NATs have been observed to do this in an attempt to 622 make other protocols work. 624 In the first scenario (an IPv6 address assigned to an IPv6 host), 625 an IPv4 NAT has IPv4 public address Y, and an address translator 626 uses IPv4 address X to map to an IPv6 address assigned to the 627 IPv6 host. If the IPv6 host sends an application payload that 628 includes an IPv6 address that directly embeds X (e.g., 629 ::ffff:0:X) then this may be translated by the IPv4 NAT to 630 ::ffff:0:Y, and similarly if the IPv4 host sends an application 631 payload that includes ::ffff:0:Y then this may be translated by 632 the IPv4 NAT to ::ffff:0:X. This may or may not be desirable. 634 ________ 635 X Y / IPv4 \ 636 IPv6 ---- IPv4/IPv6 ------- "Helpful" ---| Internet |- IPv4 637 Host Translator IPv4 NAT \________/ Host 639 In the second scenario (an IPv6 address used to represent an IPv4 640 host), the IPv4 NAT has public address Y, and the IPv4 host 641 behind it has address Z. If the IPv6 host sends an application 642 payload that includes an IPv6 address that directly embeds Y 643 (e.g., ::ffff:Y) then this may be translated by the IPv4 NAT to 644 ::ffff:Z, and similarly if the IPv4 host sends an application 645 payload that includes ::ffff:Z then this may be translated by the 646 IPv4 NAT to ::ffff:Y. This may or may not be desirable. 648 ________ 649 / IPv4 \ Y Z 650 IPv6 ---- IPv4/IPv6 --| Internet |----- "Helpful" --- IPv4 651 Host Translator \________/ IPv4 NAT Host 653 As a result, protocols such as Teredo [RFC4380] and STUN 654 [RFC5389] today avoid such problems by obscuring the IPv4 address 655 using XOR. 657 Note that providing this capability conflicts with requirement 5, 658 but anything that meets requirement 6 will also meet this 659 requirement. 661 3.2. Mechanisms 663 In this section we discuss a number of mechanisms for algorithmic 664 mapping. [EDITOR'S NOTE: currently the subsections are ordered from 665 most specific to most general. Would the opposite order be more or 666 less readable?] 668 3.2.1. IPv4-Mapped IPv6 Addresses 670 IPv4-mapped IPv6 addresses are defined in [RFC4291] Section 2.5.5.2 671 as IPv6 addresses used to represent IPv4 hosts, using the format 672 ::ffff:a.b.c.d, where a.b.c.d is the corresponding IPv4 address. 673 IPv4-mapped IPv6 addresses are used both on the wire ([RFC2765]) when 674 translation is done in the network, as well as within hosts (e.g., 675 [RFC3493]) when translation is done in the end system. This format 676 was designed to be checksum-neutral, and obviously uses a well-known 677 prefix. It is widely deployed in host operating systems today. 679 3.2.2. IPv4-Translatable Addresses 681 IPv4-translatable addresses (also known as IPv4-translated addresses) 682 are defined in [RFC2765] Section 2.1 as addresses assigned to IPv6 683 hosts, using the format ::ffff:0:a.b.c.d, where a.b.c.d is a 684 corresponding IPv4 address used by a translator. IPv4-translatable 685 addresses are used on the wire ([RFC2765]) when translation is done 686 in the network. Hypothetically they could be used within hosts when 687 translation is done in the end system, but there is no specification 688 of this at present. This format was also designed to be checksum- 689 neutral, and obviously uses a well-known-prefix. It is not known to 690 be widely deployed today. 692 OPEN ISSUE: Should IPv4-translatable addresses be deprecated by this 693 document, or should it continue to be used as the well-known default 694 prefix for this purpose? For now, we assume it will continue to be 695 used as the well-known default prefix for this purpose. 697 3.2.3. Zero-Pad And Embed 699 In this mechanism, the IPv4 address is placed in the last 32-bits, 700 after a 96-bit configured prefix. That is, a well-known or network- 701 specific prefix is zero-padded to 96 bits. This is referred to as 702 PREFIX::/96 in the deprecated [RFC2766], resulting in addresses of 703 the form PREFIX::a.b.c.d, where a.b.c.d is the corresponding IPv4 704 address. Note that typically the dotted-decimal form can only be 705 used for input and in documentation, but not display since display 706 would require the PREFIX to be known to all displaying systems to 707 indicate the use of dotted-decimal. 709 | 96 bits | 32 bits | 710 +-------------------------------------------+---------------------+ 711 | PREFIX | IPv4 address | 712 +-------------------------------------------+---------------------+ 714 This format is not checksum-neutral unless the PREFIX is checksum- 715 neutral. Hence, a well-known prefix can ensure checksum neutrality, 716 but using this format with network-specific prefixes in general 717 cannot. 719 The universal/local bit in the Modified EUI-64 occurs in the prefix 720 and MUST be set to zero unless the IPv4 address is known to be global 721 (but can be set to zero even if it is known to be global). 723 Note that IPv4-mapped and IPv4-translatable addresses are a special 724 case of this mechanism, where the PREFIX is well-known. 726 3.2.4. Compensation-Pad And Embed 728 This potential mechanism is the same as Zero-Pad And Embed 729 (Section 3.2.3), except that it provides checksum neutrality and 730 hence benefits stateless IPv4/IPv6 translators. A configured well- 731 known or network-specific PREFIX::/80 is followed by 16 bits that 732 result in the first 96 bits being checksum-neutral. 734 | 80 bits | 16 | 32 bits | 735 +--------------------------------------+----+---------------------+ 736 | PREFIX |comp| IPv4 address | 737 +--------------------------------------+----+---------------------+ 739 The universal/local bit in the Modified EUI-64 occurs in the prefix 740 and MUST be set to zero unless the IPv4 address is known to be global 741 (but can be set to zero even if it is known to be global). 743 3.2.5. Embed And Zero-Pad 745 In this mechanism (often referred to as "IVI"), the IPv4 address is 746 embedded immediately after a routable prefix, and then zero-padded at 747 the end. 749 | n bits | 32 bits | 96-n bits | 750 +--------------------------+---------------------+----------------+ 751 | PREFIX | IPv4 address | Zero | 752 +--------------------------+---------------------+----------------+ 754 [EDITOR'S NOTE: draft-baker-behave-v4v6-framework disallowed PREFIX 755 being 64-95 bits long, without explanation. IPv6 addresses used to 756 represent IPv4 hosts should be fine to use prefixes of other lengths. 757 Hence suggested clarifying text below. For IPv6 addresses assigned 758 to IPv6 hosts, kept the restriction though I do not understand why 759 this is needed and hence still consider this an OPEN ISSUE.] 761 The IPv4 address is intended to straddle the boundary between the 762 prefix used in routable tables and the bits in the host portion. For 763 IPv6 addresses assigned to IPv6 hosts, this would require a PREFIX of 764 length 32..63 bits. For IPv6 addresses used to represent IPv4 hosts, 765 any PREFIX length is sufficient. 767 However, if the PREFIX is a network-specific prefix, rather than a 768 well-known prefix, this mechanism requires the prefix to be less than 769 38 bits (so that the IPv4 address would end prior to the universal/ 770 local bit), or at least 71 bits (so that the IPv4 address would begin 771 after the universal/local bit). 773 Note that Zero-Pad and Embed can be considered to be a special case 774 of this mechanism, where the PREFIX is 96 bits and the SUFFIX is 0 775 bits. 777 3.2.6. Preconfigured Mapping Table 779 In this, the most general, mechanism, an IPv4/IPv6 address translator 780 is preconfigured with a mapping table including all legal pairs. Any 781 IPv6 and IPv4 addresses can be used. This mechanism is not checksum- 782 neutral. Since the IPv4 address is not embedded in any way, it need 783 not reveal any details of the IPv4 topology, and minimizes issues 784 with "helpful" IPv4 NATs. 786 3.3. Scenario-Specific Discussion and Recommendations 788 In this section we discuss four topologies in which IPv4/IPv6 789 translation is interesting. In each topology, initiating 790 communication can be attempted from either the IPv6 side or the IPv4 791 side. 793 3.3.1. Scenario 1: an IPv6 network to the IPv4 Internet 795 Since the IPv4 network is the Internet, there is negligible value in 796 trying to hide the topology details of the IPv4 network and hence 797 requirement 6 does not apply. The other requirements all apply 798 normally. 800 TO BE FILLED IN 802 3.3.2. Scenario 2: the IPv4 Internet to an IPv6 network 804 The considerations are the same as in scenario 1, except as follows. 806 TO BE FILLED IN 808 3.3.3. Scenario 3: the IPv6 Internet to an IPv4 network 810 In this scenario, only stateful translation can be used and hence 811 requirement 4 (checksum-neutrality) does not apply. The other 812 requirements all apply normally. 814 TO BE FILLED IN 816 3.3.4. Scenario 4: an IPv4 network to the IPv6 Internet 818 The considerations are the same as in scenario 3, except as follows. 820 TO BE FILLED IN 822 3.3.5. Scenario 5: an IPv6 network to an IPv4 network 824 Typically the IPv4 network and the IPv6 network are managed by the 825 same organization in this scenario, and hence it is not necessary to 826 hide the topology details of the IPv4 network and requirement 6 does 827 not apply in this case. The other requirements all apply normally. 829 TO BE FILLED IN 831 3.3.6. Scenario 6: an IPv4 network to an IPv6 network 833 The considerations are the same as in scenario 5, except as follows. 835 TO BE FILLED IN 837 3.3.7. Scenario 7: the IPv6 Internet to the IPv4 Internet 839 This scenario need not be supported. 841 3.3.8. Scenario 8: the IPv4 Internet to the IPv6 Internet 843 This scenario need not be supported. 845 4. Security Considerations 847 The prefix and format need to be the same among multiple devices in 848 the same network (e.g., hosts that need to prefer native over 849 translated addresses, DNS gateways, and IPv4/IPv6 translators). As 850 such, the means by which they are learned/configured must be secure. 851 Specifying a default prefix and/or format in implementations provides 852 one way to configure them securely. Any alternative means of 853 configuration is responsible for specifying how to do so securely. 855 5. IANA Considerations 857 A future version of this memo will request an IPv6 prefix assignment 858 as a Well-Known Mapped Prefix, that is used to represent IPv4 hosts, 859 and which must start with binary 000. 861 [EDITOR'S NOTE: 0/8 is reserved by the IETF (and not allocated by 862 IANA), so all that is needed is to specify the prefix herein since it 863 is an allocation from IETF not from IANA.] 865 OPEN ISSUE: The prefix length of this block has not yet been 866 determined. Some possibilities are /16, /32, /48 or /96. 868 6. Acknowledgements 870 Many people in the Behave WG have contributed to the discussion that 871 led to this document, including Andrew Sullivan, Andrew Yourtchenko, 872 Brian Carpenter, Congxiao Bao, Dan Wing, Ed Jankiewicz, Fred Baker, 873 Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Keith Moore, 874 Kevin Yin, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret 875 Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis- 876 Courmont, Remi Despres, William Waites and Xing Li. 878 7. Contributors 880 The following individuals co-authored drafts from which text has been 881 incorporated, and are listed in alphabetical order. 883 Dave Thaler 884 Microsoft Corporation 885 One Microsoft Way 886 Redmond, WA 98052 887 USA 889 Phone: +1 425 703 8835 890 Email: dthaler@microsoft.com 892 Congxiao Bao 893 CERNET Center/Tsinghua University 894 Room 225, Main Building, Tsinghua University 895 Beijing, 100084 896 China 897 Phone: +86 62785983 898 Email: congxiao@cernet.edu.cn 900 Fred Baker 901 Cisco Systems 902 Santa Barbara, California 93117 903 USA 904 Phone: +1-408-526-4257 905 Fax: +1-413-473-2403 906 Email: fred@cisco.com 908 Hiroshi Miyata 909 Yokogawa Electric Corporation 910 2-9-32 Nakacho 911 Musashino-shi, Tokyo 180-8750 912 JAPAN 913 Email: h.miyata@jp.yokogawa.com 915 Marcelo Bagnulo 916 Universidad Carlos III de Madrid 917 Av. Universidad 30 918 Leganes, Madrid 28911 919 ESPANA 920 Email: marcelo@it.uc3m.es 922 Xing Li 923 CERNET Center/Tsinghua University 924 Room 225, Main Building, Tsinghua University 925 Beijing, 100084 926 China 927 Phone: +86 62785983 928 Email: xing@cernet.edu.cn 930 8. References 932 8.1. Normative References 934 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 935 3", BCP 9, RFC 2026, October 1996. 937 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 938 Architecture", RFC 4291, February 2006. 940 8.2. Informative References 942 [I-D.bagnulo-behave-dns64] 943 Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and 944 M. Endo, "DNS64: DNS extensions for Network Address 945 Translation from IPv6 Clients to IPv4 Servers", 946 draft-bagnulo-behave-dns64-02 (work in progress), 947 March 2009. 949 [I-D.baker-behave-v4v6-framework] 950 Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 951 Translation", draft-baker-behave-v4v6-framework-02 (work 952 in progress), February 2009. 954 [I-D.wing-behave-nat64-referrals] 955 Wing, D., "Referrals Across a NAT64", 956 draft-wing-behave-nat64-referrals-00 (work in progress), 957 March 2009. 959 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 960 (SIIT)", RFC 2765, February 2000. 962 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 963 Translation - Protocol Translation (NAT-PT)", RFC 2766, 964 February 2000. 966 [RFC3484] Draves, R., "Default Address Selection for Internet 967 Protocol version 6 (IPv6)", RFC 3484, February 2003. 969 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 970 Stevens, "Basic Socket Interface Extensions for IPv6", 971 RFC 3493, February 2003. 973 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 974 Network Address Translations (NATs)", RFC 4380, 975 February 2006. 977 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 978 Address Autoconfiguration", RFC 4862, September 2007. 980 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 981 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 982 March 2008. 984 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 985 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 986 October 2008. 988 Authors' Addresses 990 Christian Huitema 991 Microsoft Corporation 992 One Microsoft Way 993 Redmond, WA 98052-6399 994 U.S.A. 996 Email: huitema@microsoft.com 998 Congxiao Bao 999 CERNET Center/Tsinghua University 1000 Room 225, Main Building, Tsinghua University 1001 Beijing, 100084 1002 China 1004 Phone: +86 10-62785983 1005 Email: congxiao@cernet.edu.cn 1007 Marcelo Bagnulo 1008 UC3M 1009 Av. Universidad 30 1010 Leganes, Madrid 28911 1011 Spain 1013 Phone: +34-91-6249500 1014 Fax: 1015 Email: marcelo@it.uc3m.es 1016 URI: http://www.it.uc3m.es/marcelo 1017 Mohamed Boucadair 1018 France Telecom 1019 3, Av Francois Chateaux 1020 Rennes 350000 1021 France 1023 Email: mohamed.boucadair@orange-ftgroup.com 1025 Xing Li 1026 CERNET Center/Tsinghua University 1027 Room 225, Main Building, Tsinghua University 1028 Beijing, 100084 1029 China 1031 Phone: +86 10-62785983 1032 Email: xing@cernet.edu.cn