idnits 2.17.1 

draft-kitamura-socks-ipv6-01.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  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 6 months
     document validity -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

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

  ** There are 23 instances of too long lines in the document, the longest
     one being 1 character in excess of 72.

  ** 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 (8 February 1999) is 9202 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 398, 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' 

  ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC
     8200)


     Summary: 8 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	 <draft-kitamura-socks-ipv6-01.txt                       NEC Corporation
4	 Expires in six months                                    8 February 1999

6	   SOCKSv5 Protocol Extensions for IPv6/IPv4 Communication Environment
7	                    <draft-kitamura-socks-ipv6-01.txt

9	 Status of this Memo

11	    This document is an Internet-Draft and is in full conformance with
12	    all provisions of Section 10 of RFC2026 except that the right to
13	    produce derivative works is not granted.

15	    Internet-Drafts are working documents of the Internet Engineering
16	    Task Force (IETF), its areas, and its working groups.  Note that
17	    other groups may also distribute working documents as Internet-
18	    Drafts.

20	    Internet-Drafts are draft documents valid for a maximum of six months
21	    and may be updated, replaced, or obsoleted by other documents at any
22	    time.  It is inappropriate to use Internet- Drafts as reference
23	    material or to cite them other than as "work in progress."

25	    The list of current Internet-Drafts can be accessed at
26	    http://www.ietf.org/ietf/1id-abstracts.txt

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

31	 Abstract

33	    This document describes three types of extensions of SOCKS Version 5
34	    protocol [RFC1928]. A new address type and a new command for Requests
35	    and Replies are introduced. These extensions supplement the
36	    insufficient generic functions of the SOCKSv5 protocol.

38	    These extensions enable a SOCKS server to be used as a translator for
39	    IPv4 and IPv6 mixed heteregenous communications with ease.  In
40	    addition, they make each homogeneous IPv4 and IPv6 communication
41	    efficient.

43	 Introduction

45	    The SOCKS Version 5 protocol [RFC1928] can deal with IPv6 address
46	    type. Only with this specification, however, it is insufficient to
47	    support IPv6 based efficient communication environment. Especially,
48	    it is difficult to support IPv4 and IPv6 mixed heterogeneous
49	    communication environment and to use a SOCKS server as a translator
50	    for mixed heterogeneous communication environment.

52	    In this document, three types of extensions of SOCKSv5 protocol are
53	    described. A new address type notion and a new command for Requests
54	    and Replies are introduced as the extensions.

56	    These extensions enable a SOCKS server to be used as a translator for
57	    IPv4 and IPv6 mixed heteregenous communications with ease.  In
58	    addition, they make each homogeneous IPv4 and IPv6 communication
59	    efficient. Because they supplement the insufficient generic functions
60	    of the SOCKSv5 protocol.

62	 Extension

64	    * Extension 1 (New address type notion)

66	     As a new address type (ATYP) notion, "ADDRESS ID" is introduced.
67	    This extension is closely related with Extension 2 (New command),
68	    which is described below.

70	     An ADDRESS ID is an identifier that represents an entry of the
71	    address association mapping table between a SOCKS client and a SOCKS
72	    server. Typically, the ADDRESS ID represents the servers' internal
73	    address association table identifier.

75	     Internal ADDRESS ID Format
76	         +-----+-----------+
77	         |CLASS|REALID(key)|
78	         +-----+-----------+
79	         |  1  |     3     |
80	         +-----+-----------+

82	     An ADDRESS ID occupies 4 octets. Internally, the first octet is used
83	    for a CLASS. The CLASS indicates categories and characteristics of
84	    the ADDRESS ID. For the time being, it is reserved and filled with
85	    zero. The rest octets are used for the real identifier (REALID) of
86	    the ADDRESS ID.

88	     Since the ADDRESS ID dose not include explicit address information,
89	    there are potential vulnerabilities. If some SOCKS clients use the
90	    same ADDRESS ID that is already used, the SOCKS server may cause
91	    confusion. (It depends on implementation methods of the SOCKS.) Most
92	    of the vulnerabilities can be avoided by the difference of the SOCKS
93	    clients' IP addresses, but they still exist for the processes at the
94	    same host.

