« back to all changes in this revision
Viewing changes to lib/inets/doc/archive/rfc2428.txt
- browse files at revision 20
- compare with another revision
- download diff
- download tarball
- view history from revision 20
- Committer: Bazaar Package Importer
- Author(s): Sergei Golovan
- Date: 2009-05-07 15:07:37 UTC
- mfrom: (3.3.1 squeeze)
- Revision ID: james.westby@ubuntu.com-20090507150737-x1m1n2qovms1zsk0
Tags: 1:13.b-dfsg1-1
* Removed another bunch of non-free RFCs from original tarball
(closes: #527053).
* Fixed build-dependencies list by adding missing comma. This requires
libsctp-dev again. Also, added libsctp1 dependency to erlang-base and
erlang-base-hipe packages because the shared library is loaded via
dlopen now and cannot be added using dh_slibdeps (closes: #526682).
* Weakened dependency of erlang-webtool on erlang-observer to recommends
to avoid circular dependencies (closes: #526627).
* Added solaris-i386 to HiPE enabled architectures.
* Made script sources in /usr/lib/erlang/erts-*/bin directory executable,
which is more convenient if a user wants to create a target Erlang system.
* Shortened extended description line for erlang-dev package to make it
fit 80x25 terminals.
(closes: #527053).
* Fixed build-dependencies list by adding missing comma. This requires
libsctp-dev again. Also, added libsctp1 dependency to erlang-base and
erlang-base-hipe packages because the shared library is loaded via
dlopen now and cannot be added using dh_slibdeps (closes: #526682).
* Weakened dependency of erlang-webtool on erlang-observer to recommends
to avoid circular dependencies (closes: #526627).
* Added solaris-i386 to HiPE enabled architectures.
* Made script sources in /usr/lib/erlang/erts-*/bin directory executable,
which is more convenient if a user wants to create a target Erlang system.
* Shortened extended description line for erlang-dev package to make it
fit 80x25 terminals.
- files removed:
- lib/inets/doc/archive
- files modified:
- debian/changelog
added
removed
lib/inets/doc/archive/rfc2428.txt
1
2
3
4
5
6
7
Network Working Group M. Allman
8
Request for Comments: 2428 NASA Lewis/Sterling Software
9
Category: Standards Track S. Ostermann
10
Ohio University
11
C. Metz
12
The Inner Net
13
September 1998
14
15
16
FTP Extensions for IPv6 and NATs
17
18
Status of this Memo
19
20
This document specifies an Internet standards track protocol for the
21
Internet community, and requests discussion and suggestions for
22
improvements. Please refer to the current edition of the "Internet
23
Official Protocol Standards" (STD 1) for the standardization state
24
and status of this protocol. Distribution of this memo is unlimited.
25
26
Copyright Notice
27
28
Copyright (C) The Internet Society (1998). All Rights Reserved.
29
30
Abstract
31
32
The specification for the File Transfer Protocol assumes that the
33
underlying network protocol uses a 32-bit network address
34
(specifically IP version 4). With the deployment of version 6 of the
35
Internet Protocol, network addresses will no longer be 32-bits. This
36
paper specifies extensions to FTP that will allow the protocol to
37
work over IPv4 and IPv6. In addition, the framework defined can
38
support additional network protocols in the future.
39
40
1. Introduction
41
42
The keywords, such as MUST and SHOULD, found in this document are
43
used as defined in RFC 2119 [Bra97].
44
45
The File Transfer Protocol [PR85] only provides the ability to
46
communicate information about IPv4 data connections. FTP assumes
47
network addresses will be 32 bits in length. However, with the
48
deployment of version 6 of the Internet Protocol [DH96] addresses
49
will no longer be 32 bits long. RFC 1639 [Pis94] specifies
50
extensions to FTP to enable its use over various network protocols.
51
Unfortunately, the mechanism can fail in a multi-protocol
52
environment. During the transition between IPv4 and IPv6, FTP needs
53
the ability to negotiate the network protocol that will be used for
54
data transfer.
55
56
57
58
Allman, et. al. Standards Track [Page 1]
59
60
RFC 2428 FTP Extensions for IPv6 and NATs September 1998
61
62
63
This document provides a specification for a way that FTP can
64
communicate data connection endpoint information for network
65
protocols other than IPv4. In this specification, the FTP commands
66
PORT and PASV are replaced with EPRT and EPSV, respectively. This
67
document is organized as follows. Section 2 outlines the EPRT
68
command and Section 3 outlines the EPSV command. Section 4 defines
69
the utilization of these two new FTP commands. Section 5 briefly
70
presents security considerations. Finally, Section 6 provides
71
conclusions.
72
73
2. The EPRT Command
74
75
The EPRT command allows for the specification of an extended address
76
for the data connection. The extended address MUST consist of the
77
network protocol as well as the network and transport addresses. The
78
format of EPRT is:
79
80
EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
81
82
The EPRT command keyword MUST be followed by a single space (ASCII
83
32). Following the space, a delimiter character (<d>) MUST be
84
specified. The delimiter character MUST be one of the ASCII
85
characters in range 33-126 inclusive. The character "|" (ASCII 124)
86
is recommended unless it coincides with a character needed to encode
87
the network address.
88
89
The <net-prt> argument MUST be an address family number defined by
90
IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the
91
writing of this document). This number indicates the protocol to be
92
used (and, implicitly, the address length). This document will use
93
two of address family numbers from [RP94] as examples, according to
94
the following table:
95
96
AF Number Protocol
97
--------- --------
98
1 Internet Protocol, Version 4 [Pos81a]
99
2 Internet Protocol, Version 6 [DH96]
100
101
The <net-addr> is a protocol specific string representation of the
102
network address. For the two address families specified above (AF
103
Number 1 and 2), addresses MUST be in the following format:
104
105
AF Number Address Format Example
106
--------- -------------- -------
107
1 dotted decimal 132.235.1.2
108
2 IPv6 string 1080::8:800:200C:417A
109
representations
110
defined in [HD96]
111
112
113
114
Allman, et. al. Standards Track [Page 2]
115
116
RFC 2428 FTP Extensions for IPv6 and NATs September 1998
117
118
119
The <tcp-port> argument must be the string representation of the
120
number of the TCP port on which the host is listening for the data
121
connection.
122
123
The following are sample EPRT commands:
124
125
EPRT |1|132.235.1.2|6275|
126
127
EPRT |2|1080::8:800:200C:417A|5282|
128
129
The first command specifies that the server should use IPv4 to open a
130
data connection to the host "132.235.1.2" on TCP port 6275. The
131
second command specifies that the server should use the IPv6 network
132
protocol and the network address "1080::8:800:200C:417A" to open a
133
TCP data connection on port 5282.
134
135
Upon receipt of a valid EPRT command, the server MUST return a code
136
of 200 (Command OK). The standard negative error code 500 and 501
137
[PR85] are sufficient to handle most errors (e.g., syntax errors)
138
involving the EPRT command. However, an additional error code is
139
needed. The response code 522 indicates that the server does not
140
support the requested network protocol. The interpretation of this
141
new error code is:
142
143
5yz Negative Completion
144
x2z Connections
145
xy2 Extended Port Failure - unknown network protocol
146
147
The text portion of the response MUST indicate which network
148
protocols the server does support. If the network protocol is
149
unsupported, the format of the response string MUST be:
150
151
<text stating that the network protocol is unsupported> \
152
(prot1,prot2,...,protn)
153
154
Both the numeric code specified above and the protocol information
155
between the characters '(' and ')' are intended for the software
156
automata receiving the response; the textual message between the
157
numeric code and the '(' is intended for the human user and can be
158
any arbitrary text, but MUST NOT include the characters '(' and ')'.
159
In the above case, the text SHOULD indicate that the network protocol
160
in the EPRT command is not supported by the server. The list of
161
protocols inside the parenthesis MUST be a comma separated list of
162
address family numbers. Two example response strings follow:
163
164
Network protocol not supported, use (1)
165
166
Network protocol not supported, use (1,2)
167
168
169
170
Allman, et. al. Standards Track [Page 3]
171
172
RFC 2428 FTP Extensions for IPv6 and NATs September 1998
173
174
175
3. The EPSV Command
176
177
The EPSV command requests that a server listen on a data port and
178
wait for a connection. The EPSV command takes an optional argument.
179
The response to this command includes only the TCP port number of the
180
listening connection. The format of the response, however, is
181
similar to the argument of the EPRT command. This allows the same
182
parsing routines to be used for both commands. In addition, the
183
format leaves a place holder for the network protocol and/or network
184
address, which may be needed in the EPSV response in the future. The
185
response code for entering passive mode using an extended address
186
MUST be 229. The interpretation of this code, according to [PR85]
187
is:
188
189
2yz Positive Completion
190
x2z Connections
191
xy9 Extended Passive Mode Entered
192
193
The text returned in response to the EPSV command MUST be:
194
195
<text indicating server is entering extended passive mode> \
196
(<d><d><d><tcp-port><d>)
197
198
The portion of the string enclosed in parentheses MUST be the exact
199
string needed by the EPRT command to open the data connection, as
200
specified above.
201
202
The first two fields contained in the parenthesis MUST be blank. The
203
third field MUST be the string representation of the TCP port number
204
on which the server is listening for a data connection. The network
205
protocol used by the data connection will be the same network
206
protocol used by the control connection. In addition, the network
207
address used to establish the data connection will be the same
208
network address used for the control connection. An example response
209
string follows:
210
211
Entering Extended Passive Mode (|||6446|)
212
213
The standard negative error codes 500 and 501 are sufficient to
214
handle all errors involving the EPSV command (e.g., syntax errors).
215
216
When the EPSV command is issued with no argument, the server will
217
choose the network protocol for the data connection based on the
218
protocol used for the control connection. However, in the case of
219
proxy FTP, this protocol might not be appropriate for communication
220
between the two servers. Therefore, the client needs to be able to
221
request a specific protocol. If the server returns a protocol that
222
is not supported by the host that will be connecting to the port, the
223
224
225
226
Allman, et. al. Standards Track [Page 4]
227
228
RFC 2428 FTP Extensions for IPv6 and NATs September 1998
229
230
231
client MUST issue an ABOR (abort) command to allow the server to
232
close down the listening connection. The client can then send an
233
EPSV command requesting the use of a specific network protocol, as
234
follows:
235
236
EPSV<space><net-prt>
237
238
If the requested protocol is supported by the server, it SHOULD use
239
the protocol. If not, the server MUST return the 522 error messages
240
as outlined in section 2.
241
242
Finally, the EPSV command can be used with the argument "ALL" to
243
inform Network Address Translators that the EPRT command (as well as
244
other data commands) will no longer be used. An example of this
245
command follows:
246
247
EPSV<space>ALL
248
249
Upon receipt of an EPSV ALL command, the server MUST reject all data
250
connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, et
251
al.). This use of the EPSV command is further explained in section
252
4.
253
254
4. Command Usage
255
256
For all FTP transfers where the control and data connection(s) are
257
being established between the same two machines, the EPSV command
258
MUST be used. Using the EPSV command benefits performance of
259
transfers that traverse firewalls or Network Address Translators
260
(NATs). RFC 1579 [Bel94] recommends using the passive command when
261
behind firewalls since firewalls do not generally allow incoming
262
connections (which are required when using the PORT (EPRT) command).
263
In addition, using EPSV as defined in this document does not require
264
NATs to change the network address in the traffic as it is forwarded.
265
The NAT would have to change the address if the EPRT command was
266
used. Finally, if the client issues an "EPSV ALL" command, NATs may
267
be able to put the connection on a "fast path" through the
268
translator, as the EPRT command will never be used and therefore,
269
translation of the data portion of the segments will never be needed.
270
When a client only expects to do two-way FTP transfers, it SHOULD
271
issue this command as soon as possible. If a client later finds that
272
it must do a three-way FTP transfer after issuing an EPSV ALL
273
command, a new FTP session MUST be started.
274
275
276
277
278
279
280
281
282
Allman, et. al. Standards Track [Page 5]
283
284
RFC 2428 FTP Extensions for IPv6 and NATs September 1998
285
286
287
5. Security Issues
288
289
The authors do not believe that these changes to FTP introduce new
290
security problems. A companion Work in Progress [AO98] is a more
291
general discussion of FTP security issues and techniques to reduce
292
these security problems.
293
294
6. Conclusions
295
296
The extensions specified in this paper will enable FTP to operate
297
over a variety of network protocols.
298
299
References
300
301
[AO98] Allman, M., and S. Ostermann, "FTP Security
302
Considerations", Work in Progress.
303
304
[Bel94] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February
305
1994.
306
307
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
308
Requirement Levels", BCP 14, RFC 2119, March 1997.
309
310
[DH96] Deering, S., and R. Hinden, "Internet Protocol, Version 6
311
(IPv6) Specification", RFC 1883, December 1995.
312
313
[HD96] Hinden, R., and S. Deering, "IP Version 6 Addressing
314
Architecture", RFC 2373, July 1998.
315
316
[Pis94] Piscitello, D., "FTP Operation Over Big Address Records
317
(FOOBAR)", RFC 1639, June 1994.
318
319
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September
320
1981.
321
322
[Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
323
September 1981.
324
325
[PR85] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
326
STD 9, RFC 959, October 1985.
327
328
[RP94] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
329
1700, October 1994. See also:
330
http://www.iana.org/numbers.html
331
332
333
334
335
336
337
338
Allman, et. al. Standards Track [Page 6]
339
340
RFC 2428 FTP Extensions for IPv6 and NATs September 1998
341
342
343
Authors' Addresses
344
345
Mark Allman
346
NASA Lewis Research Center/Sterling Software
347
21000 Brookpark Rd. MS 54-2
348
Cleveland, OH 44135
349
350
Phone: (216) 433-6586
351
EMail: mallman@lerc.nasa.gov
352
http://gigahertz.lerc.nasa.gov/~mallman/
353
354
355
Shawn Ostermann
356
School of Electrical Engineering and Computer Science
357
Ohio University
358
416 Morton Hall
359
Athens, OH 45701
360
361
Phone: (740) 593-1234
362
EMail: ostermann@cs.ohiou.edu
363
364
365
Craig Metz
366
The Inner Net
367
Box 10314-1954
368
Blacksburg, VA 24062-0314
369
370
Phone: (DSN) 754-8590
371
EMail: cmetz@inner.net
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
Allman, et. al. Standards Track [Page 7]
395
396
RFC 2428 FTP Extensions for IPv6 and NATs September 1998
397
398
399
Full Copyright Statement
400
401
Copyright (C) The Internet Society (1998). All Rights Reserved.
402
403
This document and translations of it may be copied and furnished to
404
others, and derivative works that comment on or otherwise explain it
405
or assist in its implementation may be prepared, copied, published
406
and distributed, in whole or in part, without restriction of any
407
kind, provided that the above copyright notice and this paragraph are
408
included on all such copies and derivative works. However, this
409
document itself may not be modified in any way, such as by removing
410
the copyright notice or references to the Internet Society or other
411
Internet organizations, except as needed for the purpose of
412
developing Internet standards in which case the procedures for
413
copyrights defined in the Internet Standards process must be
414
followed, or as required to translate it into languages other than
415
English.
416
417
The limited permissions granted above are perpetual and will not be
418
revoked by the Internet Society or its successors or assigns.
419
420
This document and the information contained herein is provided on an
421
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
422
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
423
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
424
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
425
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
Allman, et. al. Standards Track [Page 8]
451
Loggerhead is a web-based interface for Breezy
Version: 2.0.1