[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                             H. Kitamura
<draft-kitamura-socks-ipv6-trans-arch-00.txt>          NEC Corporation
Expires in six months                                 16 November 1998

            A SOCKS-based IPv6/IPv4 Translator Architecture
             <draft-kitamura-socks-ipv6-trans-arch-00.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
   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 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 document describes an IPv6/IPv4 Translator architecture that is
   based on the SOCKSv5 [RFC1928] mechanism. In this architecture, the
   SOCKS mechanism is extended by adding adaptive address family
   distinguish functions for supporting heterogeneous communications. By
   applying the mechanism together with protocol conversion functions,
   the IPv6/IPv4 Translator architecture is accomplished. This
   Translator provides communications between IPv6 and IPv4 nodes
   without sacrificing any convenience and functionalities of current
   communication methods. It is NOT necessary to modify the current DNS
   system at all. Only socksify environment is needed to communicate
   between IPv6 and IPv4 nodes.

   By using multiple chained Translators, a tunneling-like communication
   topology can be realized. With the architecture, there is no
   vulnerability of the packet fragmentation, and the connection can be
   authenticated by the native SOCKS authentication methods.







H. Kitamura                                                    [Page 1]

INTERNET-DRAFT      IPv6/IPv4 Translator Architecture      November 1998


1. Introduction

   This document describes an IPv6/IPv4 Translator architecture that is
   based on the SOCKSv5 [RFC1928] mechanism. By extending the SOCKS
   mechanism for supporting heterogeneous communications, the IPv6/IPv4
   Translator architecture is accomplished.

   The SOCKSv5 protocol is originally designed for an application level
   firewall system. With the SOCKS, a connection initiated by the client
   to the desired destination is replaced with two connections, and the
   SOCKS server relays these two connections internally.

   The SOCKS library is provided to the client node. Since the SOCKS
   library can replace the socket APIs and DNS name resolving APIs
   dynamically, the application on the client just feels that there is
   one normal direct connection to the desired destination. With this
   mechanism, the client application can keep the convenience and usage
   of current communication methods.

   The current SOCKS implementation relays connections between IPv4
   nodes only. By applying to relay connections between IPv6 and IPv4
   nodes, the IPv6/IPv4 Translator architecture is established.  Since
   the SOCKS mechanism has capabilities to replace the client's socket
   APIs and DNS name resolving APIs (e.g., gethostbyname() etc.), this
   Translator architecture can provides good characteristics (e.g., no
   DNS modification, no address mapper etc.). With this architecture,
   IPv6 nodes and IPv4 nodes can communicate each other smoothly without
   difficulties.

2. Basic Translator Mechanism

   Fig. 1 shows the basic translator mechanism.

   In this figure, the Client C initiates the communication to the
   Destination D. Two new functional blocks are introduced as the normal
   SOCKS mechanism does, and they compose the Translator architecture.

   One is *SOCKS Lib*. The other is *Translator*.

   *SOCKS Lib* is introduced into the client side (Client C) (this
   procedure is called "socksify"). It replaces the client's socket APIs
   and DNS name resolving APIs (e.g., gethostbyname(), getaddrinfo()
   etc.).

   *Translator* is an extended SOCKS server. It must be run on the IPv6
   and IPv4 dual stack node (Translator T). It relays connections
   between various combinations of IPvX and IPvY nodes (Client C and
   Destination D).



H. Kitamura                                                    [Page 2]

INTERNET-DRAFT      IPv6/IPv4 Translator Architecture      November 1998


                  Client C     Translator T    Destination D
               +-----------+     (Server)
               |Application|
           +-->+===========+  +-------------+  +-----------+
      same-+   |*SOCKS Lib*|  |*Translator* |  |Application|
       API +-->+===========+  +=====---=====+  +-----------+
               | Socket DNS|  | Socket  DNS |  | Socket DNS|
               +-----------+  +-------------+  +-----------+
               | [ IPv X ] |  |[IPvX]|(IPvY)|  | ( IPv Y ) |
               +-----------+  +-------------+  +-----------+
               |Network I/F|  | Network I/F |  |Network I/F|
               +-----+-----+  +---+-----+---+  +-----+-----+
                     |            |     |            |
                     +============+     +------------+
                       socksified           normal
                       connection         connection
                      (ctrl)+data          data only

                     Fig. 1 Basic Translator Mechanism


   The following 4 types of combinations of IPvX and IPvY are possible.

    type C ------ T ------ D
           [IPvX]   (IPvY)
     A      IPv4     IPv4       homogeneous (normal SOCKS)
     B      IPv4     IPv6     * heterogeneous *
     C      IPv6     IPv4     * heterogeneous *
     D      IPv6     IPv6       homogeneous


   Type A is supported by the current SOCKS mechanism.  Type B and C
   provide heterogeneous communication topologies. They are main targets
   for the Translator architecture. Type D can be supported by the
   natural extension of the SOCKS mechanism, because it is a homogeneous
   communication topology.

   *SOCKS Lib* communicates with *Translator* by the SOCKSv5 protocol
   [SOCKS5] and the SOCKSv5 extended protocol [SOCKS5EXT].

   The connection between the Client C and the Translator T is a
   socksified connection. It can transfer not only data but also control
   information (e.g. location information of the Destination etc.).

   The connection between the Translator T and the Destination D is a
   normal connection.  It is not necessary to modify (socksify) the
   application on Destination D.




H. Kitamura                                                    [Page 3]

INTERNET-DRAFT      IPv6/IPv4 Translator Architecture      November 1998


3. DNS Name Resolving Procedure

   As [TRANSMECH] mentioned, the DNS is important for a translator
   mechanism. Because information which address family (IPv4 only, IPv6
   only, or both IPv6 and IPv4) is used at a destination node is
   provided by the DNS.

   NAT-based translator mechanisms (e.g., [NATPT]) are struggling to
   deal with DNS issues. Their approaches require to modify the DNS
   mechanism.

   The SOCKS-based Translator architecture can deal with the DNS
   information effectively, and it does NOT require to modify the DNS
   mechanism.

   In this section, a DNS name resolving procedure in the Translator
   architecture is described.  As a typical example, type B combination
   case (Client is IPv4 node, Destination is IPv6 node) is explained.

   This procedure explains how the DNS name resolving problem (DNS query
   of AAAA record for IPv4 node) is solved and how the address mapping
   is created.

   1. An application in the Client C calls DNS name resolving function
   (e.g., gethostbyname2()). The logical host name FQDN of the
   Destination D exist in the argument of the function.

   2. Since the *SOCKS Lib* has replaced gethostbyname2(), the real
   gethostbyname2() function is not called. The argument information
   which includes FQDN is recorded and saved at the *SOCKS Lib*.

   3. The *SOCKS Lib* selects a fake address from reserved fake address
   space, and replies it to the application. The fake address must be
   suitable. Namely, it belongs to the same address family of the Client
   node. (In this case, it is an IPv4 fake address.)

   4. The *SOCKS Lib* creates an entry of the argued FQDN and the
   selected fake address in the mapping table.

   5. The application receives the fake address from the *SOCKS Lib* as
   a reply.

   6. The application calls a socket function (e.g., connect()). The
   received fake address information is used as an element of the argued
   socket.

   7. Since the *SOCKS Lib* has replaced such a socket function, the
   real socket function is not called.



H. Kitamura                                                    [Page 4]

INTERNET-DRAFT      IPv6/IPv4 Translator Architecture      November 1998


   8. The address information of the argued socket is checked. If the
   address belongs to the fake address space, the matched FQDN
   information of the fake address is picked up from the mapping table.

   9. The matched FQDN information is transferred to the *Translator* by
   using the SOCKS command that is matched to the called socket
   function.  (In case of connect(), the CONNECT command is used.)

   10. Finally, the *Translator* receives FQDN information of the
   destination from the *SOCKS Lib* and calls the real DNS name
   resolving function (e.g., gethostbyname2()).


   * DNS Name Resolving Delegation

   The above mechanism resolves the DNS name resolving problems, because
   the real DNS name resolving function is called at the IPv6 and IPv4
   dual stack node (Translator T).

   Also, an implementation of the IPv4-mapped IPv6 address is NOT
   indispensable at the Translator T, because the IPv4-mapped IPv6
   address is not necessary in this mechanism.

   This mechanism is called "DNS name resolving delegation". It has
   already implemented in the SOCKSv5 implementation.

   With this mechanism, smooth communications between IPv6 and IPv4
   nodes are realized.

   If the Destination D has both AAAA record and A record, the procedure
   becomes a little bit complex. The Client C has to show the preference
   which address family must be use between the Translator T and the
   Destination D. [SOCKS5EXT] has considered this case, and extensions
   of the SOCKSv5 protocol are proposed.


   * Address Mapping

   Compulsory to say, an address mapping is occurred at the *SOCKS Lib*
   by creating a mapping table entry of the combination of the selected
   fake address and the FQDN of the Destination D.

   Since the mapping table is created on each application, it is local
   and independent from others. This means that is not necessary to
   reserve global and wide address space for the address mapping. Only
   local and small fake address space is needed. This prevents the
   scalability problem.




H. Kitamura                                                    [Page 5]

INTERNET-DRAFT      IPv6/IPv4 Translator Architecture      November 1998


4. Multiple Chained Relay Mechanism


   The SOCKS mechanism can provide more advanced communication
   topologies. It is called "Multiple Chained Relay".

   Fig. 2 shows the multiple chained relay mechanism.

        Client C     Translator T1    Translator T2   Destination D
     +-----------+     (Server 1)       (Server 2)
     |Application|
     +===========+  +-------------+  +-------------+  +-----------+
     |*SOCKS Lib*|  |*Translator1*|  |*Translator2*|  |Application|
     +===========+  +=====---=====+  +=====---=====+  +-----------+
     | Socket DNS|  | Socket  DNS |  | Socket  DNS |  | Socket DNS|
     +-----------+  +-------------+  +-------------+  +-----------+
     | [ IPv X ] |  |[IPvX]|(IPvY)|  |(IPvY)|{IPvZ}|  | { IPv Z } |
     +-----------+  +-------------+  +-------------+  +-----------+
     |Network I/F|  | Network I/F |  | Network I/F |  |Network I/F|
     +-----+-----+  +---+-----+---+  +---+-----+---+  +-----+-----+
           |            |     |          |     |            |
           +============+     +==========+     +------------+
             socksified        socksified          normal
             connection        connection        connection
            (ctrl)+data       (ctrl)+data         data only

                  Fig. 2 Multiple Chained Relay Mechanism


   In this figure, the Client C initiates the communication with the
   Destination D. Underneath, the connection is replaced by 3
   connections, and they are relayed via the Translator T1 and T2.

   The *Translator* includes the same *SOCKS Lib* functionalities
   inside.  By enabling the *SOCKS Lib* functionalities at the
   *Translator1*, this topology is realized. When the Translator T1
   communicate with the Translator T2 by the SOCKS protocol, *SOCKS Lib*
   functionalities is used.

   There is no limitation of the times to relay. More than twice of
   internal relays are possible. To simplify to explain, twice relayed
   mechanism is explained in this section.

   There is no limitation on the number of relay (translation)
   operations between the Client C and the Destination D. It is possible
   to have more than two intermediate Translators. To simplify the
   discussion, a two-stage relayed mechanism is explained in this
   section.



H. Kitamura                                                    [Page 6]

INTERNET-DRAFT      IPv6/IPv4 Translator Architecture      November 1998


   The connection between the Client C and the Translator T1 and the
   connection between the Translator T1 and the Translator T2 are
   socksified connections. They can transfer not only data but also
   control information (e.g. location information of the Translator T2
   and the Destination etc.).

   The connection between the Translator T2 and the Destination D is a
   normal connection. It is not necessary to modify (socksify) the
   application on the Destination D.

   In this twice relayed topology, the following 8 types of combinations
   of IPvX, IPvY, and IPvZ are possible.

    type C ------ T1 ------ T2 ------ D
           [IPvX]    (IPvY)    {IPvZ}
     E      IPv4      IPv4      IPv4      homogeneous (normal SOCKS)
     F      IPv4      IPv4      IPv6    * heterogeneous *
     G      IPv4      IPv6      IPv4    * heterogeneous * (tunnel)
     H      IPv4      IPv6      IPv6    * heterogeneous *
     I      IPv6      IPv4      IPv4    * heterogeneous *
     J      IPv6      IPv4      IPv6    * heterogeneous * (tunnel)
     K      IPv6      IPv6      IPv4    * heterogeneous *
     L      IPv6      IPv6      IPv6      homogeneous

   Type A is supported by the current SOCKS mechanism. From type F to
   type K are heterogeneous communication topologies. They are main
   targets for the Translator architecture. Type L can be supported by
   the natural extension of the SOCKS mechanism, because it is a
   homogeneous communication topology.

   Type G and type J combinations are the most interesting cases. They
   provide similar topologies as the tunneling techniques. Since they
   are composed of real socket connections, they are efficient and do
   NOT suffer from the following problems that caused by tunneling
   techniques

   * Fragmentation vulnerability

     The tunneling technique uses the packet encapsulation mechanism.
     In the encapsulation mechanism, the length of the packet is
     increased because of the additional header. It may exceed the MTU
     of the network.  So, the tunneling technique has the vulnerability
     that the packet might be fragmented.

     In case of the SOCKS-based architecture, the size of the each
     relayed TCP packet is not changed, because the connections
     (sockets) are relayed at the application level. So, there is no
     fragmentation vulnerability.



H. Kitamura                                                    [Page 7]

INTERNET-DRAFT      IPv6/IPv4 Translator Architecture      November 1998


   * Hop limit (metric number) problem

     The tunneling technique creates one virtual connection over the
     dynamically routed and configured real networks.

     In spite of the hop limit (or metric number) of the based real
     networks is changed dynamically, the hop limit (or metric number)
     of the virtual connection can not reflect the appropriate value.
     This fact causes the effective problem.

     In case of the SOCKS-based architecture, all of the relayed
     connections are real. So, this type of the problem is never
     happened.



   In addition, the well-authenticated connections are provided. Because
   the SOCKS mechanism is originally designed for the firewall system,
   and it has various authentication methods.


5. Characteristics

   In this section, characteristics of the SOCKS-based Translator
   architecture are summarized.

   1. DNS modification is NOT necessary
      Address map servers are NOT necessary
      Global and wide reserved address space is NOT necessary

      Section "3. DNS Name Resolving Procedure", has explained these
      issues.

   2. Application independent

      If applications use the socket APIs and DNS name resolving APIs,
      they work properly in the SOCKS-based Translator architecture.

      There are exceptions, if applications exchange IP address
      information with peer applications (e.g., ftp PORT command), they
      do not work properly without special modification.

   3. OS and NIC types independent

      Since the *SOCKS Lib* and the *Translator* run as applications,
      the SOCKS-base Translator architecture runs on both UNIX and
      Windows OSs, and it dose not depend on types of physical NICs.




H. Kitamura                                                    [Page 8]

INTERNET-DRAFT      IPv6/IPv4 Translator Architecture      November 1998


   4. Only easy socksify procedure is necessary

      The socksification is not difficult, because the dynamic link
      library technique helps the socksification.

   5. IPv6 new features (e.g., IPSec) can be used

      Since two terminated connections are relayed internally, it is
      easy to enable new features that are introduced by IPv6 on one
      side IPv6 connection.

      In case of NAT-based translators, it is very difficult to realize
      this issue.

   6. Current existing client SOCKSv5 library can be used

      In case of the IPv4 -> IPv6 direction translation, the current
      existing client SOCKSv5 library that are basically designed for
      IPv4 -> IPv4 can be used without modification.

   7. Both TCP and UDP relay translations are possible.

      Since the SOCKSv5 protocol support both TCP and UDP relays, this
      architecture can translate not only TCP but also UDP relays.

   8. Both direction IPv6 <-/-> IPv4 translations are possible

      This architecture can realize not only IPv6 <- IPv4 translation
      but also IPv6 -> IPv4 translation with the same mechanism.

   9. Multiple chained relay is possible.

      Section "4. Multiple Chained Relay Mechanism", has explained this
      issues.

   10. Can support the applications that exchange IP address information
       at the application level.

      Basically, such applications can not be support by the Translator
      architecture. However, if such protocols are known like ftp, the
      Translator architecture can support them by introducing special
      protocol translation routines into the *Translator*.

      The *Translator* has the capability to introduce such protocol
      translation routines.






H. Kitamura                                                    [Page 9]

INTERNET-DRAFT      IPv6/IPv4 Translator Architecture      November 1998


6. Constraints

   The translation mechanism can not become almighty,  because IPv6 and
   IPv4 are different protocols.

   The SOCKS-based Translator architecture has following constraints.

   1. Essential constraint
      getpeername() and getsockname() functions can not provide correct
      IP address information.

      This is caused by the fact IPv6 and IPv4 are different protocols.

      However, appropriate port information can be provided by the
      SOCKSv5 protocol. Because IPv6 and IPv4 deal with the same size
      port space.

   2. Limitation of the SOCKS mechanism

      Current SOCKSv5 can not socksify all of tricky applications.

      This limitation also can be applied for the SOCKS-based Translator
      architecture.

   3. Fake address dealing constraint

      The fake address must be dealt as a temporary value in the
      application. It must not be recorded permanently.  After the
      application finished, the fake address information must be
      vanished.  Otherwise, problems will happen.

      Most of applications records FQDN and does not record DNS name
      resolved fake addresses. So, from the realistic viewpoint, this
      constraint is small.

















H. Kitamura                                                   [Page 10]

INTERNET-DRAFT      IPv6/IPv4 Translator Architecture      November 1998


References

   [RFC1928]   Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., &
                 Jones, L., "SOCKS Protocol V5," RFC1928, April 1996.

   [SOCKS5]    VanHeyningen, M, "SOCKS Protocol Version 5,"  June 1998
               currently draft-ietf-aft-socks-pro-v5-03.txt

   [SOCKS5EXT] H. Kitamura, "SOCKSv5 Protocol Extension for IPv6/IPv4
                 Communication Environment",
               currently draft-kitamura-socks-ipv6-00.txt

   [TRANSMECH] R. Gilligan and E. Nordmark, "Transition Mechanisms for
                 IPv6 Hosts and Routers", RFC 1933, April 1996.

   [NATPT]     G. Tsirtsis and P. Srishuresh, "Network Address
                 Translation - Protocol Translation (NAT-PT)",
               currently draft-ietf-ngtrans-natpt-02.txt

   [IPV6]      S. Deering, R. Hinden, "Internet Protocol, Version 6
                 (IPv6) Specification",
               currently draft-ietf-ipngwg-ipv6-spec-v2-01.txt

Author's Address

   Hiroshi Kitamura
   NEC Corporation
   C&C Media Research Laboratories
   1-1, Miyazaki, 4-Chome, Miyamae-ku,
   Kawasaki, Kanagawa, 216-8555, JAPAN

   Phone: +81 (44) 856-2123
   Fax:   +81 (44) 856-2230
   EMail: kitamura@ccm.cl.nec.co.jp

















H. Kitamura                                                   [Page 11]


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