96	     In order to avoid such potential problems and to enhance the
97	    security of the system, a simple key exchange mechanism is
98	    introduced. The SOCKS server provides a REALID as a key to the SOCKS
99	    client. It means that the REALID works as both a identifier and a
100	    key. A series of the provided REALIDs by the SOCKS server are not
101	    simple sequential numbers. The randomness of the REALIDs avoids the
102	    vulnerabilities. 3 octets are long enough to realize this mechanism,
103	    and long enough to support the number of the addresses to be dealt
104	    between the client and the server.

106	     The length of the ADDRESS ID is fixed and shorter than other address
107	    types that are specified in the current SOCKSv5 protocol, and the
108	    ADDRESS ID shows essential information between the client and the
109	    server. So, the introduction of the ADDRESS ID address type makes
110	    efficient communications via the SOCKS server. Especially, in case of
111	    UDP communications via the SOCKS server, the utilization of the
112	    ADDRESS ID address type contributes to shorten the length of the UDP
113	    Packet Structure header and to make the filtering procedure
114	    efficient.

116	     Since the introduction of the ADDRESS ID conceals the address family
117	    types, it becomes easy to enable to relay different address based
118	    connections (e.g., between IPv4 and IPv6) at the SOCKS server.

120	    * Extension 2 (New command for Requests and Replies)

122	     As a new command (CMD), "ADDRESS ASSOCIATE" is introduced.  This
123	    extension is closely related with Extension 1 (New address type
124	    notion).

126	     This command is prepared for a SOCKS client to get a ADDRESS ID from
127	    a SOCKS server. Followings are the procedure to get the ADDRESS ID.
128	      1. A SOCKS client sends a Request filled with the ADDRESS ASSOCIATE
129	    command to a SOCKS server.
130	      2. The server sends a Reply filled with the ADDRESS ID information
131	    to the BND.ADDR field.

133	     After the procedure is finished successfully, the client can use the
134	    received ADDRESS ID to any ADDR fields instead of other address types
135	    (IP V4 address, DOMAINNAME, or IP V6 address) for the Requests and
136	    the UDP Packet Structure header.

138	     With this extension, the client's DNS query delegation to the server

140	    can be accomplished explicitly in the SOCKS protocol.

142	     An ADDRESS ASSOCIATE command has different characteristics from
143	    other commands. It can be executed as a dedicated command, but also,
144	    it is possible to execute the ADDRESS ASSOCIATE command with other
145	    commands (CONNECT, BIND, or UDP ASSOCIATE) simultaneously under the
146	    special conditions that the client does not require explicit BND.ADDR
147	    information from the Replies. With the simultaneous commands
148	    execution can reduce the handshake times between the SOCKS client and
149	    the server. In order to realize this function, the ADDRESS ASSOCIATE
150	    command needs to be assigned to an appropriate bit of the CMD field
151	    of the Requests.

153	     In case an ADDRESS ASSOCIATE command is executed with other command
154	    simultaneously, the meanings of the REP field of the Replies may
155	    become unclear, and the client can not get explicit BND.ADDR
156	    information from the Replies, because BND.ADDR field is filled with
157	    ADDRESS ID information. (BND.PORT field is filled with normal
158	    information.)  In case confusion may happen, an orthodox method that
159	    the each command is executed as one dedicated function must be taken.
160	    Only when the client does not need BND.ADDR information and the
161	    meanings of the REP field is clear, this simultaneous commands
162	    execution can be taken.

164	     In case of the dedicated ADDRESS ASSOCIATE command Requests,
165	    DST.PORT field does not make sense. The meanings of this field is
166	    changed and reused. The name of it is changed to ADR.PREF. It shows
167	    the preference of the reply address type of the client. In the
168	    Extension 3 (Show the preference of the reply address type), the
169	    details of this specification are described.

171	    * Extension 3 (Show the preference of the reply address type)

173	     In case the SOCKS server relays different address based connections
174	    (e.g., between IPv4 and IPv6), the address type (ATYP) and the bound
175	    address (BND.ADDR) of the Replies are important. If the client can
176	    not deal with the replied address type, it causes confusion in the
177	    client.

179	     In order to avoid this confusion, the client needs to show the
180	    preference of the reply address type to the server. There are three
181	    methods to realize this feature.

