fix bug 2704: remove verbatim RFC text from source

(this creates problems for Debian).

1 files changed, 0 insertions, 451 deletions

diff --git a/networking/ftp_ipv6_rfc2428.txt b/networking/ftp_ipv6_rfc2428.txt
deleted file mode 100644
index a6ec353..0000000
--- a/networking/ftp_ipv6_rfc2428.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          M. Allman
-Request for Comments: 2428                  NASA Lewis/Sterling Software
-Category: Standards Track                                   S. Ostermann
-                                                         Ohio University
-                                                                 C. Metz
-                                                           The Inner Net
-                                                          September 1998
-
-
-                    FTP Extensions for IPv6 and NATs
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   The specification for the File Transfer Protocol assumes that the
-   underlying network protocol uses a 32-bit network address
-   (specifically IP version 4).  With the deployment of version 6 of the
-   Internet Protocol, network addresses will no longer be 32-bits.  This
-   paper specifies extensions to FTP that will allow the protocol to
-   work over IPv4 and IPv6.  In addition, the framework defined can
-   support additional network protocols in the future.
-
-1.  Introduction
-
-   The keywords, such as MUST and SHOULD, found in this document are
-   used as defined in RFC 2119 [Bra97].
-
-   The File Transfer Protocol [PR85] only provides the ability to
-   communicate information about IPv4 data connections.  FTP assumes
-   network addresses will be 32 bits in length.  However, with the
-   deployment of version 6 of the Internet Protocol [DH96] addresses
-   will no longer be 32 bits long.  RFC 1639 [Pis94] specifies
-   extensions to FTP to enable its use over various network protocols.
-   Unfortunately, the mechanism can fail in a multi-protocol
-   environment.  During the transition between IPv4 and IPv6, FTP needs
-   the ability to negotiate the network protocol that will be used for
-   data transfer.
-
-
-
-Allman, et. al.             Standards Track                     [Page 1]
-
-RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
-
-
-   This document provides a specification for a way that FTP can
-   communicate data connection endpoint information for network
-   protocols other than IPv4.  In this specification, the FTP commands
-   PORT and PASV are replaced with EPRT and EPSV, respectively.  This
-   document is organized as follows.  Section 2 outlines the EPRT
-   command and Section 3 outlines the EPSV command.  Section 4 defines
-   the utilization of these two new FTP commands.  Section 5 briefly
-   presents security considerations.  Finally, Section 6 provides
-   conclusions.
-
-2.  The EPRT Command
-
-   The EPRT command allows for the specification of an extended address
-   for the data connection.  The extended address MUST consist of the
-   network protocol as well as the network and transport addresses.  The
-   format of EPRT is:
-
-           EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
-
-   The EPRT command keyword MUST be followed by a single space (ASCII
-   32).  Following the space, a delimiter character (<d>) MUST be
-   specified.  The delimiter character MUST be one of the ASCII
-   characters in range 33-126 inclusive.  The character "|" (ASCII 124)
-   is recommended unless it coincides with a character needed to encode
-   the network address.
-
-   The <net-prt> argument MUST be an address family number defined by
-   IANA in the latest Assigned Numbers RFC (RFC 1700 [RP94] as of the
-   writing of this document).  This number indicates the protocol to be
-   used (and, implicitly, the address length).  This document will use
-   two of address family numbers from [RP94] as examples, according to
-   the following table:
-
-        AF Number   Protocol
-        ---------   --------
-        1           Internet Protocol, Version 4 [Pos81a]
-        2           Internet Protocol, Version 6 [DH96]
-
-   The <net-addr> is a protocol specific string representation of the
-   network address.  For the two address families specified above (AF
-   Number 1 and 2), addresses MUST be in the following format:
-
-        AF Number   Address Format      Example
-        ---------   --------------      -------
-        1           dotted decimal      132.235.1.2
-        2           IPv6 string         1080::8:800:200C:417A
-                    representations
-                    defined in [HD96]
-
-
-
-Allman, et. al.             Standards Track                     [Page 2]
-
-RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
-
-
-   The <tcp-port> argument must be the string representation of the
-   number of the TCP port on which the host is listening for the data
-   connection.
-
-   The following are sample EPRT commands:
-
-        EPRT |1|132.235.1.2|6275|
-
-        EPRT |2|1080::8:800:200C:417A|5282|
-
-   The first command specifies that the server should use IPv4 to open a
-   data connection to the host "132.235.1.2" on TCP port 6275.  The
-   second command specifies that the server should use the IPv6 network
-   protocol and the network address "1080::8:800:200C:417A" to open a
-   TCP data connection on port 5282.
-
-   Upon receipt of a valid EPRT command, the server MUST return a code
-   of 200 (Command OK).  The standard negative error code 500 and 501
-   [PR85] are sufficient to handle most errors (e.g., syntax errors)
-   involving the EPRT command.  However, an additional error code is
-   needed.  The response code 522 indicates that the server does not
-   support the requested network protocol.  The interpretation of this
-   new error code is:
-
-        5yz Negative Completion
-        x2z Connections
-        xy2 Extended Port Failure - unknown network protocol
-
-   The text portion of the response MUST indicate which network
-   protocols the server does support.  If the network protocol is
-   unsupported, the format of the response string MUST be:
-
-        <text stating that the network protocol is unsupported> \
-            (prot1,prot2,...,protn)
-
-   Both the numeric code specified above and the protocol information
-   between the characters '(' and ')' are intended for the software
-   automata receiving the response; the textual message between the
-   numeric code and the '(' is intended for the human user and can be
-   any arbitrary text, but MUST NOT include the characters '(' and ')'.
-   In the above case, the text SHOULD indicate that the network protocol
-   in the EPRT command is not supported by the server.  The list of
-   protocols inside the parenthesis MUST be a comma separated list of
-   address family numbers.  Two example response strings follow:
-
-        Network protocol not supported, use (1)
-
-        Network protocol not supported, use (1,2)
-
-
-
-Allman, et. al.             Standards Track                     [Page 3]
-
-RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
-
-
-3.  The EPSV Command
-
-   The EPSV command requests that a server listen on a data port and
-   wait for a connection.  The EPSV command takes an optional argument.
-   The response to this command includes only the TCP port number of the
-   listening connection.  The format of the response, however, is
-   similar to the argument of the EPRT command.  This allows the same
-   parsing routines to be used for both commands.  In addition, the
-   format leaves a place holder for the network protocol and/or network
-   address, which may be needed in the EPSV response in the future.  The
-   response code for entering passive mode using an extended address
-   MUST be 229.  The interpretation of this code, according to [PR85]
-   is:
-
-        2yz Positive Completion
-        x2z Connections
-        xy9 Extended Passive Mode Entered
-
-   The text returned in response to the EPSV command MUST be:
-
-        <text indicating server is entering extended passive mode> \
-            (<d><d><d><tcp-port><d>)
-
-   The portion of the string enclosed in parentheses MUST be the exact
-   string needed by the EPRT command to open the data connection, as
-   specified above.
-
-   The first two fields contained in the parenthesis MUST be blank.  The
-   third field MUST be the string representation of the TCP port number
-   on which the server is listening for a data connection.  The network
-   protocol used by the data connection will be the same network
-   protocol used by the control connection.  In addition, the network
-   address used to establish the data connection will be the same
-   network address used for the control connection.  An example response
-   string follows:
-
-        Entering Extended Passive Mode (|||6446|)
-
-   The standard negative error codes 500 and 501 are sufficient to
-   handle all errors involving the EPSV command (e.g., syntax errors).
-
-   When the EPSV command is issued with no argument, the server will
-   choose the network protocol for the data connection based on the
-   protocol used for the control connection.  However, in the case of
-   proxy FTP, this protocol might not be appropriate for communication
-   between the two servers.  Therefore, the client needs to be able to
-   request a specific protocol.  If the server returns a protocol that
-   is not supported by the host that will be connecting to the port, the
-
-
-
-Allman, et. al.             Standards Track                     [Page 4]
-
-RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
-
-
-   client MUST issue an ABOR (abort) command to allow the server to
-   close down the listening connection.  The client can then send an
-   EPSV command requesting the use of a specific network protocol, as
-   follows:
-
-        EPSV<space><net-prt>
-
-   If the requested protocol is supported by the server, it SHOULD use
-   the protocol.  If not, the server MUST return the 522 error messages
-   as outlined in section 2.
-
-   Finally, the EPSV command can be used with the argument "ALL" to
-   inform Network Address Translators that the EPRT command (as well as
-   other data commands) will no longer be used.  An example of this
-   command follows:
-
-        EPSV<space>ALL
-
-   Upon receipt of an EPSV ALL command, the server MUST reject all data
-   connection setup commands other than EPSV (i.e., EPRT, PORT, PASV, et
-   al.).  This use of the EPSV command is further explained in section
-   4.
-
-4.  Command Usage
-
-   For all FTP transfers where the control and data connection(s) are
-   being established between the same two machines, the EPSV command
-   MUST be used.  Using the EPSV command benefits performance of
-   transfers that traverse firewalls or Network Address Translators
-   (NATs).  RFC 1579 [Bel94] recommends using the passive command when
-   behind firewalls since firewalls do not generally allow incoming
-   connections (which are required when using the PORT (EPRT) command).
-   In addition, using EPSV as defined in this document does not require
-   NATs to change the network address in the traffic as it is forwarded.
-   The NAT would have to change the address if the EPRT command was
-   used.  Finally, if the client issues an "EPSV ALL" command, NATs may
-   be able to put the connection on a "fast path" through the
-   translator, as the EPRT command will never be used and therefore,
-   translation of the data portion of the segments will never be needed.
-   When a client only expects to do two-way FTP transfers, it SHOULD
-   issue this command as soon as possible.  If a client later finds that
-   it must do a three-way FTP transfer after issuing an EPSV ALL
-   command, a new FTP session MUST be started.
-
-
-
-
-
-
-
-
-Allman, et. al.             Standards Track                     [Page 5]
-
-RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
-
-
-5.  Security Issues
-
-   The authors do not believe that these changes to FTP introduce new
-   security problems.  A companion Work in Progress [AO98] is a more
-   general discussion of FTP security issues and techniques to reduce
-   these security problems.
-
-6.  Conclusions
-
-   The extensions specified in this paper will enable FTP to operate
-   over a variety of network protocols.
-
-References
-
-   [AO98]   Allman, M., and S. Ostermann, "FTP Security
-            Considerations", Work in Progress.
-
-   [Bel94]  Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February
-            1994.
-
-   [Bra97]  Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [DH96]   Deering, S., and R. Hinden, "Internet Protocol, Version 6
-            (IPv6) Specification", RFC 1883, December 1995.
-
-   [HD96]   Hinden, R., and S. Deering, "IP Version 6 Addressing
-            Architecture", RFC 2373, July 1998.
-
-   [Pis94]  Piscitello, D., "FTP Operation Over Big Address Records
-            (FOOBAR)", RFC 1639, June 1994.
-
-   [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September
-            1981.
-
-   [Pos81b] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
-            September 1981.
-
-   [PR85]   Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
-            STD 9, RFC 959, October 1985.
-
-   [RP94]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
-            1700, October 1994.  See also:
-            http://www.iana.org/numbers.html
-
-
-
-
-
-
-
-Allman, et. al.             Standards Track                     [Page 6]
-
-RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
-
-
-Authors' Addresses
-
-   Mark Allman
-   NASA Lewis Research Center/Sterling Software
-   21000 Brookpark Rd.  MS 54-2
-   Cleveland, OH  44135
-
-   Phone: (216) 433-6586
-   EMail: mallman@lerc.nasa.gov
-   http://gigahertz.lerc.nasa.gov/~mallman/
-
-
-   Shawn Ostermann
-   School of Electrical Engineering and Computer Science
-   Ohio University
-   416 Morton Hall
-   Athens, OH  45701
-
-   Phone: (740) 593-1234
-   EMail: ostermann@cs.ohiou.edu
-
-
-   Craig Metz
-   The Inner Net
-   Box 10314-1954
-   Blacksburg, VA  24062-0314
-
-   Phone:  (DSN) 754-8590
-   EMail: cmetz@inner.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allman, et. al.             Standards Track                     [Page 7]
-
-RFC 2428            FTP Extensions for IPv6 and NATs      September 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allman, et. al.             Standards Track                     [Page 8]
-