RFC 6384: An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation
In plain English — editorial summary, not part of the RFC
The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers, FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent. FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. [STANDARDS-TRACK]
Document record
- Document ID
- RFC6384
- Published
- October 2011
- Authors
- I. van Beijnum
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- tsv
- Pages
- 16
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 8215Local-Use IPv4/IPv6 Translation PrefixCurrent
August 2017
- RFC 8512A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)Current
January 2019
- RFC 6146Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 ServersCurrent
April 2011
- RFC 6145IP/ICMP Translation AlgorithmObsoleted
April 2011
- RFC 6052IPv6 Addressing of IPv4/IPv6 TranslatorsCurrent
October 2010
- RFC 6889Analysis of Stateful 64 TranslationCurrent
April 2013
- RFC 7050Discovery of the IPv6 Prefix Used for IPv6 Address SynthesisUpdated
November 2013
- RFC 7051Analysis of Solution Proposals for Hosts to Learn NAT64 PrefixCurrent
November 2013
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?