AAA

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

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

В данном 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). В документе 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 основана на группе базовых допущений о коммуникационной системе. Допущения, связанные с хостами, перечислены ниже:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наконец, часть конфигурационных опций может потребоваться для обеспечения взаимодействия с устаревшими или содержащими ошибки реализациями протоколов, распространяемыми без исходных кодов (к несчастью, такое встречается в 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 считается «безусловно совместимой» (unconditionally compliant); если же выполняются все требования MUST, но проигнорирована часть требований SHOULD, реализация считается «условно совместимой» (conditionally compliant).

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

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

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

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

 _______________________________________________
| LL hdr | IP hdr |         (data)              |
|________|________|_____________________________|

 <---------- Frame ----------------------------->
          <----------Packet -------------------->

B) Перед фрагментацией IP или после сборки:

 ______________________________________
| IP hdr | transport| Application Data |
|________|____hdr___|__________________|

 <--------  Datagram ------------------>
          <-------- Message ----------->

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

 ______________________________________
| IP hdr |  TCP hdr | Application Data |
|________|__________|__________________|

 <--------  Datagram ------------------>
          <-------- Segment ----------->

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 Согласование трейлерного протокола

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

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

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

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

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

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

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

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 Мбит/с) с помощью кабеля

Хосты 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 — 1492 байта.

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

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

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

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

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

ФункцияПараграфТребование
Трейлерная инкапсуляция2.3.1Обязательно
Передавать трейлеры по умолчанию без согласования2.3.1Недопустимо
ARP2.3.2
Удаление устаревших записей2.3.2.1Обязательно
Предотвращение ARP-лавин2.3.2.1Обязательно
Настройка тайм-аута для кэша2.3.2.1Рекомендуется
Сохранение по крайней мере последнего пакета с unresolved адресом2.3.2.2Рекомендуется
Инкапсуляция Ethernet и IEEE 8022.3.3
Способность хоста:2.3.3
Использовать RFC 894 для приема и передачи2.3.3Обязательно
Использовать RFC 1042 для приема2.3.3Рекомендуется
Использовать RFC 1042 для передачи2.3.3Возможно
Для этого случая поддержка по умолчанию RFC 8942.3.3Обязательно
Использование инкапсуляции с K1=62.3.3Недопустимо
Поддержка ARP для сетей Ethernet и IEEE 8022.3.3Обязательно
Канальный уровень сообщает о широковещательных кадрах уровню IP2.4Обязательно
Передача уровнем IP значений TOS на канальный уровень2.4Обязательно
Трактовка отсутствия адреса в кэше как Destination Unreachable2.4Недопустимо

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

3.1 Введение

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

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

Ссылки на другие источники информации приведены в главе 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 discard. Это означает, что дейтаграмма отбрасывается без дальнейшей обработки и даже не передается сообщение ICMP об ошибке (см. параграф 3.2.2). Однако, для обеспечения диагностики хост должен обеспечивать возможность протоколирования таких ошибок (см. параграф 1.2.3), включая запись содержимого отбрасываемых дейтаграмм. Кроме того, количество отбрасываемых дейтаграмм должно учитываться счетчиком статистики.

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 зарезервирован для экспериментов.

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

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

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

или

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

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

Номера сетей распределяются административно, чтобы каждая сеть в масштабе планеты имела уникальный номер. В адресах 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-группы, в которую входит данный хост.

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

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

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

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

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

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

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

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

Поле Precedence предназначено для специальных приложений Министерства Обороны (Department of Defense). Вопросы использования отличных от 0 значений этого поля выходит за пределы компетенции настоящего документа и стандартов IP. Производители продукции должны консультироваться с агентством DCA (Defense Communication Agency) для получения рекомендаций по использованию поля Precedence в своих реализациях протоколов других уровней. Однако, разработчики должны понимать, что использование поля precedence потребует передачи его значения между протоколами разных уровней, как это делается для поля TOS.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

3.2.2.1 Destination Unreachable: RFC 792

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

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

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

