idnits 2.17.1 draft-van-beijnum-v6ops-mnat-pt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 972. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 17 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 11 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 220: '... this mechanism MAY still be used. H...' RFC 2119 keyword, line 221: '... this specification, DNS ALGs MUST include an EDNS0 option [RFC2671]...' RFC 2119 keyword, line 225: '... with IPv4 hosts SHOULD look up the A ...' RFC 2119 keyword, line 231: '... a MNAT-PT translator SHOULD behave in...' RFC 2119 keyword, line 277: '... SHOULD avoid storing addresses lear...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2008) is 5916 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) ** Downref: Normative reference to an Informational RFC: RFC 2694 ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Downref: Normative reference to an Informational RFC: RFC 4966 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-09 == Outdated reference: A later version (-03) exists of draft-woodyatt-ald-02 == Outdated reference: A later version (-01) exists of draft-durand-v6ops-natv4v6v4-00 == Outdated reference: A later version (-01) exists of draft-bagnulo-v6ops-6man-nat64-pb-statement-00 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. van Beijnum 3 Internet-Draft IMDEA Networks 4 Expires: August 15, 2008 B. Carpenter 5 Univ. of Auckland 6 February 12, 2008 8 Modified Network Address Translation - Protocol Translation 9 draft-van-beijnum-v6ops-mnat-pt-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 15, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 A smooth transition from IPv4 to IPv6 requires that either all hosts 43 are upgraded to dual stack before the first hosts can become IPv6- 44 only, or that there be some mechanism for IPv6-only hosts to talk to 45 IPv4-only hosts. Expecting the former within a reasonable timeframe 46 isn't realistic, based on current adoption of dual stack combined 47 with the latest projections for the IPv4 depletion that point to a 48 date early in the next decade. And the IETF has recently deprecated 49 the main mechanism that allows the latter: NAT-PT. 51 This document proposes a modified form of NAT-PT that addresses the 52 reasons why the mechanism was deprecated and currently understood 53 requirements. This should allow future deployment of the modified 54 NAT-PT as an IPv4-to-IPv6 transition mechanism, giving operators the 55 option of running their networks largely IPv6-only. 57 1. Introduction 59 1.1. Background 61 The original NAT-PT mechanism outlined in [RFC2766] couples three 62 underlying techniques to arrive at a comprehensive solution that 63 allows IPv6-only hosts to initiate connections or associations 64 towards IPv4-only hosts: 66 1. Stateless IP and ICMP Translation [RFC2765] 68 2. Network Address / Port Translation 70 3. A DNS Application Layer Gateway [RFC2694] 72 Basically, when an IPv6 host wants to connect to a service, it looks 73 up the associated host/service name in the DNS. If no AAAA records 74 are available for the name in question, the DNS ALG synthesizes an 75 AAAA record based on the A record for the host/service and a prefix 76 that's routed to a translation device. The IPv6 host initiates 77 communication towards the resulting IPv6 address. The associated 78 packets end up at the translator, which recovers the original IPv4 79 destination address, translates between IPv6 and IPv4, performs IPv4 80 NAT and sends the resulting packet to the IPv4 destination. Return 81 packets are translated back and sent to the IPv6 host. 83 1.2. Summary of Requirements 85 [RFC4966] explains why NAT-PT as originally defined is problematic. 86 The main objections boil down to hosts being exposed to an unexpected 87 environment, issues with referrals in the absence of relevant 88 Application Layer Gateways, generation of synthetic DNS responses 89 that may be harmful if not properly contained and constraints on 90 network topology. Another problem with having a DNS ALG in a central 91 location in the network is that this makes it hard to make synthetic 92 AAAA records only flow towards IPv6-only hosts and not dual stack 93 hosts. A major requirement on any modified form of NAT-PT is to 94 mitigate or eliminate as many of the issues in [RFC4966] as possible. 96 The underlying requirement can be summarized as providing a 97 scaleable, reliable and secure mechanism by which IPv4-only hosts may 98 exchange packets with IPv6-only hosts. Aspects of this include: 100 1. IPv4-only hosts are presumed to be legacy systems to which no 101 modifications whatever can be made. Even if IPv6 is supported on 102 their network, they have no way to understand or create IPv6 103 packets, even if certain applications understand IPv6 addresses. 105 2. IPv4-only hosts may be on legacy networks whose routers have no 106 support for IPv6. 108 3. For the purposes of this document, the IPv6 host has no direct 109 support for IPv4, i.e. it is not a dual-stack host. (If it was a 110 dual-stack host, it could have direct or tunneled and possibly 111 NATted IPv4 connectivity to the IPv4-only host.) 113 4. From the IPv4 host's point of view, nothing should behave worse 114 than in the case of an IPv4-to-IPv4 translation. 116 5. From the IPv6-only host's point of view, we can require some 117 special code in the IP stack, but no knowledge of IPv4 should 118 generally be required in the transport layer or above. 120 6. IPv6 routing should not be affected in any way, and there should 121 be no risk of importing "entropy" from the IPv4 routing tables 122 into IPv6. 124 7. At the point where the IPv6 and IPv4 addressing domains meet, it 125 is necessary to share limited IPv4 addresses among multiple IPv6 126 hosts in some way, while allowing the IPv4 host to assume that 127 {IPv4 address, port number} 2tuples are unique. 129 8. It should be possible to locate the translation device at an 130 arbitrary point in the network (i.e. not at fixed points such as 131 a site exit), so that there is full operational flexibility. 133 9. Any configuration need for an IPv6 host to make use of the 134 mechanism should be possible centrally, e.g. a DHCP option. 136 A full problem statement and requirements analysis is developed in 137 [I-D.bagnulo-v6ops-6man-nat64-pb-statement]. 139 1.3. Outline of Solution 141 As noted in the requirements, we cannot ask for any change whatever 142 in legacy IPv4 hosts. However, it is considered reasonable to 143 require enhancements to IPv6-only stacks, which are much rarer at the 144 time of writing than dual stacks, and certainly are not a legacy. 145 Based on this consideration, this document proposes to make the IPv6 146 side aware of the translation in order to avoid the majority of the 147 problems associated with the original NAT-PT. The objective is to 148 allow the IPv6 stack at the host to be aware of the presence of the 149 translator, of the addresses involved in the translation, and of 150 other information known by the translator that may be of value to the 151 IPv6 host. 153 There may be cases where a "legacy" IPv6 stack is in used that knows 154 nothing of this solution. We do propose a mechanism for this, which 155 can best be described as a DNS trick (moving the creation of 156 synthetic AAAA records much closer to the IPv6 host). 158 Although this document goes into some detail, it's intended as a 159 discussion document; as such, not every aspect is completely worked 160 out. This version incorporates text and ideas from 161 [I-D.carpenter-shanti]. 163 In some discussions, a distinction is made between Network Address 164 Translation (NAT) which only translates addresses, and Network 165 Address/Port Translation (NAPT) which translates both addresses and 166 TCP/UDP port numbers. No such distinction is made here; "NAT" is 167 used to refer to both types of translation. In fact, due to the 168 requirement for multiple IPv6 hosts to share a limited number of IPv4 169 addresses, port multiplexing is inevitable. 171 The requirement above that behaviour be no worse than in IPv4-IPv4 172 NAT is significant. It means that the required behaviour is 173 isomorphic to an IPv6-to-IPv4 translation followed by IPv4-IPv4 NAT, 174 even if the two translations are implemented in a single stage. 176 We use the abbreviation "MNAT-PT" to refer to the modified NAT-PT 177 mechanism described in this document. 179 2. IPv6-to-IPv4 operation 181 In the following diagram, 183 A(x) is an IPv6 address of the IPv6 host X. 185 P(x) is the port number in use at X. 187 A(t) is a synthesized IPv6 address for the translator T. 189 P(y) is the port number in use at the IPv4 host Y. 191 a(t) is an IPv4 address of the translator. 193 P(tx) is the translated port number presented to the IPv4 host. 195 a(y) is the IPv4 address of Y. 197 v6 host MNAT-PT v4 host 198 X T Y 199 _______ A(x) A(t) _______________ a(t) a(y) _______ 200 | | V6|P(x) P(y)| V6| | | V4|P(tx) P(y)| V4| | 201 | | | | | S | N | | | | | 202 | U | S | | S | I | A | S | | S | U | 203 | L | T |------------| T | I | T | T |-----------| T | L | 204 | P | A | | A | T | | A | | A | P | 205 | | C | | C | | | C | | C | | 206 | | K | | K | | | K | | K | | 207 |___|___| |___|___|___|___| |___|___| 209 If there's another IPv4 NAT with address a(n) on the IPv4 path, it 210 won't know anything is special, and a(y) will be represented by a(n). 211 X, Y and T won't know that the NAT is there. X and T will not know 212 if Y has a private [RFC1918] address or if additional port 213 translation takes place. 215 2.1. Use of A records and addressing the translator 217 In the original NAT-PT design a DNS ALG would create synthetic AAAA 218 DNS records for FQDNs that only have A records. This is the source 219 of the worst problems described in [RFC4966]. Although discouraged, 220 this mechanism MAY still be used. However, in order to comply with 221 this specification, DNS ALGs MUST include an EDNS0 option [RFC2671] 222 in any replies that contain synthetic AAAA records to make these 223 records recognizable as synthetic so that they can be filtered by 224 hosts that have no need for them and DNS servers. IPv6 hosts that 225 want to communicate with IPv4 hosts SHOULD look up the A records 226 themselves, obtaining a(y), and create a synthetic IPv6 destination 227 address by concatenating a particular /96 prefix and the bits of 228 a(y). The resulting IPv6 address A(t) will cause the packet to be 229 delivered to the relevant MNAT-PT. 231 Thus the IPv6 hosts "behind" a MNAT-PT translator SHOULD behave in 232 one of two ways: 234 1. The IPv6 host has a combination of resolver, API and stack that 235 in effect maps A records into AAAA records expanded with that 236 /96. When resolving an FQDN via getaddrinfo(), the effect is to 237 return A(t) instead of a(y). The upper layer protocol will see 238 only an IPv6 address. 240 2. Alternatively, the IPv6 host users IPv4 addresses in their native 241 or IPv4-mapped IPv6 form and then add the /96 bits as a packet is 242 about to be generated for transmission on the wire. 244 Both mechanisms will work in a network with a mixture of MNAT-PT and 245 dual-stack hosts. The former would see A(t), and the latter would 246 see a(y), using the same, unmodified, DNS server. 248 The two ways to do MNAT-PT have different tradeoffs. In both cases, 249 it's suboptimal to have MNAT-PT activated on dual stack hosts, 250 because this prevents native IPv4 operation. In addition to that, in 251 the former case going from IPv6-only with MNAT-PT to dual stack 252 without MNAT-PT (when native IPv6 connectivity becomes available) 253 doesn't cause interruptions in ongoing communication. In the latter 254 case, the transition from IPv6-only with MNAT-PT to dual stack 255 without MNAT-PT means all communication towards IPv4 destinations 256 will immediately change from using MNAT-PT to native IPv4, thereby 257 breaking ongoing sessions. 259 This document does not specify exactly how MNAT-PT should be 260 implemented; there is a range of design options, such as in the 261 resolver, in the socket API, or even in the stack itself, as detailed 262 below. This list of options is not exhaustive; any implementation 263 that exhibits similar externally visible behaviour is acceptable. 265 The most basic way to implement this specification is almost 266 identical to the original NAT-PT, except that the DNS ALG 267 functionality is moved as close to the hosts that make use of the 268 translator as possible. The DNS ALG can be integrated in a host's 269 resolver library or be provided by an external server topologically 270 close to the host. This means that the IPv6 stack on a host sees 271 synthetic AAAA records and treats the addresses in those AAAA records 272 as regular IPv6 addresses. For many applications and protocols, this 273 can work well, but it has the downside that applications may see NAT 274 applied to what they percieve as IPv6 communication. As such, this 275 way of implementing MNAT-PT is only recommended for applications and 276 protocols that have no problem working through NAT. Applications 277 SHOULD avoid storing addresses learned through synthetic AAAA records 278 in accordance with the zero (or one) TTL value in those records. 280 Alternatively, an implementation may forego the use of synthetic AAAA 281 records, and present IPv4 addresses in A records to applications as 282 IPv4-mapped IPv6 addresses in the ::ffff:0:0/96 prefix. When the 283 host in question only has IPv6 connectivity and it is configured with 284 a /96 prefix of a translator, it will, for the purposes of [RFC3484] 285 address selection, treat destination addresses of this type as IPv6 286 addresses so the host's IPv6 address(es) can be used as a source 287 address. When generating IP packets, the stack replaces the ::ffff: 288 0:0/96 prefix in the destination address with the /96 prefix for the 289 translator and sends the packets to the translator. Applications may 290 recognize the IPv4-mapped IPv6 addresses and adjust their behaviour 291 to the apparent use of IPv4. However, the use of an IPv6 source 292 address could lead to unexpected application behaviour in this case. 294 Finally, an implementation may choose to provide full IPv4 service to 295 applications, by not only supporting the IPv6 socket API with IPv4- 296 mapped addresses as outlined above, but by also supporting the IPv4 297 socket API. For full compatibility, a synthetic IPv4 source address 298 in [RFC1918] space is generated, indicating to applications not only 299 that the communication is going towards an IPv4 destination, but also 300 that there will be NAT, so that applications can employ NAT traversal 301 techniques. 303 Each of these approaches removes the need for a DNS-ALG that is 304 created by the original NAT-PT model, and thereby removes the 305 problems caused by a DNS-ALG. 307 In the hopefully rare case that an IPv6 address representing an IPv4 308 host needs to be configured manually, it MAY be configured as the 309 MNAT-PT translator's /96 prefix concatenated with the IPv4 address. 310 The approach where IPv4 addresses are used in their native or IPv4- 311 mapped IPv6 form is preferable and SHOULD be used if supported 312 because this way, the host is able to communicate successfully if it 313 is later served by a different MNAT-PT translator or obtains native 314 IPv4 connectivity. 316 There are three possible approaches to the /96 prefix: 318 1. Use ::ffff:0:0/96 as an anycast prefix 320 2. Use a to-be-defined prefix other than ::ffff:0:0/96 as an anycast 321 prefix 323 3. Use a prefix specific to a translator 325 The authors are of the opinion that the benefits of simplicity of the 326 first approach don't outweigh the downsides of unexpectedly seeing 327 IPv4-mapped IPv6 addresses on the wire. In order to provide 328 flexibility to operators, the third option MUST be supported using 329 the discovery/configuration mechanisms outlined later in this 330 document. The desireability of the second option is open for further 331 discussion. As such: 333 The 96-bit prefix used by a translator SHOULD be in the IPv6 global 334 unicast space (2000::/3) or unique local address space (fc00::/7). 335 Note that the status of parts of the IPv6 address space may change 336 over time; it is not appropriate to hardcode these prefixes in 337 applications or default configurations. The 96-bit prefix used by a 338 translator MUST NOT use the ::/96 or ::ffff:0:0/96 prefixes. 340 Discussion: There has been an operational preference that IPv4-mapped 341 IPv6 addresses should not appear on the wire, although this is broken 342 by SIIT ([RFC2765]), one of the underlying mechanisms of the original 343 NAT-PT. Operational difficulties have been reported with such 344 addresses escaping into the wild, and there is confusion because thay 345 are also used for automatic mapping within some dual stacks. 346 Although it requires more work, an arbitrary prefix for the 347 translator can still maintain the "checksum to zero" property. 348 However, since we assume that the MNAT-PT device will also perform 349 port mapping, checksum recalculation seems inevitable anyway. So 350 does the checksum-to-zero property matter? The SHANTI proposal 351 [I-D.carpenter-shanti] avoided this problem by actively translating 352 the IPv6 address used, at the expense of considerable complexity. 353 The current proposal is to accept that checksum recalculation in the 354 translator is inevitable (as it is in IPv4-IPv4 NAT). In this case, 355 the ::ffff:0:0/96 prefix has no particular advantage. 357 Allowing an arbitrary, or anycast, prefix to locate the MNAT-PT 358 device allows for arbitrary topology: the MNAT-PT can be on the IPv6 359 site, or in any ISP location that has both IPv4 and IPv6 360 connectivity. This allows for great flexibility in deployment 361 models. 363 For operational convenience, there must be a way for a client machine 364 to discover the locally applicable MNAT-PT /96 prefixe. This draft 365 does not fully specify this mechanism. The range of possibilities 366 include: 368 1. Default to the anycast prefix mentioned above. 370 2. Define a DHCPv6 option. 372 3. Define a DNS based convention such as mnat. prepended to the 373 local domain name. Use the /96 prefix of the corresponding AAAA 374 record. 376 4. Allow manual configuration of a DNS name as an almost last 377 resort. 379 5. Allow manual configuration as a last resort. 381 The authors intended to specify mechanisms for the second and third 382 options in a later version of this document. 384 2.2. Use of a synthetic IPv4 source address 386 Optionally, IPv6-only hosts MAY support IPv4 (and IPv4-mapped IPv6) 387 socket calls for compatibility with applications that don't support 388 native IPv6 communication and/or need to be aware of the fact that 389 communication is happening over IPv4 and/or is subject to NAT. A 390 natural way to indicate this is through the use of an IPv4 source 391 address from [RFC1918] space. 393 An IPv6-only host implementing IPv4 compatible socket calls picks one 394 of its global scope IPv6 addresses as the source address A(x) for 395 MNAT-PT. It then generates a local IPv4 address in the prefix 396 172.31.0.0/16, where the lower 16 bits are chosen such that a TCP or 397 UDP checksum computed over the IPv6 addresses that appear on the wire 398 are the same as those resulting from the synthetic IPv4 source 399 address and the IPv4 destination address. 401 This means that the value of the lower 16 bits in the synthetic IPv4 402 address are generated through the one's complement addition of the 403 16-bit words that make up the 96 bit prefix used for IPv4 404 destinations reachable through the translator and the selected IPv6 405 source address. Then, a one's complement subtraction of the value 406 44063 (decimal) is performed to adjust for the 172.31.0.0/16 prefix. 407 The result of this is that TCP and UDP checksums computed over both 408 the IPv4 and MNAT-PT IPv6 representations of packets destined for the 409 translator are the same (ignoring port numbers for the moment). UDP 410 packets MUST have a valid checksum, as required by IPv6. 412 Although adjusting checksums during translation steps is relatively 413 easy, knowing that IPv4 and IPv6 versions of the checksum are 414 identical may allow for a more flexible implementation, where it's 415 not necessary to keep track of whether a packet was or will be 416 translated when a checksum is computed. 418 The resulting synthetic IPv4 address is internally used as the source 419 address in all IPv4 processing. Note that MNAT-PT translators keep 420 track of IPv6 hosts by their IPv6 address: the synthetic IPv4 source 421 address is unknown to translators and is only used for compatibility 422 with IPv4-aware applications. 424 2.3. Signaling from the translator to the IPv6 host 426 An option to be considered, derived from [I-D.carpenter-shanti], is 427 for the MNAT-PT to signal to the IPv6 host to inform it of the port 428 number P(tx) and outbound IPv4 address a(t) actually in use. The 429 IPv6 host is aware of its own IPv6 address and of the port number it 430 is using, but these are meaningless on the IPv4 side. With the added 431 signaling, it would know the 4tuple {a(y), a(t), P(y), P(tx)} in use 432 on the IPv4 side. In this case, the IPv6 host could in principle 433 compute a transport checksum that will be valid after address and 434 port translation, and send this instead of a valid IPv6 checksum. 436 Such signaling, to be useful to the upper layer protocols in the IPv6 437 host, would need to occur before the upper layer protocol actually 438 sent its first packet; in effect the IPv6 stack would have to send a 439 "request to send" message to the MNAT-PT, in order for the MNAT-PT to 440 create the necessary translation state and respond with the {a(t), 441 P(tx)} values. 443 Tentatively, such a mechanism could use either a dedicated signaling 444 channel such as an SSL connection between the IPv6 host and the 445 MNAT-PT, or in-band signaling using a shim header modeled on SHIM6 446 [I-D.ietf-shim6-proto]. The type of information to be signaled might 447 include discovery of a(t) and P(tx), opening an external port, etc. 449 It is open to discussion whether this is worthwhile or whether a more 450 general approach such as [I-D.woodyatt-ald] might not be better. 451 This question is not discussed further in this draft. 453 2.4. Operation 455 Packets towards to-be-translated IPv4 destinations are transmitted 456 over the network as usual, but are delivered to the IPv6 interface of 457 the MNAT-PT translation device. The translation device performs SIIT 458 translation and IPv4 NAT. The possible artificial IPv4 source 459 address is ignored during these steps, since it is not required by 460 either step except as a means to keep track of which sessions on the 461 public IPv4 side map to which sessions on the IPv6 side. However, 462 since different IPv6 hosts served by the same translation device may 463 have selected the same artificial IPv4 address, (de)multiplexing 464 based on this value won't work. So the SIIT and NAT stages must be 465 integrated such that the NAT associates sessions on the public IPv4 466 side directly with the IPv6 side without a private IPv4 intermediate. 467 Port translation, port mapping, and transport checksum recalculation 468 will be handled by the NAT component exactly as in a normal IPv4-IPv4 469 NAT. 471 3. IPv4-to-IPv6 operation 473 In order for IPv6-only hosts to receive unsolicited incoming packets 474 (e.g. incoming TCP sessions and UDP packets that aren't replies to 475 UDP packets sent earlier), unsolicited packets towards a certain 476 address / port combination must be translated to a corresponding IPv6 477 address by a MNAT-PT translators. Much of this resembles what a 478 normal NAT must do to handle unsolicited incoming packets destined 479 for servers using private [RFC1918] address space. If the NAT 480 function of the MNAT-PT (see above diagram) opens port P(tx) at IPv4 481 address a(t) for unsolicited packets, it must be configured to map 482 that port to a port P(x) at IPv6 address A(x). When a flow starts, 483 state is kept to be able to translate return packets from IPv6 to 484 IPv4. 486 The issues associated with configuring port mappings and creating, 487 maintaining and expiring this state are exactly those encountered by 488 normal NAT, but those can be avoided using the mechanism described 489 below. 491 Any organisation needing to provide MNAT-PT translation for 492 unsolicited incoming packets will need to allocate one or more IPv4 493 addresses under its control to this purpose, and arrange for the 494 corresponding mappings to be configured in MNAT-PT devices. It is 495 most likely that this will be done by sites running IPv6-only servers 496 and wishing to serve IPv4-only clients, or by the ISP serving a site. 497 A site running dual-stack servers has no need to run MNAT-PT, and an 498 IPv4-only site or ISP is unable to do so. 500 In most scenarios, the IPv4 address(es) assigned to an MNAT-PT device 501 will be globally routable public addresses. However, there is no 502 technical reason that they should not be chosen from private[RFC1918] 503 address space, if a deployment scenario requires it. 505 The IPv4 source address is encoded in bits 96 - 127 and the IPv4 506 destination port number in bits 80 - 95 of the IPv6 address for 507 thusly translated packets so that applications configured with the 508 knowledge that they are receiving incoming sessions from IPv4 hosts 509 may recover the original IPv4 source address and destination port 510 number. The source port number MUST NOT be changed during the 511 translation process. This makes the translation process stateless. 513 If desired, the owner of an address block that is used exclusively 514 for IPv4-to-IPv6 translation can publish mappings from IPv4 address/ 515 port combinations to IPv6 address/port combinations in the reverse 516 DNS tree as follows: 518 _service._proto.31.2.0.192.in-addr.arpa IN SRV pri weight v6port FQDN 520 Where proto is an upper layer protocol (TCP or UDP), pri is a 521 priority, weight a weight, v6port is a port number used by the IPv6 522 host and FQDN a fully qualified domain name used by the IPv6 host in 523 accordance with [RFC2782]. service, however, is not a service name, 524 but the decimal form of the destination port number in the IPv4 525 packet. 527 The address block is then advertised in IPv4 BGP with the well-known 528 community TRANSLATEV6 attached [RFC1997]. This allows operators of 529 translators that receive the advertisement through BGP to route 530 packets towards the address block in question to their own 531 translator, which recovers the mappings from the DNS and performs the 532 translation locally. Because the translator inserts its own /96 533 prefix in the IPv6 source address, packets flow back and forth 534 between the IPv4 and IPv6 hosts through the same translator. 536 It is of course compatible with the above that organisations obtain 537 address blocks for the specific purpose of making IPv6 services 538 available over IPv4 and anycasting these address blocks in addition 539 to setting the TRANSLATEV6 community. Because each TCP and UDP port 540 number can be mapped individually, a relatively small IPv4 address 541 block can accommodate a large number of IPv6 services, as long as 542 these services don't depend on well-known port numbers. 544 MNAT-PT translators MUST encode the IPv4 destiantion port number and 545 source address in the lower 48 bits of the IPv6 source address in 546 translated packets. This means that translators must have a /80 547 range of IPv6 addresses available to perform this type of 548 translation. Encoding of the IPv4 source address in the IPv6 source 549 address allows conformant applications or operating systems to 550 recover the original IPv4 destination port and source address of the 551 correspondent. However, this only works if the incoming packets are 552 indeed translated IPv4 packets. If this functionality is desired, 553 administrators must take care to keep incoming translated IPv4 554 sessions and normal IPv6 sessions apart by making these arrive at 555 different IPv6 addresses. In other words, if it's desired that 556 applications can tell when incoming sessions originate from IPv4 557 hosts, a server behind an MNAT-PT will need at least one IPv6 address 558 in its native IPv6 server role (announced as a public AAAA record), 559 and at least one other IPv6 address in its MNAT-PT serving role (not 560 announced as an AAAA record, but announced in SRV records in the 561 reverse IPv4 DNS). 563 Note that for this type of translation, there is no requirement that 564 checksums calculated over the IPv4 and IPv6 pseudo headers are the 565 same: translators must adjust checksums. 567 An alternative to this was part of the SHANTI proposal 568 [I-D.carpenter-shanti] in which the external address and port numbers 569 would be signaled to the IPv6 host stack. In this case checksums and 570 any other upper layer uses of the IPv4 information could be handled 571 in the IPv6 host alone. As noted above, it is an open question 572 whether this added complexity is worthwhile. 574 4. Examples 576 The anycast range for IPv6-to-IPv4 translation is assumed to be 577 1000::/96 in these examples, and the IPv4 address of the translator 578 is 10.0.0.96. (10.0.0.96 and 172.18.64.80 are used as an example 579 public IPv4 addresses, not as private addresses here.) 581 4.1. IPv6-to-IPv4 583 IPv6 host pc1.beispiel.de 2001:db8:31::dead:beef wants to communicate 584 with IPv4 host www.example.com, which holds address 192.0.2.58. 585 pc1.beispiel.de doesn't use a synthetic IPv4 source address. 587 1. pc1.beispiel.de looks up AAAA records for www.example.com with no 588 results 590 2. pc1.beispiel.de looks up A records for www.example.com: 591 192.0.2.58 593 3. pc1.beispiel.de initiates a TCP session from 2001:db8:31::dead: 594 beef port 1025 to 1000::192.0.2.58 port 80 596 4. the translator sets up a translation mapping from { [2001:db8: 597 31::dead:beef]:1025 [1000::192.0.2.58]:80 } to { [10.0.0.96]: 598 49152 [192.0.2.58]:80 } 600 5. the translator translates packets back and forth until the 601 session is no longer used and the mapping is garbage collected 603 4.2. IPv6-to-IPv4 with synthetic IPv4 source address 605 IPv6 host pc2.beispiel.de 2001:db8:31::cafe wants to communicate with 606 IPv4 host www.example.com, which holds address 192.0.2.58. 607 pc2.beispiel.de uses a synthetic IPv4 source address. 609 1. pc2.beispiel.de does a one's complement addition of the values 610 1000, 0000, 0000, 0000, 0000, 0000 (the translator anycast 611 address), 2001, 0db8, 0031, 0000, 0000, 0000, 0000, cafe (its 612 source address) which results in 08e9 614 2. pc2.beispiel.de does a one's complement subtraction of ac1f 615 (172.31) from 08e9 = a336 (163.54) 617 3. pc2.beispiel.de configures a virtual network interface with IPv4 618 address 172.31.163.54 620 4. pc2.beispiel.de looks up AAAA records for www.example.com with no 621 results 623 5. pc2.beispiel.de looks up A records for www.example.com: 624 192.0.2.58 626 6. pc2.beispiel.de initiates a TCP session from 2001:db8:31::cafe 627 port 1025 to 1000::192.0.2.58 port 80 629 7. the translator sets up a translation mapping from { [2001:db8: 630 31::cafe]:1025 [1000::192.0.2.58]:80 } to { 10.0.0.96:49153 631 192.0.2.58:80 } 633 8. the translator translates packets back and forth until the 634 session is no longer used and the mapping is garbage collected 636 4.3. IPv4-to-IPv6 638 IPv4 host mac1.example.com holding address 192.0.2.253 wants to 639 communicate over the FTP protocol with IPv6 host pc1.beispiel.de. 640 The port number available for this service is 32767. In order to 641 accommodate incoming sessions, pc1.beispiel.de has set up the 642 following entries in the DNS: 644 pc1.beispiel.de. IN A 172.18.64.80 646 _32767._tcp.80.64.18.172.in-addr.arpa IN SRV 21 pc1.ddns.beispiel.de. 648 pc1.ddns.beispiel.de. IN AAAA 2001:db8:31::dead:beef 650 The closest MNAT-PT translator uses prefix 2001:db8:ffff::/96 for 651 translations from IPv4 to IPv6. 653 1. mac1.example.com wants to connect to pc1.beispiel.de on port 654 32767 656 2. mac1.example.com looks up A records for pc1.beispiel.de in the 657 DNS: 172.18.64.80 659 3. mac1.example.com sets up a TCP session from 192.0.2.253:1025 to 660 172.18.64.80:32767 662 4. the packet for 172.18.64.80 is routed towards a MNAT-PT 663 translator 665 5. the translator transfers 172.18.64.80:32767 into 666 _32767._tcp.80.64.18.172.in-addr.arpa 668 6. the translator looks up SRV records: 0 0 21 pc1.ddns.beispiel.de 669 7. the translator looks up AAAA records: 2001:db8:31::dead:beef 671 8. the translator sets up a mapping from { 192.0.2.253:1025 672 172.18.64.80:32767 } to { [2001:db8:ffff::192.0.2.253]:1025 673 [2001:db8:31::dead:beef]:21 } 675 9. the translator translates packets back and forth until the 676 session is no longer used and the mapping is garbage collected 678 5. Advantages and disadvantages 680 5.1. Disadvantages 682 MNAT-PT operation is possible without necessarily requiring changes 683 to the TCP/IP stack or applications, but in that case, applications 684 may operate under the assumption that they're talking to IPv6 685 correspondents, while in fact they are communicating with IPv4 686 correspondents. This may result in a mismatch in IP protocol version 687 for protocols that embed IP addresses. 689 5.2. Advantages 691 There are several advantages. An important one is that NAT issues 692 only come up when the host is communicating towards IPv4 addresses. 693 As such, it's trivial for applications to limit NAT workaround code 694 to sessions towards IPv4 destinations and assume global 695 addressability for IPv6 destinations. Since there is no DNS ALG, and 696 if there is one, it inserts the EDNS0 "poison pill" in any records 697 that contain synthetic AAAA records, there are no issues with 698 possible leakage of synthetic AAAA records as soon as the EDNS0 699 option is widely supported and/or DNS ALGs are no longer used. Both 700 IPv4 applications that use IPv4 socket calls and IPv6 applications 701 that use IPv6 socket calls with IPv4-mapped IPv6 addresses can work 702 over MNAT-PT. Alternatively, light-weight implementations may omit 703 all IPv4 code, except perhaps the ability to perform A record 704 lookups. 706 5.3. Advantages over providing real NATed IPv4 connectivity 708 An obvious way to enjoy many of the same benefits would be to build a 709 network that supports both IPv6 and IPv4 with NATed connectivity. 710 However, this means that there must be an IPv4 network infrastructure 711 in place in the form of IPv4 routers and IPv4 address provisioning 712 (DHCP). Today, this is easy to do in smaller installations if there 713 is a single public IPv4 address available. However, in larger 714 networks the planning of private IPv4 addressing can become 715 cumbersome, and when IPv4 addresses are scarce, it may be unavoidable 716 to implement multiple levels of NAT. Multiple levels of NAT at the 717 very least impose the limits of the most restrictive NAT, and also 718 make hole punching that is used to be able to receive incoming 719 connections much harder as a single set of port numbers must be 720 shared by a larger number of hosts. NAT traversal technologies may 721 or may not support multiple layers of NAT. 723 With MNAT-PT, it's only necessary to provision IPv6 connectivity and 724 addressing, which is easier to plan for because unlike IPv4, a 725 standard /64 IPv6 subnet supports arbitrary numbers of hosts. The 726 translation device that performs NAT and the hosts making use of the 727 MNAT-PT service can be located with few topological constraints, so 728 multiple layers of NAT are much easier to avoid. Additionally, the 729 only state that must be kept by the translator is that inherent to 730 NAT operation, there is no need to maintain IPv4 addressing, allowing 731 for easier scalability of the solution. 733 6. Evaluation of RFC4966 concerns 735 This section provides an overview of the issues raised in [RFC4966] 736 and how they apply to the use of modified NAT-PT with modifications 737 on the IPv6 side. 739 6.1. Issues with Lack of Address Persistence 741 To-be-translated IPv4 destination addresses map to the same IPv6 742 destination address until the host selects a different /96 prefix. 743 However, if addresses are stored in their IPv4 form, this doesn't 744 lead to broken referrals. Issues with mapping persistence from the 745 IPv4 side to the IPv6 side are the same as with regular NAT and can 746 be solved in the same way: by having the application or OS set up a 747 persistent mapping that allows incoming connections. 749 6.2. DoS Attacks on Memory and Address/Port Pools 751 Denial-of-service issues are mostly the same as with regular NAT. 752 When a non-anycast translator is used, it's likely that 753 authentication through a control connection is required, allowing for 754 easy rejection of to-be-translated traffic coming from addresses that 755 don't have an active control connection. However, unless the IPv6 756 source host and the translator are prepared to set up an IPsec 757 tunnel, there is no way to reject to-be-translated traffic which 758 spoofs the source address of a host with an active control 759 connection. If the source host uses an IPv6 source address for this 760 communication that it doesn't use for other types of communication, 761 only on-path attackers or hosts on the same subnet have easy 762 knowledge of the source address in question. 764 6.3. Issues Directly Related to Use of DNS-ALG 766 Fixed definitively. 768 6.4. Impact on IPv6 Application Development 770 Applications see regular IPv4 destination addresses for to-be- 771 translated destinations so they can engage IP version specific code 772 paths as required. The presence of the [RFC1918] synthetic source 773 address makes it possible for applications to use NAT workarounds for 774 to-be-translated destinations. The extra work the application needs 775 to do here is the same as it would when running on a dual stack host. 777 Alternatively, TCP/IP stacks may forego implementing the synthetic 778 IPv4 source address and/or applications may choose to remain ignorant 779 of whether they're communicating with an IPv4 or IPv6 correspondent. 780 In those cases, address-based referrals are likely to break for IPv4 781 destinations unless the MNAT-PT translator employs an Application 782 Layer Gateway for the protocol that's used. 784 7. Acknowledgments 786 This document has benefited from ideas from Marcelo Bagnulo and Alain 787 Durand. Readers are encouraged to also review 788 [I-D.carpenter-shanti], [I-D.durand-v6ops-natv4v6v4] and 789 [I-D.bagnulo-v6ops-6man-nat64-pb-statement]. 791 8. IANA considerations 793 IANA is requested to allocate an IPv6 anycast /96 prefix TBD1 for the 794 location of a default MNAT-PT device. 796 IANA is requested to allocate an EDNS0 option and a DHCP option, both 797 TBD, and a BGP well-known community "TRANSLATEV6". 799 9. Security considerations 801 Security considerations need to be expanded in a revision of this 802 document. However, generically, MNAT-PT does not appear to introduce 803 any specific new attack vectors, although it does nothing to prevent 804 spoofing or DOS attacks. As a potential single point of failure that 805 stores per-flow state, it is intrinsically vulnerable to simple DOS. 807 Like any address translator, MNAT-PT is unfriendly to IPsec. 809 The use of synthetic AAAA records is incompatible with DNSSEC; hosts 810 implementing both MNAT-PT and DNSSEC MUST therefore perform A lookups 811 themselves. 813 In the past, security issues have been identified with the use of 814 IPv4-mapped IPv6 addresses. If these addresses were to appear on the 815 wire, neither IPv4 nor IPv6 filters would recognize them as packets 816 associated with IPv4 operation, possibly allowing the bypassing of 817 access restrictions. The current proposal suggests that such 818 addresses should not appear on the wire (or on the wireless). 820 Implementers should take care to avoid having mechanisms that 821 restrict access based on IPv4 addresses without also taking into 822 account various translation mechanisms. 824 The malicious insertion of the TRANSLATEV6 BGP community by an 825 intermediate AS will lead to routing of an address block towards a 826 translator, making that address block unreachable. However, 827 intermediate ASes have many options to disrupt the flow of IP 828 traffic, and as such, this doesn't add to existing capabilities. 830 10. References 832 10.1. Normative References 834 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 835 E. Lear, "Address Allocation for Private Internets", 836 BCP 5, RFC 1918, February 1996. 838 [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. 839 Heffernan, "DNS extensions to Network Address Translators 840 (DNS_ALG)", RFC 2694, September 1999. 842 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 843 (SIIT)", RFC 2765, February 2000. 845 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 846 Translation - Protocol Translation (NAT-PT)", RFC 2766, 847 February 2000. 849 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 850 Address Translator - Protocol Translator (NAT-PT) to 851 Historic Status", RFC 4966, July 2007. 853 [RFC3484] Draves, R., "Default Address Selection for Internet 854 Protocol version 6 (IPv6)", RFC 3484, February 2003. 856 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 857 specifying the location of services (DNS SRV)", RFC 2782, 858 February 2000. 860 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 861 RFC 2671, August 1999. 863 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 864 Communities Attribute", RFC 1997, August 1996. 866 10.2. Informative References 868 [I-D.ietf-shim6-proto] 869 Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming 870 Shim Protocol for IPv6", draft-ietf-shim6-proto-09 (work 871 in progress), November 2007. 873 [I-D.woodyatt-ald] 874 Woodyatt, J., "Application Listener Discovery (ALD) for 875 IPv6", draft-woodyatt-ald-02 (work in progress), 876 December 2007. 878 [I-D.carpenter-shanti] 879 Carpenter, B., "Shimmed IPv4/IPv6 Address Network 880 Translation Interface (SHANTI)", draft-carpenter-shanti-01 881 (work in progress), November 2007. 883 [I-D.durand-v6ops-natv4v6v4] 884 Durand, A., "Non dual-stack IPv6 deployments for broadband 885 providers", draft-durand-v6ops-natv4v6v4-00 (work in 886 progress), November 2007. 888 [I-D.bagnulo-v6ops-6man-nat64-pb-statement] 889 Bagnulo, M., "IPv6 - IPv4 Translators (NAT64) - Problem 890 Statement and Analysis", 891 draft-bagnulo-v6ops-6man-nat64-pb-statement-00 (work in 892 progress), November 2007. 894 Appendix A. Document and discussion information 896 Revision history: 898 o Version 00: initial version 900 o Version 01: added mechanisms that require changes at the IPv4 side 901 o Version 02: added support for incoming sessions from IPv4-only to 902 IPv6-only host and IPv4-IPv6-IPv4 translation, removed mechanisms 903 that require changes at the IPv4 side to avoid confusion 905 o Version 00: added in material from SHANTI, added co-author, 906 clarifications throughout, new name, removed IPv4-IPv6-IPv4 907 operation and control connection text; this may be addressed in a 908 separate document later 910 The latest version of this document will always be available at 911 http://www.muada.com/drafts/. Please direct questions and comments 912 to the v6ops mailinglist or directly to the authors. 914 Authors' Addresses 916 Iljitsch van Beijnum 917 IMDEA Networks 918 Av. Universidad 30 919 Leganes, Madrid 28911 920 ES 922 Phone: +34-91-6246245 923 Email: iljitsch@muada.com 925 Brian Carpenter 926 Department of Computer Science 927 University of Auckland 928 PB 92019 929 Auckland, 1142 930 New Zealand 932 Email: brian.e.carpenter@gmail.com 934 Full Copyright Statement 936 Copyright (C) The IETF Trust (2008). 938 This document is subject to the rights, licenses and restrictions 939 contained in BCP 78, and except as set forth therein, the authors 940 retain all their rights. 942 This document and the information contained herein are provided on an 943 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 944 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 945 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 946 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 947 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 948 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 950 Intellectual Property 952 The IETF takes no position regarding the validity or scope of any 953 Intellectual Property Rights or other rights that might be claimed to 954 pertain to the implementation or use of the technology described in 955 this document or the extent to which any license under such rights 956 might or might not be available; nor does it represent that it has 957 made any independent effort to identify any such rights. Information 958 on the procedures with respect to rights in RFC documents can be 959 found in BCP 78 and BCP 79. 961 Copies of IPR disclosures made to the IETF Secretariat and any 962 assurances of licenses to be made available, or the result of an 963 attempt made to obtain a general license or permission for the use of 964 such proprietary rights by implementers or users of this 965 specification can be obtained from the IETF on-line IPR repository at 966 http://www.ietf.org/ipr. 968 The IETF invites any interested party to bring to its attention any 969 copyrights, patents or patent applications, or other proprietary 970 rights that may cover technology that may be required to implement 971 this standard. Please address the information to the IETF at 972 ietf-ipr@ietf.org. 974 Acknowledgment 976 Funding for the RFC Editor function is provided by the IETF 977 Administrative Support Activity (IASA).