idnits 2.17.1 draft-kitamura-socks-ipv6-trans-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC1928]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (16 November 1998) is 9290 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPvX' is mentioned on line 297, but not defined == Unused Reference: 'IPV6' is defined on line 477, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-aft-socks-pro-v5-03 -- Possible downref: Normative reference to a draft: ref. 'SOCKS5' == Outdated reference: A later version (-01) exists of draft-kitamura-socks-ipv6-00 -- Possible downref: Normative reference to a draft: ref. 'SOCKS5EXT' ** Obsolete normative reference: RFC 1933 (ref. 'TRANSMECH') (Obsoleted by RFC 2893) == Outdated reference: A later version (-07) exists of draft-ietf-ngtrans-natpt-02 ** Downref: Normative reference to an Historic draft: draft-ietf-ngtrans-natpt (ref. 'NATPT') Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT H. Kitamura 3 NEC Corporation 4 Expires in six months 16 November 1998 6 A SOCKS-based IPv6/IPv4 Translator Architecture 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 This document describes an IPv6/IPv4 Translator architecture that is 30 based on the SOCKSv5 [RFC1928] mechanism. In this architecture, the 31 SOCKS mechanism is extended by adding adaptive address family 32 distinguish functions for supporting heterogeneous communications. By 33 applying the mechanism together with protocol conversion functions, 34 the IPv6/IPv4 Translator architecture is accomplished. This 35 Translator provides communications between IPv6 and IPv4 nodes 36 without sacrificing any convenience and functionalities of current 37 communication methods. It is NOT necessary to modify the current DNS 38 system at all. Only socksify environment is needed to communicate 39 between IPv6 and IPv4 nodes. 41 By using multiple chained Translators, a tunneling-like communication 42 topology can be realized. With the architecture, there is no 43 vulnerability of the packet fragmentation, and the connection can be 44 authenticated by the native SOCKS authentication methods. 46 1. Introduction 48 This document describes an IPv6/IPv4 Translator architecture that is 49 based on the SOCKSv5 [RFC1928] mechanism. By extending the SOCKS 50 mechanism for supporting heterogeneous communications, the IPv6/IPv4 51 Translator architecture is accomplished. 53 The SOCKSv5 protocol is originally designed for an application level 54 firewall system. With the SOCKS, a connection initiated by the client 55 to the desired destination is replaced with two connections, and the 56 SOCKS server relays these two connections internally. 58 The SOCKS library is provided to the client node. Since the SOCKS 59 library can replace the socket APIs and DNS name resolving APIs 60 dynamically, the application on the client just feels that there is 61 one normal direct connection to the desired destination. With this 62 mechanism, the client application can keep the convenience and usage 63 of current communication methods. 65 The current SOCKS implementation relays connections between IPv4 66 nodes only. By applying to relay connections between IPv6 and IPv4 67 nodes, the IPv6/IPv4 Translator architecture is established. Since 68 the SOCKS mechanism has capabilities to replace the client's socket 69 APIs and DNS name resolving APIs (e.g., gethostbyname() etc.), this 70 Translator architecture can provides good characteristics (e.g., no 71 DNS modification, no address mapper etc.). With this architecture, 72 IPv6 nodes and IPv4 nodes can communicate each other smoothly without 73 difficulties. 75 2. Basic Translator Mechanism 77 Fig. 1 shows the basic translator mechanism. 79 In this figure, the Client C initiates the communication to the 80 Destination D. Two new functional blocks are introduced as the normal 81 SOCKS mechanism does, and they compose the Translator architecture. 83 One is *SOCKS Lib*. The other is *Translator*. 85 *SOCKS Lib* is introduced into the client side (Client C) (this 86 procedure is called "socksify"). It replaces the client's socket APIs 87 and DNS name resolving APIs (e.g., gethostbyname(), getaddrinfo() 88 etc.). 90 *Translator* is an extended SOCKS server. It must be run on the IPv6 91 and IPv4 dual stack node (Translator T). It relays connections 92 between various combinations of IPvX and IPvY nodes (Client C and 93 Destination D). 95 Client C Translator T Destination D 96 +-----------+ (Server) 97 |Application| 98 +-->+===========+ +-------------+ +-----------+ 99 same-+ |*SOCKS Lib*| |*Translator* | |Application| 100 API +-->+===========+ +=====---=====+ +-----------+ 101 | Socket DNS| | Socket DNS | | Socket DNS| 102 +-----------+ +-------------+ +-----------+ 103 | [ IPv X ] | |[IPvX]|(IPvY)| | ( IPv Y ) | 104 +-----------+ +-------------+ +-----------+ 105 |Network I/F| | Network I/F | |Network I/F| 106 +-----+-----+ +---+-----+---+ +-----+-----+ 107 | | | | 108 +============+ +------------+ 109 socksified normal 110 connection connection 111 (ctrl)+data data only 113 Fig. 1 Basic Translator Mechanism 115 The following 4 types of combinations of IPvX and IPvY are possible. 117 type C ------ T ------ D 118 [IPvX] (IPvY) 119 A IPv4 IPv4 homogeneous (normal SOCKS) 120 B IPv4 IPv6 * heterogeneous * 121 C IPv6 IPv4 * heterogeneous * 122 D IPv6 IPv6 homogeneous 124 Type A is supported by the current SOCKS mechanism. Type B and C 125 provide heterogeneous communication topologies. They are main targets 126 for the Translator architecture. Type D can be supported by the 127 natural extension of the SOCKS mechanism, because it is a homogeneous 128 communication topology. 130 *SOCKS Lib* communicates with *Translator* by the SOCKSv5 protocol 131 [SOCKS5] and the SOCKSv5 extended protocol [SOCKS5EXT]. 133 The connection between the Client C and the Translator T is a 134 socksified connection. It can transfer not only data but also control 135 information (e.g. location information of the Destination etc.). 137 The connection between the Translator T and the Destination D is a 138 normal connection. It is not necessary to modify (socksify) the 139 application on Destination D. 141 3. DNS Name Resolving Procedure 143 As [TRANSMECH] mentioned, the DNS is important for a translator 144 mechanism. Because information which address family (IPv4 only, IPv6 145 only, or both IPv6 and IPv4) is used at a destination node is 146 provided by the DNS. 148 NAT-based translator mechanisms (e.g., [NATPT]) are struggling to 149 deal with DNS issues. Their approaches require to modify the DNS 150 mechanism. 152 The SOCKS-based Translator architecture can deal with the DNS 153 information effectively, and it does NOT require to modify the DNS 154 mechanism. 156 In this section, a DNS name resolving procedure in the Translator 157 architecture is described. As a typical example, type B combination 158 case (Client is IPv4 node, Destination is IPv6 node) is explained. 160 This procedure explains how the DNS name resolving problem (DNS query 161 of AAAA record for IPv4 node) is solved and how the address mapping 162 is created. 164 1. An application in the Client C calls DNS name resolving function 165 (e.g., gethostbyname2()). The logical host name FQDN of the 166 Destination D exist in the argument of the function. 168 2. Since the *SOCKS Lib* has replaced gethostbyname2(), the real 169 gethostbyname2() function is not called. The argument information 170 which includes FQDN is recorded and saved at the *SOCKS Lib*. 172 3. The *SOCKS Lib* selects a fake address from reserved fake address 173 space, and replies it to the application. The fake address must be 174 suitable. Namely, it belongs to the same address family of the Client 175 node. (In this case, it is an IPv4 fake address.) 177 4. The *SOCKS Lib* creates an entry of the argued FQDN and the 178 selected fake address in the mapping table. 180 5. The application receives the fake address from the *SOCKS Lib* as 181 a reply. 183 6. The application calls a socket function (e.g., connect()). The 184 received fake address information is used as an element of the argued 185 socket. 187 7. Since the *SOCKS Lib* has replaced such a socket function, the 188 real socket function is not called. 190 8. The address information of the argued socket is checked. If the 191 address belongs to the fake address space, the matched FQDN 192 information of the fake address is picked up from the mapping table. 194 9. The matched FQDN information is transferred to the *Translator* by 195 using the SOCKS command that is matched to the called socket 196 function. (In case of connect(), the CONNECT command is used.) 198 10. Finally, the *Translator* receives FQDN information of the 199 destination from the *SOCKS Lib* and calls the real DNS name 200 resolving function (e.g., gethostbyname2()). 202 * DNS Name Resolving Delegation 204 The above mechanism resolves the DNS name resolving problems, because 205 the real DNS name resolving function is called at the IPv6 and IPv4 206 dual stack node (Translator T). 208 Also, an implementation of the IPv4-mapped IPv6 address is NOT 209 indispensable at the Translator T, because the IPv4-mapped IPv6 210 address is not necessary in this mechanism. 212 This mechanism is called "DNS name resolving delegation". It has 213 already implemented in the SOCKSv5 implementation. 215 With this mechanism, smooth communications between IPv6 and IPv4 216 nodes are realized. 218 If the Destination D has both AAAA record and A record, the procedure 219 becomes a little bit complex. The Client C has to show the preference 220 which address family must be use between the Translator T and the 221 Destination D. [SOCKS5EXT] has considered this case, and extensions 222 of the SOCKSv5 protocol are proposed. 224 * Address Mapping 226 Compulsory to say, an address mapping is occurred at the *SOCKS Lib* 227 by creating a mapping table entry of the combination of the selected 228 fake address and the FQDN of the Destination D. 230 Since the mapping table is created on each application, it is local 231 and independent from others. This means that is not necessary to 232 reserve global and wide address space for the address mapping. Only 233 local and small fake address space is needed. This prevents the 234 scalability problem. 236 4. Multiple Chained Relay Mechanism 238 The SOCKS mechanism can provide more advanced communication 239 topologies. It is called "Multiple Chained Relay". 241 Fig. 2 shows the multiple chained relay mechanism. 243 Client C Translator T1 Translator T2 Destination D 244 +-----------+ (Server 1) (Server 2) 245 |Application| 246 +===========+ +-------------+ +-------------+ +-----------+ 247 |*SOCKS Lib*| |*Translator1*| |*Translator2*| |Application| 248 +===========+ +=====---=====+ +=====---=====+ +-----------+ 249 | Socket DNS| | Socket DNS | | Socket DNS | | Socket DNS| 250 +-----------+ +-------------+ +-------------+ +-----------+ 251 | [ IPv X ] | |[IPvX]|(IPvY)| |(IPvY)|{IPvZ}| | { IPv Z } | 252 +-----------+ +-------------+ +-------------+ +-----------+ 253 |Network I/F| | Network I/F | | Network I/F | |Network I/F| 254 +-----+-----+ +---+-----+---+ +---+-----+---+ +-----+-----+ 255 | | | | | | 256 +============+ +==========+ +------------+ 257 socksified socksified normal 258 connection connection connection 259 (ctrl)+data (ctrl)+data data only 261 Fig. 2 Multiple Chained Relay Mechanism 263 In this figure, the Client C initiates the communication with the 264 Destination D. Underneath, the connection is replaced by 3 265 connections, and they are relayed via the Translator T1 and T2. 267 The *Translator* includes the same *SOCKS Lib* functionalities 268 inside. By enabling the *SOCKS Lib* functionalities at the 269 *Translator1*, this topology is realized. When the Translator T1 270 communicate with the Translator T2 by the SOCKS protocol, *SOCKS Lib* 271 functionalities is used. 273 There is no limitation of the times to relay. More than twice of 274 internal relays are possible. To simplify to explain, twice relayed 275 mechanism is explained in this section. 277 There is no limitation on the number of relay (translation) 278 operations between the Client C and the Destination D. It is possible 279 to have more than two intermediate Translators. To simplify the 280 discussion, a two-stage relayed mechanism is explained in this 281 section. 283 The connection between the Client C and the Translator T1 and the 284 connection between the Translator T1 and the Translator T2 are 285 socksified connections. They can transfer not only data but also 286 control information (e.g. location information of the Translator T2 287 and the Destination etc.). 289 The connection between the Translator T2 and the Destination D is a 290 normal connection. It is not necessary to modify (socksify) the 291 application on the Destination D. 293 In this twice relayed topology, the following 8 types of combinations 294 of IPvX, IPvY, and IPvZ are possible. 296 type C ------ T1 ------ T2 ------ D 297 [IPvX] (IPvY) {IPvZ} 298 E IPv4 IPv4 IPv4 homogeneous (normal SOCKS) 299 F IPv4 IPv4 IPv6 * heterogeneous * 300 G IPv4 IPv6 IPv4 * heterogeneous * (tunnel) 301 H IPv4 IPv6 IPv6 * heterogeneous * 302 I IPv6 IPv4 IPv4 * heterogeneous * 303 J IPv6 IPv4 IPv6 * heterogeneous * (tunnel) 304 K IPv6 IPv6 IPv4 * heterogeneous * 305 L IPv6 IPv6 IPv6 homogeneous 307 Type A is supported by the current SOCKS mechanism. From type F to 308 type K are heterogeneous communication topologies. They are main 309 targets for the Translator architecture. Type L can be supported by 310 the natural extension of the SOCKS mechanism, because it is a 311 homogeneous communication topology. 313 Type G and type J combinations are the most interesting cases. They 314 provide similar topologies as the tunneling techniques. Since they 315 are composed of real socket connections, they are efficient and do 316 NOT suffer from the following problems that caused by tunneling 317 techniques 319 * Fragmentation vulnerability 321 The tunneling technique uses the packet encapsulation mechanism. 322 In the encapsulation mechanism, the length of the packet is 323 increased because of the additional header. It may exceed the MTU 324 of the network. So, the tunneling technique has the vulnerability 325 that the packet might be fragmented. 327 In case of the SOCKS-based architecture, the size of the each 328 relayed TCP packet is not changed, because the connections 329 (sockets) are relayed at the application level. So, there is no 330 fragmentation vulnerability. 332 * Hop limit (metric number) problem 334 The tunneling technique creates one virtual connection over the 335 dynamically routed and configured real networks. 337 In spite of the hop limit (or metric number) of the based real 338 networks is changed dynamically, the hop limit (or metric number) 339 of the virtual connection can not reflect the appropriate value. 340 This fact causes the effective problem. 342 In case of the SOCKS-based architecture, all of the relayed 343 connections are real. So, this type of the problem is never 344 happened. 346 In addition, the well-authenticated connections are provided. Because 347 the SOCKS mechanism is originally designed for the firewall system, 348 and it has various authentication methods. 350 5. Characteristics 352 In this section, characteristics of the SOCKS-based Translator 353 architecture are summarized. 355 1. DNS modification is NOT necessary 356 Address map servers are NOT necessary 357 Global and wide reserved address space is NOT necessary 359 Section "3. DNS Name Resolving Procedure", has explained these 360 issues. 362 2. Application independent 364 If applications use the socket APIs and DNS name resolving APIs, 365 they work properly in the SOCKS-based Translator architecture. 367 There are exceptions, if applications exchange IP address 368 information with peer applications (e.g., ftp PORT command), they 369 do not work properly without special modification. 371 3. OS and NIC types independent 373 Since the *SOCKS Lib* and the *Translator* run as applications, 374 the SOCKS-base Translator architecture runs on both UNIX and 375 Windows OSs, and it dose not depend on types of physical NICs. 377 4. Only easy socksify procedure is necessary 379 The socksification is not difficult, because the dynamic link 380 library technique helps the socksification. 382 5. IPv6 new features (e.g., IPSec) can be used 384 Since two terminated connections are relayed internally, it is 385 easy to enable new features that are introduced by IPv6 on one 386 side IPv6 connection. 388 In case of NAT-based translators, it is very difficult to realize 389 this issue. 391 6. Current existing client SOCKSv5 library can be used 393 In case of the IPv4 -> IPv6 direction translation, the current 394 existing client SOCKSv5 library that are basically designed for 395 IPv4 -> IPv4 can be used without modification. 397 7. Both TCP and UDP relay translations are possible. 399 Since the SOCKSv5 protocol support both TCP and UDP relays, this 400 architecture can translate not only TCP but also UDP relays. 402 8. Both direction IPv6 <-/-> IPv4 translations are possible 404 This architecture can realize not only IPv6 <- IPv4 translation 405 but also IPv6 -> IPv4 translation with the same mechanism. 407 9. Multiple chained relay is possible. 409 Section "4. Multiple Chained Relay Mechanism", has explained this 410 issues. 412 10. Can support the applications that exchange IP address information 413 at the application level. 415 Basically, such applications can not be support by the Translator 416 architecture. However, if such protocols are known like ftp, the 417 Translator architecture can support them by introducing special 418 protocol translation routines into the *Translator*. 420 The *Translator* has the capability to introduce such protocol 421 translation routines. 423 6. Constraints 425 The translation mechanism can not become almighty, because IPv6 and 426 IPv4 are different protocols. 428 The SOCKS-based Translator architecture has following constraints. 430 1. Essential constraint 431 getpeername() and getsockname() functions can not provide correct 432 IP address information. 434 This is caused by the fact IPv6 and IPv4 are different protocols. 436 However, appropriate port information can be provided by the 437 SOCKSv5 protocol. Because IPv6 and IPv4 deal with the same size 438 port space. 440 2. Limitation of the SOCKS mechanism 442 Current SOCKSv5 can not socksify all of tricky applications. 444 This limitation also can be applied for the SOCKS-based Translator 445 architecture. 447 3. Fake address dealing constraint 449 The fake address must be dealt as a temporary value in the 450 application. It must not be recorded permanently. After the 451 application finished, the fake address information must be 452 vanished. Otherwise, problems will happen. 454 Most of applications records FQDN and does not record DNS name 455 resolved fake addresses. So, from the realistic viewpoint, this 456 constraint is small. 458 References 460 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., & 461 Jones, L., "SOCKS Protocol V5," RFC1928, April 1996. 463 [SOCKS5] VanHeyningen, M, "SOCKS Protocol Version 5," June 1998 464 currently draft-ietf-aft-socks-pro-v5-03.txt 466 [SOCKS5EXT] H. Kitamura, "SOCKSv5 Protocol Extension for IPv6/IPv4 467 Communication Environment", 468 currently draft-kitamura-socks-ipv6-00.txt 470 [TRANSMECH] R. Gilligan and E. Nordmark, "Transition Mechanisms for 471 IPv6 Hosts and Routers", RFC 1933, April 1996. 473 [NATPT] G. Tsirtsis and P. Srishuresh, "Network Address 474 Translation - Protocol Translation (NAT-PT)", 475 currently draft-ietf-ngtrans-natpt-02.txt 477 [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 478 (IPv6) Specification", 479 currently draft-ietf-ipngwg-ipv6-spec-v2-01.txt 481 Author's Address 483 Hiroshi Kitamura 484 NEC Corporation 485 C&C Media Research Laboratories 486 1-1, Miyazaki, 4-Chome, Miyamae-ku, 487 Kawasaki, Kanagawa, 216-8555, JAPAN 489 Phone: +81 (44) 856-2123 490 Fax: +81 (44) 856-2230 491 EMail: kitamura@ccm.cl.nec.co.jp