Сообщение Destination Unreachable, принятое с кодом 0 (Net — сеть), 1 (Host — хост) или 5 (Bad Source Route — некорректный маршрут от отправителя), может приходить от транзитного маршрутизатора и должно интерпретироваться как намек (не доказательство) на то, что адресат может быть недоступен [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, Appendix 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.

3.2.2.4 Time Exceeded: RFC 792

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

3.2.2.5 Parameter Problem: RFC 792

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

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

3.2.2.6 Echo Request/Reply: RFC 792

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

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

3.2.2.7 Information Request/Reply: RFC 792

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

3.2.2.8 Timestamp/Timestamp Reply: RFC 792

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

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

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 и должны выполняться следующие условия:

Если сообщения 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 приведены в параграфе System Initialization работы [INTRO: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 выбирает следующий маршрутизатор (next hop) для каждой передаваемой дейтаграммы. Если получатель находится в подключенной сети, дейтаграмма передается на этот хост напрямую; в остальных случаях дейтаграмма направляется маршрутизатору подключенной сети.

3.3.1.1 Выбор Local/Remote

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

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

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

3.3.1.2 Выбор шлюза

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.2 Сборка (Reassembly)

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

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

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

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

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

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

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

Хост должен реализовать механизм, позволяющий транспортному уровню выяснять значение 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 требуется для каждого сетевого интерфейса.

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

3.3.4.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.7 IP Multicasting

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

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

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

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

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

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

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

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

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

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

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

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

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

ФункцияПараграфТребование
Реализация IP и ICMP3.1Обязательно
Обработка remote multihoming на прикладном уровне3.1Обязательно
Поддержка local multihoming3.1Возможно
Выполнение требований к шлюзам при рассылке дейтаграмм3.1Обязательно
Настройка конфигурации для встроенного маршрутизатора3.1Обязательно
Режим маршрутизатора по умолчанию выключен3.1Обязательно
Автоматическая настройка по числу интерфейсов3.1Недопустимо
Возможность протоколирования отброшенных дейтаграмм3.1Рекомендуется
Корректировка счетчиков статистики при отбрасывании3.1Рекомендуется
Отбрасывание без уведомления пакетов других (не 4) версий3.2.1.1Обязательно
Проверка контрольной сумм и отбрасывание без уведомления при ошибках3.2.1.2Обязательно
Адресация:3.2.1.3
Адресация подсетей (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.4Возможно
TOS:
Возможность установки TOS на транспортном уровне3.2.1.6Обязательно
Передача принятых значений TOS на транспортный уровень3.2.1.6Рекомендуется
Использование на канальном уровне отображения RFC 7953.2.1.6Не рекомендуется
TTL:
Передача пакетов с TTL=03.2.1.7Не допускается
Отбрасывание принятых дейтаграмм с TTL < 23.2.1.7Не допускается
Возможность установки TTL на транспортном уровне3.2.1.7Обязательно
Возможность установки фиксированного значения TTL3.2.1.7Обязательно
Опции IP:
Возможность транспортного уровня передавать опции3.2.1.8Обязательно
Передача всех принятых опций на вышележащий уровень3.2.1.8Обязательно
Игнорирование неизвестных опций на уровне IP3.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 Route3.2.1.8cОбязательно
Дейтаграммы с заполненным SR передаются на транспортный уровень3.2.1.8cОбязательно
Построение корректного (без избыточности) пути возврата3.2.1.8cОбязательно
Передача множества опции SR в заголовке3.2.1.8cНедопустимо
ICMP:
Отбрасывание без уведомления неизвестных типов ICMP3.2.2Обязательно
Включение более 8 октетов исходной дейтаграммы3.2.2Возможно
Включение полученных октетов3.2.2Обязательно
Передача сообщений ICMP Error транспортному ровню3.2.2Обязательно
Передача сообщений ICMP с TOS=03.2.2Рекомендуется
Передача сообщений ICMP об ошибках для:
— сообщений ICMP об ошибках3.2.2Недопустимо
— широковещательных и групповых пакетов IP3.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 unreachable3.2.2.1Рекомендуется
Интерпретация dest. unreachable лишь как совета3.2.2.1Обязательно
Redirect:
Хост посылает Redirect3.2.2.2Не рекомендуется
Обновление кэша маршрутов при получении Redirect3.2.2.2Обязательно
Обслуживание Redirect для хоста и сети3.2.2.2Обязательно
Отбрасывание некорректных сообщений Redirect3.2.2.2Рекомендуется
Source Quench:
Передача Source Quench при нехватке буферов3.2.2.3Возможно
Передача Source Quench на верхний уовень3.2.2.3Обязательно
Воздейтсвие верхнего уровня на Source Quench3.2.2.3Рекомендуется
Передача Time Exceeded на верхний уровень3.2.2.4Обязательно
Проблемы с параметрами:
Передача сообщений Parameter Problem3.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 Reply3.2.2.6Обязательно
Сохранение данных в Echo Reply3.2.2.6Обязательно
Передача Echo Reply на верхний уровень3.2.2.6Обязательно
Отражение опций Record Route, Time Stamp3.2.2.6Рекомендуется
Инверсия и отражение опции Source Route3.2.2.6Обязательно
ICMP Information Request/Reply3.2.2.7Не рекомендуется
ICMP Timestamp/Timestamp Reply:Возможно
Минимизация вариаций задержки3.2.2.8Рекомендуется
Отбрасывание без уведомления широковещательных пакетов Timestamp3.2.2.8Возможно
Отбрасывание без уведомления групповых Timestamp3.2.2.8Возможно
Использование указанного адреса как отправителя TS Reply3.2.2.8Обязательно
Отражение опций Record Route и Timestamp3.2.2.8Рекомендуется
Обращение и отражение опции Source Route3.2.2.8Обязательно
Передача на верхний уровень3.2.2.8Обязательно
Выполнение правил для «стандартных значений»3.2.2.8Обязательно
ICMP Address Mask Request/Reply:
Настройка источника получения Address Mask3.2.2.9Обязательно
Поддержка статической конфигурации адресных масок3.2.2.9Обязательно
Динамическое получение маски при загрузке3.2.2.9Возможно
Получение маски с помощью Addr. Mask Request/Reply3.2.2.9Возможно
Повторная передача запроса при отсутствии отклика3.2.2.9Обязательно
Использование маски по умолчанию при отсутствии отклика3.2.2.9Рекомендуется
Обновление маски после получения первого отклика3.2.2.9Обязательно
Разумная проверка маски3.2.2.9Рекомендуется
Неуполномоченная передача откликов Address Mask Reply3.2.2.9Недопустимо
Явное указание уполномоченных агентов3.2.2.9Обязательно
Статическая конфигурация => флаг Addr-Mask-Authoritative3.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 Redirect3.3.1.2Рекомендуется
Использование шлюза по умолчанию при отсутствии записи в кэше3.3.1.2Обязательно
Поддержка множества «шлюзов по умолчанию»3.3.1.2Обязательно
Поддержка таблицы статических маршрутов3.3.1.2Возможно
Флаг: возможность переписывания маршрута путем Redirect3.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_R3.3.2Рекомендуется
Возможность транспортного уровня выяснять MMS_R3.3.2Обязательно
Передача ICMP Time Exceed при тайм-ауте во время сборки3.3.2Обязательно
Фиксированный тайм-аут для сборки3.3.2Рекомендуется
Передача MSS_S на верхние уровни3.3.3Обязательно
Локальная фрагментация исходящих пакетов3.3.3Возможно
или отказ от передачи пакетов > MSS_S3.3.3Обязательно
Передача не более 576 байтов за пределы сети3.3.3Рекомендуется
Конфигурационный флаг All-Subnets-MTU3.3.3Возможно
Многодомные хосты:
Ответ в таким же адресом, как указанный адрес получателя3.3.4.2Рекомендуется
Возможность для приложений выбирать локальные адреса IP3.3.4.2Обязательно
Отбрасывание дейтаграмм на «некорректном» интерфейсе3.3.4.2Возможно
Передача дейтаграмм только через «правильный» интерфейс3.3.4.2Возможно
Пересылка SOURCE-ROUTE:
Пересылка дейтаграмм с опцией Source Route3.3.5Возможно
Выполнение соответствующих правил для шлюзов3.3.5Обязательно
Обновление TTL с помощью правил шлюза3.3.5Обязательно
Возможность генерации кодов ошибок ICMP 4, 53.3.5Обязательно
IP-адрес отправителя не указывает на локальный хост3.3.5Возможно
Обновление опций Timestamp, Record Route3.3.5Обязательно
Настраиваемый переключатель для нелокальных SRing3.3.5Обязательно
По умолчанию отключено3.3.5Обязательно
Выполнение правил доступа к шлюзу для нелокальных SRing3.3.5Обязательно
Если не пересылаем, использовать опцию Dest Unreach (5)3.3.5Рекомендуется
Широковещание:
Широковещательный IP-адрес отправителя3.2.1.3Недопустимо
Нормальный прием широковещательных дейтаграмм форм. 0 и -13.3.6Рекомендуется
Опция передачи широковещ. дейтаграмм форм. 0 и -13.3.6Возможно
По умолчанию формат -13.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Обязательно
Транспортный уровень может передав. некоторые сообщения ICMP3.4Обязательно
Передача заданных сообщений ICMP на транспортный уровень3.4Обязательно
Включение заголовка IP + 8 или более октетов3.4Обязательно

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

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

4.1.1 Введение

Протокол пользовательских дейтаграмм UDP [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, для которого нет прослушивания (LISTEN), протоколу UDP рекомендуется передать сообщение отправителю ICMP Port Unreachable.

4.1.3.2 Опции IP

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

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

4.1.3.3 Сообщения ICMP

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

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

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

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

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

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 Unreachable4.1.3.1Рекомендуется
Опции IP в UDP
Передача полученных опций на уровень приложений4.1.3.2Обязательно
Приложения могут устанавливать опции при передаче4.1.3.2Обязательно
UDP передает опции на уровень IP4.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Возможно
Многодомные хосты UDP:
Передача указанного адреса получателя приложениям4.1.3.5Обязательно
Возможность задания локального адреса отправителя на прикладном уровне4.1.3.5Обязательно
Возможность задания шаблона локального адреса отправителя на прикладном уровне4.1.3.5Обязательно
Уведомление приклад. уровня об используемом локальном адресе4.1.3.5Возможно
Дейтаграммы с некорректным IP-адресом отправителя отбрасываются UDP/IP4.1.3.6Обязательно
При передаче дейтаграмм используется только корректный. адрес IP4.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 Введение

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

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

4.2.2.1 Хорошо известные (Well-Known) порты: RFC 793, параграф 2.7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Протокол TCP должен поддерживать опции максимального размера сегмента — MSS для приема и передачи [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

где:

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

MMS_R - 20

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

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

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

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, содержащих данные.

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 MSL. Однако возможно восприятие новых вызовов SYN от удаленного TCP для повторного открытия соединения непосредственно из состояния TIME-WAIT, если выполняются следующие условия:

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

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).

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).

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 должен проверить его стандартным способом (см. ниже).

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

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

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

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

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

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

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

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 сказано возможно).

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

Ниже приведены некоторые поправки к параграфу «Обработка событий» в RFC 793.

4.2.2.21 Подтверждение для сегментов из очереди: RFC 793, параграф 3.9

TCP может передавать сегмент ACK, подтверждающий RCV.NXT, когда приходит корректный сегмент, который находится в окне, но не на его левой границе.

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

4.2.3.1 Расчет тайм-аута для повторной передачи

Хост TCP должен поддерживать алгоритмы Karn и Jacobson для расчета тайм-аута повторной передачи RTO.

Такая реализация должна также включать экспоненциальный рост последовательных значений RTO для одного сегмента. Для повторной передачи сегментов SYN рекомендуется использовать такой же алгоритм, как для сегментов данных.

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

Известно, что рекомендованные значения верхней и нижней границ RTO неадекватны для больших сетей. Рекомендуется задавать нижнюю границу в долях секунды (для работы со скоростными ЛВС), а в качестве верхней границы использовать значение 2*MSL (240 секунд).

4.2.3.2 Когда передавать сегмент ACK

Хост, получающий поток сегментов данных TCP, может повысить эффективность работы (хостов и Internet) за счет передачи меньшего числа подтверждений ACK для принятых сегментов. Такой метод называется задержкой подтверждений [TCP:5].

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

4.2.3.3 Когда передавать Window Update

Протокол TCP должен включать алгоритм предотвращения SWS на приемной стороне [TCP:5].

4.2.3.4 Когда передавать данные

Протокол TCP должен поддерживать механизм предотвращения SWS на приемной стороне.

Для протокола TCP рекомендуется реализация алгоритма Nagle [TCP:9], позволяющего объединять короткие сегменты. Однако, приложениям должен обеспечиваться способ запрета алгоритма Nagle для отдельных соединений. Во всех случаях для передачи данных действуют также ограничения, вносимые алгоритмом Slow Start (см. 4.2.2.15).

4.2.3.5 Сбои в соединениях TCP

Многократные повторы передачи одного сегмента TCP свидетельствуют о наличии сбоев на удаленном хосте или пути через Internet. Эти сбои могут быть кратковременными или продолжительными. При возникновении таких ситуаций хост должен использовать перечисленные ниже процедуры [IP:11]:

Рекомендуется устанавливать для R1 значение, соответствующее по крайней мере 3 повторам при текущем значении RTO. Для R2 рекомендуется задавать значение не менее 100 секунд.

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

Однако, значения R1 и R2 для сегментов SYN могут отличаться от значения для сегментов данных. В частности, значение R2 для SYN должно быть достаточно велико, чтобы обеспечивать повторные передачи по крайней мере в течение 3 минут. Приложение может закрыть соединение и раньше (например, задав число попыток).

4.2.3.6 TCP Keep-Alive

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

Пакеты keep-alive должны передаваться только при отсутствии пакетов данных или подтверждений в течение заданного интервала. Значение этого интервала должно быть настраиваемым и по умолчанию должно составлять не менее 2 часов. Очень важно помнить, что для сегментов ACK, не содержащих данных, протокол TCP не обеспечивает гарантии доставки. Следовательно, при реализации механизма keep-alive сбои в ответ на специфические проверки не должны интерпретироваться как «умирание» соединения.

Рекомендуется передавать сегменты keep-alive без данных, однако можно настраивать протокол на передачу сегментов keepalive, содержащих один произвольный октет для совместимости с ошибочными реализациями TCP.

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.

4.2.3.10 Проверка корректности удаленного адреса

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

Входящие запросы SYN с некорректным адресом отправителя должны игнорироваться уровнем TCP или IP (см. 3.2.1.3). Реализация TCP должна без уведомления отбрасывать все входящие сегменты SYN с широковещательными или групповыми адресами.

4.2.3.11 Картины трафика TCP

4.2.3.12 Эффективность

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

4.2.4.1 Асинхронные отчеты

Должен обеспечиваться механизм информирования приложений о некритичных ошибках TCP. В общем случае это реализуется с помощью прикладной процедуры ERROR_REPORT, которая может асинхронно [INTRO:7] вызываться с транспортного уровня: ERROR_REPORT(local connection name, reason, subreason) Кодирование причин ошибок не рассматривается здесь, однако сообщения, асинхронно передаваемые приложениям, должны включать:

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

4.2.4.2 Тип обслуживания

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

Значение TOS задается независимо для каждого направления в соединении, поэтому принимающее приложение будет задавать TOS для сегментов ACK.

TCP может передавать приложениям последнее использованное значение TOS из принятых сегментов.

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,] ... )