183	      1. Do nothing special

185	          The client shows nothing special to the server and expects a
186	         default reply address type that can be associated naturally. It
187	         means to expect the same address (family) type that is used for
188	         the connection between the client and the server. In this
189	         method, the client dose not care which address family type is
190	         used in the connection between the server and the desired
191	         destination.

193	      2. Use FLAG field of the Requests

195	          The client shows the reply address type preference by setting
196	         the flag field FLAG of the Requests. An appropriate bit of the
197	         FLAG field shows off or on of the preference of the client.
198	          If the appropriate bit is off (0), it is the same case of the
199	         "Do nothing special."  Default address type is replied.
200	          If the appropriate bit is on (1), the client asks the server to
201	         reply the address as the same address (family) type that is used
202	         in the connection between the server and the desired
203	         destination. In this case, the client must deal with all of the
204	         expected address family types.

206	      3. Use DST.PORT field of the dedicated ADDRESS ASSOCIATE Requests

208	          In case of the dedicated ADDRESS ASSOCIATE Requests, the name
209	         of the DST.PORT field is changed to ADR.PREF, and it shows the
210	         preference of the reply address type.
211	          Since the ADR.PREF has 2 octets, it has a possibility to show
212	         complex preference. For the time being, the upper octet of the
213	         ADR.PREF is reserved. The lower octet is used to show the show
214	         the preference.  The format is the same to the ATYP field.
215	          (As an additional function, this mechanism enables the client
216	         to realize the deligation of the reverse DNS query, also.)
217	          The appropriate bit of the FLAG has a high priority and can
218	         overwrite the preference that is shown by the ADR.PREF field.

220	 Formats

222	    In the following sections, the formats that include the described
223	    extensions are shown. Most parts are quoted from the [RFC1928] and
224	    the current SOCKS version 5 specification [SOCKSv5]. Since [RFC1928]
225	    and [SOCKSv5] explain the meanings of the fields except extensions
226	    that are described in this document, they are omitted here.

228	    x marks (instead of o marks) indicate extensions.

230	    Note:

232	    Unless otherwise noted, the decimal numbers appearing in packet-
233	    format diagrams represent the length of the corresponding field, in
234	    octets.  Where a given octet must take on a specific value, the
235	    syntax X'hh' is used to denote the value of the single octet in that
236	    field. When the word 'Variable' is used, it indicates that the
237	    corresponding field has a variable length defined either by an
238	    associated (one or two octet) length field, or by a data type field.

240	 Requests Format

242	         +----+-----+------+------+----------+----------+
243	         |VER | CMD | FLAG | ATYP | DST.ADDR | DST.PORT |
244	         +----+-----+------+------+----------+----------+
245	         | 1  |  1  |  1   |  1   | Variable |    2     |
246	         +----+-----+------+------+----------+----------+

248	           o  VER    protocol version:  X'05'
249	           o  CMD
250	              o  CONNECT                X'01'
251	              o  BIND                   X'02'
252	              o  UDP ASSOCIATE          X'03'
253	              x  ADDRESS ASSOCIATE      X'08' (bit set)
254	              x  CONNECT
255	                    +ADDRESS ASSOCIATE  X'09'
256	              x  BIND
257	                    +ADDRESS ASSOCIATE  X'0A'
258	              x  UDP ASSOCIATE
259	                    +ADDRESS ASSOCIATE  X'0B'
260	              o  X'10' to X'7F' IANA ASSIGNED
261	              o  X'80' to X'FF' RESERVED FOR PRIVATE METHODS
262	           o FLAG   command dependent flag (defaults to X'00')
263	              x  Prefer Default address family type
264	                                        X'00' (off)
265	              x  Prefer address family type of the Destination
266	                                        X'10' (on)
267	           o  ATYP   address type of following address
268	              o  IP V4 address:         X'01'
269	              o  DOMAINNAME:            X'03'
270	              o  IP V6 address:         X'04'
271	              x  ADDRESS ID:            X'08'
272	           o  DST.ADDR       desired destination address
273	           o  DST.PORT desired destination port in network octet
274	              order

