Internet-Draft K. Yamamoto IIJlab Expires in six months M. Sumikawa Hitachi, Ltd. November, 1998 Categorizing Translators between IPv4 and IPv6 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.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This memo categorizes translators between IPv4 and IPv6. The two components, address interpretation and address mapping, are discussed. This draft is based on a paper appeared in the proceedings of INET98. The intention of this memo is circulation of such knowledge. 1. Introduction In the early stage of the migration from IPv4[IPv4] to IPv6[IPv6], it is expected that IPv6 islands will be connected to the IPv4 ocean. On the other hand, in the late stage of the migration, IPv4 islands will be connected to the IPv6 ocean. IPv4 hosts need to be connected to the Internet after the IPv4 address space is exhausted. So, it is necessary to develop translators to enable direct communication between IPv4 hosts and IPv6 hosts. This memo assumes the following for the practical migration scenario from IPv4 to IPv6: (1) We cannot modify IPv4 hosts, but we can implement IPv6 hosts as we like. (2) A small space of IPv4 address is also assigned to an IPv6 Yamamoto [Page 1] Internet-Draft Translator Categories November 1998 island according to the current severe address assignment policy. (3) An IPv4 island can also obtain a large space of IPv6 address. A typical translator consists of two components: interpretation between IPv4 packets and IPv6 packets described in Section 2 and address mapping between IPv4 and IPv6 explained in Section 3. 2. Interpretation of IPv4 and IPv6 For interpretation of IPv4 and IPv6, three technologies are available: header conversion, TCP relay, and application proxy. 2.1 Header Conversion Header conversion refers to converting IPv6 packet headers to IPv4 packet headers, or vice versa, and re-calculating checksums if necessary. This is IP level translation. An example is SIIT[SIIT]. Note that NAT[NAT] is IPv4-to-IPv4 header converter. Header conversion is fast enough, but it has disadvantages in common with NAT. A good example is difficulty in the translation of network layer addresses embedded in application layer protocols, which are typically found in FTP and FTP Extensions[EFTP]. Also, header conversion has problems which are not found in NAT: a large IPv4 packet is fragmented to IPv6 packets because the header length of IPv6 is typically 20 bytes larger than that of IPv4, and the semantics of ICMP[ICMP] and that of ICMPv6[ICMPv6] are not inter-changeable. 2.2 TCP relay TCP relay refers to relaying a TCP/IPv4 connection and a TCP/IPv6 connection in the middle. This is TCP level translation. A typical TCP relay server works as follows: when a TCP request reaches a relay server, the network layer tosses it up to the TCP layer even if the destination is not the server's address. The server accepts this TCP packet and establishes a TCP connection from the source host. One more TCP connection is also made from the server to the real destination. Then the server reads data from one of the two connections and writes the data to the other. SOCKS[SOCKS] is an another example. A SOCKS based translator requires client hosts to be "SOCKS-ready" by installing SOCKS libraries, etc. TCP relay does not have problems like fragmentation or ICMP conversion, since each connection is closed in IPv4 and IPv6, respectively, but it does have problems like the translation of network layer addresses embedded in application layer protocols. Yamamoto [Page 2] Internet-Draft Translator Categories November 1998 2.3 Application Proxy An application proxy for a transaction service is used to hide site information and improve service performance with a cache mechanism. An application proxy can be a translator between IPv4 and IPv6 if it supports both protocols. This is application level translation. Since each service is closed in IPv4 and IPv6, respectively, there are no disadvantages found in header conversion, but servers for each service must be bilingual. 3. Address Mapping Address mapping refers to the allocation of an IPv6 destination address for a given IPv4 destination address, and vice versa. It also includes the allocation of an IPv6 source address for a given IPv4 source address, and vice verca. If interpretation is performed at the Internet protocol level or TCP level, address mapping is an essential issue. If an FQDN(Fully Qualified Domain Name) is used to specify a target host, address mapping is not necessary. So, the application proxy is free of this problem. SOCKS version 5 is a kind of TCP relay, but it is also free of this because it can make use of FQDN. In the case that address mapping is dynamic, it must be implemented in interaction with DNS. If it is static, however, it can be implemented by extending resolver libraries on local hosts. Of course, DNS can also map addresses statically. An example of library extensions for static mapping: an application tries resolving AAAA records against a host name. The resolver library requests DNS servers A or AAAA records to the name. If only A records are returned, the library converts them to AAAA records embedding them into the pre-configured prefix. An example of DNS extensions for dynamic mapping: if a DNS server receives a request to return A records for a host name, but only an AAAA record is resolved, the server picks up an IPv4 address from its address spool then returns it as A record. There are two criteria for addresses to be assigned: (1) the assigned addresses must be reachable between the triggered host and translator, and (2) if addresses are assigned dynamically by DNS, it must be ensured that the DNS cache doesn't cause problems for further communications. If TCP relay is used for interpretation, address mapping is necessary only for destination addresses since source address mapping is closed in the relay server. In other words, the protocol association of the first TCP connection is mapped to a local TCP Yamamoto [Page 3] Internet-Draft Translator Categories November 1998 port number on the relay server. For header conversion, source address mapping is not essential, either. A protocol association can be represented by a local port of the conversion router or by an address out of the pool or by both. 3.1. Translator Categories To discuss address mapping, this memo categorizes IPv4/IPv6 translator into four types illustrated by the following pictures: In the early stage +----------------------+ +-------------+ Translator A | | | |--------------->| | | IPv6 island | | The IPv4 ocean | | |<---------------| | +-------------+ Translator B | | +----------------------+ In the late stage +----------------------+ +-------------+ Translator C | | | |--------------->| | | IPv4 island | | The IPv6 ocean | | |<---------------| | +-------------+ Translator D | | +----------------------+ Translator A: It is used in the early stage of transition to establish a connection from an IPv6 host in an IPv6 island to an IPv4 host in the IPv4 ocean. Translator B: It is used in the early stage of transition to establish a connection from an IPv4 host in the IPv4 ocean to an IPv6 host in an IPv6 island. Translator C: It is used in the late stage of transition to establish a connection from an IPv4 host in an IPv4 island to an IPv6 host in the IPv6 ocean. Translator D: It is used in the late stage of transition to establish a connection from an IPv6 host in the IPv6 ocean to an IPv4 host in an IPv4 island. 3.2. Observations on Address Mapping for Each Translator Here are observations on address mapping for each translator: Translator A: Destination address mapping: global IPv4 to global IPv6 Static or dynamic: static Yamamoto [Page 4] Internet-Draft Translator Categories November 1998 Address pool: a part of assigned global IPv6 addresses to the IPv6 site DNS cache problem: not encountered Implementation: straightforward Note: IPv4 addresses can be embedded to pre-configured IPv6 prefix. Translator B: Destination address mapping: global IPv6 to global IPv4 Static or dynamic: dynamic Address pool: assigned global IPv4 addresses to the IPv6 site DNS cache problem: potentially proliferated into the IPv4 ocean Implementation: nearly impossible Note: it is recommended to use static address mapping for several IPv6 hosts(servers) in the IPv6 site to provide their services to the IPv4 ocean(e.g. dual-stack servers without translators). Translator C: Destination address mapping: global IPv6 to private IPv4 Static or dynamic: dynamic Address pool: a part of private IPv4 addresses DNS cache problem: closed to the IPv4 site Implementation: possible Note: mapped addresses should be reserved as longer as possible for UDP applications which can't tell the end of communications and for applications which cache DNS entries. Translator D: Destination address mapping: global IPv4 to global IPv6 Static or dynamic: static Address pool: assigned global IPv6 addresses to the site DNS cache problem: not encountered Implementation: straightforward Note: IPv4 addresses can be embedded to pre-configured IPv6 prefix. References [INET] K. Yamamoto, A. Kato, M Sumikawa, and J. Murai, Deployment and Experiences of WIDE 6bone, in Proceedings of INET98, 1998. [ICMP] J. Postel, Internet Control Message Protocol, RFC 792, 1981. [ICMPv6] S. Deering and R. Hinden, Internet Protocol Version 6 (IPv6), RFC 1883, 1995. [IPv4] J. Postel, Internet Protocol, RFC 791, 1981. [IPv6] A. Conta and S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6, RFC 1885. 1995. [EFTP] M. Allman, S. Ostermann, and C. Metz, FTP Extensions for IPv6 and NATs, RFC 2428, 1998. Yamamoto [Page 5] Internet-Draft Translator Categories November 1998 [NAT] K. Egevang and P. Francis, The IP Network Address Translator (NAT), RFC 1631, 1994. [SOCK5] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and L. Jones, SOCKS Protocol Version 5, RFC 1928, 1996. [SIIT] E. Nordmark, Stateless IP/ICMP Translator (SIIT), Internet-Draft, , 1997. Acknowledgements The authors would like to thank many people for their contributions to this memo, especially Shin-ichi Fujisawa, Jun-ichiro Ito, Akira Jinzaki, Akira Kato, Atsushi Onoe, Kazushi Sugyo, and Shigeya Suzuki (in alphabetical order). Authors' Addresses Kazuhiko YAMAMOTO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho Chiyoda-ku, Tokyo 101-0054 JAPAN Phone: +81-3-5259-6350 FAX: +81-3-5259-6351 EMail: kazu@iijlab.net Munechika Sumikawa Hitachi, Ltd. 810 Shimoimaizumi, Ebina city, Kanagawa 243-0435 JAPAN Phone: +81-462-35-8265 FAX: +81-462-35-8325 EMail: sumikawa@ebina.hitachi.co.jp Yamamoto [Page 6]