Subject: (ngtrans) FAITH translator

From: [email-masked]
Date: Wed, 14 Jul 1999 00:55:15 +0900

In yesterday's meeting (ngtrans 1st slot) Mr. Sekiya of WIDE mentioned
	translators used in WIDE CAMP (offsite meeting of our research group).
	We used TCP relay translator and IPv4-to-IPv6 header translator for it.
	The latter is much like SIIT, but the former is not documented yet.

	To give you more detail about our TCP relay translator, I wrote
	up a draft for it.  It is still incomplete (has incomplete references) 
	but I felt it worth sending as we are in Oslo.  If you have
	questions and comments, please catch me during Oslo IETF meetings
	or send me emails.  After Oslo IETF, I'll submit it to the proper
	path (so that it can appear in i-d directory).

	I think it can become informational draft after some discussions and
	clarifications.  this is not for standard track.

itojun

---

Internet Engineering Task Force                 Jun-ichiro itojun Hagino
INTERNET-DRAFT                                         Research Lab, IIJ
Expires: January 9, 2000                                   Kazu Yamamoto
                                                       Research Lab, IIJ
                                                           July 13, 1999

              ``FAITH'' IPv6-to-IPv4 TCP relay translator
                     draft-itojun-ipv6-faith-00.txt

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 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 learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Distribution of this memo is unlimited.

The internet-draft will expire in 6 months.  The date of expiration will
be January 9, 2000.

Abstract

The document describes IPv6-to-IPv4 TCP relay translator, hereby called
``FAITH''.  It lets IPv6 node to make TCP connection toward IPv4 node.
FAITH TCP translator box, which sits in the middle, will take care of
the protocol translation.

The draft talks about how we can implement FAITH TCP translator box.
The draft is about how you can use the existing technologies, and this
does not define any new protocol.

1.  Problem domain

If you deploy IPv6-only network, you will need to access network
resources outside, accessible only by IPv4, such as IPv4-only web
servers.  To support such an environment, many IPv6-to-IPv4 translation
technologies are proposed (***reference***).  The document solves same
problem as other translation technologies, but in TCP relay based
technique.  We call our technique ``FAITH'', which stands for

Hagino                  Expires: January 9, 2000                [Page 1]


DRAFT                  FAITH TCP relay translator              July 1999

``Firewall-Aided Internet Translator H???''  (***what was H stands
for?***).

The following lists advantages and disadvantages of TCP relay based
translation technique:

o  If you do IPv6-to-IPv4 header translation, you will need a great care
   about path MTU and fragmentation issues.  TCP relay translation does
   not have the problem.

o  FAITH is designed so that it needs no extra configuration or
   requirement at IPv6-only originating node.  Originating node can be
   any IPv6 node.  Other translation mechanisms, such as SOCKS or AIIH,
   needs extra configuration on IPv6-only end node.

o  FAITH supports TCP connection originated at IPv6 node destined to
   IPv4 node, but no others.  Some of other mechanisms try to support
   opposite direction.

o  TCP relay translation supports translation of TCP traffic only.
   IPv6-to-IPv4 header translation can support other protocols, such as
   UDP, as well.

o  TCP relay translation needs a stateful translator box between the
   communicating peers.  Therefore, it can be the single point of
   failure.  Some other mechanisms, such as SIIT (**reference**), uses
   stateless translator box.  SIIT does not have the single point of
   failure.

2.  Transparent TCP relay

Here we describe transparent TCP relay in general.  The technique has
been used in TCP relay firewall products, such as TIS Gauntlet
(***reference***).

Network is constructed as seen in the following diagram.  TCP relay box
does not forward IP packet across inner to outer network.  It only
relays TCP traffic on specific port, from inner network side to outer
network side.  The diagram has only two subnets, one for inner and one
for outer, but both side can be more complex.  There can be as many
routers as you wish.

Hagino                  Expires: January 9, 2000                [Page 2]


DRAFT                  FAITH TCP relay translator              July 1999

     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), the TCP packet 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
communicate with originating node.  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 two TCP connection 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)
         addr on packet: A -> X
     TCP relay box (Y) --> destination node (X)
         addr on packet: Y -> B

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.  On BSD-
based IP stack, it can be achieved by tweaking ip_input(), to (1) check
address pair and destination port on the packet, and (2) perform ``goto
ours'' if it needs to be captured.

