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.''
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
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]