276	           In case of the dedicated ADDRESS ASSOCIATE Requests:
277	           x  DST.PORT = ADR.PREF
278	                 show the preference of the reply address type.
279	                       X'00'(reserved)+ ATYP
280	              x  IP V4 address:         X'01'
281	              x  DOMAINNAME:            X'03'
282	              x  IP V6 address:         X'04'

284	 Addressing Format

286	    In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies
287	    the type of address contained within the field:

289	           o  X'01'

291	    the address is a version-4 IP address, with a length of 4 octets

293	           o  X'03'

295	    the address field contains a fully-qualified domain name.  The first
296	    octet of the address field contains the number of octets of name that
297	    follow, there is no terminating NUL octet.

299	           o  X'04'

301	    the address is a version-6 IP address, with a length of 16 octets.

303	           x  X'08'

305	    the address is a identifier of the servers' internal address
306	    association table, with a length of 1 octet.

308	 Replies Format

310	         +----+-----+------+------+----------+----------+
311	         |VER | REP | FLAG | ATYP | BND.ADDR | BND.PORT |
312	         +----+-----+------+------+----------+----------+
313	         | 1  |  1  |  1   |  1   | Variable |    2     |
314	         +----+-----+------+------+----------+----------+

316	           o  VER    protocol version: X'05'
317	           o  REP    Reply field:
318	              o  X'00' succeeded
319	              o  X'01' general SOCKS server failure
320	              o  X'02' connection not allowed by ruleset
321	              o  X'03' Network unreachable
322	              o  X'04' Host unreachable
323	              o  X'05' Connection refused
324	              o  X'06' TTL expired
325	              o  X'07' Command not supported
326	              o  X'08' Address type not supported
327	              o  X'09' Invalid address
328	              o  X'0A' to X'FF' unassigned
329	           o  FLAG   command dependent flag
330	           o  ATYP   address type of following address
331	              o  IP V4 address:         X'01'
332	              o  DOMAINNAME:            X'03'
333	              o  IP V6 address:         X'04'
334	              x  ADDRESS ID:            X'08'
335	           o  BND.ADDR       server bound address
336	           o  BND.PORT       server bound port in network octet order

338	 UDP Control Channel Requests Format

340	         +----+-----+------+------+----------+------+
341	         |RSV | SUB | FLAG | ATYP | ADDR     | PORT |
342	         +----+-----+------+------+----------+------+
343	         | 1  |  1  |  1   |   1  | Variable |  2   |
344	         +----+-----+------+------+----------+------+

346	           o  RSV  Reserved X'00'
347	           o  SUB  Subcommand
348	                o  INTERFACE DATA: X'01'
349	           o  FLAG  A subcommand dependent flag (normally X'00')
350	           o  ATYP   address type of following address
351	              o  IP V4 address:         X'01'
352	              o  DOMAINNAME:            X'03'
353	              o  IP V6 address:         X'04'
354	              x  ADDRESS ID:            X'08'
355	           o  ADDR  destination address information
356	           o  PORT  destination port information

358	 UDP Packet Structure Format

360	         +------+------+------+----------+----------+----------+
361	         | FLAG | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
362	         +------+------+------+----------+----------+----------+
363	         |  2   |  1   |  1   | Variable |    2     | Variable |
364	         +------+------+------+----------+----------+----------+

366	    The fields in the UDP request header are:

368	           o  FLAG   Reserved X'0000'
369	           o  FRAG   Current fragment number
370	           o  ATYP   address type of following address
371	              o  IP V4 address:         X'01'
372	              o  DOMAINNAME:            X'03'
373	              o  IP V6 address:         X'04'
374	              x  ADDRESS ID:            X'08'
375	           o  DST.ADDR       desired destination address
376	           o  DST.PORT       desired destination port
377	           o  DATA     user data

379	 Security Considerations

381	    This document describes a protocol for the application-layer
382	    traversal of IP network firewalls.  The security of such traversal is
383	    highly dependent on the particular authentication and encapsulation
384	    methods provided in a particular implementation, and selected during
385	    negotiation between SOCKS client and SOCKS server.

387	    Careful consideration should be given by the administrator to the
388	    selection of authentication methods.

390	 References

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

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

398	    [IPv6]     S. Deering, R. Hinden, "Internet Protocol, Version 6
399	                  (IPv6) Specification", RFC2460, December 1998.

401	 Author's Address

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

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