[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.
                                                             March, 2000

                   Overview of Transition Techniques
            for IPv6-only to Talk to IPv4-only Communication

                <draft-ietf-ngtrans-translator-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 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
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

Abstract

    This memo discusses translators to enable direct communication
    between IPv4 hosts and IPv6 hosts. Three translation mechanisms are
    described. From the address mapping point of view, the translators
    are categorized into four types and each feasibility is considered.
    This memo is based on a paper appeared in Proceedings of
    INET98[INET].

1. Introduction

    In the early stage of the migration from IPv4[IPv4] to IPv6[IPv6],
    it is expected that IPv6 sites will be connected to the IPv4
    Internet. On the other hand, in the late stage of the migration,
    IPv4 sites will be connected to the IPv6 Internet. IPv4 hosts need
    to be connected to the Internet even after the IPv4 address space
    is exhausted. So, it is necessary to develop translators to enable
    direct communication between IPv4 hosts and IPv6 hosts.





Yamamoto                                                        [Page 1]


Internet-Draft             IPv4/IPv6 translators              March 2000

    This memo assumes the following for the practical migration scenario
    from IPv4 to IPv6:

        (1) We cannot modify both IPv4 hosts and IPv6 hosts in typical
            environments.

        (2) A small space of IPv4 address is also assigned to an IPv6
            site according to the current severe address assignment
            policy.

        (3) An IPv4 site can also obtain a large space of IPv6
            address.

    In this memo, the word "translator" is used as an intermediate
    component between an IPv4 host and an IPv6 host to enable direct
    communication between them, without requiring any modifications to
    them according to the assumption (1) above.

    This memo is organized as follows: Three translation techniques are
    described in Section 2. Address mapping between IPv4 and IPv6 is
    discussed in Section 3.

    Both SIIT[SIIT] and SOCKS[SOCKS] are a kind of translator between
    IPv4 and IPv6. This memo, however, does not cover such
    technologies because they require specific modifications to IPv4
    and/or IPv6 hosts. BIS[BIS] is a technology to make an IPv4 host
    be dual-stack. So, BIS is outside the scope of this memo.

2. Translation Techniques of IPv4 and IPv6

    For translation between IPv4 and IPv6, three technologies are
    available: header conversion, transport relay, and application
    level gateway(ALG).

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. (Note that
    NAT[NAT] is an IPv4-to-IPv4 header converter.)

    The procedure to translate IPv4 packets to IPv6 packets, or vice
    versa, is defined as a part of SIIT. NATPT[NATPT] (excluding its
    ALG portion) is an example this kind of translator, which is based
    on SIIT. (Note that generic concerns about header translation were
    originally raised in [IPNGWP]. )

    Header conversion could be 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].




Yamamoto                                                        [Page 2]


Internet-Draft             IPv4/IPv6 translators              March 2000


    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. Also
    not all the semantics of ICMP[ICMP] and that of ICMPv6[ICMPv6] are
    inter-changeable. However, the latter problem is believed minor in
    practical cases.

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 with the source host. Then the server also makes one
    more TCP connection to the real destination. When two connections
    are established, the server reads data from one of the two
    connections and writes the data to the other.

    Transport relay does not have problems like fragmentation or ICMP
    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 Level Gateway (ALG)

    An ALG for a transaction service is used to hide site information
    and improve service performance with a cache mechanism. An ALG 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 ALGs for each
    service must be capable of running over both IPv4 and IPv6

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 translation 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 ALG is free
    of this problem.




Yamamoto                                                        [Page 3]


Internet-Draft             IPv4/IPv6 translators              March 2000

    In the case that address mapping is dynamic, it must be
    implemented in interaction with DNS. 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.  However, this
    violates the assumption (1). So, it is recommended that DNS is
    used for address mapping even in the static case.

    Examples:

        An example of static mapping: suppose that an application tries
        resolving AAAA/A6[A6] records against a host name. A DNS server
        receives this query but it can resolve only A record. In this
        case, the server converts them to AAAA/A6 records embedding them
        into the pre-configured prefix. Then it returns these records to
        the application. ([NATPT] also discusses this mechanism.)

        An example of dynamic mapping: if a DNS server receives a
        request to return A records for a host name, but only an AAAA/A6
        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 a connection initiating
    host and a 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 transport relay is used for translation, 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.


















Yamamoto                                                        [Page 4]


Internet-Draft             IPv4/IPv6 translators              March 2000


