RFC 1122 Requirements for Internet Hosts — Communication Layers

Network Working Group                Internet Engineering Task Force
Request for Comments: 1122                         R. Braden, Editor
                                                        October 1989

 

Требования к хостам Internet — коммуникационные уровни

Requirements for Internet Hosts — Communication Layers

PDF

Статус документа

В данном RFC содержатся официальные спецификации для сообщества Internet. Документ содержит ссылки, исправления и дополнения к первичным стандартам протоколов, имеющим отношение к хостам. Документ можно распространять свободно.

Аннотация

Этот документ является одним из двух RFC, посвященных определению и обсуждению требований к программам хостов Internet. Данный документ посвящен коммуникационным протоколам, а второй документ RFC 1123 — прикладным протоколам и протоколам поддержки.

1. Введение

Этот документ является первым из пары RFC, определяющих и обсуждающих требования к реализации хост-систем на базе стека протоколов Internet. Документ посвящен коммуникационным протоколам — канальный уровень, уровень IP (сетевой) и транспортный уровень. Второй документ пары — RFC 1123 Requirements for Internet Hosts — Application and Support [INTRO:1] — посвящен протоколам прикладного уровня. С этой парой также тесно связан документ RFC 1009 — Requirements for Internet Gateways [INTRO:2].

Документ предназначен для производителей и разработчиков, а также для пользователей коммуникационных программ Internet. Документ написан на основе обобщения опыта работы исследователей Internet и компаний-производителей.

В этом RFC рассмотрены стандарты протоколов, которые должны использоваться на хостах, подключенных к сети Internet, а также связанные с ними RFC и другие документы, описывающие текущие варианты спецификаций для таких протоколов. В документе исправлен ряд ошибок, встречающихся в упоминаемых документах, рассмотрены дополнительные вопросы и даны рекомендации по реализации протоколов.

Для каждого протокола в данном документе также приведен явный набор требований, рекомендаций и опций. Читатель должен понимать, что список приведенных в документе требований неполон — полные требования для хостов Internet содержатся в документах, определяющих спецификации протоколов. В данном RFC приведены поправки, уточнения и дополнения к стандартам протоколов.

Качественная реализация протоколов, подготовленная в результате внимательного прочтения этого RFC, работы в контакте с техническим сообществом Internet и учета позитивной практики разработки коммуникационных программ, не должна сильно отличаться от содержащихся в документе требований. Многие из «требований» данного RFC уже реализованы в стандартах или рассматриваются для включения в стандарты, поэтому их обсуждение в данном документе может показаться избыточным. Однако такие вопросы были включены в документ, поскольку некоторые из имеющихся реализаций содержат ошибки, приводящие к недостаточной интероперабельности, снижению производительности и возникновению иных проблем.

В документе обсуждается и разъясняется множество требований и рекомендаций. Простой список требований может быть опасен по ряду причин:

  • некоторые требуемые функции более важны, а ряд функций не является обязательным;
  • существует множество причин, по которым продукция, разработанная для ограниченного контекста может быть выбрана для использования в иных средах.

Нужно следовать приведенным в документе спецификациям для обеспечения интероперабельности хостов при взаимодействии через разнородные и сложные системы Internet. Хотя многие из числа имеющихся реализаций не соответствуют тем или иным требованиям, спецификации являются идеалом, к которому нужно стремиться.

Приведенные в документе требования основаны на современном уровне архитектуры Internet. Документ будет обновляться по мере развития спецификаций и технологий в тех областях, с которыми он связан.

Вводная часть документа начинается с краткого обзора архитектуры Internet применительно к хостам, приведены также некоторые рекомендации по выбору программ для хостов. Кроме того, во введении даны некоторые рекомендации по работе с остальной частью документа и рассмотрена используемая терминология.

1.1 Архитектура Internet

Рассмотрению основ архитектуры Internet и поддерживаемых протоколов посвящена книга DDN Protocol Handbook [INTRO:3], основы архитектуры рассмотрены также в работах [INTRO:9], [INTRO:10], [INTRO:11]. В работе [INTRO:5] рассматриваются вопросы получения документов со стандартами протоколов Internet, а документ [INTRO:6] содержит список номеров (числовых идентификаторов), выделенных для протоколов Internet.

1.1.1 Хосты Internet

Хост-компьютер или попросту хост является конечным пользователем коммуникационного сервиса. На хостах в общем случае выполняются программы по запросам пользователей и/или поддерживаются коммуникационные службы Internet для обслуживания пользовательских запросов. Хосты Internet соответствуют концепции конечной системы (End-System) в стеке протоколов OSI [INTRO:13].

Коммуникационная система Internet содержит соединенные между собой сети передачи пакетов, в которых обмен информацией между хостами осуществляется на основе протоколов Internet. Сети подключаются к Internet или промежуточным системам OSI (Intermediate Systems, [INTRO:13]) с использованием компьютеров, обеспечивающих коммутацию пакетов — такие компьютеры называют шлюзами (gateway) или маршрутизаторами IP (IP router)1. В документе Requirements for Internet Gateways [INTRO:2] содержатся официальные спецификации для шлюзов (маршрутизаторов) Internet. RFC 1009 вместе с настоящим документом и RFC 1123 [INTRO:1] определяют правила для текущей реализации архитектуры Internet.

Хосты Internet сильно различаются по своим размерам, производительности и выполняемым функциям. В сети Internet используются самые разные компьютеры, включая настольные ПК, рабочие станции, мэйнфреймы и суперкомпьютеры. По выполняемым функциям хосты делятся на системы общего назначения (например, терминальные серверы) и мультисервисные системы (поддержка широкого спектра сетевых служб — remote login, FTP, электронная почта и т. п.).

Для обозначения хостов с множеством интерфейсов в одну или несколько сетей используется термин multihomed (многодомный). Более подробное описание таких хостов приведено в параграфе 1.1.3 Терминология.

1.1.2 Архитектурные допущения

Современная архитектура Internet основана на группе базовых допущений о коммуникационной системе. Допущения, связанные с хостами, перечислены ниже:

  1. Internet является «сетью сетей». Каждый хост напрямую подключен к какой-либо сети (сетям) — соединение с Internet является лишь концептуальным. Два хоста одной сети могут обмениваться между собой данными с использованием тех же протоколов, которые служат для связи с хостами удаленных сетей.

  2. Шлюзы не хранят информацию о состоянии соединений. Для повышения устойчивости коммуникационных систем шлюзы разрабатываются таким образом, чтобы обеспечивалась пересылка дейтаграмм IP без организации явных соединений (stateless) и независимо от других дейтаграмм. В результате для обеспечения устойчивости могут использоваться избыточные (redundant) пути, которые активизируются при возникновении сбоев на основных путях. Вся информация, требуемая для сквозного управления потоком данных (end-to-end flow control) через соединение, обеспечивается хостами с помощью программ транспортного или прикладного уровня. Таким образом, все данные для контроля соединения сосредоточены в конечных точках соединения и могут быть потеряны только при сбое на хостах.
  3. Маршрутизация осуществляется в шлюзах. Маршрутизация является сложным процессом и должна выполняться шлюзами, а не хостами. Важной причиной такого допущения является избавление от необходимости смены или повторной настройки программ в результате изменений, вносимых при сменах архитектуры маршрутизации Internet.
  4. Система должна быть совместима с различными вариантами сетей. Базовой предпосылкой архитектуры Internet является возможность изменения в широких пределах сетевых параметров (например, скорости каналов, задержки, числа теряемых пакетов, изменения порядка доставки пакетов, максимального размера пакетов и т. п.). Другим важным требованием является устойчивость к сбоям в отдельных сетях, шлюзах, хостах и сохранение возможности работы с доступной скоростью. Конечной целью взаимодействия открытых систем (open system interconnection) является обеспечение эффективной работы Internet и полной интероперабельности для всех типов хостов и сетей, соединенных через различные каналы Internet. В некоторых случаях разработчики преследуют менее амбициозные цели. Например, среды ЛВС обычно менее требовательны к хостам по сравнению с Internet в целом — локальные сети имеют небольшие задержки, теряется только малая часть пакетов и порядок доставки пакетов обычно сохраняется. Некоторые компании в своих реализациях используют решения, приемлемые для ЛВС, но совершенно не подходящие для гетерогенных сред. Обычно такую продукцию преподносят в качестве дешевого решения для локальных сетей. Однако, изолированная ЛВС может перестать быть таковой и при организации взаимодействия с другими сетями и Internet использование таких упрощенных решений с неизбежностью породит проблемы. В конце концов ни пользователь, ни производитель могут оказаться не в состоянии решить проблемы, возникшие в результате применения не полностью соответствующих стандартам оборудования и программ.

Приведенные в документе требования относятся к полнофункциональным хостам Internet, обеспечивающим полную интероперабельность при использовании самых разных путей передачи данных сети Internet.

1.1.3 Стек протоколов Internet

Для связи через Internet на хостах должен использоваться многоуровневый набор протоколов, соответствующий стеку протоколов Internet. Обычно на хостах реализован по крайней мере один протокол для каждого из уровней.

Уровни протоколов, используемые в архитектуре Internet, описаны в работе [INTRO:4]:

  • Прикладной уровень (Application Layer) Прикладной уровень располагается в верхней части стека протоколов Internet. В стеке Internet прикладной уровень не разделен на подуровни, хотя некоторые из протоколов прикладного уровня Internet содержат внутренние подуровни. Прикладной уровень стека Internet объединяет в себе функции двух уровней (Presentation — уровень представления и Application — прикладной) эталонной модели OSI. Мы будем различать две категории протоколов прикладного уровня — пользовательские протоколы, которые предоставляют услуги непосредственно пользователю, и протоколы поддержки (служебные), обеспечивающие системные функции общего назначения. Требования к пользовательским и служебным протоколам рассмотрены в RFC 1123 [INTRO:1]. Наиболее распространенными пользовательскими протоколами Internet являются:
    • Telnet (удаленный вход в систему)
    • FTP (передача файлов)
    • SMTP (доставка электронной почты)

    Существует также множество стандартизованных [INTRO:4] и частных пользовательских протоколов. Служебные протоколы используются для преобразования имен, загрузки ОС и управления — к числу таких протоколов относятся SNMP, BOOTP, RARP, DNS2.

  • Транспортный уровень (Transport Layer) Транспортный уровень обеспечивает сквозную связь (end-to-end) между приложениями через сеть. На транспортном уровне используются два основных протокола:

    • Transmission Control Protocol (TCP) — протокол управления передачей

    • User Datagram Protocol (UDP) — протокол пользовательских дейтаграмм

    TCP представляет собой основанный на соединениях (connection-oriented) транспортный сервис с гарантированной доставкой пакетов, обеспечивающий надежную доставку с сохранением порядка пакетов и управлением потоком данных. Протокол UDP не использует явных соединений (connectionless) и передает данные в виде дейтаграмм (datagram) без гарантии доставки. Исследовательскими организациями были разработаны и другие протоколы транспортного уровня, которые могут получить статус стандартных протоколов. Более подробное описание протоколов транспортного уровня приведено в главе 4.

  • Уровень Internet3 (Internet Layer) Все транспортные протоколы используют протокол IP (Internet Protocol) для передачи данных от отправителя к получателю. IP представляет собой службу доставки дейтаграмм без организации соединений (connectionless), не обеспечивающую сквозной гарантии доставки. Таким образом, при доставке на хост получателя дейтаграммы IP могут оказаться поврежденными; кроме того, не гарантируется сохранение порядка их доставки, отдельные дейтаграммы могут быть потеряны, а некоторые — продублированы. Если требуются гарантии доставки, ответственность за такие гарантии должны брать на себя вышележащие уровни. Протокол IP отвечает за адресацию, обозначение типа сервиса, фрагментацию и сборку, а также безопасность. Передача данных без организации соединений лежит в основе протокола IP и является одной из основных характеристик архитектуры Internet. Протокол IP послужил моделью при разработке сетевого протокола OSI Connectionless Network Protocol [INTRO:12]. Управляющий протокол ICMP является важной составной частью IP, хотя с точки зрения архитектуры он работает поверх IP (т. е., использует IP для передачи данных, подобно транспортным протоколам TCP и UDP). ICMP обеспечивает доставку сообщений об ошибках, насыщении сети и перенаправлении пакетов для первого маршрутизатора (first-hop). IGMP представляет собой протокол уровня Internet, используемый для организации динамических групп хостов с целью группового обмена информацией (IP multicasting). Протоколы уровня Internet (IP, ICMP и IGMP) более подробно рассмотрены в главе 3.
  • Канальный уровень (Link Layer) Для связи с непосредственно подключенными к нему сетями хост должен поддерживать коммуникационный протокол, используемый для обмена данными с сетью. Мы будем называть такой протокол MAC-протоколом (media-access layer protocol4) или протоколом канального уровня (link layer). На канальном уровне может использоваться множество протоколов в зависимости от используемой сетевой технологии. Протоколы канального уровня рассмотрены в главе 2.

1.1.4 Встроенная маршрутизация

Программы некоторых хостов Internet включают встроенный маршрутизатор — такие хосты могут пересылать пакеты, как это делают шлюзы, обеспечивая в то же время функции прикладного уровня как обычные хосты.

Такие системы двойного назначения должны соответствовать требованиям RFC 1009 [INTRO:2] в части функций шлюза и требованиям настоящего документа, применительно к функциям хоста. Во всех перекрывающихся случаях эти две спецификации должны быть согласованы.

В сообществе Internet существует множество мнений о поддержке встроенных функций маршрутизации. Ниже приведены основные аргументы за и против таких систем5:

  • За — такие системы могут быть приемлемы с точки зрения удобства и экономичности в локальных сетях или изолированных системах для использования существующих хостов в качестве маршрутизаторов. Существуют также аргументы в пользу встроенной маршрутизации с точки зрения архитектуры — компьютеров с несколькими сетевыми интерфейсами больше, нежели с одним интерфейсом, и поддержка функций маршрутизации позволяет более эффективно использовать такие хосты.
  • Против — алгоритмы и протоколы маршрутизации постоянно изменяются с ростом Internet. Попытка реализации этих протоколов на хостах общего назначения будет требовать постоянного обновления программ на таких хостах. Наличие многочисленных реализаций кода маршрутизации дополнительно затрудняет внесение требуемых изменений. И, наконец, реализация уровня IP для шлюза сложнее, нежели для обычного хоста, что делает работу с такими хостами также более сложной. Кроме того, стиль работы некоторых хостов просто неприемлем для их использования в качестве стабильных и надежных маршрутизаторов.

Обе точки зрения имеют свои плюсы и минусы. Прежде, чем выбрать решение для себя, администратор должен принять во внимание реальную потребность в поддержке хостом функций маршрутизации. Более детальное рассмотрение этого вопроса приведено в параграфе 3.1.

1.2 Общие вопросы

Существуют два важнейших аспекта, которые должны принимать во внимание разработчики программ для хостов Internet.

1.2.1 Постоянное изменение Internet

Непредсказуемо быстрый рост Internet порождает проблемы управления и масштабирования в гигантских системах передачи дейтаграмм. В результате решения таких проблем изменяются и спецификации, описываемые в данном документе. Изменения планируются и осуществляются под контролем и с участием производителей сетевой продукции и организаций, ответственных за работу сетей.

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

1.2.2 Принципы устойчивости

Для протоколов всех уровней существует общее правило, которому приложения должны следовать во избежание проблем с устойчивостью и интероперабельностью [IP:1]:

Предъявлять жесткие требования по отношению к себе, быть более мягким по отношению к другим6.

Программы должны уметь обрабатывать все мыслимые ошибки; не имеет значения вероятность возникновения той или иной ошибки — раньше или позже пакет с любой возможной комбинацией ошибок и/или атрибутов будет получен и программа должна быть готова к обработке такого пакета. Если программа не может эффективно обрабатывать ошибки, она приведет прямой дорогой к хаосу. В общем случае лучше предположить, что сеть наводнена зловредными объектами, которые постоянно передают пакеты, предназначенные для нанесения максимального вреда. Такое предположение обеспечит высокий уровень защиты. Наиболее серьезные проблемы в Internet связаны с неисследованными механизмами, включающимися с малой вероятностью; намерения обычных злоумышленников никогда не могут принести такого вреда7!

На всех уровнях программ хостов Internet должны быть реализованы средства адаптации. В качестве простого примера рассмотрим спецификацию протокола, использующего численные значения для какого-либо поля в заголовке (например, тип, номер порта или код ошибки) — при разработке следует предполагать, что используемая нумерация неполна. Если спецификация протокола предполагает четыре возможных кода ошибки, приложение должно уметь обрабатывать по крайней мере пять типов ошибок (4 заданных и все остальные). Появление не определенных в спецификации кодов должно протоколироваться (см. ниже), но не должно нарушать работу системы.

Почти так же важен и другой аспект — программы на других хостах могут содержать определения, которые могут толкнуть хост на неразумные, но допустимые с точки зрения протокола действия. Естественным решением будет «поиск неразумных хостов» — программы хоста должны быть готовы не просто переносить появление неразумных хостов, но и участвовать в процессе ограничения вредных воздействий, которые подобные хосты могут нанести сетевым объектам общего пользования.

1.2.3 Протоколирование ошибок

Сеть Internet включает огромное количество разнотипных хостов и шлюзов, в каждом из которых реализовано множество протоколов и уровней, — некоторые из хостов и маршрутизаторов наверняка содержат ошибки в программах стека протоколов Internet. В результате сложности, разнотипности и использования распределенных функций диагностика Internet является весьма непростой задачей.

Упростить поиск проблем помогает использование хостами специальных средств протоколирования ошибок и странностей в поведении протоколов. При записи таких событий важно включать максимум диагностической информации. Часто бывает весьма полезно записывать заголовки пакетов, вызывающих ошибки. Однако следует знать меру — средства протоколирования ошибок не должны отнимать слишком много ресурсов хоста и снижать эффективность его работы.

При записи информации об ошибках существует вероятность получения журнальных файлов огромного размера — таких ситуаций можно избежать, используя «циклический» журнал или включая запись только для диагностики определенных сбоев. Полезно также фильтровать и считать повторяющиеся последовательные сообщения. Представляется привлекательной приведенная ниже стратегия:

  1. всегда считать аномальные события и делать содержимое счетчиков доступным с помощью средств управления сетью (см. [INTRO:1]);
  2. поддерживать возможность выбора протоколируемых событий (например, записывать все ошибки, связанные с хостом X).

Отметим, что разные системы управления сетью могут придерживаться различных правил в части числа протоколируемых ошибок для каждого хоста. Некоторые системы исходят из принципа: «если это не имеет ко мне прямого отношения, я не хочу об этом знать», тогда как другие системы прилагают максимум усилий для обнаружения и устранения аномалий в поведении сетевых протоколов.

1.2.4 Конфигурационные параметры

Идеальной реализацией хоста будет та, на которой настройка стека протоколов Internet будет полностью автоматизирована. Это позволит реализовать весь стек в ПЗУ или встроить в микросхемы оборудования — такое решение упростит организацию бездисковых станций, снимет значительную часть нагрузки с сетевых администраторов и упростит разработку систем. Однако этот идеал недостижим и на практике к нему не удается даже серьезно приблизиться.

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

Наконец, часть конфигурационных опций может потребоваться для обеспечения взаимодействия с устаревшими или содержащими ошибки реализациями протоколов, распространяемыми без исходных кодов (к несчастью, такое встречается в Internet достаточно часто). Для обеспечения корректного сосуществования с такими “сбойными” системами администраторам зачастую приходится «расстраивать» (mis-configure) корректно работающие системы. Такие проблемы будут решаться сами собой по мере удаления сбойных систем, но разработчики не должны оставлять этот вопрос без внимания.

Когда мы говорим, что параметр требует настройки, это не означает требования читать значение параметра из конфигурационного файла при каждой загрузке. Мы рекомендуем разработчикам устанавливать для таких параметров используемые по умолчанию значения — тогда в конфигурационных файлах могут содержаться лишь те значения, которые не совпадают с принятыми по умолчанию. Таким образом, конфигурационные требования обеспечивают гарантию возможности изменения принятых по умолчанию значений параметров — это решение можно использовать даже при загрузке программного кода из ПЗУ.

В этом документе для ряда случаев указаны значения, которые следует использовать по умолчанию. Выбор принятых по умолчанию значений является достаточно важным вопросом для случаев использования вместе с существующими сбойными системами. По мере продвижения Internet к полной интероперабельности, принятые по умолчанию значения будут реализовать официальный протокол, а не «расстраивать» систему для обеспечения совместимости с плохо работающими реализациями. Хотя рынок заставляет некоторых производителей устанавливать по умолчанию значения для «расстройки», мы рекомендуем использовать по умолчанию значения, соответствующие стандартам.

В заключении отметим, что производители продукции должны предоставлять полную документацию по всем конфигурационным параметрам, указывая допустимые значения и описывая влияние параметров на работу системы.

1.3 Работа с документом

1.3.1 Структура документа

Деление протоколов на уровни, которое в общем случае используется как организационный принцип при реализации сетевых программ, служит также принципом организации данного документа. При описании правил мы предполагаем, что реализация достаточно точно отражает деление протоколов по уровням. Таким образом, документ поделен на три основных части — канальный уровень, уровень internet и транспортный уровень. Документ RFC 1123 [INTRO:1] содержит описание программ прикладного уровня. Такая организация документов представляется простой и наглядной.

Однако, жесткое деление на уровни не является совершенной моделью как для стека протоколов, так и для реализации программ. Протоколы различных уровней взаимодействуют в комплексе, иногда даже трудно отделить один протокол от другого, а отдельные функции могут включать несколько уровней. При разработке программных реализаций существует масса вариантов, многие из которых «творчески» подходят к вопросам деления на уровни. Мы рекомендуем всем разработчикам внимательно прочесть документы [INTRO:7] и [INTRO:8].

В этом документе описывается концептуальный интерфейс взаимодействия между уровнями, использующий функциональную нотацию (procedure call — вызов процедур), подобную той, что используется в спецификации TCP [TCP:1]. Реализация хоста должна поддерживать логические потоки информации, применяемые при таких вызовах, но не требовать дословной реализации самих вызовов. Например, во многих реализациях связь между транспортным уровнем и IP отражается предоставлением разделяемого доступа к общим структурам данных.

В общем случае все главы документа организованы в форме следующих параграфов:

  1. Введение
  2. Общие вопросы — рассматриваются документы со спецификациями протокола, приводятся исправления ошибок, перечисляются требования, которые могли быть нечетко или неточно сформулированы, и приводятся дополнительные комментарии и разъяснения.

  3. Частные вопросы — рассматривается устройство протокола и вопросы реализации, не включенные в предыдущий раздел.
  4. Интерфейсы — обсуждаются услуги, предоставляемые вышележащему протоколу.
  5. Заключение — резюмируются требования данной главы.

Во многих темах документа встречаются параграфы, помеченные как «Обсуждение» или «Реализация». Этот материал предназначен для разъяснения требований, рассмотренных ранее в документе. Такие параграфы также включают некоторые предложения по вариантам будущих разработок. Материалы о реализации содержат предложения, которые могут быть интересны для разработчиков.

Заключение служит в качестве краткого руководства и справочника к главе, но оно слишком кратко для использования в качестве информационного источника. Такие заключения никогда не должны использоваться отдельно от текста полного RFC.

1.3.2 Уровень требований

В этом документе модальные глаголы, служащие для формулировки требований, выделены жирным шрифтом и используются в оговоренном ниже смысле:

Требуется, должен (MUST)

Этот глагол (или причастие от него) используется для обозначения абсолютной необходимости.

Следует, рекомендуется (SHOULD)

Этот глагол (или причастие рекомендуемый) служит для обозначения тех случаев, когда могут существовать дополнительные факторы, позволяющие игнорировать данное требование; в таких случаях рекомендуется принимать взвешенное решение с учетом всех факторов.

Можно (MAY)

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

Реализация считается несовместимой со стандартами, если в ней не выполнены обязательные требования (MUST). Реализация, в которой выполнены все требования MUST и SHOULD считается «безусловно совместимой»; если же выполняются все требования MUST, но проигнорирована часть требований SHOULD, реализация считается «условно совместимой».

1.3.3 Терминология

Ряд используемых в документе технических терминов определен в данном параграфе.

Сегмент — Segment

Сегментом будем называть модуль данных8, используемый для сквозной передачи по протоколу TCP. Сегмент состоит из заголовка TCP, за которым следуют данные. Сегменты передаются с использованием инкапсуляции в дейтаграммы IP.

Сообщение — Message

При описании протоколов нижних уровней термин сообщение обозначает модуль, передаваемый на транспортном уровне. В частности, сегмент TCP является сообщением. Сообщение содержит заголовок транспортного уровня, за которым следуют данные. Для сквозной передачи через сеть Internet сообщение должно инкапсулироваться в дейтаграммы.

Дейтаграмма IP — IP Datagram

Дейтаграмма IP представляет собой модуль данных протокола IP. Дейтаграмма IP содержит заголовок IP, за которым следует информация транспортного уровня (т. е., сообщение).

При описании уровня Internet (глава 3) термин дейтаграмма обычно относится к дейтаграммам IP.

Пакет — Packet

Пакет представляет собой модуль данных, передаваемый через интерфейс между уровнем Internet и канальным уровнем. Пакет включает заголовок IP и данные. Пакет может быть полной дейтаграммой IP или фрагментом такой дейтаграммы.

Кадр — Frame

Кадр представляет собой модуль данных для передачи на канальном уровне и содержит заголовок канального уровня, за которым следует пакет.

Подключенная сеть — Connected Network

Сеть, к которой непосредственно подключен хост, часто называют локальной сетью (local network) или подсетью (subnetwork) применительно к данному хосту. Однако использование этих терминов может привести к путанице, поэтому мы будем пользоваться термином подключенная сеть (connected network).

Multihomed — многодомный

Хост называют многодомным если он имеет более одного адреса IP. Более подробное обсуждение таких хостов вы найдете в параграфе 3.3.4.

Физический интерфейс — Physical network interface

Физический интерфейс используется для подключения хоста к сети. Интерфейс имеет адрес канального уровня (возможно, уникальный). В хосте может использоваться множество физических интерфейсов с общим адресом канального уровня, но для каждого хоста одной физической сети должен обеспечиваться уникальный адрес на канальном уровне.

Логический интерфейс — Logical [network] interface

Определим логический [сетевой] интерфейс как логический путь в подключенную сеть. Для идентификации логического интерфейса служит уникальный адрес IP. Более подробное рассмотрение логических интерфейсов приведено в параграфе 3.3.4.

Specific-destination address

Эффективный адрес получателя дейтаграммы, даже если она является широковещательной (broadcast) или групповой (multicast). Дополнительная информация по этому вопросу содержится в параграфе 3.2.1.3.

Путь — Path

В каждый момент времени все дейтаграммы IP от определенного хоста-отправителя к определенному хосту-получателю обычно передаются через одинаковую последовательность маршрутизаторов. Мы будем использовать термин “путь” для обозначения таких последовательностей маршрутизаторов. Отметим, что путь является однонаправленным, т. е. данные между парой хостов могут передаваться в каждом направлении по своему пути.

MTU9

Максимальный размер передаваемого модуля данных (т. е., размер наибольшего пакета, который может быть передан через сеть).

Термины кадр, пакет, дейтаграмма и сегмент дополнительно проиллюстрированы на приведенных ниже рисунках.

  1. Передача в подключенную сеть:

Заголовок канального уровня Заголовок IP Данные

<———————— Кадр ——————>

<————— Пакет —————>

  1. Перед фрагментацией IP или после сборки:
Заголовок IP Заголовок транспорт. уровня Данные приложений

<——————— Дейтаграмма ————->

<———— Сообщение ————>

то же самое для TCP:

Заголовок IP Заголовок TCP Данные приложений

<——————— Дейтаграмма ————->

<————- Сегмент ————->

1.4 Благодарности

Этот документ включает результаты работы и комментарии большой группы специалистов по протоколам Internet, включая представителей университетов и исследовательских лабораторий, компаний-производителей и государственных агентств. Подготовка документа велась в рабочей группе IETF Host Requirements.

Редактор выражает особую благодарность за неустанную работу людям, принявшим участие в долгих конференциях и написавшим 3 мегабайта почтовых сообщений за 18 месяцев подготовки этого документа, — Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU) и James Van Bokkelen (FTP Software).

Кроме того, выражается благодарность всем, кто внес большой вклад в подготовку документа — Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), Mike StJohns (DCA). Перечисленные ниже люди внесли значительный вклад в подготовку отдельных тем — Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco) и Rayan Zachariassen (Toronto).

Благодарим также всех, кто так или иначе способствовал появлению этого документа.

2. Канальный уровень

2.1 Введение

Для всех систем Internet — хостов и маршрутизаторов — предъявляются одинаковые требования к протоколам канального уровня. Эти требования подробно рассмотрены в главе 3 документа «Requirements for Internet Gateways» [INTRO:2] и дополнены в настоящем документе.

2.2 Общие вопросы

Не рассматриваются.

2.3 Частные вопросы

2.3.1 Согласование трейлерного протокола

Для инкапсуляции на канальном уровне может использоваться трейлерный протокол [LINK:1], но использование такого протокола должно быть согласовано обеими системами (хосты или маршрутизаторы), взаимодействующими на канальном уровне с применением трейлеров. Если системы не могут согласовать трейлерный протокол динамически (для каждого получателя), принятая по умолчанию конфигурация должна запрещать использование трейлеров.

Обсуждение

Трейлерный протокол представляет собой метод инкапсуляции на канальном уровне, обеспечивающий перекомпоновку пакетов, передаваемых в физическую сеть. В некоторых случаях трейлеры повышают производительность протоколов верхних уровней за счет снижения объема копируемых данных. Протоколы верхних уровней не знают об использовании трейлеров, но приемник и передатчик пакетов должны понимать, какой протокол используется для инкапсуляции.

Некорректное использование трейлеров может привести к серьезной путанице. С использованием трейлеров инкапсулируются только пакеты с заданным набором атрибутов и обычно этому требованию удовлетворяет лишь малая часть передаваемых пакетов. Таким образом, если одна система будет использовать трейлеры, а другая не будет, часть пакетов будет «улетать в черную дыру», а остальные будут доставляться нормально.

Реализация

В сетях Ethernet пакеты, инкапсулируемые с трейлерами, используют различные типы Ethernet [LINK:1] и согласование трейлера выполняется одновременно с использованием протокола ARP для определения адреса получателя. Обмен пакетами ARP для определения адреса осуществляется обычным способом, но хост, согласующий трейлер, будет передавать дополнительный отклик ARP (trailer ARP reply), указывающий тип трейлерного протокола инкапсуляции в формате обычного отклика ARP. Если хост, настроенный на использование трейлеров, получает отклик ARP с типом трейлера от удаленной машины, он может добавить ее в список систем, поддерживающих трейлеры (например, пометив соответствующую запись в кэше ARP).

Хосты, желающие использовать трейлерную инкапсуляцию, передают отклик trailer ARP всякий раз при завершении нормального обмена ARP для IP-адреса. Таким образом, хост, получивший запрос ARP для своего IP-адреса, будет передавать отклик trailer ARP в дополнение к нормальному отклику IP ARP; хост, передавший запрос IP ARP, будет передавать отклик trailer ARP при получении отклика на запрос IP ARP. При таком способе как запрашивающий, так и отвечающий хост в процессе обмена пакетами IP ARP может запросить использование трейлерной инкапсуляции.

Такая схема с использованием дополнительных пакетов trailer ARP reply вместо запросов ARP на указание типа трейлерного протокола была разработана для того, чтобы избежать непрерывного обмена пакетами ARP с некорректно работающими хостами, которые в ответ на запрос типа трейлера передают стандартный отклик ARP для IP-адреса. Проблема решается за счет передачи отклика trailer ARP в ответ на отклик IP ARP только в тех случаях, когда отклик IP ARP отвечает на невыполненный запрос (это верно для тех случаев, когда аппаратный адрес хоста остается неизвестным к моменту получения отклика IP ARP). Отклик trailer ARP всегда можно посылать вместе с откликом IP ARP, соответствующим запросу IP ARP.

2.3.2 Протокол преобразования адресов — ARP

2.3.2.1 Проверка кэша ARP

Реализация протокола преобразования адресов ARP10 [LINK:2] должна обеспечивать механизм удаления устаревших записей из таблицы. Если поддерживаемый механизм использует тайм-аут, должна обеспечиваться возможность настройки времени ожидания.

Реализация должна обеспечивать механизм предотвращения лавинной рассылки (ARP flooding) в виде повторяющихся с высокой частотой запросов ARP Request для одного адреса IP. Рекомендуемая частота запросов не должна превышать для каждого адреса 1 запрос/сек.

Обсуждение

Спецификация ARP [LINK:2] предлагает, но не требует использовать механизм тайм-аутов для объявления некорректными (invalidate) элементов кэша при смене хостом своего адреса Ethernet. Широкое распространение proxy ARP (см. параграф 2.4 в работе [INTRO:2]) существенно повышает вероятность того, что в кэше будут содержаться некорректные записи, следовательно требуется механизм удаления устаревших записей из кэша ARP. Даже в отсутствие proxy ARP использование тайм-аутов полезно для автоматической коррекции данных ARP, которые могли быть кэшированы.

Реализация

Для удаления устаревших записей из кэша используется 4 механизма (иногда в комбинации).

  1. Timeout — записи периодически удаляются из кэша, даже если они остаются актуальными11. При использовании ARP тайм-аут должен быть порядка 1 минуты.
  2. Unicast Poll — активный опрос удаленных хостов с помощью периодической отправки по их адресам пакетов ARP Request и удаление записей для тех адресов, от которых не пришло пакетов ARP Reply после N последовательных опросов. Тайм-аут должен по-прежнему составлять около 1 минуты, а типичное значение N = 2.
  3. Link-Layer Advice — если драйвер канального уровня обнаруживает проблемы с доставкой, соответствующая запись удаляется из кэша ARP.
  4. Higher-layer Advice — обеспечивается вызов на канальный уровень с уровня Internet для индикации проблем с доставкой. Эффект такого вызова заключается в том, что соответствующая запись удаляется из кэша. Такой вызов является аналогом вызова ADVISE_DELIVPROB() с транспортного уровня на уровень Internet (см. параграф 3.4) и подпрограмма ADVISE_DELIVPROB фактически может использоваться для вызова программы канального уровня, удаляющей запись из кэша ARP.

Варианты (1) и (2) используют тайм-аут порядка 1 минуты или меньше. При отсутствии ARP такой короткий период ожидания может породить заметный избыточный трафик в больших сетях Ethernet. Следовательно, может потребоваться увеличение тайм-аута ARP.

2.3.2.2 Очередь пакетов ARP

Канальный уровень должен сохранять (а не отбрасывать) по крайней мере один (последний) пакет из каждой группы пакетов для того или иного адреса IP и передавать сохраненный пакет, когда адрес будет преобразован (resolve).

Обсуждение

Невыполнение приведенного выше требования приводит к потере первого пакета при каждом обмене. Хотя протоколы верхних уровней в общем случае способны заново отправлять пакеты при их потере, утрата пакетов будет снижать производительность системы. Например, потеря запроса на открытие сеанса TCP приведет к тому, что оценка времени кругового обхода (round-trip time) будет некорректной. Приложения на основе UDP (такие, как DNS) будут еще сильнее страдать от такого недостатка.

2.3.3 Инкапсуляция Ethernet и IEEE 802

Инкапсуляция пакетов IP для сетей Ethernet описана в RFC 894 [LINK:3], а RFC 1042 [LINK:4] содержит описание инкапсуляции IP для сетей IEEE 802. RFC 1042 уточняет вопросы, рассмотренные в параграфе 3.4 документа [INTRO:2].

Для каждого хоста Internet, подключенного к сети Ethernet (10 Мбит/с) с помощью кабеля

  • требуется поддержка приема и передачи пакетов с использованием инкапсуляции RFC 894;
  • рекомендуется поддерживать прием пакетов RFC 1042 вперемешку с пакетами RFC 894;
  • допустимо поддерживать передачу пакетов с использованием инкапсуляции RFC 1042.

Хосты Internet, реализующие передачу с использованием инкапсуляции обоих типов (RFC 894 и RFC 1042), должны поддерживать возможность настройки (конфигурационная опция) используемого типа инкапсуляции. По умолчанию требуется использовать инкапсуляцию RFC 894.

Отметим, что стандартная инкапсуляция IP в соответствии с RFC 1042 не использует значение идентификатора протокола (K1=6), зарезервированное IEEE для протокола IP, устанавливая вместо этого значение K1=170, указывающее на расширение (SNAP), которое может использоваться для поля EtherType. Для систем Internet недопустима передача пакетов IEEE 802 с использованием K1=6.

Трансляция адресов Internet в адреса канального уровня для сетей Ethernet и IEEE 802 должна обеспечиваться на основе протокола ARP.

Значение MTU для Ethernet составляет 1500, а для 802.3 — 149212 байта.

Обсуждение

Спецификация IEEE 802.3 обеспечивает работу по кабелям Ethernet 10 Мбит/с, что может вести к смешению в одной физической среде кадров Ethernet13 и IEEE 802.3. Приемник может различать кадры Ethernet и 802.3 по значению поля длины (Length) для 802.3 — это 2-октетное поле совпадает14 с полем EtherType в кадрах Ethernet. Значение поля длины для кадров 802.3 не должно превышать 1500, а все корректные значения EtherType превышают 1500.

Другая проблема совместимости связана с широковещательными кадрами на канальном уровне. Широковещательные кадры того или иного типа не будут видны хостам, способным принимать лишь другой тип кадров.

Основной задачей данного параграфа является обеспечение рекомендаций по интероперабельности сетей с инкапсуляцией RFC 894 и RFC 1042 в одной физической среде. Основной упор делается на доминирующие сейчас сети RFC 894, с учетом перехода в будущем на инкапсуляцию RFC 1042.

Отметим, что системы, поддерживающие только RFC 894, не могут напрямую взаимодействовать с системами RFC 1042. Если каждый тип инкапсуляции организовать в виде логической сети (на том же кабеле), то две логические сети можно будет связать через шлюз IP (маршрутизатор). Использование хостов, способных поддерживать оба формата, не всегда полезно (и не всегда возможно), поскольку трудно автоматически определить формат передачи кадров из-за проблем с широковещательными кадрами канального уровня.

2.4 Интерфейс между канальным уровнем и IP

Интерфейс приема пакетов между IP и канальным уровнем должен включать флаг, показывающий пакеты для широковещательной рассылки на канальном уровне.

Обсуждение

Хотя уровень IP в общем случае не знает адресов канального уровня (поскольку в каждой физической среде используется свой формат адресации), широковещательный адрес для поддерживающих широковещательную рассылку сред является в некотором роде исключением из общего правила. Более подробное рассмотрение этого вопроса приведено в параграфе 3.2.2.

Интерфейс передачи пакетов между IP и канальным уровнем должен включать 5-битовое поле TOS, описанное в параграфе 3.2.1.6.

Для канального уровня недопустима передача сообщений об ошибке Destination Unreachable на уровень IP при отсутствии записи с адресом получателя в кэше ARP.

2.5 Требования к канальному уровню

Функция Параграф

Требование

Трейлерная инкапсуляция

2.3.1

Обязательно

Передавать трейлеры по умолчанию без согласования

2.3.1

Недопустимо

ARP Удаление устаревших записей Предотвращение ARP-лавин Настройка тайм-аута для кэша Сохранение по крайней мере последнего пакета с непреобразованным адресом

2.3.2

2.3.2.1

2.3.2.1

2.3.2.1

2.3.2.2

Обязательно

Обязательно

Следует

Следует

Инкапсуляция Ethernet и IEEE 802 Способность хоста: Использовать RFC 894 для приема и передачи Использовать RFC 1042 для приема Использовать RFC 1042 для передачи Для этого случая поддержка по умолчанию RFC 894 Использование инкапсуляции с K1=6 Поддержка ARP для сетей Ethernet и IEEE 802

2.3.3

2.3.3

2.3.3

2.3.3

2.3.3

2.3.3

2.3.3

2.3.3

Обязательно

Следует

Возможно

Обязательно

Недопустимо

Обязательно

Канальный уровень сообщает о широковещательных кадрах уровню IP

2.4

Обязательно

Передача уровнем IP значений TOS на канальный уровень

2.4

Обязательно

Трактовка отсутствия адреса в кэше как Destination Unreachable

2.4

Недопустимо

3. Протоколы уровня INTERNET

3.1 Введение

Принцип устойчивости — «быть либеральным при приеме и консервативным при передаче» особенно важен для уровня Internet, где некорректное поведение одного хоста может нарушить работу множества других хостов.

К числу протокольных стандартов уровня Internet относятся:

  • RFC 791 [IP:1] — определяет протокол IP и содержит введение в архитектуру Internet.
  • RFC 792 [IP:2] — определяет протокол ICMP, обеспечивающий диагностику и сообщения об ошибках для протокола IP. Хотя сообщения ICMP инкапсулируются в дейтаграммы IP, обработка ICMP рассматривается (и обычно реализована) как часть уровня IP. См. параграф 3.2.2.
  • RFC 950 [IP:3] — определяет обязательную поддержку подсетей для архитектуры адресации.
  • RFC 1112 [IP:4] определяет протокол IGMP (Internet Group Management Protocol — протокол управления группами Internet) как часть рекомендуемого расширения для хостов и интерфейсов хост-шлюз, обеспечивающего в масштабах Internet поддержку групповой адресации на уровне IP. См. параграф 3.2.3. Адресатами групповых (multicast) пакетов IP могут быть произвольные группы хостов Internet. Групповая адресация IP разработана как естественное расширение групповой адресации на канальном уровне и обеспечивает стандартное толкование для локального доступа к multicasting-объектам.

Ссылки на другие источники информации приведены в главе 5.

Программы уровня Internet на каждом хосте должны поддерживать оба протокола — IP и ICMP. Требования в части поддержки IGMP рассмотрены в параграфе 3.3.7.

Уровень IP выполняет две основных функции: (1) выбирает следующий маршрутизатор или хост (next hop) для исходящих дейтаграмм IP и (2) обеспечивает сборку принимаемых дейтаграмм IP. Уровень IP также может (3) реализовать преднамеренную фрагментацию исходящих дейтаграмм. Наконец, уровень IP должен (4) поддерживать детектирование и обработку ошибок. Предполагается, что в будущем функциональность уровня IP может быть расширена путем разработки новых приложений Internet для контроля и управления.

Для нормальных дейтаграмм осуществляется прямая (straightforward) обработка. Для входящих дейтаграмм уровень IP выполняет следующие операции:

  1. проверка корректности формата дейтаграммы;
  2. проверка того, что дейтаграмма адресована локальному хосту;
  3. обработка опций;
  4. при необходимости сборка дейтаграмм из фрагментов;
  5. передача инкапсулированного в дейтаграмме сообщения соответствующему модулю транспортного уровня.

Для исходящих дейтаграмм уровень IP выполняет следующие операции:

  1. установка всех полей, не заданных на транспортном уровне;
  2. выбор подходящего интерфейса подключенной сети (маршрутизация);
  3. фрагментация дейтаграммы, если это необходимо, или преднамеренная фрагментация при использовании таковой (см. параграф 3.3.3);
  4. передача пакетов соответствующему драйверу канального уровня.

Хост называют многодомным (multihomed), если он имеет несколько адресов IP. Поддержка множества адресов для хостов вносит в стек протоколов дополнительную сложность и возможность путаницы, В этой части архитектуры Internet требуется серьезная работа для решения всех проблем. С поддержкой множества адресов связаны, прежде всего, две аспекта проблемы:

  1. Local multihoming — рассматриваемый хост имеет множество адресов;
  2. Remote multihoming — локальному хосту приходится работать с удаленным хостом, использующим множество адресов.

В настоящее время обслуживание работы с удаленными многодомными хостами должно обеспечиваться на прикладном уровне, как описано в RFC 1123 [INTRO:1]. Работа с локальным хостом, поддерживающим множество адресов, рассмотрена ниже (параграф 3.3.4).

Любой хост, пересылающий дейтаграммы от других хостов, действует как маршрутизатор и должен удовлетворять спецификациям маршрутизаторов (шлюзов), рассматриваемым в RFC 1009 [INTRO:2]. Хост Internet, поддерживающий встроенный маршрутизатор, должен иметь конфигурационные опции, позволяющие отключить маршрутизацию (по умолчанию маршрутизация должна быть выключена). В таком режиме дейтаграмма, принятая через какой-либо интерфейс, не будет пересылаться другому хосту или шлюзу (если не используется маршрутизация, заданная отправителем — source-route), независимо от числа имеющихся в данном хосте интерфейсов. Не допускается автоматический переход хоста в режим маршрутизации при наличии на хосте нескольких интерфейсов, поскольку оператор хоста может не желать выполнять функции маршрутизации и быть некомпетентным в этом вопросе.

В таких случаях для принятой дейтаграммы зачастую используют операцию silently discard15. Это означает, что дейтаграмма отбрасывается без дальнейшей обработки и даже не передается сообщение ICMP об ошибке (см. параграф 3.2.2). Однако, для обеспечения диагностики хост должен обеспечивать возможность протоколирования таких ошибок (см. параграф 1.2.3), включая запись содержимого отбрасываемых дейтаграмм. Кроме того, количество отбрасываемых дейтаграмм должно учитываться счетчиком статистики.

Обсуждение:

Отбрасывание ошибочных дейтаграмм без уведомления в общем случае используется для предотвращения широковещательных штормов (broadcast storms).

3.2 Общие вопросы

3.2.1 Протокол Internet — IP

3.2.1.1 Номер версии: RFC 791, параграф 3.1

Дейтаграммы с номером версии, отличающимся от 4, должны отбрасываться без уведомления.

3.2.1.2 Контрольная сумма: RFC 791, параграф 3.1

Хост должен проверять контрольную сумму заголовка IP для каждой полученной дейтаграммы и отбрасывать без уведомления дейтаграммы с некорректной контрольной суммой.

3.2.1.3 Адресация: RFC 791, параграф 3.2

Существует пять классов IP-адресов — от A до E. Адреса класса D используются для групповой адресации IP [IP:4], а класс E зарезервирован для экспериментов16.

Групповые адреса (класс D) представляют собой 28-битовые логические адреса, используемые для групп хостов, и могут быть постоянными или временными. Постоянные групповые адреса распределяет агентство IANA17 [INTRO:6], а временные динамически выделяются для временных групп хостов. Принадлежность к группе определяется динамически на основе протокола IGMP [IP:4].

Рассмотрим более подробно IP-адреса классов A, B и C, используя обозначения:

 { <Номер сети>, <Номер хоста> }

или

 { <Номер сети>, <Номер подсети>, <Номер хоста> }

и -1 для обозначения полей, содержащих только единицы (1). Такая нотация не предполагает, что единицы в маске адреса должны быть непрерывными.

  1. { 0, 0 }

    Данный хост в данной сети. Этот адрес недопустимо указывать в качестве адреса отправителя за исключением случаев передачи адреса отправителя в процессе инициализации, посредством которого хост узнает свой IP-адрес.

    В параграфе 3.3.6 рассмотрены варианты нестандартного использования {0,0}.

  2. { 0, <Номер хоста> } Указывает хост данной сети. Такие адреса недопустимо указывать в качестве адреса отправителя за исключением случаев использования как адреса отправителя в процедурах инициализации, с помощью которых хост получает полный IP-адрес.
  3. { -1, -1 } Широковещательный пакет ограниченного действия (Limited broadcast). Такой адрес недопустимо указывать в качестве адреса отправителя. Дейтаграмма с таким адресом в поле получателя будет приниматься каждым хостом данной физической сети, но не будет выходить за пределы сети через маршрутизаторы.
  4. { <Номер сети>, -1 } Широковещательный адрес для данной сети. Такой адрес недопустимо указывать в качестве адреса отправителя.
  5. { <Номер сети>, <Номер подсети>, -1 } Направленное широковещание для заданной подсети18. Такой адрес недопустимо использовать в качестве адреса получателя за исключением тех случаев, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской.
  6. { <Номер сети>, -1, -1 } Широковещательный пакет для всех подсетей данной сети. Такой адрес недопустимо указывать в качестве адреса отправителя.
  7. { 127, <любой> } Внутренний loopback-адрес хоста. Пакеты с таким адресом отправителя недопустимо передавать за пределы хоста.

(h) { <Номер сети>, <Номер подсети>, 0 }

Номер подсети19. Этот адрес не следует использовать в качестве адреса отправителя за исключением ситуаций, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской. Для других типов каналов пакеты с таким адресом получателя следует отбрасывать без уведомления. Если такие пакеты не отбрасываются, они должны трактоваться, как широковещательные пакеты IP [RFC1812].

Номера сетей распределяются административно, чтобы каждая сеть в масштабе планеты имела уникальный номер.

В адресах IP недопустимо использование значений 0 и -1 в любом из полей <Номер хоста>, <Номер сети> или <Номер подсети>, за исключением специальных случаев, перечисленных выше. Это требование подразумевает, что каждое из полей должно иметь размер не менее 2 битов.

Более подробное рассмотрение широковещательных адресов дается в параграфе 3.3.6.

Хост должен поддерживать подсети IP [IP:3]. В соответствии с этим требованием каждый хост должен иметь маску адреса в форме {-1, -1, 0} (см. параграфы 3.2.2.9 и 3.3.1.1).

Когда хост передает дейтаграмму, в качестве IP-адреса отправителя должен указываться один из IP-адресов этого хоста, но не широковещательный или групповой адрес.

Хост должен отбрасывать без уведомления входящие дейтаграммы, не адресованные ему. Входящая дейтаграмма считается адресованной хосту, если в поле адреса получателя указан:

  1. IP-адрес этого хоста (один из имеющихся);
  2. широковещательный адрес IP, корректный для данной сети;
  3. адрес multicast-группы20, в которую входит данный хост.

В большинстве случаев дейтаграммы, адресованные всем (broadcast) или группе (multicast) хостов, обрабатываются так, будто они направлены по одному из IP-адресов данного хоста. Мы будем использовать термин «конкретный адрес получателя» (specific-destination address) в качестве эквивалента локального IP-адреса хоста. Конкретный адрес получателя должен указываться в заголовках пакетов IP, если такие пакеты не являются групповыми или широковещательными. Конкретный адрес получателя является IP-адресом физического интерфейса, через который дейтаграмма принимается хостом.

Хост должен без уведомления отбрасывать дейтаграммы, содержащие адрес отправителя, противоречащий приведенным в этом параграфе правилам. Проверка корректности может осуществляться на уровне IP или любым протоколом транспортного уровня.

Обсуждение

Дейтаграммы с некорректными адресами могут появляться в результате широковещательной рассылки на канальном уровне дейтаграмм с индивидуальным (unicast) адресом или вследствие ошибок в настройках хостов и маршрутизаторов.

Архитектура хостов Internet должна поддерживать обработку IP-адресов как 32-битовых целых чисел без каких-либо особенностей и избегать применения алгоритмов, требующих знания формата IP-адресов. Если этому правилу не следовать, любые изменения формата или интерпретации адресов в будущем потребуют внесения изменений в программы хостов. Однако, проверка корректности широковещательных и групповых адресов требует отказа от таких правил21.

Разработчики программ должны знать, что приложения, использующие широковещательную адресацию во все подсети (рассмотренный выше вариант f), могут оказаться неработоспособными в некоторых сетях. Широковещание для всех подсетей поддерживается не всеми маршрутизаторами и даже при наличии такой поддержки отдельные администраторы запрещают ее при настройке маршрутизаторов.

3.2.1.4 Фрагментация и сборка: RFC 791, параграф 3.2

Модель Internet требует, чтобы каждый хост поддерживал сборку фрагментов (reassembly). Требования к фрагментации и сборке рассмотрены в параграфах 3.3.2 и 3.3.3.

3.2.1.5 Идентификация: RFC 791, параграф 3.2

При передаче идентичной копии ранее отправленной дейтаграммы хост может сохранять значение идентификационного поля для такой копии.

Обсуждение

Некоторые специалисты по протоколам Internet утверждают, что при передаче копии ранее отправленной дейтаграммы эта копия должна содержать такое же значение поля идентификации, как оригинал. Это обеспечивает два преимущества: (1) если дейтаграмма фрагментирована и некоторые фрагменты теряются, принимающая сторона может восстановить полную дейтаграмму из фрагментов оригинала и копии; (2) перегруженный маршрутизатор может использовать поле IP Identification (и поле Fragment Offset — смещение фрагмента) для удаления дубликатов дейтаграмм из очереди.

Однако наблюдения за реальным трафиком и потерей дейтаграмм в Internet показывают, что использование первого из перечисленных преимуществ маловероятно в силу существования других механизмов (например, перепаковка TCP перед повторной передачей), предотвращающих повторную передачу идентичных дейтаграмм [IP:9]. Следовательно, сохранение идентификационного поля при повторной передаче дейтаграмм может оказаться бесполезным. Кроме того, работающие без организации соединений протоколы (типа UDP) будут требовать взаимодействия с прикладными программами для сохранения значения идентификационного поля при повторной передаче.

3.2.1.6 Тип обслуживания: RFC 791, параграф 3.2

Байт Type-of-Service (тип обслуживания) в заголовке IP поделен на 2 части — поле Precedence (3 старших бита) и поле TOS (5 младших битов). В этом документе термин TOS всегда относится к одноименному полю (младшие 5 битов).

Поле Precedence предназначено для специальных приложений Министерства обороны США. Вопросы использования отличных от 0 значений этого поля выходит за пределы компетенции настоящего документа и стандартов IP. Производители продукции должны консультироваться с агентством DCA22 для получения рекомендаций по использованию поля Precedence в своих реализациях протоколов других уровней23. Однако, разработчики должны понимать, что использование поля Precedence потребует передачи его значения между протоколами разных уровней, как это делается для поля TOS.

Уровень IP должен обеспечивать для транспортного уровня способ установки поля TOS в каждой передаваемой дейтаграмме (по умолчанию все биты имеют нулевые значения). Рекомендуется для уровня IP передавать значения TOS принятых из сети пакетов на транспортный уровень.

Отображения TOS на канальном уровне, определенные в RFC 795, не рекомендуется применять.

Обсуждение

Хотя поле TOS мало использовалось в прошлом, планируется возрастание роли этого поля в ближайшем будущем. Предполагается, что TOS будет использоваться для управления двумя аспектами работы шлюзов — маршрутизацией и алгоритмами использования очередей. В параграфе 2 работы [INTRO:1] рассматриваются требования к прикладным программам для работы с полем TOS.

Значение TOS должно также отображаться на селекторы сервиса канального уровня. Такое решение, например, применяется для организации эффективного совместного использования последовательных каналов разными классами трафика TCP. Однако отображение, предложенное в RFC 795 для сетей, которые входили в состав Internet в 1981 году, сейчас явно устарело.

3.2.1.7 Время жизни: RFC 791, параграф 3.2

Для хостов недопустима передача дейтаграмм с нулевым значением времени жизни (поле TTL).

Для хостов недопустимо отбрасывание дейтаграмм лишь потому, что они приняты со значением поля TTL < 2.

Уровень IP должен обеспечивать для транспортного уровня способ установки поля TTL в каждой передаваемой дейтаграмме. При использовании фиксированного значения TTL требуется обеспечить возможность настройки этого значения. Рекомендуемые значения времени жизни указаны в документе Assigned Numbers24.

Обсуждение:

Поле TTL обеспечивает две функции — ограничение времени жизни сегментов TCP (RFC 793 [TCP:1], стр. 28) и предотвращение петель в маршрутизации Internet. Хотя TTL задает время в секундах, это поле используется также в качестве счетчика интервалов (hop-count), поскольку каждый маршрутизатор должен уменьшать значение поля TTL на 1.

Смысл поля TTL состоит в том, что при уменьшении значения этого поля до 0 дейтаграмма отбрасывается маршрутизатором (но не конечным хостом). Хосты, выполняющие функции маршрутизации, должны следовать этому правилу для TTL, как маршрутизаторы.

Протокол вышележащего уровня может устанавливать значение TTL при реализации поиска в расширенной области для некоторых ресурсов Internet. Такой ход используется также некоторыми средствами диагностики и может оказаться полезным в целом ряде случаев (например, для обнаружения «ближайшего» сервера данного класса с использованием групповой адресации IP). Конкретный протокол транспортного уровня может задать свою границу TTL для максимального времени жизни дейтаграмм.

При использовании фиксированного значения времени жизни оно должно быть достаточно велико (по крайней мере, больше «диаметра» Internet — самого длинного из возможных путей). Разумно устанавливать для времени жизни двойной «диаметр» с учетом продолжающегося расширения Internet.

3.2.1.8 Опции: RFC 791, параграф 3.2

Для транспортного уровня должен обеспечиваться способ задания опций IP, которые будут включаться во все передаваемые дейтаграммы IP (см. параграф 3.4).

Все опции IP (за исключением NOP и END-OF-LIST) из принимаемых дейтаграмм должны передаваться на транспортный уровень или системе обработки ICMP (если дейтаграмма является сообщением ICMP). Оба уровня (транспортный и уровень IP) должны интерпретировать понятные им опции IP, игнорируя остальные.

Ниже в этом документе рассматриваются вопросы поддержки специфических опций IP, требуемой протоколами ICMP, TCP и UDP.

Обсуждение

Передача всех принятых опций IP на транспортный уровень является преднамеренным «нарушением жесткого деления на уровни», которое предназначено для упрощения ввода в будущем новых опций IP, относящихся к транспортному уровню. Каждый уровень должен выбрать все имеющие к нему отношение опции для внутренней обработки и игнорировать остальные опции. Для этого каждая опция IP (кроме NOP и END-OF-LIST) указывает свой размер.

В этом документе не определяется порядок обработки опций каждого заголовка IP. Хосты, использующие множество опций при передаче, должны понимать, что результаты могут зависеть от порядка обработки опций.

Реализация

Программы IP-уровня должны быть устойчивы к сообщениям с опциями, размер которых выходит за допустимые пределы. Известны примеры реализаций, которые входят в бесконечный цикл при получении пакетов с полем опций некорректного размера.

Ниже перечислены требования к отдельным опциям IP:

  1. Security (безопасность) Некоторые среды требуют наличия опции Security в каждой дейтаграмме — такие требования выходят за пределы настоящего документа и стандартов IP. Отметим, что опции безопасности, определенные в RFC 791 и RFC 1038, утратили силу. Для приложений DoD25 разработчикам следует обращаться к документу [IP:8].
  2. Stream Identifier (идентификатор потока) Эта опция устарела – ее недопустимо передавать в пакетах, а на приемной стороне она должна игнорироваться.
  3. Source Route (маршрутизация отправителем) Хост должен поддерживать маршрутизацию отправителем в исходящих дейтаграммах и должен поддерживать себя, как конечного адресата при маршрутизации отправителем.

Если хост получает дейтаграмму, содержащую завершенный маршрут от отправителя26 (completed source route), это говорит о доставке дейтаграммы конечному адресату. Принятые опции (записанный маршрут) должны передаваться на транспортный уровень (или системе обработки сообщений ICMP). Записанные маршруты будут инвертироваться и использоваться для передачи отклика на дейтаграмму (см. Опции IP в главе 4). Когда маршрут возврата построен, требуется корректно сформировать его даже при использовании записи маршрута от хоста-отправителя (см. пункт (B) ниже).

Заголовки IP, содержащие более одной опции Source Route, передавать недопустимо, поскольку маршрутизация в таких случаях будет зависеть от реализации.

В параграфе 3.3.5 приведены правила для хостов, выступающих в качестве промежуточных (intermediate hop) для source route (т. е. пересылающих дейтаграммы с заданной отправителем маршрутизацией).

Обсуждение

При фрагментировании дейтаграмм source-route каждый фрагмент будет содержать копию заданного отправителем маршрута. Поскольку обработка опций IP (включая source route) должна предшествовать сборке фрагментов, исходная дейтаграмма не может быть собрана до тех пор, пока она не будет доставлена конечному адресату.

Предположим, что такая дейтаграмма передается от хоста S на хост D через шлюзы G1, G2, … Gn. В спецификации IP существуют неоднозначности, позволяющие задавать для опций source route дейтаграмм, передаваемых хостом S, вариант (A) или (B):

  1. {>>G2, G3, … Gn, D} <— корректно
  2. {S, >>G2, G3, … Gn, D} <—- ошибка

(>> представляет указатель). При использовании варианта (A) дейтаграмма, принятая хостом D, будет содержать опции {G1, G2, … Gn >>}, с IP-адресами хостов S и D как отправителя и получателя. Если использован вариант (B), принятая хостом D дейтаграмма будет по-прежнему содержать адреса S и D как отправителя и получателя, но опции будут иметь вид {S, G1, …Gn >>}, т. е; хост-отправитель исходной дейтаграммы оказывается первым в маршруте возврата.

  1. Record Route (запись маршрута) Реализация установки и обработки опции Record Route является необязательной.
  2. Timestamp (временная метка) Реализация установки и обработки опции Timestamp является необязательной. При реализации этой опции должны выполняться следующие правила:
      • хост-отправитель должен записывать временную метку в поле Timestamp опций, для которых поле адреса еще не указано или содержит адрес интерфейса данного хоста;
      • принимающий хост должен (если это возможно) добавить текущее время в опцию Timestamp перед передачей опции для обработки на транспортный уровень или ICMP;
      • значение временной метки должно соответствовать требованиям, приведенным в параграфе 3.2.2.8 для сообщений ICMP Timestamp.

3.2.2 Протокол управляющих сообщений Internet — ICMP

Сообщения ICMP делятся на два класса27.

  • ICMP-сообщения об ошибках: Destination Unreachable — адресат недоступен (см. параграф 3.2.2.1) Redirect перенаправление (см. параграф 3.2.2.2) Source Quench — «заткнуть рот отправителю» (см. параграф 3.2.2.3) Time Exceeded — время жизни истекло (см. параграф 3.2.2.4) Parameter Problem — проблема с параметрами (см. параграф 3.2.2.5)
  • Запросы ICMP: Echo — эхо (см. параграф 3.2.2.6) Information — информация (см. параграф 3.2.2.7) Timestamp — временная метка (см. параграф 3.2.2.8) Address Mask — маска адреса (см. параграф 3.2.2.9)

При получении сообщений ICMP неизвестного типа такие сообщения должны отбрасываться без уведомления.

Каждое сообщение ICMP об ошибке включает заголовок IP и по крайней мере первые 8 октетов дейтаграммы, с которой связана ошибка. Заголовок и данные должны в точности соответствовать исходной дейтаграмме, связанной с ошибкой; возможно включение более 8 октетов.

В тех случаях, когда уровень IP должен передавать сообщения ICMP на транспортный уровень, из исходного сообщения должен извлекаться номер протокола IP, используемый для выбора соответствующего объекта транспортного уровня, обеспечивающего обработку ошибок.

Сообщения ICMP об ошибках должны передаваться с нормальными (т. е., 0) значениями битов TOS.

Не допускается передача сообщений ICMP об ошибках в результате приема следующих пакетов28:

  • сообщение ICMP об ошибке;
  • дейтаграммы с групповым или широковещательным адресом IP;
  • дейтаграммы, переданные, как широковещательные на канальном уровне;
  • фрагмент, не являющийся первым;
  • дейтаграммы, для которых адрес отправителя не определен как один хост (например, нулевой адрес, loopback-адрес, широковещательный или групповой адрес, адрес класса E).

Обсуждение

Эти правила будут предотвращать возникновение «широковещательных штормов» при получении хостом ICMP-сообщения об ошибке в ответ на широковещательную дейтаграмму. Например, широковещательный сегмент UDP, адресованный в несуществующий порт, может инициировать лавину дейтаграмм ICMP Destination Unreachable от всех машин, которые не обслуживают указанный в дейтаграмме порт. В большой сети Ethernet такая лавина может привести к остановке сети на несколько секунд в результате возникновения коллизий.

Каждая дейтаграмма, передаваемая в широковещательном режиме в подключенную сеть, должна содержать корректный широковещательный адрес IP для своих получателей (см. параграф 3.3.6). Однако, некоторые хосты не соблюдают это правило, поэтому каждый хост должен проверять широковещательные адреса канального уровня и широковещательные адреса IP.

Реализация

Канальный уровень должен информировать уровень IP о получении широковещательных для канального уровня дейтаграмм (см. параграф 2.4).

3.2.2.1 Destination Unreachable: RFC 792

Для сообщений этого типа определены дополнительные коды:

6 — неизвестна сеть адресата

7 — неизвестен хост-адресат

8 — изолированный хост-отправитель

9 — связь с сетью адресата административно запрещена

10 — связь с хостом-адресатом административно запрещена

11 — сеть недоступна для заданного типа обслуживания

12 — хост недоступен заданного типа обслуживания

Рекомендуется для хостов генерировать сообщения Destination Unreachable с кодами:

2 (Protocol Unreachable — протокол недоступен) — указанный транспортный протокол не поддерживается

3 (Port Unreachable — порт недоступен) — указанный транспортный протокол (например, UDP) не может демультиплексировать дейтаграмму и нет механизма передачи отправителю уведомления.

Принятые сообщения Destination Unreachable должны передаваться на транспортный уровень. Транспортный уровень должен использовать полученную информацию подобающим образом (см. примеры в параграфах 4.1.3.3, 4.2.3.9, 4.2.4). Транспортный протокол, обеспечивающий собственный механизм уведомления отправителя о недоступности портов (например, TCP при передаче сегментов RST), никогда не должен воспринимать сообщения ICMP Port Unreachable для таких же целей.

Сообщение Destination Unreachable, принятое с кодом 0 (сеть), 1 (хост) или 5 (некорректный маршрут от отправителя), может приходить от транзитного маршрутизатора и должно интерпретироваться, как намек (не доказательство) на то, что адресат может быть недоступен [IP:11]. В частности, такие сообщения не могут служить доказательством неработоспособности маршрутизатора (см. параграф 3.3.1).

3.2.2.2 Redirect: RFC 792

Хостам не рекомендуется передавать сообщений ICMP Redirect, поскольку эти сообщения являются прерогативой маршрутизаторов. Хост, получивший сообщение Redirect, должен соответственно скорректировать свою маршрутную информацию. Каждый хост должен быть готов к приему сообщений Host Redirect и Network Redirect для их обработки в соответствии с рекомендациями параграфа 3.3.1.2.

Сообщения Redirect рекомендуется отбрасывать без уведомления, если указанный в них новый шлюз не находится в той же сети, через которую было доставлено сообщение Redirect [INTRO:2, Приложение A], или сообщения Redirect приходят от маршрутизатора, который не указан, как first-hop (первый маршрутизатор) для данного получателя (см. параграф 3.3.1).

3.2.2.3 Source Quench: RFC 792

Хост может передавать сообщения Source Quench в тех случаях, когда он находится или приближается к состоянию необходимости отбрасывания входящих дейтаграмм в результате переполнения буферов сборки или нехватки других ресурсов. Более подробную информацию по этому вопросу вы сможете найти в параграфе 2.2.3 работы [INTRO:2].

При получении сообщения Source Quench уровень IP должен сообщить об этом транспортному уровню (или системе обработки сообщений ICMP). В общем случае транспортный или прикладной уровень должен обеспечивать механизм реакции на сообщения Source Quench для всех протоколов, которые могут передавать последовательность дейтаграмм одному адресату и способны поддерживать достаточно информации о состоянии, чтобы сделать возможной реакцию на такие сообщения. Обработка сообщений Source Quench протоколами TCP и UDP описана в главе 4.

Обсуждение

Сообщения Source Quench могут генерироваться хостами-получателями или некоторыми шлюзами по пути передачи дейтаграмм. Хост, получивший сообщение Source Quench, должен снизить уровень трафика для данного получателя на некоторое время и потом постепенно восстанавливать его. Механизм реакции на сообщения Source Quench может быть реализован на транспортном (для протоколов на основе соединений типа TCP) или прикладном (для протоколов, работающих на базе UDP) уровне. В работе [IP:14] предложен механизм для уровня IP, позволяющий непосредственно реагировать на сообщения Source Quench за счет управления скоростью передачи дейтаграмм, однако это предложение пока является только экспериментальным и не может быть рекомендовано для использования.

3.2.2.4 Time Exceeded: RFC 792

Принимаемые сообщения Time Exceeded должны передаваться на транспортный уровень.

Обсуждение

Маршрутизаторы передают сообщение Time Exceeded с кодом 0 (в процессе передачи) при получении дейтаграмм с нулевым значением TTL. Такая ситуация может говорить о наличии петель в маршрутизации или слишком малом значении TTL при генерации дейтаграммы.

Хост может получать сообщения Time Exceeded с кодом 1 (тайм-аут при сборке) от хоста-адресата, который не смог в заданное время получить все фрагменты и собрать дейтаграмму29. В будущем такие сообщения могут стать частью некоторых процедур MTU discovery, используемых для определения максимального размера дейтаграмм, которые можно передать без фрагментации.

3.2.2.5 Parameter Problem: RFC 792

Для хостов рекомендуется генерировать сообщения Parameter Problem. Принимаемые сообщения Parameter Problem должны передаваться на транспортный уровень и, кроме того, информация о таких сообщениях может передаваться пользователю.

Обсуждение

Сообщения ICMP Parameter Problem передаются хосту-отправителю при обнаружении любых проблем, для которых нет специализированных сообщений ICMP. Появление сообщений Parameter Problem обычно служит сигналом о наличии ошибок в работе протоколов на локальном или удаленном хосте.

Ниже определяется новое значение кода для сообщений Parameter Problem:

1 = отсутствует обязательный параметр.

Обсуждение

Этот код уже используется в военных приложениях при отсутствии опций безопасности.

3.2.2.6 Echo Request/Reply: RFC 792

Каждый хост должен поддерживать функции сервера ICMP Echo, обеспечивающие прием запросов Echo Request и передачу в ответ на них сообщений Echo Reply. Рекомендуется также реализовать интерфейс прикладного уровня для передачи сообщений Echo Request и получения откликов Echo Reply с диагностическими целями.

Сообщения ICMP Echo Request, полученные с групповым или широковещательным адресом IP, можно отбрасывать без уведомления.

Обсуждение

Здесь приводятся беспристрастные результаты дебатов между теми, кто считает, что отклики на широковещательные запросы ICMP Echo обеспечивают эффективные возможности для диагностики, и теми, кто утверждает, что с помощью таких откликов очень легко создать пакетные бури.

IP-адрес отправителя в откликах ICMP Echo Reply должен совпадать с указанным адресом получателя (см. определение в 3.2.1.3) из соответствующего сообщения ICMP Echo Request.

Данные, получаемые в запросе ICMP Echo Request, должны полностью включаться в результирующий отклик Echo Reply. Однако, если передача Echo Reply требует преднамеренной фрагментации, которая не реализована, дейтаграмма должна быть усечена до размера MTU (см. параграф 3.3.3).

Сообщения Echo Reply должны передаваться на пользовательский интерфейс ICMP, если соответствующий запрос Echo Request не направлен на уровень IP.

Если в запросе ICMP Echo Request присутствует опция Record Route и/или TimeStamp, эта опция(и) должна быть обновлена с включением в маршрут текущего хоста и вставлена в заголовок IP отклика Echo Reply без «усекновения». Таким образом сохраняется записанный маршрут для замкнутого кольца.

Если в запросе ICMP Echo Request присутствует опция Source Route, маршрут возврата должен быть инвертирован и вставлен в поле Source Route сообщения Echo Reply.

3.2.2.7 Information Request/Reply: RFC 792

Для хостов рекомендуется не реализовать эти сообщения.

Обсуждение

Пара сообщений Information Request/Reply была предназначена для поддержки самонастраиваемых систем типа бездисковых станций, чтобы позволить им получать IP-адреса в процессе загрузки. Однако протоколы RARP и BOOTP обеспечивают более эффективные механизмы получения хостами IP-адресов.

3.2.2.8 Timestamp/Timestamp Reply: RFC 792

Хост может поддерживать сообщения Timestamp и Timestamp Reply. Если такая поддержка реализована, должно выполняться приведенное ниже правило.

  • Функция сервера ICMP Timestamp возвращает сообщение Timestamp Reply в ответ на каждое принятое сообщение Timestamp. Если эта функция реализована, она должна обеспечивать минимальные вариации задержки (т. е. функция должна быть включена в ядро, чтобы избежать вариаций задержки, связанных с пользовательскими процессами).

В перечисленных ниже случаях обработка Timestamp должна соответствовать правилам для ICMP Echo:

  • Сообщения Timestamp Request с групповыми и широковещательными адресами IP можно отбрасывать без уведомления.
  • IP-адрес отправителя в сообщении Timestamp Reply должен совпадать с адресом получателя, указанным в соответствующем запросе Timestamp.
  • При получении опции Source-route в запросе Timestamp, путь возврата должен инвертироваться при создании опции Source Route для отклика Timestamp Reply.
  • При наличии опции Record Route и/или Timestamp в запросе Timestamp Request, эти опции рекомендуется обновлять с включением текущего хоста и помещать обновленное значение в поле заголовка IP для сообщения Timestamp Reply.
  • Входящие сообщения Timestamp Reply должны передаваться пользовательскому интерфейсу ICMP. Предпочтительной формой временных меток («стандартное значение») является число миллисекунд с полуночи по Стандартному времени (Universal Time). Однако временные метки с таким разрешением могут быть слишком сложны в реализации. Например, во многих системах используются часы, синхронизируемые от электросети (50 или 60 Гц), следовательно, такие системы не могут обеспечить требуемого разрешения. Поэтому допускается отклонение от стандартного значения:
  1. «Стандартное значение» должно обновляться не менее 15 раз в секунду (т. е. не менее 6 младших битов должны быть неопределенными).
  2. Точность «стандартного значения» должна приближаться к точности таймера CPU.

3.2.2.9 Address Mask Request/Reply: RFC 950

Хост должен поддерживать первый и может реализовать все три из перечисленных ниже методов определения адресных масок, соответствующих IP-адресам этого хоста:

  1. статические конфигурационные параметры;
  2. динамическое определение масок в процессе инициализации системы (см. [INTRO:1]);
  3. передача сообщений ICMP Address Mask Request и прием откликов ICMP Address Mask Reply.

Для каждого хоста требуется обеспечить выбор используемого метода.

При использовании метода (3) можно применять Address Mask и должны выполняться следующие условия:

  1. При инициализации хост должен передать с широковещательным адресом сообщение Address Mask Request в подключенную сеть. Если ответ Address Mask Reply не приходит незамедлительно, должно использоваться минимальное число повторов.
  2. До получения отклика Address Mask Reply хосту рекомендуется предполагать, что маска соответствует классу адреса данного хоста (т. е. подключенная сеть не поделена на подсети).
  3. Первое принятое сообщение Address Mask Reply должно использоваться для установки адресной маски, соответствующей частному локальному адресу IP. Это верно даже в тех случаях, когда первое сообщение Address Mask Reply не было запрошено (unsolicited) — в таких случаях оно будет широковещательным и может прийти после того, как хост перестал передавать повторные запросы Address Mask Request. После того, как маска была установлена с использованием Address Mask Reply, последующие сообщения Address Mask Reply должны игнорироваться.

Если сообщения Address Mask запрещены, запросы ICMP Address Mask Request не будут передаваться и все принятые отклики ICMP Address Mask Reply для локального IP-адреса должны игнорироваться.

Для хостов рекомендуется выполнять некоторые разумные проверки устанавливаемых адресных масок (см. «Реализация» ниже).

Недопустима передача системой откликов Address Mask Reply, если эта система не является уполномоченным агентом для адресных масок. Уполномоченный агент может быть хостом или шлюзом, но он должен быть явно настроен, как агент для адресных масок. Получение адресных масок с помощью Address Mask Reply не дает получателю таких прав и не может использоваться, как основание для передачи откликов Address Mask Reply.

При статически заданных адресных масках рекомендуется использовать дополнительный конфигурационный флаг, определяющий для хоста возможность выступать в качестве уполномоченного агента для масок (отвечать на запросы Address Mask Request с использованием маски).

Настроенный в качестве агента хост должен передать в широковещательном режиме сообщение Address Mask Reply для маски инициализируемого интерфейса.

Дополнительные сведения об использовании сообщений Address Mask Request/Reply приведены в параграфе «Инициализация хоста» работы [INTRO:1].

Обсуждение

Хосты, передающие сообщения Address Mask Reply, часто могут порождать серьезные проблемы. Для предотвращения этого отклики Address Mask Reply должны передаваться только уполномоченными агентами, явно указанными администратором сети.

Когда уполномоченный агент получает сообщение Address Mask Request, он будет передавать отклик Address Mask Reply по IP-адресу отправителя запроса. Если сетевая часть этого адреса имеет нулевое значение (см. (a) и (b) в параграфе 3.2.1.3), отклик передается в широковещательном режиме.

Не получив отклика на сообщения Address Mask Request, хост будет предполагать отсутствие агентов или подсетей, но причиной отсутствия отклика может быть временная недоступность агента. Агент будет передавать в широковещательном режиме незапрошенные сообщения Address Mask Reply при своей инициализации для обновления масок на всех хостах, которые были инициализированы в период недоступности агента.

Реализация

Предлагается выполнять следующую проверку адресной маски — в маске должны содержаться не только единицы (1) и старшие 8 битов должны быть установлены в 1 или вся маска должна быть нулевой.

3.2.3 Протокол IGMP (Internet Group Management Protocol)

Протокол IGMP [IP:4] используется хостами и маршрутизаторами одной сети для организации и поддержки членства хостов в multicast-группах. Шлюзы используют этот протокол вместе с протоколом групповой маршрутизации для поддержки трафика IP multicast через Internet.

В настоящее время реализация IGMP является необязательной (см. параграф 3.3.7). Без использования IGMP хосты могут участвовать в multicast-группах подключенной сети.

3.3 Частные вопросы

3.3.1 Маршрутизация исходящих дейтаграмм

Уровень IP выбирает следующий маршрутизатор для каждой передаваемой дейтаграммы. Если получатель находится в подключенной сети, дейтаграмма передается на этот хост напрямую, в остальных случаях дейтаграмма направляется маршрутизатору подключенной сети.

3.3.1.1 Выбор Local/Remote

Для определения принадлежности хоста к подключенной сети должен использоваться следующий алгоритм [см. IP:3]:

  1. Адресная маска (применительно к локальному IP-адресу для многодомного хоста) представляет собой 32-битовое значение, позволяющее выбрать поля номеров сети и подсети в адресах IP.
  2. Если биты IP-адреса получателя, извлеченные с помощью маски30, совпадают с битами IP-адреса отправителя, полученными с такой же маской, это говорит о принадлежности хоста к подключенной сети и дейтаграмма передается напрямую хосту-получателю.
  3. Если условие (b) не выполняется, для доставки дейтаграммы должен использоваться шлюз, определяемый в соответствии с требованиями параграфа 3.3.1.2.

Для некоторых специальных случаев используется иной алгоритм:

  • для групповых и широковещательных адресов ограниченного действия дейтаграммы просто передаются на канальный уровень через соответствующий интерфейс;
  • Для широковещательных дейтаграмм, адресованных всей сети или подсети, могут использоваться стандартные алгоритмы маршрутизации.

IP-уровень хоста должен корректно работать в минимальной сетевой среде (в частности, при отсутствии маршрутизаторов). Если IP-уровень хоста упорно ищет хотя бы один шлюз при инициализации, такой хост не сможет работать в изолированной сети.

3.3.1.2 Выбор шлюза

Для эффективной маршрутизации группы дейтаграмм одному получателю хост-отправитель должен сохранять кэш маршрутов. Хост использует описанный ниже алгоритм для маршрутизации дейтаграмм с использованием кэша (алгоритм предназначен прежде всего для переноса основного бремени маршрутизации на шлюзы) [IP:11].

  • Если кэш маршрутов не содержит информации для интересующего адреса, хост выбирает принятый по умолчанию шлюз и передает дейтаграмму этому маршрутизатору. Соответствующая запись вносится в кэш маршрутов.

  • Если шлюз не является лучшим путем к адресату, он должен будет переслать дейтаграмму наиболее подходящему маршрутизатору и вернуть хосту-отправителю сообщение ICMP Redirect.
  • Получив сообщение Redirect, хост обновляет шлюз в соответствующей записи кэша для того, чтобы последующие дейтаграммы доставлялись по более эффективному пути.

Поскольку маска сети для адреса получателя в общем случае неизвестна, сообщения Network Redirect должны трактоваться аналогично сообщениям Host Redirect, т.е. запись в кэше для хоста-получателя (и только для него) будет обновляться (или создаваться, если ранее ее не было) с учетом нового шлюза.

Обсуждение

Эта рекомендация предназначена для защиты от шлюзов, передающих сообщения Network Redirect в сеть с подсетями в нарушение требований к маршрутизаторам [INTRO:2].

При отсутствии в кэше записи для адреса получателя (если адресат не находится в подключенной сети) уровень IP должен выбрать маршрутизатор из своего списка принятых по умолчанию шлюзов. Уровень IP должен поддерживать множество используемых по умолчанию шлюзов.

В качестве дополнительной возможности уровень IP хоста может реализовать таблицу статических маршрутов. Каждый статический маршрут может включать флаг, определяющий возможность переписывания этого маршрута с помощью ICMP Redirect.

Обсуждение.

Для начала работы хосту требуется знать по крайней мере один используемый по умолчанию шлюз. Эту информацию можно получить из конфигурационного файла или загрузочного сценария (например, BOOTP [INTRO:1]).

Предполагается, что хост может расширять список используемых по умолчанию шлюзов, добавляя в него маршрутизаторы по мере их обнаружения. Например, хост может записывать каждый шлюз, на который пересылает пакеты. Такое решение может оказаться очень эффективным для некоторых случаев, но в иных ситуациях (не все маршрутизаторы одинаковы) оно может порождать проблемы и, поэтому, не рекомендуется.

Статический маршрут представляет собой отображение хоста или сети на тот или иной следующий маршрутизатор; маршрут может также зависеть от типа обслуживания (ToS), рассматриваемого в следующем параграфе. Статические маршруты устанавливаются администратором сети взамен обычных механизмов автоматической маршрутизации и для обслуживания исключительных ситуаций. Однако следует помнить, что статические маршруты являются потенциальным источником ошибок при изменении конфигурации или повреждениях оборудования.

3.3.1.3 Кэш маршрутов

Каждая запись в кэше маршрутов должна содержать следующие поля:

  1. локальный IP-адрес (для многодомных хостов)
  2. IP-адрес получателя
  3. тип(ы) обслуживания ToS
  4. IP-адрес следующего маршрутизатора

Поле (2) может содержать полный адрес получателя или только адрес сети, в которую тот входит. Поле TOS (3) должно присутствовать в записи.

Процедуры работы с кэшем маршрутов описаны в параграфе 3.3.4.2.

Обсуждение

Включение поля Type-of-Service в кэш маршрутов и его рассмотрение в алгоритме маршрутизации будет обеспечивать механизм для применения в будущем маршрутизации по типу обслуживания в сети Internet (см. параграф 3.2.1.6).

Каждая запись в кэше определяет конечную точку пути через Internet. Хотя маршрут между двумя точками может динамически изменяться, характеристики пути передачи остаются почти неизменными в течение продолжительного времени для каждого транспортного соединения между парой хостов.

Следовательно, запись в кэше маршрутов является естественным местом для хранения информации о свойствах пути. Примером такого свойства может служить максимальный размер нефрагментируемой дейтаграммы (см. параграф 3.3.3) или средняя задержка на круговом пути, измеренная транспортным протоколом.

Эти данные в общем случае собираются и используются протоколами вышележащих уровней (например, TCP) или приложениями, использующими протокол UDP. В настоящее время ведутся эксперименты по кэшированию свойств путей описанным здесь способом.

Существуют разногласия по вопросу использования ключей для кэша — только адрес получателя или оба адреса (получателя и отправителя). Сторонники использования только адресов получателей приводят следующие аргументы:

  1. в соответствии с требованиями параграфа 3.3.1.2 сообщения Redirect будут порождать записи, ключами к которым являются адреса получателей; простейшая и наиболее общая схема всегда будет использовать адреса хостов;
  2. уровень IP не всегда может знать адресную маску для сети получателя в сложной среде с подсетями;
  3. использование только адресов хостов-получателей позволит применять полные 32-битовые адреса, обеспечивая восприимчивость к изменению архитектуры Internet.

Сторонники использования в качестве ключей адресов отправителей и получателей также приводят свои аргументы:

  1. экономия памяти;
  2. упрощение структуры данных, простота объединения с таблицами принятых по умолчанию и статических маршрутов (см. ниже);
  3. обеспечивается больше полезного места для хранения информации о свойствах пути, как было упомянуто выше.

Реализация

Кэш должен быть достаточно велик и обеспечивать возможность включения записей для максимального числа хостов-получателей, которое может использоваться в каждый момент времени.

Маршрутная запись в кэше может также включать управляющую информацию, используемую для выбора заменяемой записи. Это может быть реализовано, например, в форме бита recently used (недавно использована) или временной метки для последнего обращения. В целях диагностики рекомендуется сохранять время последнего изменения записи.

При реализации может возникнуть желание снизить издержки на сканирование кэша маршрутов для каждой передаваемой дейтаграммы. Это можно реализовать с помощью хэш-таблицы для ускорения просмотра или путем предоставления ориентированными на соединения протоколами транспортного уровня «советов» или временных указателей на подходящую запись в кэше уровню IP с каждой последовательной дейтаграммой.

Хотя мы рассматривали здесь кэш маршрутов и список используемых по умолчанию шлюзов по-отдельности, на практике их часто объединяют в одну структуру данных — таблицу маршрутизации.

3.3.1.4 Обнаружение «мертвых» шлюзов

Уровень IP должен обеспечивать возможность обнаружения неработающих маршрутизаторов на следующем интервале, включенных в кэш маршрутов, и выбора других маршрутов взамен поврежденных (см. параграф 3.3.1.5).

Процесс обнаружения сбойных маршрутизаторов детально рассмотрен в RFC 816 [IP:11]. До сегодняшнего дня не разработано полного алгоритма, обеспечивающего эффективное обнаружение сбойных маршрутов, хотя предложен целый ряд методик.

  • Не рекомендуется использовать конкретный маршрутизатор при отсутствии признаков его работоспособности.
  • Активные средства проверки типа ping (т.е., использование сообщений ICMP Echo Request/Reply) слишком накладны и не обеспечивают требуемого масштабирования. В частности, следует отметить, что недопустимо проверять состояние первого маршрутизатора путем непрерывной передачи по его адресу запросов ICMP.
  • Даже при отсутствии других способов проверки состояния маршрутизатора ping следует применять только в случаях отсутствия подтверждений работы маршрутизатора при передаче ему реального трафика, что позволяет усомниться в работоспособности маршрутизатора.
  • Чтобы избежать использования ping уровни выше и ниже IP должны обеспечивать возможность получения сведений о состоянии пути в кэше маршрутов за счет использования позитивной (маршрутизатор работает) или негативной информации о состоянии шлюза.

Обсуждение

Если реализация не включает адекватного механизма обнаружения неработающих маршрутизаторов, сбой в маршрутизаторе будет приводить к пропаданию пакетов в «черной дыре». Такие ситуации вызывают массу нареканий со стороны пользователей и весьма сложны для обнаружения.

Механизм обнаружения «мертвых» маршрутизаторов не должен создавать неприемлемой нагрузки на хост, подключенную сеть или соседние маршрутизаторы. Продолжительность детектирования и приемлемый уровень нагрузки в некоторой степени зависят от характера использования хоста, но в общем случае требуется достаточно быстро находить повреждение в ближайшем маршрутизаторе, чтобы не нарушалась работа приложений транспортного уровня, не использующих прямых соединений, за время детектирования сбоя и поиска альтернативного пути.

Передача информации от соседних уровней стека протоколов усложняет интерфейс между уровнями, но может существенно упростить обнаружение сбойных маршрутизаторов. Информация может приходить почти от всех элементов архитектуры IP/TCP, но наиболее важны сведения от транспортного и канального уровней. Ниже приведены примеры такой информации.

  • TCP или другой протокол на основе соединений должен обеспечивать возможность получения негативной информации (например, слишком большое число повторных передач).
  • TCP может давать позитивную информацию после получения (нового) подтверждения о доставке данных. Даже при асимметричном маршруте такое подтверждение свидетельствует об успешной передаче.
  • Сообщения ICMP Redirect от конкретных маршрутизаторов должны использоваться, как позитивные сведения о работе шлюза.
  • Информация канального уровня, который способен эффективно детектировать сбои и сообщать о них (например, с помощью сообщений ARPANET Destination Dead), должна использоваться, как негативные сведения.
  • Сбои в работе ARP или при проверке отображений (преобразований) ARP могут использоваться, как негативная информация для соответствующих адресов IP.
  • Поступление пакетов от конкретного адреса канального уровня является подтверждением работы соответствующего устройства. Однако включение таких данных в сведения о работоспособности шлюзов требует отображения адресов канального уровня на адреса IP и последующей проверки принадлежности этих адресов указанным в кэше маршрутов шлюзам. Такое решение может оказаться недостаточно эффективным.

Отметим, что использование позитивных сведений от каждой полученной дейтаграммы может привести к чрезмерной загрузке системы.

Сведения могут передаваться с использованием требуемых аргументов во все интерфейсы с IP-уровнем, однако некоторые транспортные и прикладные протоколы не способны генерировать корректные анонсы. Такие интерфейсы, следовательно, должны поддерживать нейтральные сведения, поскольку передача анонса с неверным знаком (позитив — негатив) может привести к некорректной работе системы.

Существуют (и широко распространен) иной метод определения «мертвых» маршрутизаторов, но его использование не рекомендуется. Этот метод основан на прослушивании хостом (в пассивном режиме) дейтаграмм протокола IGP31, которыми маршрутизаторы обмениваются между собой с использованием широковещательных адресов. Такое решение имеет существенный недостаток — хосты должны распознавать все протоколы внутренних шлюзов, которые маршрутизатор может использовать (см. [INTRO:2]). Кроме того, такой вариант будет работать только в широковещательной сети.

В настоящее время ping (т. е., использование сообщений ICMP Echo) используется, как механизм проверки работоспособности маршрутизаторов только при возникновении абсолютной необходимости. Отклики на ping гарантируют работоспособность проверяемого интерфейса и связанной с ним машины, но они не гарантируют возможности передачи дейтаграмм в другие интерфейсы маршрутизатора. При наличии сообщений Redirect или иных явных признаков того, что машина является шлюзом, отклики на ping будут говорить о том что маршрутизатор успешно выполняет свои функции. Однако отбрасывание хостом без уведомления пакетов, которые маршрутизатор должен пересылать или перенаправлять, может приводить к тому, что такое предположение перестанет быть верным. Чтобы избежать подобных проблем, разрабатывается новый тип сообщений «are you a gateway?» (это маршрутизатор?).

Реализация

Для обнаружения «мертвых» маршрутизаторов предлагается следующий алгоритм:

  • Связать таймер «повторной маршрутизации» с каждым шлюзом, на который указывает запись в кэше маршрутов. При инициализации таймера устанавливается значение Tr, которое должно быть достаточно мало, чтобы можно было обнаружить неработающий маршрутизатор до того, как транспортное соединение будет разорвано по тайм-ауту.
  • Позитивные сведения будут сбрасывать таймер в Tr, а негативные — обнулять таймер.
  • Всякий раз, когда уровень IP используется для маршрутизации дейтаграммы, должно проверяться состояние таймера. Если таймер содержит нулевое значение, уровень IP будет использовать ping для данного шлюза.
  • Пакеты ping (ICMP Echo) можно при необходимости повторять до N раз. Если за N попыток не было получено ни одного отклика, делается вывод о неработоспособности маршрутизатора и в кэше должен указываться новый шлюз для всех записей, указывающих на сбойный маршрутизатор.

Отметим, что значение Tr обратно пропорционально числу возможных анонсов. Значение Tr должно быть достаточно мало, чтобы обеспечить следующие условия:

  • пакеты ping должны составлять достаточно малую часть (например, <10%) от всех пакетов, передаваемых маршрутизатору с данного хоста;
  • пакеты ping должны передаваться достаточно редко (например, каждые 3 минуты).

Поскольку описанный алгоритм имеет дело с маршрутизаторами, на которые указывают записи в кэше маршрутов, а не с самими записями, для реализации этого алгоритма желательно использовать двухуровневую структуру кэша (например, по типу кэша ARP).

3.3.1.5 Выбор нового шлюза

Если прекративший работать шлюз не является в настоящий момент используемым по умолчанию, уровень IP может незамедлительно переключиться на работу с принятым по умолчанию маршрутизатором. При сбое в работе установленного по умолчанию шлюза уровень IP должен выбрать другой маршрутизатор для использования по умолчанию (предполагается, что может существовать несколько таких шлюзов) на прекратившем работу пути и организовать новые маршруты.

Обсуждение

В случае прекращения работы маршрутизатора другие шлюзы подключенной сети узнают об этом с помощью некоторых протоколов обмена информацией между маршрутизаторами. Однако, это не происходит моментально, поскольку протоколы маршрутизации имеют время обмена порядка 30-60 секунд. Если хост переключится на другой маршрут до того, как выбранный маршрутизатор узнает о сбое, этот маршрутизатор может попытаться переслать дейтаграмму вышедшему из строя шлюзу и послать отправителю дейтаграммы сообщение Redirect, указывающее на «мертвый» маршрутизатор (!). В результате этого может начаться процесс автогенерации обновлений кэша маршрутов до того, как маршрутизатор узнает о прекращении работы другого шлюза. Для предотвращения таких ситуаций логика обнаружения «мертвых» маршрутизаторов должна обеспечивать некоторый гистерезис. Однако на практике упомянутые случаи автогенерации обновлений случаются редко, поскольку обслуживание хоста не может быть восстановлено до тех пор, пока шлюз не организует маршрутную информацию.

Реализация

Одним из вариантов реализации выбора нового маршрута по умолчанию является простой циклический перебор хостом своего списка используемых по умолчанию шлюзов. Другим вариантом является ранжирование маршрутизаторов по уровню приоритета и использование по умолчанию шлюза с максимальным приоритетом. Если в данный момент текущим является маршрутизатор не с высшим приоритетом, хост использует ping (достаточно редкие запросы), чтобы обнаружить восстановление работы маршрутизатора с высшим приоритетом. Частота запросов может быть очень низкой, порядка одного запроса в 3 минуты.

3.3.1.6 Инициализация

Должна обеспечиваться возможность настройки следующих параметров:

  1. IP-адреса;
  2. маски адресов;
  3. список используемых по умолчанию шлюзов с уровнем приоритета для каждого.

Должна обеспечиваться возможность ручной настройки перечисленных параметров и, кроме того, могут использоваться различные методы динамического определения параметров (см. параграф «Инициализация хоста» в [INTRO:1]).

Обсуждение

Некоторые реализации хостов прослушивают протоколы маршрутизации в широковещательной сети для обнаружения шлюзов. Стандартный метод определения используемых по умолчанию шлюзов находится в стадии разработки32.

3.3.2 Сборка фрагментов

Уровень IP должен обеспечивать сборку фрагментов дейтаграмм IP.

Будем обозначать максимальный размер дейтаграммы, которая может быть собрана, как EMTU_R33; иногда используется термин «размер буфера сборки». Значение EMTU_R должно быть не менее 576 (октетов) и рекомендуется обеспечивать возможность настройки этого значения или использования неограниченного буфера сборки. Кроме того, это значение рекомендуется делать не меньше, чем значение MTU для подключенных сетей.

Обсуждение

Фиксированное значение предела EMTU_R не должно встраиваться в программный код, поскольку некоторые протоколы прикладного уровня требуют использования EMTU_R > 576.

Реализация

При реализации можно использовать непрерывный буфер сборки для каждой дейтаграммы или применять более сложные структуры данных, позволяющие собирать дейтаграммы неопределенно большого размера; в последнем случае говорят о неограниченном EMTU_R.

Логически сборка представляет собой просто копирование каждого фрагмента в буфер с использованием указанного смещения. Отметим, что фрагменты дейтаграмм могут перекрываться в результате повторной передачи после нового фрагментирования с сохранением идентификатора.

Некоторую хитрость при сборке представляет учет для определения момента, когда собраны все фрагменты дейтаграммы. Мы рекомендуем алгоритм Кларка [IP:10], не требующий дополнительного пространства памяти для учета. Однако следует отметить, что в отличие от сказанного в [IP:10], заголовок первого фрагмента должен быть сохранен для включения в возможное сообщение ICMP Time Exceeded (тайм-аут при сборке).

Должен обеспечиваться механизм, посредством которого транспортный уровень будет определять значение MMS_R — максимальный размер сообщения, которое может быть принято и собрано в дейтаграмму IP (см. функцию GET_MAXSIZES в параграфе 3.4). Если используется неограниченное значение EMTU_R, величина MMS_R определяется как MMS_R = EMTU_R — 2034.

Для сборки должно задаваться максимальное время (тайм-аут). Значение тайм-аута рекомендуется делать фиксированным, а не привязывать его к оставшемуся времени жизни (TTL). Рекомендуется устанавливать тайм-аут в диапазоне 60 — 120 секунд. По истечении заданного времени частично собранные дейтаграммы должны отбрасываться с передачей сообщений ICMP Time Exceeded хосту-отправителю (если получен начальный фрагмент).

Обсуждение

Спецификация IP говорит, что тайм-аут для сборки должен быть равен оставшемуся времени жизни дейтаграммы (TTL) из заголовка IP, но такое решение не работает должным образом, поскольку маршрутизаторы в общем случае трактуют TTL просто как счетчик интервалов, а не время доставки. Если тайм-аут для сборки слишком мал, дейтаграммы будут отбрасываться без нужды, что приведет к излишней загрузке коммуникационных каналов. Значение тайм-аута должно быть не меньше среднего времени доставки пакетов через Internet. Реальная оценка минимального значения тайм-аута для сборки фрагментов составляет 60 секунд.

Предлагается сохранять в кэше значения времени на передачу дейтаграмм туда и обратно, измеряемые протоколами транспортного уровня, и использовать эти значения для определения величины тайм-аута при сборке. Однако для применения таких методов на практике требуются дополнительные исследования.

При установке слишком большого значения тайм-аута на принимающем хосте может не хватить выделенного для буферов пространства и время жизни сегмента MSL35 [TCP:1] станет слишком велико. Значение MSL управляет максимальной скоростью, с которой могут передаваться фрагменты дейтаграмм при использовании различных значений 16-битового поля идентификации (увеличение MSL снижает максимальную скорость). Спецификация TCP [TCP:1] предполагает для MSL значение 2 минуты. Эта величина устанавливает верхний предел для тайм-аута при сборке.

3.3.3 Фрагментация

Уровень IP может реализовать механизм преднамеренной фрагментации дейтаграмм.

Будем обозначать максимальный размер передаваемой дейтаграммы IP для конкретной комбинации отправитель — получатель (и возможно TOS), как EMTU_S36.

Хост должен реализовать механизм, позволяющий транспортному уровню выяснять значение MMS_S (максимальный размер сообщения транспортного уровня, которое может быть передано) для данной комбинации {отправитель, получатель, TOS} (см. функцию GET_MAXSIZES в параграфе 3.4). Если локальной фрагментации не производится, должно выполняться условие:

MMS_S = EMTU_S - <размер заголовка IP>

и значение EMTU_S не должно быть больше MTU для сетевого интерфейса, соответствующего адресу отправителя дейтаграммы. Отметим, что значение <размер заголовка IP> в этом выражении будет равно 20, если IP не резервирует пространство для вставки опций IP в дополнение к опциям, устанавливаемым на транспортном уровне.

Хост, не реализующий локальную фрагментацию, должен обеспечивать получение транспортным (для TCP) или прикладным (для UDP) уровнем значения MMS_S от уровня IP и передачу дейтаграмм, размер которых не превышает MMS_S.

В общем случае желательно избегать локальной фрагментации и выбирать значение EMTU_S достаточно небольшим для того, чтобы избежать фрагментации на любом из шлюзов по пути доставки. При отсутствии актуальной информации о минимальном значении MTU для пути уровень IP должен использовать значение EMTU_S <= 576, если получатель не находится в подключенной сети (для этого случая используется принятое в сети значение MTU).

Значение MTU для каждого физического интерфейса должно быть настраиваемым.

Реализация уровня IP может использовать флаг конфигурации All-Subnets-MTU (MTU для всех подсетей), показывающий, что значение MTU в подключенной сети будет использоваться и для других подсетей этой сети (но не для других сетей). Таким образом, этот флаг заставляет использовать маску сети взамен маски подсети для выбора значения EMTU_S. Для многодомных хостов флаг All-Subnets-MTU требуется для каждого сетевого интерфейса.

Обсуждение

Выбор корректного размера дейтаграмм для передачи данных является сложной задачей [IP:9].

  1. В общем случае от хоста не требуется прием дейтаграмм IP размером более 576 байтов (включая заголовок) и хост не должен передавать дейтаграмм большего размера без предварительного явного согласования с хостом-получателем. Таким образом, MMS_S задает только верхнюю границу размера дейтаграмм, которые может передавать транспортный уровень. Даже при MMS_S > 556 транспортный уровень должен ограничивать свои сообщения размером 556 байтов при отсутствии информации от хоста-получателя о возможности принимать более крупные сообщения.
  2. Некоторые транспортные протоколы (например, TCP) обеспечивают возможность явного уведомления отправителя о максимальном размере дейтаграмм, которые другая сторона может принимать и собирать [IP:7]. На уровне IP подобного механизма не существует. Транспортный протокол, предполагающий EMTU_R > 576 (см. параграф 3.3.2), может передавать дейтаграммы большого размера другим хостам, поддерживающим такой же протокол.
  3. В идеальном случае хост должен ограничивать свое значение EMTU_S для данного получателя до минимального значения MTU во всех сетях на пути к получателю во избежание фрагментации. Фрагментация IP, будучи формально корректной, может существенно снижать производительность протокола транспортного уровня, поскольку потеря одного фрагмента будет требовать повторной передачи всех фрагментов сообщения [IP:9].

Поскольку практически все сети в среде Internet поддерживают MTU=>576, настоятельно рекомендуется использовать значение 576 для дейтаграмм, передаваемых за пределы локальной сети.

Для определения MTU на данном пути предлагается передавать фрагмент дейтаграммы с нулевым смещением и ожидать отклика ICMP Time Exceeded в результате тайм-аута при сборке (остальные фрагменты не передаются). Такое сообщение будет содержать заголовок самого большого из оставшихся фрагментов в своем теле. Ведутся эксперименты и с более прямыми механизмами, но они еще не адаптированы (см. например RFC 1063).

3.3.4 Локальные многодомные хосты

3.3.4.1 Введение

Многодомный хост имеет множество адресов IP, которые можно рассматривать, как логические интерфейсы. Эти интерфейсы могут быть связаны с одним или различными физическими интерфейсами, а последние могут быть соединены с одной или разными сетями.

Различается несколько вариантов многодомных хостов:

  1. Множество логических сетей Создатели архитектуры Internet предполагали, что каждая физическая сеть будет иметь уникальный номер IP-сети (или подсети). Однако администраторы локальных сетей иногда считают полезным отказ от такого допущения и организуют в одной физической ЛВС множество логических сетей. Если хост, подключенный к такой физической сети, настроен на обслуживание трафика каждой из N различных логических сетей, этот хост будет иметь N логических интерфейсов. Эти интерфейсы могут использовать один или множество физических интерфейсов для подключения к одной физической сети.
  2. Множество логических хостов Когда хост имеет множество адресов IP с одинаковой сетевой частью (или одинаковым номером подсети), используется понятие логического хоста. Логические интерфейсы хоста могут использовать один или множество физических интерфейсов.
  3. Простой вариант В этом случае каждый логический интерфейс отображается на отдельный физический интерфейс, подключенный к своей физической сети. Термин «многодомный» изначально относился только к таким хостам, но сейчас толкование термина существенно расширилось. Хост со встроенными функциями маршрутизации обычно представляет собой простой вариант многодомного хоста. Отметим, однако, что многодомный хост не обязан поддерживать функций маршрутизации (т. е. он может не реализовать пересылку пакетов из одной подключенной сети в другую). Простой многодомный хост представляет наиболее серьезную проблему маршрутизации. Выбор интерфейса (т.е., сети first-hop) может существенно влиять на производительность и даже на доступность удаленных частей Internet.

В заключение отметим также обратный случай (не многодомный хост), когда один логический интерфейс объединяет несколько физических интерфейсов (например, в целях повышения надежности или пропускной способности за счет организации параллельных каналов передачи данных между двумя точками сети две системы могут быть соединены множеством каналов «точка-точка»). Такой вариант мы будем называть мультиплексированием на канальном уровне. При таком мультиплексировании протоколы, расположенные выше канального уровня, просто не знают о наличии множества физических интерфейсов — драйвер устройства на канальном уровне отвечает за мультиплексирование и маршрутизацию пакетов через разные физические интерфейсы.

В архитектуре протоколов Internet элемент протокола транспортного уровня не имеет собственного адреса, используя взамен общий адрес IP. Это задача уровня IP — обеспечивать интерфейс для транспортного и прикладного уровней. В частности, прикладная программа может знать о множестве адресов IP многодомного хоста и выбирать один из них для своего использования.

3.3.4.2 Требования для многодомных хостов

Приведенные здесь правила применяются при выборе IP-адреса отправителя для передачи дейтаграмм многодомными хостами.

  1. Если дейтаграмма передается в ответ на принятую дейтаграмму, адрес отправителя должен совпадать с адресом получателя в принятой дейтаграмме. Более подробное описание требования для вышележащих уровней приведено в параграфах 4.1.3.5 и 4.2.3.7, а также в параграфе «Общие вопросы» [INTRO:1]. В остальных случаях адрес отправителя можно выбирать.
  2. Приложение должно быть способно явно указывать адрес отправителя при организации соединения или запросе.
  3. При отсутствии такой спецификации сетевые программы должны выбирать адрес отправителя в соответствии с приведенными ниже правилами.

С многодомными хостами связаны два ключевых вопроса:

  1. Хост может отбрасывать без уведомления входящие дейтаграммы, в которых адрес получателя не соответствует физическому интерфейсу, принявшему дейтаграмму.
  2. Хост может ограничить себя передачей дейтаграмм IP (не source-route) только через физический интерфейс, соответствующий IP-адресу отправителя в дейтаграмме.

Обсуждение

Разработчики программ для хостов Internet используют две различных по концепции модели многодомных хостов, кратко рассмотренные ниже. В этом документе не отдается преимущества какой-либо модели — обе имеют свои плюсы и минусы. Различия между этими моделями, рассмотренные в (A) и (B), являются опциональными.

  • Модель Strong ES Модель Strong ES37 придает важное значение различиям между хостами и маршрутизаторами (ES/IS) и применительно к ней следует изменить может на должен в пунктах (A) и (B), рассмотренных выше. В этой модели многодомный хост представляется как множество логических хостов в одном физическом компьютере. Применительно к (A) сторонники модели Strong ES отмечают, что механизм автоматической маршрутизации Internet не обеспечивает маршрутизации дейтаграмм в физические интерфейсы, которые не соответствуют адресу получателя. В модели Strong ES расчет маршрута для исходящих дейтаграмм представляет собой отображение:

    маршрут(IP-адрес отправителя, IP-адрес получателя, TOS) -> шлюз

    Адрес отправителя включен, как параметр для того, чтобы выбрать шлюз, напрямую доступный через соответствующий физический интерфейс. Отметим, что эта модель логически требует по крайней мере одного принятого по умолчанию шлюза и предпочитает иметь множество таких шлюзов для каждого IP-адреса отправителя.

  • Модель Weak ES В этой модели различия между хостами и маршрутизаторами не считаются существенными и следует использовать недопустимо вместо может для приведенных выше пунктов (A) и (B). Эта модель может быть более естественной для хостов, прослушивающих протоколы маршрутизации, и просто необходима для хостов с поддержкой встроенной маршрутизации.

Модель Weak ES может приводить к сбоям в работе механизма Redirect. Если дейтаграмма передана физическому интерфейсу, который не соответствует адресу получателя, первый маршрутизатор не сможет понять, когда ему нужно отправить сообщение Redirect. С другой стороны, хост поддерживающий функции маршрутизации, может получать маршрутную информацию без использования сообщений Redirect.

В модели Weak ES расчет маршрута для исходящих дейтаграмм представляет собой отображение:

маршрут(IP-адрес получателя, TOS) -> шлюз, интерфейс
3.3.4.3 Выбор адреса отправителя

Обсуждение

При передаче начального запроса соединения (например, сегмент TCP SYN) или дейтаграммы запроса обслуживания (например, UDP-запрос) транспортный уровень многодомного хоста должен знать, какой адрес отправителя нужно использовать. Если приложение не задало этот адрес, транспортный уровень должен запросить у IP-уровня концептуальное отображение:

GET_SRCADDR(удаленный IP-адрес, TOS) -> локальный IP-адрес

Значение TOS задает тип обслуживания (см. 3.2.1.6) и результатом является нужный адрес отправителя. Для реализации такого отображения предлагаются следующие правила:

  1. когда удаленный адрес Internet относится к одной из (под)сетей, с которыми хост непосредственно соединен, может быть выбран соответствующий адрес отправителя, если нужный интерфейс находится в рабочем состоянии;
  2. можно просмотреть кэш маршрутов для поиска активного маршрута в интересующую сеть через любой сетевой интерфейс; если такой маршрут найден, можно выбрать локальный адрес IP, соответствующий интерфейсу;
  3. аналогичным образом можно использовать и таблицу статических маршрутов (см. 3.3.1.2);
  4. можно просмотреть список используемых по умолчанию шлюзов — если такой шлюз связан с другими интерфейсами, можно выбрать шлюз с максимальным приоритетом.

В будущем для многодомных хостов может быть определен способ передачи маршрутизаторам всех подключенных сетей запросов для определения сети, наиболее подходящей для данного получателя.

Реализация

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

3.3.5 Пересылка Source Route

С учетом приведенных ниже ограничений хост может выступать в качестве промежуточного интервала в маршруте source route, пересылая маршрутизируемые отправителем дейтаграммы на следующий указанный хост.

Однако, при выполнении таких функций квази-маршрутизации хост должен соответствовать всем требованиям, предъявляемым к шлюзам при пересылке дейтаграмм source route [INTRO:2]. Эти требования имеют более высокий приоритет, нежели рассмотренные выше требования к хостам.

  1. TTL (см. параграф 3.2.1.7) Значение поля TTL должно декрементироваться и дейтаграмма может быть отброшена в соответствии с требованиями к шлюзам [INTRO:2].
  2. ICMP Destination Unreachable (см. параграф 3.2.2.1) Хост должен быть способен генерировать сообщения Destination Unreachable со следующими кодами: 4 (Fragmentation Required but DF Set), если дейтаграмма source route не может быть фрагментирована в соответствии с требованиями сети получателя; 5 (Source Route Failed), если дейтаграмму source route невозможно переслать (например, из-за проблем с маршрутизацией или в связи с тем, что следующий интервал при строгом задании маршрута — strict source route — не находится в подключенной сети).
  3. IP-адрес отправителя (см. параграф 3.2.1.3) Маршрутизируемые отправителем дейтаграммы при их пересылке могут иметь (в нормальных условиях имеют) адрес отправителя, который не является одним из IP-адресов пересылающего хоста.
  4. Опция Record Route (см. параграф 3.2.1.8d) Хост, пересылающий дейтаграммы source route, которые содержат опцию Record Route, должен обновлять значение этого поля, вписывая туда информацию о себе.
  5. Опция Timestamp (см. параграф 3.2.1.8e) Хост, пересылающий дейтаграммы source route, которые содержат опцию Timestamp, должен добавлять в нее текущую временную метку в соответствии с правилами для этой опции.

Для определения правил, регулирующих работу хостов при пересылке дейтаграмм source route, мы будем использовать термин «локальная обработка», если следующий шлюз доступен через тот же физический интерфейс, который принял дейтаграмму; в остальных случаях будет использоваться термин «нелокальная обработка».

  • Хост может выполнять локальную обработку без каких-либо ограничений.
  • Хост, поддерживающий нелокальную обработку, должен иметь конфигурационную опцию, позволяющую запретить пересылку и по умолчанию пересылка должна быть отключена.
  • Хост должен соответствовать всем требованиям к шлюзам в части настройки политики фильтрации ([INTRO:2]), ограничивающей нелокальную обработку.

Когда хост получает дейтаграмму с незавершенным маршрутом source route, но по тем или иным причинам не пересылает ее, он должен послать сообщение ICMP Destination Unreachable (код 5, Source Route Failed) отправителю дейтаграммы, если сама дейтаграмма не является сообщением ICMP об ошибке.

3.3.6 Широковещание

В параграфе 3.2.1.3 определены 4 стандартных формы широковещательных адресов IP:

Limited Broadcast — ограниченная область: {-1, -1}

Directed Broadcast — широковещание для сети: {<Номер сети>,-1}

Subnet Directed Broadcast — широковещание для подсети: {<Номер сети>,<Номер подсети>,-1}

All-Subnets Directed Broadcast — широковещание для всех подсетей: {<Номер сети>,-1,-1}

Хост должен распознавать все эти форматы в поле получателя принимаемых дейтаграмм.

Существует класс хостов38, использующих нестандартный формат широковещательных адресов (0 взамен -1). Для всех хостов рекомендуется распознавать и принимать такие нестандартные форматы в полях адреса получателя для входящих дейтаграмм. Хост может использовать конфигурационную опцию для выбора формата (0 или -1) на каждом физическом интерфейсе, но по умолчанию должна применяться стандартная форма (-1).

Когда хост отправляет дейтаграмму по широковещательному адресу канального уровня, IP-адрес получателя должен быть корректным широковещательным или групповым адресом IP.

Для хостов рекомендуется отбрасывать без уведомления дейтаграммы, полученные в широковещательных кадрах канального уровня (см. 2.4), если в них не указан широковещательный или групповой IP-адрес получателя.

Для рассылки широковещательных сообщений в подключенные сети рекомендуется использовать адреса формата Limited Broadcast.

Обсуждение

Использование формата Limited Broadcast взамен Directed Broadcast может повысить устойчивость системы. Проблемы часто бывают вызваны машинами, которые не понимают до конца природы широковещательных адресов (см. 3.2.1.3) или используют собственные идеи о применении таких адресов. Типичным примером из прошлого являются машины, которые не понимают выделение подсетей, но подключены к сети, содержащей последние. Передача сообщений с адресом Subnet Broadcast для подключенной сети будет приводить к тому, что такие машины воспримут эти сообщения как адресованные другому хосту (не им).

Существует также вопрос о возможности передачи дейтаграмм с адресом формата Limited Broadcast через все интерфейсы многодомного хоста, однако этот вопрос выходит за пределы документа.

3.3.7 IP Multicasting

Хост должен поддерживать локальное использование групповой адресации для всех подключенных сетей, на которых возможно отображение IP-адресов класса D на адреса канального уровня (см. ниже). Локальная поддержка групповой адресации включает передачу multicast-дейтаграмм, присоединение к multicast-группам, прием multicast-дейтаграмм и выход из multicast-групп. Сюда включается поддержка всех расширений [IP:4], за исключением протокола IGMP, поддержка которого не является обязательной.

Обсуждение

Протокол IGMP обеспечивает шлюзы, поддерживающие маршрутизацию групповых адресов, информацией, требуемой для обеспечения групповой адресации IP через множество сетей. В настоящее время multicast-маршрутизация находится в стадии экспериментов и доступна не везде. Для хостов, не подключенных к сетям с multicast-шлюзами, или в тех случаях, когда не нужно принимать multicast-дейтаграммы из других сетей, протокол IGMP не используется, поэтому его реализация не является обязательной. Однако, другие расширения [IP:4] в настоящее время рекомендованы в целях обеспечения доступа на уровне IP с локальной групповой адресацией, как альтернатива локальной широковещательной адресации. Предполагается, что реализация IGMP тоже станет обязательной в будущем, когда multicast-маршрутизация получит более широкое распространение.

Если поддержка IGMP не реализована, для хостов рекомендуется сохранять принадлежность к группе all-hosts (все хосты) с адресом 224.0.0.1 при инициализации уровня IP и сохранять принадлежность к этой группе в течение всего периода активности уровня IP.

Обсуждение

Включение в группу all-hosts будет обеспечивать локальную поддержку групповой адресации (например, протокол обнаружения шлюзов) даже без поддержки IGMP.

Отображение IP-адресов класса D на локальные адреса в настоящее время стандартизовано для следующих типов сетей:

  • Ethernet/IEEE 802.3 в соответствии с [IP:4];
  • всех сетей, поддерживающих широковещательную, но не групповую адресацию (IP-адреса класса D отображаются на локальный широковещательный адрес);
  • всех типов каналов «точка-точка» (например, SLIP или HDLC) — в этом случае отображения адресов не требуется. Все групповые дейтаграммы IP передаются в исходном виде, включая локальное кадрирование.

Отображение для сетей других типов будет стандартизовано в будущем39.

Хостам рекомендуется обеспечивать для протоколов верхних уровней или приложений способ определения поддержки групповой адресации IP хостами подключенных сетей.

3.3.8 Сообщения об ошибках

На практике хосты должны возвращать сообщения ICMP об ошибках при обнаружении последних, за исключением тех случаев, когда возврат сообщений ICMP об ошибках специально запрещен.

Обсуждение

Общим явлением в сетях на базе дейтаграмм является «болезнь черных дыр» — дейтаграммы передаются адресату, а от того не приходит никаких откликов. При отсутствии откликов обнаружение проблем становится весьма затруднительным.

3.4 Интерфейс между IP и транспортным уровнем

Интерфейс между IP и транспортным уровнем должен обеспечивать полный доступ ко всем механизмам уровня IP, включая опции, тип обслуживания TOS и время жизни (TTL). Транспортный уровень должен иметь механизм установки интерфейсных параметров или/и обеспечивать передачу таких параметров от приложений.

Обсуждение

Для приложений очень важна возможность использования таких параметров, даже если соответствующие механизмы еще недостаточно эффективны в Internet (например, TOS). Реализация поддержки этих механизмов обеспечивает возможность работы с ними без серьезного изменения программных настроек хоста по мере реализации механизмов в Internet.

Опишем концептуальный интерфейс между транспортным уровнем и IP, как набор процедурных вызовов. Приведенное здесь описание является расширением RFC 791 [IP:1] (параграф 3.3).

  • Передача дейтаграмм

    SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)

    параметры процедуры описаны в RFC 791. Передача параметра Id необязательна (см. 3.2.1.5).

  • Прием дейтаграмм
    RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt)

    Все параметры определены в RFC 791, за исключением SpecDest = указанный адрес получателя дейтаграммы (см. 3.2.1.3)

    Полученный в результате параметр dst содержит адрес получателя дейтаграммы. Поскольку этот адрес может быть широковещательным, должен передаваться параметр SpecDest, не определенный в RFC 791. Параметр opt содержит все опции IP для дейтаграммы и также должен передаваться на транспортный уровень.

  • Выбор адреса отправителя

    GET_SRCADDR(remote, TOS) -> local remote = remote IP address

    TOS = тип обслуживания (Type-of-Service);

    local = локальный адрес IP.

    См. параграф 3.3.4.3.

  • Определение максимального размера дейтаграмм

    GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S

    MMS_R = максимальный размер принимаемого сообщения транспортного уровня;

    MMS_S = максимальный размер передаваемого сообщения транспортного уровня;

    (local, remote, TOS определены выше).

    См. параграфы 3.3.2 и 3.3.3.

  • Сообщение об успешной доставке

    ADVISE_DELIVPROB(sense, local, remote, TOS)

    Параметр sense представляет собой 1-битовый флаг, показывающий тип анонса (позитивный или негативный), описанного в параграфе 3.3.1.4. Остальные параметры были определены выше.

  • Передача сообщения ICMP

    SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) -> result

    (Параметры определены в RFC 791).

    Передача параметра Id не является обязательной (см. параграф 3.2.1.5). Транспортный уровень должен быть способен передавать некоторые сообщения ICMP Port Unreachable или любой из запросов. Эта функция может рассматриваться как частный случай вызова SEND() и отдельное рассмотрение ее диктуется лишь задачами упрощения.

  • Прием сообщения ICMP

    RECV_ICMP(BufPTR ) -> result, src, dst, len, opt

    (Параметры определены в RFC 791).

    Уровень IP должен передавать некоторые сообщения ICMP соответствующим программам транспортного уровня. Эта функция может рассматриваться как частный случай вызова RECV() и указана отдельно лишь для упрощения.

Для сообщений ICMP об ошибках, передаваемых на верхние уровни, данные должны включать исходный заголовок IP и все октеты исходной дейтаграммы, включенные в сообщение ICMP. Эти данные будут использоваться транспортным уровнем для поиска информации о состоянии соединения.

На верхний уровень передаются, в частности, следующие сообщения:

  • Destination Unreachable;
  • Source Quench;
  • Echo Reply (пользовательскому интерфейсу ICMP, если Echo Request передан не с уровня IP);
  • Timestamp Reply (пользовательскому интерфейсу ICMP);
  • Time Exceeded.

Обсуждение

В будущем интерфейс обмена данными между транспортным уровнем и IP может быть расширен (см. параграф 3.3.1.3) для передачи информации о пути.

3.5 Требования к уровню INTERNET

 

Функция

Параграф

Требование

Реализация IP и ICMP

3.1

Обязательно

Обработка remote multihoming на прикладном уровне

3.1

Обязательно

Поддержка local multihoming

3.1

Возможно

Выполнение требований к шлюзам при рассылке дейтаграмм

3.1

Обязательно

Настройка конфигурации для встроенного маршрутизатора

3.1

Обязательно

Режим маршрутизатора по умолчанию выключен1

3.1

Обязательно

Автоматическая настройка по числу интерфейсов1

3.1

Недопустимо

Возможность протоколирования отброшенных дейтаграмм

3.1

Следует

Корректировка счетчиков статистики при отбрасывании

3.1

Следует

Отбрасывание без уведомления пакетов других (не 4) версий

3.2.1.1

Обязательно

Проверка контрольной сумм и отбрасывание без уведомления при ошибках

3.2.1.2

Обязательно

Адресация:
Адресация подсетей (RFC 950)

3.2.1.3

Обязательно

Адресом отправителя должен быть собственный адрес хоста

3.2.1.3

Обязательно

Отбрасывание без уведомления дейтаграмм с некорректным адресом получателя

3.2.1.3

Обязательно

Отбрасывание без уведомления дейтаграмм с некорректным адресом отправителя

3.2.1.3

 Обязательно
Поддержка сборки фрагментов

3.2.1.4

Обязательно

Сохранение идентификатора для копии дейтаграммы

3.2.1.5

Возможно

TOS:
Возможность установки TOS на транспортном уровне

3.2.1.6

Обязательно

Передача принятых значений TOS на транспортный уровень

3.2.1.6

Следует

Использование на канальном уровне отображения RFC 795

3.2.1.6

Не следует

TTL:
Передача пакетов с TTL=0

3.2.1.7

Недопустимо

Отбрасывание принятых дейтаграмм с TTL < 2

3.2.1.7

Недопустимо

Возможность установки TTL на транспортном уровне

3.2.1.7

Обязательно

Возможность установки фиксированного значения TTL

3.2.1.7

Обязательно

Опции IP:
Возможность транспортного уровня передавать опции

3.2.1.8

Обязательно

Передача всех принятых опций на вышележащий уровень

3.2.1.8

Обязательно

Игнорирование неизвестных опций на уровне IP

3.2.1.8

Обязательно

Опции безопасности

3.2.1.8a

Возможно

Передача идентификатора потока

3.2.1.8b

Не следует

Игнорирование опции идентификатора потока

3.2.1.8c

Обязательно

Запись маршрутов

3.2.1.8d

Возможно

Временная метка

3.2.1.8e

Возможно

Опция Source Route:
Инициирование и завершение опции Source Route

3.2.1.8c

Обязательно

Дейтаграммы с заполненным SR передаются на транспортный уровень

3.2.1.8c

Обязательно

Построение корректного (без избыточности) пути возврата

3.2.1.8c

Обязательно

Передача множества опции SR в заголовке

3.2.1.8c

Недопустимо

ICMP:
Отбрасывание без уведомления неизвестных типов ICMP

3.2.2

Обязательно

Включение более 8 октетов исходной дейтаграммы

3.2.2

Возможно

Включение полученных октетов

3.2.2

Обязательно

Передача сообщений ICMP Error транспортному ровню

3.2.2

Обязательно

Передача сообщений ICMP с TOS=0

3.2.2

Следует

Передача сообщений ICMP об ошибках для:
— сообщений ICMP об ошибках

3.2.2

Недопустимо

— широковещательных и групповых пакетов IP

3.2.2

Недопустимо

— широковещательных пакетов канального уровня

3.2.2

Недопустимо

— фрагментов, не являющихся первыми

3.2.2

Недопустимо

— дейтаграмм с неуникальным адресом отправителя

3.2.2

Недопустимо

Возврат сообщений ICMP об ошибках (если не запрещено)

3.3.8

Обязательно

Получатель недоступен (destination unreachable):
Генерация destination unreachable (код 2 и 3)

3.2.2.1

Следует

Передача destination unreachable на верхние уровни

3.2.2.1

 Обязательно
Действия верхних уровней для destination unreachable

3.2.2.1

Следует

Интерпретация dest. unreachable лишь как совета

3.2.2.1

Обязательно

Redirect:
Хост посылает Redirect

3.2.2.2

Не следует

Обновление кэша маршрутов при получении Redirect

3.2.2.2

Обязательно

Обслуживание Redirect для хоста и сети

3.2.2.2

Обязательно

Отбрасывание некорректных сообщений Redirect

3.2.2.2

Следует

Source Quench:
Передача Source Quench при нехватке буферов

3.2.2.3

Возможно

Передача Source Quench на верхний уовень

3.2.2.3

Обязательно

Воздейтсвие верхнего уровня на Source Quench

3.2.2.3

Следует

Передача Time Exceeded на верхний уровень

3.2.2.4

Обязательно

Проблемы с параметрами:
Передача сообщений Parameter Problem

3.2.2.5

Следует

Передача Parameter Problem на верхний уровень

3.2.2.5

Обязательно

Передача сообщений Parameter Problem пользователю

3.2.2.5

Возможно

ICMP Echo Request/Reply:
Эхо-сервер и эхо-клиент

3.2.2.6

Обязательно

Эхо-клиент

3.2.2.6

Следует

Отбрасывание Echo Request для широковещательных адресов

3.2.2.6

Возможно

Отбрасывание Echo Request для групповых адресов

3.2.2.6

Возможно

Использование указанного адреса отправителя в Echo Reply

3.2.2.6

Обязательно

Сохранение данных в Echo Reply

3.2.2.6

Обязательно

Передача Echo Reply на верхний уровень

3.2.2.6

Обязательно

Отражение опций Record Route, Time Stamp

3.2.2.6

Следует

Инверсия и отражение опции Source Route

3.2.2.6

Обязательно

ICMP Information Request/Reply

3.2.2.7

Не следует

ICMP Timestamp/Timestamp Reply:

Возможно

Минимизация вариаций задержки

3.2.2.8

Следует

Отбрасывание без уведомления широковещательных пакетов Timestamp

3.2.2.8

Возможно

Отбрасывание без уведомления групповых Timestamp

3.2.2.8

Возможно

Использование указанного адреса как отправителя TS Reply

3.2.2.8

Обязательно

Отражение опций Record Route и Timestamp

3.2.2.8

Следует

Обращение и отражение опции Source Route

3.2.2.8

Обязательно

Передача на верхний уровень

3.2.2.8

Обязательно

Выполнение правил для «стандартных значений»

3.2.2.8

Обязательно

ICMP Address Mask Request/Reply:
Настройка источника получения Address Mask

3.2.2.9

Обязательно

Поддержка статической конфигурации адресных масок

3.2.2.9

Обязательно

Динамическое получение маски при загрузке

3.2.2.9

Возможно

Получение маски с помощью Addr. Mask Request/Reply

3.2.2.9

Возможно

Повторная передача запроса при отсутствии отклика

3.2.2.9

Обязательно

Использование маски по умолчанию при отсутствии отклика

3.2.2.9

Следует

Обновление маски после получения первого отклика

3.2.2.9

Обязательно

Разумная проверка маски

3.2.2.9

Следует

Неуполномоченная передача откликов Address Mask Reply

3.2.2.9

Недопустимо

Явное указание уполномоченных агентов

3.2.2.9

Обязательно

Статическая конфигурация => флаг Addr-Mask-Authoritative

3.2.2.9

Следует

Широковещательная передача Addr. Mask Reply при инициализации

3.2.2.9

Обязательно

Маршрутизация исходящих дейтаграмм:
Использование маски при выборе локальный/удаленный

3.3.1.1

Обязательно

Работа с подключенной сетью без шлюза

3.3.1.1

Обязательно

Поддержка кэша для ближайших (next-hop) шлюзов

3.3.1.2

Обязательно

Одинаковая трактовка Host/Net Redirect

3.3.1.2

Следует

Использование шлюза по умолчанию при отсутствии записи в кэше

3.3.1.2

Обязательно

Поддержка множества “шлюзов по умолчанию”

3.3.1.2

Обязательно

Поддержка таблицы статических маршрутов

3.3.1.2

Возможно

Флаг: возможность переписывания маршрута путем Redirect

3.3.1.2

Возможно

Использование в качестве ключа адреса хоста, а не сети

3.3.1.3

Возможно

Включение TOS в кэш маршрутов

3.3.1.3

Следует

Возможность обнаружения сбоев в следующем шлюзе

3.3.1.4

Обязательно

Предположение о постоянной доступности маршрута

3.3.1.4

Не следует

Непрерывное использование ping для шлюзов

3.3.1.4

Недопустимо

ping используется только при передаче трафика

3.3.1.4

Обязательно

ping используется только при отсутствии позитивных анонсов

3.3.1.4

Обязательно

Анонсы от верхних и нижних уровней

3.3.1.4

Следует

Смена “умершего” шлюза по умолчанию

3.3.1.5

Обязательно

Возможность ввода конфигурационных параметров вручную

3.3.1.6

Обязательно

Фрагментация и сборка
Возможность сборки входящих дейтаграмм

3.3.2

Обязательно

По крайней мере дейтаграммы размером 576 байтов

3.3.2

Обязательно

Настраиваемое или неограниченное значение EMTU_R

3.3.2

Следует

Возможность транспортного уровня выяснять MMS_R

3.3.2

Обязательно

Передача ICMP Time Exceed при тайм-ауте во время сборки

3.3.2

Обязательно

Фиксированный тайм-аут для сборки

3.3.2

Следует

Передача MSS_S на верхние уровни

3.3.3

Обязательно

Локальная фрагментация исходящих пакетов

3.3.3

Возможно

или отказ от передачи пакетов > MSS_S

3.3.3

Обязательно

Передача не более 576 байтов за пределы сети

3.3.3

Следует

Конфигурационный флаг All-Subnets-MTU

3.3.3

Возможно

Многодомные хосты:
Ответ в таким же адресом, как указанный адрес получателя

3.3.4.2

Следует

Возможность для приложений выбирать локальные адреса IP

3.3.4.2

Обязательно

Отбрасывание дейтаграмм на “некорректном” интерфейсе

3.3.4.2

Возможно

Передача дейтаграмм только через “правильный” интерфейс

3.3.4.2

Возможно

Пересылка SOURCE-ROUTE:
Пересылка дейтаграмм с опцией Source Route

3.3.5

Возможно

Выполнение соответствующих правил для шлюзов

3.3.5

Обязательно

Обновление TTL с помощью правил шлюза

3.3.5

Обязательно

Возможность генерации кодов ошибок ICMP 4, 5

3.3.5

Обязательно

IP-адрес отправителя не указывает на локальный хост

3.3.5

Возможно

Обновление опций Timestamp, Record Route

3.3.5

Обязательно

Настраиваемый переключатель для нелокальных SRing

3.3.5

Обязательно

По умолчанию отключено

3.3.5

Обязательно

Выполнение правил доступа к шлюзу для нелокальных SRing

3.3.5

Обязательно

Если не пересылаем, использовать опцию Dest Unreach (5)

3.3.5

Следует

Широковещание:
Широковещательный IP-адрес отправителя

3.2.1.3

Недопустимо

Нормальный прием широковещательных дейтаграмм форм. 0 и -1

3.3.6

Следует

Опция передачи широковещ. дейтаграмм форм. 0 и -1

3.3.6

Возможно

По умолчанию формат -1

3.3.6

Следует

Распознавание всех форматов широковещательных адресов

3.3.6

Обязательно

Использ. групповых/широковещательных адресов IP в широковещ. канального уровня

3.3.6

Обязательно

Отбрасывание дейтаграмм только с широковещательным адресом канального уровня

3.3.6

Следует

Использование адресов Limited Broadcasct для подключенных сетей

3.3.6

Следует

Групповая адресация:
Поддержка локальной групповой адресации IP (RFC 1112)

3.3.7

Следует

Поддержка IGMP (RFC 1112)

3.3.7

Возможно

Присоединение группы all-hosts при старте

3.3.7

Следует

Поддержка интерфейса с верхним уровнем

3.3.7

Следует

Интерфейс:
Возможность использовать все механизмы IP на транспортном уровне

3.4

Обязательно

Передача идентификатора интерфейса на транспортный уровень

3.4

Обязательно

Передача всех опций IP на транспортный уровень

3.4

Обязательно

Транспортный уровень может передав. некоторые сообщения ICMP

3.4

Обязательно

Передача заданных сообщений ICMP на транспортный уровень

3.4

Обязательно

Включение заголовка IP + 8 или более октетов

3.4

Обязательно

 

Продолжение




RFC 1122 (часть 2)

Часть 1

4. Транспортные протоколы

4.1 Протокол пользовательских дейтаграмм UDP

4.1.1 Введение

Протокол пользовательских дейтаграмм UDP45 [UDP:1] обеспечивает лишь минимальный транспортный сервис — негарантированную доставку дейтаграмм — и предоставляет приложениям прямой доступ к службе дейтаграмм уровня IP. UDP используется приложениями, которым не нужен высокий уровень сервиса TCP, или требуемые приложению коммуникационные службы не поддерживаются протоколом TCP (например, групповая или широковещательная адресация).

Протокол UDP не добавляет почти ничего к службам уровня IP — лишь поддержку контрольных сумм и мультиплексирование по номерам портов. Следовательно, прикладные программы, использующие UDP должны сами решать все задачи сквозного обмена данными, которые обычно обслуживаются протоколами, основанными на соединениях (т. е., обеспечивать повторную передачу при неудачах, управлять потоком данных, контролировать насыщение и т. п). Сложность взаимодействия между IP и TCP заменяется на сложное взаимодействие между UDP и приложениями, использующими протокол UDP.

4.1.2 Общие вопросы

В спецификации UDP ошибки отсутствуют.

4.1.3 Частные вопросы

4.1.3.1 Порты

Общеизвестные порты UDP подчиняются тем же правилам, что и общеизвестные порты для протокола TCP (см. параграф 4.2.2.1).

Если принятая дейтаграмма адресована порту UDP, для которого нет прослушивания, протоколу UDP следует передать отправителю сообщение ICMP Port Unreachable.

4.1.3.2 Опции IP

Протокол UDP должен передавать прикладным программам все опции IP, полученные от уровня IP.

Приложениям должна предоставляться возможность установки опций IP для передаваемых дейтаграмм UDP и протокол UDP должен передавать эти опции уровню IP.

Обсуждение

В настоящее время через UDP передаются только опции Source Route, Record Route и Time Stamp. Однако в будущем число таких опций может быть расширено (например, за счет опций безопасности IP) и реализации протокола UDP, поэтому, не должны делать каких-либо предположений о формате или содержимом передаваемых опций.

Приложениям на основе UDP может потребоваться получение информации source route из дейтаграмм с запросами и установка обратного маршрута в передаваемых откликах.

4.1.3.3 Сообщения ICMP

Протокол UDP должен передавать на уровень приложений все сообщения ICMP об ошибках, полученные от уровня IP. Для реализации этого может использоваться вызов процедуры ERROR_REPORT (см. 4.2.4.1).

Обсуждение

Отметим, что сообщения ICMP об ошибках в результате передачи дейтаграмм UDP принимаются асинхронно. Приложения на базе протокола UDP, желающие получать сообщения ICMP об ошибках, сами отвечают за поддержку состояния, которое обеспечит демультиплексирование принятых сообщений (например, программа может сохранять операцию приема незавершенной). Приложения также отвечают за предотвращение конфликтов в результате задержки сообщений ICMP об ошибках по причине занятости портов.

4.1.3.4 Контрольные суммы UDP

Хост должен поддерживать механизмы генерации и проверки контрольных сумм UDP. Приложения могут управлять процессом генерации контрольных сумм UDP, но по умолчанию протокол должен самостоятельно работать с контрольными суммами.

Если принятая дейтаграмма UDP содержит отличную от нуля и некорректную контрольную сумму, протокол UDP должен отбросить такую дейтаграмму без уведомления. Приложения могут управлять решением вопроса об отбрасывании дейтаграмм без контрольной суммы.

Обсуждение

Некоторые приложения, применяемые преимущественно в локальных сетях, могут отключать использование контрольных сумм UDP в целях повышения производительности. В результате этого природа множества ошибок, которые могут возникать, не будет определена. Эффективность работы с отключенным механизмом контрольных сумм UDP весьма спорна.

Реализация

В реализации контрольных сумм UDP часто допускают одну и ту же ошибку. В отличие от контрольных сумм TCP контрольные суммы UDP не являются обязательными — нулевое значение поля контрольной суммы в заголовке UDP говорит об отсутствии контрольной суммы. Если отправитель получает для контрольной суммы реальной дейтаграммы UDP нулевое значение, он должен установить в поле контрольной суммы значение 65535 (все биты имеют значение 1). От получателя не требуется в таких случаях каких-либо дополнительных действий, поскольку значения 0 и 65535 эквивалентны с точки зрения арифметики с дополнением до 1.

4.1.3.5 Многодомные хосты UDP

При получении дейтаграммы UDP указанный адрес получателя должен передаваться на уровень приложений. Прикладные программы должны иметь возможность указывать IP-адрес отправителя при передаче дейтаграмм UDP или оставлять поле адреса пустым (в этих случаях сетевые программы должны указать подходящий адрес отправителя). Рекомендуется обеспечивать способ передачи выбранного адреса отправителя на прикладной уровень, чтобы программа могла позднее получать отклик на дейтаграмму только от соответствующего интерфейса.

Обсуждение

Приложения на основе запросов/откликов, использующие протокол UDP, должны устанавливать для откликов в качестве адреса отправителя тот же адрес, который был задан для получателя запроса (см. параграф «Общие вопросы» в [INTRO:1]).

4.1.3.6 Некорректная адресация

Дейтаграммы UDP, принятые с некорректным IP-адресом отправителя (например, широковещательный или групповой адрес) должны отбрасываться на уровне UDP или IP (см. 3.2.1.3).

Когда хост передает дейтаграмму UDP, в качестве адреса отправителя должен использоваться IP-адрес (один из возможных) этого хоста.

4.1.4 Интерфейс между уровнем UDP и прикладным уровнем

Интерфейс между приложениями и UDP должен полностью обеспечивать службы, описанные в параграфе 3.4. Таким образом, приложениям на основе UDP требуются функции GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB() и RECV_ICMP(), описанные в 3.4. Например, функция GET_MAXSIZES() может использоваться для определения эффективного значения максимального размера дейтаграмм UDP для конкретной триады {интерфейс, удаленный хост, TOS}.

Программы прикладного уровня должны иметь возможность установки значений TTL и TOS, а также опций IP при передаче дейтаграмм UDP и установленные значения должны прозрачно передаваться на уровень IP. UDP может передавать полученные значения TOS на уровень приложений.

4.1.5 Требования к протоколу UDP

Функция

Параграф

Требование

UDP передает сообщения Port Unreachable

4.1.3.1

Следует

Опции IP в UDP
Передача полученных опций на уровень приложений

4.1.3.2

Обязательно

Приложения могут устанавливать опции при передаче

4.1.3.2

Обязательно

UDP передает опции на уровень IP

4.1.3.2

Обязательно

Передача сообщений ICMP на прикладной уровень

4.1.3.3

Обязательно

Контрольные суммы UDP:

4.1.3.4

Обязательно

Генерация и проверка контрольных сумм

4.1.3.4

Обязательно

Отбрасывание дейтаграмм с ошибкой в контрольной сумме

4.1.3.4

Обязательно

Передача дейтаграмм без контрольной суммы

4.1.3.4

Возможно

По умолчанию контрольная сумма используется

4.1.3.4

Обязательно

Получатель может требовать контрольную сумму

4.1.3.4

Возможно

Многодомные хосты UDP:
Передача указанного адреса получателя приложениям

4.1.3.5

Обязательно

Возможность задания локального адреса отправителя на прикладном уровне

4.1.3.5

Обязательно

Возможность задания шаблона локального адреса отправителя на прикладном уровне

4.1.3.5

Обязательно

Уведомление приклад. уровня об используемом локальном адресе

4.1.3.5

Возможно

Дейтаграммы с некорректным IP-адресом отправителя отбрасываются UDP/IP

4.1.3.6

Обязательно

При передаче дейтаграмм используется только корректный. адрес IP

4.1.3.6

Обязательно

Службы интерфейса UDP c приложениями:
Полный интерфейс IP (см. 3.4) для приложений

4.1.4

Обязательно

Возможность задания TTL, TOS и опций IP при передаче

4.1.4

Обязательно

Передача принятого TOS на уровень приложений

4.1.4

Возможно

4.2 Протокол управления передачей — TCP

4.2.1 Введение

Протокол управления передачей — TCP46 [TCP:1] представляет собой транспортный протокол стека Internet для работы с виртуальными соединениями. TCP обеспечивает гарантированную доставку с сохранением порядка для полнодуплексных потоков данных (октеты или байты). Протокол TCP используется теми приложениями, которым нужен ориентированный на соединения транспортный сервис с гарантией доставки (например, электронная почта SMTP, передача файлов по протоколу FTP, служба виртуальных терминалов Telnet); требования к таким протоколам прикладного уровня описаны в работе [INTRO:1].

4.2.2 Общие вопросы

4.2.2.1 Общеизвестные порты: RFC 793, параграф 2.7

Обсуждение

TCP резервирует номера от 0 до 255 для общеизвестных портов, которые служат для использования стандартных служб через Internet. Остальные номера портов могут свободно распределяться между прикладными процессами. Текущий список общеизвестных портов можно найти в документе Assigned Numbers [INTRO:6]. Предпосылкой задания новых общеизвестный номеров является подготовка для новой службы RFC, достаточно детально описывающего сервис для обеспечения возможности его реализации.

Некоторые системы выделяют еще одну область портов TCP — зарезервированные порты, которые обычно используются для системных задач. Например, зарезервированные порты могут занимать номера от 256 до некоторого значения, принятого в данной системе. Некоторые системы используют защиту общеизвестных и зарезервированных портов, позволяя лишь привилегированным пользователям открывать соединения TCP с использованием этих портов. Такая мера весьма разумна, если хост не делает предположений, что другие хосты используют порты с младшими номерами портов аналогичным образом.

4.2.2.2 Использование флага Push: RFC 793, параграф 2.8

Когда приложение использует серию вызовов SEND без установки флага PUSH, TCP может объединять (агрегировать) данные внутренними средствами, не передавая их. Подобно этому, при получении серии сегментов без бита PSH, TCP может помещать данные во внутреннюю очередь без передачи их принимающему приложению.

Бит PSH не является маркером записи и не связан с границами сегментов. Отправителю рекомендуется удалять последовательные биты PSH при пакетировании данных для передачи сегментов максимального размера.

TCP может реализовать флаги PUSH при вызовах функции SEND. Если флаги PUSH не реализованы, требуется выполнение двух условий при передаче TCP: (1) буфер данных не должен быть бесконечным и (2) должен устанавливаться бит PSH в последнем буферизованном сегменте (т. е., при отсутствии в очереди данных для передачи).

В RFC 793 на страницах 48, 50 и 74 ошибочно указано, что принятый бит PSH должен передаваться прикладному уровню — передача прикладному уровню полученного флага PSH не является обязательной.

От прикладных программ требуется установка флага PUSH при вызове SEND, если требуется форсировать доставку во избежание простоя соединения. Однако протоколу TCP рекомендуется по возможности передавать сегменты максимального размера в целях повышения производительности (см. 4.2.3.4).

Обсуждение

Когда флаг PUSH не реализован для вызовов функции SEND (т. е., интерфейс между прикладным уровнем и TCP использует потоковую модель в чистом виде), ответственность за объединение небольших фрагментов данных в сегменты разумного размера частично ложится на уровень приложений.

В общем случае интерактивный прикладной протокол должен устанавливать флаг PUSH по крайней мере при последнем вызове SEND для каждого набора команд или откликов. Протоколы, передающие большие объемы данных (типа FTP), должны устанавливать флаг PUSH для последнего сегмента файла или при возникновении необходимости предотвратить «застой» буфера.

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

4.2.2.3 Размер окна: RFC 793, параграф 3.1

Размер окна должен трактоваться как беззнаковое целое — если большое окно будет представляться, как окно с отрицательным размером, TCP просто не будет работать. Рекомендуется использовать 32-битовые поля для размера окна передачи и приема в записи с параметрами соединения.

Обсуждение

Известно, что поле размера окна в заголовке TCP слишком мало для высоких скоростей и путей с большой задержкой. Для расширения окна TCP определены экспериментальные опции (см. например, [TCP:11]). С учетом такого расширения при реализации TCP следует рассчитывать на 32-битовые значения размера окна.

4.2.2.4 Указатель срочности: RFC 793, параграф 3.1

Второе предложение этого параграфа содержит ошибку — urgent pointer указывает на порядковый номер последнего (а не следующего за ним) октета в последовательности срочных данных. Описание на стр. 56 (последнее предложение) корректно.

Протокол TCP должен поддерживать последовательности срочных данных любой длины.

Протокол TCP должен информировать прикладной уровень в асинхронном режиме всякий раз, когда указатель Urgent получен при отсутствии ожидающих обработки срочных данных или Urgent упреждает срочные данные в потоке. Для приложений должен обеспечиваться способ определения количества остающихся срочных данных, которые будут прочитаны из соединения, или, по крайней мере, возможность узнать о наличии таких данных.

Обсуждение

Хотя механизм Urgent может использоваться для любых приложений, обычно он применяется для передачи «прерываний» типа команд Telnet (см. параграф Using Telnet Synch Sequence в [INTRO:1]).

Асинхронное уведомление по обдельному каналу (out-of-band) будет позволять приложениям перейти в режим urgent при чтении данных из соединения TCP. Это позволяет контролировать команды, передаваемые приложению, нормальный буфер которого заполнен необработанными данными.

Реализация

Базовый механизм ERROR-REPORT(), описанный в параграфе 4.2.4.1, может использоваться для информирования приложений о приходе важных данных.

4.2.2.5 Опции TCP: RFC 793, параграф 3.1

Протокол TCP должен обеспечивать возможность получения опций TCP в любом сегменте. Протокол TCP должен игнорировать без генерации ошибки любые опции TCP, которые в нем не реализованы, предполагая, что опции содержат поле размера (все определяемые в будущем опции TCP будут также содержать поле размера). Протокол TCP должен быть готов к обработке опций некорректного (например, нулевого) размера без возникновения серьезных проблем — одним из вариантов такой обработки является сброс соединения и протоколирование причины.

4.2.2.6 Максимальный размер сегмента: RFC 793, параграф 3.1

Протокол TCP должен поддерживать опции максимального размера сегмента — MSS47 для приема и передачи [TCP:4].

Для TCP рекомендуется передавать опцию MSS в каждом сегменте SYN при получении MSS, отличного от принятого по умолчанию значения 536; можно передавать эту опцию во всех случаях.

Если опция MSS не получена при организации соединения, протокол TCP должен использовать принятое по умолчанию значение MSS = 536 (576-40) [TCP:4].

Максимальный размер сегмента, реально передаваемого TCP — эффективное значение MSS для передачи, — должен быть меньше MSS для передачи (отражает доступный размер буфера сборки на удаленном хосте) и максимального размера, поддерживаемого уровнем IP:

Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - Ipoptionsize,

где:

  • SendMSS — значение MSS, полученное от удаленного хоста или принятое по умолчанию значение 536, если опция MSS не была получена;
  • MMS_S — максимальный размер сообщений транспортного уровня, которые может передавать TCP;
  • TCPhdrsize — размер заголовка TCP (обычно 20, но может быть больше за счет опций TCP);
  • IPoptionsize — размер всех опций IP, которые TCP будет передавать на уровень IP с этим сообщением.

Значение MSS, которое будет передано в опции MSS, не должно быть больше

MMS_R - 20

где MMS_R — максимальный размер для сообщений транспортного уровня, которые могут быть приняты (и собраны); TCP получает значения MMS_R и MMS_S от уровня IP (см. описание функции GET_MAXSIZES в 3.4).

Обсуждение

Размер сегмента TCP оказывает существенное влияние на производительность. Увеличение сегментов повышает пропускную способность за счет снижения объема заголовков в общем потоке данных и уменьшения времени на обработку этих заголовков. Однако, если пакеты столь велики, что требуется фрагментация IP, эффективность существенно снижается при потере любого фрагмента [IP:9].

Некоторые реализации TCP передают опцию MSS только в тех случаях, когда хост-получатель относится к подключенной сети. Однако в общем случае уровень TCP может не иметь достаточно информации для определения такой принадлежности, поэтому разумно передать уровню IP решение вопроса определения приемлемого значения MTU для пути Internet. Рекомендуется использовать опцию MSS во всех случаях, когда значение отличается от 536 (тогда уровень IP определяет MMS_R в соответствии с параграфами 3.3.3 и 3.4). Предлагаемые для уровня IP механизмы определения MTU в этом случае не будут оказывать влияния на TCP.

4.2.2.7 Контрольная сумма TCP: RFC 793, параграф 3.1

В отличие от контрольных сумм UDP (см. 4.1.3.4), контрольные суммы TCP использовать обязательно. Отправитель должен генерировать контрольную сумму, а получатель должен ее проверять.

4.2.2.8 Диаграмма состояния соединения TCP: RFC 793 параграф 3.2, стр. 23

С диаграммами состояния связано несколько проблем:

  1. Стрелка от SYN-SENT к SYN-RCVD должна помечаться snd SYN,ACK, в соответствии с текстом на стр. 68 и рисунком 8.
  2. Возможна стрелка от состояния SYN-RCVD к состоянию LISTEN при условии получения RST после пассивного открытия (см. стр 70 в RFC 793).
  3. Возможно прямо перейти из FIN-WAIT-1 в состояние TIME-WAIT (см. стр. 75 в RFC 793).
4.2.2.9 Выбор начального порядкового номера: RFC 793, параграф 3.3, стр. 27

Протокол TCP должен использовать начальный порядковый номер, генерируемый в соответствии с текущим временем.

4.2.2.10 Число последовательных попыток открытия: RFC 793, параграф 3.4, стр. 32

На рисунке 8 допущена ошибка — пакет в строке 7 должен быть идентичен пакету в строке 5.

Протокол TCP должен поддерживать одновременные попытки организации соединения.

Обсуждение

Разработчики иногда удивляются, увидев, что при попытке двух приложений одновременно соединиться друг с другом организуется только одно соединение. Это не ошибка, а предусмотренное поведение, поэтому не пытайтесь «исправить» ситуацию.

4.2.2.11 Восстановление по старым дубликатам SYN: RFC 793, параграф 3.4, стр. 33

Отметим, что реализации TCP должны сохранять информацию о соединениях, достигших состояния SYN_RCVD в результате пассивного или активного использования OPEN.

4.2.2.12 Сегмент RST: RFC 793, параграф 3.4

Для протокола TCP следует допускать прием сегментов RST, содержащих данные.

Обсуждение

Предлагается включать в сегменты RST текст в формате ASCII, содержащий код и объяснение причины RST. Стандарта для представления таких данных еще не разработано.

4.2.2.13 Завершение соединений: RFC 793, параграф 3.5

Соединения TCP могут завершаться двумя способами: (1) нормальная процедура завершения TCP с использованием FIN и (2) разрыв в результате передачи одного или нескольких сегментов RST, приводящих к немедленному закрытию соединения. Если соединение TCP закрыто удаленной стороной, локальное приложение должно получить информацию об использованном варианте завершения (1 или 2).

При нормальном завершении соединений TCP обеспечивается гарантированная доставка данных в обоих направлениях. Поскольку оба направления соединений TCP закрываются независимо, возможно существование «полузакрытых» соединений, когда передача данных в одном направлении завершена (и невозможна), а в другом данные продолжают передаваться.

Хост может реализовать «полудуплексные» последовательности закрытия TCP так, что приложение, вызвавшее функцию CLOSE, не сможет после этого читать данные из соединения. Если такой хост вызывает CLOSE в процессе приема данных через соединение TCP или новые данные получены уже после вызова CLOSE, протоколу TCP следует передать сегмент RST для информирования о потере данных.

При активном закрытии соединения оно должно сохраняться в состоянии TIME-WAIT (ожидание) в течение времени 2 x MSL48. Однако возможно восприятие новых вызовов SYN от удаленного TCP для повторного открытия соединения непосредственно из состояния TIME-WAIT, если выполняются следующие условия:

  1. начальный порядковый номер для нового соединения больше максимального порядкового номера, использованного в предыдущем соединении;
  2. происходит возврат в состояние TIME-WAIT, если SYN оказывается дубликатом старого вызова.

Обсуждение

Полнодуплексное завершение соединений TCP для сохранения данных не включено в аналогичный транспортный протокол TP4 стека ISO.

Некоторые системы не поддерживают полузакрытых соединений, поскольку такие соединения не согласуются с моделью ввода-вывода используемой операционной системы. В таких системах приложение после вызова CLOSE уже не сможет читать данные из соединения — такая ситуация называется полудуплексным завершением сеанса TCP.

Изящный алгоритм завершения TCP требует, чтобы активное состояние сохранялось (по крайней мере) на одной из сторон в течение времени 2 x MSL (4 минуты). В течение этого периода пара (удаленный сокет, локальный сокет), определяющая соединение, остается занятой и не может быть повторно использована. Для сокращения периода занятости данной пары портов некоторые реализации TCP позволяют воспринимать новые вызовы SYN в состоянии TIME-WAIT.

4.2.2.14 Передача данных: RFC 793, параграф 3.7, стр. 40

С момента выхода RFC 793 алгоритмы TCP постоянно совершенствовались для повышения эффективности обмена данными. В последующих параграфах этого документа описаны обязательные и рекомендуемые алгоритмы TCP, позволяющие определить, когда следует передавать данные (4.2.3.4) и подтверждения (4.2.3.2) или обновлять окно (4.2.3.3).

Обсуждение

Одним из важных вопросов производительности является «синдром глупого окна» (SWS49), описанный в [TCP:5] — стабильное небольшое увеличение окна, в результате которого происходит существенное снижение производительности TCP. Алгоритмы предотвращения SWS описаны ниже как для передающей (4.2.3.4), так и для приемной стороны (4.2.3.3).

Кратко говоря, причиной SWS является получение информации о расширении окна вправо всякий раз, когда есть буферное пространство, доступное для приема данных, и отправитель использует увеличение окна (невзирая на его незначительность) для передачи большего объема данных [TCP:5]. Результатом этого может стать непрерывная передача крошечных сегментов даже при наличии больших буферов на приемной и передающей стороне. SWS может возникать только при передаче больших объемов данных; если соединение стабильно (передается постоянный поток данных), проблема исчезает. Причиной проблемы является типичная реализация прямого управления окном — ниже описаны алгоритмы для получателя и отправителя, позволяющие решить эту проблему.

Другим важным вопросом производительности TCP является то, что некоторые приложения (особенно системы удаленного входа) на хостах с посимвольным вводом имеют тенденцию передавать потоки однооктетных сегментов данных. Во избежание застоя каждый вызов TCP SEND от таких приложений должен выталкиваться приложением явно или в неявной форме с помощью TCP. В результате может возникнуть поток сегментов TCP, содержащих лишь по одному октету, что ведет к снижению эффективности использования Internet и вносит существенный вклад в насыщение. Алгоритм Nagle, описанный в параграфе 4.2.3.4, обеспечивает простое и эффективное решение этой проблемы. Алгоритм обеспечивает группировку символов для соединений Telnet (это может удивить пользователей, ожидающих эхо после каждого символа, но восприятие пользователей не является проблемой).

Отметим, что алгоритм Nagle и алгоритм предотвращения SWS дополняют друг друга в деле повышения производительности. Алгоритм Nagle предотвращает передачу крошечных сегментов, которая может приводить к незначительному постоянному расширению окна, а алгоритм предотвращения SWS блокирует появление мелких сегментов в результате незначительных сдвигов правого края окна в сторону расширения.

В осторожных реализациях может передаваться два или более подтверждений для каждого принятого сегмента. Предположим для примера, что получатель незамедлительно подтверждает прием каждого сегмента. Когда прикладная программа «потребит» данные и снова увеличит доступное пространство в буфере приема, получатель может передать второе подтверждение отправителю для обновления окна. Экстремальная ситуация возникает при 1-октетных сегментах в соединениях TCP, использующих протокол Telnet для удаленного входа в систему. Встречаются реализации, где на каждое нажатие клавиши пользователем генерируется три передаваемых в ответ сегмента: (1) подтверждение, (2) однобайтовое расширение окна и (3) эхо-символ.

4.2.2.15 Тайм-аут повторной передачи: RFC 793, параграф 3.7, стр. 41

Сейчас известно, что предложенный в RFC 793 алгоритм расчета тайм-аута для повторной передачи не является адекватным (см параграф 4.2.3.1).

Недавняя работа Якобсона [TCP:7] по вопросам насыщения Internet и стабильности повторной передачи TCP предлагает новый алгоритм, объединяющий механизмы slow start (замедленный старт) и congestion avoidance (предотвращение насыщения). Протокол TCP должен реализовать эти алгоритмы.

Если повторный пакет идентичен исходному (сохранены не только границы данных, но также окно и поля подтверждения в заголовке), можно использовать прежнее значение поля идентификации IP (см. 3.2.1.5).

Реализация

Некоторые разработчики TCP выбирают «пакетированный» поток данных, т. е., указывают границы сегмента при передаче в очередь и держат эти границы в очереди на повторную передачу, пока не будет получено подтверждение. В других вариантах (они могут быть проще) пакетирование не происходит до завершения передачи (или повтора), поэтому очередь на повторную передачу в таких реализациях не используется.

В варианте с очередью на повторную передачу производительность TCP может быть повышена за счет повторного пакетирования для сегментов, ожидающих подтверждения при первом тайм-ауте повторной передачи. Оставшиеся сегменты будут объединяться в один сегмент максимального размера с новым идентификатором IP. После этого TCP будет держать новый сегмент в очереди на передачу, пока не будет получено подтверждение. Однако, если первые два сегмента в очереди на повторную передачу превышают максимальный размер сегмента, TCP будет повторять передачу только для первого сегмента из очереди с сохранением идентификационного поля IP.

4.2.2.16 Управление окном: RFC 793, параграф 3.7, стр. 41

Получателям TCP не рекомендуется отсекать часть окна (т. е., перемещать правый край окна влево). Однако отправитель TCP должен быть устойчивым к уменьшению окна, при котором значение «useable window» (см. 4.2.3.4) становится отрицательным.

Если такое происходит, отправителю не следует передавать новые данные, но следует повторить передачу неподтвержденных данных между SND.UNA и SND.UNA+SND.WND. Отправитель также может повторить передачу данных за пределами SND.UNA+SND.WND, но не следует прерывать соединение по тайм-ауту, если доставка данных за пределами правого края окна не подтверждена. Если окно сокращается до нуля, протокол TCP должен проверить его стандартным способом (см. ниже).

Обсуждение

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

4.2.2.17 Проверка нулевого окна: RFC 793, параграф 3.7, стр. 42

Должна поддерживаться проверка нулевого (предлагаемого) окна.

TCP может сохранять свои предлагаемые приемные окна закрытыми в течение неопределенного времени. До тех пор, пока TCP на приемной стороне продолжает слать подтверждения в ответ на проверочные сегменты, протокол TCP на передающей стороне должен сохранять соединение открытым.

Обсуждение

Очень важно помнить, что сегменты ACK, которые не содержат данных, передаются протоколом TCP без гарантий. Если проверка нулевого окна не поддерживается, соединение может быть разорвано при потере сегмента ACK, заново открывающего окно.

Задержка при открытии нулевого окна обычно происходит в тех случаях, когда принимающее приложение останавливает обмен данными с со своим TCP. Например, демон печати может остановить работу при отсутствии в принтере бумаги.

Передающему хосту рекомендуется посылать первую пробу нулевого окна, когда такое окно существовало в течение периода, равного тайм-ауту для передачи (см. 4.2.2.15); интервалы передачи последующих проб рекомендуется экспоненциально увеличивать.

Обсуждение

Эта процедура минимизирует задержку, если условие нулевого окна возникает в результате потери сегмента ACK, содержащего обновление открытия окна. Рекомендуется экспоненциальное увеличение интервала (возможно с заданием максимального значения). Эта процедура напоминает алгоритм повтора передачи и реализацию этих процессов можно объединить.

4.2.2.18 Пассивные вызовы OPEN: RFC 793, параграф 3.8

Каждый пассивный вызов OPEN создает новую запись о соединении в состоянии LISTEN или возвращает ошибку — это не должно оказывать влияния на любые ранее созданные записи соединений.

Реализации TCP, поддерживающие множество пользователей одновременно, должны обеспечивать вызовы OPEN, функционально позволяющие приложениям прослушивать (LISTEN) порт, пока не будет блокировано соединение с таким же номером локального порта в состоянии SYN-SENT или SYN-RECEIVED.

Обсуждение

Некоторые приложения (например, серверы SMTP) могут требовать обслуживания множества одновременных попыток организации соединения. Вероятность отказа при таких попытках может быть снижена за счет предоставления программе возможности прослушивания соединения одновременно с попыткой согласования параметров для ранее организованного соединения.

Реализация

Приемлемые реализации одновременных попыток соединения могут разрешать множество открытых пассивных вызовов OPEN или «клонирование» соединений в состоянии LISTEN из одного пассивного вызова OPEN.

4.2.2.19 Время жизни: RFC 793, параграф 3.9, стр. 51

В RFC 793 указано, что TCP будет запрашивать у IP-уровня передачу сегментов TCP со значением TTL = 60. Это требование устарело и значение TTL для передачи сегментов TCP должно быть настраиваемым (см. 3.2.1.7).

4.2.2.20 Обработка событий: RFC 793, параграф 3.9

Хоть это и не является обязательным, следует поддерживать для TCP очереди с нарушением порядка сегментов TCP (в RFC 793 на стр. 70 сказано возможно).

Обсуждение

Некоторые реализации для небольших хостов не используют очереди сегментов по причине ограниченности буферного пространства. Такое решение может привести к существенному снижению производительности TCP, поскольку потеря единственного сегмента приведет к тому, что все последующие сегменты будут доставляться с нарушением порядка.

В общем случае обработка принятых сегментов должна быть построена так, чтобы сегменты ACK по возможности объединялись. Например, если TCP обрабатывает группу сегментов из очереди, передача сегмента ACK должна происходить только после обработки всех таких сегментов.

Ниже приведены некоторые поправки к параграфу «Обработка событий» в RFC 793.

  1. Вызов CLOSE, состояние CLOSE-WAIT (стр. 61): следует читать LAST-ACK взамен CLOSING.
  2. Состояние LISTEN, проверка SYN (стр. 65, 66): При наличии бита SYN передача сбрасывается, если для сегмента некорректны значения security/compartment или precedence. В документе допущена ошибка. Правильная команда сброса показана ниже:
    <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
  3. Состояние SYN-SENT, проверка SYN (стр. 68): При переходе соединения в состояние ESTABLISHED должны быть установлены следующие переменные:
    SND.WND <- SEG.WND
    SND.WL1 <- SEG.SEQ
    SND.WL2 <- SEG.ACK
  4. Проверка защиты и предпочтений (стр. 71): Первый заголовок ESTABLISHED STATE реально должен быть списком всех состояний, кроме SYN-RECEIVED — ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT.
  5. Вместо «check the SYN bit» (стр. 71) следует читать «In SYN-RECEIVED state and if the connection was initiated with a passive OPEN, then return this connection to the LISTEN state and return. Otherwise check the SYN bit50».
  6. Проверка поля ACK, состояние SYN-RECEIVED (стр. 72: При переходе соединения в состояние ESTABLISHED должны быть установлены переменные, указанные в п. (c).
  7. Проверка поля ACK, состояние ESTABLISHED (стр. 72): ACK является дубликатом, если SEG.ACK =< SND.UNA (знак = пропущен). Аналогичный пропуск в условии обновления окна — должно быть: SND.UNA =<SEG.ACK =< SND.NXT.
  8. USER TIMEOUT (стр. 77):

Лучше будет уведомлять приложение о тайм-ауте, а не о разрешении TCP закрыть соединение (см. также параграф 4.2.3.5).

4.2.2.21 Подтверждение для сегментов из очереди: RFC 793, параграф 3.9

TCP может передавать сегмент ACK, подтверждающий RCV.NXT, когда приходит корректный сегмент, который находится в окне, но не на его левой границе.

Обсуждение

В RFC 793 (стр. 74) нет ясности по вопросу передачи сегмента ACK при получении сегментов с нарушением порядка (т. е., SEG.SEQ не равно RCV.NXT).

Одной из причин передачи подтверждений для сегментов с нарушением порядка доставки может быть поддержка экспериментального алгоритма, названного fast retransmit (ускоренный повтор передачи). При использовании этого алгоритма отправитель передает избыточные подтверждения ACK для указания потери сегмента до истечения тайм-аута повторной передачи. Подсчитывается число полученных подтверждений ACK с одинаковым значением SEG.ACK и одинаковой правой границей окна. При получении большего числа ACK, нежели заданное пороговое значение, предполагается потеря сегмента, начинающегося с SEG.ACK, и выполняется повторная передача без ожидания тайм-аута. Пороговое значение выбирается таким образом, чтобы компенсировать максимальное разупорядочивание сегментов в Internet. Использование этого алгоритма пока слишком непродолжительно, чтобы сделать выводы о его полезности.

4.2.3 Частные вопросы

4.2.3.1 Расчет тайм-аута для повторной передачи

Хост TCP должен поддерживать алгоритмы Karn и Jacobson для расчета тайм-аута повторной передачи RTO.

  • алгоритм Jacobson для расчета взвешенного времени кругового обхода (RTT) включает простое измерение вариаций [TCP:7];
  • алгоритм Karn для выбора способа измерения RTT гарантирует, что случайные значения времени кругового обхода не будут уничтожать результат расчета взвешенного времени обхода [TCP:6].

Такая реализация должна также включать экспоненциальный рост последовательных значений RTO для одного сегмента. Для повторной передачи сегментов SYN рекомендуется использовать такой же алгоритм, как для сегментов данных.

Обсуждение

Известны две проблемы, связанные с расчетом RTO, описанным в RFC 793. Во-первых, при наличии повторов точное измерение RTT становится затруднительным. Во-вторых, алгоритм расчета взвешенного времени кругового обхода неадекватен [TCP:7], поскольку использует некорректное предположение о малости и постоянстве вариаций RTT. Для решения этих проблем используются алгоритмы Karn и Jacobson, соответственно.

Повышение производительности в результате использования этих алгоритмов может колебаться от незначительного до гигантского. Алгоритм Jacobson для включения вариаций измеренных значений RTT особенно важен для низкоскоростных каналов, где естественные вариации размера пакетов приводят к значительным вариациям RTT. Один из разработчиков отметил рост эффективности использования канала 9.6 кбит/с с 10% до 90% в результате реализации алгоритма Jacobson для TCP.

Для инициализации оценочных параметров новых соединений рекомендуется использовать значения:

  1. RTT = 0 секунд;
  2. RTO = 3 секунды (взвешенные вариации инициализируются значением, которое будет влиять на RTO).

Известно, что рекомендованные значения верхней и нижней границ RTO неадекватны для больших сетей. Рекомендуется задавать нижнюю границу в долях секунды (для работы со скоростными ЛВС), а в качестве верхней границы использовать значение 2*MSL (240 секунд).

Обсуждение

Опыт показывает, что приведенные выше параметры инициализации имеют разумные значения, а использование алгоритмов Karn и Jacobson делает поведение TCP разумным, независимо от выбора начальных параметров.

4.2.3.2 Когда передавать сегмент ACK

Хост, получающий поток сегментов данных TCP, может повысить эффективность работы (хостов и Internet) за счет передачи меньшего числа подтверждений ACK для принятых сегментов. Такой метод называется задержкой подтверждений [TCP:5].

Для TCP рекомендуется реализовать задержку ACK, но такая задержка не должна быть слишком большой. В частности, задержка должна быть меньше 0.5 сек. и в потоке сегментов полного размера подтверждения должны передаваться по крайней мере для каждого второго сегмента.

Обсуждение

Задержка ACK позволяет приложениям обновить окно и, возможно, передать незамедлительный отклик. В частности, для систем удаленного доступа с посимвольным вводом задержка ACK может снижать число сегментов, передаваемых сервером, втрое (ACK, обновление окна и эхо-символ передаются в одном сегменте).

В дополнение к этому на некоторых крупных, многопользовательских хостах задержка ACK может существенно снизить затраты на обработку заголовков за счет уменьшения общего числа обрабатываемых пакетов [TCP:5]. Однако, чрезмерная задержка ACK может нарушать определение времени обхода и работу алгоритмов «тактирования» пакетов [TCP:7].

4.2.3.3 Когда передавать Window Update

Протокол TCP должен включать алгоритм предотвращения SWS на приемной стороне [TCP:5].

Реализация

Алгоритм предотвращения SWS на приемной стороне определяет, когда может быть анонсировано расширение правого края окна (обновление окна). Этот алгоритм используют совместно с задержкой подтверждений ACK (см. 4.2.3.2) для определения момента передачи получателю сегмента ACK, содержащего текущее окно. При описании мы будем использовать обозначения, принятые в RFC 793 (см. рис. 4 и 5 в этом документе).

Решением для приемной стороны является предотвращение анонсов смещения правого края окна RCV.NXT+RCV.WND с небольшим инкрементом даже при получении из сети мелких сегментов.

Предположим, что на приемной стороне имеется буфер RCV.BUFF. В любой момент времени RCV.USER октетов из этого буфера может быть связано с данными, которые уже получены и подтверждены, но еще не восприняты пользовательским процессом. Когда соединение находится в статичном состоянии, RCV.WND = RCV.BUFF и RCV.USER = 0.

Сохранение правого края окна неподвижным при получении и подтверждении данных требует чтобы получатель анонсировал пространство, которое меньше его реального буфера, т. е., получатель должен задавать значение RCV.WND, которое позволит сохранить постоянной сумму RCV.NXT+RCV.WND при возрастании RCV.NXT. Таким образом, общее пространство буфера RCV.BUFF в общем случае делится на три части:

    |<------- RCV.BUFF ---------------->|
         1              2            3
----|---------|------------------|------|----
           RCV.NXT               ^

(фиксированная часть)

  1. RCV.USER — полученные, но не воспринятые приложением данные;
  2. RCV.WND — пространство, анонсируемое отправителю;
  3. Reduction — доступное, но еще не анонсированное пространство.

Предлагаемый алгоритм предотвращения SWS для приемной стороны сохраняет фиксированное значение RCV.NXT+RCV.WND до тех пор, пока выполняется условие:

RCV.BUFF - RCV.USER - RCV.WND >= min(Fr * RCV.BUFF, Eff.snd.MSS)

гле Fr — часть, рекомендуемое значение которой составляет 1/2, а Eff.snd.MSS — эффективное значение MSS для передачи в данном соединении (см. 4.2.2.6). При выполнении условий неравенства устанавливается RCV.WND = RCV.BUFF-RCV.USER.

Отметим, что общим эффектом этого алгоритма является анонсирование RCV.WND с инкрементом Eff.snd.MSS (для разумных буферов на приемной стороне Eff.snd.MSS < RCV.BUFF/2). Отметим также, что приемная сторона должна использовать свое значение Eff.snd.MSS, предполагая, что оно совпадает со значением для передающей стороны.

4.2.3.4 Когда передавать данные

Протокол TCP должен поддерживать механизм предотвращения SWS на приемной стороне.

Для протокола TCP рекомендуется реализация алгоритма Nagle [TCP:9], позволяющего объединять короткие сегменты. Однако, приложениям должен обеспечиваться способ запрета алгоритма Nagle для отдельных соединений. Во всех случаях для передачи данных действуют также ограничения, вносимые алгоритмом Slow Start (см. 4.2.2.15).

Обсуждение

Алгоритм Nagle в общем случае действует следующим образом:

При наличии неподтвержденных данных (т. е., SND.NXT > SND.UNA) в буферы TCP передаются все пользовательские данные (не принимая во внимание бит PSH), пока остающиеся данные не будут подтверждены или пока TCP не сможет передать сегмент полного размера (Eff.snd.MSS байтов; см. 4.2.2.6).

Некоторые приложения (например, отображение окон в реальном масштабе времени) требуют запрета алгоритма Nagle, чтобы небольшие сегменты данных передавались с максимальной скоростью.

Реализация

Алгоритм предотвращения SWS на передающей стороне реализуется сложней, нежели на приемной, поскольку отправитель не знает (явно) размер буферного пространства RCV.BUFF на приемной стороне. Проверенным вариантом является расчет отправителем значения максимального окна передачи для соединения Max(SND.WND) и использование полученного значения для оценки RCV.BUFF. К сожалению, возможна только оценка буфера, поскольку приемная сторона может время от времени менять значение RCV.BUFF. Чтобы избежать застоя соединений в результате этого, необходимо использовать значение тайм-аута для форсирования передачи данных, имеющего преимущество перед алгоритмом предотвращения SWS. На практике форсирование передачи по тайм-ауту должно происходить редко.

Доступное окно имеет размер ([TCP:5]):

U = SND.UNA + SND.WND - SND.NXT

т. е., предлагаемое окно меньше, чем размер переданных, но не подтвержденных данных. Если D указывает количество данных в очереди на передачу TCP, рекомендуется использовать следующий набор правил для передачи данных:

  1. при достижении максимального размера передаваемого сегмента, т. е.:
    min(D,U) >= Eff.snd.MSS;
  2. или установлен флаг push и все данные из очереди могут быть переданы, т. е.:
    [SND.NXT = SND.UNA and] PUSHED and D <= U

    (условие в квадратных скобках вносится алгоритмом Nagle);

  3. или по крайней мере Fs-ая часть максимального окна может быть передана, т. е.:
    [SND.NXT = SND.UNA and] min(D.U) >= Fs * Max(SND.WND);
  4. или установлен флаг PUSH и достигнут тайм-аут.

Fs представляет собой часть, рекомендуемое значение которой составляет 1/2. Значение тайм-аута должно составлять 0.1 — 1.0 сек. Может оказаться удобным объединение этого таймера с таймером проверки нулевого окна, описанным в параграфе 4.2.2.17.

В заключение отметим, что использование алгоритма предотвращения SWS рекомендуется взамен алгоритма sender-side, описанного в работе [TCP:5].

4.2.3.5 Сбои в соединениях TCP

Многократные повторы передачи одного сегмента TCP свидетельствуют о наличии сбоев на удаленном хосте или пути через Internet. Эти сбои могут быть кратковременными или продолжительными. При возникновении таких ситуаций хост должен использовать перечисленные ниже процедуры [IP:11]:

  1. Существуют два пороговых значения R1 и R2 для измерения числа повторов передачи одного сегмента. Для задания R1 и R2 могут использоваться единицы времени или число повторов передачи.
  2. При достижении числа повторов R1 передается негативный анонс (см. 3.3.1.4) на уровень IP для включения диагностики работоспособности шлюзов.
  3. При достижении порога R2 (превышает R1) соединение закрывается.
  4. Приложениям должна обеспечиваться возможность установки порога R2 для отдельного соединения. Например, интерактивные соединения могут устанавливать для R2 «бесконечное» значение, предоставляя пользователю самостоятельно решать вопрос о разрыве соединения.
  5. Протоколу TCP следует информировать приложения о проблемах с доставкой (если это не запрещено приложением; см. 4.2.4.1), при достижении порога R1, но до порога R2. Такая информация позволяет программам удаленного доступа (типа Telnet) информировать пользователя о проблемах.

Следует устанавливать для R1 значение, соответствующее по крайней мере 3 повторам при текущем значении RTO. Для R2 следует задавать значение не менее 100 секунд.

При попытке создать соединение TCP может наблюдаться сбой с многократным повтором сегмента SYN, получением сегмента RST или сообщения ICMP Port Unreachable. Повторные передачи SYN должны обрабатываться обычным способом (как для данных), включая уведомление прикладного уровня.

Однако, значения R1 и R2 для сегментов SYN могут отличаться от значения для сегментов данных. В частности, значение R2 для SYN должно быть достаточно велико, чтобы обеспечивать повторные передачи по крайней мере в течение 3 минут. Приложение может закрыть соединение и раньше (например, задав число попыток).

Обсуждение

Для некоторых путей Internet время организации соединения достаточно велико и число таких путей может существенно возрасти в будущем.

4.2.3.6 TCP Keep-Alive

Разработчики могут включать в свои реализации TCP пакеты keep-alive, хотя такая практика не принята повсеместно. При включении keep-alive приложениям должна обеспечиваться возможность запрета таких пакетов для отдельных соединений TCP и по умолчанию такие пакеты должны быть запрещены.

Пакеты keep-alive должны передаваться только при отсутствии пакетов данных или подтверждений в течение заданного интервала. Значение этого интервала должно быть настраиваемым и по умолчанию должно составлять не менее 2 часов.

Очень важно помнить, что для сегментов ACK, не содержащих данных, протокол TCP не обеспечивает гарантии доставки. Следовательно, при реализации механизма keep-alive сбои в ответ на специфические проверки не должны интерпретироваться как «умирание» соединения.

Рекомендуется передавать сегменты keep-alive без данных, однако можно настраивать протокол на передачу сегментов keep-alive, содержащих один произвольный октет для совместимости с ошибочными реализациями TCP.

Обсуждение

Механизм keep-alive периодически проверяет удаленную сторону при простое соединения, даже если отсутствуют неподтвержденные данные. Спецификация TCP не включает механизма keep-alive, поскольку он: (1) может обрывать нормальные соединения в результате транзитных сбоев Internet, (2) приводит к ненужному расходу полосы и (3) повышает расходы для соединений Internet с платным трафиком.

Некоторые реализации TCP все же включают механизм keep-alive. Для подтверждения работоспособности бездействующего соединения такие реализации передают пробные сегменты, предназначенные для получения отклика удаленной стороны. Такие сегменты в общем случае включают поле SEG.SEQ=SND.NXT-1 и могут также содержать один произвольный октет данных. Отметим, что для бездействующих соединений SND.NXT=RCV.NXT, поэтому значение SEG.SEQ будет выходить за пределы окна. Следовательно, пробный сегмент будет заставлять приемник вернуть сегмент подтверждения, говорящий о том, что соединение сохраняет работоспособность. Если удаленная сторона разорвала соединение, она будет возвращать RST вместо подтверждающего сегмента.

К несчастью, в некоторых не вполне корректных реализациях TCP возникают сбои при получении сегмента с SEG.SEQ = SND.NXT-1, если такой сегмент не содержит данных. Приложение может дополнительно проверить, способна ли удаленная сторона корректно отвечать на пакеты keep-alive без вставленного в них произвольного октета данных.

Механизм TCP keep-alive следует использовать только в серверных приложениях, которые могут неограниченно долго сохранять соединения, потребляя без нужды сетевые ресурсы, даже если клиент по тем или иным причинам разорвал или потерял соединение.

4.2.3.7 Многодомные хосты TCP

Если приложение на многодомном хосте не указывает локальный IP-адрес при активной организации соединения TCP, протокол TCP должен запрашивать уровень IP для получения локального IP-адреса до (первой) передачи SYN. Более подробные сведения приведены в параграфе 3.4 — функция GET_SRCADDR().

Во всех остальных случаях через это соединение был уже передан или принят сегмент и протокол TCP должен использовать тот же локальный адрес, который применялся для предыдущего сегмента.

4.2.3.8 Опции IP

При передаче опций на уровень TCP со стороны IP, протокол TCP должен игнорировать непонятные опции.

TCP может поддерживать опции Time Stamp и Record Route.

Приложениям должна обеспечиваться возможность задания source route при активной организации соединения TCP и этот маршрут должен иметь преимущество перед source route из принятой дейтаграммы.

При пассивной организации соединения TCP и достижении пакетом конечной точки, указанной опцией IP Source Route (содержащей путь возврата), протокол TCP должен сохранить маршрут возврата и использовать его для всех сегментов, передаваемых через это соединение. Если в последующих сегментах приходит иной маршрут source route, новый маршрут следует использовать взамен прежнего.

4.2.3.9 Сообщения ICMP

Протокол TCP должен передавать сообщения ICMP об ошибках, полученные с уровня IP, соединениям, с которыми связаны ошибки. Демультиплексирование осуществляется на основе заголовков IP, содержащих сообщения ICMP.

  • Source Quench Протокол TCP должен реагировать на сообщения Source Quench замедлением передачи через соединение. Для реализации этого следует использовать процедуру как при тайм-ауте повторной передачи.
  • Destination Unreachable — коды 0, 1, 5 Поскольку такие сообщения говорят о кратковременных ошибках, протокол TCP не должен прерывать соединение; рекомендуется передать эту информацию приложению.

Обсуждение

Протокол TCP может сообщать о некритичных ошибках непосредственно прикладному уровню с помощью процедуры ERROR_REPORT; допускается также информировать приложения только при возникновении тайм-аута для соединения TCP.

    • Destination Unreachable — коды 2-4 Эти сообщения говорят о серьезных ошибках, поэтому следует разрывать соединения TCP.
    • Time Exceeded — коды 0, 1 Эти ошибки трактуются аналогично Destination Unreachable с кодами 0, 1, 5 (см. выше).
    • Parameter Problem Эти ошибки трактуются аналогично Destination Unreachable с кодами 0, 1, 5 (см. выше).
4.2.3.10 Проверка корректности удаленного адреса

Реализация TCP должна отбрасывать (как ошибочные) локальные вызовы OPEN с некорректным IP-адресом удаленной стороны (например, широковещательный или групповой адрес).

Входящие запросы SYN с некорректным адресом отправителя должны игнорироваться уровнем TCP или IP (см. 3.2.1.3).

Реализация TCP должна без уведомления отбрасывать все входящие сегменты SYN с широковещательными или групповыми адресами.

4.2.3.11 Картины трафика TCP

Реализация

Спецификация протокола TCP [TCP:1] предоставляет разработчикам свободу выбора алгоритма для контроля за потоком сообщений через соединение — пакетирование, управление окном, передача подтверждений и т. д. Выбрать алгоритм непросто, поскольку протокол TCP должен адаптироваться к различным картинам трафика. Опыт показывает, что разработчикам TCP требуется проверять реализацию для двух экстремальных вариантов трафика:

  • Односимвольные сегменты Даже при использовании передающей стороной алгоритма Nagle соединения TCP для удаленного входа в систему через ЛВС с малой задержкой будут порождать поток односимвольных сегментов. Если на удаленном терминале включен режим эхо-символов, принимающая сторона будет в общем случае генерировать отклик на каждый принятый символ.
  • Передача больших объемов данных При использовании TCP для передачи большого объема данных поток почти полностью будет состоять из сегментов размером MSS (эффективное значение). Хотя TCP использует пространство порядковых номеров с байтовой (октетной) гранулярностью, при передаче больших объемов данных должны учитываться только сегменты.

Опыт показывает что эффективные и корректные реализации TCP хорошо работают в обоих экстремальных случаях.

Наиболее важным средством для проверки новых реализаций TCP являются программы трассировки пакетов. Многолетний опыт показывает важность трассировки для различных картин трафика при использовании с другими реализациями TCP для поиска ошибок.

4.2.3.12 Эффективность

Реализация

На основании накопленного опыта выработаны рекомендации для разработчиков TCP.

    1. Не копируйте данные При передаче больших объемов данных наибольшую нагрузку на процессор создает копирование данных из одного места в другое для определения контрольной суммы. Важно минимизировать число копий данных TCP. Поскольку передача данных через шину памяти может существенно ограничивать скорость, полезно объединять копирование данных с вычислением контрольных сумм.
    2. Внимательно относитесь к вычислению контрольных сумм Хорошие программы вычисления контрольных сумм TCP обычно в 2-5 раз быстрее, по сравнению с простой реализацией определений CRC. Для эффективного вычисления контрольных сумм требуется программирование высокого класса (см. [TCP:10]).
    3. Код общего назначения Обработка протокола TCP может быть сложной, но для большинства сегментов используется лишь несколько простых решений. Посегментная обработка существенно ускоряется за счет эффективного кодирования основной линии с минимизацией числа принимаемых решений для наиболее вероятных ситуаций.

4.2.4 Интерфейс между TCP и прикладным уровнем

4.2.4.1 Асинхронные отчеты

Должен обеспечиваться механизм информирования приложений о некритичных ошибках TCP. В общем случае это реализуется с помощью прикладной процедуры ERROR_REPORT, которая может асинхронно [INTRO:7] вызываться с транспортного уровня:

ERROR_REPORT(local connection name, reason, subreason)

Кодирование причин ошибок не рассматривается здесь, однако сообщения, асинхронно передаваемые приложениям, должны включать:

  • полученные сообщения ICMP об ошибках (см. 4.2.3.9);
  • информацию о многократных повторах передачи (см. 4.2.3.5);
  • анонсы указателей срочности (см. 4.2.2.4).

Для программ, которые не хотят получать информации об ошибках ERROR_REPORT, следует отключить вызов процедуры.

Обсуждение

Сообщения в общем случае включают сведения о некритичных ошибках, которые можно игнорировать без вреда для большинства приложений. Предполагается, что по умолчанию передача отчетов об ошибках запрещена, но это не обязательно.

4.2.4.2 Тип обслуживания

Прикладному уровню должна быть обеспечена возможность задавать тип обслуживания TOS для сегментов, передаваемых через соединение. Следует также обеспечивать приложениям возможность изменения TOS в процессе использования соединения. Протоколу TCP следует передавать текущее значение TOS без изменений на уровень IP при передаче сегмента в соединение.

Значение TOS задается независимо для каждого направления в соединении, поэтому принимающее приложение будет задавать TOS для сегментов ACK.

TCP может передавать приложениям последнее использованное значение TOS из принятых сегментов.

Обсуждение

Некоторые приложения (например, SMTP) меняют тип обмена данными во время соединения и, следовательно, могут пожелать изменить значение TOS.

Отметим также, что вызов OPEN в соответствии с RFC 793 включает параметр options, в котором могут быть заданы опции IP (source route, record route, timestamp).

4.2.4.3 Вызов Flush

Некоторые реализации TCP включают вызовы FLUSH, которые очищают очередь передачи TCP от всех данных, помещенных в нее с помощью вызовов SEND из прикладных программ, но сохраняет данные, остающиеся в правой части текущего окна передачи. Таким образом, эта функция удаляет из очереди как можно больше данных без потери синхронизации порядковых номеров. Это полезно для реализации функций типа abort output в Telnet.

4.2.4.4 Многодомные хосты

Пользовательский интерфейс, описанный в параграфах 2.7 и 3.8 RFC 793, требует расширения для многодомных хостов. Функция OPEN должна поддерживать необязательный параметр с локальным адресом:

OPEN( ... [local IP address,] ... )

Обсуждение

Некоторые приложения на базе TCP (например, FTP) требуют указывать локальный IP-адрес, который используется для организации соединения.

Реализация

Пассивный вызов OPEN с заданным локальным адресом IP будет ждать входящего запроса на соединение с этим адресом. Если параметр не указан, пассивный вызов OPEN будет ждать запроса на входящее соединение по любому локальному адресу IP и потом связывать локальный IP-адрес с этим соединением.

Для активных вызовов OPEN указанный локальный IP-адрес будет использоваться для организации соединения. Если параметр не задан, сетевая программа будет выбирать подходящий локальный адрес IP (см. 3.3.4.2) для организации соединения.

4.2.5 Требования к протоколу TCP

Функция

Параграф

Требование

Флаг Push
Объединение или очередь при отсутствии флага Push

4.2.2.2

Возможно

Передающая сторона удаляет последовательные флаги Push

4.2.2.2

Следует

При вызове функции SEND можно установить Push

4.2.2.2

Возможно

При отсутствии Push бесконечный буфер передачи

4.2.2.2

Недопустимо

При отсутствии Push установка PSH для последнего сегмента

4.2.2.2

Обязательно

Уведомление принимающей программы о PSH

4.2.2.2

Возможно

Передача по возможности сегментов максимального размера

4.2.2.2

Следует

Окно
Размер трактуется как беззнаковое целое

4.2.2.3

Обязательно

Поддержка 32-битового поля размера

4.2.2.3

Следует

Сокращение окна справа

4.2.2.16

Не следует

Устойчивость к сокращению окна

4.2.2.16

Обязательно

Неопределенное закрытие окна приемником

4.2.2.17

Возможно

Отправитель проверяет нулевое окно

4.2.2.17

Обязательно

Первая проверка после RTO

4.2.2.17

Следует

Экспоненциальное увеличение интервала проверки

4.2.2.17

Следует

Возможность неопределенного обнуления окна

4.2.2.17

Обязательно

Тайм-аут для нормального соединения с нулевым окном

4.2.2.17

Недопустимо

Срочные данные
Указатель на последний октет

4.2.2.4

Обязательно

Последовательности срочных данных произвольной длины

4.2.2.4

Обязательно

Асинхронное уведомление приложений о срочных данных

4.2.2.4

Обязательно

Приложение может узнавать о наличии срочных данных

4.2.2.4

Обязательно

Опции TCP
Получение опций в любом сегменте

4.2.2.5

Обязательно

Игнорировать неподдерживаемые опции

4.2.2.5

Обязательно

Устойчивость к опциям некорректного размера

4.2.2.5

Обязательно

Реализация приема и передачи опции MSS

4.2.2.6

Обязательно

Передача опции MSS, если максимальный размер не равен 536

4.2.2.6

Следует

Передача опции MSS во всех случаях

4.2.2.6

Возможно

Значение MSS для передачи по умолчанию равно 536

4.2.2.6

Обязательно

Расчет эффективного размера сегмента передачи

4.2.2.6

Обязательно

Контрольные суммы TCP
Отправитель рассчитывает контрольную сумму

4.2.2.7

Обязательно

Получатель проверяет контрольную сумму

4.2.2.7

Обязательно

Установка начального номера по текущему времени

4.2.2.9

Обязательно

Организация соединений
Поддержка одновременных попыток

4.2.2.10

Обязательно

SYN-RCVD помнит последнее состояние

4.2.2.11

Обязательно

Пассивные вызовы CALL могут мешать друг другу

4.2.2.18

Недопустимо

Функция одновременного прослушивания для одного порта

4.2.2.18

Обязательно

Запрос адреса отправителя на уровне IP при необходимости

4.2.3.7

Обязательно

В противном случае использовать локальные адреса соединения

4.2.3.7

Обязательно

OPEN для групповых и широковещательных IP-адресов

4.2.2.14

Недопустимо

Отбрасывание сегментов для групповых/широковещательных адресов

4.2.2.14

Обязательно

Завершение соединений
Сегмент RST может содержать данные

4.2.2.12

Следует

Информирование приложений о разрыве соединения

4.2.2.13

Обязательно

Полудуплексное закрытие соединений

4.2.2.13

Возможно

Передача RST для индикации потери данных

4.2.2.13

Следует

Сохранять состояние TIME-WAIT в течение 2 x MSL

4.2.2.13

Обязательно

Восприятие новых SYN во время TIME-WAIT

4.2.2.13

Возможно

Повторная передача
Алгоритм Jacobson Slow Start

4.2.2.15

Обязательно

Алгоритм Jacobson Congestion-Avoidance

4.2.2.15

Обязательно

Повторная передача с сохранением идентификации IP

4.2.2.15

Возможно

Алгоритм Karn

4.2.3.1

Обязательно

Алгоритм Якобсона для оценки RTO

4.2.3.1

Обязательно

Экспоненциальное увеличение тайм-аута

4.2.3.1

Обязательно

Расчет SYN RTO как для данных

4.2.3.1

Следует

Рекомендуемые начальные значения и границы

4.2.3.1

Следует

Генерация подтверждений (ACK)
Очередь для сегментов с нарушением порядка

4.2.2.20

Следует

Обработка всей очереди до передачи подтверждения

4.2.2.20

Обязательно

Передача ACK для сегментов с нарушением порядка

4.2.2.21

Возможно

Отложенные подтверждения

4.2.3.2

Следует

Задержка < 0.5 сек

4.2.3.2

Обязательно

Подтверждается каждый 2-ой сегмент полного размера

4.2.3.2

Обязательно

Алгоритм предотвращения SWS на приемной стороне

4.2.3.3

Обязательно

Передача данных
Настраиваемое значение TTL

4.2.2.19

Обязательно

Алгоритм предотвращения SWS на передающей стороне

4.2.3.4

Обязательно

Алгоритм Nagle

4.2.3.4

Следует

Приложение может отключить алгоритм Nagle

4.2.3.4

Обязательно

Сбои в соединениях
Негативный анонс для IP при достижении R1

4.2.3.5

Обязательно

Закрытие соединения при достижении R2

4.2.3.5

Обязательно

Приложения могут устанавливать R2

4.2.3.5

Обязательно

Информировать прикладной уровень после R1, но до R2

4.2.3.5

Следует

Рекомендуемые значения для R1 и R2

4.2.3.5

Следует

Поддержка такого же механизма для SYN

4.2.3.5

Обязательно

Значение R2 для SYN не менее 3 минут

4.2.3.5

Обязательно

Передача пакетов Keep-Alive

4.2.3.6

Возможно

Приложение может передавать запросы

4.2.3.6

Обязательно

По умолчанию механизм отключен

4.2.3.6

Обязательно

Возможность передачи только во время бездействия

4.2.3.6

Обязательно

Возможность настройки интервала

4.2.3.6

Обязательно

По умолчанию интервал не менее 2 часов

4.2.3.6

Обязательно

Устойчивость к потере подтверждений

4.2.3.6

Обязательно

Опции IP
Игнорировать опции, не понятные TCP

4.2.3.8

Обязательно

Поддержка временных меток

4.2.3.8

Возможно

Поддержка записи маршрута

4.2.3.8

Возможно

Source Route
Возможность задать из приложения

4.2.3.8

Обязательно

Переписывание Source Route в дейтаграммах

4.2.3.8

Обязательно

Построение маршрута возврата по исходному

4.2.3.8

Обязательно

Изменение Source Route дял новых сегментов

4.2.3.8

Следует

Прием сообщений ICMP от уровня IP

4.2.3.9

Обязательно

Destination Unreach (0,1,5) => информировать приложение

4.2.3.9

Следует

Destination Unreach (0,1,5) => разорвать соединение

4.2.3.9

Недопустимо

Destination Unreach (2-4) => разорвать соединение

4.2.3.9

Следует

Source Quench => замедленный старт

4.2.3.9

Следует

Time Exceeded => информировать приложение без разрыва соединения

4.2.3.9

Следует

Param Problem => информировать приложение без разрыва соединения

4.2.3.9

Следует

Проверка адресов
Отказ для вызовов CALL с неверным адресом IP

4.2.3.10

Обязательно

Отказ для SYN от некорректных адресов IP

4.2.3.10

Обязательно

Отбрасывание без уведомления SYN с широковещательными/групповыми адресами

4.2.3.10

Обязательно

Интерфейс между TCP и приложениями
Механизм информирования об ошибках

4.2.4.1

Обязательно

Приложение может отключать информирование об ошибках

4.2.4.1

Следует

Приложение может задавать TOS для передачи

4.2.4.2

Обязательно

Передача без изменений на уровень IP

4.2.4.2

Следует

Приложение может менять TOS для действующего соединения

4.2.4.2

Следует

Передача приложению полученного TOS

4.2.4.2

Возможно

Вызов FLUSH

4.2.4.3

Возможно

Адрес IP как необязательный параметр OPEN

4.2.4.4

Обязательно

5. Литература

Введение

[INTRO:1] «Requirements for Internet Hosts — Application and Support51,» IETF Host Requirements Working Group, R. Braden, Ed., RFC 1123, October 1989.

[INTRO:2] «Requirements for Internet Gateways,» R. Braden and J. Postel, RFC 100952, June 1987.

[INTRO:3] «DDN Protocol Handbook,» NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985.

[INTRO:4] «Official Internet Protocols,»53 J. Reynolds and J. Postel, RFC 1011, May 1987.

[INTRO:5] «Protocol Document Order Information,» O. Jacobsen and J. Postel, RFC 980, March 1986.

[INTRO:6] «Assigned Numbers,» J. Reynolds and J. Postel, RFC 10101, May 1987.

[INTRO:7] «Modularity and Efficiency in Protocol Implementations,» D. Clark, RFC 817, July 1982.

[INTRO:8] «The Structuring of Systems Using Upcalls,» D. Clark, 10th ACM SOSP, Orcas Island, Washington, December 1985.

Дополнительная информация

[INTRO:9] «A Protocol for Packet Network Intercommunication,» V. Cerf and R. Kahn, IEEE Transactions on Communication, May 1974.

[INTRO:10] «The ARPA Internet Protocol,» J. Postel, C. Sunshine, and D. Cohen, Computer Networks, Vol. 5, No. 4, July 1981.

[INTRO:11] «The DARPA Internet Protocol Suite,» B. Leiner, J. Postel, R. Cole and D. Mills, Proceedings INFOCOM 8554, IEEE, Washington DC, March 1985.

[INTRO:12] «Final Text of DIS8473, Protocol for Providing the Connectionless Mode Network Service,»55 ANSI, March 1986.

[INTRO:13] «End System to Intermediate System Routing Exchange Protocol,» ANSI X3S3.356, April 1986.

Канальный уровень

[LINK:1] «Trailer Encapsulations,» S. Leffler and M. Karels, RFC 893, April 1984.

[LINK:2] «An Ethernet Address Resolution Protocol,» D. Plummer, RFC 82657, November 1982.

[LINK:3] «A Standard for the Transmission of IP Datagrams over Ethernet Networks,» C. Hornig, RFC 894, April 1984.

[LINK:4] «A Standard for the Transmission of IP Datagrams over IEEE 802 Networks,» J. Postel and J. Reynolds, RFC 1042, February 1988.

Уровень IP

[IP:1] «Internet Protocol (IP),» J. Postel, RFC 791, September 1981.

[IP:2] «Internet Control Message Protocol (ICMP),» J. Postel, RFC 792, September 1981.

[IP:3] «Internet Standard Subnetting Procedure,» J. Mogul and J. Postel, RFC 950, August 1985.

[IP:4] «Host Extensions for IP Multicasting,» S. Deering, RFC 111258, August 1989.

[IP:5] «Military Standard Internet Protocol,» MIL-STD-177759, Department of Defense, August 1983.

[IP:6] «Some Problems with the Specification of the Military Standard Internet Protocol,» D. Sidhu, RFC 963, November 1985.

[IP:7] «The TCP Maximum Segment Size and Related Topics,»60 J. Postel, RFC 879, November 1983.

[IP:8] «Internet Protocol Security Options,» B. Schofield, RFC 1108, October 1989.

[IP:9] «Fragmentation Considered Harmful,»61 C. Kent and J. Mogul, ACM SIGCOMM-87, August 1987. Published as ACM Comp Comm Review, Vol. 17, no. 5.

[IP:10] «IP Datagram Reassembly Algorithms,»62 D. Clark, RFC 815, July 1982.

[IP:11] «Fault Isolation and Recovery,» D. Clark, RFC 816, July 1982.

Дополнительная информация

[IP:12] «Broadcasting Internet Datagrams in the Presence of Subnets,» J. Mogul, RFC 92263, October 1984.

[IP:13] «Name, Addresses, Ports, and Routes,» D. Clark, RFC 814, July 1982.

[IP:14] «Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQUID)64,» W. Prue and J. Postel, RFC 1016, July 1987.

Протокол UDP

[UDP:1] «User Datagram Protocol,» J. Postel, RFC 768, August 1980.

Протокол TCP

[TCP:1] «Transmission Control Protocol,» J. Postel, RFC 793, September1981.

[TCP:2] «Transmission Control Protocol,» MIL-STD-177865, US Department of Defense, August 1984.

[TCP:3] «Some Problems with the Specification of the Military Standard Transmission Control Protocol,» D. Sidhu and T. Blumer, RFC 964, November 1985.

[TCP:4] «The TCP Maximum Segment Size and Related Topics,» J. Postel, RFC 879, November 1983.

[TCP:5] «Window and Acknowledgment Strategy in TCP,» D. Clark, RFC 813, July 1982.

[TCP:6] «Round Trip Time Estimation,» P. Karn & C. Partridge, ACM SIGCOMM-87, August 1987.

[TCP:7] «Congestion Avoidance and Control,» V. Jacobson, ACM SIGCOMM-88, August 1988.

Дополнительная информация

[TCP:8] «Modularity and Efficiency in Protocol Implementation,» D. Clark, RFC 817, July 1982.

[TCP:9] «Congestion Control in IP/TCP,» J. Nagle, RFC 896, January 1984.

[TCP:10] «Computing the Internet Checksum,» R. Braden, D. Borman, and C. Partridge, RFC 107111, September 1988.

[TCP:11] «TCP Extensions for Long-Delay Paths,» V. Jacobson & R. Braden, RFC 107266, October 1988.

Вопросы безопасности

С программами различных коммуникационных уровней хостов связано множество вопросов безопасности, но их обсуждение выходит за рамки данного RFC.

Архитектура Internet в общем случае обеспечивает весьма слабую защиту против подмены IP-адресов отправителя, поэтому любой механизм обеспечения безопасности на основе IP-адресов отправителей должен применяться с осторожностью. Однако в ограниченной среде некоторая проверка адресов отправителей становится вполне возможной. Например, можно создать безопасную ЛВС, входной маршрутизатор которой будет отбрасывать любые дейтаграммы, где в качестве отправителя указан внутренний адрес локальной сети. В этом случае хост ЛВС может различать внешние и внутренние хосты по адресу отправителя. Проблема усложняется при задании маршрута отправителем и существуют предложения запретить хостам рассылку дейтаграмм source-route из соображений безопасности (см. 3.3.5).

Вопросы безопасности рассматриваются в параграфах, связанных с опцией IP Security (см. 3.2.1.8), сообщениями ICMP Parameter Problem (см. 3.2.2.5), опциями IP в дейтаграммах UDP (см. 4.1.3.2) и резервированием портов TCP (см. 4.2.2.1).

Адрес автора

Robert Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695 Телефон: (213) 822 1511 EMail: Braden@ISI.EDU


Перевод на русский язык Николай Малых nmalykh@gmail.com

1 Во время подготовки этого RFC термин gateway (шлюз) использовлся применительно к хостам, обеспечивающим пересылку пакетов между разными физическими сетями. Со временем функции межсетевой пересылки трафика стали реализоваться в основном на специализированных устройствах, называемых маршрутизаторами (router), а термин шлюз сейчас обычно относят в к системам, обеспечивающим преобразования форматов на более высоких, нежели IP, уровнях (например, шлюз электронной почты). В этом документе термины «шлюз» и «маршрутизатор» используются, как синонимы, если в тексте явно не означено иное. Прим. перев.

2Domain Name System — система доменных имен.
3Уровень Internet соответствует сетевому уровню (network layer) эталонной модели OSI. Прим. перев.
4Протокол уровня доступа к среде.
5В современной среде настольных ПК этот вопрос несколько утратил остроту, поскольку функции маршрутизации реализованы практически для всех операционных систем (встроенными средствами или с помощью дополнительных программ). Прим. перев.
6В оригинале «Be conservative in what you do, be liberal in what you accept from others». Прим. перев.
7Сегодня ситуация уже иная и целенаправленные действия злоумышленников наносят значитьельно больший вред. Прим. перев.
8Термином модуль будем обозначать неделимую при передаче на данном уровне совокупность данных. Прим. перев.
9Maximum transmission unit
10Address Resolution Protocol.
11Отсчет времени должен начинаться заново всякий раз, когда запись в кэше обновляется. Точка отсчета определяется путем просмотра полей отправителя независимо от искомого адреса в широковещательных пакетах ARP.
12В соответствии с современной версией стандарта IEEE 802.3-2005 максимальный размер кадра Ethernet составляет 1500 октетов. Прим. перев.

13Речь идет о стандарте Ethernet DIX, который в настоящее время практически не используется. Прим. перев.

14По расположению в кадре. Прим. перев.
15Отбросить без уведомления.
16В настоящее время принята парадигма бесклассовой междоменной маршрутизации CIDR (RFC 1817 – RFC 1819) и деление адресов IP на классы утратило актуальность. Переводы упомянутых RFC имеются на сайте www.protocols.ru. Прим. перев.
17Internet Assigned Number Authority.
18Текст этого пункта обновлен в соответствии с RFC 3021. Перевод текста исходного документа имел вид: «Широковещательный пакет для указанного маршрутизатора (конкретной подсети). Такой адрес недопустимо указывать в качестве адреса отправителя.». Прим. перев.
19Пункт (h) добавлен в перевод документа в соответствии с RFC 3021. Прим. перев.
20На принимающем физическом интерфейсе. Прим. перев.
21Существует еще ряд исключений, рассматриваемых в этом документе.
22Defense Communication Agency.
23В настоящее время использование поля Precedence оговорено в ряде новых RFC (1812, 2460, 2474, 2873), переводы которых имеются на сайте www.protocols.ru. Прим. перев.
24Последний вариант этого документа находится в RFC 1700. В настоящее время эта информация представлена в базе данных на сайте www.iana.org. Прим. перев.
25Министерство обороны США. Прим. перев.
26Указатель за пределы последнего поля.
27С момента разработки этого документа число типов ICMP было расширено. Прим. перев.
28Приведенные здесь требования имеют превосходство над всеми остальными требованиями, указанными в этом документе для передачи сообщений ICMP.
29Такие дейтаграммы отбрасываются — см. параграф 3.3.2
30Операция AND. Прим. перев.
31Interior Gateway Protocol — протокол внутренней маршрутизации.
32См. RFC 1256 ICMP Router Discovery messages. Прим. перев.
33Effective MTU to receive — эффективное значение MTU для приема.
34Минимальный размер заголовка IP.
35Maximum Segment Lifetime.
36Effective MTU for sending — эффективное значение MTU для передачи.
37End System — конечная система, т.е., хост
384.2BSD Unix и производные, но не 4.3BSD.
39См. RFC 1469 (Token Ring), RFC 2022 (ATM). Прим. перев.
40Только при реализации этой опции
41Только при реализации опции
42Если опция реализована и включена.
43Если не используются встроенные функции маршрутизатора или source routed.
44Это требование изменяется для дейтаграмм, содержащих сообщений ICMP об ошибках.
45User Datagram Protocol.
46Transmission Control Protocol.
47Maximum Segment Size
48Maximum Segment Lifetime — максимальное время жизни сегмента.
49Silly Window Syndrome.
50В состоянии SYN-RECEIVED, если соединение было инициировано пассивным вызовом OPEN, это соединение должно переводиться обратно с состояние LISTEN с возвратом управления. В остальных случаях следует проверить флаг SYN.
51В RFC 2181 внесены уточнения и изменения для этого документа. Перевод обоих документов имеется на сайте www.protocols.ru. Прим. перев.
52Более современный вариант этого документа содержится в RFC 1812, перевод которого имеется на сайте www.protocols.ru. Прим. перев.
53Последний вариант этого документа опубликован в RFC 5000. Прим. перев.
54Этот документ также опубликован, как ISI-RS-85-153 и статья в IEEE Communications Magazine, March 1985.
55Этот документ также опубликован, как RFC 994.
56Этот документ также опубликован, как RFC 995.
57Перевод этого документа имеется на сайте www.protocols.ru. Прим. перев.
58В RFC 2236 включены добавления к RFC 1112 в части протокола IGMP. Перевод RFC 1112 на русский язык имеется на сайте www.protocols.ru. Прим. перев.
59Эта спецификация, как указано в RFC 963, предназначена для описания протокола IP, но в ней пропущены важные моменты (например, обязательная поддержка подсетей [IP:3] и дополнительная поддержка групповой адресации [IP:4]). Кроме того, документ достаточно устарел. При возникновении конфликтов с этим документов преимущество следует отдавать RFC 791, RFC 792 и RFC 950, а настоящий документ имеет преимущество над всеми. Прим. перев.
60Обсуждаются соотношения между TCP Maximum Segment Size и размером дейтаграмм IP.
61В этой полезной статье обсуждаются вопросы фрагментации и представлен ряд дополнительных решений проблемы.
62Этот и следующий документ должен прочесть каждый разработчик.
63Перевод этого документа имеется на сайте www.protocols.ru. Прим. перев.
64В документе впервые описана направленная широковещательная адресация. Однако большая часть этого RFC посвящена маршрутизаторам и хостам.
65Эта спецификация, как указано в RFC 964, описывает тот же протокол, что и RFC 793 [TCP:1]. При возникновении конфликтов преимущество должно отдаваться RFC 793, а данный документ имеет преимущество по отношению к обоим.

66Этот документ признан устаревшим и заменен RFC 1323, перевод которого имеется на сайте www.protocols.ru. Прим. перев.




RFC 1123 Requirements for Internet Hosts — Application and Support

Network Working Group                                    Internet Engineering Task Force
Request for Comments: 1123 R. Braden, Editor
October 1989

Требования к хостам Internet

Прикладные и служебные протоколы

Requirements for Internet Hosts — Application and Support

PDF

Статус документа

В данном RFC содержатся официальные спецификации для сообщества Internet. Документ содержит ссылки, исправления и дополнения к первичным стандартам протоколов, имеющим отношение к хостам. Документ можно распространять свободно.

Аннотация

Этот документ является одним из двух RFC, посвященных определению и обсуждению требований к программам хостов Internet. Этот документ посвящен прикладным и служебным протоколам, а второй документ RFC 1122 — коммуникационным протоколам канального уровня, IP и транспортного уровня.

1. Введение

Этот документ является одним из пары RFC, определяющих и обсуждающих требования к реализации хост-систем на базе стека протоколов Internet. Документ посвящен протоколам прикладного уровня. Другой документ — RFC 1122 «Требования к хостам Internet — Коммуникационные уровни» [INTRO:1] — посвящен коммуникационным протоколам — канальный уровень, уровень IP (сетевой) и транспортный уровень. С этой парой также тесно связан документ RFC 1009 «Требования к шлюзам1 Internet» [INTRO:2].

Документ предназначен для производителей и разработчиков, а также для пользователей коммуникационных программ Internet. Документ написан на основе обобщения опыта работы исследователей Internet и компаний-производителей.

В этом RFC рассмотрены стандарты протоколов, которые должны использоваться на хостах, подключенных к сети Internet, а также связанные с ними RFC и другие документы, описывающие текущие варианты спецификаций для таких протоколов. В документе исправлен ряд ошибок, встречающихся в упоминаемых документах, рассмотрены дополнительные вопросы и даны рекомендации по реализации протоколов.

Для каждого протокола в данном документе также приведен явный набор требований, рекомендаций и опций. Читатель должен понимать, что список приведенных в документе требований неполон — полные требования для хостов Internet содержатся в документах, определяющих спецификации протоколов. В данном RFC приведены поправки, уточнения и дополнения к стандартам протоколов.

Качественная реализация протоколов, подготовленная в результате внимательного прочтения этого RFC, работы в контакте с техническим сообществом Internet и учета позитивной практики разработки коммуникационных программ, не должна сильно отличаться от содержащихся в документе требований. Многие из требований данного RFC уже реализованы в стандартах или рассматриваются для включения в стандарты, поэтому их обсуждение в данном документе может показаться избыточным. Однако такие вопросы были включены в документ, поскольку некоторые из имеющихся реализаций содержат ошибки, приводящие к недостаточной интероперабельности, снижению производительности и возникновению иных проблем.

В документе обсуждается и разъясняется множество требований и рекомендаций. Ограничиваться простым списком требований было бы опасно по ряду причин:

  • некоторые требуемые функции более важны, а ряд функций не относится к числу обязательных;
  • существует множество причин, по которым продукция, разработанная для ограниченного контекста, может быть выбрана для использования в иных средах.

Нужно следовать приведенным в документе спецификациям для обеспечения интероперабельности хостов при взаимодействии через разнородные и сложные системы Internet. Хотя многие из числа имеющихся реализаций не соответствуют тем или иным требованиям, спецификации являются идеалом, к которому нужно стремиться.

Приведенные в документе требования основаны на современном уровне архитектуры Internet. Документ будет обновляться по мере развития спецификаций и технологий в тех областях, с которыми связан этот документ.

Вводная часть документа начинается с краткого обзора архитектуры Internet применительно к хостам, приведены также некоторые рекомендации по выбору программ для хостов. Кроме того, во введении даны некоторые рекомендации по работе с остальной частью документа и рассмотрена используемая терминология. Глава 2 описывает общие требования ко всем прикладным протоколам, главы 3 — 5 описывают требования к протоколам трех основных приложений — Telnet, обмена файлами (FTP) и электронной почты. Глава 6 посвящена служебным приложениям — DNS, инициализация и управление. В главе 7 приведены ссылки на другие источники информации.

1.1 Архитектура Internet

Краткое описание архитектуры Internet с точки зрения хостов приведено в параграфе 1.1 работы [INTRO:1]. Там же можно найти ссылки на другие публикации по архитектуре Internet.

1.2 Общие вопросы

Существует два важных аспекта, которые должны принимать во внимание все разработчики программ для хостов Internet, — постоянное развитие Сети и принцип устойчивости.

1.2.1 Постоянное развитие Internet

Непредсказуемо быстрый рост Internet порождает проблемы управления и масштабирования в гигантских системах передачи дейтаграмм. В результате решения таких проблем изменяются и спецификации, описываемые в данном документе. Изменения планируются и осуществляются под контролем с участием производителей сетевой продукции и организаций, ответственных за работу сетей.

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

1.2.2 Принцип устойчивости

Для протоколов всех уровней существует общее правило, которому приложения должны следовать во избежание проблем с устойчивостью и интероперабельностью: «будьте либеральны при приеме данных и консервативны при их передаче».

Программы должны уметь обрабатывать все мыслимые ошибки; не имеет значения вероятность возникновения той или иной ошибки — раньше или позже пакет с любой возможной комбинацией ошибок и/или атрибутов будет получен и программа должна быть готова к обработке такого пакета. Если программа не может эффективно обрабатывать ошибки, она приведет прямой дорогой к хаосу. В общем случае лучше предположить, что сеть наводнена зловредными объектами, которые постоянно передают пакеты, предназначенные для нанесения максимального вреда. Такое предположение обеспечит высокий уровень защиты. Наиболее серьезные проблемы в Internet связаны с неисследованными механизмами, включающимися с малой вероятностью; намерения обычных злоумышленников никогда не могут принести такого вреда!

На всех уровнях программ хостов Internet должны быть реализованы средства адаптации. В качестве простого примера рассмотрим спецификацию протокола, использующего численные значения для какого-либо поля в заголовке (например, тип, номер порта или код ошибки) — при разработке следует предполагать, что используемая нумерация неполна. Если спецификация протокола предполагает четыре возможных кода ошибки, приложение должно уметь обрабатывать по крайней мере пять типов ошибок (4 заданных и все остальные). Появление не определенных в спецификации кодов должно протоколироваться (см. ниже), но не должно нарушать работу системы.

Почти так же важен еще один аспект — программы на других хостах могут содержать определения, которые могут толкнуть хост на неразумные, но допустимые с точки зрения протокола действия. Естественным решением будет «поиск неразумных хостов» — программы хоста должны быть готовы не просто переносить появление неразумных хостов, но и участвовать в процессе ограничения вредных воздействий, которые подобные хосты могут нанести сетевым объектам общего пользования.

1.2.3 Протоколирование ошибок

Сеть Internet включает огромное количество разнотипных хостов и шлюзов, в каждом из которых реализовано множество протоколов и уровней — некоторые из хостов и маршрутизаторов наверняка содержат ошибки в программах стека протоколов Internet. В результате сложности, разнотипности и использования распределенных функций диагностика Internet является весьма непростой задачей.

Упростить поиск проблем помогает использование хостами специальных средств протоколирования ошибок и странностей в поведении протоколов. При записи таких событий важно включать максимум диагностической информации. Часто бывает весьма полезно записывать заголовки пакетов, вызывающих ошибки. Однако следует знать меру — средства протоколирования ошибок не должны отнимать слишком много ресурсов хоста и снижать эффективность его работы.

При записи информации об ошибках существует вероятность получения журнальных файлов огромного размера — таких ситуаций можно избежать, используя «циклический» журнал или включая запись только для диагностики определенных сбоев. Полезно также фильтровать и считать повторяющиеся последовательные сообщения. Представляется привлекательной приведенная ниже стратегия:

  1. всегда считать аномальные события и делать содержимое счетчиков доступным с помощью средств управления сетью (см. параграф 6.3);
  2. поддерживать возможность выбора протоколируемых событий (например, записывать все ошибки, связанные с хостом X).

Отметим, что разные системы управления сетью могут придерживаться различных правил в части числа протоколируемых ошибок для каждого хоста. Некоторые системы исходят из принципа: «если это не имеет ко мне прямого отношения, не хочу об этом знать», тогда, как другие системы прилагают максимум усилий для обнаружения и устранения аномалий в поведении сетевых протоколов.

1.2.4 Конфигурационные параметры

Идеальной реализацией хоста будет та, на которой настройка стека протоколов Internet будет полностью автоматизирована (self-configuring). Это позволит реализовать весь стек в ПЗУ2 или встроить в микросхемы оборудования — такое решение упростит организацию бездисковых станций, снимет значительную часть нагрузки с сетевых администраторов и упростит разработку систем. Однако этот идеал недостижим и на практике к нему не удается даже серьезно приблизиться.

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

Наконец, часть конфигурационных опций может потребоваться для обеспечения взаимодействия с устаревшими или содержащими ошибки реализациями протоколов, распространяемыми без исходных текстов (к несчастью, такое встречается в Internet достаточно часто). Для обеспечения корректного сосуществования с такими «сбойными» системами администраторам зачастую приходится «расстраивать» корректно работающие системы. Такие проблемы будут решаться сами собой по мере удаления сбойных систем, но разработчики не должны оставлять этот вопрос без внимания.

Когда мы говорим, что параметр требует настройки, это не означает требования читать значение параметра из конфигурационного файла при каждой загрузке. Мы рекомендуем разработчикам устанавливать для таких параметров используемые по умолчанию значения — тогда в конфигурационных файлах могут содержаться лишь те значения, которые не совпадают с принятыми по умолчанию. Таким образом, конфигурационные требования обеспечивают гарантию возможности изменения принятых по умолчанию значений параметров — это решение можно использовать даже при загрузке программного кода из ПЗУ.

В этом документе для ряда случаев указаны значения, которые следует использовать по умолчанию. Выбор принятых по умолчанию значений является достаточно важным вопросом для случаев использования вместе с существующими сбойными системами. По мере продвижения Internet к полной интероперабельности, принятые по умолчанию значения будут реализовать официальный протокол, а не «расстраивать» систему для обеспечения совместимости с плохо работающими реализациями. Хотя рынок заставляет некоторых производителей устанавливать по умолчанию значения для «расстройки», мы рекомендуем использовать по умолчанию значения, соответствующие стандартам.

В заключение отметим, что производители продукции должны предоставлять полную документацию по всем конфигурационным параметрам, указывая допустимые значения и описывая влияние параметров на работу системы.

1.3 Работа с документом

1.3.1 Структура документа

В общем случае все главы документа организованы в форме следующих параграфов:

  1. Введение
  2. Общие вопросы — рассматриваются документы со спецификациями протокола, приводятся исправления ошибок, перечисляются требования, которые могли быть нечетко или неточно сформулированы и приводятся дополнительные комментарии и разъяснения.
  3. Частные вопросы — рассматривается устройство протокола и вопросы реализации, не включенные в предыдущий раздел.
  4. Интерфейсы — обсуждаются услуги, предоставляемые вышележащему протоколу.
  5. Заключение — резюмируются требования данной главы.

Во многих темах документа встречаются параграфы, помеченные как Обсуждение или Реализация. Этот материал предназначен для разъяснения требований, рассмотренных ранее в документе. Такие параграфы также включают некоторые предложения по вариантам будущих разработок. Материалы о реализации содержат предложения, которые могут быть интересны для разработчиков.

Заключение служит в качестве краткого руководства и справочника к главе, но оно слишком кратко для использования в качестве информационного источника. Такие заключения никогда не должны использоваться отдельно от текста полного RFC.

1.3.2 Уровни требований

В этом документе модальные глаголы, служащие для формулировки требований, выделены жирным шрифтом и используются в оговоренном ниже смысле:

Требуется, должен (MUST)

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

Следует, рекомендуется (SHOULD)

Этот глагол (или причастие рекомендуемый) служит для обозначения тех случаев, когда могут существовать дополнительные факторы, позволяющие игнорировать данное требование; в таких случаях рекомендуется принимать взвешенное решение с учетом всех факторов.

Можно (MAY)

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

Реализация считается несовместимой со стандартами, если в ней не выполнены обязательные требования (MUST). Реализация, в которой выполнены все требования MUST и SHOULD, считается безусловно совместимой. Если же выполняются все требования MUST, но проигнорирована часть требований SHOULD, реализация считается условно совместимой.

1.3.3 Терминология

Ряд используемых в документе технических терминов определен в данном параграфе.

Сегмент — Segment

Сегментом будем называть модуль3 данных, используемый для сквозной передачи по протоколу TCP. Сегмент состоит из заголовка TCP, за которым следуют данные. Сегменты передаются с использованием инкапсуляции в дейтаграммы IP.

Сообщение — Message

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

Дейтаграмма — Datahram

Дейтаграмма [UDP] представляет собой модуль данных, используемый для передачи по протоколу UDP.

Многодомный — Multihomed

Хост называют многодомным (multihomed) если он имеет более одного адреса IP.

1.4 Благодарности

Этот документ включает результаты работы и комментарии большой группы специалистов по протоколам Internet, включая представителей университетов и исследовательских лабораторий, компаний-производителей и государственных агентств. Подготовка документа велась в рабочей группе IETF Host Requirements.

Редактор выражает особую благодарность за неустанную работу людям, принявшим участие в долгих конференциях и написавшим 3 мегабайта почтовых сообщений за 18 месяцев подготовки этого документа: Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU), James Van Bokkelen (FTP Software).

Кроме того, выражается благодарность всем, кто внес большой вклад в подготовку документа: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), Mike StJohns (DCA). Перечисленные ниже люди внесли значительный вклад в подготовку отдельных тем: Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco), Rayan Zachariassen (Toronto).

Благодарим также всех, кто так или иначе способствовал появлению этого документа.

2. Общие вопросы

В этом разделе рассматриваются требования, применимые ко всем протоколам прикладного уровня.

2.1 Имена хостов и числовые адреса

Синтаксис имен хостов Internet описан в RFC 952 [DNS:4]. Однако одно из требований к именам изменено настоящим документом — в качестве первого символа имени может использоваться буква латиницы или цифра4. Программы хостов должны следовать более либеральному требованию настоящего документа.

Программы хостов должны поддерживать имена длиной до 63 символов и следует поддерживать имена размером до 255 символов.

Следует обеспечивать возможность идентификации хостов с помощью (1) доменного имени хоста или (2) IP-адреса в десятичном формате с разделением точками (#.#.#.#). Для хостов следует синтаксически проверять введенный IP-адрес до обращения к DNS.

Обсуждение

Последнее требование не означает полную проверку синтаксиса введенного адреса — этот вопрос должен решаться на уровне пользовательского интерфейса. Например, адреса IP должны указываться в квадратных скобках [ ] для почтовых программ SMTP (см. 5.2.17). Такое обозначение может быть сделано универсальным в масштабе хоста, что позволяет упростить синтаксическую проверку вводимых адресов.

Если адреса можно указывать без ограничителей такого типа, требуется выполнять их полную синтаксическую проверку, поскольку имя хоста может начинаться с цифр и даже содержать только цифры (см. параграф 6.1.2.4). Однако корректное имя хоста никогда не может иметь вид корректного адреса IP в формате #.#.#.#, поскольку по крайней мере компонента (домен) верхнего уровня должна быть буквенной.

2.2 Использование службы доменных имен

Доменные имена хостов должны транслироваться в IP-адреса в соответствии с требованиями параграфа 6.1.

Приложения, использующие службу доменных имен, должны быть способны справиться с незначительными ошибками. Приложение должно ожидать в течение разумного периода перед выполнением повтора при некритичных ошибках. Кроме того, приложения должны допускать возможность того, что в результате сетевых проблем службы могут быть недоступными в течение часов и даже дней.

Для приложений не следует основываться на возможности обнаружения записи WKS, содержащей точный список всех служб для отдельного хоста, поскольку тип WKS RR нечасто используется на хостах Internet. Для проверки доступности сервиса нужно просто попытаться его использовать.

2.3 Приложения на многодомных хостах

Если удаленный хост является многодомным, трансляция имени будет возвращать список адресов IP. Как сказано в параграфе 6.1.3.4, этот список должен быть упорядочен по уменьшению приоритета адресов. Для реализаций прикладных протоколов следует быть готовым к попыткам использования нескольких адресов из полученного списка для достижения успеха. Более специфические требования для протокола SMTP рассмотрены в параграфе 5.3.4.

Когда локальный хост является многодомным, приложениям на основе запросов/откликов UDP следует передавать отклик с IP-адресом отправителя, который совпадает с адресом получателя в дейтаграмме запроса UDP. Термин «заданный адрес получателя» определен в параграфе 3.2.1.3 документа RFC 1122 [INTRO:1].

Подобно этому, серверным приложениям, открывающим множество соединений TCP с одним клиентом, следует использовать один локальный адрес IP для всех таких соединений.

2.4 Тип обслуживания

Приложение должно выбирать приемлемые значения TOS при обращении к службам транспортного уровня и эти значения должны быть настраиваемыми. Отметим, что значение TOS содержит 5 битов, из которых используются только три старших бита, а два оставшихся должны иметь нулевое значение.

Обсуждение

По мере разработки алгоритмов поддержки TOS маршрутизаторами рекомендуемые значения типа обслуживания для различных прикладных протоколов могут изменяться. Кроме того, очевидно, что для различных комбинаций пользователей и путей Internet могут возникать потребности в использовании нестандартных значений TOS. Исходя из этих соображений, значения TOS должны быть настраиваемыми.

Рекомендуемые значения TOS для различных прикладных протоколов можно найти в документе «Assigned Numbers» [INTRO:5].

2.5 Требования общего плана

Функция

Параграф

Требования

Пользовательские интерфейсы:
Имена хостов могут начинаться с цифры

2.1

Обязательно

Поддержка имен размером до 635 символов

2.1

Обязательно

Поддержка имен размером до 255 символов

2.1

Следует

Поддержка IP-адресов в десятичном формате

2.1

Следует

Выполнение сначала проверки синтаксиса для IP-адресов

2.1

Следует

Преобразование доменных имен в соответствии с параграфом 6.2

2.2

Обязательно

Повторение с разумным интервалом

2.2

Обязательно

Допустимость продолжительного отсутствия сервиса

2.2

Обязательно

Предположение о доступности записей WKS

2.2

Не следует

Попытки использования. различных. адресов для многодомного удаленного хоста

2.3

Следует

Адрес отправителя отклика UDP соответствует. адресу получателя запроса

2.3

Следует

Использование одного адреса IP для связанных соединений TCP

2.3

Следует

Задание приемлемых значений TOS

2.4

Обязательно

Возможность выбора TOS

2.4

Обязательно

Неиспользуемые биты (младшие 2 бита) равны 0

2.4

Обязательно

 

3. Удаленный доступ по протоколу TELNET

3.1 Введение

Telnet представляет собой стандартный протокол Internet для удаленного доступа в систему. Протокол обеспечивает правила кодирования для «связывания» клавиатуры и монитора на клиентском компьютере с командным интерпретатором удаленного сервера. Часть протокола Telnet включена также в другие протоколы прикладного уровня (например, FTP и SMTP).

Telnet использует одно соединение TCP и его нормальный поток данных (режим виртуального сетевого терминала — Network Virtual Terminal или NVT) представляет 7-битовые символы ASCII с escape-последовательностями, служащими для управления. Протокол Telnet обеспечивает возможность согласования множества дополнительных режимов и функций.

Основная спецификация Telnet содержится в RFC 854 [TELNET:1], а опции определены во множестве других RFC, перечисленных в разделе 7.

3.2 Общие вопросы

3.2.1 Согласование опций: RFC 854, стр. 2-3

Каждая реализация Telnet должна включать опцию согласования параметров с дополнительными механизмами [TELNET:2].

Хост должен аккуратно выполнять требования RFC 854, чтобы избежать возникновения петель при согласовании опций. Хост должен отказываться (т. е., давать отклик WONT/DONT на запросы DO/WILL) от использования не поддерживаемых им опций. Следует сохранять возможность согласования опций (даже при отказе от всех запросов) в течение всего срока существования соединения Telnet.

Если согласовать опции не удалось, реализация Telnet должна перейти в используемый по умолчанию режим NVT.

Обсуждение

Хотя поддержка более изощренных терминалов и опций стала нормой, люба реализация должна быть готова к поддержке режима NVT для любого соединения пользователя с сервером.

3.2.2 Функция Telnet Go-Ahead: RFC 854, стр. 5, RFC 858

На хосте, который никогда не передает команду Telnet GA6, сервер Telnet должен попытаться согласовать опцию подавления этой команды — Suppress Go Ahead (т. е., передать WILL Suppress Go Ahead). Клиент и сервер Telnet должны всегда принимать согласование опции Suppress Go Ahead (подавление команды «идите прочь»).

При использовании режима полнодуплексного терминала, для которого GA не имеет смысла, реализация клиента Telnet может игнорировать команды GA.

Обсуждение

Полудуплексные (locked-keyboard) терминалы line-at-a-time (строка в один прием), для которых был разработан механизм Go-Ahead, сегодня уже практически не используются. Во многих операционных системах достаточно сложно реализовать передачу сигналов Go-Ahead, даже если эта ОС поддерживает полудуплексные терминалы. Эти трудности обычно связаны с тем, что программный код сервера Telnet не имеет доступа к информации о блокировке пользовательского процесса в ожидании данных от соединения Telnet (т. е. невозможно надежно определить момент передачи команды GA). Следовательно, большинство хостов с серверами Telnet не поддерживает команду GA.

Смысл приведенных в этом параграфе правил состоит в том, что следует разрешать другой стороне соединения Telnet блокировать использование команд GA.

Существует класс полудуплексных терминалов, до сих пор находящихся в эксплуатации (терминалы ввода данных), которые работают в полноэкранном режиме. Однако поддержка таких терминалов при использовании ими протокола Telnet не требует сигналов Go Ahead (см. 3.3.2).

3.2.3 Функции управления: RFC 854, стр. 7-8

Список команд Telnet был расширен для включения команды EOR7 с кодом 239 [TELNET:9].

Клиент и сервер Telnet могут поддерживать функции управления EOR, EC, EL, Break и должны поддерживать функции AO, AYT, DM, IP, NOP, SB, SE.

Хост должен быть способен принимать и игнорировать любые функции управления Telnet, которые он не поддерживает.

Обсуждение

Отметим, что сервер Telnet должен поддерживать функцию Telnet IP (Interrupt Process — прерывание), даже при наличии на хосте эквивалента этой функции (например, комбинация клавиш Control-C во многих системах). Функция Telnet IP может быть сильнее такой команды прерывания, поскольку использует срочные данные TCP.

Управляющая функция EOR может использоваться для задания границ потока. Важным применением этой функции является поддержка терминалов ввода данных (см; 3.3.2). Обратим внимание, что команда EOR не была определена в RFC 854, поэтому хост, не способный корректно игнорировать неизвестные команды Telnet, может «рухнуть» при получении EOR. Для защиты таких хостов была введена опция End-of-Record [TELNET:9], однако для корректно реализованных программ Telnet такая защита не требуется.

3.2.4 Сигнал Telnet Synch: RFC 854, стр. 8-10

При получении срочных данных TCP клиент или сервер Telnet должен отвергать все данные, за исключением команд Telnet, пока не будет получен сигнал DM (и завершатся срочные данные).

При передаче Telnet IP (Interrupt Process) клиенту Telnet следует сопровождать такое прерывание последовательностью Telnet Synch (т. е. передавать как срочные данные TCP последовательность IAC IP IAC DM). Указатель срочности TCP должен указывать на октет DM.

При получении команд Telnet IP сервер Telnet может передать последовательность Telnet Synch клиенту для отсечения выходного потока. Выбор решения связан с реакцией операционной системы сервера на локальное прерывание процесса пользователем.

При получении команды Telnet AO сервер Telnet должен передать пользователю последовательность Telnet Synch для отсечения выходного потока.

Клиенту Telnet следует поддерживать возможность отсечения вывода при передаче Telnet IP (см. также 3.4.5).

Обсуждение

Для клиента Telnet существует три способа отсечения выходного потока данных сервера:

  1. Передать команду AO после IP.

В результате хост сервера будет передавать сигнал flush-buffered-output (отбросить буферизованный вывод) своей операционной системе. Однако команда AO может не дать локального эффекта (т. е., не остановить терминальный вывод на стороне клиента Telnet), пока сервер Telnet получает и обрабатывает команду AO и передает обратно Synch.

  1. Передать DO TIMING-MARK [TELNET:7] после IP и локально отвергать весь вывод, пока не будет получена последовательность WILL/WONT TIMING-MARK от сервера Telnet.

Поскольку DO TIMING-MARK обрабатывается на сервере после IP, отклик на эту команду должен находиться в корректном месте выходного потока данных. Однако TIMING-MARK не будет посылать операционной системе сервера сигнал flush buffered output. Необходимость такого сигнала определяется операционной системой сервера Telnet.

  1. Использовать оба способа.

Однозначно выбрать лучший из двух вариантов нельзя, поскольку требуется адаптация к различным хостам с серверами Telnet, которые могут не соответствовать стандартам Telnet в различных вопросах. Наиболее безопасным решением будет поддержка выбираемой пользователем опции (1), (2) или (3).

3.2.5 Принтер и клавиатура в режиме NVT: RFC 854, стр. 11

В режиме NVT серверу Telnet не следует передавать символы с установленным старшим битом8 и недопустимо использовать этот бит для контроля четности. Реализациям, передающим старший бит пользователю, следует согласовывать опцию бинарного9 режима (см. 3.2.6).

Обсуждение

Разработчики должны помнить, что RFC 854 позволяет клиентам и серверам, ожидающим NVT ASCII, игнорировать символы с установленным старшим битом. В общем случае предполагается использование бинарного режима для передачи расширенного (за пределы 7 битов) набора символов программам Telnet.

Однако, существуют приложения, которым реально требуется 8-битовое расширение режима NVT, не определенное в настоящее время, и такие приложения устанавливают старший бит на все или часть времени существования соединения Telnet. Отметим, что бинарный режим не совпадает с 8-битовым расширением NVT, поскольку в бинарном режиме отключается обработка символов завершения строки. С учетом сказанного требования к использованию старшего бита, включают глагол следует, а не требуется.

RFC 854 определяет минимальный набор свойств виртуального сетевого терминала (NVT); это не означает запрета на поддержку дополнительных функций в реальных терминалах. Соединения Telnet полностью прозрачны для всех 7-битовых символов ASCII, включая дополнительные коды управления ASCII.

Например, терминал может поддерживать полноэкранные команды, кодируемые как escape-последовательности ASCII; реализация Telnet будет передавать такие последовательности как неинтерпретируемые данные. Таким образом, режим NVT не следует трактовать, как терминал с сильно ограниченными возможностями.

3.2.6 Структура команд Telnet: RFC 854, стр. 13

Поскольку опции могут появляться в любой части потока данных, escape-символ Telnet (известный: как IAC, со значением 255), передаваемый как данные, должен дублироваться.

3.2.7 Опция Telnet Binary: RFC 856

При успешном согласовании опции Binary, разрешается использование 8-битовых символов. Однако, в потоке данных по-прежнему должны просматриваться символы IAC, должны выполняться все встроенные команды Telnet, а символы IAC в качестве данных должны дублироваться. Обработка других символов (например, замена CR на CR NUL или CR LF) недопустима. В частности, для бинарного режима не действует соглашение end-of-line (конец строки), обсуждаемое в параграфе 3.3.1.

Обсуждение

Опция Binary обычно согласуется для обоих направлений, чтобы перевести соединение Telnet из режима NVT в двоичный режим.

Последовательность IAC EOR может использоваться для обозначения границ блоков данных в бинарном потоке Telnet.

3.2.8 Опция типа терминала Telnet: RFC 1091

Опция Terminal-Type должна использовать названия типов терминалов, официально определенные в документе Assigned Numbers [INTRO:5], когда такие имена существуют для применяемых терминалов. Однако приниматься должны любые значения опции Terminal-Type.

Обсуждение

RFC 1091 [TELNET:10] содержит обновленное (по сравнению с RFC 930) определение опции Terminal-Type. Прежняя версия позволяла хосту сервера поддерживать множество типов терминалов для определения типа клиентского терминала на основе предположения, что каждый физический терминал имеет собственный тип. Однако сегодня терминал в большинстве случаев является на самом деле программой эмуляции терминала на базе ПК, которая зачастую может поддерживать различные типы терминалов. Следовательно, RFC 1091 расширяет спецификацию, позволяя более общее согласование типа терминала между клиентом и сервером Telnet.

3.3 Частные вопросы

3.3.1 Соглашение Telnet о завершении строки

Протокол Telnet определяет последовательность символов CR LF в качестве сигнала завершения строки. Для терминального ввода это соответствует завершению команды или нажатию клавиши перевода строки на пользовательском терминале (на терминалах ASCII это клавиша CR, которая может также называться Return или Enter).

Когда сервер Telnet принимает сигнал завершения строки CR LF, как ввод с удаленного терминала, эффект должен быть таким же, как от нажатия клавиши перевода строки на локальном терминале. На хостах, использующих ASCII, в частности, получение сервером Telnet последовательности CR LF должно сопровождаться таким же эффектом, как нажатие клавиши CR на локальном терминале. Таким образом, последовательности CR LF и CR NUL должны иметь одинаковый эффект на серверных хостах ASCII при получении ввода от соединений Telnet.

Клиент Telnet должен обеспечивать возможность передачи любой из последовательностей CR LF, CR NUL и LF. Клиентам Telnet на хостах ASCII следует обеспечивать пользователю возможность выбора последовательности CR LF или CR NUL при нажатии клавиши перевода строки (по умолчанию следует использовать последовательность CR LF).

Последовательность завершения строки Telnet CR LF должна использоваться для передачи данных Telnet, которые не относятся к типу «терминал-хост» (например, при передаче вывода от сервера Telnet или встраивании других прикладных протоколов в Telnet).

Обсуждение

Для обеспечения интероперабельности между различными серверами и клиентами Telnet в протоколе Telnet определено стандартное представление сигнала завершения строки. Поскольку ASCII не включает в явном виде символа завершения строки, могут использоваться различные варианты, в зависимости от системы (например, CR, LF, CR LF). В качестве стандартной протокол Telnet определяет последовательность CR LF.

К сожалению, спецификация протокола Telnet в RFC 854 [TELNET:1] не указывает однозначно символов, которые должны передаваться от клиента к серверу при нажатии клавиши перевода строки. В результате отсутствия однозначности постоянно возникают проблемы с интероперабельностью, порождаемой различными недостаточно корректными реализациями клиентов и серверов Telnet.

Хотя протокол Telnet основан на симметричной модели взаимодействия, в сеансах удаленного доступа роли пользовательского терминала и серверного хоста различаются. Например, RFC 854 определяет CR, LF и CR LF как выходные последовательности сервера, но не задает, какие символы должны передаваться со стороны клиента Telnet при нажатии на терминале клавиши завершения строки.

При нажатии пользователем клавиши завершения строки некоторые реализации клиентов Telnet передают последовательность CR LF, а другие — CR NUL (в результате различной интерпретации одного и того же предложения в тексте RFC 854). Эти последовательности будут эквиваленты для корректно реализованных серверов на хостах ASCII, как было показано выше. Для других серверов требуется выбор режима в клиентской реализации Telnet.

Существование клиентов Telnet, которые передают только CR NUL при нажатии клавиши CR, порождает дилемму для хостов, не поддерживающих ASCII — трактовать CR NUL на входе как эквивалент CR LF, препятствуя возможности ввода только CR, или полностью терять связь с сетью.

Предположим, что пользователь на хосте A применяет Telnet для доступа к серверу на хосте B и запуска на этом хосте (B) другого клиента Telnet для работы с сервером на хосте C. Для комбинации клиент/сервер Telnet на хосте B желательно обеспечить прозрачность (т. е. для хоста A такое подключение должно выглядеть, как прямое соединение с сервером C). В частности, корректная реализация будет обеспечивать прозрачность для Telnet-последовательностей завершения строки (за исключением преобразования CR LF в CR NUL и обратно).

Реализация

Чтобы разобраться с вопросами трактовки завершения строки в Telnet, нужно понять по крайней мере общую модель взаимодействия Telnet с локальной ОС. Серверный процесс Telnet обычно встроен в терминальный драйвер операционной системы как псевдотерминал. Последовательность завершения строки, принимаемая сервером Telnet, должна давать такой же эффект, как нажатие клавиши перевода строки на локально подключенном терминале.

Операционные системы, поддерживающие интерактивные приложения с посимвольным вводом (например, текстовые редакторы), обычно поддерживают два внутренних режима для своих терминалов ввода-вывода — форматированный режим, при котором к потоку данных применяется соглашение о завершении строки и другие правила форматирования, и режим необработанного текста (raw), при котором приложение имеет прямой доступ к символу сразу после его ввода. Серверы Telnet должны быть реализованы таким образом, чтобы оба режима имели одинаковый эффект для локальных и удаленных терминалов. Для примера предположим, что последовательность CR LF или CR NUL принимается сервером Telnet на хосте ASCII. В режиме raw передается приложению символ CR, а в форматированном режиме используется локальное соглашение о символах завершения строки.

3.3.2 Терминалы ввода данных

Обсуждение

В дополнение к строковым и символьным терминалам ASCII, для которых был разработан протокол Telnet, существует еще несколько семейств видео-терминалов, которые называют терминалами ввода данных или DET10. Семейство IBM 3270 является широко известным примером такого типа терминалов.

Для поддержки базовых типов DET были разработаны два протокола Internet — SUPDUP [TELNET:16, TELNET:17] и опция DET [TELNET:18, TELNET:19]. Опция DET обслуживает терминалы ввода данных через соединения Telnet с использованием (суб)согласования. SUPDUP представляет собой самостоятельный терминальный протокол, который может быть введен из Telnet путем согласования. Хотя протокол SUPDUP и опцию DET можно успешно использовать в отдельных типах сред, ни один из этих вариантов не обеспечивает универсальности.

Другим вариантом использования DET является реализация поддержки семейства терминалов IBM 3270 с помощью Telnet (это применимо к любым терминалам DET). Идея состоит в создании режима native DET, в котором оригинальные потоки ввода-вывода DET передаются, как двоичные данные. Команда Telnet EOR используется в этом случае для обозначения границ логических записей (например, «экранов») в двоичном потоке.

Реализация

Для активизации и отключения режима native DET используются следующие правила:

  • сервер использует опцию Terminal-Type [TELNET:10] для определения принадлежности клиента к DET;
  • обе стороны согласуют опцию EOR [TELNET:9] (это общепринято, но не обязательно);
  • обе стороны согласуют опцию Binary [TELNET:3] для перехода в режим native DET;
  • когда одна из сторон выходит из бинарного режима, другая сторона также должна сделать это, вернувшись в режим NVT.

3.3.3 Поддержка опций

Каждая реализация Telnet должна поддерживать опции Binary [TELNET:3] и Suppress Go Ahead [TELNET:5]; следует также поддерживать опции Echo [TELNET:4], Status [TELNET:6], End-of-Record [TELNET:9] и Extended Options List [TELNET:8].

Для клиентов и серверов Telnet следует поддерживать опцию Window Size [TELNET:12], если локальная ОС обеспечивает соответствующие возможности.

Обсуждение

Отметим, что опция End-of-Record (конец записи) означает лишь, возможность Telnet получать Telnet EOR без краха; следовательно, каждый модуль Telnet может попытаться согласовать опцию End-of-Record (см. 3.2.3).

3.3.4 Инициирование согласования опций

При использовании протокола Telnet в режиме клиент-сервер для сервера следует инициировать согласование режима взаимодействия с терминалом, который ожидает сервер.

Обсуждение

Протокол Telnet был определен как симметричный, но его реальное применение обычно бывает асимметричным. Удаленный вход в систему приводит к краху, если ни одна из сторон не инициирует согласования требуемых ей опций, которые не установлены по умолчанию. Обычно сервер определяет предпочтительный режим, поэтому сервер и должен инициировать согласование опций. Поскольку процесс согласования является симметричным, клиент также может быть инициатором.

Клиентам Telnet следует предоставлять пользователю возможность разрешить или запретить инициативу клиента по согласованию опций.

Обсуждение

Пользователям иногда требуется подключение к прикладным службам (например, FTP или SMTP), которые используют протокол Telnet для управления своими потоками данных, но не поддерживают опции Telnet. Для этих целей может использоваться клиент Telnet, если инициатива по согласованию опций для этого клиента запрещена.

3.3.5 Опция Telnet Linemode

Обсуждение

Важную роль играет новая опция Telnet LINEMODE [TELNET:12], обеспечивающая возможность согласования между клиентом и сервером обработки терминальных символов на стороне клиента, а не сервером. Когда клиент подготовит всю строку текста, он будет передавать ее серверу (обычно) в одном сегменте TCP. Эта опция позволяет существенно снизить число пакетов в сеансах Telnet и значительно ускорить отклик в нагруженных сетях или при значительных задержках в сети.

Опция LINEMODE позволяет динамически переключаться между локальной и удаленной обработкой символов. Например, соединение Telnet будет автоматически переходить в посимвольный режим при работе с полноэкранным редактором и возвращаться в строковый режим при завершении работы с редактором.

Предполагается, что после выпуска этого RFC хосты будут реализовать эту опцию для клиентских программ. Для корректной реализации опции на серверах последние должны обеспечивать возможность сказать локальной операционной системе, что не нужно обрабатывать символьный ввод, но следует запоминать текущее состояние терминала и уведомлять серверный процесс Telnet при изменении состояния. Это позволит обеспечить корректный вывод эхо-символов паролей и нормальную работу полноэкранных редакторов.

3.4 Пользовательский интерфейс TELNET

3.4.1 Прозрачность набора символов

Для реализаций клиентов Telnet следует обеспечивать возможность приема и передачи любых 7-битовых символов ASCII. Следует по возможности обходить все интерпретации специальных символов операционной системой пользовательского хоста, чтобы такие символы могли удобно приниматься и передаваться через соединение.

Какой-либо символ должен быть зарезервирован для перехода в командный режим (escape to command mode) с дублированием этого символа, когда он встречается в потоке данных. Следует предоставлять пользователю возможность выбора такого символа.

Для двоичных соединений клиент Telnet может обеспечивать escape-механизм для введения произвольных 8-битовых символов, если операционная система хоста не позволяет вводить такие символы непосредственно с клавиатуры.

Реализация

Вопросы прозрачности менее актуальны для серверов, но разработчики должны быть аккуратны и в этом случае — маскировать биты четности (передаются старыми, нестандартными клиентами) до того, как они будут переданы программам, ожидающим только NVT ASCII, и корректно обслуживать программы, запрашивающие 8-битовые потоки данных.

3.4.2 Команды Telnet

Клиент Telnet должен предоставлять пользователю возможность ввода управляющих функций Telnet IP, AO и AYT, следует также обеспечивать возможность ввода EC, EL и Break.

3.4.3 Ошибки соединений TCP

Клиенту Telnet следует сообщать пользователю о любых ошибках TCP, о которых сообщает транспортный уровень (см параграф «Интерфейс между TCP и прикладным уровнем» в работе [INTRO:1]).

3.4.4 Использование нестандартных портов

Для клиентов Telnet следует предоставлять пользователю возможность выбора нестандартного номера порта на хосте сервера Telnet.

3.4.5 Отсечение вывода

Для клиентов Telnet следует предоставлять пользователю возможность задавать режим отсечения вывода при передаче IP (см. 3.2.4).

Для любой схемы отсечения вывода, которая заставляет клиента Telnet отсекать вывод локально, пока не будет получен сигнал Telnet от сервера, следует обеспечить пользователю возможность вручную восстанавливать нормальный вывод, когда сервер не передает ожидаемый сигнал.

3.5. Требования к TELNET

Функция

Параграф

Требования

Согласование опций

3.2.1

Обязательно

Предотвращение петель при согласовании

3.2.1

Обязательно

Отказ от неподдерживаемых опций

3.2.1

Обязательно

Возможность согласования в течение всего сеанса

3.2.1

Следует

Использование по умолчанию режима NVT

3.2.1

Обязательно

Передача официальных названий в опции Term-Type

3.2.8

Обязательно

Восприятие любых имен в опции Term-Type

3.2.8

Обязательно

Поддержкаопций Binary, Supress-GA

3.3.3

Обязательно

Опции Echo, Status, EOL, Ext-Opt-List

3.3.3

Следует

Реализация опции Window-Size при наличии поддержки в ОС

3.3.3

Следует

Сервер инициирует согласование режима

3.3.4

Следует

Пользователь может разрешить и запретить согласование единиц

3.3.4

Следует

Go-Ahead

 

 

Сервер, не поддерживающий GA, согласует опцию Supress-GA

3.2.2

Обязательно

Клиент или сервер принимает опцию Supress-GA

3.2.2

Обязательно

Клиент Telnet игнорирует GA

3.2.2

Возможно

Функции управления

 

 

Поддержка SE NOP DM IP AO AYT SB

3.2.3

Обязательно

Поддержка EOR EC EL Break

3.2.3

Возможно

Игнорирование неподдерживаемых функций управления

3.2.3

Обязательно

Клиент и сервер отбрасывают срочные данные вплоть до DM

3.2.4

Обязательно

Клиент передает Synch после IP, AO, AYT

3.2.4

Следует

Сервер отвечает Synch на IP

3.2.4

Возможно

Сервер отвечает Synch на AO

3.2.4

Обязательно

Клиент может отсекать вывод при передаче IP

3.2.4

Возможно

Кодировка символов

 

 

Использование старшего бита в режиме NVT

3.2.5

Не следует

Использование старшего бита для контроля четности

3.2.5

Недопустимо

Согласование. двоичного режима при передаче старшего бита приложениям

3.2.5

Следует

Дублирование IAC в потоке данных в любом режиме

3.2.6

Обязательно

Дублирование IAC в потоке данных при бинарном режиме

3.2.7

Обязательно

Следовать командам Telnet в бинарном режиме

3.2.7

Обязательно

Завершение строки CR NUL в бинарном режиме

3.2.7

Недопустимо

4. Передача файлов

4.1 Протокол передачи файлов — FTP

4.1.1 Введение

Протокол передачи файлов FTP является основным средством обмена файлами в сети Internet. Текущая спецификация протокола содержится в RFC 95911 [FTP:1].

FTP обеспечивает независимые одновременные соединения TCP для управления и передачи данных. Протокол FTP включает множество возможностей, из которых только часть относится к общеприменимым. Однако для каждой из возможностей FTP существует, по крайней мере, одна реализация. Минимальная реализация, оговоренная в RFC 959, оказалась слишком примитивной, поэтому здесь определяются некоторые дополнительные требования.

Пользователи Internet в течение многих лет вынуждены были использовать дефективные реализации FTP. Разработчики приложений зачастую основывались на ошибочном предположении, что реализация FTP должна быть тривиальной. Это неверно, поскольку FTP имеет пользовательский интерфейс и программы должны работать (корректно) со всеми коммуникационными и операционными системами, обеспечивая устойчивость к их ошибкам.

4.1.2. Общие вопросы

4.1.2.1 Тип LOCAL: RFC 959, 3.1.1.4

Программы FTP должны поддерживать тип I (IMAGE или бинарный тип), а также тип L 8 (LOCAL — локальный с логическим размером байта 8). Машины, память которых организована в слова размерности m и значение m не кратно 8, могут также поддерживать тип L m.

Обсуждение

Команда TYPE L 8 часто требуется для передачи двоичных данных между машинами, память которых организована (например) в 36-битовые слова, и машинами с байтовой (8 битов) организацией памяти. Для машин с байтовой организацией памяти типы L 8 и IMAGE эквивалентны.

TYPE L m иногда используется программами FTP при обмене между двумя машинами с m-битовыми словами для обеспечения корректной передачи данных в естественном формате с одной машины на другую. Однако эта команда на таких машинах должна обеспечивать такой же эффект, как TYPE I.

4.1.2.2 Управление форматом Telnet: RFC 959, 3.1.1.5.2

Хостам, не делающим различий между TYPE N и TYPE T, следует реализовать тип T идентично типу N.

Обсуждение

Такое решение должно упрощать интероперабельность с хостами, которые различают эти типы.

Многие хосты используют для текстовых файлов внутреннее представление в виде строк символов ASCII, используя встроенные символы форматирования ASCII (LF, BS, FF, …) для управления форматом при печати. Для таких хостов не существует разницы между пригодными для печати файлами и остальными типами файлов. Однако, системы, которые используют структурированные в виде записей файлы, требуют для печати использования специальных форматов (например, ASA для управления кареткой). Для таких хостов протокол FTP позволяет выбирать типе — TYPE N или TYPE T.

4.1.2.3 Структура страницы: RFC 959, 3.1.2.3 и Appendix I

Реализовать структуру страницы в общем случае не следует. Однако, если хосту не нужна реализация FTP для доступа к файлам типа random access (произвольный доступ) или holey («дырявый»), он должен использовать определенный формат структуры страницы вместо определения нового частного формата FTP.

4.1.2.4 Преобразования структуры данных: RFC 959, 3.1.2

Преобразования FTP между record-structure и file-structure следует делать обратимыми, чтобы расширить возможности использования файла на хосте получателе.

Обсуждение

RFC 959 требует обратимости преобразований структуры между record-structure и file-structure, но на практике вопросы эффективности и удобства зачастую препятствуют такой обратимости и требование остается невыполненным. Существует два различных подхода к передаче файлов — хост-получатель обрабатывает файлы или просто сохраняет их. Для варианта простого сохранения обратимость преобразований имеет важное значение. При обработке файлов получателем файл, создаваемый на приемной стороне, должен использовать формат, ожидаемый прикладной программой на этом хосте.

В качестве примера конфликта рассмотрим ориентированные на записи ОС, которые требуют, чтобы некоторые файлы данных использовали записи размером в точности 80 байтов. При сохранении файла на таком хосте сервер FTP должен обеспечивать возможность дополнения каждой строки или записи до требуемых 80 байтов; при последующем обращении к таким файлам исходное состояние не всегда можно восстановить (необратимое преобразование).

4.1.2.5 Управление соединением для передачи данных: RFC 959, 3.3

FTP-клиентам, которые используют потоковый режим (STREAM), следует посылать команду PORT для выделения нестандартного (non-default) порта для передачи данных по каждой из команд.

Обсуждение

Это требование обусловлено наличием значительной задержки между закрытием соединения TCP для пары сокетов и возможностью организации повторного соединения для этой же пары. Использование нестандартных портов позволяет организовать множество потоков данных в одном сеансе FTP. Передачи команды PORT можно избежать при использовании других режимов (не потокового), оставляя открытым соединение для передачи данных.

4.1.2.6 Команда PASV: RFC 959, 4.1.2

Сервер FTP должен поддерживать команду PASV.

Если в одной сессии организуется множество передач файлов различным клиентам, новые команды PASV должны вводиться перед каждой командой новой передачи для получения уникального номера порта.

Реализация

Формат отклика 227 на команду PASV не стандартизован должным образом. В частности, клиент FTP не может предполагать наличие круглых скобок, показанных на странице 40 в RFC 959 (и, фактически, опущенных на рисунке 3, стр. 43). Следовательно, клиент FTP, интерпретирующий отклик PASV, должен сканировать весь отклик для обнаружения первой цифры адреса хоста и номера порта.

Отметим, что h1,h2,h3,h4 задает IP-адрес серверного хоста, который передал отклик, а p1,p2 указывает нестандартный порт выделенный для передачи данных командой PASV.

4.1.2.7 Команды LIST и NLST: RFC 959, 4.1.3

Данные, возвращаемые командой NLST, должны содержать только простой список корректных параметров, которые сервер может непосредственно использовать, как аргументы в последующих командах передачи данных для отдельных файлов.

Для данных, возвращаемых командами LIST и NLST, рекомендуется использовать неявняй тип TYPE AN, если не задан в качестве текущего тип EBCDIC; если в качестве неявного задан тип TYPE EN, следует использовать этот тип.

Обсуждение

Многие клиенты FTP поддерживают макрокоманды, для загрузки (get) или выгрузки (put) файлов, соответствующих шаблону, с использованием команды NLST для получения списка имен. Расширение multiple-put является локальным для клиента, а multiple-get требует взаимодействия с сервером.

Для команд LIST и NLST разработан неявный тип, обеспечивающий совместимость с существующими клиентами FTP и поддерживающий групповые команды get.

4.1.2.8 Команда SITE: RFC 959, 4.1.3

Серверам FTP рекомендуется использовать команду SITE для поддержки нестандартных функций, взамен реализации фирменных нестандартных команд или нестандартного расширения существующих команд.

4.1.2.9 Команда STOU: RFC 959, 4.1.3

Команда STOU позволяет сохранять файлы с уникальными именами. При получении команды STOU сервер FTP должен возвратить актуальное имя файла в сообщении «125 Transfer Starting» или «150 Opening Data Connection», предшествующем передаче (код 250, указанный в RFC 959, некорректен для таких случаев). Точный формат сообщения показан ниже:

125 FILE: pppp

150 FILE: pppp

pppp представляет уникальное полное имя файла, который будет записан.

4.1.2.10 Код завершения строки Telnet: RFC 959, стр. 34

Недопустимо делать какие-либо предположения о соответствии между границами READ в управляющем соединении и последовательностями завершения строки Telnet EOL (CR LF).

Обсуждение

Таким образом, сервер или клиент FTP должен продолжать чтение символов из управляющего соединения, пока не будет получена полная последовательность Telnet EOL, прежде, чем начинать обработку команд (или откликов). Одна операция READ может получать из управляющего соединения несколько команд FTP.

4.1.2.11 Отклики FTP: RFC 959, 4.2, стр. 35

Сервер FTP должен передавать только корректно форматированные отклики в управляющее соединение. Отметим, что RFC 959 (в отличие от ранних спецификаций FTP) не содержит мер предосторожности для нестандартных откликов.

Серверам следует использовать коды откликов, определенные в RFC 959, всякий раз, когда это возможно. Однако сервер может использовать при необходимости иные коды откликов в соответствии с общими правилами (см. параграф 4.2). При выборе между кодами 4xx и 5xx серверам следует посылать коды 4xx (временный сбой), когда есть какая-то реальная возможность восстановления сервиса FTP в течение нескольких часов.

В общем случае клиентам следует использовать только старшую цифру 3-значного кода отклика для принятия решений — это позволяет избавиться от трудностей при получении откликов с нестандартными кодами.

Клиент FTP должен уметь работать с многострочными откликами. При получении откликов с превышающим допустимое значение числом строк клиент FTP должен сохранять нормальный режим работы (например, пропускать лишние строки до конца сообщения).

Клиентам FTP не следует специально интерпретировать код отклика 42112, но следует детектировать закрытие сервером управляющего соединения.

Обсуждение

Реализации серверов с некорректными откликами часто приводят к зависанию клиентских программ FTP. Отметим, что RFC 959 устраняет неоднозначности в правилах передачи откликов, присутствовавшие в ранних спецификациях FTP.

Важно выбирать коды откликов FTP, которые позволяют отличать временные сбои от постоянных проблем, что позволяет успешно использовать клиентские демоны FTP. Работа таких программ зависит от кода отклика, на основе которого принимается решение о продолжении попыток. Использование кодов 5xx (постоянная проблема) для временных сбоев может приводить к некорректной работе демонов.

Говоря о том, что отклики должны в точности соответствовать RFC 959, зачастую трактуют это соответствие, как дословную передачу. Однако, разработчикам серверов FTP следует выбирать (по возможности) тексты откликов, специфические для используемой ОС.

4.1.2.12 Соединения: RFC 959, 5.2

Слова «and the port used» во втором абзаце параграфа 5.2 RFC 959 являются (исторической) ошибкой и не должны приниматься во внимание.

На многодомных серверных хостах используемый по умолчанию порт передачи данных (L-1) должен связываться с тем же локальным адресом IP, который используется вместе с соответствующим портом управляющего соединения L.

Для клиентов FTP недопустимо передавать какие-либо коды управления Telnet, за исключением SYNCH и IP в управляющие соединения FTP. В частности, недопустимо для клиента согласовывать опции Telnet для управляющего соединения. Однако, сервер FTP должен быть способен воспринимать согласование опций Telnet и отказывать в таком согласовании (например, передавая DONT/WONT).

Обсуждение

Хотя в RFC сказано: «Server- and User-processes should follow the conventions for the Telnet protocol…[on the control connection]13», это не имеет отношения к согласованию опций Telnet.

4.1.2.13 Минимальна реализация: RFC 959, 5.1

Перечисленные ниже команды и опции должны поддерживаться всеми клиентами и серверами FTP, за исключением случаев, когда файловая система или ОС не позволяют реализовать ту или иную возможность.

Типы: ASCII Non-print, IMAGE, LOCAL 8

Режимы: Stream

Структуры: File, Record14

Команды:

USER, PASS, ACCT,

PORT, PASV,

TYPE, MODE, STRU,

RETR, STOR, APPE,

RNFR, RNTO, DELE,

CWD, CDUP, RMD, MKD, PWD,

LIST, NLST,

SYST, STAT,

HELP, NOOP, QUIT.

Обсуждение

Поощряется реализация более широкого набора команд и опций. Например, в протоколе заложены важные средства обеспечения устойчивости (например, Restart, ABOR, блоковый режим), которые будут интересны некоторым пользователям Internet, но реализованы далеко не всегда.

Хост, который не использует структуры записей в своей файловой системе, может по-прежнему воспринимать файлы с STRU R, записывая байтовый поток «дословно».

4.1.3 Частные вопросы

4.1.3.1 Нестандартные команды

FTP позволяет использовать «экспериментальные» команды, имена которых начинаются с «X». При последующем включении команд в стандартные спецификации, они по-прежнему могут начинаться с X. Ниже представлен список экспериментальных команд:

RFC 959    Экспериментальные
MKD        XMKD
RMD        XRMD
PWD        XPWD
CDUP       XCUP
CWD        XCWD

Для всех реализаций FTP следует распознавать обе формы этих команд, просто просматривая дополнительные записи в таблице команд.

Реализация

Клиент FTP может обращаться к серверу, поддерживающему только X-команды, с помощью переключателя режима или за счет автоматического использования следующей процедуры — если стандартная (RFC 959) форма любой из перечисленных выше команд была отвергнута с кодом 500 или 502, следует попытаться использовать расширенную команду; все остальные отклики будут передаваться пользователю.

4.1.3.2 Время бездействия

Для серверных процессов FTP следует задавать время бездействия, по истечении которого процесс будет прерываться в случае отсутствия активности (нет команд или передачи данных). Значение тайм-аута следует делать настраиваемым и по умолчанию время бездействия должно составлять 5 минут.

Клиентскому процессу FTP (User-PI в RFC 959) тайм-аут на отклики нужен лишь в случаях вызова клиента из программ.

Обсуждение

Без использования тайм-аута сервер FTP может неограниченно долго оставаться в состоянии ожидания при крахе клиента без разрыва управляющего соединения.

4.1.3.3 Одновременное управление и передача данных

Обсуждение

При разработке протокола FTP ставилась задача обеспечения пользователю возможности передать в любой момент в процессе передачи данных команду STAT, на которую сервер будет незамедлительно возвращать информацию о состоянии (например, размер переданной части файла). Подобно этому команда ABOR должна обеспечивать возможность прерывания передачи данных в любой момент.

К несчастью, некоторые ОС (в небольших машинах) затрудняют программирование одновременных операций. Отдельные разработчики идут по пути наименьшего сопротивления, не поддерживая в своих реализациях возможности управления в процессе передачи данных. Но даже в минимальной реализации серверы должны быть готовы к восприятию и отсрочке команд STAT и ABOR, получаемых во время передачи данных.

4.1.3.4 Механизм FTP Restart

В описании отклика 110 на стр. 40-41 RFC 959 допущена ошибка, исправленная здесь. Сообщение restart reply, передаваемое через управляющее соединение от принимающего FTP клиенту FTP, имеет формат:

110 MARK ssss = rrrr

где:

  • ssss — текстовая строка, которая появляется в Restart Marker в потоке данных и кодирует позицию в файловой системе отправителя;
  • rrrr — кодирует соответствующую позицию в файловой системе получателя.

Кодирование зависит от используемой ОС и сетевой реализации и всегда генерируется и интерпретируется одной и той же системой (отправителем или получателем).

Когда FTP, реализующий рестарт, получает Restart Marker в потоке данных, следует форсировать запись данных до этой точки на стабильную среду для кодирования соответствующей позиции rrrr. Для FTP, передающего Restart Markers, не допускается предположение о возврате откликов 110 синхронно с данными (т. е., следует дождаться отклика 110 перед продолжением передачи данных).

Для сообщений об ошибках при рестарте передачи определяются два новых кода:

554 Requested action not taken: invalid REST parameter — запрошенное действие не выполнено: некорректный параметр REST.

Отклик 554 может быть результатом сервисной команды FTP, которой следует за командой REST. Отклик показывает, что существующий файл на сервере FTP невозможно репозиционировать в соответствии с командой REST.

555 Requested action not taken: type or stru mismatch — запрошенное действие не выполнено: несоответствие типа или stru.

Отклик 555 может быть результатом команды APPE или любой сервисной команды FTP, за которой следует команда REST. Этот код говорит о рассогласовании между текущими параметрами передачи (type и stru) и атрибутами существующего файла.

Обсуждение

Отметим, что механизм FTP Restart требует использования режима Block или Compressed для передачи данных, чтобы обеспечивалась возможность включения маркеров Restart Marker в поток данных. Частота передачи маркеров может быть достаточно низкой.

Restart Marker отмечает место в потоке данных, но получатель может выполнять некоторые преобразования данных при их сохранении в стабильной среде. В общем случае кодирование на приемной стороне должно включать любую информацию о состоянии, которая может потребоваться для возобновления передачи с любой точки потока данных FTP. Например, при передачах TYPE A некоторые принимающие хосты преобразуют последовательности CR LF в один символ LF при записи файла на диск. Если Restart Marker попадает между CR и LF, принимающая сторона должна указать в rrrr, что передача должна возобновляться в состоянии «CR has been seen and discarded» (получен и отброшен символ возврата каретки).

Отметим, что Restart Marker требуется обозначать, как строку печатных символов ASCII, независимо от типа данных.

RFC 959 говорит, что информация о возобновлении будет возвращаться пользователю. Это высказывание не следует понимать буквально. В общем случае клиенту FTP следует сохранять информацию о возобновлении (ssss,rrrr) на стабильной среде (например, дописывать ее в файл управления возобновлением передачи). Пустое поле управления рестартом следует создавать при начале передачи и автоматически удалять после ее успешного завершения. Предполагается, что имя такого файла будет связано с именем передаваемого файла и удаленного хоста (по типу имен для резервных копий редактируемых файлов в текстовых редакторах).

Возможны три варианта рестарта FTP.

  1. Передача от пользователя к серверу

Клиент FTP помещает маркеры Restart <ssss> в подходящие места потока данных. Когда сервер FTP получает маркер, он записывает все предшествующие данные на диск, кодируя позицию в своей файловой системе и состояние преобразования как rrrr, после чего возвращает отклик «110 MARK ssss = rrrr» через управляющее соединение. Клиент FTP дописывает пару (ssss,rrrr) в конец своего файла управления возобновлением передачи.

Для возобновления передачи FTP-клиент делает выборку последней пары (ssss,rrrr) из своего управляющего файла, меняет позицию в своей файловой системе и состояние, используя значение ssss, после чего передает серверу команду REST rrrr.

  1. Передача от сервера к пользователю

Сервер FTP помещает маркеры Restart <ssss> в подходящие места потока данных. Когда клиент FTP получает маркер, он записывает все предшествующие данные на диск, кодируя позицию в своей файловой системе и состояние преобразования как rrrr, после чего дописывает пару (rrrr,ssss) в конец своего файла управления рестартом.

Для возобновления передачи FTP-клиент делает выборку последней пары (ssss,rrrr) из своего управляющего файла, меняет позицию в своей файловой системе и состояние, используя значение ssss, после чего передает серверу команду REST ssss.

  1. Передача от сервера к серверу (Third-Party)

Передающий сервер помещает маркеры Restart <ssss> в подходящие места потока данных. Когда принимающий сервер получает маркер, он записывает все предшествующие данные на диск, кодируя позицию в своей файловой системе и состояние преобразования как rrrr, после чего возвращает отклик «110 MARK ssss = rrrr» через управляющее соединение. Клиент FTP дописывает пару (ssss,rrrr) в конег своего файла управления возобновлением передачи.

Для возобновления передачи FTP-клиент делает выборку последней пары (ssss,rrrr) из своего управляющего файла и отправляет сообщение REST ssss передающему серверу FTP и REST rrrr — принимающему серверу FTP.

4.1.4 Пользовательский интерфейс FTP

В этом разделе рассматривается пользовательский интерфейс FTP.

4.1.4.1 Спецификация Pathname

Поскольку протокол FTP предназначен для гетерогенных систем, реализация клиента должна поддерживать имена удаленных файлов как произвольные символьные строки, форма и содержание которые не ограничены соглашениями локальной ОС.

Обсуждение

В частности, имена удаленных файлов могут иметь произвольную длину и содержать любые печатаемые символы ASCII, включая пробелы (0x20). RFC 959 позволяет включать в имена все 7-битовые символы ASCII, за исключением CR и LF.

4.1.4.2 Команда QUOTE

Клиент FTP должен поддерживать команду QUOTE, которая будет передавать серверу произвольные символьные строки и выводить на консоль полученные на них отклики.

Чтобы команда QUOTE была полезна, клиентам FTP следует передавать серверу команды управления как ввод от пользователя, а не сохранять их для передачи серверу после того, как начнется передача данных.

Обсуждение

Команда QUOTE обеспечивает пользователям возможность доступа к серверам, которые требуют ввода специфических команд (например, SITE или ALLO), и позволяет реализовать возможности, не реализованные в стандартных клиентах FTP. В качестве примера использования QUOTE может служить команда TYPE A T для передачи файла на печать хостам, которые требуют различия типов, хотя клиент FTP не распознает эти типы.

4.1.4.3 Передача откликов пользователю

Для FTP-клиентов следует выводить для пользователя полный текст всех полученных сообщений об ошибках. Следует также поддерживать режим verbose, в котором выводятся полностью все переданные команды и полный текст откликов с кодом результата. Такая возможность позволяет упростить поиск проблем.

4.1.4.4 Поддержка синхронизации

Клиентам FTP следует быть устойчивыми к потере сообщений и неожиданным откликам, чтобы поддерживать синхронизацию команд с сервером.

4.1.5 Требования к FTP

Функция Параграф Требования
Если не делается различий, реализовать TYPE T, как TYPE N 4.1.2.2 Следует
Обратимое преобразование файлов/записей 4.1.2.4 Следует
Клиент FTP передает команду PORT для потокового режима 4.1.2.5 Следует
Реализация сервером FTP команды PASV 4.1.2.6 Обязательно
PASV для каждой передачи отдельно 4.1.2.6 Обязательно
Возможность использования отклика NLST в командах RETR 4.1.2.7 Обязательно
Подразумеваемый тип для команд LIST и NLST 4.1.2.7 Следует
Команда SITE для нестандартных функций 4.1.2.8 Следует
Команда STOU возвращает указанное им файла (pathname) 4.1.2.9 Обязательно
Использование границ TCP READ на управляющем соединении 4.1.2.10 Недопустимо
Сервер передает отклики только в корректном формате 4.1.2.11 Обязательно
Сервер использует только стандартные отклики 4.1.2.11 Следует
Новые отклики в соответствии с требованиями параграфа 4.2 4.1.2.11 Возможно
Клиент использует только старшую цифру отклика 4.1.2.11 Следует
Клиент может работать с многострочными откликами 4.1.2.11 Обязательно
Специальная обработка клиентом откликов с кодом 421 4.1.2.11 Не следует
Порт данных по умолчанию использует тот же IP-адрес, что и порт управления 4.1.2.12 Обязательно
Клиент FTP передает команды Telnet (за исключением Synch, IP) 4.1.2.12 Недопустимо
Клиент FTP согласует опции Telnet 4.1.2.12 Недопустимо
Сервер FTP обслуживает опции Telnet 4.1.2.12 Обязательно
Поддержка «экспериментальных» команд 4.1.3.1 Следует
Тайм-аут по бездействию для серверов 4.1.3.2 Следует
Настраиваемое значение тайм-аута 4.1.3.2 Следует
Restart Marker как контрольная точка для приемной стороны 4.1.3.4 Следует
Отправитель предполагает синхронный характер откликов 110 4.1.3.4 Недопустимо
Поддержка типов (TYPE):
ASCII — Non-Print (AN) 4.1.2.13 Обязательно
ASCII — Telnet (AT) — то же, что AN 4.1.2.2 Следует
ASCII — Carriage Control (AC) 959 3.1.1.5.2 Возможно
EBCDIC — (люба форма) 959 3.1.1.2 Возможно
IMAGE 4.1.2.1 Обязательно
LOCAL 8 4.1.2.1 Обязательно
LOCAL m 4.1.2.1 Возможно
Поддержка режимов (MODE):
Stream (поток) 4.1.2.13 Обязательно
Block (блок) 959 3.4.2 Возможно
Поддержка структур (STRUCTURE):
File (файл) 4.1.2.13 Обязательно
Record (запись) 4.1.2.13 Обязательно
Page (страница) 4.1.2.3 Не следует
Поддержка команд:
USER 4.1.2.13 Обязательно
PASS 4.1.2.13 Обязательно
ACCT 4.1.2.13 Обязательно
CWD 4.1.2.13 Обязательно
CDUP 4.1.2.13 Обязательно
SMNT 959 5.3.1 Возможно
REIN 959 5.3.1 Возможно
QUIT 4.1.2.13 Обязательно
PORT 4.1.2.13 Обязательно
PASV 4.1.2.6 Обязательно
TYPE 4.1.2.13 Обязательно
STRU 4.1.2.13 Обязательно
MODE 4.1.2.13 Обязательно
RETR 4.1.2.13 Обязательно
STOR 4.1.2.13 Обязательно
STOU 959 5.3.1 Следует
APPE 4.1.2.13 Обязательно
ALLO 959 5.3.1 Возможно
REST 959 5.3.1 Возможно
RNFR 4.1.2.13 Обязательно
RNTO 4.1.2.13 Обязательно
ABOR 959 5.3.1 Возможно
DELE 4.1.2.13 Обязательно
RMD 4.1.2.13 Обязательно
MKD 4.1.2.13 Обязательно
PWD 4.1.2.13 Обязательно
LIST 4.1.2.13 Обязательно
NLST 4.1.2.13 Обязательно
SITE 4.1.2.8 Возможно
STAT 4.1.2.13 Обязательно
SYST 4.1.2.13 Обязательно
HELP 4.1.2.13 Обязательно
NOOP 4.1.2.13 Обязательно
Пользовательский интерфейс:
Произвольные имена файлов (pathname) 4.1.4.1 Обязательно
Реализация команды QUOTE 4.1.4.2 Обязательно
Непосредственна передача команд управления 4.1.4.2 Следует
Вывод сообщений об ошибках на консоль пользователя 4.1.4.3 Следует
Режим Verbose 4.1.4.3 Следует
Поддержка синхронизации с сервером 4.1.4.4 Следует

4.2 Тривиальный протокол передачи файлов TFTP

4.2.1 Введение

Простой протокол передачи файлов (Trivial File Transfer Protocol — TFTP) определен в RFC 783 [TFTP:1].

TFTP своими средствами обеспечивает надежную доставку на базе транспортного протокола UDP, используя простую систему подтверждений stop-and-wait (остановиться и подождать). Поскольку TFTP работает только с одним окном размером 512 октетов, этот протокол может эффективно использоваться только на путях с небольшим значением произведения задержка*полоса. Интерфейс TFTP очень прост и не обеспечивает контроля доступа и безопасности.

Основным применением TFTP является стартовая загрузка (bootstrapping) хостов через локальную сеть, поскольку этот протокол достаточно прост и может быть легко реализован в EPROM [BOOT:1, BOOT:2]. Производителям оборудования просто требуется поддерживать TFTP для загрузки устройств.

4.2.2 Общие вопросы

Спецификация TFTP [TFTP:1] написана в открытом стиле и не определяет полностью многие части протокола.

4.2.2.1 Режимы передачи: RFC 783, стр. 3

Не следует не поддерживать режим передачи mail.

4.2.2.2 Заголовок UDP: RFC 783, стр. 17

Поле Length (длина) заголовка UDP определено некорректно; это поле включает размер заголовка UDP — 8 октетов.

4.2.3 Частные вопросы

4.2.3.1 Sorcerer’s Apprentice Syndrome

В спецификации протокола содержится серьезна ошибка — «синдром ученика колдуна18», которая хоть и не приводит к некорректной передаче (файл всегда передается корректно, если передача завершена), но может привести к избыточным повторам передачи и тайм-аутам.

Во всех реализациях эта ошибка должна быть исправлена — отправитель (т. е., сторона, передающая пакеты данных) никогда не должен заново передавать текущий пакет данных (DATA) при получении дубликата подтверждения ACK.

Обсуждение

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

Для понимания проблемы может быть полезна приведенная ниже иллюстрация.

     TFTP A                 TFTP B
(1)  Прием ACK X-1
     Передача DATA X
(2)                         Прием DATA X
                            Передача ACK X
    (ACK X задерживается в сети и возникает тайм-аут):
(3)  Повтор передачи DATA X
(4)                         Прием DATA X (повт.)
                            Передача ACK X (повт.)
(5)  Прием (задерж.) ACK X
     Передача DATA X+1
(6)                         Прием DATA X+1
                            Передача ACK X+1
(7)  Прием ACK X (повт.)
     Передача DATA X+1 (повт.)
(8)                         Прием DATA X+1 (повт.)
                            Передача ACK X+1 (повт.)
(9)  Прием ACK X+1
     Передача DATA X+2
(10)                        Прием DATA X+2
                            Передача ACK X+3
(11) Прием ACK X+1 (повт.)
     Передача DATA X+2 (повт.)
(12)                        Прием DATA X+2 (повт.)
                            Передача ACK X+3 (повт.)

Отметим, что после доставки задержанного подтверждения ACK протокол начинает дублировать все последующие пакеты (пп. 5-8 и 9-12). Проблема вызывается не тайм-аутом на любой из сторон, а повторной передачей обеими сторонами при получении дубликатов.

Для решения проблемы нужно разорвать возникшую петлю, как показано выше. Это аналогично поведению протокола TCP. Можно удалить таймер повторной передачи на приемной стороне, поскольку повторная передача подтверждения ACK не будет вызывать каких-либо действий; это упрощение TFTP особенно полезно при использовании протокола для стартовой загрузки. Сохранение таймера возможно и может оказаться полезным, если повторно переданное подтверждение ACK заменяет потерянное в сети. Для отправителя таймер повторной передачи остается необходимым.

4.2.3.2 Алгоритм определения тайм-аута

Реализация TFTP должна использовать адаптивный тайм-аут.

Реализация

Алгоритмы повторной передачи TCP обеспечивают полезный прототип. Необходимо реализовать по крайней мере экспоненциальное изменение тайм-аута повторной передачи.

4.2.3.3 Расширения

К протоколу TFTP было добавлено множество нестандартных расширений, включающих дополнительные режимы передачи и обеспечение безопасности (пароли). Ни одно из этих расширений не было стандартизовано.

4.2.3.4 Контроль доступа

При реализации сервера TFTP следует включать некоторые настраиваемые возможности контроля за счет задания полных имен файлов, которые допустимы при операциях TFTP.

4.2.3.5 Широковещательные запросы

Запрос TFTP, отправленный по широковещательному адресу, следует отбрасывать без уведомления.

Обсуждение

По причине слабого контроля доступа в TFTP, передача широковещательных запросов TFTP в чужие сети может пробить существенную брешь в безопасности.

4.2.4 Требования к TFTP

Функция Параграф Требования
Преодоление синдрома Sorcerer 4.2.3.1 Обязательно
Режимы передачи:
netascii RFC 783 Обязательно
octet (октет) RFC 783 Обязательно
mail (почта) 4.2.2.1 Не следует
extensions (Расширения) 4.2.3.3 Возможно
Использование адаптивного тайм-аута 4.2.3.2 Обязательно
Настраиваемое управление доступом 4.2.3.4 Следует
Игнорирование широковещательных запросов 4.2.3.5 Следует

5. Электронная почта — SMTP и RFC 822

5.1 Введение

В стеке протоколов TCP/IP электронная почта в формате RFC 822 [SMTP:2] передается с помощью протокола SMTP19, определенного в RFC 821 [SMTP:1].

Хотя протокол SMTP остается неизменным уже в течение многих лет, сообщество Internet внесло некоторые изменения в способы использования SMTP. В частности, переход к системе доменных имен (Domain Name System или DNS) потребовал изменения формата почтовых адресов и маршрутизации электронной почты. В этом разделе предполагается наличие у читателя базовых познаний в части DNS (см. параграф 6.1).

RFC 822 является стандартом Internet для форматов электронной почты. RFC 822 отменяет действие предшествующих стандартов, хотя RFC 733 может еще использоваться, несмотря на его отмену. Эти форматы для краткости обозначают номерами — 822 и 733.

RFC 822 используется также за пределами почтовой среды Internet с почтовыми протоколами, отличными от SMTP, да и протокол SMTP также адаптирован для использования в средах, отличных от Internet. Отметим, что данный документ содержит правила использования SMTP и RFC 822 только для среды Internet; в других почтовых средах, использующих эти протоколы, можно ожидать иных правил.

5.2 Общие вопросы

Этот раздел тесно связан с RFC 821 и RFC 822. Спецификация SMTP в RFC 821 описана четко и однозначно, а также содержит множество примеров, поэтому реализация не должна вызывать затруднений. В данном разделе просто рассмотрены некоторое важные аспекты RFC 821 и внесен ряд поправок.

RFC 822 — большой и сложный документ, содержащий синтаксические определения. К сожалению, неполные и некорректные реализации RFC 822 встречаются на каждом шагу. Сегодня используются практически все из множества форматов RFC 822, поэтому программы должны распознавать и корректно интерпретировать весь синтаксис RFC 822.

5.2.1 Модель SMTP: RFC 821, раздел 2

Обсуждение

Электронная почта передается с помощью серии транзакций запрос-отклик между клиентом (sender-SMTP) и сервером (receiver-SMTP). Эти транзакции проверяют (1) корректность сообщения, состоящего из заголовка и тела письма, а также (2) SMTP-адреса для отправителя и получателя (envelope — конверт).

Программы SMTP аналогичны агентам MTA20 в среде X.400. Есть также другой уровень программ, расположенных ближе к пользователю, которые отвечают за сборку и анализ заголовков в сообщениях RFC 822; эта компонента называется пользовательским агентом (UA21) в среде X.400 и мы будем применять этот термин в данном документе. Существуют четкие различия между пользовательским агентом и реализацией SMTP, поскольку они работают на разных уровнях протокола. Отметим, однако, что это различие может неточно отражаться структурой типичных реализаций почтовых программ Internet. Очень часто программы, называемые mailer, реализуют функции SMTP и некоторые функции пользовательского агента; остальные функции UA включаются в пользовательский интерфейс, который служит для чтения и подготовки почтовых сообщений.

Конверт SMTP создается на стороне отправителя (обычно пользовательским агентом) при передаче сообщения в очередь для программы Sender-SMTP. Адрес для конверта может быть построен по адресу в заголовке сообщения, полученному от пользовательского интерфейса (например, для выполнения запроса bcc:), или найден в локальных конфигурационных параметрах (например, в списке рассылок). В общем случае конверт SMTP не может быть сгенерирован заново на более поздних этапах доставки почты, поэтому он передается отдельно от сообщения с использованием команд MAIL и RCPT протокола SMTP.

В RFC 821 предполагается, что почта доставляется отдельным пользователям на каждом хосте. С развитием доменной системы и началом маршрутизации почты на основе записей MX22 почтовые программы должны обеспечивать доставку почты пользователям в домене, а не на отдельно взятом хосте. Однако это не меняет характера SMTP, который является протоколом обмена почтой между хостами.

5.2.2 Канонизация имен: RFC 821, 3.1

Имена доменов, которые Sender-SMTP передает в командах MAIL и RCPT, должны быть «канонизированы», т. е., должны быть полностью заданными именами (principal name или domain literal), а не кличками (nickname) или сокращениями. Канонизированное имя идентифицирует непосредственно хост или имя MX и не может быть CNAME (псевдоним имени).

5.2.3 Команды VRFY и EXPN: RFC 821, 3.3

Получатель SMTP должен поддерживать команду VRFY и следует также реализовать команду EXPN (это отличается от требований RFC 821). Однако возможно запрещать обработку команд VRFY и EXPN с помощью конфигурационных опций (более того, можно даже запрещать команду EXPN для отдельных списков).

Для команды VRFY здесь определяется новый код отклика:

252 Cannot VRFY user — невозможно проверить пользователя (например, отсутствует локальна информация), но будет предпринята попытка доставить почту этому пользователю.

Обсуждение

Пользователи и администраторы SMTP регулярно обращаются к этим командам для поиска проблем с доставкой почты. С ростом использования многоуровневых почтовых списков (зачастую, более 2 уровней), возрастает важность команды EXPN при определении возможных петель в списках доставки. С другой стороны, существует мнение, что команда EXPN представляет угрозу сохранению тайны личности и, возможно, безопасности23.

5.2.4 Команды SEND, SOML, SAML: RFC 821, 3.4

SMTP может реализовать команды для передачи сообщений на пользовательский терминал: SEND, SOML, SAML.

Обсуждение

Предполагается, что трансляция почты (mail relaying) с помощью записей MX несовместима с использованием команды SEND для непосредственной доставки сообщений на пользовательский терминал. Однако принимающая программа SMTP, которая не способна писать непосредственно на пользовательский терминал, может передавать отклик «251 User Not Local» (нелокальный пользователь) на RCPT с последующей командой SEND для информирования оператора о возможности отложенной доставки.

5.2.5 Команда HELO: RFC 821, 3.5

Отправитель SMTP должен обеспечивать корректность параметра <domain> в команде HELO (полное доменное имя хоста) для клиентского хоста. В результате этого получателю SMTP не нужно будет выполнять преобразования MX для этого имени, чтобы проверить корректность параметра HELO.

Получатель HELO может проверить, что параметр HELO реально соответствует IP-адресу отправителя. Однако получатель не имеет права отказываться от восприятия сообщения даже при отрицательном результате проверки отправителя команды HELO.

Обсуждение

Проверка параметра HELO требует определения доменного имени и может, следовательно, потребовать значительного времени. Ниже предлагается другой способ определения подставных отправителей с помощью команды DATA.

Отметим также, что аргумент HELO все равно должен использовать корректный синтаксис <domain>, поскольку это имя будет появляться в строке Received: (при некорректном имени возникает ошибка 501).

Реализация

Когда проверка параметра HELO дает отрицательный результат, предлагается вставлять примечание о невозможности проверки отправителя в заголовок сообщения (например, в строку Received:).

5.2.6 Трансляция почты: RFC 821, 3.6

Различают три типа пересылки почты (возможно, с промежуточным сохранением):

  1. Простая программа пересылки (mail exchanger) рассылает сообщения с использованием частной информации о получателях (см. RFC 821, параграф 3.2).
  2. Транслятор SMTP (mail relay) пересылает сообщения в среде SMTP с использованием явно заданного отправителем маршрута (explicit source route), как определено в параграфе 3.6 RFC 821. Функции SMTP relay используют форму «@…:» для задания маршрута в соответствии с RFC 822 (см. 5.2.19 ниже).
  3. Почтовый шлюз (mail gateway) передает сообщения между различными средами. Правила работы почтовых шлюзов рассмотрены в параграфе 5.3.7.

Хостам Internet, пересылающим почту, но не являющимся шлюзами в другие почтовые среды (т. е., относящимся к типу (1) или (2)), не следует менять поля заголовков в сообщениях, хотя можно добавлять строку Received: в соответствии с требованиями параграфа 5.2.8.

Отправителям SMTP не следует передавать команду RCPT TO:, содержащую явный маршрут, с использованием адреса в формате «@…:». Таким образом, функции трансляции почты, определенные в параграфе 3.6 RFC 821, не следует использовать.

Обсуждение

Задача состоит в полном искоренении source routing и упразднении явного задания маршрутов для доставки почты в среде Internet. Задание маршрута не требуется и во всех случаях следует использовать простую форму адреса получателя — user@domain. Это является результатом принятия решения на уровне архитектуры почтовой среды об использовании универсального именования вместо явного задания маршрутов доставки почты. Таким образом, SMTP обеспечивает сквозную связность, а DNS — уникальные в масштабе планеты и не зависящие от местоположения имена. Для обработки случаев, когда может потребоваться задание маршрута используются записи MX.

Получатель SMTP должен воспринимать синтаксис явного задания маршрута в конверте, но он может реализовать функции трансляции в соответствии с параграфом 3.6 RFC 821. Если функция трансляции не реализована, получателю следует попробовать доставить сообщение напрямую хосту, указанному в адресе справа от знака @.

Обсуждение

Предположим для примера, что хост, не поддерживающий трансляции, получает сообщение с командой SMTP «RCPT TO:<@ALPHA,@BETA:joe@GAMMA>»(ALPHA, BETA и GAMMA представляют доменные имена). Вместо отказа с возвратом ошибки 550 (как предлагается на стр. 20 в RFC 821), хосту следует попытаться переслать сообщение напрямую в GAMMA с помощью команды RCPT TO:<joe@GAMMA>”. Поскольку этот хост не поддерживает трансляции, ему не требуется обновлять путь возврата.

Некоторые считают, что задание маршрута может иногда потребоваться при отправке почты вручную в случаях наличия сбоев; однако реальность и важность такого применения весьма сомнительны. Использование явной трансляции SMTP для решения таких задач не представляется разумным и, фактически, не обеспечивает успеха, поскольку многие хосты не поддерживают явного задания маршрутов. В некоторых случаях для решения таких задач используется «%-hack» (см. параграф 5.2.16).

5.2.7 Команда RCPT: RFC 821, 4.1.1

Хост, поддерживающий функции SMTP-получателя, должен обеспечивать почтовый ящик Postmaster.

Получатель SMTP может проверять параметры RCPT при доставке; однако, отклики RCPT недопустимо задерживать сверх разумного времени (см. 5.3.2).

Следовательно, отклик 250 OK для RCPT не обязательно говорит о корректности указанного адреса получателя. Информация об ошибках, обнаруженных после восприятия сообщения, будет передаваться в виде почтовых сообщений в соответствующий адрес (см. 5.3.3).

Обсуждение

Набор условий, по которому параметр RCPT должен проверяться незамедлительно, был задан при разработке архитектуры. Передача уведомления об ошибке в адресе получателя для отправителя SMTP до отправки всего сообщения имеет достаточно важное значение, поскольку позволяет снизить расход времени и полосы канала, но это преимущество может быть утеряно при длительной проверке RCPT.

Например, получатель может проверить незамедлительно любую локальную ссылку (зарегистрированный локально почтовый ящик). С другой стороны, ограничение «разумным временем» в общем случае предполагает отложенную проверку для списков рассылки (пока сообщение не будет передано и воспринято), поскольку проверка большого числа адресов потребует продолжительного времени. Реализация программы может использовать или не использовать отложенную проверку адресов, которые не являются локальными и, следовательно, требуют обращения к DNS. Если используется DNS и при запросе обнаруживается некритичная ошибка (например, тайм-аут), адрес следует считать корректным.

5.2.8 Команда DATA: RFC 821, 4.1.1

Каждый получатель SMTP (не только тот, который принимает сообщения для трансляции или окончательной доставки [SMTP:1]), должен вставлять строку Received: в начале сообщения. В этой строке, которая в RFC 821 названа «time stamp line» (строка с временной меткой), указывается:

  • в поле FROM следует включать (1) имя хоста-отправителя, представленное в команде HELO, и (2) доменное имя с адресом IP, определенным из соединения TCP;
  • поле ID может содержать «@» (как предложено в RFC 822), но это необязательно;
  • поле FOR может содержать список <path>, если было введено множество команд RCPT.

Для почтовых программ Internet недопустимо изменять строки Received:, добавленные в заголовок раньше.

Обсуждение

Включение имени хоста и IP-адреса отправителя в строку Received: может предоставить достаточно информации для обнаружения источников недозволенной почты и позволяет избавиться от необходимости явной проверки параметра HELO.

Строки Received: предназначены, прежде всего, для прослеживания (человеком) почтовых маршрутов, прежде всего в целях поиска проблем (см. также Обсуждение в параграфе 5.3.7).

Когда получатель SMTP выполняет окончательную доставку (final delivery) сообщения, он должен передать адрес MAIL FROM из конверта SMTP, связанного с данным сообщением, для использования в тех случаях, когда позднее требуется передать отправителю информацию об ошибках (см. 5.3.3). Это аналогично требованию к шлюзам при передаче почты из Internet в иную почтовую среду (см. 5.3.7).

Обсуждение

Отметим, что окончательный отклик на команду DATA зависит только от успеха при передаче и сохранении сообщения. Проблемы с адресом получателя могут привести (1) к сообщению об ошибке при вызове команды RCPT или (2) передаче последующего сообщения об ошибке в адрес отправителя.

Реализация

Информация MAIL FROM: может передаваться как параметр или строка Return-Path: в начале сообщения.

5.2.9 Синтаксис команд: RFC 821, 4.1.2

Синтаксис команды MAIL FROM: в RFC 821 не рассматривает случай пустой строки пути — MAIL FROM: <> (см. стр. 15 в RFC 821). Пустые пути возврата должны поддерживаться.

5.2.10 Отклики SMTP: RFC 821, 4.2

Получателю SMTP следует передавать только отклики с кодами, перечисленными в параграфе 4.2.2 RFC 821 или в данном документе. По возможности получателю SMTP следует использовать в откликах тексты, приведенные в примерах RFC 821.

Отправитель SMTP должен определять свои действия только на основе кода отклика, но не его текста (за исключением откликов 251 и 551); любой текст (или отсутствие такового) должен восприниматься нормально. Пробелы после кода отклика рассматриваются как часть текста. Отправителю SMTP следует проверять только первую цифру в коде отклика (см. Приложение E в RFC 821).

Обсуждение

Могут возникнуть проблемы с интероперабельностью при использовании кодов отклика, не указанных явно в параграфе 4.3 RFC 821, но корректных в соответствии с теорией откликов, рассмотренной в Приложении E (RFC 821).

5.2.11 Прозрачность: RFC 821, 4.5.2

Разработчики программ должны быть уверены, что их почтовые системы всегда добавляют и удаляют точки для обеспечения прозрачности сообщений.

5.2.12 Использование WKS при обработке MX: RFC 974, стр. 5

RFC 974 [SMTP:3] рекомендует запрашивать у DNS записи WKS24, чтобы убедиться в поддержке SMTP каждым предложенным получателем. Однако опыт показывает, что поддержка WKS реализована не везде, поэтому WKS при обработке MX использовать не следует.

Далее приведены комментарии к RFC 822, организованные по разделам документа.

5.2.13 Спецификация сообщений: RFC 822, глава 4

Синтаксис строки Return-path не предусматривает возможности пустого пути возврата, которая используется для предотвращения петель при уведомлениях об ошибках (см. 5.3.3). Полный синтаксис имеет вид:

return = "Return-path" ":" route-addr "Return-path" ":" "<" ">"

Набор добавленных в последнее время полей заголовков включает поле Content-Type, определенное в RFC 1049 [SMTP:7]. Это поле позволяет программам для чтения почты идентифицировать тип структурированного тела сообщения и определить процесс для его корректного отображения [SMTP:7]. Пользовательский агент может поддерживать это поле.

5.2.14 Спецификации даты и времени: RFC 822, глава 5

Синтаксис дат был недавно изменен и теперь имеет вид:

date = 1*2DIGIT month 2*4DIGIT

Во всех почтовых сообщениях следует использовать 4 знака для обозначения года, чтобы упростить переход в следующее столетие.

Существует сильная тенденция в направлении использования цифровых обозначений часовых поясов и приложениям следует использовать цифровые обозначения вместо имен. Однако все реализации должны воспринимать оба типа обозначений. При использовании имен часовых поясов, эти имена должны в точности соответствовать RFC 822.

Военные часовые пояса в RFC 822 указаны некорректно — счет от UT ведется в обратном направлении. В результате военные часовые пояса в заголовках RFC 822 не несут полезной информации.

Наконец, отметим, что в определении «zone» при рассмотрении синтаксиса в Приложении D допущена опечатка; корректное определение приведено в главе 3 RFC 822.

5.2.15 Изменение синтаксиса: RFC 822, 6.1

Синтаксическое определение почтового ящика (mailbox) в RFC 822 недавно было заменено:

mailbox = addr-spec ; simple address
/ [phrase] route-addr ; name & addr-spec

Т. е., фраза, предшествующая адресу маршрута (route address) сейчас является необязательной. Это изменение делает корректным приведенный ниже фрагмент заголовка:

From: <craig@nnsc.nsf.net>

5.2.16 Локальный путь: RFC 822, 6.2

Базовая спецификация адреса почтового ящика имеет форму: local-part@domain. Вместо local-part (локальная часть адреса) иногда используют термин left-hand side (левая часть адреса).

Хост, который пересылает сообщение, но не является его получателем, имеет дело с правой частью адреса — доменом. При пересылке сообщений недопустимо менять что-либо в локальной части адреса.

Когда почта передается через шлюз из почтовой среды Internet в инородную почтовую среду (см. 5.3.7), маршрутная информация для такой среды может быть вложена в локальную часть адреса. В этом случае шлюз будет интерпретировать локальную часть адреса в соответствии с требованиями чужой среды.

Обсуждение

Хотя задание маршрута отправителем не следует использовать для почты Internet (см. 5.2.6), существуют почтовые среды, в которых механизмы работы шлюзов основаны на таких маршрутах. Обычно маршруты для таких сред встраивают в локальную часть адреса при передаче почты через Internet. Когда почта приходит на нужный почтовый шлюз Internet, этот шлюз интерпретирует локальную часть адреса и строит адрес или маршрут для инородной почтовой среды.

Например, хост Internet может отправить почту по адресу a!b!c!user@gateway-domain. Сложная локальная часть a!b!c!user будет прозрачно передаваться через Internet, но указанный шлюз разберет эту часть и преобразует ее в корректный адрес другой почтовой среды.

Вложенные маршруты source route иногда помещаются в локальную часть адреса с использованием знака «%» в качестве правого оператора маршрутизации. Например, в адресе:

user%domain%relay3%relay2@relay1

знак % показывает, что почта маршрутизируется из relay1 через relay2 и relay3 для передачи пользователю user в домене domain. Такую нотацию часто называют %-hack. Предполагается, что % имеет меньший приоритет, нежели другие операторы маршрутизации (например, «!»), спрятанные в локальной части адреса. Например, a!b%c будет интерпретироваться как (a!b)%c.

Только хосту-получателю (в нашем случае, relay1) дозволено анализировать локальную часть user%domain%relay3%relay2.

5.2.17 Доменные имена: RFC 822, 6.2.3

Почтовая программа (mailer) должна воспринимать и разбирать доменные литералы Internet, контекст которых (dtext в RFC 822) содержит адрес хоста в десятичном формате с разделением точками. Это соответствует требованиям параграфа 2.1 для случая электронной почты.

Программа SMTP должна принимать и распознавать доменные литералы для любого из своих адресов IP.

5.2.18 Общие ошибки при форматировании адресов: RFC 822, 6.1

Ошибки при форматировании и анализе адресов формата 822 к сожалению встречаются постоянно. В этом параграфе рассматриваются лишь наиболее распространенные ошибки. Пользовательский агент должен воспринимать все корректные форматы адресов RFC 822; недопустимо генерирование адресов с некорректным синтаксисом.

  • Общей ошибкой является сохранение точки с запятой (;) после идентификатора группы.
  • Некоторые системы допускают ошибки при генерации полных имен в создаваемых сообщениях. Справа от знака @ в адресе заголовка должно размещаться полное доменное имя (FQDN25).

Например, некоторые системы некорректно указывают доменное им в поле From:. В таких случаях возникают проблемы при попытке использования команды reply на приемной стороне.

Обсуждение

Хотя RFC 822 допускает локальное (внутри домена) использование сокращенных доменных имен, применение RFC 822 для почты Internet не позволяет использовать такие сокращения. Для хостов Internet недопустимо передавать сообщения SMTP, заголовок которых содержит сокращенное доменное имя в поле адреса. Такие сокращения допустимы только для заголовков сообщений, которые не будут передаваться через Internet, как сказано в параграфе 5.2.6.

  • Многие системы не умеют корректно разбирать заголовки с указанным маршрутом из нескольких частей:
    @relay1,@relay2,@relay3:user@domain.
  • Некоторые системы ошибочно добавляют точку в конце полного доменного имени в адресах и идентификаторах сообщений. Это является нарушением синтаксиса RFC 822.

5.2.19 Явное задание маршрута: RFC 822, 6.2.7

Программам хостов Internet не следует создавать заголовки RFC 822, содержащие адреса с явным маршрутом (explicit source route), но они должны воспринимать такие заголовки в целях совместимости.

Обсуждение

RFC 822 говорит: «The use of explicit source routing is discouraged» (рекомендуется избегать использования явно заданных маршрутов в адресах). На многих хостах поддержка маршрутов RFC 822 реализована некорректно, поэтому синтаксис на практике не обеспечивает однозначной трактовки. Многие пользователи считают этот синтаксис опасным. Явное задание маршрута в конверте не требуется для доставки (см. 5.2.6). В силу всего сказанного явное задание маршрутов с использованием синтаксиса RFC 822 не применяется в заголовках электронной почты Internet.

Как было сказано в параграфе 5.2.16, необходимо обеспечить возможность встраивания явных маршрутов в локальную часть адреса (например, за счет использования %-hack), чтобы позволить шлюзам передавать почту в инородные среды, требующие явного задания маршрута. Внимательный читатель заметит, что для пользовательских агентов не существует способа обнаружить и предотвратить использование таких неявных маршрутов при передаче почты в среде Internet. Мы можем только рекомендовать не применять задание маршрутов для почты Internet — это не нужно и нежелательно.

5.3 Частные вопросы

5.3.1 Стратегия очередей SMTP

Общая структура реализации SMTP на хосте включает пользовательские почтовые ящики, одну или несколько областей для организации очередей транзитных сообщений, а также один или несколько процессов-демонов для приема и передачи почты. Точная структура будет зависеть от потребностей пользователей, а также числа и размера поддерживаемых хостом списков рассылок. Здесь рассмотрены вопросы оптимизации, позволяющие повысить эффективность работы почтовых систем (в частности, систем с большим трафиком).

Любая стратегия работы с очередями должна включать:

  • время ожидания (тайм-аут) для всех операций (см. 5.3.2);
  • невозможность передачи сообщений об ошибке в ответ на сообщения об ошибке.
5.3.1.1 Стратеги передачи

Общая модель передающей стороны SMTP включает один или несколько процессов, периодически пытающихся передать исходящую почту. В типовой системе программы, готовящие почтовые сообщения, используют некий метод запроса немедленных действий для вновь созданного сообщений, однако почта не может быть отправлена незамедлительно, поэтому новые сообщения должны помещаться в очередь, к которой периодически обращается программа рассылки почты. Элемент почтовой очереди будет включать не только почтовое сообщение, но и связанный с ним конверт.

Отправитель должен задерживать попытки отправить почту по тому или иному адресу после связанной с этим адресом неудачи. В общем случае следует использовать интервал повтора не менее 30 минут, однако более изощренные и гибкие стратегии с определением причин неудачи являются более предпочтительными.

Попытки продолжаются, пока сообщение не будет передано или отправитель не откажется от дальнейших попыток (обычно отказ происходит через 4-5 дней). Параметры повторов передачи должны быть настраиваемыми.

Отправителю следует сохранять список хостов, с которыми не удается связаться и соответствующее время ожидания вместо простых попыток повтора передачи.

Обсуждение

Опыт показывает, что большинство отказов носит временный характер (например, перезагрузка хоста-получателя), поэтому рекомендуется делать две попытки передачи в течение первого часа пребывания сообщения в очереди и потом повторять попытки каждые 2 -3 часа.

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

Отправитель SMTP может иметь большие очереди сообщений для каждого из недоступных хостов и при попытках передать все такие сообщения в каждом цикле повтора будет возникать излишняя загрузка, которая может привести к блокировке почтового демона на продолжительный период. Отметим, что SMTP в общем случае может определить отказ только по истечении времени ожидания (минута или больше); минутный тайм-аут для соединения будет приводить к очень большим задержкам при повторении попыток для десятков и даже сотен сообщений из очереди.

Когда одно сообщение доставляется нескольким пользователям на одном хосте, следует передавать только одну копию. Т. е., отправителю SMTP рекомендуется использовать последовательность команд: RCPT, RCPT,… RCPT, DATA вместо последовательности: RCPT, DATA, RCPT, DATA,… RCPT, DATA. Реализация этого эффективного варианта настоятельно рекомендуется.

Подобно этому, отправитель SMTP может поддерживать множество одновременных исходящих почтовых транзакций для обеспечения быстрой доставки. Однако следует задавать некоторый предел для предотвращения излишнего расхода ресурсов на передачу почты.

Использование различных адресов на многодомных хостах рассматривается ниже.

5.3.1.2 Стратеги приема

На приемной стороне SMTP следует сохранять постоянное прослушивание порта SMTP. Это требуется для поддержки множества входящих TCP-соединений для SMTP. Можно ввести некоторые ограничения.

Реализация

Когда принимающая сторона SMTP получает почту от того или иного хоста, она может уведомить отправителя SMTP о возможности повтора для любой почты на данный хост, хранящейся в очереди.

5.3.2 Тайм-ауты SMTP

Существует два подхода при выборе времени ожидания для отправителей SMTP — (a) раздельно ограничивать время для каждой команды SMTP или (b) ограничивать время диалога SMTP в целом для каждого почтового сообщения. Для отправителей SMTP следует использовать вариант (a) — покомандные тайм-ауты. Следует также обеспечивать простой способ изменения времени ожидания, предпочтительно без перекомпиляции кода SMTP.

Обсуждение

Время ожидания является важным параметром реализации SMTP. Если тайм-аут слишком велик (или не задан вообще) отказы в соединениях Internet или ошибки в программах на приемной стороне SMTP могут привести процессы SMTP в состояние бесконечного ожидания. Если время ожидания слишком мало, это приведет к излишнему расходу ресурсов на попытки повторной передачи сообщений.

При использовании варианта (b) тайм-аут должен быть достаточно большим (например, час), чтобы можно было работать с очень большими списками рассылок. Может также потребоваться увеличение тайм-аута пропорционально размеру сообщения при работе с сообщениями большого размера. Использование большого тайм-аута с фиксированным значением может привести к двум проблемам — состояние отказа может сохраняться очень долго, а очень большие сообщения будут приводить к фиктивным тайм-аутам просто потому, что не хватило времени на передачу (это ведет к очень серьезным издержкам!).

При использовании рекомендуемого варианта (a) таймер устанавливается для каждой команды SMTP и каждого буфера передачи данных. Последнее означает, что общее время ожидания растет пропорционально размеру сообщения.

На основе опыта эксплуатации сильно загруженных почтовых хостов выработаны приведенные ниже правила, которые следует использовать при выборе времени ожидания:

  • Изначальное сообщение 220: 5 минутПроцесс-отправитель SMTP должен различать отказы соединений TCP от задержки при получении изначального отклика 220. Многие получатели SMTP будут воспринимать соединения TCP, но задерживать отклик 220 до тех пор, пока в системе не появится возможность обработки новой почты.
  • Команда MAIL: 5 минут
  • Команда RCPT: 5 минутБолее продолжительный тайм-аут требуется при обработке списков рассылки и псевдонимов, если ее невозможно отложить, пока не будет воспринято сообщение.
  • Инициирование команды DATA: 2 минутыЭто время ожидания отклика 354 Start Input на команду DATA.
  • Блок данных: 3 минутыЭто время, в течение которого вызов TCP SEND передает блок данных.
  • Прерывание команды DATA: 10 минутВремя ожидания отклика 250 OK. Когда получатель переходит на этап завершения приема данных, он обычно выполняет операции по доставке сообщения в пользовательский почтовый ящик. Фиктивные тайм-ауты на этом этапе ведут к значительным издержкам, поскольку сообщение уже было передано целиком.

Для получателей SMTP следует устанавливать тайм-аут не менее 5 минут для ожидания следующей команды отправителя.

5.3.3 Надежное получение почты

Когда получатель SMTP принимает часть почты (передавая сообщение 250 OK в ответ на команду DATA), он берет на себя ответственность за доставку или трансляцию этого сообщения. Эта ответственность должна восприниматься серьезно, т. е., недопустимо терять сообщения по незначительным причинам (например, в результате последующего краха хоста или предсказуемой нехватки ресурсов).

Если после восприятия сообщения возникают проблемы с его доставкой, получатель SMTP должен сформулировать и передать уведомление об этом. Такие уведомления должны передаваться с использованием пустого («<>») пути возврата в конверте (см. параграф 3.6 в RFC 821). В качестве получателя такого уведомления следует указывать адрес из пути возврата в конверте или строки Return-Path:. Если этот адрес пуст («<>»), для получателя SMTP недопустима передача уведомления о возникших проблемах. Если адрес содержит заданный явно маршрут, следует разобрать его до конечной точки.

Обсуждение

Предположим, что уведомление об ошибке должно быть передано для сообщения, принятого с «MAIL FROM:<@a,@b:user@d>». Уведомление в этом случае адресуется на: «RCPT TO:<user@d>».

Некоторые отказы при доставке после восприятия сообщения являются неизбежными. Например, причиной такого отказа может послужить невозможность проверки всех адресов доставки в команде RCPT в результате некритичной ошибки в домене или при отправке сообщения в адрес списка рассылок (см. обсуждение RCPT).

Во избежание дублирования сообщений в результате тайм-аутов получатель SMTP должен искать способ минимизации времени, требуемого для отклика на финальную точку, завершающую передачу сообщения. Обсуждение этой проблемы приведено в RFC 1047 [SMTP:4].

5.3.4 Надежная доставка почты

Для передачи сообщения отправитель SMTP определяет IP-адрес хоста-получателя по адресу получателя в конверте (преобразуется в адрес IP часть адреса получателя справа от знака @). При таком отображении или преобразовании могут возникать некритичные ошибки (soft error), в результате которых отправитель SMTP будет перестраивать почтовую очередь для последующей доставки сообщений, связанных с неудачной попыткой (см. 5.3.1.1).

При успешном преобразовании может быть возвращен список адресов доставки вместо единственного адреса (причиной этого может служить (a) наличие множества записей MX, (b) многодомный характер хоста или то и другое вместе). Для обеспечения надежной доставки почты отправитель SMTP должен предоставлять возможность попыток (и повторов) передачи по каждому из полученных адресов в соответствии с их порядком в списке, пока какая-либо из попыток не завершится успешно. Однако могут существовать конфигурационные ограничения на число альтернативных адресов, по которым могут осуществляться попытки доставки. В таких случаях хостам следует предпринять попытки хотя бы для двух адресов.

Для ранжирования адресов в списке можно использовать следующую информацию:

  1. Множество записей MX — значение записи можно использовать в качестве ключа сортировки. При существовании множества получателей с одинаковым значением и отсутствии других критериев (например, предпочтительный адрес) установки очередности отправителю SMTP следует использовать случайный выбор для распределения нагрузки между почтовыми серверами, обслуживающими указанную организацию (отметим, что в работе [DNS:3] предложен усовершенствованный вариант этой процедуры).
  2. Многодомный хост — хост-получатель (возможно определенный по записи MX с высшим приоритетом) может быть многодомным и в этом случае программа преобразования доменных имен будет возвращать список адресов IP. Упорядочивание адресов в списке (по уровню приоритета) является прерогативой программы-переобразователя адресов (см. параграф 6.1.3.4) и отправитель SMTP должен пытаться применять адреса в предложенном порядке.

Обсуждение

Хотя возможность работы с множеством альтернативных адресов является требованием, в некоторых обстоятельствах использование альтернативных адресов может быть ограничено или запрещено. Вопрос о возможности использования различных адресов многодомного хоста остается спорным. Главным аргументом в пользу работы с множеством адресов является повышение вероятности быстрой доставки и бесспорное повышение вероятности какой-либо доставки. Аргументом против такого использования является повышение расхода ресурсов26.

5.3.5 Поддержка доменных имен

Реализации SMTP должны использовать механизм, определенный в параграфе 6.1 для преобразования доменных имен в IP-адреса и обратно. Это означает, что хост Internet SMTP должен включать поддержку Internet DNS.

В частности, отправитель SMTP должен поддерживать схему записей MX [SMTP:3]. Дополнительную информацию о преобразованиях доменных имен для SMTP можно найти в параграфе 7.4 работы [DNS:2].

5.3.6 Списки рассылок и псевдонимы

Использующим SMTP хостам рекомендуется поддерживать обе формы (списки — list и псевдонимы — alias) расширения адресов для организации групповой доставки. Когда сообщение доставляется или пересылается по каждому из адресов списка, адрес возврата в конверте (MAIL FROM:) должен заменяться на адрес администратора списка, но заголовок письма (в частности, поле From:) должен сохраняться неизменным.

Обсуждение

Важным вопросом для почтовой системы является доставка одного сообщения по множеству адресов, выполняемая путем преобразования или расширения (expanding) псевдо-адреса в список адресов реальных получателей. Когда сообщение передается по такому псевдоадресу (иногда такой почтовый ящик называют exploder — детонатор), копии письма отправляются по каждому из адресов, полученных путем преобразования. Такие псевдо-адреса делятся на псевдонимы (alias) и списки (list):

  1. Alias — псевдоним

Для расширения псевдонима принимающая программа просто заменяет псевдо-адрес в конверте на каждый включенный в псевдоним реальный адрес; остальная часть конверта и тело сообщения при этом не изменяются. Сообщение после этого доставляется или пересылается по каждому из адресов.

  1. List — список

Список адресов использует перераспределение (redistribution), а не пересылку (forwarding). Для расширения списка принимающая программа заменяет псевдоадрес в конверте реальными адресами из списка. Адрес возврата в конверте изменяется, поэтому все сообщения об ошибках доставляются администратору списка, а не отправителю сообщения, который зачастую не имеет возможности контроля списка адресов.

5.3.7 Почтовый шлюз

Передача почты между различными почтовыми средами, использующими разные форматы и протоколы, является сложной задачей, для которой еще нет должного уровня стандартизации (см. примеры в [SMTP:5a], [SMTP:5b]). Однако здесь приведены некоторые общие требования для почтовых шлюзов, обеспечивающих пересылку между Internet и другими почтовыми средами.

  1. Поля заголовков могут переписываться при необходимости в процессе обработки сообщений почтовыми шлюзами.

Обсуждение

Основным вопросом является интерпретация локальной части адреса, рассмотренная в параграфе 5.2.16.

Инородные почтовые системы при передаче сообщений в Internet обычно используют подмножество заголовков RFC 822, но некоторые из почтовых систем не имеют эквивалента конвертов SMTP. Следовательно, когда сообщение покидает среду Internet, может потребоваться включение информации из конверта SMTP в заголовок сообщения. Возможным решением является создание новых полей заголовка для передачи информации из конверта (например, X-SMTP-MAIL: и X-SMTP-RCPT:); однако такое решение может потребовать изменений в почтовых программах чужой среды.

  1. При пересылке сообщений в среду Internet или из нее, шлюз должен подготовить свою строку Received:, но недопустимо менять содержимое других строк Received: в полученном заголовке.

Обсуждение

Это требование является частью общих правил для строки Received:, рассмотренных в параграфе 5.2.8 и приведено здесь только для напоминания.

Поля Received: сообщений из другой среды могут не соответствовать в точности RFC 822. Однако, наиболее важным применением строк Received: является обнаружение почтовых отказов и такая отладка может быть испорчена шлюзами, которые пытаются править строки Received:.

Для шлюзов настоятельно рекомендуется указывать среду и протокол в предложениях «via» строки Received:, доставляемой шлюзом.

  1. Со стороны Internet шлюзу следует принимать все допустимые форматы адресов в командах SMTP и заголовках RFC 822, а также все допустимые сообщения RFC 822. Хотя шлюз должен воспринимать явно указанные маршруты RFC 822 (формат «@…:») в заголовке RFC 822 или в конверте, шлюз не обязан действовать на маршруте от отправителя (см. 5.2.6 и 5.2.19.

Обсуждение

Часто возникает искушение ограничить диапазон адресов, воспринимаемых почтовым шлюзом для упрощения трансляции адресов в форматы другой среды. Такая практика основывается на предположении, что пользователи почты имеют контроль над всеми адресами, по которым их почтовые программы шлют сообщения почтовому шлюзу. На практике, однако, пользователи имеют ограниченный контроль над адресами, которые они в конечном итоге используют, поскольку почтовые программы могут свободно менять адреса в любой допустимый формат RFC 822.

  1. Шлюз должен гарантировать, что все поля заголовков сообщений, пересылаемых в Internet, соответствуют почтовым требованиям Internet. На практике все адреса в полях From:, To:, Cc: и т. п. должны быть преобразованы (при необходимости) в соответствии с требованиями синтаксиса RFC 822.
  2. Алгоритму трансляции, используемому для преобразования почты Internet в другие почтовые системы, следует пытаться обеспечить гарантии доставки сообщений об ошибках из чужой среды по пути возврата из конверта SMTP, а не отправителю, указанному в поле From: сообщения RFC 822.

Обсуждение

Списки рассылок Internet обычно помещают адрес владельца списка в конверт, но указывают реального отправителя в поле From:. Этот подход представляется разумным — ответ на письмо приходит его реальному отправителю, а сообщения об ошибках — администратору списка, который может исправить связанные со списком ошибки.

  1. Подобно сказанному, при пересылке почты из чужой среды в Internet шлюзу следует установить в конверте путь возврата в соответствии с требованиями возврата сообщений об ошибках для инородной среды.

5.3.8 Максимальный размер сообщения

Почтовая программа должна обеспечивать возможность передачи и приема сообщений, размером не менее 64 кбайт (включая заголовок); желательно обеспечивать возможность работы с более крупными сообщениями.

Обсуждение

Хотя SMTP не задает максимальный размер сообщения, во многих системах этот размер ограничен.

Фактически в Internet обеспечивается гарантия передачи сообщений размером 64 кбайт. Однако электронная почта используется для решения различных задач и может потребоваться передача больших сообщений. Например, электронную почту зачастую используют взамен FTP для передачи ASCII-файлов, которые могут содержать целый документ. В результате сообщения размером 1 Мбайт и более не являются чем-то, из ряда вон выходящим.

5.4 Требования к SMTP

 

Функция Параграф Требования
Получатель SMTP:
Реализация VRFY 5.2.3 Обязательно
Реализация EXPN 5.2.3 Следует
Возможность настройки EXPN, VRFY 5.2.3 Возможно
Реализация SEND, SOML, SAML 5.2.4 Возможно
Проверка параметра HELO 5.2.5 Возможно
Отбрасывание сообщений с некорректным HELO 5.2.5 Недопустимо
Допустимость явного синтаксиса source-route в среде 5.2.6 Обязательно
Поддержка postmaster 5.2.7 Обязательно
Обработка RCPT при получении (кроме списков) 5.2.7 Возможно
Значительна задержка откликов RCPT 5.2.7 Недопустимо
Добавление строки Received: 5.2.8 Обязательно
Строка Received: включает доменные литералы 5.2.8 Следует
Изменение предыдущей строки Received: 5.2.8 Недопустимо
Передача информации о пути возврата (Rerurn-Path) 5.2.8 Обязательно
Поддержка пустых обратных путей 5.2.9 Обязательно
Передача только официальных кодов отклика 5.2.10 Следует
Передача текста из RFC 822 5.2.10 Следует
Удаление *.* для прозрачности 5.2.11 Обязательно
Восприятие и распознавание своих доменных имен 5.2.17 Обязательно
Генерация сообщений об ошибках для сообщений об ошибках 5.3.1 Недопустимо
Сохранение состояния прослушивания для порта SMTP 5.3.1.2 Следует
Ограничение числа одновременно принимаемых сообщений 5.3.1.2 Возможно
Ожидание не менее 5 мин. перед следующей командой отправителя 5.3.2 Следует
Предотвращение сбоев при доставке после сообщений “250 OK” 5.3.3 Недопустимо
Передача уведомлений об ошибках после получения 5.3.3 Обязательно
Передача с использованием пустого пути возврата 5.3.3 Обязательно
Передача по пути возврата конверта 5.3.3 Следует
Передача по пустому адресу 5.3.3 Недопустимо
Вырезание заданного явно source-route 5.3.3 Следует
Минимизация задержки восприятия (RFC 1047) 5.3.3 Обязательно
Отправитель SMTP:
Канонизированные доменные имена в MAIL, RCPT 5.2.2 Обязательно
Реализация SEND, SOML, SAML 5.2.4 Возможно
Передача корректного основного имени в HELO 5.2.5 Обязательно
Передача явного маршрута в RCPT TO: 5.2.6 Не следует
Использование для определения действия только кода отклика 5.2.10 Обязательно
Использование только старшей цифры кода отклика 5.2.10 Следует
Добавление *.* для прозрачности 5.2.11 Обязательно
Повторение передачи после некритичных ошибок 5.3.1.1 Обязательно
Задержка перед повтором 5.3.1.1 Обязательно
Настраиваемые параметры повторной передачи 5.3.1.1 Обязательно
Одна попытка для каждого хоста-получателя в очереди доставки 5.3.1.1 Следует
Множество RCPT для одной команды DATA 5.3.1.1 Следует
Поддержка одновременных транзакций 5.3.1.1 Возможно
Ограничение числа 5.3.1.1 Следует
Тайм-аут для всех операций 5.3.1 Обязательно
Тайм-аут для каждой команды независимо 5.3.2 Следует
Проста настройка времени ожидания 5.3.2 Следует
Рекомендуемые значения 5.3.2 Следует
Пробовать альтернативные адреса по порядку 5.3.4 Обязательно
Конфигурационные ограничения для числа адресов 5.3.4 Возможно
Пробовать по крайней мере два адреса 5.3.4 Следует
Распределение нагрузки при равных значениях MX 5.3.4 Следует
Использование DNS 5.3.5 Обязательно
Поддержка записей MX 5.3.5 Обязательно
Использование WKS при обработке MX 5.2.12 Не следует
Пересылка почты:
Изменение существующих полей заголовка 5.2.6 Не следует
Реализация функций трансляции (RFC 821, параграф 3.6) 5.2.6 Возможно
Если нет, доставка в домен RHS 5.2.6 Следует
Интерпретация локальной части адреса (local-part) 5.2.12 Недопустимо
Списки рассылок и псевдонимы:
Поддержка тех и других 5.3.6 Следует
Отчеты для локального администратора об ошибках в списке рассылки 5.3.6 Обязательно
Почтовые шлюзы:
Встраивание чужого почтового маршрута в локальную часть 5.2.16 Возможно
Переписывание при необходимости полей заголовка 5.3.7 Возможно
Вставка строки Received: в начало 5.3.7 Обязательно
Изменение существующих строк Received: 5.3.7 Недопустимо
Полное восприятие RFC 822 со стороны Internet 5.3.7 Следует
Работа на явном маршруте RFC 822 5.3.7 Возможно
Передача в сторону Internet только корректных RFC 822 5.3.7 Обязательно
Доставка сообщений об ошибках по адресу в конверте 5.3.7 Следует
Установка пути возврата в конверте из пути возврата ошибки 5.3.7 Следует
Пользовательский агент — RFC 822:
Пользователь может вводить адрес <route> 5.2.6 Не следует
Поддержка пол Content Type (RFC 1049) 5.2.13 Возможно
Использование 4-значного года 5.2.14 Следует
Генерация временных зон в форме чисел 5.2.14 Следует
Восприятие всех временных зон 5.2.14 Обязательно
Использование нечисловых временных зон RFC 822 5.2.14 Обязательно
Опускание фразы перед route-addr 5.2.15 Возможно
Восприятие и разборка доменных имен dot.dec. 5.2.17 Обязательно
Восприятие всех форматов адреса RFC 822 5.2.18 Обязательно
Генерация адресов в некорректных форматах (RFC 822) 5.2.18 Недопустимо
Полные доменные имена в заголовке 5.2.18 Обязательно
Создание явного маршрута в заголовке 5.2.19 Не следует
Восприятие явного маршрута в заголовке 5.2.19 Обязательно
Прием/передача сообщений не менее 64 кбайт. 5.3.8 Обязательно

6. Служебные протоколы

6.1 Трансляция доменных имен

6.1.1 Введение

Каждый хост должен реализовать программу преобразования (resolver) для DNS и механизм использования этой программы для преобразования имен хостов в адреса IP и обратно [DNS:1, DNS:2].

В дополнение к DNS хост может поддерживать механизм преобразования имен на основе поиска в локальной таблице имен хостов Internet (см. параграф 6.1.3.8).

Обсуждение

Трансляция имен хостов Internet поначалу осуществлялась путем поиска в локальной копии списка всех хостов. Эти списки со временем стали слишком велики для обновления и распространения в прежней манере, поэтому была разработана служба доменных имен — DNS.

DNS использует распределенную базу данных, которая служит прежде всего для преобразования имен хостов в их адреса и наоборот. Требуется реализация программ DNS. Система доменных имен DNS состоит из двух различных частей — серверов имен и программ преобразования, которые иногда называют резольверами (resolver), хотя при реализации эти две части могут объединять в целях повышения эффективности [DNS:2].

Серверы доменных имен сохраняют полномочные (authoritative) данные для отдельных частей распределенной базы данных и отвечают на соответствующие запросы. Программы преобразования имен запрашивают у серверов данные по запросам пользовательских процессов. На каждом хосте, следовательно, должна быть программа преобразования (DNS resolver); а на некоторых хостах нужен также сервер имен. Поскольку ни один из серверов имен не содержит всей информации, в общем случае для преобразования имени в адрес (или наоборот) может потребоваться получение информации от нескольких серверов имен.

6.1.2 Общие вопросы

Разработчики должны внимательно ознакомиться с документами [DNS:1] и [DNS:2], содержащими описания теории, протоколов и реализации системы доменных имен с учетом реального опыта.

6.1.2.1 Записи RR с TTL=0: RFC 1035, 3.2.1

Серверы имен и преобразователи DNS должны корректно обрабатывать RR с нулевым значением TTL, возвращая клиенту запись RR, но не кэшируя ее.

Обсуждение

Нулевое значение TTL говорит о том, что запись RR можно использовать только для выполняемой транзакции и не следует кэшировать; это очень полезно для часто меняющихся данных.

6.1.2.2 Значения QCLASS: RFC 1035, 3.2.5

Запросы с QCLASS=* не следует использовать, если запрашивающая сторона не просматривает данные из нескольких классов. В частности, если запрашивающая сторона интересуется только типами данных Internet, необходимо использовать QCLASS=IN.

6.1.2.3 Неиспользуемые поля: RFC 1035, 4.1.1

Неиспользуемые поля запросов и откликов должны иметь нулевые значения.

6.1.2.4 Сжатие: RFC 1035, 4.1.4

Серверы имен должны использовать в откликах сжатие данных.

Обсуждение

Сжатие позволяет избавиться от лишних дейтаграмм UDP, как описано в параграфе 6.1.3.2.

6.1.2.5 Запрет на использование конфигурационных сведений: RFC 1035, 6.1.2

Рекурсивные серверы имен и полнофункциональные преобразователи используют некую конфигурационную информацию, содержащую сведения о расположении корневых и локальных серверов имен. Для реализаций программ недопустимо включение такой информации в отклики.

Обсуждение

Многие разработчики считают удобным сохранять такие данные, как будто они кэшируются, но иногда пренебрегают обеспечением запрета на включение этих «кэшируемых» данных в отклики. Некорректность такого рода информации может привести к серьезным проблемам в Internet.

6.1.3 Частные вопросы

6.1.3.1 Реализация программы преобразования

Для программ преобразования имен (name resolver) следует обеспечивать поддержку одновременных запросов, если хост поддерживает одновременные процессы.

При разработке программ преобразования могут выбраны различные модели — полнофункциональный преобразователь (full-service resolver) или оконечный (stub) преобразователь.

  1. Полнофункциональная программа

Полнофункциональный преобразователь обеспечивает полный сервис преобразования имен и может работать при коммуникационных сбоях, отказах отдельных серверов имен, а также способен определить корректный сервер для данного имени и т. д. К таким преобразователям предъявляются следующие требования:

  • должны поддерживаться функции локального кэширования, позволяющие избавиться от лишних запросов к удаленным серверам при повторении идентичных запросов; для записей в локальном кэше должно задаваться время жизни;
  • следует обеспечивать возможность настройки конфигурационных параметров при старте программы с помощью сведений, указывающих на разные корневые серверы и различные серверы имен для локального домена; это обеспечивает доступ преобразователя ко всему пространству имен в нормальном режиме и возможность преобразования локальных имен при отсутствии связи с Internet.
  1. Оконечная программа — боковик (Stub Resolver)

Работа оконечных преобразователей основана на обращениях к рекурсивным серверам имен в подключенной сети или соседней сети. Такая схема позволяет хосту передать нереализованные функции преобразования адресов серверу имен на другом хосте. Зачастую такое решение используется для небольших хостов (например, ПК) и рекомендуется также для случаев, когда хост является одной из нескольких рабочих станций локальной сети, поскольку такое решение позволяет всем станциям ЛВС использовать кэш рекурсивного сервера имен и, следовательно, снижает число запросов, экспортируемых локальной сетью.

В минимальном варианте stub-программа должна быть способна перенаправить свои запросы к резервным рекурсивным серверам имен. Отметим, что рекурсивные серверы имен разрешены для ограничения числа отправителей запросов, которые будут обслуживаться, поэтому администратор хоста должен убедиться в наличии сервиса. Оконечные преобразователи могут использовать кэширование и в таком случае должны задать время жизни информации в кэше.

6.1.3.2 Транспортные протоколы

Программы преобразования и рекурсивные серверы DNS должны поддерживать протокол UDP (следует также поддерживать TCP) для передачи запросов (не для переноса зон). Отметим также, что при передаче запроса, не относящегося к передаче зоны, сначала должен использоваться протокол UDP. Если раздел Answer (ответ) в отклике отсечен и запрашивающая программа поддерживает TCP, следует повторить запрос с использованием TCP.

Серверы DNS должны обслуживать запросы UDP; следует обслуживать также TCP-запросы. Сервер имен может ограничить ресурсы для обслуживания запросов TCP, но не следует отказываться от обработки таких запросов лишь потому, что они могли быть обслужены по протоколу UDP.

Недопустимо сохранять (кэшировать) усеченные отклики и использовать их впоследствии в качестве нормальных откликов.

Обсуждение

Протокол UDP является предпочтительным для передачи запросов, поскольку UDP порождает меньше пакетов и не так сильно загружает канал связи. Использование UDP играет очень важную роль для загруженных серверов (особенно для корневых). UDP также обеспечивает дополнительную устойчивость, поскольку преобразователь может сделать UDP-запросы к нескольким серверам по цене одного запроса TCP.

Ситуации с усекновением откликов DNS весьма редки в современной среде Internet, но все-таки реальны. Предсказать такие ситуации невозможно, поскольку их возникновение зависит от данных. Эта зависимость включает число записей RR в ответе, размер каждой записи RR и реализацию алгоритма сжатия имен. Обычно считается, что отсечения списков NS и MX не должно происходить для ответов, содержащих не более 15 записей RR.

Возможность использования усеченных ответов зависит от приложения. Почтовым программам недопустимо использовать усеченные записи MX, поскольку это может привести к возникновению почтовых петель.

Практика показала возможность использования UDP в большинстве случаев. Серверы имен должны использовать компрессию данных в откликах. Преобразователи должны отличать ответы с усеченным дополнительным разделом (Additional), который содержит только добавочную информацию, от случаев усекновения раздела Answer (ответ) — в случае отсечения записей MX ответы просто нельзя использовать в почтовых программах. Администраторы должны ограничиваться разумным числом первичных имен в списках серверов имен, вариантов MX и т. п.

Однако очевидно, что новые типы записей DNS, которые появятся определены в будущем, могут содержать объем информации, превышающий 512-байтовый предел для UDP, и, следовательно, потребуют использования протокола TCP. Таким образом, программы службы доменных имен должны сегодня поддерживать протокол TCP как резерв для UDP, понимая, что в будущем использование TCP неизбежно.

Серверы имен и преобразователи на основе частного соглашения могут применять TCP для всего трафика между собой. Для передачи зон должен использоваться протокол TCP.

Сервер DNS должен иметь достаточно внутренних ресурсов для продолжения обработки запросов UDP во время ожидания отклика или при переносе зоны через открытое соединение TCP [DNS:2].

Сервер может поддерживать запросы UDP, для доставки которых используются групповые или широковещательные адреса IP. Однако для запросов с групповым адресом недопустимо устанавливать бит RD27 и запросы в групповых или широковещательных пакетах с установленным битом RD должны игнорироваться сервером имен. Хостам, передающим запросы DNS с использованием широковещательного или группового адреса следует передавать их таким способом только в редких случаях — поместив в кэш IP-адрес(а) из отклика, хост в дальнейшем может передавать нормальные запросы по этому адресу.

Обсуждение

Широковещательные и (особенно) групповые запросы могут обеспечивать способ поиска серверов имен в соседних сетях при отсутствии информации об адресах таких серверов. Однако частое использование таких запросов может привести к ненужной и чрезмерной загрузке как сети, так и серверов имен.

6.1.3.3 Эффективное использование ресурсов

Приведенные ниже требования к серверам имен и преобразователям очень важны для нормальной работы Internet в целом, особенно для ситуаций, когда серверы DNS постоянно вовлечены в работу автоматических серверов верхних уровней (например, почтовых).

  1. Преобразователь должен обеспечивать управление повторной передачей для того, чтобы не расходовать излишней полосы каналов связи; кроме того, должно ограничиваться количество ресурсов, потребляемых для отклика на один запрос (конкретные рекомендации можно найти на страницах 43-44 работы [DNS:2]).
  2. После того, как запрос был передан несколько раз без отклика, программа должна прекратить попытки и сообщить приложению о некритичной ошибке.
  3. Всем серверам DNS и преобразователям следует кэшировать временные неполадки с периодом ожидания в несколько минут.

Обсуждение

Это будет предотвращать избыточный трафик DNS от приложений, которые немедленно повторяют запрос при получении информации о некритичной ошибке в нарушение требований параграфа 2.2 настоящего документа.

  1. Всем серверам DNS и преобразователям следует кэшировать негативные отклики, которые говорят, что заданное имя не существует (в соответствии с требованиями [DNS:2]).
  2. При повторении серверами DNS и резольверами запросов UDP следует использовать экспоненциальный алгоритм изменения периода повторов, для которого следует задавать верхнюю и нижнюю границу.

Реализация

Следует использовать измеренные значения RTT28 и вариаций (если возможно) для расчета начального периода повтора запросов. Если такая информация недоступна, следует использовать по умолчанию период повтора не менее 5 секунд. Реализации могут ограничивать интервал повторной передачи, но эта граница должна превышать удвоенное значение максимального времени жизни сегмента в Internet с учетом задержки при обработке на сервере имен.

  1. Когда сервер или резольвер получает ответ Source Quench для переданного запроса, следует приложить усилия для снижения частоты запросов к этому серверу в ближайшем будущем; Сервер может игнорировать отклики Source Quench, получаемые в результате передачи дейтаграмм-откликов.

Реализация

Рекомендуется для снижения частоты запросов к серверу попытаться использовать другой сервер, если таковые имеются. Другим вариантом является увеличение периода повторов для запросов к серверу.

6.1.3.4 Многодомные хосты

Когда при преобразовании имени в адрес функция встречает многодомный хост, следует ранжировать или сортировать его адреса, используя информацию о номерах непосредственно подключенных сетей и любые другие сведения о производительности, а также предысторию.

Обсуждение

Различные адреса многодомного хоста обычно подразумевают различные пути Internet, из которых некоторые могут быть более предпочтительными с точки зрения производительности, надежности или административных ограничений. Общего алгоритма определения наилучшего пути не существует. Рекомендуется принимать такие решения на основе локальных конфигурационных параметров, установленных системным администратором.

Реализация

Предложенная ниже схема хорошо показала себя на практике:

  1. конфигурационные параметры хоста включают Network-Preference List — простой список сетей в порядке предпочтения. Этот список может быть пустым, если предпочтения отсутствуют.
  2. Когда имя хоста преобразуется в список адресов IP, эти адреса сортируются по номерам сетей в том же порядке, который задан в Network-Preference List. IP-адреса, отсутствующие в списке предпочтений, помещаются в конец сортированного списка.
6.1.3.5 Возможности расширения

Программы DNS должны поддерживать все общеизвестные, не зависящие от классов форматы [DNS:2]; следует при разработке программ минимизировать возможные издержки при введении новых общеизвестных типов и локальных экспериментах с нестандартными типами.

Обсуждение

Типы и классы данных, используемые DNS, постоянно изменяются — появляются новые типы, а старые удаляются или определяются заново. Введение новых типов должно зависеть только от правил компрессии доменных имен в сообщениях DNS и трансляции между печатным (master-файл) и внутренним форматом записей RR29.

Сжатие основано на знании формата данных внутри отдельной записи RR. Поэтому компрессия должна использоваться только для содержимого общеизвестных и не зависящих от класса записей RR, но недопустима для зависящих от класса RR или записей, не относящихся к общеизвестным. Имя владельца RR всегда подходит для сжатия.

Сервер имен может получить (путем переноса зоны) записи RR, которые сервер не умеет преобразовывать в печатный формат. Подобную информацию преобразователь может получить в результате запроса. Для корректной работы такие данные нужно предварительно сохранить, поскольку программы DNS не могут использовать текстовые форматы для внутреннего хранения.

DNS определяет синтаксис доменных имен лишь в самом общем виде — как строку меток из 8-битовых символов длиной до 63 символов каждая с общей длиной строки не более 255 октетов. Частные приложения DNS могут дополнительно ограничивать синтаксис, хотя развертывание DNS привело к появлению приложений, разрешающих имена более общих типов. В частности, параграф 2.1 данного документа несколько либерализует синтаксис имен хостов по сравнению с требованиями RFC 952 [DNS:4].

6.1.3.6 Состояние типов RR

Сервер имен должен быть способен загружать все типы RR (за исключением MD и MF) из конфигурационных файлов. Типы MD и MF являются устаревшими и недопустимы для использования (в частности, недопустимо загружать эти типы из конфигурационных файлов).

Обсуждение

RR типов MB, MG, MR, NULL, MINFO и RP являются экспериментальными и приложения, использующие DNS, не должны ожидать поддержки этих типов в любом домене. Многие из этих типов могут быть переопределены.

Типы TXT и WKS редко используются сайтами Internet, поэтому для большинства доменов не следует надеяться на существование этих записей.

6.1.3.7 Устойчивость

Программам DNS иной раз приходиться работать в средах, где корневые серверы или иные важные серверы недоступны в результате проблем с сетевыми соединениями или по иным причинам. В этой ситуации серверы имен и преобразователи DNS должны продолжать предоставление сервиса для доступной части пространства имен, выдавая информацию о временной недоступности остальной части сети.

Обсуждение

Хотя DNS используется преимущественно в сетях, соединенных с Internet, должна обеспечиваться возможность использования и в изолированных системах. Следовательно, работоспособность программ не должна зависеть от возможности доступа к корневым серверам при обслуживании запросов для локальных имен.

6.1.3.8 Локальный список хостов

Обсуждение

Хост может использовать локальный список хостов в качестве резервирования или в дополнение к DNS. При таком варианте возникает вопрос очередности использования; наиболее гибким является выбор предпочтений с помощью конфигурационных опций.

Обычно содержимое списка задается локально для каждого хоста. Однако общедоступные списки хостов Internet поддерживаются Сетевым информационным центром DDN (DDN NIC) в формате, заданном [DNS:4]. Эти таблицы можно загрузить с DDN NIC, используя протокол, описанный в работе [DNS:5]. Следует отметить, что эти таблицы содержат лишь малую часть хостов Internet. Хостам, использующим протокол [DNS:5] для получения списков DDN NIC, следует применять команду VERSION для проверки наличия обновлений в таблице и только после этого запрашивать всю таблицу с помощью команды ALL. Идентификатор VERSION следует трактовать как произвольную строку и проверять ее только на совпадение, не пытаясь найти порядковый номер версии.

Таблица хостов DDN NIC включает административную информацию (например, сети и шлюзы), которая не требуется для работы хостов и, следовательно, не включается в базу данных DNS. Однако в будущем значительная часть этой информации может быть включена в DNS. И наоборот, DNS обеспечивает важные службы (в частности, записи MX), которые недоступны в таблице хостов DDN NIC.

6.1.4 Пользовательский интерфейс DNS

6.1.4.1 Администрирование DNS

Этот документ посвящен вопросам архитектуры и реализации программ для хостов и не связан с администрированием и поддержкой. Однако вопросы администрирования весьма важны в DNS, поскольку ошибки в отдельных сегментах большой распределенной базы данных могут повлиять на работу множества сайтов. Вопросы администрирования подробно рассматриваются в [DNS:6] и [DNS:7].

6.1.4.2 Интерфейс DNS — пользователь

Хост должен обеспечивать интерфейс с DNS для всех прикладных программ на хосте. Этот интерфейс обычно направляет все запросы системному процессу для выполнения функций преобразования имен [DNS:1, 6.1:2].

По минимуму базовый интерфейс должен поддерживать запросы для всей информации заданного типа и класса, связанной с указанным именем, и должен возвращать всю запрошенную информацию или код возникшей ошибки. При отсутствии ошибок базовый интерфейс возвращает полностью запрошенную информацию, не меняя ее, поэтому при появлении новых типов и классов базовый интерфейс не потребуется обновлять.

Обсуждение

Индикация некритичных ошибок является существенной частью интерфейса, поскольку не всегда возможно воспринять информацию непосредственно от DNS (см. параграф 6.1.3.3).

Хост может обеспечивать иные интерфейсы DNS, основанные на отдельных функциях, преобразовании неупорядоченных данных о домене в удобную форму и т. п. В частности, хост должен обеспечивать интерфейс DNS для выполнения преобразований имен хостов в адреса и наоборот.

6.1.4.3 Возможности сокращений

Пользовательский интерфейс может обеспечивать поддержку сокращенного ввода широко распространенных имен. Хотя определение такого метода выходит за пределы спецификации DNS, здесь сформулированы некоторые правила, которые позволят обеспечить доступ ко всему пространству имен DNS и предотвратят излишнюю загрузку ресурсов Internet. При использовании сокращений:

  1. должно быть некое соглашение для обозначения полностью введенных имен (в этом случае обработка сокращений отключается). Общепринятым методом является точка в конце полного имени.
  2. Преобразование сокращенных имен должно выполняться только один раз и в том контексте, в котором имя было введено.

Обсуждение

Например, при использовании сокращений в почтовой программе, сокращенное им должно преобразовываться в полное и сохраняться в почтовой с пометкой полноты. В противном случае, сокращенное им может быть преобразовано еще раз при поиске в списке почтовой системы или при многократной канонизации.

Существуют два общепринятых метода сокращений:

  1. Псевдонимы интерфейсного уровня

Псевдонимы интерфейсного уровня реализуются в виде списка пар псевдоним — доменное имя. Эти списки могут создаваться в масштабе хоста или отдельно для каждого пользователя и для каждой функции может быть создан свой список (например, один список для трансляции имен в адреса, а другой — для почтовых доменов). Когда пользователь вводит имя, интерфейс пытается найти в списке подходящий псевдоним и при удачном поиске меняет сокращенное им на полное.

Отметим, что псевдонимы интерфейсного уровня полностью отличаются от механизма CNAME — интерфейсные псевдонимы имеют лишь локальную значимость, CNAME обеспечивает псевдонимы в масштабе Internet, реализуемые на уровне серверов DNS.

  1. Списки поиска

Список поиска концептуально реализуется, как упорядоченный список доменных имен. Когда пользователь вводит имя, доменные имена из списка поиска подставляются как суффикс для заданного пользователем имени одно за другим, пока не будет найдено доменное имя с желаемыми ассоциированными данными или не закончится список. Списки поиска часто содержат имена родительского домена для хоста или других доменов-предков. Зачастую списки поиска создаются для отдельных пользователей или процессов.

Следует обеспечивать администратору возможность запрета поиска по спискам — такой запрет в некоторых случаях может потребоваться для предотвращения злоупотреблений с DNS.

Существует опасность, что механизм поиска по списку будет приводить к излишним запросам для корневых серверов в процессе поиска полного имени для заданного пользователем сокращения. Механизм поиска по списку должен обеспечивать маркировку полной формы имен и следует также реализовать оба предложенных ниже способа предотвращения излишних запросов:

  1. реализовать в локальном преобразователе/сервере имен кэширование негативных откликов (см. 6.1.3.3);
  2. средство расширения имен по списку должно обращаться к нелокальным серверам только при наличии одной или двух точек в сгенерированном доменном имени.

Обсуждение

Реализация этого требования позволяет избежать ненужных задержек при проверке списка и снизить число запросов к корневым серверам и серверам верхних уровней. Например, если пользователь ввел имя «X» и список поиска содержит в качестве компоненты корневой сервер, при поиске обращение к корневому серверу будет предшествовать переходу к следующему элементу списка. В результате число запросов к корневому серверу будет неоправданно возрастать.

Кеширование негативных откликов имеет ограниченный эффект при первом использовании имени. Правило внутренних точек проще в реализации, но может блокировать поиск для некоторых имен верхних уровней.

6.1.5 Требования к DNS

Функция Параграф Требования
Общие вопросы:
Преобразование имени в адрес 6.1.1 Обязательно
Преобразование адреса в им 6.1.1 Обязательно
Поддержка преобразований с использованием таблицы хостов 6.1.1 Возможно
Корректна обработка RR c TTL=0 6.1.2.1 Обязательно
Необязательность использования QCLASS=* 6.1.2.2 Следует
Использование QCLASS=IN для Internet 6.1.2.2 Обязательно
Нулевые значения неиспользуемых полей 6.1.2.3 Обязательно
Использование сжатия в откликах 6.1.2.4 Обязательно
Включение конфигурационной информации в отклики 6.1.2.5 Недопустимо
Поддержка всех хорошо известных, независимых от класса типов 6.1.2.5 Обязательно
Легко расширяемый список типов 6.1.2.5 Следует
Загрузка всех типов RR (кроме MD и MF) 6.1.2.6 Обязательно
Загрузка типа MD или MF 6.1.2.6 Недопустимо
Работоспособность при недоступности корневого сервера и т. п. 6.1.2.7 Обязательно
Программа преобразования (resolver):
Поддержка множества одновременных запросов 6.1.3.1 Следует
Полнофункциональный резольвер: 6.1.3.1 Возможно
локальное кэширование 6.1.3.1 Обязательно
старение данных в локальном кэше 6.1.3.1 Обязательно
настройка конфигурации при старте 6.1.3.1 Следует
Оконечный преобразователь (stub): 6.1.3.1 Возможно
использование резервных серверов имен (рекурсия) 6.1.3.1 Обязательно
локальное кэширование 6.1.3.1 Возможно
старение данных в локальном кэше 6.1.3.1 Обязательно
Поддержка многодомных удаленных хостов:
сортировка адресов в порядке предпочтения 6.1.3.4 Следует
Транспортные протоколы:
Поддержка запросов UDP 6.1.3.2 Обязательно
Поддержка запросов TCP 6.1.3.2 Следует
Передача запросов сначала с помощью UDP 6.1.3.2 Обязательно
Использование TCP, если UDP-запросы отвергнуты 6.1.3.2 Следует
Сервер имен ограничивает ресурсы для запросов по TCP 6.1.3.2 Возможно
“Наказание” для неоправданных запросов TCP 6.1.3.2 Не следует
Использование “усеченных” данных, как нормальных 6.1.3.2 Недопустимо
Частное соглашение на использование только TCP 6.1.3.2 Возможно
Использование TCP для переноса зон 6.1.3.2 Обязательно
Использование TCP не блокирует запросов UDP 6.1.3.2 Обязательно
Поддержка групповых и широковещательных запросов 6.1.3.2 Возможно
Бит RD в запросе установлен 6.1.3.2 Недопустимо
Бит RD игнорируется сервером для групповых и широковещательных запросов 6.1.3.2 Обязательно
Редкая передача только для получения адресов серверов имен 6.1.3.2 Следует
Использование ресурсов:
Управление передачей в соответствии с [DNS:2] 6.1.3.3 Обязательно
Конечные границы для запроса 6.1.3.3 Обязательно
Сообщение о некритичной ошибке после нескольких неудач 6.1.3.3 Обязательно
Кэширование временных отказов 6.1.3.3 Следует
Кэширование негативных откликов 6.1.3.3 Следует
Повторы с экспоненциальным периодом 6.1.3.3 Следует
Верхняя и нижняя граница 6.1.3.3 Следует
Клиент обрабатывает Source Quench 6.1.3.3 Следует
Сервер игнорирует Source Quench 6.1.3.3 Возможно
Пользовательский интерфейс:
Все программы имеют доступ к интерфейсу DNS 6.1.4.2 Обязательно
Возможность запросить всю информацию для данного имени 6.1.4.2 Обязательно
Возврат полной информации или сообщения об ошибке 6.1.4.2 Обязательно
Специальные интерфейсы 6.1.4.2 Возможно
Трансляция им <-> адрес 6.1.4.2 Обязательно
Возможности сокращений: 6.1.4.3 Возможно
Соглашение для полных имен 6.1.4.3 Обязательно
Однократное преобразование 6.1.4.3 Обязательно
Преобразование в приемлемом контексте 6.1.4.3 Обязательно
Список поиска: 6.1.4.3 Возможно
Администратор может запретить 6.1.4.3 Следует
Предотвращение излишних корневых запросов 6.1.4.3 Обязательно
Оба метода 6.1.4.3 Следует

6.2 Инициализация хоста

6.2.1 Введение

В этом разделе описана инициализация программ хоста через подключенную сеть или (в более общем случае) через Internet. Такие операции требуются для бездисковых станций, но могут использоваться и для хостов с дисками. Для бездисковых хостов процесс инициализации называется загрузкой из сети (network booting) и управляется программой загрузки (bootstrap), хранящейся в ПЗУ (boot ROM).

При инициализации бездисковых хостов через сеть выделяют две фазы:

  1. настройка уровня IP.

Бездисковые станции зачастую неспособны хранить параметры своей конфигурации, поэтому должна обеспечиваться возможность динамического получения таких параметров для поддержки остальных этапов процесса загрузки хоста. Конфигурационные параметры должны включать по крайней мере адреса IP для данного хоста и сервера загрузки. Для поддержки загрузки через маршрутизатор требуется также маска подсети и список используемых по умолчанию шлюзов.

  1. Загрузка системного кода для хоста.

На этапе загрузки операционной системы используется подходящий протокол передачи файлов для копирования программного кода через сеть с сервера загрузки.

Для хостов с дисками может использоваться первая фаза — динамическая настройка конфигурации. Это важно для микрокомпьютеров, наличие дисковода в которых позволяет ошибочно дублировать параметры конфигурации с других хостов. Кроме того, инсталляция новых хостов значительно упрощается за счет возможности получения конфигурационных параметров с центрального сервера — это экономит время администратора и избавляет от ненужных ошибок.

6.2.2 Требования

6.2.2.1 Динамическая настройка конфигурации

Для динамической настройки поддерживается целый ряд протоколов и служб.

  • Сообщения ICMP Information Request/ReplyЭта устаревшая пара сообщений предназначена для обеспечения хостам возможности определения номера сети. К сожалению, эти сообщения полезны только для хостов, которые уже знают свой номер (связанную с хостом часть адреса IP).
  • Протокол обратного преобразования адресов RARP [BOOT:4]RARP является протоколом канального уровня для широковещательных сред, который позволяет определять адрес IP по адресу канального уровня. К сожалению, RARP не работает через шлюзы IP и, следовательно, требует наличия сервера RARP в каждой сети. Другой конфигурационной информации протокол RARP не обеспечивает.
  • Сообщения ICMP Address Mask Request/ReplyЭти сообщения ICMP позволяют хосту определить адресную маску для отдельного сетевого интерфейса.
  • Протокол BOOTP [BOOT:2]Этот протокол позволяет хосту определить свой IP-адрес и адрес сервера загрузки непосредственно в процессе загрузки. Кроме того, дополнительно может передаваться маска подсети и список используемых по умолчанию шлюзов. Для нахождения сервера BOOTP хост передает широковещательные запросы с использованием протокола UDP. Для передачи широковещательных запросов BOOTP через маршрутизаторы используется специальное расширение, а в будущем IP Multicasting обеспечит стандартный механизм.

Для динамической настройки хостов предлагается использовать протокол BOOTP с расширением BOOTP Vendor Information Extensions, определенным в RFC 1084 [BOOT:3]. RFC 1084 определяет некоторые важные особенности такого расширения, не зависящие от реализации. В частности, это расширение позволяет протоколу BOOTP обеспечивать информацию о маске сети; рекомендуется передавать маски сетей в соответствии с этим документом.

Обсуждение

Исторически понятие подсетей появилось после определения IP и был разработан специальный механизм (сообщения ICMP Address Mask) для передачи хостам значения маски. Однако адресная маска IP и соответствующий IP-адрес образуют концептуальную пару и для упрощения работы их следует определять одновременно с помощью одного механизма из конфигурационного файла или во время динамической настройки типа BOOTP.

Отметим, что протокол BOOTP не обеспечивает возможности настройки конфигурации для всех интерфейсов многодомного хоста. Такие хосты или используют BOOTP раздельно для каждого интерфейса или настраивают один интерфейс с помощью BOOTP для выполнения загрузки через сеть, а потом инициализируют остальные интерфейсы.

Предполагается, что конфигурационные параметры прикладных уровней извлекаются из файлов после загрузки операционной системы.

6.2.2.2 Фаза загрузки

На этапе загрузки предлагается использовать протокол TFTP [BOOT:1] на основе адреса IP, полученного по BOOTP.

Не следует использовать TFTP с широковещательным адресом, по причинам, рассмотренным выше (см. 4.2.3.4).

6.3 Удаленное управление

6.3.1 Введение

Сообщество Internet внесло значительный вклад в разработку протоколов сетевого управления [MGT:1, MGT:6] — в результате этого были разработаны протоколы SNMP31 [MGT:4] и CMOT32 [MGT:5].

Для управления с помощью протоколов SNMP или CMOT хост должен поддерживать соответствующий агент управления. В состав хостов Internet следует включать агент для протокола SNMP или CMOT.

Оба протокола SNMP и CMOT работают на основе MIB33, определяющих набор объектов и значений для управления устройствами. Читая и меняя значения параметров, удаленное приложение может запрашивать и изменять состояние управляемой системы.

Стандарт MIB [MGT:3] был разработан для использования в обоих протоколах управления на основе типов данных, определенных SMI34 [MGT:2]. Дополнительные переменные MIB могут включаться в ветви enterprises и experimental пространства имен MIB [MGT:2].

Для каждого протокольного модуля на хосте следует реализовать имеющие к нему отношение переменные MIB. Хосту следует использовать переменные MIB, определенные в последней версии стандарта MIB, и можно поддерживать другие переменные MIB, когда они приемлемы и полезны.

6.3.2 Общие вопросы

Базы MIB предназначены для хостов и шлюзов, хотя для этих случаев реализации MIB могут различаться в деталях. В этом параграфе рассмотрены вопросы интерпретации MIB для хостов. Очевидно, что последующие версии MIB будут включать дополнительные объекты для управления хостами.

Управляемый хост должен реализовать следующие группы определений объектов MIB: System, Interfaces, Address Translation, IP, ICMP, TCP, UDP.

Ниже перечислены конкретные интерпретации, применимые к хостам:

  1. ipInHdrErrors

Отметим, что ошибка time-to-live exceeded35 может происходить на хостах только при пересылке дейтаграмм isource-route.

  1. ipOutNoRoutes

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

  1. ipFragOKs, ipFragFails, ipFragCreates

Хосты, не поддерживающие преднамеренной фрагментации (см. параграф «Фрагментация» в работе [INTRO:1]) должны возвращать нулевые значения для этих переменных.

  1. icmpOutRedirects

Для хостов эта переменная должна всегда иметь нулевое значение, если хост не передает сообщений Redirect.

  1. icmpOutAddrMaskReps

Для хостов эта переменная должна всегда иметь нулевое значение, если хост не уполномочен на передачу информации об адресных масках.

  1. ipAddrTable

Для хостов объект IP Address Table представляет собой эффективную таблицу логических интерфейсов.

  1. ipRoutingTable

Для хостов объект IP Routing Table представляет собой комбинацию маршрутного кэша и таблицы статических маршрутов, описанные в параграфе «Маршрутизация исходящих дейтаграмм» работы [INTRO:1].

В каждом объекте ipRouteEntry, записи ipRouteMetric1…4 обычно не имеют значения для хоста; следует задавать для них значения -1, если ipRouteType не имеет значения remote.

Если адресаты в подключенной сети не появляются в кэше маршрутов (см. параграф «Маршрутизация исходящих дейтаграмм» в работ [INTRO:1]), не будет записей со значением ipRouteType = direct.

Обсуждение

Текущая спецификация MIB не включает тип обслуживания TOS в записи ipRouteEntry, но в будущих реализациях этот параметр будет включен.

Предполагается также расширение MIB для поддержки программ удаленного управления (например, удаленной настройки почтовых систем). Сетевые сервисные службы типа почтовых систем должны, следовательно, разрабатываться с учетом прерываний для удаленного управления.

6.3.3 Требования к функциям управления

Функция

Параграф

Требования

Поддержка агента SNMP или CMOT

6.3.1

Следует

Реализация указанных объектов в стандартной базе MIB

6.3.1

Следует

7. Литература

В этом разделе перечислены основные и дополнительные источники информации по рассмотренным в документе вопросам.

Общие вопросы

[INTRO:1] «Requirements for Internet Hosts — Communication Layers,» IETF Host Requirements Working Group, R. Braden, Ed., RFC 1122, October 1989.

[INTRO:2] «DDN Protocol Handbook,» NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985.

[INTRO:3] «Official Internet Protocols,» J. Reynolds and J. Postel, RFC 101137, May 1987.

[INTRO:4] «Protocol Document Order Information,» O. Jacobsen and J. Postel, RFC 980, March 1986.

[INTRO:5] «Assigned Numbers,» J. Reynolds and J. Postel, RFC 101038, May 1987.

TELNET

[TELNET:1] «Telnet Protocol Specification,» J. Postel and J. Reynolds, RFC 85439, May 1983.

[TELNET:2] «Telnet Option Specification,» J. Postel and J. Reynolds, RFC 855, May 1983.

[TELNET:3] «Telnet Binary Transmission,» J. Postel and J. Reynolds, RFC 856, May 1983.

[TELNET:4] «Telnet Echo Option,» J. Postel and J. Reynolds, RFC 857, May 1983.

[TELNET:5] «Telnet Suppress Go Ahead Option,» J. Postel and J. Reynolds, RFC 858, May 1983.

[TELNET:6] «Telnet Status Option,» J. Postel and J. Reynolds, RFC 859, May 1983.

[TELNET:7] «Telnet Timing Mark Option,» J. Postel and J. Reynolds, RFC 860, May 1983.

[TELNET:8] «Telnet Extended Options List,» J. Postel and J. Reynolds, RFC 861, May 1983.

[TELNET:9] «Telnet End-Of-Record Option,» J. Postel, RFC 88540, December 1983.

[TELNET:10] «Telnet Terminal-Type Option,» J. VanBokkelen, RFC 109141, February 1989.

[TELNET:11] «Telnet Window Size Option,» D. Waitzman, RFC 1073, October 1988.

[TELNET:12] «Telnet Linemode Option,» D. Borman, RFC 111642, August 1989.

[TELNET:13] «Telnet Terminal Speed Option,» C. Hedrick, RFC 1079, December 1988.

[TELNET:14] «Telnet Remote Flow Control Option,» C. Hedrick, RFC 108043, November 1988.

Дополнительная литература по TELNET

[TELNET:15] «Telnet Protocol,» MIL-STD-178244, U.S. Department of Defense, May 1984.

[TELNET:16] «SUPDUP Protocol,» M. Crispin, RFC 734, October 1977.

[TELNET:17] «Telnet SUPDUP Option,» M. Crispin, RFC 736, October 1977.

[TELNET:18] «Data Entry Terminal Option,» J. Day, RFC 73245, June 1977.

[TELNET:19] «TELNET Data Entry Terminal option — DODIIS Implementation,» A. Yasuda and T. Thompson, RFC 1043, February 1988.

FTP

[FTP:1] «File Transfer Protocol,» J. Postel and J. Reynolds, RFC 95946, October 1985.

[FTP:2] «Document File Format Standards,» J. Postel, RFC 678, December 1974.

[FTP:3] «File Transfer Protocol,» MIL-STD-178047, U.S. Department of Defense, May 1984.

TFTP:

[TFTP:1] «The TFTP Protocol Revision 2,» K. Sollins, RFC 78348, June 1981.

Электронная почта:

[SMTP:1] «Simple Mail Transfer Protocol,» J. Postel, RFC 82149, August 1982.

[SMTP:2] «Standard For The Format of ARPA Internet Text Messages,» D. Crocker, RFC 82250, August 1982.

[SMTP:3] «Mail Routing and the Domain System,» C. Partridge, RFC 9744, January 1986.

[SMTP:4] «Duplicate Messages and SMTP,» C. Partridge, RFC 1047, February 1988.

[SMTP:5a]51 «Mapping between X.400 and RFC 822,» S. Kille, RFC 98752, June 1986.

[SMTP:5b] «Addendum to RFC 987,» S. Kille, RFC 102653, September 1987.

[SMTP:6] «Simple Mail Transfer Protocol,» MIL-STD-178154, U.S. Department of Defense, May 1984.

[SMTP:7] «A Content-Type Field for Internet Messages,» M. Sirbu, RFC 1049, March 1988.

Служба доменных имен:

[DNS:1] «Domain Names — Concepts and Facilities,» P. Mockapetris, RFC 103455, November 1987.

[DNS:2] «Domain Names — Implementation and Specification,» RFC 1035, P. Mockapetris, November 1987.

[DNS:3] «Mail Routing and the Domain System,» C. Partridge, RFC 9744, January 1986.

[DNS:4] «DoD Internet Host Table Specification,» K. Harrenstein, RFC 952, M. Stahl, E. Feinler, October 1985.

Дополнительные ссылки по DNS:

[DNS:5] «Hostname Server,» K. Harrenstein, M. Stahl, E. Feinler, RFC 953, October 1985.

[DNS:6] «Domain Administrators Guide,» M. Stahl, RFC 1032, November 1987.

[DNS:7] «Domain Administrators Operations Guide,» M. Lottor, RFC 1033, November 1987.

[DNS:8] «The Domain Name System Handbook,» Vol. 4 of Internet Protocol Handbook, NIC 50007, SRI Network Information Center, August 1989.

Инициализация системы:

[BOOT:1] «Bootstrap Loading Using TFTP,» R. Finlayson, RFC 906, June 1984.

[BOOT:2] «Bootstrap Protocol (BOOTP),» W. Croft and J. Gilmore, RFC 95158, September 1985.

[BOOT:3] «BOOTP Vendor Information Extensions,» J. Reynolds, RFC 108459, December 1988.

[BOOT:4] «A Reverse Address Resolution Protocol,» R. Finlayson, T. Mann, J. Mogul, and M. Theimer, RFC 90312, June 1984.

Управление:

[MGT:1] «IAB Recommendations for the Development of Internet Network Management Standards,» V. Cerf, RFC 1052, April 1988.

[MGT:2] «Structure and Identification of Management Information for TCP/IP-based internets,» M. Rose and K. McCloghrie, RFC 106560, August 1988.

[MGT:3] «Management Information Base for Network Management of TCP/IP-based internets,» M. Rose and K. McCloghrie, RFC 106661, August 1988.

[MGT:4] «A Simple Network Management Protocol,» J. Case, M. Fedor, M. Schoffstall, and C. Davin, RFC 109862, April 1989.

[MGT:5] «The Common Management Information Services and Protocol over TCP/IP,» U. Warrier and L. Besaw, RFC 109563, April 1989.

[MGT:6] «Report of the Second Ad Hoc Network Management Review Group,» V. Cerf, RFC 1109, August 1989.

Вопросы безопасности

Существует множество вопросов безопасности, связанных с приложениями и служебными программами, но подробное рассмотрение этих вопросов выходит за пределы данного RFC. Связанные с безопасностью темы рассмотрены в параграфах, посвященных протоколу TFTP (4.2.1, 4.2.3.4, 4.2.3.5), командам SMTP VRFY и EXPN (5.2.3), а также командам SMTP HELO (5.2.5), и SMTP DATA (Section 5.2.8).

Адрес автора

Robert Braden (Роберт Браден)

USC/Information Sciences Institute

4676 Admiralty Way

Marina del Rey, CA 90292-6695

телефон: (213) 822 1511

EMail: Braden@ISI.EDU


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

 

1Маршрутизаторам в современной терминологии.

2Постоянное запоминающее устройство. Прим. перев.

3Термином модуль (блок) будем обозначать неделимую при передаче на данном уровне совокупность данных. Прим. перев.

4RFC 952 разрешает для первого символа только буквы английского алфавита. Прим. перев.

5В исходном документе ошибочно указан размер 635. Прим. перев.

6Go Ahead — идите прочь.

7End-of-Record — конец записи.

8Коды ASCII > 127. Прим. перев.

9Т. е. не текстового. Прим. перев.

10Data entry terminal.

11В RFC 2228 (безопасность) и RFC 2640 (интернационализация) содержится ряд дополнений к этой спецификации. Прим. перев.

12Service not available, closing control connection — сервис недоступен, управляющее соединение закрывается.

13сервер и клиент должны следовать соглашениям для протокола Telnet…[для управляющего соединения].

14Структуры Record требуются для тех хостов, чьи файловые системы поддерживают структуры записей.

15Число m задает размер слова памяти в битах.

16Для хостов с файловой системой на основе записей; в остальных случаях необязательно.

17Для показанных раньше значений.

18Sorcerer’s Apprentice Syndrome.

19Simple Mail Transfer Protocol — простой протокол передачи почты.

20Message Transfer Agent — агент переноса сообщений.

21User Agent — пользовательский агент. Прим. перев.

22Mail-exchange — обмен почтой.

23Во многих современных руководствах по безопасности рекомендуется отключить команды VRFY и EXPN. Прим. перев.

24Well-Known Service — общеизвестный сервис.

25Fully-qualified domain name.

26Отметим, что на затраты ресурсов при передаче значительное влияние оказывает выбор стратегии передачи (см. 5.3.1).

27Recursion Desired — желательна рекурсия.

28Round-trip time — период кругового обхода. Прим. перев.

29Resource Record — запись о ресурсе.

30Если не существует частного соглашения между сервером и резольвером на использование только TCP.

31Simple Network Management Protocol — простой протокол сетевого управления.

32Common Management Information Protocol over TCP — протокол передачи управляющей информации через TCP.

33Management Information Base — база информации для управления.

34Structure of Management Information — структура управляющей информации.

35Время жизни истекло.

36В RFC 1349, RFC 2181, RFC 5321 содержится ряд обновлений к этому документу. Прим. перев.

37Этот документ периодически обновляется. На сегодняшний день последняя версия содержится в RFC 5000. Прим. перев.

38В соответствии с RFC 3232 документ STD 2 утратил силу. Значения Assigned Numbers следует искать в базе данных, доступной на сайте www.iana.org/numbers.html. Прим. перев.

39В RFC 5198 содержится ряд обновлений для этого документа. Прим. перев.

40В исходном документе ошибочно указан документ RFC 855. Прим. перев.

41Этот документ заменяет RFC 930.

42В настоящее время этот документ заменен RFC 1184. Прим. перев.

43В настоящее время этот документ заменен RFC 1372. Прим. перев.

44Этот документ описывает тот же самый протокол, что и RFC 854. При возникновении разночтений RFC 854 имеет более высокий приоритет, а данный документ имеет преимущество над обоими.

45В RFC 1043 [TELNET:19] содержится ряд поправок к этой спецификации. Прим. перев.

46В RFC 2228 (безопасность), RFC 2640 (интернационализация), RFC 2773, RFC 3659, RFC 5797 содержится ряд дополнений и изменений к спецификации протокола. Прим. перев.

47Этот документ основан на ранней версии спецификации FTP (RFC 765) и утратил свою силу.

48Действующий сегодня вариант спецификации TFTP описан в RFC 1350. Прим. перев.

49Этот документ признан устаревшим и заменен документом RFC 2821, который, в свою очередь, был заменен RFC 5321 и обновлен в RFC 5336. Прим. перев.

50Этот документ признан устаревшим и заменен RFC 2822, который, в свою очередь, был заменен RFC 5322 и обновлен в RFC 5335 и RFC 5336. Прим. перев.

51Документы [SMTP:5a] и [SMTP:5b] содержат описание стандарта, предложенного для организации шлюзов между Internet и средами X.400.

52В настоящее время этот документ устарел и заменен RFC 1327 и RFC 2156. Прим. перев.

53В исходном документе номер этого RFC не указан в результате ошибки. В настоящее время этот документ устарел и заменен RFC 1327 и RFC 2156. Прим. перев.

54Эта спецификация описывает тот же протокол, что RFC 821. Однако, стандарт MIL-STD-1781 не полон (в частности, в нем отсутствуют записи MX [SMTP:3]).

55RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 2065, RFC 2181, RFC 2308, RFC 2535, RFC 4035, RFC 4343, RFC 4592, RFC 5936 содержат ряд дополнений и поправок к этому стандарту. Прим. перев.

56В RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 1995, RFC 1996, RFC 2065, RFC 2136, RFC 2137, RFC 2181, RFC 2308, RFC 2535, RFC 2845, RFC3425, RFC 3658, RFC 4033, RFC 4034, RFC 4035, RFC 4343, RFC 5936 содержится ряд дополнений и поправок к этому стандарту. Прим. перев.

58В RFC 1395, RFC 1497, RFC 1532, RFC 1542, RFC 5494 содержится ряд дополнений и поправок к этому стандарту. Прим. перев.

59Этот документ отменен более поздними RFC 1395, RFC 1497, RFC 1533. Прим. перев.

60Этот документ отменен более поздним RFC 1155. Прим. перев.

61Этот документ отменен более поздним RFC 1156. Прим. перев.

62Этот документ отменен более поздним RFC 1157. Прим. перев.

63Этот документ отменен более поздним RFC 1189. Прим. перев.