< draft-ietf-ngtrans-tcpudp-relay-03.txt		draft-ietf-ngtrans-tcpudp-relay-04.txt >
	Internet Engineering Task Force Jun-ichiro itojun Hagino		A new Request for Comments is now available in online RFC libraries.
	INTERNET-DRAFT IIJ Research Laboratory
	Expires: October 5, 2001 Kazu Yamamoto
	IIJ Research Laboratory
	April 5, 2001
	An IPv6-to-IPv4 transport relay translator
	draft-ietf-ngtrans-tcpudp-relay-03.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		RFC 3142
	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		Title: An IPv6-to-IPv4 Transport Relay Translator
	http://www.ietf.org/1id-abstracts.html		Author(s): J. Hagino, K. Yamamoto
			Status: Informational
			Date: June 2001
			Mailbox: itojun@iijlab.net, kazu@iijlab.net
			Pages: 11
			Characters: 20864
			Updates/Obsoletes/SeeAlso: None
	The list of Internet-Draft Shadow Directories can be accessed at		I-D Tag: draft-ietf-ngtrans-tcpudp-relay-04.txt
	http://www.ietf.org/shadow.html.
	Distribution of this memo is unlimited.		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3142.txt
	The internet-draft will expire in 6 months. The date of expiration will		The document describes an IPv6-to-IPv4 transport relay translator
	be October 5, 2001.		(TRT). It enables IPv6-only hosts to exchange {TCP,UDP} traffic with
			IPv4-only hosts. A TRT system, which locates in the middle,
			translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa.
	Abstract		This document is a product of the Next Generation Transition Working
			Group of the IETF.
	The memo describes an IPv6-to-IPv4 transport relay translator (TRT). It		This memo provides information for the Internet community. It does
	enables IPv6-only hosts to exchange {TCP,UDP} traffic with IPv4-only		not specify an Internet standard of any kind. Distribution of this
	hosts. A TRT system, which locates in the middle, translates		memo is unlimited.
	{TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa.
	The draft talks about how to implement a TRT system using existing		The memo talks about how to implement a TRT system using existing
	technologies. It does not define any new protocols.		technologies. It does not define any new protocols.
	1. Problem domain		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
	When you deploy an IPv6-only network, you still want to gain access to		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	IPv4-only network resources outside, such as IPv4-only web servers. To		added to or deleted from the RFC-DIST distribution list should
	solve this problem, many IPv6-to-IPv4 translation technologies are		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	proposed, mainly in the IETF ngtrans working group. The memo describes
	a translator based on the transport relay technique to solve the same
	problem.
	In this memo, we call this kind of translator ``TRT'' (transport relay
	translator). A TRT system locates between IPv6-only hosts and IPv4
	hosts and translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, vice versa.
	Advantages of TRT are as follows:
	o TRT is designed to require no extra modification on IPv6-only
	initiating hosts, nor that on IPv4-only destination hosts. Some other
	translation mechanisms need extra modifications on IPv6-only
	initiating hosts, limiting possibility of deployment.
	o The IPv6-to-IPv4 header converters have to take care of path MTU and
	fragmentation issues. However, TRT is free from this problem.
	Disadvantages of TRT are as follows:
	o TRT supports bidirectional traffic only. The IPv6-to-IPv4 header
	converters may be able to support other cases, such as unidirectional
	multicast datagrams.
	o TRT needs a stateful TRT system between the communicating peers, just
	like NAT systems. While it is possible to place multiple TRT systems
	in a site (see Appendix A), a transport layer connection goes through
	particular, a single TRT system. The TRT system thus can be
	considered a single point of failure, again like NAT systems. Some
	other mechanisms, such as SIIT [Nordmark, 2000] , use stateless
	translator systems which can avoid a single point of failure.
	o Special code is necessary to relay NAT-unfriendly protocols. Some of
	NAT-unfriendly protocols, including IPsec, cannot be used across TRT
	system.
	The memo assumes that traffic is initiated by an IPv6-only host destined
	to an IPv4-only host. The memo 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 the 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. TCP relay
	TCP relay systems have been used in firewall-related products. These
	products are designed to achieve the follwing goals: (1) disallow
	forwarding of IP packets across a system, and (2) allow {TCP,UDP}
	traffic to go through the system indirectly. For example, consider a
	network constructed like the following diagram. ``TCP relay system'' in
	the diagram does not forward IP packet across the inner network to the
	outer network, vice versa. It only relays TCP traffic on a specific
	port, from the inner network to the outer network, vice versa. (Note:
	The diagram has only two subnets, one for inner and one for outer.
	Actually both sides can be more complex, and there can be as many
	subnets and routers as you wish)
	destination host
	|X
	==+=======+== outer network
	|Y
	TCP relay system
	|B
	==+=======+== inner network
	|A
	initiating host
	When the initiating host (whose IP address is A) tries to make a TCP
	connection to the destination host (X), TCP packets are routed toward
	the TCP relay system based on routing decision. The TCP relay system
	receives and accepts the packets, even though the TCP relay system does
	not own the destination IP address (X). The TCP relay system pretends
	to having IP address X, and establishes TCP connection with the
	initiating host as X. The TCP relay system then makes a another TCP
	connection from Y to X, and relays traffic from A to X, and the other
	way around.
	Thus, two TCP connections are established in the picture: from A to B
	(as X), and from Y to X, like below:
	TCP/IPv4: the initiating host (A) --> the TCP relay system (as X)
	address on IPv4 header: A -> X
	TCP/IPv4: the TCP relay system (Y) --> the destination host (X)
	address on IPv4 header: Y -> X
	The TCP relay system needs to capture some of TCP packets that is not
	destined to its address. The way to do it is implementation dependent
	and outside the scope of this memo.
	2.2. 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 systems does, by
	recording address/port pairs onto an table and managing table entries
	with timeouts.
	3. IPv6-to-IPv4 transport relay translator
	We propose a transport relay translator for IPv6-to-IPv4 protocol
	translation, TRT. In the following description, TRT for TCP is
	described. TRT for UDP can be implemented in similar manner.
	For address mapping, we reserve an IPv6 prefix referred to by C6::/64.
	C6::/64 should be a part of IPv6 unicast address space assigned to the
	site. Routing information must be configured so that packets to C6::/64
	are routed toward the TRT system. The following diagram shows the
	network configuration. The subnet marked as ``dummy prefix'' does not
	actually exist. Also, now we assume that the initiating host to be
	IPv6-only, and the destination host to be IPv4-only.
	destination host
	|X4
	==+=======+== outer network
	|Y4
	TRT system --- dummy prefix (C6::/64)
	|B6
	==+=======+== inner network
	|A6
	initiating host
	When the initiating host (whose IPv6 address is A6) wishes to make a
	connection to the destination host (whose IPv4 address is X4), it needs
	to make an TCP/IPv6 connection toward C6::X4. For example, if C6::/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 is routed toward
	the TRT system, and is captured by it. The TRT system accepts the
	TCP/IPv6 connection between A6 and C6::X4, and communicate with the
	initiating host, using TCP/IPv6. Then, the TRT system investigates the
	lowermost 32bit of the destination address (IPv6 address C6::X4) to get
	the real IPv4 destination (IPv4 address X4). It makes an TCP/IPv4
	connection from Y4 to X4, and forward traffic across the two TCP
	connections.
	There are two TCP connections. One is TCP/IPv6 and another is TCP/IPv4,
	in the picture: from A6 to B6 (as C6::X4), and Y4 to X4, like below:
	TCP/IPv6: the initiating host (A6) --> the TRT system (as C6::X4)
	address on IPv6 header: A6 -> C6::X4
	TCP/IPv4: the TRT system (Y4) --> the destination host (X4)
	address on IPv4 header: Y4 -> X4
	4. Address mapping
	As seen in the previous section, an initiating host must use a special
	form of IPv6 address to connect to an IPv4 destination host. The
	special form can be resolved from a hostname by static address mapping
	table on the initiating host (like /etc/hosts in UNIX), special DNS
	server implementation, or modified DNS resolver implementation on
	initiating host.
	5. Notes to implementers
	TRT for UDP must take care of path MTU issues on the UDP/IPv6 side.
	This is implementation dependent and outside of the scope of this memo.
	A simple solution would be to always fragment packets from the TRT
	system to UDP/IPv6 side to IPv6 minimum MTU (1280 octets), to eliminate
	the need for path MTU discovery.
	Though the TRT system only relays {TCP,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 between A6 and C6::X4.
	When forwarding TCP traffic, a TRT system needs to handle urgent data
	[Postel, 1981] carefully.
	To relay NAT-unfriendly protocols [Holdrege, 2000] a TRT system may need
	to modify data content, just like any translators which modifies the IP
	addresses.
	Scalability issues must carefully be considered when you deploy TRT
	systems 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 TRT system. Design decision must be made to use proper number of
	userland processes to support proper number of connections.
	To make TRT for TCP more scalable in a large site, it is possible to
	have multiple TRT systems in a site. This can be done by taking the
	following steps: (1) configure multiple TRT systems, (2) configure
	different dummy prefix to them, (3) and let the initiating host pick a
	dummy prefix randomly for load-balancing. (3) can be implemented as
	follows; If you install special DNS server to the site, you may (3a)
	configure DNS servers differently to return different dummy prefixes and
	tell initiating hosts of different DNS servers. Or you can (3b) let DNS
	server pick a dummy prefix randomly for load-balancing. The load-
	balancing is possible because you will not be changing destination
	address (hence the TRT system), 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
	initiating host, and assuming it would cause deployment problems.
	6. Applicability statement
	Combined with a special DNS server implementation (which translates IPv4
	addresses into IPv6), TRT systems support IPv6-to-IPv4 translation very
	well. It requires no change to existing IPv6 clients, nor IPv4 servers,
	so the TRT system can be installed very easily to existing IPv6-capable
	networks.
	IPv4-to-IPv6 translation is much harder to support with any of the
	translator techniques [Yamamoto, 2000] . While it is possible to use
	TRT system for IPv4-to-IPv6 translation, it requires nontrivial mapping
	between DNS names to temporary IPv4 addresses, as presented in NAT-PT
	RFC [Tsirtsis, 2000] .
	As presented in the earlier sections, TRT systems use transport layer
	(TCP/UDP) relay technique to translate IPv6 traffic to IPv4 traffic. It
	gives two major benefits: (1) the implementation of the TRT system can
	be done very simple, (2) the TRT system can ignore issues with packet
	sizes, including path MTU discovery and fragmentation. Even with the
	simplicity, the TRT system can cover most of the daily applications
	(HTTP, SMTP, SSH, and many other protocols). For NAT-unfriendly
	protocols, a TRT system may need to modify data content, just like any
	translators/NATs. As the TRT system reside in transport layer, it is
	not possible for the TRT system to translate protocols that are not
	known to the TRT system.
	7. Security considerations
	Malicious party may try to use TRT systems akin to an SMTP open relay
	[Lindberg, 1999] for traffic to IPv4 destinations, which is similar to
	circumventing ingress filtering [Ferguson, 1998] , or to achieve some
	other improper use. TRT systems should implement some sorts of access
	control to prevent such improper usage.
	A careless TRT implementation may be subject to buffer overflow attack,
	but this kind of issue is implementation dependent and outside the scope
	of this memo.
	Due to the nature of TCP/UDP relaying service, it is not recommended to
	use TRT for protocols that use authentication based on source IP address
	(i.e. rsh/rlogin).
	A transport relay system intercepts TCP connection between two nodes.
	This may not be a legitimate behavior for an IP node. The draft does
	not try to claim it to be legitimate.
	IPsec cannot be used across a relay.
	Use of DNS proxies that modify the RRs will make it impossible for the
	resolver to verify DNSsec signatures.
	References
	Nordmark, 2000.
	E. Nordmark, "Stateless IP/ICMP Translator (SIIT)" in RFC2765 (February,
	2000). ftp://ftp.isi.edu/in-notes/rfc2765.txt.
	Postel, 1981.
	J. Postel, "Transmission Control Protocol" in RFC793 (Sep 1, 1981).
	ftp://ftp.isi.edu/in-notes/rfc793.txt.
	Holdrege, 2000.
	Matt Holdrege and Pyda Srisuresh, "Protocol Complications with the IP
	Network Address Translator (NAT)" in draft-ietf-nat-protocol-
	complications-02.txt (March 2000). work in progress material.
	Yamamoto, 2000.
	K. Yamamoto and M. Sumikawa, "Overview of Transition Techniques for
	IPv6-only to Talk to IPv4-only Communication," internet draft (March
	2000). work in progress material.
	Tsirtsis, 2000.
	G. Tsirtsis and P. Srisuresh, "Network Address Translation - Protocol
	Translation (NAT-PT)" in RFC2766 (February 2000). ftp://ftp.isi.edu/in-
	notes/rfc2766.txt.
	Lindberg, 1999.
	Gunnar Lindberg, "Anti-Spam Recommendations for SMTP MTAs" in RFC2505
	(February 1999). ftp://ftp.isi.edu/in-notes/rfc2505.txt.
	Ferguson, 1998.
	P. Ferguson and D. Senie, "Network Ingress Filtering: Defeating Denial
	of Service Attacks which employ IP Source Address Spoofing" in RFC2267
	(January 1998). ftp://ftp.isi.edu/in-notes/rfc2267.txt.
	Appendix A. Operational experiences
	WIDE KAME IPv6 stack implements TRT for TCP, called ``FAITH''. 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,
	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 a TRT system to support more than 100 IPv6 hosts on
	the meeting network to connect to outside IPv4 hosts. From statistics
	we gathered SSH, FTP, HTTP, and POP3 are the most popular protocol we
	have relayed.
	The 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).
	Acknowledgements
	The authors would like to thank people who were involved in implementing		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	KAME FAITH translator code, including Kei-ichi SHIMA and Munechika		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	SUMIKAWA.		help: ways_to_get_rfcs. For example:
	Author's address		To: rfc-info@RFC-EDITOR.ORG
			Subject: getting rfcs
	Jun-ichiro itojun HAGINO		help: ways_to_get_rfcs
	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		Requests for special distribution should be addressed to either the
	Research Laboratory, Internet Initiative Japan Inc.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	(see above for address and phone #)		specifically noted otherwise on the RFC itself, all RFCs are for
	Email: kazu@iijlab.net		unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 14 change blocks.
	358 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/