RFC: 2463
Оригинал: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
Другие версии: RFC 1885, RFC 4443
Категория: Проект стандарта
Дата публикации:
Авторы: ,
Перевод: Мельников Дмитрий Анатольевич

RFC 2463, Страница 4 из 12

2.4. Правила обработки сообщений

Прикладные программные ICMPv6-модули должны выполнять следующие требования при обработке ICMPv6-сообщений (RFC 1122):

  1. Если принято ICMPv6-сообщение об ошибке неизвестного типа, то тогда необходимо его передать на более высокий уровень Internet-архитектуры.

  2. Если принято информационное ICMPv6-сообщение неизвестного типа, то тогда необходимо его «молча» уничтожить.

  3. Каждое ICMPv6-сообщение об ошибке (тип сообщения <128) содержит такую часть «бракованного» IPv6-пакета (пакета, содержащего ошибку), которая не превышает максимальный допустимый размер передаваемого IPv6-пакета.

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

  5. Не допускается передача ICMPv6-сообщения об ошибке в результате приема:

    1. ICMPv6-сообщения об ошибке;

    2. IPv6-пакета с групповым адресом (тогда существуют два исключения из этих правил:

      • сообщение о слишком большом пакете позволяет определить маршрут передачи IPv6-пакета с групповым адресом;

      • сообщение о параметрической проблеме, значение «2» в поле «Тип кодирования» указывает на не известный тип дополнительной IPv6-функции, поле которой («Тип дополнительной функции») содержит два старших бита «10»);

    3. Пакета, который был передан с групповым адресом, но в интересах протокола канального уровня (порядок действий определен в п.5.2).

    4. Пакета, который был передан с широковещательным адресом, но в интересах протокола канального уровня (порядок действий определен в п.5.2).

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

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

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

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

    Параметры ограничения (например, «Т» и «F» из приведенных выше примеров) должны быть обязательно установлены в каждом IP-узле, причем должен быть предусмотрен «режим по умолчанию» (например, «Т=1сек», «нет=0сек» или «F=2%», «нет=0%»).

Страница 4 из 12

2007 - 2022 © Русские переводы RFC, IETF, ISOC.