3.  FAITH TCP translation box

FAITH TCP translator box works just as the TCP relay box in previous
section.  The only addition is that it involves IPv6 to IPv4 address
translation.

For address translation, we will reserve an IPv6 prefix referred to by
C6::/64.  The routing announcement must be configured so that it will be
routed toward FAITH translator box.  The following diagram shows the
network configuration.  Dummy prefix does not actually exist.  Also, now
inner network is IPv6-only, and outer network is IPv4-only.

Hagino                  Expires: January 9, 2000                [Page 3]


DRAFT                  FAITH TCP relay translator              July 1999

     destination node
       |X4
     ==+=======+== outer network
               |Y4
             FAITH translator box --- dummy prefix (C6::/64)
               |B6
     ==+=======+== inner network
       |A6
     originating node

When originating node (IPv6 address is A6) wishes to make a connection
to 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 FAITH translator
box, and will be captured by FAITH translator box.  FAITH translator box
will accept the IPv6 TCP connection and communicate with originating
node, using IPv6 TCP.  Then, FAITH 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 two TCP connection, 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)
             --> FAITH translator box (as C6::X4, interface is B6)
         addr on packet: A6 -> C6::X4
     IPv4 TCP: FAITH translator box (Y4) --> destination node (X4)
         addr on packet: Y4 -> B4

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 by static address mapping (/etc/hosts in UNIX), modified
DNS resolver implementation on originating node, or special DNS server
implementation,

The author recommends to have special DNS server implementation in a
site for large-scale installation, and use of static mapping for small-
scale installation.  It is not a good idea to tweak resolvers on
originating nodes.

Hagino                  Expires: January 9, 2000                [Page 4]


DRAFT                  FAITH TCP relay translator              July 1999

5.  Notes to implementers

Though FAITH translator box only relays TCP traffic, it needs to check
ICMPv6 packets destined to C6::X4 as well, so that it can recognize path
MTU changes and other events.

When forwarding TCP traffic, urgent data [Postel, 1981] must be handled
carefully.

NAT-unfriendly protocols such as FTP [Reynolds, 1985] needs translation
of TCP data content as well.

Scalability issues must be considered when you deploy FAITH translator
box it to large IPv6 site.  Scalability parameters would be (1) number
of TCP connections the kernel can accept, (2) number of TCP connections
a userland process can forward (equals to number of filehandles per
process), and (3) number of TCP relaying processes on a box.  Design
decision must be made to use proper number of userland processes to
support proper number of TCP connections.

HTTP traffic can be supported by IPv4/v6 dual stack HTTP proxies as
well.  It is sometimes better to use HTTP proxies, as some
implementation provides caching of content.

6.  Operational experiences

The FAITH IPv6-to-IPv4 TCP relay translator is implemented in KAME IPv6
stack and has been used for more than 2 years.  The implementation has
been used at WIDE research group offsite meeting.  We configured
IPv6-only terminal network cluster just like we do in IETF meetings, and
used FAITH translator box to support more than 100 IPv6 nodes on the
offsite network to connect to outside IPv4 nodes.  From statistics we
gathered, SSH, FTP, HTTP, and POP3 are the most popular protocol we've
relayed.

7.  Security considerations

The document describes TCP relay box used for IPv6-to-IPv4 protocol
translation.  The author believes that there is no security risk
introduced by this draft.

Careless TCP relay implementation may subject to buffer overflow attack,
but this kind of issue is implementation issue, not the document issue.

References

Postel, 1981.
J. Postel, "Transmission Control Protocol" in RFC793 (Sep 1, 1981).
ftp://ftp.isi.edu/in-notes/rfc793.txt.

Hagino                  Expires: January 9, 2000                [Page 5]


DRAFT                  FAITH TCP relay translator              July 1999

Reynolds, 1985.
J. Postel and J.K. Reynolds, "File Transfer Protocol" in RFC959 (Oct 1,
1985). ftp://ftp.isi.edu/in-notes/rfc959.txt.

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: January 9, 2000                [Page 6]