One document matched: draft-ietf-ngtrans-translator-01.txt
Differences from draft-ietf-ngtrans-translator-00.txt
Internet-Draft K. Yamamoto
IIJ Research Laboratory
Expires in six months M. Sumikawa
Category: Informational Hitachi, Ltd.
January, 1999
Categorizing Translators between IPv4 and IPv6
<draft-ietf-ngtrans-translator-01.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
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 entire list of current Internet-Drafts, 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).
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[INET]. 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
island according to the current severe address assignment
Yamamoto [Page 1]
Internet-Draft Translator Categories January 1999
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, transport relay, and application
proxy.
2.1 Header Conversion
Header conversion refers to converting IPv6 packet headers to IPv4
packet headers, or vice versa, and adjusting (or re-calculating)
checksums if necessary. This is IP level translation. Examples are
SIIT[SIIT] and main part of NATPT[NATPT]. 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 Transport relay
Transport relay refers to relaying a {TCP, UDP}/IPv4 session and a
{TCP, UDP}/IPv6 session in the middle. This is transport level
translation.
For example, 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.
Transport relay does not have problems like fragmentation or ICMP
Yamamoto [Page 2]
Internet-Draft Translator Categories January 1999
conversion, since each session is closed in IPv4 and IPv6,
respectively, but it does have problems like the translation of
network layer addresses embedded in application layer protocols.
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 transport 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. However, if it is static and proliferation
of mapped addresses is limited to a small region(i.e. Translator A,
described later), 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 of the name. If only A records are returned, the library
converts them to AAAA records embedding them into the
pre-configured prefix. ([NATPT] also discusses this mechanism.)
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 pool 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.
Yamamoto [Page 3]
Internet-Draft Translator Categories January 1999
If transport 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 transport session is mapped to a local 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
Yamamoto [Page 4]
Internet-Draft Translator Categories January 1999
Here are observations on address mapping for each translator:
Translator A:
Destination address mapping: global IPv4 to global IPv6
Static or dynamic: static
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 long 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
[EFTP] M. Allman, S. Ostermann, and C. Metz, "FTP Extensions for
IPv6 and NATs", RFC 2428, 1998.
[ICMP] J. Postel, "Internet Control Message Protocol", RFC 792,
1981.
[ICMPv6] A. Conta and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, 1998.
Yamamoto [Page 5]
Internet-Draft Translator Categories January 1999
[INET] K. Yamamoto, A. Kato, M Sumikawa, and J. Murai, "Deployment
and Experiences of WIDE 6bone", in Proceedings of INET98, 1998.
[IPv4] J. Postel, "Internet Protocol", RFC 791, 1981.
[IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, 1998
[NAT] K. Egevang and P. Francis, "The IP Network Address Translator
(NAT)", RFC 1631, 1994.
[NATPT] G. Tsirtsis and P. Srishuresh, "Network Address Translation -
Protocol Translation (NAT-PT)",
<draft-ietf-ngtrans-natpt-04.txt>, 1999
[SOCKS] 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, <draft-ietf-ngtrans-header-trans-04.txt>, 1998.
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
Changes
From 00 to 01:
- Updating references
- Refering to NATPT
- Replacing TCP relay with transport relay to generalize
Yamamoto [Page 6]
Internet-Draft Translator Categories January 1999
- Clarify that the library extensions can be used only for
Translator A.
Yamamoto [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 15:58:45 |