4.2.5 Требования к протоколу TCP

ФункцияПараграфТребование
Флаг Push
Объединение или очередь при отсутствии флага Push4.2.2.2Возможно
Передающая сторона удаляет последовательные флаги Push4.2.2.2Рекомендуется
При вызове функции SEND можно установить Push4.2.2.2Возможно
При отсутствии Push бесконечный буфер передачи4.2.2.2Недопустимо
При отсутствии Push установка PSH для последнего сегмента4.2.2.2Обязательно
Уведомление принимающей программы о PSH4.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Обязательно
Первая проверка после RTO4.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Обязательно
Реализация приема и передачи опции MSS4.2.2.6Обязательно
Передача опции MSS, если максимальный размер не равен 5364.2.2.6Рекомендуется
Передача опции MSS во всех случаях4.2.2.6Возможно
Значение MSS для передачи по умолчанию равно 5364.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 MSL4.2.2.13Обязательно
Восприятие новых SYN во время TIME-WAIT4.2.2.13Возможно
Повторная передача
Алгоритм Jacobson Slow Start4.2.2.15Обязательно
Алгоритм Jacobson Congestion-Avoidance4.2.2.15Обязательно
Повторная передача с сохранением идентификации IP4.2.2.15Возможно
Алгоритм Karn4.2.3.1Обязательно
Алгоритм Якобсона для оценки RTO4.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Обязательно
Передача данных
Настраиваемое значение TTL4.2.2.19Обязательно
Алгоритм предотвращения SWS на передающей стороне4.2.3.4Обязательно
Алгоритм Nagle4.2.3.4Рекомендуется
Приложение может отключить алгоритм Nagle4.2.3.4Обязательно
Сбои в соединениях
Негативный анонс для IP при достижении R14.2.3.5Обязательно
Закрытие соединения при достижении R24.2.3.5Обязательно
Приложения могут устанавливать R24.2.3.5Обязательно
Информировать прикладной уровень после R1, но до R24.2.3.5Рекомендуется
Рекомендуемые значения для R1 и R24.2.3.5Рекомендуется
Поддержка такого же механизма для SYN4.2.3.5Обязательно
Значение R2 для SYN не менее 3 минут4.2.3.5Обязательно
Передача пакетов Keep-Alive4.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
Игнорировать опции, не понятные TCP4.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 от уровня IP4.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 => slow start4.2.3.9Рекомендуется
Time Exceeded => информировать приложение без разрыва соединения4.2.3.9Рекомендуется
Param Problem => информировать приложение без разрыва соединения4.2.3.9Рекомендуется
Проверка адресов
Отказ для вызовов CALL с неверным адресом IP4.2.3.10Обязательно
Отказ для SYN от некорректных адресов IP4.2.3.10Обязательно
Отбрасывание без уведомления SYN с широковещательными/групповыми адресами4.2.3.10Обязательно
Интерфейс между TCP и приложениями
Механизм информирования об ошибках4.2.4.1Обязательно
Приложение может отключать информирование об ошибках4.2.4.1Рекомендуется
Приложение может задавать TOS для передачи4.2.4.2Обязательно
Передача без изменений на уровень IP4.2.4.2Рекомендуется
Приложение может менять TOS для действующего соединения4.2.4.2Рекомендуется
Передача приложению полученного TOS4.2.4.2Возможно
Вызов FLUSH4.2.4.3Возможно
Адрес IP как необязательный параметр OPEN4.2.4.4Обязательно

