Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT Research Lab, IIJ Expires: July 16, 2000 Kazu Yamamoto Research Lab, IIJ January 16, 2000 An IPv6-to-IPv4 transport relay translator draft-ietf-ngtrans-tcpudp-relay-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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.'' To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be July 16, 2000. Abstract The document describes an IPv6-to-IPv4 transport relay translator. It enables an IPv6-only node to exchange TCP or UDP traffic with IPv4-only nodes. A transport relay translator box, which sits in the middle, will take care of the protocol translation. The draft talks about how we can implement a transport relay translator box. The draft is about how you can use existing technologies, and it does not define any new protocols. 1. Problem domain When you deploy an IPv6-only network, you still want to be able to access IPv4-only network resources outside, like IPv4-only web servers. To support such a configuration, many IPv6-to-IPv4 translation technologies are proposed, mainly in the IETF ngtrans working group. Hagino Expires: July 16, 2000 [Page 1] DRAFT v6-to-v4 transport relay translator January 2000 The document solves the same problem as other translation technologies solve, but based on transport relay technique. The list of advantages and disadvantages of the technique is as follows: o A transport relay translator is designed to require no extra configuration or requirement on IPv6-only originating nodes, nor IPv4-only destination nodes. Some other translation mechanisms need extra configuration on IPv6-only originating nodes, limiting possibility of deployment. o If you perform an IPv6-to-IPv4 header translation, you will need a great care about path MTU and fragmentation issues. If we relay TCP traffic by transport relay boxes, we do not need to care about path MTU nor fragmentation issues. o A transport relay supports connected bidirectional traffic only. An IPv6-to-IPv4 header translator may be able to support other cases, such as unidirectional multicast datagrams, as well. o Transport relay needs a stateful translator box between the communicating peers, just like NAT boxes. While it is possible to place multiple translator boxes in a site (see section on operational experiences), a transport layer connection will go through particular, single translator box. Therefore, the traslator box can be considered a single point of failure, again like NAT boxes. Some other mechanisms, such as SIIT [Nordmark, 1999] , use stateless translator boxes. With stateless translator boxes, you do not have a single point of failure. The document assumes that connections are originated at IPv6 node destined to IPv4 node. The document can be extended to handle opposite direction, if an apprpriate address mapping mechanism is introduced. 2. IPv4-to-IPv4 transport relay To help understanding of the proposal in the next section, here we describe transparent transport relay in general. The transport relay technique itself is not new, as it has been used in many of firewall- related products. 2.1. Transparent TCP relay Transparent TCP relay devices have been used in firewall-related products. These products are designed to achieve the follwing goals: (1) disallow forwarding of IP packet across the device, (2) while allowing TCP or UDP traffic to go through, indirectly, across the device. For example, consider a network constructed like the following diagram. ``TCP relay box'' in the diagram does not forward IP packet across inner to outer network. It only relays TCP traffic on specific Hagino Expires: July 16, 2000 [Page 2] DRAFT v6-to-v4 transport relay translator January 2000 port, from inner network side to outer network side. (Note: The diagram has only two subnets, one for inner and one for outer. Actually both side can be more complex, and there can be as many subnets and routers as you wish) destination node |X ==+=======+== outer network |Y TCP relay box |B ==+=======+== inner network |A originating node When originating node (IP address is A) tries to make a TCP connection to destination node (X), TCP packets will be routed toward TCP relay box based on routing decision. TCP relay box will receive and accept the packet, even though TCP relay box does not own the destination IP address (X). TCP relay box pretends to having IP address X, and establishes TCP connection with the originating node as X. TCP relay box will then make a separate TCP connection, from Y to X, and relay traffic from A to X, and the other way around. Therefore, there will be two TCP connections in the picture: from A to B (as X), and Y to X, like below: originating node (A) --> TCP relay box (as X, interface is B) address on IP header: A -> X TCP relay box (Y) --> destination node (X) address on IP header: Y -> X TCP relay box needs to capture some of TCP packets that is not destined to its address. The way to do it is implementation specific. 2.2. Transparent UDP relay If you can recognize UDP inbound and outbound traffic pair in some way UDP relay can be implemented in similar manner as TCP relay. An implementation can recognize UDP traffic pair like NAT boxes does, by recording address/port pairs onto an table and managing table entries by using timeouts. 3. IPv6-to-IPv4 transport relay translator We propose a transport relay box with IPv6-to-IPv4 protocol translation, which we call ``translator box'' in the document. In the following description TCP relay with IPv6-to-IPv4 translation is described. UDP Hagino Expires: July 16, 2000 [Page 3] DRAFT v6-to-v4 transport relay translator January 2000 relay can be implemented in similar manner. For address translation, we will reserve an IPv6 prefix referred to by C6::/64. Routing information must be configured so that it will be routed toward translator box. The following diagram shows the network configuration. The subnet marked as ``dummy prefix'' does not actually exist. Also, now we assume that the originating node to be IPv6-only, and the destination node to be IPv4-only. destination node |X4 ==+=======+== outer network |Y4 translator box --- dummy prefix (C6::/64) |B6 ==+=======+== inner network |A6 originating node When the originating node (IPv6 address is A6) wishes to make a connection to the destination node (IPv4 address is X4), it needs to make a IPv6 TCP connection toward C6::X4. If C4::/64 equals to fec0:0:0:1::/64, and X4 equals to 10.1.1.1, the destination address to be used is fec0:0:0:1::10.1.1.1. The packet will be routed toward translator box, and will be captured by translator box. Translator box will accept the IPv6 TCP connection between A6 and C6::X4, and communicate with originating node, using IPv6 TCP. Then, translator box will look at the lowermost 32bit of the destination address (IPv6 address C6::X4) to get the real IPv4 destination (IPv4 address X4). It will make a IPv4 TCP connection from Y4 to X4, and forward traffic across two TCP connections. There will be two TCP connections, one is IPv6 TCP and another is IPv4 TCP, in the picture: from A6 to B6 (as C6::X4), and Y4 to X4, like below: IPv6 TCP: originating node (A6) --> translator box (as C6::X4, interface is B6) address on IPv6 header: A6 -> C6::X4 IPv4 TCP: translator box (Y4) --> destination node (X4) address on IPv4 header: Y4 -> X4 4. Address mapping As seen in the previous section, originating node must use special form of IPv6 address to connect to IPv4 destination node. The special form can be resolved from hostname by static address mapping table on the originating node (like /etc/hosts in UNIX), special DNS server implementation, or modified DNS resolver implementation on originating Hagino Expires: July 16, 2000 [Page 4] DRAFT v6-to-v4 transport relay translator January 2000 node. 5. Notes to implementers UDP relay translator may need to care about path MTU issues and fragmentation issues. Though the translator box only relays TCP or UDP traffic, it needs to check ICMPv6 packets destined to C6::X4 as well, so that it can recognize path MTU discovery messsages and other notifications. When forwarding TCP traffic, the translator box needs to handle urgent data [Postel, 1981] carefully. To relay NAT-unfriendly protocols such as FTP [Postel, 1985] the translator box needs to modify data content. Scalability issues must carefully be considered when you deploy translator box to a large IPv6 site. Scalability parameters would be (1) number of connections the operating system kernel can accept, (2) number of connections a userland process can forward (equals to number of filehandles per process), and (3) number of transport relaying processes on a box. Design decision must be made to use proper number of userland processes to support proper number of connections. To make TCP relay translator more scalable when you install it to a large site, it is possible to have multiple translator boxes in a site. This can be done by taking the following steps: (1) configure multiple translator boxes, (2) configure different dummy prefix to them, (3a) and let the originating node pick a dummy prefix randomly for load- balancing. If you install special DNS server to the site, you may (3b) configure DNS servers differently to return different dummy prefixes and tell originating nodes of different DNS servers, or (3c) let DNS server pick a dummy prefix randomly for load-balancing. This is possible because you will not be changing destination address (hence the translator box), once a TCP connection is established. For address mapping, the authors recommend use of a special DNS server for large-scale installation, and static mapping for small-scale installation. It is not always possible to have special resolver on the originating node, and assuming it would cause a deployment problem. 6. Operational experiences WIDE KAME IPv6 stack implements the tecnique as ``FAITH'' IPv6-to-IPv4 TCP relay translator implementation. The implementation came from WIDE Hydrangea IPv6 stack, which is one of ancestors of the KAME IPv6 stack. The FAITH code has been available and operational for more than 3 years. The implementation has been used at WIDE research group offsite meeting, Hagino Expires: July 16, 2000 [Page 5] DRAFT v6-to-v4 transport relay translator January 2000 and IETF ipngwg 1999 Tokyo interim meeting. At the latter occasion, we configured IPv6-only terminal network cluster just like we do in IETF meetings, and used translator box to support more than 100 IPv6 nodes on the meeting network to connect to outside IPv4 nodes. From statistics we gathered, SSH, FTP, HTTP, and POP3 are the most popular protocol we have relayed. Source code is available as free software, bundled in the KAME IPv6 stack kit. Special DNS server implementations are available as ``newbie'' DNS server implementation by Yusuke Doi, and ``totd'' DNS proxy server from University of Tromso (Norway). 7. Security considerations The document describes transport relay box used for IPv6-to-IPv4 protocol translation. The authors believe that there is no new security risk introduced by this draft. Malicious IPv6 node may try to use translator box for anonymizing the source IP address of traffic to IPv4 destinations. A translator box should implement some sort of access control to avoid such improper usage. Careless transport relay implementation may subject to buffer overflow attack, but this kind of issue is implementation issue, not the document issue. References Nordmark, 1999. Erik Nordmark, "Stateless IP/ICMP Translator (SIIT)" in draft-ietf- ngtrans-siit-06.txt (June 24, 1999). work in progress material. Postel, 1981. J. Postel, "Transmission Control Protocol" in RFC793 (Sep 1, 1981). ftp://ftp.isi.edu/in-notes/rfc793.txt. Postel, 1985. J. Postel and J.K. Reynolds, "File Transfer Protocol" in RFC959 (Oct 1, 1985). ftp://ftp.isi.edu/in-notes/rfc959.txt. Acknowledgements The authors would like to thank people who were involved in implementing KAME FAITH translator code, including Kei-ichi Shima and Munechika Sumikawa. Hagino Expires: July 16, 2000 [Page 6] DRAFT v6-to-v4 transport relay translator January 2000 Author's address Jun-ichiro itojun Hagino Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 email: itojun@iijlab.net Kazu Yamamoto Research Laboratory, Internet Initiative Japan Inc. (see above for address and phone #) email: kazu@iijlab.net Hagino Expires: July 16, 2000 [Page 7]