idnits 2.17.1 draft-kitamura-socks-ipv6-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-24) 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 ([SOCKSv5], [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 (6 August 1998) is 9393 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) == Unused Reference: 'IPv6' is defined on line 384, 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. 'SOCKSv5' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 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 6 August 1998 6 SOCKSv5 Protocol Extensions for IPv6/IPv4 Communication Environment 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 three types of extensions of SOCKS Version 5 30 protocol [RFC1928]. A new address type and a new command for Requests 31 and Replies are introduced. These extensions supplement the 32 insufficient generic functions of the SOCKSv5 protocol. 34 These extensions are basically designed to support IPv6 based 35 efficient communication environment. In addition, they make both IPv4 36 and IPv6 based communications efficient. Also, they enable a SOCKS 37 server to be used as a translator between IPv4 and IPv6 based 38 communications with ease. 40 Introduction 42 The SOCKS Version 5 protocol [RFC1928] can deal with IPv6 address 43 type. Only with this specification, however, it is insufficient to 44 support IPv6 based efficient communication environment. Especially, 45 it is difficult to support IPv4 and IPv6 mixed communication 46 environment and to use a SOCKS server as a translator between IPv4 47 and IPv6 based communications. 49 In this document, three types of extensions of SOCKSv5 protocol are 50 described. A new address type notion and a new command for Requests 51 and Replies are introduced as the extensions. 53 These extensions are basically designed to support IPv6 based 54 efficient communication environment. In addition, the existing IPv4 55 based communications also become efficient with these extensions. 56 Because they supplement the insufficient generic functions of the 57 SOCKSv5 protocol. 59 Extension 61 * Extension 1 (New address type notion) 63 As a new address type (ATYP) notion, "ADDRESS ID" is introduced. 64 This extension is closely related with Extension 2 (New command), 65 which is described below. 67 An ADDRESS ID is an identifier that represents an entry of the 68 address association mapping table between a SOCKS client and a SOCKS 69 server. Typically, the ADDRESS ID represents the servers' internal 70 address association table identifier. 72 Internal ADDRESS ID Format 73 +-----+-----------+ 74 |CLASS|REALID(key)| 75 +-----+-----------+ 76 | 1 | 3 | 77 +-----+-----------+ 79 An ADDRESS ID occupies 4 octets. Internally, the first octet is used 80 for a CLASS. The CLASS indicates categories and characteristics of 81 the ADDRESS ID. For the time being, it is reserved and filled with 82 zero. The rest octets are used for the real identifier (REALID) of 83 the ADDRESS ID. 85 Since the ADDRESS ID dose not include explicit address information, 86 there are potential vulnerabilities. If some SOCKS clients use the 87 same ADDRESS ID that is already used, the SOCKS server may cause 88 confusion. (It depends on implementation methods of the SOCKS.) Most 89 of the vulnerabilities can be avoided by the difference of the SOCKS 90 clients' IP addresses, but they still exist for the processes at the 91 same host. 93 In order to avoid such potential problems and to enhance the 94 security of the system, a simple key exchange mechanism is 95 introduced. The SOCKS server provides a REALID as a key to the SOCKS 96 client. It means that the REALID works as both a identifier and a 97 key. A series of the provided REALIDs by the SOCKS server are not 98 simple sequential numbers. The randomness of the REALIDs avoids the 99 vulnerabilities. 3 octets are long enough to realize this mechanism, 100 and long enough to support the number of the addresses to be dealt 101 between the client and the server. 103 The length of the ADDRESS ID is fixed and shorter than other address 104 types that are specified in the current SOCKSv5 protocol, and the 105 ADDRESS ID shows essential information between the client and the 106 server. So, the introduction of the ADDRESS ID address type makes 107 efficient communications via the SOCKS server. Especially, in case of 108 UDP communications via the SOCKS server, the utilization of the 109 ADDRESS ID address type contributes to shorten the length of the UDP 110 Packet Structure header and to make the filtering procedure 111 efficient. 113 Since the introduction of the ADDRESS ID conceals the address family 114 types, it becomes easy to enable to relay different address based 115 connections (e.g., between IPv4 and IPv6) at the SOCKS server. 117 * Extension 2 (New command for Requests and Replies) 119 As a new command (CMD), "ADDRESS ASSOCIATE" is introduced. This 120 extension is closely related with Extension 1 (New address type 121 notion). 123 This command is prepared for a SOCKS client to get a ADDRESS ID from 124 a SOCKS server. Followings are the procedure to get the ADDRESS ID. 125 1. A SOCKS client sends a Request filled with the ADDRESS ASSOCIATE 126 command to a SOCKS server. 127 2. The server sends a Reply filled with the ADDRESS ID information 128 to the BND.ADDR field. 130 After the procedure is finished successfully, the client can use the 131 received ADDRESS ID to any ADDR fields instead of other address types 132 (IP V4 address, DOMAINNAME, or IP V6 address) for the Requests and 133 the UDP Packet Structure header. 135 With this extension, the client's DNS query delegation to the server 137 can be accomplished explicitly in the SOCKS protocol. 139 An ADDRESS ASSOCIATE command has different characteristics from 140 other commands. It can be executed as a dedicated command, but also, 141 it is possible to execute the ADDRESS ASSOCIATE command with other 142 commands (CONNECT, BIND, or UDP ASSOCIATE) simultaneously under the 143 special conditions that the client does not require explicit BND.ADDR 144 information from the Replies. With the simultaneous commands 145 execution can reduce the handshake times between the SOCKS client and 146 the server. In order to realize this function, the ADDRESS ASSOCIATE 147 command needs to be assigned to an appropriate bit of the CMD field 148 of the Requests. 150 In case an ADDRESS ASSOCIATE command is executed with other command 151 simultaneously, the meanings of the REP field of the Replies may 152 become unclear, and the client can not get explicit BND.ADDR 153 information from the Replies, because BND.ADDR field is filled with 154 ADDRESS ID information. (BND.PORT field is filled with normal 155 information.) In case confusion may happen, an orthodox method that 156 the each command is executed as one dedicated function must be taken. 157 Only when the client does not need BND.ADDR information and the 158 meanings of the REP field is clear, this simultaneous commands 159 execution can be taken. 161 In case of the dedicated ADDRESS ASSOCIATE command Requests, 162 DST.PORT field does not make sense. The meanings of this field is 163 changed and reused. The name of it is changed to ADR.PREF. It shows 164 the preference of the reply address type of the client. In the 165 Extension 3 (Show the preference of the reply address type), the 166 details of this specification are described. 168 * Extension 3 (Show the preference of the reply address type) 170 In case the SOCKS server relays different address based connections 171 (e.g., between IPv4 and IPv6), the address type (ATYP) and the bound 172 address (BND.ADDR) of the Replies are important. If the client can 173 not deal with the replied address type, it causes confusion in the 174 client. 176 In order to avoid this confusion, the client needs to show the 177 preference of the reply address type to the server. There are three 178 methods to realize this feature. 180 1. Do nothing special 182 The client shows nothing special to the server and expects a 183 default reply address type that can be associated naturally. It 184 means to expect the same address (family) type that is used for 185 the connection between the client and the server. In this 186 method, the client dose not care which address family type is 187 used in the connection between the server and the desired 188 destination. 190 2. Use FLAG field of the Requests 192 The client shows the reply address type preference by setting 193 the flag field FLAG of the Requests. An appropriate bit of the 194 FLAG field shows off or on of the preference of the client. 195 If the appropriate bit is off (0), it is the same case of the 196 "Do nothing special." Default address type is replied. 197 If the appropriate bit is on (1), the client asks the server to 198 reply the address as the same address (family) type that is used 199 in the connection between the server and the desired 200 destination. In this case, the client must deal with all of the 201 expected address family types. 203 3. Use DST.PORT field of the dedicated ADDRESS ASSOCIATE Requests 205 In case of the dedicated ADDRESS ASSOCIATE Requests, the name 206 of the DST.PORT field is changed to ADR.PREF, and it shows the 207 preference of the reply address type. 208 Since the ADR.PREF has 2 octets, it has a possibility to show 209 complex preference. For the time being, the upper octet of the 210 ADR.PREF is reserved. The lower octet is used to show the show 211 the preference. The format is the same to the ATYP field. 212 (As an additional function, this mechanism enables the client 213 to realize the deligation of the reverse DNS query, also.) 214 The appropriate bit of the FLAG has a high priority and can 215 overwrite the preference that is shown by the ADR.PREF field. 217 Formats 219 In the following sections, the formats that include the described 220 extensions are shown. Most parts are quoted from the [RFC1928] and 221 the current SOCKS version 5 specification [SOCKSv5]. Since [RFC1928] 222 and [SOCKSv5] explain the meanings of the fields except extensions 223 that are described in this document, they are omitted here. 225 x marks (instead of o marks) indicate extensions. 227 Note: 229 Unless otherwise noted, the decimal numbers appearing in packet- 230 format diagrams represent the length of the corresponding field, in 231 octets. Where a given octet must take on a specific value, the 232 syntax X'hh' is used to denote the value of the single octet in that 233 field. When the word 'Variable' is used, it indicates that the 234 corresponding field has a variable length defined either by an 235 associated (one or two octet) length field, or by a data type field. 237 Requests Format 239 +----+-----+------+------+----------+----------+ 240 |VER | CMD | FLAG | ATYP | DST.ADDR | DST.PORT | 241 +----+-----+------+------+----------+----------+ 242 | 1 | 1 | 1 | 1 | Variable | 2 | 243 +----+-----+------+------+----------+----------+ 245 o VER protocol version: X'05' 246 o CMD 247 o CONNECT X'01' 248 o BIND X'02' 249 o UDP ASSOCIATE X'03' 250 x ADDRESS ASSOCIATE X'08' (bit set) 251 x CONNECT 252 +ADDRESS ASSOCIATE X'09' 253 x BIND 254 +ADDRESS ASSOCIATE X'0A' 255 x UDP ASSOCIATE 256 +ADDRESS ASSOCIATE X'0B' 257 o X'10' to X'7F' IANA ASSIGNED 258 o X'80' to X'FF' RESERVED FOR PRIVATE METHODS 259 o FLAG command dependent flag (defaults to X'00') 260 x Prefer Default address family type 261 X'00' (off) 262 x Prefer address family type of the Destination 263 X'08' (on) 264 o ATYP address type of following address 265 o IP V4 address: X'01' 266 o DOMAINNAME: X'03' 267 o IP V6 address: X'04' 268 x ADDRESS ID: X'08' 269 o DST.ADDR desired destination address 270 o DST.PORT desired destination port in network octet 271 order 273 In case of the dedicated ADDRESS ASSOCIATE Requests: 274 x DST.PORT => ADR.PREF 275 show the preference of the reply address type. 276 X'00'(reserved)+ ATYP 277 x IP V4 address: X'01' 278 x DOMAINNAME: X'03' 279 x IP V6 address: X'04' 281 Addressing Format 283 In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies 284 the type of address contained within the field: 286 o X'01' 288 the address is a version-4 IP address, with a length of 4 octets 290 o X'03' 292 the address field contains a fully-qualified domain name. The first 293 octet of the address field contains the number of octets of name that 294 follow, there is no terminating NUL octet. 296 o X'04' 298 the address is a version-6 IP address, with a length of 16 octets. 300 x X'08' 302 the address is a identifier of the servers' internal address 303 association table, with a length of 1 octet. 305 Replies Format 307 +----+-----+------+------+----------+----------+ 308 |VER | REP | FLAG | ATYP | BND.ADDR | BND.PORT | 309 +----+-----+------+------+----------+----------+ 310 | 1 | 1 | 1 | 1 | Variable | 2 | 311 +----+-----+------+------+----------+----------+ 313 o VER protocol version: X'05' 314 o REP Reply field: 315 o X'00' succeeded 316 o X'01' general SOCKS server failure 317 o X'02' connection not allowed by ruleset 318 o X'03' Network unreachable 319 o X'04' Host unreachable 320 o X'05' Connection refused 321 o X'06' TTL expired 322 o X'07' Command not supported 323 o X'08' Address type not supported 324 o X'09' Invalid address 325 o X'0A' to X'FF' unassigned 326 o FLAG command dependent flag 327 o ATYP address type of following address 328 o IP V4 address: X'01' 329 o DOMAINNAME: X'03' 330 o IP V6 address: X'04' 331 x ADDRESS ID: X'08' 332 o BND.ADDR server bound address 333 o BND.PORT server bound port in network octet order 335 UDP Control Channel Requests Format 337 +----+-----+------+------+----------+------+ 338 |RSV | SUB | FLAG | ATYP | ADDR | PORT | 339 +----+-----+------+------+----------+------+ 340 | 1 | 1 | 1 | 1 | Variable | 2 | 341 +----+-----+------+------+----------+------+ 343 o RSV Reserved X'00' 344 o SUB Subcommand 345 o INTERFACE DATA: X'01' 346 o FLAG A subcommand dependent flag (normally X'00') 347 o ATYP address type of following address 348 o IP V4 address: X'01' 349 o DOMAINNAME: X'03' 350 o IP V6 address: X'04' 351 x ADDRESS ID: X'08' 352 o ADDR destination address information 353 o PORT destination port information 355 UDP Packet Structure Format 357 +------+------+------+----------+----------+----------+ 358 | FLAG | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | 359 +------+------+------+----------+----------+----------+ 360 | 2 | 1 | 1 | Variable | 2 | Variable | 361 +------+------+------+----------+----------+----------+ 363 The fields in the UDP request header are: 365 o FLAG Reserved X'0000' 366 o FRAG Current fragment number 367 o ATYP address type of following address 368 o IP V4 address: X'01' 369 o DOMAINNAME: X'03' 370 o IP V6 address: X'04' 371 x ADDRESS ID: X'08' 372 o DST.ADDR desired destination address 373 o DST.PORT desired destination port 374 o DATA user data 376 References 378 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R. Koblas, D., & 379 Jones, L., "SOCKS Protocol V5," April 1996. 381 [SOCKSv5] VanHeyningen, M, "SOCKS Protocol Version 5," June 1998 382 currently draft-ietf-aft-socks-pro-v5-03.txt 384 [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 385 (IPv6) Specification", 386 currently draft-ietf-ipngwg-ipv6-spec-v2-01.txt. 388 Author's Address 390 Hiroshi Kitamura 391 NEC Corporation 392 C&C Media Research Laboratories 393 1-1, Miyazaki, 4-Chome, Miyamae-ku, 394 Kawasaki, Kanagawa, 216-8555, JAPAN 396 Phone: +81 (44) 856-2121 397 Fax: +81 (44) 856-2229 398 EMail: kitamura@ccm.cl.nec.co.jp