5. Литература

  1. [INTRO:1] "Requirements for Internet Hosts — Application and Support," IETF Host Requirements Working Group, R. Braden, Ed., RFC 1123, October 1989
  2. [INTRO:2] "Requirements for Internet Gateways," R. Braden and J. Postel, RFC 1009, June 1987.
  3. [INTRO:3] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985.
  4. [INTRO:4] "Official Internet Protocols," J. Reynolds and J. Postel, RFC 1011, May 1987.
  5. [INTRO:5] "Protocol Document Order Information," O. Jacobsen and J. Postel, RFC 980, March 1986.
  6. [INTRO:6] "Assigned Numbers," J. Reynolds and J. Postel, RFC 1010, May 1987.
  7. [INTRO:7] "Modularity and Efficiency in Protocol Implementations," D. Clark, RFC 817, July 1982.
  8. [INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM SOSP, Orcas Island, Washington, December 1985.
  9. [INTRO:9] "A Protocol for Packet Network Intercommunication," V. Cerf and R. Kahn, IEEE Transactions on Communication, May 1974.
  10. [INTRO:10] "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D. Cohen, Computer Networks, Vol. 5, No. 4, July 1981.
  11. [INTRO:11] "The DARPA Internet Protocol Suite," B. Leiner, J. Postel, R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC, March 1985.
  12. [INTRO:12] "Final Text of DIS8473, Protocol for Providing the Connectionless Mode Network Service," ANSI, March 1986.
  13. [INTRO:13] "End System to Intermediate System Routing Exchange Protocol," ANSI X3S3.3, April 1986.
  14. [LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC 893, April 1984.
  15. [LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC 826, November 1982.
  16. [LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet Networks," C. Hornig, RFC 894, April 1984
  17. [LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks," J. Postel and J. Reynolds, RFC 1042, February 1988.
  18. [IP:1] "Internet Protocol (IP)," J. Postel, RFC 791, September 1981
  19. [IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC 792, September 1981
  20. [IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel, RFC 950, August 1985
  21. [IP:4] "Host Extensions for IP Multicasting," S. Deering, RFC 1112, August 1989
  22. [IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department of Defense, August 1983.
  23. [IP:6] "Some Problems with the Specification of the Military Standard Internet Protocol," D. Sidhu, RFC 963, November 1985.
  24. [IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel, RFC 879, November 1983.
  25. [IP:8] "Internet Protocol Security Options," B. Schofield, RFC 1108, October 1989.
  26. [IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM SIGCOMM-87, August 1987. Published as ACM Comp Comm Review, Vol. 17, no. 5.
  27. [IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC 815, July 1982.
  28. [IP:11] "Fault Isolation and Recovery," D. Clark, RFC 816, July 1982.
  29. [IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J. Mogul, RFC 922, October 1984.
  30. [IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC 814, July 1982.
  31. [IP:14] "Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQUID)," W. Prue and J. Postel, RFC 1016, July 1987.
  32. [UDP:1] "User Datagram Protocol," J. Postel, RFC 768, August 1980
  33. [TCP:1] "Transmission Control Protocol," J. Postel, RFC 793, September 1981
  34. [TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of Defense, August 1984.
  35. [TCP:3] "Some Problems with the Specification of the Military Standard Transmission Control Protocol," D. Sidhu and T. Blumer, RFC 964, November 1985.
  36. [TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel, RFC 879, November 1983.
  37. [TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC 813, July 1982.
  38. [TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM SIGCOMM-87, August 1987.
  39. [TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88, August 1988.
  40. [TCP:8] "Modularity and Efficiency in Protocol Implementation," D. Clark, RFC 817, July 1982.
  41. [TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC 896, January 1984.
  42. [TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C. Partridge, RFC 1071, September 1988
  43. [TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden, RFC 1072, October 1988.

Вопросы безопасности

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

Архитектура Internet в общем случае обеспечивает весьма слабую защиту против подстановки (spoofing) IP-адресов отправителя, поэтому любой механизм обеспечения безопасности на основе IP-адресов отправителей должен применяться с осторожностью. Однако, в ограниченной среде некоторая проверка адресов отправителей становится вполне возможной. Например, можно создать безопасную ЛВС, входной маршрутизатор которой будет отбрасывать любые дейтаграммы, в которых в качестве отправителя указан внутренний адрес локальной сети. В этом случае хост ЛВС может различать внешние и внутренние хосты по адресу отправителя. Проблема усложняется при задании маршрута отправителем (source routing) и существуют предложения запретить хостам рассылку дейтаграмм 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: ude.isi@nedarb

Перевод на русский язык

Николай Малых, moc.milib@hkylamn