Subject: (ngtrans) An IPv6-to-IPv4 transport relay translator

From: Bob Fink <[email-masked]>
Date: Wed, 19 Jan 2000 08:05:41 -0800

NGtrans folk,

Jun-ichiro itojun Hagino has requested that we start a new project on a 
TCP/UDP (transport) Relay Translator. Below is the draft as submitted to 
the I-D editor.

There is no determination yet of the destination status of this document 
(info, standard or experimental) so please comment on this as well.

Comments to the ngtrans list please.

Thanks,

Bob

===
 >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.

	Bob Fink (ngtrans chair) suggested draft-ietf-ngtrans-tcpudp-relay-NN
	as filename, so the attached version reflects that.  Thanks.

itojun

========================================================================
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: [email-masked]

      Kazu Yamamoto
      Research Laboratory, Internet Initiative Japan Inc.
      (see above for address and phone #)
      email: [email-masked]

Hagino                   Expires: July 16, 2000                 [Page 7]