One document matched: draft-kitamura-socks-ipv6-trans-arch-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 22:39:27 |