INTERNET-DRAFT George Tsirtsis, BTLABS December 1997 Network Address Translation - Protocol Translation (NAT-PT] Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This document specifies a transition mechanism in addition to those already specified in RFC 1933. The new mechanism can be used to allow IPv6-only hosts to communicate with IPv4-only hosts using Network Address Translation, for efficient use of the IPv4 address space, and Protocol Translation, in order to avoid implementing dual-stack in every machine that migrates to IPv6. This proposal attempts to reuse as much functionality as possible from existing proposals like [NAT], [NNAT] and [SIIT]. 1. Introduction IPv6 is the upcoming IP protocol that was designed in order to modernise IPv4, which was designed in the 1970s. IPv6 has a number of advantages over IPv4 including the fact that it provides a much larger address space than IPv4, which for many, is the number one reason to move to IPv6. A basic requirement, however, for a large number of people is to be able to communicate with IPv4 hosts during the transition period. Keeping in mind that the chances are, that IPv4 and IPv6 will have to coexist for a very long time, interoperability becomes a very important issue. Up to now the proposed solution was the dual stack machines. These are machines that have both an IPv4 and an IPv6 stack, which enables them to communicate with machines from both worlds. This approach has a number of problems like the fact that dual stack IPv6 machines need to be assigned global IPv4 addresses, which counteracts the main reason to move to IPv6 in the first place (lack of address space in IPv4). The NNAT proposal deals with this problem in [NNAT]. Dual stack solutions, however, have the added disadvantage of having two systems in the same machine, although hybrid stacks go some way to overcome the complexity. Some maintain that the additional burden of maintaining two stacks is negligible, mainly due to the simplification of the IPv6 maintenance through auto-configuration, automatic renumbering etc. In some cases, however, it could be unreasonable to mandate the existence of both IPv4 and IPv6 in a network, in order to maintain interoperability with IPv4. The SIIT proposal [SIIT] describes a protocol translation mechanism that allows communication between IPv6-only and IPv4-only machines. This proposal describes in detail the translation of IP and ICMP headers from IPv4 to IPv6 and vice versa. The way the IPv6 host acquires its IPv4 address, as well as, the way that IPv4 hosts initiate connections with IPv6 hosts is not included in SIIT. The NAT-PT proposal, described in this document, can be viewed as the stateful instance of the SIIT proposal, combined with Network Address Translation (NAT). NAT-PT reuses the packet translation mechanism as described in [SIIT], the NAT idea as described in [NAT] and the RT DNS record idea described in [NNAT]. Protocol Translation as described in [SIIT] is stateless. This means that each packet is translated individually and independently from all the others. In NAT-PT, all packets of a session MUST be translated with the same address mapping. Mechanisms to recognise the start and end of a session are described in [LSNAT]. Apart from the address mapping, the rest of the translation can be either stateless, exactly like in [SIIT], or stateful (by caching translation information per session). For the remainder of this document we assume stateful translation in the NAT-PT. Since NAT-PT performs address translation, applications that carry the IP address in the higher layers (like FTP) will not work. In this case Application Layer Gateways (ALG) MAY be required to provide services to that kind of applications. Some kind of local intelligence and state could also be used for the translation of more complicated functions, ranging from QoS mapping to translation of option headers. The definition of this add-on functionality is out of the scope of this document. 2. Terminology 2.1 NAT-PT Terminology Session initiation packet This is the first packet of a session (TCP/UDP) and is recognised as described in [LSNAT]. Network Address Translation (NAT) NAT in this document is very similar, but not the same, with IPv4 NAT as described in [NAT]. IPv4 NAT translates IPv4 addresses (e.g: private to global). Here by NAT we mean the translation of an IPv4 address to an IPv6 address or the translation of an IP v6 address to the IPv4 address. Protocol Translation (PT) PT in this document means the translation of an IPv4/ICMPv4 header to an IPv6/ICMPv6 header or the translation of an IPv6/ICMPv6 header to an IPv4/ICMPv4 header. The detailed translation process is described in [SIIT]. 2.2 Specification Language The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORDS]. 3. Operation In the following paragraphs we describe the operation of NAT-PT and the way that connections can be initiated from both sides, when an IPv6 domain is connected to an IPv4 domain through a NAT-PT. 3.1 Outgoing Communication (IPv6 to IPv4) ^ | [IPv6-B]-+ | +==============+ [IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C] | +==============+ (pool of v4 addresses) Figure 1: IPv6 to IPv4 communication Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210 Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211 Host IPv4-C has an IPv4 address -> 132.146.243.30 NAT-PT has a pool of addresses including the IPv4 subnet 120.130.26.0 Say the IPv6 Host A wants to communicate with the IPv4 Host C. Host A creates a packet with: Source Address, SA=FEDC:BA98::7654:3210 and Destination Address, DA = 0::132.146.243.30 The packet is routed (by static routes) to the NAT-PT gateway, where it has to be translated to IPv4. If the outgoing packet is not a session initialisation packet, the NAT-PT SHOULD already have stored some state about the related session, including assigned IPv4 address and cached parameters for the translation. If this state does not exist the packet SHOULD be silently discarded. If the packet is a session initialisation packet the NAT-PT allocates an address (e.g: 120.130.26.10) from its pool of addresses and the packet is translated to IPv4, while translation parameters are cached for the duration of the session. The resulting IPv4 packet has SA=120.130.26.10 and DA=132.146.243.30. The returning traffic will be recognised as belonging to the same session and the packet will use the cached information in order to be translated, while the addresses after the transla tion will be as follows. SA=0::132.146.243.30, DA=FEDC:BA98::7654:3210. Note that this packet can now be routed inside the IPv6-only network as normal. 3.2 Incoming Communication ^ | [DNS]-----[DNS]------[DNS]-------[DNS] [IPv6-B]-+ | | | | +==============+ | [IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C] | +==============+ (pool of v4 addresses) Figure 2: IPv4 to IPv6 communication Incoming communication is a bit more complicated because of the address translation. If Host C wants to communicate with Host A, Host C can not send a packet to Host A because Host C can not use an IPv6 address and Host A does not have an IPv4 address. Host A, however, has a DNS name, which has the same format in IPv4 and IPv6. Host C make a name lookup through its local DNS server. The DNS server does not have a record of IPv4 address attached to this name so it forwards the request to a parent server. The request at some point reaches the Primary DNS server of the IPv6 site, which redirects the request to the NAT-PT (e.g: using the RT record as described in [NNAT]). The NAT-PT returns a valid IPv4 address (e.g: from its pool of addresses) to the DNS server and eventually the reply returns to Host C, while NAT-PT caches the address mapping for a fixed amount of time (Discussion! How much time?) Host C now can initiate a connection to Host A with an IPv4 packet which includes the following addresses SA=132.146.243.30 and DA=120.130.26.10. On receiving the packet, the NAT-PT, recognises the session and translates the packets and its addresses as normal to SA=0::132.146.243.30 and DA= FEDC:BA98::7654:3210. 4. Security Considerations All security considerations associated with NAT routers, described in [NAT] as well as those described in [SIIT] and [NNAT] are applicable to NAT-PT REFERENCES [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [LSNAT] P. Srisuresh, et.al., Load Share Network Address Translator, ftp://ietf.org/internet-drafts/draft-srisuresh-lsnat-00.tx, November 1997 [NAT] P. Srisuresh, et.al., The IP Network Address Translator (NAT), ftp://ietf.org/internet-drafts/draft-rfced-info-srisuresh-03.txt, September 1997 [NNAT] Jim Bound, No Network Address Translation (NNAT) for IPv6 ,ftp://ietf.org/internet-drafts/draft-ietf-ngtrans-nnat-00.txt, November 1997 [SIIT] Erik Nordmark, Stateless IP/ICMP Translator (SIIT), ftp://ietf.org/internet-drafts/draft-ietf-ngtrans-header-trans-01.txt November 20, 1997 ACKNOWLEDGMENTS Many thanks to my colleagues Alan O'Neill and Martin Tatham whose help and support made this possible. AUTHOR George Tsirtsis Internet Transport Group B29 Room 129 BT Laboratoties Martlesham Heath IPSWICH Suffolk IP5 3RE England Phone: +44 1473 640756 Fax: +44 1473 640709 e-mail: george@gideon.bt.co.uk DISCLAIMER Notice: This contribution has been prepared to assist the IETF as a basis for discussion. It is not a binding proposal on British telecommunications plc; specifically, British Telecommunications plc reserves the right to modify, delete and amend any statements contain herein.