[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

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]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/