RFC 854¶

RFC 854 — это документ, опубликованный в мае 1983 года, который определяет протокол Telnet, предназначенный для обеспечения двунаправленного, восьмибитного, ориентированного на байты канала связи для удалённого терминального доступа к вычислительным системам. Документ является частью серии «Запросов на комментарии» (Request for Comments, RFC), разрабатываемых под эгидой Инженерного совета Интернета (IETF), и относится к категории «Стандарты Интернета» (Internet Standard STD 8). RFC 854 устанавливает базовые принципы работы Telnet, включая механизм согласования опций, и остаётся основой для реализации большинства Telnet-клиентов и серверов.

¶История и контекст создания

Протокол Telnet был разработан в начале 1980-х годов, когда сеть ARPANET (предшественница современного Интернета) переходила от протокола NCP (Network Control Program) к TCP/IP. Основной задачей было создание универсального средства для удалённого управления компьютерами, которое позволяло бы пользователю подключаться к удалённой системе и работать с ней так, как если бы он находился за её терминалом. До появления единого стандарта существовали разрозненные реализации, такие как протоколы TELNET для NCP (RFC 97, 1969 год) и более поздние версии, но они не были совместимы между собой.

RFC 854 был разработан рабочей группой IETF под руководством Джона Постела (John Postel) и Джойс К. Рейнольдс (Joyce K. Reynolds). Документ заменил более ранние спецификации, такие как RFC 764 (1980 год), и ввёл единую архитектуру, основанную на модели «виртуального сетевого терминала» (Network Virtual Terminal, NVT). В 1983 году RFC 854 был принят как стандарт Интернета, а позже дополнен рядом других RFC, в частности RFC 855 (опции Telnet), RFC 856 (опция бинарной передачи) и RFC 857 (опция эха).

¶Основные принципы работы

¶Виртуальный сетевой терминал (NVT)

Центральным понятием RFC 854 является Network Virtual Terminal (NVT) — абстрактное устройство, которое представляет собой минимальный набор функций, необходимых для работы с удалённой системой. NVT включает в себя:

• Клавиатуру, способную генерировать символы ASCII (7-битный набор, но с возможностью 8-битного расширения).
• Принтер или дисплей, отображающий символы.
• Управляющие символы, такие как перевод строки (CR, LF), возврат каретки (CR) и табуляция.

NVT обеспечивает независимость от конкретных типов терминалов (например, VT100, IBM 3270), так как клиент и сервер договариваются о возможностях через механизм опций.

¶Управляющие последовательности

Протокол Telnet использует специальные управляющие последовательности, начинающиеся с символа «Интерпретируй как команду» (Interpret as Command, IAC), который имеет код 255 (0xFF). После IAC следуют коды команд, определяющие действие:

• IAC WILL (251) — клиент или сервер сообщает, что хочет включить опцию.
• IAC WONT (252) — отказ от включения опции.
• IAC DO (253) — запрос на включение опции.
• IAC DONT (254) — запрос на отключение опции.
• IAC SB (250) — начало подпараметра (для передачи данных опции).
• IAC SE (240) — конец подпараметра.

Пример: если клиент отправляет IAC WILL 1 (опция «Эхо»), сервер может ответить IAC DO 1 (согласие) или IAC DONT 1 (отказ).

¶Механизм согласования опций

RFC 854 вводит симметричный механизм согласования, при котором любая сторона (клиент или сервер) может инициировать обсуждение опции. Это позволяет динамически настраивать параметры соединения, такие как:

• Режим эха (Echo) — опция 1.
• Режим подавления (Suppress Go Ahead) — опция 3.
• Тип терминала (Terminal Type) — опция 24.
• Скорость передачи (Terminal Speed) — опция 32.
• Окно (Window Size) — опция 31.

Согласование происходит по принципу «запрос-ответ»: после получения команды WILL или DO сторона обязана ответить DO/DONT или WILL/WONT соответственно. Если опция не поддерживается, отправляется WONT или DONT.

¶Структура протокола

¶Формат данных

Данные передаются в виде последовательности 8-битных байтов. Символы с кодами от 0 до 127 (ASCII) являются обычными данными. Символы с кодами от 128 до 255 могут использоваться для расширенных наборов символов или для управляющих последовательностей. Для передачи данных, содержащих байт 255 (0xFF), используется удвоение: каждый байт 255 передаётся как два байта 255 (IAC IAC).

