Network Working Group I. van Beijnum Internet-Draft IMDEA Networks Expires: August 15, 2008 B. Carpenter Univ. of Auckland February 12, 2008 Modified Network Address Translation - Protocol Translation draft-van-beijnum-v6ops-mnat-pt-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract A smooth transition from IPv4 to IPv6 requires that either all hosts are upgraded to dual stack before the first hosts can become IPv6- only, or that there be some mechanism for IPv6-only hosts to talk to IPv4-only hosts. Expecting the former within a reasonable timeframe isn't realistic, based on current adoption of dual stack combined with the latest projections for the IPv4 depletion that point to a date early in the next decade. And the IETF has recently deprecated van Beijnum & Carpenter Expires August 15, 2008 [Page 1] Internet-Draft Modified NAT-PT February 2008 the main mechanism that allows the latter: NAT-PT. This document proposes a modified form of NAT-PT that addresses the reasons why the mechanism was deprecated and currently understood requirements. This should allow future deployment of the modified NAT-PT as an IPv4-to-IPv6 transition mechanism, giving operators the option of running their networks largely IPv6-only. 1. Introduction 1.1. Background The original NAT-PT mechanism outlined in [RFC2766] couples three underlying techniques to arrive at a comprehensive solution that allows IPv6-only hosts to initiate connections or associations towards IPv4-only hosts: 1. Stateless IP and ICMP Translation [RFC2765] 2. Network Address / Port Translation 3. A DNS Application Layer Gateway [RFC2694] Basically, when an IPv6 host wants to connect to a service, it looks up the associated host/service name in the DNS. If no AAAA records are available for the name in question, the DNS ALG synthesizes an AAAA record based on the A record for the host/service and a prefix that's routed to a translation device. The IPv6 host initiates communication towards the resulting IPv6 address. The associated packets end up at the translator, which recovers the original IPv4 destination address, translates between IPv6 and IPv4, performs IPv4 NAT and sends the resulting packet to the IPv4 destination. Return packets are translated back and sent to the IPv6 host. 1.2. Summary of Requirements [RFC4966] explains why NAT-PT as originally defined is problematic. The main objections boil down to hosts being exposed to an unexpected environment, issues with referrals in the absence of relevant Application Layer Gateways, generation of synthetic DNS responses that may be harmful if not properly contained and constraints on network topology. Another problem with having a DNS ALG in a central location in the network is that this makes it hard to make synthetic AAAA records only flow towards IPv6-only hosts and not dual stack hosts. A major requirement on any modified form of NAT-PT is to mitigate or eliminate as many of the issues in [RFC4966] as possible. van Beijnum & Carpenter Expires August 15, 2008 [Page 2] Internet-Draft Modified NAT-PT February 2008 The underlying requirement can be summarized as providing a scaleable, reliable and secure mechanism by which IPv4-only hosts may exchange packets with IPv6-only hosts. Aspects of this include: 1. IPv4-only hosts are presumed to be legacy systems to which no modifications whatever can be made. Even if IPv6 is supported on their network, they have no way to understand or create IPv6 packets, even if certain applications understand IPv6 addresses. 2. IPv4-only hosts may be on legacy networks whose routers have no support for IPv6. 3. For the purposes of this document, the IPv6 host has no direct support for IPv4, i.e. it is not a dual-stack host. (If it was a dual-stack host, it could have direct or tunneled and possibly NATted IPv4 connectivity to the IPv4-only host.) 4. From the IPv4 host's point of view, nothing should behave worse than in the case of an IPv4-to-IPv4 translation. 5. From the IPv6-only host's point of view, we can require some special code in the IP stack, but no knowledge of IPv4 should generally be required in the transport layer or above. 6. IPv6 routing should not be affected in any way, and there should be no risk of importing "entropy" from the IPv4 routing tables into IPv6. 7. At the point where the IPv6 and IPv4 addressing domains meet, it is necessary to share limited IPv4 addresses among multiple IPv6 hosts in some way, while allowing the IPv4 host to assume that {IPv4 address, port number} 2tuples are unique. 8. It should be possible to locate the translation device at an arbitrary point in the network (i.e. not at fixed points such as a site exit), so that there is full operational flexibility. 9. Any configuration need for an IPv6 host to make use of the mechanism should be possible centrally, e.g. a DHCP option. A full problem statement and requirements analysis is developed in [I-D.bagnulo-v6ops-6man-nat64-pb-statement]. 1.3. Outline of Solution As noted in the requirements, we cannot ask for any change whatever in legacy IPv4 hosts. However, it is considered reasonable to require enhancements to IPv6-only stacks, which are much rarer at the van Beijnum & Carpenter Expires August 15, 2008 [Page 3] Internet-Draft Modified NAT-PT February 2008 time of writing than dual stacks, and certainly are not a legacy. Based on this consideration, this document proposes to make the IPv6 side aware of the translation in order to avoid the majority of the problems associated with the original NAT-PT. The objective is to allow the IPv6 stack at the host to be aware of the presence of the translator, of the addresses involved in the translation, and of other information known by the translator that may be of value to the IPv6 host. There may be cases where a "legacy" IPv6 stack is in used that knows nothing of this solution. We do propose a mechanism for this, which can best be described as a DNS trick (moving the creation of synthetic AAAA records much closer to the IPv6 host). Although this document goes into some detail, it's intended as a discussion document; as such, not every aspect is completely worked out. This version incorporates text and ideas from [I-D.carpenter-shanti]. In some discussions, a distinction is made between Network Address Translation (NAT) which only translates addresses, and Network Address/Port Translation (NAPT) which translates both addresses and TCP/UDP port numbers. No such distinction is made here; "NAT" is used to refer to both types of translation. In fact, due to the requirement for multiple IPv6 hosts to share a limited number of IPv4 addresses, port multiplexing is inevitable. The requirement above that behaviour be no worse than in IPv4-IPv4 NAT is significant. It means that the required behaviour is isomorphic to an IPv6-to-IPv4 translation followed by IPv4-IPv4 NAT, even if the two translations are implemented in a single stage. We use the abbreviation "MNAT-PT" to refer to the modified NAT-PT mechanism described in this document. 2. IPv6-to-IPv4 operation In the following diagram, A(x) is an IPv6 address of the IPv6 host X. P(x) is the port number in use at X. A(t) is a synthesized IPv6 address for the translator T. P(y) is the port number in use at the IPv4 host Y. van Beijnum & Carpenter Expires August 15, 2008 [Page 4] Internet-Draft Modified NAT-PT February 2008 a(t) is an IPv4 address of the translator. P(tx) is the translated port number presented to the IPv4 host. a(y) is the IPv4 address of Y. v6 host MNAT-PT v4 host X T Y _______ A(x) A(t) _______________ a(t) a(y) _______ | | V6|P(x) P(y)| V6| | | V4|P(tx) P(y)| V4| | | | | | | S | N | | | | | | U | S | | S | I | A | S | | S | U | | L | T |------------| T | I | T | T |-----------| T | L | | P | A | | A | T | | A | | A | P | | | C | | C | | | C | | C | | | | K | | K | | | K | | K | | |___|___| |___|___|___|___| |___|___| If there's another IPv4 NAT with address a(n) on the IPv4 path, it won't know anything is special, and a(y) will be represented by a(n). X, Y and T won't know that the NAT is there. X and T will not know if Y has a private [RFC1918] address or if additional port translation takes place. 2.1. Use of A records and addressing the translator In the original NAT-PT design a DNS ALG would create synthetic AAAA DNS records for FQDNs that only have A records. This is the source of the worst problems described in [RFC4966]. Although discouraged, this mechanism MAY still be used. However, in order to comply with this specification, DNS ALGs MUST include an EDNS0 option [RFC2671] in any replies that contain synthetic AAAA records to make these records recognizable as synthetic so that they can be filtered by hosts that have no need for them and DNS servers. IPv6 hosts that want to communicate with IPv4 hosts SHOULD look up the A records themselves, obtaining a(y), and create a synthetic IPv6 destination address by concatenating a particular /96 prefix and the bits of a(y). The resulting IPv6 address A(t) will cause the packet to be delivered to the relevant MNAT-PT. Thus the IPv6 hosts "behind" a MNAT-PT translator SHOULD behave in one of two ways: 1. The IPv6 host has a combination of resolver, API and stack that in effect maps A records into AAAA records expanded with that /96. When resolving an FQDN via getaddrinfo(), the effect is to return A(t) instead of a(y). The upper layer protocol will see van Beijnum & Carpenter Expires August 15, 2008 [Page 5] Internet-Draft Modified NAT-PT February 2008 only an IPv6 address. 2. Alternatively, the IPv6 host users IPv4 addresses in their native or IPv4-mapped IPv6 form and then add the /96 bits as a packet is about to be generated for transmission on the wire. Both mechanisms will work in a network with a mixture of MNAT-PT and dual-stack hosts. The former would see A(t), and the latter would see a(y), using the same, unmodified, DNS server. The two ways to do MNAT-PT have different tradeoffs. In both cases, it's suboptimal to have MNAT-PT activated on dual stack hosts, because this prevents native IPv4 operation. In addition to that, in the former case going from IPv6-only with MNAT-PT to dual stack without MNAT-PT (when native IPv6 connectivity becomes available) doesn't cause interruptions in ongoing communication. In the latter case, the transition from IPv6-only with MNAT-PT to dual stack without MNAT-PT means all communication towards IPv4 destinations will immediately change from using MNAT-PT to native IPv4, thereby breaking ongoing sessions. This document does not specify exactly how MNAT-PT should be implemented; there is a range of design options, such as in the resolver, in the socket API, or even in the stack itself, as detailed below. This list of options is not exhaustive; any implementation that exhibits similar externally visible behaviour is acceptable. The most basic way to implement this specification is almost identical to the original NAT-PT, except that the DNS ALG functionality is moved as close to the hosts that make use of the translator as possible. The DNS ALG can be integrated in a host's resolver library or be provided by an external server topologically close to the host. This means that the IPv6 stack on a host sees synthetic AAAA records and treats the addresses in those AAAA records as regular IPv6 addresses. For many applications and protocols, this can work well, but it has the downside that applications may see NAT applied to what they percieve as IPv6 communication. As such, this way of implementing MNAT-PT is only recommended for applications and protocols that have no problem working through NAT. Applications SHOULD avoid storing addresses learned through synthetic AAAA records in accordance with the zero (or one) TTL value in those records. Alternatively, an implementation may forego the use of synthetic AAAA records, and present IPv4 addresses in A records to applications as IPv4-mapped IPv6 addresses in the ::ffff:0:0/96 prefix. When the host in question only has IPv6 connectivity and it is configured with a /96 prefix of a translator, it will, for the purposes of [RFC3484] address selection, treat destination addresses of this type as IPv6 van Beijnum & Carpenter Expires August 15, 2008 [Page 6] Internet-Draft Modified NAT-PT February 2008 addresses so the host's IPv6 address(es) can be used as a source address. When generating IP packets, the stack replaces the ::ffff: 0:0/96 prefix in the destination address with the /96 prefix for the translator and sends the packets to the translator. Applications may recognize the IPv4-mapped IPv6 addresses and adjust their behaviour to the apparent use of IPv4. However, the use of an IPv6 source address could lead to unexpected application behaviour in this case. Finally, an implementation may choose to provide full IPv4 service to applications, by not only supporting the IPv6 socket API with IPv4- mapped addresses as outlined above, but by also supporting the IPv4 socket API. For full compatibility, a synthetic IPv4 source address in [RFC1918] space is generated, indicating to applications not only that the communication is going towards an IPv4 destination, but also that there will be NAT, so that applications can employ NAT traversal techniques. Each of these approaches removes the need for a DNS-ALG that is created by the original NAT-PT model, and thereby removes the problems caused by a DNS-ALG. In the hopefully rare case that an IPv6 address representing an IPv4 host needs to be configured manually, it MAY be configured as the MNAT-PT translator's /96 prefix concatenated with the IPv4 address. The approach where IPv4 addresses are used in their native or IPv4- mapped IPv6 form is preferable and SHOULD be used if supported because this way, the host is able to communicate successfully if it is later served by a different MNAT-PT translator or obtains native IPv4 connectivity. There are three possible approaches to the /96 prefix: 1. Use ::ffff:0:0/96 as an anycast prefix 2. Use a to-be-defined prefix other than ::ffff:0:0/96 as an anycast prefix 3. Use a prefix specific to a translator The authors are of the opinion that the benefits of simplicity of the first approach don't outweigh the downsides of unexpectedly seeing IPv4-mapped IPv6 addresses on the wire. In order to provide flexibility to operators, the third option MUST be supported using the discovery/configuration mechanisms outlined later in this document. The desireability of the second option is open for further discussion. As such: The 96-bit prefix used by a translator SHOULD be in the IPv6 global van Beijnum & Carpenter Expires August 15, 2008 [Page 7] Internet-Draft Modified NAT-PT February 2008 unicast space (2000::/3) or unique local address space (fc00::/7). Note that the status of parts of the IPv6 address space may change over time; it is not appropriate to hardcode these prefixes in applications or default configurations. The 96-bit prefix used by a translator MUST NOT use the ::/96 or ::ffff:0:0/96 prefixes. Discussion: There has been an operational preference that IPv4-mapped IPv6 addresses should not appear on the wire, although this is broken by SIIT ([RFC2765]), one of the underlying mechanisms of the original NAT-PT. Operational difficulties have been reported with such addresses escaping into the wild, and there is confusion because thay are also used for automatic mapping within some dual stacks. Although it requires more work, an arbitrary prefix for the translator can still maintain the "checksum to zero" property. However, since we assume that the MNAT-PT device will also perform port mapping, checksum recalculation seems inevitable anyway. So does the checksum-to-zero property matter? The SHANTI proposal [I-D.carpenter-shanti] avoided this problem by actively translating the IPv6 address used, at the expense of considerable complexity. The current proposal is to accept that checksum recalculation in the translator is inevitable (as it is in IPv4-IPv4 NAT). In this case, the ::ffff:0:0/96 prefix has no particular advantage. Allowing an arbitrary, or anycast, prefix to locate the MNAT-PT device allows for arbitrary topology: the MNAT-PT can be on the IPv6 site, or in any ISP location that has both IPv4 and IPv6 connectivity. This allows for great flexibility in deployment models. For operational convenience, there must be a way for a client machine to discover the locally applicable MNAT-PT /96 prefixe. This draft does not fully specify this mechanism. The range of possibilities include: 1. Default to the anycast prefix mentioned above. 2. Define a DHCPv6 option. 3. Define a DNS based convention such as mnat. prepended to the local domain name. Use the /96 prefix of the corresponding AAAA record. 4. Allow manual configuration of a DNS name as an almost last resort. 5. Allow manual configuration as a last resort. The authors intended to specify mechanisms for the second and third van Beijnum & Carpenter Expires August 15, 2008 [Page 8] Internet-Draft Modified NAT-PT February 2008 options in a later version of this document. 2.2. Use of a synthetic IPv4 source address Optionally, IPv6-only hosts MAY support IPv4 (and IPv4-mapped IPv6) socket calls for compatibility with applications that don't support native IPv6 communication and/or need to be aware of the fact that communication is happening over IPv4 and/or is subject to NAT. A natural way to indicate this is through the use of an IPv4 source address from [RFC1918] space. An IPv6-only host implementing IPv4 compatible socket calls picks one of its global scope IPv6 addresses as the source address A(x) for MNAT-PT. It then generates a local IPv4 address in the prefix 172.31.0.0/16, where the lower 16 bits are chosen such that a TCP or UDP checksum computed over the IPv6 addresses that appear on the wire are the same as those resulting from the synthetic IPv4 source address and the IPv4 destination address. This means that the value of the lower 16 bits in the synthetic IPv4 address are generated through the one's complement addition of the 16-bit words that make up the 96 bit prefix used for IPv4 destinations reachable through the translator and the selected IPv6 source address. Then, a one's complement subtraction of the value 44063 (decimal) is performed to adjust for the 172.31.0.0/16 prefix. The result of this is that TCP and UDP checksums computed over both the IPv4 and MNAT-PT IPv6 representations of packets destined for the translator are the same (ignoring port numbers for the moment). UDP packets MUST have a valid checksum, as required by IPv6. Although adjusting checksums during translation steps is relatively easy, knowing that IPv4 and IPv6 versions of the checksum are identical may allow for a more flexible implementation, where it's not necessary to keep track of whether a packet was or will be translated when a checksum is computed. The resulting synthetic IPv4 address is internally used as the source address in all IPv4 processing. Note that MNAT-PT translators keep track of IPv6 hosts by their IPv6 address: the synthetic IPv4 source address is unknown to translators and is only used for compatibility with IPv4-aware applications. 2.3. Signaling from the translator to the IPv6 host An option to be considered, derived from [I-D.carpenter-shanti], is for the MNAT-PT to signal to the IPv6 host to inform it of the port number P(tx) and outbound IPv4 address a(t) actually in use. The IPv6 host is aware of its own IPv6 address and of the port number it van Beijnum & Carpenter Expires August 15, 2008 [Page 9] Internet-Draft Modified NAT-PT February 2008 is using, but these are meaningless on the IPv4 side. With the added signaling, it would know the 4tuple {a(y), a(t), P(y), P(tx)} in use on the IPv4 side. In this case, the IPv6 host could in principle compute a transport checksum that will be valid after address and port translation, and send this instead of a valid IPv6 checksum. Such signaling, to be useful to the upper layer protocols in the IPv6 host, would need to occur before the upper layer protocol actually sent its first packet; in effect the IPv6 stack would have to send a "request to send" message to the MNAT-PT, in order for the MNAT-PT to create the necessary translation state and respond with the {a(t), P(tx)} values. Tentatively, such a mechanism could use either a dedicated signaling channel such as an SSL connection between the IPv6 host and the MNAT-PT, or in-band signaling using a shim header modeled on SHIM6 [I-D.ietf-shim6-proto]. The type of information to be signaled might include discovery of a(t) and P(tx), opening an external port, etc. It is open to discussion whether this is worthwhile or whether a more general approach such as [I-D.woodyatt-ald] might not be better. This question is not discussed further in this draft. 2.4. Operation Packets towards to-be-translated IPv4 destinations are transmitted over the network as usual, but are delivered to the IPv6 interface of the MNAT-PT translation device. The translation device performs SIIT translation and IPv4 NAT. The possible artificial IPv4 source address is ignored during these steps, since it is not required by either step except as a means to keep track of which sessions on the public IPv4 side map to which sessions on the IPv6 side. However, since different IPv6 hosts served by the same translation device may have selected the same artificial IPv4 address, (de)multiplexing based on this value won't work. So the SIIT and NAT stages must be integrated such that the NAT associates sessions on the public IPv4 side directly with the IPv6 side without a private IPv4 intermediate. Port translation, port mapping, and transport checksum recalculation will be handled by the NAT component exactly as in a normal IPv4-IPv4 NAT. 3. IPv4-to-IPv6 operation In order for IPv6-only hosts to receive unsolicited incoming packets (e.g. incoming TCP sessions and UDP packets that aren't replies to UDP packets sent earlier), unsolicited packets towards a certain address / port combination must be translated to a corresponding IPv6 van Beijnum & Carpenter Expires August 15, 2008 [Page 10] Internet-Draft Modified NAT-PT February 2008 address by a MNAT-PT translators. Much of this resembles what a normal NAT must do to handle unsolicited incoming packets destined for servers using private [RFC1918] address space. If the NAT function of the MNAT-PT (see above diagram) opens port P(tx) at IPv4 address a(t) for unsolicited packets, it must be configured to map that port to a port P(x) at IPv6 address A(x). When a flow starts, state is kept to be able to translate return packets from IPv6 to IPv4. The issues associated with configuring port mappings and creating, maintaining and expiring this state are exactly those encountered by normal NAT, but those can be avoided using the mechanism described below. Any organisation needing to provide MNAT-PT translation for unsolicited incoming packets will need to allocate one or more IPv4 addresses under its control to this purpose, and arrange for the corresponding mappings to be configured in MNAT-PT devices. It is most likely that this will be done by sites running IPv6-only servers and wishing to serve IPv4-only clients, or by the ISP serving a site. A site running dual-stack servers has no need to run MNAT-PT, and an IPv4-only site or ISP is unable to do so. In most scenarios, the IPv4 address(es) assigned to an MNAT-PT device will be globally routable public addresses. However, there is no technical reason that they should not be chosen from private[RFC1918] address space, if a deployment scenario requires it. The IPv4 source address is encoded in bits 96 - 127 and the IPv4 destination port number in bits 80 - 95 of the IPv6 address for thusly translated packets so that applications configured with the knowledge that they are receiving incoming sessions from IPv4 hosts may recover the original IPv4 source address and destination port number. The source port number MUST NOT be changed during the translation process. This makes the translation process stateless. If desired, the owner of an address block that is used exclusively for IPv4-to-IPv6 translation can publish mappings from IPv4 address/ port combinations to IPv6 address/port combinations in the reverse DNS tree as follows: _service._proto.31.2.0.192.in-addr.arpa IN SRV pri weight v6port FQDN Where proto is an upper layer protocol (TCP or UDP), pri is a priority, weight a weight, v6port is a port number used by the IPv6 host and FQDN a fully qualified domain name used by the IPv6 host in accordance with [RFC2782]. service, however, is not a service name, but the decimal form of the destination port number in the IPv4 van Beijnum & Carpenter Expires August 15, 2008 [Page 11] Internet-Draft Modified NAT-PT February 2008 packet. The address block is then advertised in IPv4 BGP with the well-known community TRANSLATEV6 attached [RFC1997]. This allows operators of translators that receive the advertisement through BGP to route packets towards the address block in question to their own translator, which recovers the mappings from the DNS and performs the translation locally. Because the translator inserts its own /96 prefix in the IPv6 source address, packets flow back and forth between the IPv4 and IPv6 hosts through the same translator. It is of course compatible with the above that organisations obtain address blocks for the specific purpose of making IPv6 services available over IPv4 and anycasting these address blocks in addition to setting the TRANSLATEV6 community. Because each TCP and UDP port number can be mapped individually, a relatively small IPv4 address block can accommodate a large number of IPv6 services, as long as these services don't depend on well-known port numbers. MNAT-PT translators MUST encode the IPv4 destiantion port number and source address in the lower 48 bits of the IPv6 source address in translated packets. This means that translators must have a /80 range of IPv6 addresses available to perform this type of translation. Encoding of the IPv4 source address in the IPv6 source address allows conformant applications or operating systems to recover the original IPv4 destination port and source address of the correspondent. However, this only works if the incoming packets are indeed translated IPv4 packets. If this functionality is desired, administrators must take care to keep incoming translated IPv4 sessions and normal IPv6 sessions apart by making these arrive at different IPv6 addresses. In other words, if it's desired that applications can tell when incoming sessions originate from IPv4 hosts, a server behind an MNAT-PT will need at least one IPv6 address in its native IPv6 server role (announced as a public AAAA record), and at least one other IPv6 address in its MNAT-PT serving role (not announced as an AAAA record, but announced in SRV records in the reverse IPv4 DNS). Note that for this type of translation, there is no requirement that checksums calculated over the IPv4 and IPv6 pseudo headers are the same: translators must adjust checksums. An alternative to this was part of the SHANTI proposal [I-D.carpenter-shanti] in which the external address and port numbers would be signaled to the IPv6 host stack. In this case checksums and any other upper layer uses of the IPv4 information could be handled in the IPv6 host alone. As noted above, it is an open question whether this added complexity is worthwhile. van Beijnum & Carpenter Expires August 15, 2008 [Page 12] Internet-Draft Modified NAT-PT February 2008 4. Examples The anycast range for IPv6-to-IPv4 translation is assumed to be 1000::/96 in these examples, and the IPv4 address of the translator is 10.0.0.96. (10.0.0.96 and 172.18.64.80 are used as an example public IPv4 addresses, not as private addresses here.) 4.1. IPv6-to-IPv4 IPv6 host pc1.beispiel.de 2001:db8:31::dead:beef wants to communicate with IPv4 host www.example.com, which holds address 192.0.2.58. pc1.beispiel.de doesn't use a synthetic IPv4 source address. 1. pc1.beispiel.de looks up AAAA records for www.example.com with no results 2. pc1.beispiel.de looks up A records for www.example.com: 192.0.2.58 3. pc1.beispiel.de initiates a TCP session from 2001:db8:31::dead: beef port 1025 to 1000::192.0.2.58 port 80 4. the translator sets up a translation mapping from { [2001:db8: 31::dead:beef]:1025 [1000::192.0.2.58]:80 } to { [10.0.0.96]: 49152 [192.0.2.58]:80 } 5. the translator translates packets back and forth until the session is no longer used and the mapping is garbage collected 4.2. IPv6-to-IPv4 with synthetic IPv4 source address IPv6 host pc2.beispiel.de 2001:db8:31::cafe wants to communicate with IPv4 host www.example.com, which holds address 192.0.2.58. pc2.beispiel.de uses a synthetic IPv4 source address. 1. pc2.beispiel.de does a one's complement addition of the values 1000, 0000, 0000, 0000, 0000, 0000 (the translator anycast address), 2001, 0db8, 0031, 0000, 0000, 0000, 0000, cafe (its source address) which results in 08e9 2. pc2.beispiel.de does a one's complement subtraction of ac1f (172.31) from 08e9 = a336 (163.54) 3. pc2.beispiel.de configures a virtual network interface with IPv4 address 172.31.163.54 4. pc2.beispiel.de looks up AAAA records for www.example.com with no results van Beijnum & Carpenter Expires August 15, 2008 [Page 13] Internet-Draft Modified NAT-PT February 2008 5. pc2.beispiel.de looks up A records for www.example.com: 192.0.2.58 6. pc2.beispiel.de initiates a TCP session from 2001:db8:31::cafe port 1025 to 1000::192.0.2.58 port 80 7. the translator sets up a translation mapping from { [2001:db8: 31::cafe]:1025 [1000::192.0.2.58]:80 } to { 10.0.0.96:49153 192.0.2.58:80 } 8. the translator translates packets back and forth until the session is no longer used and the mapping is garbage collected 4.3. IPv4-to-IPv6 IPv4 host mac1.example.com holding address 192.0.2.253 wants to communicate over the FTP protocol with IPv6 host pc1.beispiel.de. The port number available for this service is 32767. In order to accommodate incoming sessions, pc1.beispiel.de has set up the following entries in the DNS: pc1.beispiel.de. IN A 172.18.64.80 _32767._tcp.80.64.18.172.in-addr.arpa IN SRV 21 pc1.ddns.beispiel.de. pc1.ddns.beispiel.de. IN AAAA 2001:db8:31::dead:beef The closest MNAT-PT translator uses prefix 2001:db8:ffff::/96 for translations from IPv4 to IPv6. 1. mac1.example.com wants to connect to pc1.beispiel.de on port 32767 2. mac1.example.com looks up A records for pc1.beispiel.de in the DNS: 172.18.64.80 3. mac1.example.com sets up a TCP session from 192.0.2.253:1025 to 172.18.64.80:32767 4. the packet for 172.18.64.80 is routed towards a MNAT-PT translator 5. the translator transfers 172.18.64.80:32767 into _32767._tcp.80.64.18.172.in-addr.arpa 6. the translator looks up SRV records: 0 0 21 pc1.ddns.beispiel.de van Beijnum & Carpenter Expires August 15, 2008 [Page 14] Internet-Draft Modified NAT-PT February 2008 7. the translator looks up AAAA records: 2001:db8:31::dead:beef 8. the translator sets up a mapping from { 192.0.2.253:1025 172.18.64.80:32767 } to { [2001:db8:ffff::192.0.2.253]:1025 [2001:db8:31::dead:beef]:21 } 9. the translator translates packets back and forth until the session is no longer used and the mapping is garbage collected 5. Advantages and disadvantages 5.1. Disadvantages MNAT-PT operation is possible without necessarily requiring changes to the TCP/IP stack or applications, but in that case, applications may operate under the assumption that they're talking to IPv6 correspondents, while in fact they are communicating with IPv4 correspondents. This may result in a mismatch in IP protocol version for protocols that embed IP addresses. 5.2. Advantages There are several advantages. An important one is that NAT issues only come up when the host is communicating towards IPv4 addresses. As such, it's trivial for applications to limit NAT workaround code to sessions towards IPv4 destinations and assume global addressability for IPv6 destinations. Since there is no DNS ALG, and if there is one, it inserts the EDNS0 "poison pill" in any records that contain synthetic AAAA records, there are no issues with possible leakage of synthetic AAAA records as soon as the EDNS0 option is widely supported and/or DNS ALGs are no longer used. Both IPv4 applications that use IPv4 socket calls and IPv6 applications that use IPv6 socket calls with IPv4-mapped IPv6 addresses can work over MNAT-PT. Alternatively, light-weight implementations may omit all IPv4 code, except perhaps the ability to perform A record lookups. 5.3. Advantages over providing real NATed IPv4 connectivity An obvious way to enjoy many of the same benefits would be to build a network that supports both IPv6 and IPv4 with NATed connectivity. However, this means that there must be an IPv4 network infrastructure in place in the form of IPv4 routers and IPv4 address provisioning (DHCP). Today, this is easy to do in smaller installations if there is a single public IPv4 address available. However, in larger networks the planning of private IPv4 addressing can become cumbersome, and when IPv4 addresses are scarce, it may be unavoidable van Beijnum & Carpenter Expires August 15, 2008 [Page 15] Internet-Draft Modified NAT-PT February 2008 to implement multiple levels of NAT. Multiple levels of NAT at the very least impose the limits of the most restrictive NAT, and also make hole punching that is used to be able to receive incoming connections much harder as a single set of port numbers must be shared by a larger number of hosts. NAT traversal technologies may or may not support multiple layers of NAT. With MNAT-PT, it's only necessary to provision IPv6 connectivity and addressing, which is easier to plan for because unlike IPv4, a standard /64 IPv6 subnet supports arbitrary numbers of hosts. The translation device that performs NAT and the hosts making use of the MNAT-PT service can be located with few topological constraints, so multiple layers of NAT are much easier to avoid. Additionally, the only state that must be kept by the translator is that inherent to NAT operation, there is no need to maintain IPv4 addressing, allowing for easier scalability of the solution. 6. Evaluation of RFC4966 concerns This section provides an overview of the issues raised in [RFC4966] and how they apply to the use of modified NAT-PT with modifications on the IPv6 side. 6.1. Issues with Lack of Address Persistence To-be-translated IPv4 destination addresses map to the same IPv6 destination address until the host selects a different /96 prefix. However, if addresses are stored in their IPv4 form, this doesn't lead to broken referrals. Issues with mapping persistence from the IPv4 side to the IPv6 side are the same as with regular NAT and can be solved in the same way: by having the application or OS set up a persistent mapping that allows incoming connections. 6.2. DoS Attacks on Memory and Address/Port Pools Denial-of-service issues are mostly the same as with regular NAT. When a non-anycast translator is used, it's likely that authentication through a control connection is required, allowing for easy rejection of to-be-translated traffic coming from addresses that don't have an active control connection. However, unless the IPv6 source host and the translator are prepared to set up an IPsec tunnel, there is no way to reject to-be-translated traffic which spoofs the source address of a host with an active control connection. If the source host uses an IPv6 source address for this communication that it doesn't use for other types of communication, only on-path attackers or hosts on the same subnet have easy knowledge of the source address in question. van Beijnum & Carpenter Expires August 15, 2008 [Page 16] Internet-Draft Modified NAT-PT February 2008 6.3. Issues Directly Related to Use of DNS-ALG Fixed definitively. 6.4. Impact on IPv6 Application Development Applications see regular IPv4 destination addresses for to-be- translated destinations so they can engage IP version specific code paths as required. The presence of the [RFC1918] synthetic source address makes it possible for applications to use NAT workarounds for to-be-translated destinations. The extra work the application needs to do here is the same as it would when running on a dual stack host. Alternatively, TCP/IP stacks may forego implementing the synthetic IPv4 source address and/or applications may choose to remain ignorant of whether they're communicating with an IPv4 or IPv6 correspondent. In those cases, address-based referrals are likely to break for IPv4 destinations unless the MNAT-PT translator employs an Application Layer Gateway for the protocol that's used. 7. Acknowledgments This document has benefited from ideas from Marcelo Bagnulo and Alain Durand. Readers are encouraged to also review [I-D.carpenter-shanti], [I-D.durand-v6ops-natv4v6v4] and [I-D.bagnulo-v6ops-6man-nat64-pb-statement]. 8. IANA considerations IANA is requested to allocate an IPv6 anycast /96 prefix TBD1 for the location of a default MNAT-PT device. IANA is requested to allocate an EDNS0 option and a DHCP option, both TBD, and a BGP well-known community "TRANSLATEV6". 9. Security considerations Security considerations need to be expanded in a revision of this document. However, generically, MNAT-PT does not appear to introduce any specific new attack vectors, although it does nothing to prevent spoofing or DOS attacks. As a potential single point of failure that stores per-flow state, it is intrinsically vulnerable to simple DOS. Like any address translator, MNAT-PT is unfriendly to IPsec. van Beijnum & Carpenter Expires August 15, 2008 [Page 17] Internet-Draft Modified NAT-PT February 2008 The use of synthetic AAAA records is incompatible with DNSSEC; hosts implementing both MNAT-PT and DNSSEC MUST therefore perform A lookups themselves. In the past, security issues have been identified with the use of IPv4-mapped IPv6 addresses. If these addresses were to appear on the wire, neither IPv4 nor IPv6 filters would recognize them as packets associated with IPv4 operation, possibly allowing the bypassing of access restrictions. The current proposal suggests that such addresses should not appear on the wire (or on the wireless). Implementers should take care to avoid having mechanisms that restrict access based on IPv4 addresses without also taking into account various translation mechanisms. The malicious insertion of the TRANSLATEV6 BGP community by an intermediate AS will lead to routing of an address block towards a translator, making that address block unreachable. However, intermediate ASes have many options to disrupt the flow of IP traffic, and as such, this doesn't add to existing capabilities. 10. References 10.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. van Beijnum & Carpenter Expires August 15, 2008 [Page 18] Internet-Draft Modified NAT-PT February 2008 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. 10.2. Informative References [I-D.ietf-shim6-proto] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-09 (work in progress), November 2007. [I-D.woodyatt-ald] Woodyatt, J., "Application Listener Discovery (ALD) for IPv6", draft-woodyatt-ald-02 (work in progress), December 2007. [I-D.carpenter-shanti] Carpenter, B., "Shimmed IPv4/IPv6 Address Network Translation Interface (SHANTI)", draft-carpenter-shanti-01 (work in progress), November 2007. [I-D.durand-v6ops-natv4v6v4] Durand, A., "Non dual-stack IPv6 deployments for broadband providers", draft-durand-v6ops-natv4v6v4-00 (work in progress), November 2007. [I-D.bagnulo-v6ops-6man-nat64-pb-statement] Bagnulo, M., "IPv6 - IPv4 Translators (NAT64) - Problem Statement and Analysis", draft-bagnulo-v6ops-6man-nat64-pb-statement-00 (work in progress), November 2007. Appendix A. Document and discussion information Revision history: o Version 00: initial version o Version 01: added mechanisms that require changes at the IPv4 side van Beijnum & Carpenter Expires August 15, 2008 [Page 19] Internet-Draft Modified NAT-PT February 2008 o Version 02: added support for incoming sessions from IPv4-only to IPv6-only host and IPv4-IPv6-IPv4 translation, removed mechanisms that require changes at the IPv4 side to avoid confusion o Version 00: added in material from SHANTI, added co-author, clarifications throughout, new name, removed IPv4-IPv6-IPv4 operation and control connection text; this may be addressed in a separate document later The latest version of this document will always be available at http://www.muada.com/drafts/. Please direct questions and comments to the v6ops mailinglist or directly to the authors. Authors' Addresses Iljitsch van Beijnum IMDEA Networks Av. Universidad 30 Leganes, Madrid 28911 ES Phone: +34-91-6246245 Email: iljitsch@muada.com Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand Email: brian.e.carpenter@gmail.com van Beijnum & Carpenter Expires August 15, 2008 [Page 20] Internet-Draft Modified NAT-PT February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). van Beijnum & Carpenter Expires August 15, 2008 [Page 21]