RFC: 1122
Оригинал: Requirements for Internet Hosts - Communication Layers
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых

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

3.1 Введение

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

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

  • [RFC791]
  • определяет протокол IP и содержит введение в архитектуру Internet.
  • [RFC792]
  • определяет протокол ICMP, обеспечивающий диагностику и сообщения об ошибках для протокола IP. Хотя сообщения ICMP инкапсулируются в дейтаграммы IP, обработка ICMP рассматривается (и обычно реализована) как часть уровня IP. См. параграф 3.2.2.
  • [RFC950]
  • определяет обязательную поддержку подсетей для архитектуры адресации.
  • [RFC1112]
  • определяет протокол IGMP (Internet Group Management Protocol — протокол управления группами Internet) как часть рекомендуемого расширения для хостов и интерфейсов хост-шлюз, обеспечивающего в масштабах Internet поддержку групповой адресации на уровне IP. См. параграф 3.2.3.

    Адресатами групповых (multicast) пакетов IP могут быть произвольные группы хостов Internet. Групповая адресация IP разработана как естественное расширение групповой адресации на канальном уровне и обеспечивает стандартное толкование для локального доступа к multicasting-объектам.

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

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

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

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

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

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

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

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

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

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

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

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

  • Обсуждение:
  • Тихое отбрасывание ошибочных дейтаграмм в общем случае используется для предотвращения широковещательных штормов (broadcast storms).
2007 - 2017 © Русские переводы RFC, IETF, ISOC.