¶Команды и их коды

¶Синхронизация и управление потоком

RFC 854 определяет механизм синхронизации через команду «Data Mark» (DM), которая используется для восстановления синхронизации после сбоя. Для управления потоком данных применяется механизм «Urgent» (срочные данные) на уровне TCP, который позволяет отправлять управляющие команды вне очереди обычных данных.

¶Применение и значение

¶Историческое значение

Telnet, определённый в RFC 854, стал первым универсальным протоколом удалённого доступа, широко использовавшимся в 1980-х и 1990-х годах для администрирования Unix-систем, маршрутизаторов и сетевых устройств. Он сыграл ключевую роль в развитии Интернета, так как позволял исследователям и инженерам работать с удалёнными машинами без физического присутствия.

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

Несмотря на появление более безопасных альтернатив, таких как SSH (Secure Shell), Telnet всё ещё применяется в следующих сценариях:

• Отладка сетевых протоколов: Telnet-клиент используется для ручного тестирования HTTP, SMTP, POP3 и других текстовых протоколов, так как позволяет отправлять команды вручную.
• Управление устаревшим оборудованием: Многие промышленные контроллеры, маршрутизаторы и коммутаторы, выпущенные до 2000-х годов, поддерживают только Telnet.
• Образовательные цели: Изучение сетевых протоколов и истории Интернета.
• Встраиваемые системы: В простых устройствах с ограниченными ресурсами Telnet может быть единственным доступным способом удалённого управления.

¶Безопасность

Основным недостатком Telnet является отсутствие шифрования. Все данные, включая пароли, передаются в открытом виде, что делает протокол уязвимым для перехвата трафика. В современных сетях использование Telnet без дополнительных мер защиты (например, через VPN) считается небезопасным. В связи с этим большинство организаций перешли на SSH, который обеспечивает шифрование и аутентификацию.

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

RFC 854 критикуется за:

• Отсутствие безопасности: Протокол не предусматривает шифрования, аутентификации или защиты от подмены.
• Сложность согласования опций: Механизм опций может приводить к несовместимости между реализациями, особенно при использовании нестандартных расширений.
• Ограниченная поддержка современных терминалов: NVT, основанный на ASCII, не поддерживает современные графические интерфейсы, Unicode (в базовой версии) или цветные выводы без дополнительных опций.
• Уязвимость к атакам: Telnet подвержен атакам типа «человек посередине» (MITM) и перехвату паролей.

¶Расширения и связанные стандарты

RFC 854 дополнен рядом других документов, которые расширяют его функциональность:

• RFC 855 — Telnet Option Specifications (общие правила для опций).
• RFC 856 — Telnet Binary Transmission (опция бинарной передачи).
• RFC 857 — Telnet Echo Option (опция эха).
• RFC 858 — Telnet Suppress Go Ahead Option (опция подавления Go Ahead).
• RFC 1091 — Telnet Terminal-Type Option (опция типа терминала).
• RFC 1572 — Telnet Environment Option (опция среды).
• RFC 2217 — Telnet Com Port Control Option (управление последовательными портами).

¶Интересные факты

• RFC 854 является одним из старейших действующих стандартов Интернета, принятых в 1983 году, и до сих пор используется в некоторых реализациях.
• Протокол Telnet стал основой для разработки протокола rlogin (1983 год), который также использовался для удалённого доступа в Unix-системах.
• В 1995 году, с выходом SSH-1, началось постепенное вытеснение Telnet из массового использования, но процесс затянулся на десятилетия.
• В RFC 854 используется термин «Network Virtual Terminal» (NVT), который позже был заимствован для других протоколов, таких как TN3270 (Telnet для IBM 3270).

¶Источники

• RFC 854 — Telnet Protocol Specification, J. Postel, J. Reynolds, 1983.
• RFC 855 — Telnet Option Specifications, J. Postel, J. Reynolds, 1983.
• RFC 856 — Telnet Binary Transmission, J. Postel, J. Reynolds, 1983.
• RFC 857 — Telnet Echo Option, J. Postel, J. Reynolds, 1983.
• RFC 1091 — Telnet Terminal-Type Option, J. VanBokkelen, 1989.
• «Internetworking with TCP/IP, Volume 1» — Douglas E. Comer, 2000.
• «TCP/IP Illustrated, Volume 1» — W. Richard Stevens, 1994.