RFC 2428¶

RFC 2428 — это запрос комментариев (Request for Comments) под номером 2428, опубликованный в сентябре 1998 года Инженерным советом Интернета (IETF). Документ озаглавлен «Расширения FTP для поддержки IPv6 и NAT» (FTP Extensions for IPv6 and NAT). Он определяет расширения протокола передачи файлов (FTP), позволяющие ему работать через сетевые экраны (firewalls) и трансляцию сетевых адресов (NAT), а также обеспечивает поддержку протокола IPv6. RFC 2428 является предложенным стандартом (Proposed Standard) и входит в серию документов, развивающих и модернизирующих базовый протокол FTP, определённый в RFC 959.

¶Предпосылки создания

К концу 1990-х годов протокол FTP, разработанный в 1971 году и стандартизированный в 1985 году (RFC 959), столкнулся с рядом ограничений. Основные проблемы были связаны с двумя аспектами:

• Использование IPv4 и ограниченность адресного пространства. В FTP для передачи данных используется отдельное TCP-соединение, параметры которого (IP-адрес и порт) передаются внутри управляющего соединения в виде текстовых строк. Формат этих строк был жёстко привязан к 32-битным адресам IPv4 (например, 192,168,1,1,0,21). С внедрением IPv6, использующего 128-битные адреса (например, 2001:db8::1), этот механизм стал неработоспособен.
• Проблемы с NAT и сетевыми экранами. Классический FTP использует два режима передачи данных: активный (PORT) и пассивный (PASV). В активном режиме сервер сам инициирует соединение к клиенту, что часто блокируется сетевыми экранами. В пассивном режиме клиент инициирует соединение к серверу, но IP-адрес и порт, сообщаемые сервером, могут быть недоступны клиенту из-за NAT (трансляции адресов). RFC 2428 был призван решить обе эти проблемы.

¶Основные положения RFC 2428

Документ вводит две новые команды для управляющего соединения FTP и изменяет формат ответа на некоторые существующие команды.

¶Команда EPSV (Extended Passive Mode)

Команда EPSV является расширением пассивного режима (PASV). Она позволяет клиенту запросить у сервера открытие порта для передачи данных, но с использованием расширенного формата ответа.

• Формат запроса: EPSV [<протокол>]
• Формат ответа: 229 Entering Extended Passive Mode (|||<порт>|)

Ключевое отличие от PASV заключается в том, что ответ сервера содержит только номер порта, а не IP-адрес. Это решает проблему NAT: клиент, находящийся за транслятором адресов, получает от сервера лишь порт, а IP-адрес для соединения использует тот же, что и для управляющего соединения. Таким образом, клиенту не нужно обрабатывать IP-адрес, который может быть недоступен (например, внутренний адрес сервера за NAT).

Необязательный параметр <протокол> указывает на сетевой протокол: 1 для IPv4, 2 для IPv6. Если параметр опущен, сервер использует тот же протокол, что и для управляющего соединения.

¶Команда EPRT (Extended Port)

Команда EPRT является расширением активного режима (PORT). Она позволяет клиенту сообщить серверу свой адрес и порт для обратного соединения, используя универсальный формат, поддерживающий как IPv4, так и IPv6.

• Формат запроса: EPRT |<протокол>|<адрес>|<порт>|
• Формат ответа: 200 EPRT command successful.

Разделителем полей служит символ вертикальной черты (|). Параметр <протокол> принимает значение 1 (IPv4) или 2 (IPv6). Адрес указывается в стандартном текстовом представлении (например, 192.0.2.1 или 2001:db8::1), а порт — десятичным числом.

¶Изменения в ответах на PASV и PORT

RFC 2428 также уточняет, что при использовании IPv6 сервер должен отклонять команды PORT и PASV (определённые в RFC 959) с сообщением об ошибке 504 Command not implemented for that parameter, поскольку они не поддерживают 128-битные адреса. Вместо них следует использовать EPRT и EPSV.

¶Влияние и современное использование

RFC 2428 стал важным шагом в адаптации FTP к современной сетевой инфраструктуре.

• Поддержка IPv6. Без расширений, введённых RFC 2428, FTP был бы практически непригоден для использования в сетях IPv6. Команды EPRT и EPSV стали обязательными для реализации FTP-клиентами и серверами, претендующими на поддержку IPv6.
• Работа с NAT. Команда EPSV (часто называемая «пассивным режимом с расширенным ответом») фактически решила проблему FTP через NAT. Большинство современных FTP-клиентов по умолчанию используют именно EPSV, что позволяет им корректно работать за домашними и корпоративными маршрутизаторами.
• Совместимость. RFC 2428 разработан с обратной совместимостью. Серверы, не поддерживающие EPSV или EPRT, должны отвечать кодом ошибки 500 или 502, после чего клиент может переключиться на стандартные PASV или PORT.

Несмотря на то, что сам протокол FTP считается устаревшим (его часто заменяют более безопасными протоколами, такими как SFTP или FTPS), RFC 2428 остаётся действующим стандартом. Большинство современных FTP-серверов (например, vsftpd, ProFTPD, FileZilla Server) и клиентов (FileZilla, WinSCP) поддерживают команды EPSV и EPRT. Документ также упоминается в более поздних RFC, касающихся безопасности FTP, например, в RFC 4217 (FTP over TLS/SSL), где уточняется использование расширенных команд в защищённом соединении.

¶Критика и ограничения

Основная критика в адрес RFC 2428 связана не с самим документом, а с общими недостатками протокола FTP, которые он не решает:

• Безопасность. FTP передаёт данные и учётные данные (логин и пароль) в открытом виде. RFC 2428 не добавляет никаких механизмов шифрования. Для защиты соединения требуется использование отдельного расширения, такого как AUTH TLS (RFC 4217), что часто не реализовано или настроено неправильно.
• Сложность с NAT. Хотя EPSV решает проблему для большинства клиентов, некоторые конфигурации NAT (особенно с симметричной трансляцией адресов) всё ещё могут вызывать проблемы. В таких случаях может потребоваться использование прокси-серверов или других методов туннелирования.
• Неполная поддержка. Не все FTP-серверы корректно реализуют EPSV. Некоторые могут отвечать на команду EPSV кодом 229, но при этом открывать порт на другом IP-адресе, чем тот, который используется для управляющего соединения, что нарушает логику работы расширения.

¶Источники

• RFC 2428 — FTP Extensions for IPv6 and NAT (сентябрь 1998)
• RFC 959 — File Transfer Protocol (октябрь 1985)
• RFC 4217 — Securing FTP with TLS (октябрь 2005)
• Стевенс, У. Р. «TCP/IP Illustrated, Volume 1: The Protocols» (Addison-Wesley, 1994) — главы, посвящённые FTP и сетевым протоколам.
• Документация IETF (Internet Engineering Task Force) по протоколам передачи файлов.