3.1. Translator Categories

    This memo categorizes IPv4/IPv6 translators from the address mapping
    point of view. The first picture illustrates the Internet in the
    early stage of the migration. The second one does that in the late
    stage.

                           In the early stage

                                       +----------------------+
        +-------------+  Translator A  |                      |
        |             |--------------->|                      |
        |  IPv6 site  |                |  The IPv4 Internet   |
        |             |<---------------|                      |
        +-------------+  Translator B  |                      |
                                       +----------------------+

                           In the late stage

                                       +----------------------+
        +-------------+  Translator C  |                      |
        |             |--------------->|                      |
        |  IPv4 site  |                |  The IPv6 Internet   |
        |             |<---------------|                      |
        +-------------+  Translator D  |                      |
                                       +----------------------+

    For simplicity, IPv4/IPv6 translators are categorized into four
    types. Note that practical translation stories could be combination
    of these four types.

        Translator A: It is used in the early stage of transition to
            establish a connection from an IPv6 host in an IPv6 site
            to an IPv4 host in the IPv4 Internet.

        Translator B: It is used in the early stage of transition to
            establish a connection from an IPv4 host in the IPv4 Internet
            to an IPv6 host in an IPv6 site.

        Translator C: It is used in the late stage of transition to
            establish a connection from an IPv4 host in an IPv4 site
            to an IPv6 host in the IPv6 Internet.

        Translator D: It is used in the late stage of transition to
            establish a connection from an IPv6 host in the IPv6 Internet
            to an IPv4 host in an IPv4 site.








Yamamoto                                                        [Page 5]


Internet-Draft             IPv4/IPv6 translators              March 2000

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
        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 Internet
        Implementation: very hard
        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 Internet or to use 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.

Security Consideration

    When one or more IPv4/IPv6 translators are used in the intermediate
    path of an IPv4 host and an IPv6 host, end-to-end authentication
    mechanisms based on IPv4 and/or IPv6 address (including
    IPsec[IPsec]) is not available. This problem is well-known in the
    case of NAT.




Yamamoto                                                        [Page 6]


Internet-Draft             IPv4/IPv6 translators              March 2000

References

    [A6] M. Crawford, C. Huitema and S. Thomson, "DNS Extensions to
        Support IP Version 6", <draft-ietf-ipngwg-dns-lookups-06.txt>,
        1999

    [BIS] K. Tsuchiya, H. Higuchi and Y. Atarashi, "Dual Stack Hosts
        using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, 2000.

    [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.

    [INET] K. Yamamoto, A. Kato, M Sumikawa, and J. Murai, "Deployment
        and Experiences of WIDE 6bone", in Proceedings of INET98, 1998.

    [IPNGWP] B. Carpenter, "IPng White Paper on Transition and Other
        Considerations", RFC 1671, 1994.

    [IPsec] S. Kent and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, 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)", RFC 2766, 2000.

    [SIIT] E. Nordmark, "Stateless IP/ICMP Translator (SIIT)",
        RFC 2765, 2000.

    [SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and
        L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1996.

Acknowledgements

    The authors would like to thank many people for their contributions
    to this memo, especially Rundy Bush, Brian Carpenter, Shin-ichi
    Fujisawa, Jun-ichiro Ito, Akira Jinzaki, Akira Kato, Atsushi Onoe,
    Kazushi Sugyo, and Shigeya Suzuki (in alphabetical order).




Yamamoto                                                        [Page 7]


Internet-Draft             IPv4/IPv6 translators              March 2000



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.
    1 Horiyamashita, Hadano city, Kanagawa
    259-1392 JAPAN

    Phone: +81-463-88-1311
    FAX:   +81-463-88-8062
    EMail: sumikawa@ebina.hitachi.co.jp

Changes

    From 02 to 03:
        - The title changed from "Categorizing Translators between IPv4
            and IPv6" to "Overview of Transition Techniques for
            IPv6-only to Talk to IPv4-only Communication".
        - The word "translator" is explicitly defined.
        - Even in the case of static mapping, DNS is recommended for the
            address mapping.
        - Both SIIT and SOCKS are now outside of the scope.
        - The assumption (1) is changed: IPv6 hosts cannot be modified,
            either.
        - Updating references
        - Sumikawa's address is changed.

    From 01 to 02:
        - Updating references
        - Refering RFC 1671
        - Adding the case of A6 records
        - Adding security consideration

    From 00 to 01:
        - Updating references
        - Refering to NATPT
        - Replacing TCP relay with transport relay to generalize
        - Clarify that the library extensions can be used only for
          Translator A.






Yamamoto                                                        [Page 8]


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