RFC 2463 — Протокол передачи управляющих сообщений (ICMPv6) для 6-ой версии IP-протокола (IPv6)

Оглавление

• 1. Предисловие
• 2. Общие положения
• 2.1. Общий формат сообщений
• 2.2. Определение адреса источника сообщения
• 2.3. Вычисление проверочной суммы сообщения
• 2.4. Правила обработки сообщений
• 3. ICMPv6-сообщения об ошибках
• 3.1. Сообщение «Узел назначения не достижим»
• 3.2. Сообщение «Размер IP-пакета слишком большой»
• 3.3. Сообщение «Превышение времени»
• 3.4. Сообщение «Параметрическая проблема»
• 4. Информационные ICMPv6-сообщения
• 4.1. Сообщение «Эхо-пакет – запрос»
• 4.2. Сообщение «Эхо-пакет – ответ»
• 5. Вопросы безопасности
• 6. Аутентификация и шифрование ICMPv6-сообщений

1. Предисловие

Этот стандарт определяет протокол передачи управляющих сообщений (ICMP) для шестой версии IP-адресации (IPv6). ICMPv6 имеет собственное обозначение в поле «Следующий заголовок» в IP-заголовке IPv6: 58.

В этом стандарте представлена только логическая характеристика ICMPv6 и кратное описание порядка применения ICMPv6-сообщений.

2. Общие положения

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

2.1. Общий формат сообщений

ICMPv6-сообщения можно разделить на два класса:

1. сообщения об ошибках;
2. информационные сообщения.

Сообщения об ошибках отличаются тем, что в поле «Тип сообщения» старший бит имеет нулевое значение. Таким образом, сообщения об ошибках могут иметь в поле «Тип сообщения» значения 0…127, а информационные — 128…255.

В данном стандарте представлены следующие ICMPv6-сообщения:

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

  • «1» — узел назначения не достижим;
  • «2» — размер IP-пакета слишком большой;
  • «3» — превышение времени;

  • «4» — параметрическая проблема;

• Информационные сообщения:

  • «128» — запрашивающий эхо-пакет;
  • «129» — ответный эхо-пакет.

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

Замечание. Это значение отличается от того, которое используется в стандарте ICMPv4.

На рис.1 представлен общий формат ICMPv6-сообщений.

Поле «Тип ICMPv6-сообщения» указывает на тип ICMPv6-сообщения. Значение, содержащееся в этом поле, определяет формат следующих за этим полем данных.

Поле «Тип кодирования» зависит от типа ICMPv6-сообщения. Оно предназначено для создания дополнительного уровня структуры сообщения.

Поле «Проверочная сумма» используется для обнаружения искаженных данных в ICMPv6-сообщении и некоторых частях IPv6-заголовка.

2.2. Определение адреса источника сообщения

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

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

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

3. Если сообщение является ответом на сообщение, которое было передано по адресу, который не принадлежит данному IP-узлу (но было им получено), то тогда целесообразно, чтобы адрес источника был уникальным адресом этого IP-узла, который используется последним для диагностирования ошибок (то есть, наиболее приемлем для диагностирования ошибок). Например, если сообщение является ответом на IP-пакет, подлежащий дальнейшей ретрансляции, но которая не может быть успешно осуществлена, то тогда адрес источника в ответе должен быть уникальным адресом того интерфейса, на который поступил этот «бракованный» IP-пакет.

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

2.3. Вычисление проверочной суммы сообщения

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

Замечание. Включение «псевдозаголовка» в последовательность для вычисления проверочной суммы ICMPv6-сообщения является новшеством по сравнению с IPv4-стандартом.

Перед вычислением проверочной суммы само поле «Проверочная сумма» заполняется нулями.

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

3. ICMPv6-сообщения об ошибках

3.1. Сообщение «Узел назначения не достижим»

На рис.2 представлен формат сообщения «Узел назначения не достижим».

• Поле «Адрес получателя» IPv6-заголовка пакета:

  Он копируется из поля «Адрес отправителя» IPv6-заголовка принятого ошибочного пакета.

• Поле «Тип ICMPv6-сообщения» ICMPv6-сообщения:

  Это поле содержит значение «1».

• Поле «Тип кодирования» ICMPv6-сообщения:

  Это поле может содержать следующие значения:

  • «0» — маршрут для этого адреса получателя не известен;
  • «1» — связь с этим адресатом административно запрещена;
  • «2» — это значение не определено;
  • «3» — адрес назначения не достижим;
  • «4» — порт назначения не достижим.

• Поле «Не используется» ICMPv6-сообщения:

  Это поле не используется при всех значениях поля «Тип кодирования». Оно должно заполняться нулями отправителем и игнорироваться получателем.

Применение ICMPv6-сообщения «Узел назначения не достижим»:

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

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

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

Если причиной отказа от дальнейшей ретрансляции пакета является административный запрет (например, сетевой фильтр), то тогда в поле «Тип кодирования» устанавливается значение «1».

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

Целесообразно, чтобы IP-узел-получатель передавал ответное ICMPv6-сообщение «Узел назначения не достижим» со значением «4» в поле «Тип кодирования», если он получил пакет, для которого протокол транспортного уровня (например, UDP) не обнаружен, или если такой транспортный протокол не имеет других средств для информирования передающей стороны.

Уведомление протокола вышележащего уровня:

IP-узел, который получил ICMPv6-сообщение «Узел назначения не достижим», должен уведомить протокольный процесс вышележащего уровня.

3.2. Сообщение «Размер IP-пакета слишком большой»

На рис.3 представлен формат сообщения «Размер IP-пакета слишком большой».

• Поле «Адрес получателя» IPv6-заголовка пакета:

  Он копируется из поля «Адрес отправителя» IPv6-заголовка принятого ошибочного пакета.

• Поле «Тип ICMPv6-сообщения» ICMPv6-сообщения:

  Это поле содержит значение «2».

• Поле «Тип кодирования» ICMPv6-сообщения:

  Это поле содержит значение «0», которое устанавливает отправитель, а само поле игнорируется получателем.

• Поле «Максимальный разрешенный размер IP-пакета для передачи» ICMPv6-сообщения:

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

Применение ICMPv6-сообщения «Размер IP-пакета слишком большой»:

Это сообщение должно передаваться маршрутизатором в ответ на принятый IP-пакет, который имеет размер, превышающий максимальный разрешенный (для входного интерфейса конкретного канала связи) и поэтому не может ретранслироваться дальше. Информация в этом сообщении используется в процедуре определения маршрута, по которому можно передать IP-пакет наибольшего размера («Path MTU Discovery»).

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

Уведомление протокола вышележащего уровня:

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

3.3. Сообщение «Превышение времени»

На рис.4 представлен формат сообщения «Превышение времени».

• Поле «Адрес получателя» IPv6-заголовка пакета:

  Он копируется из поля «Адрес отправителя» IPv6-заголовка принятого ошибочного пакета.

• Поле «Тип ICMPv6-сообщения» ICMPv6-сообщения:

  Это поле содержит значение «3».

• Поле «Тип кодирования» ICMPv6-сообщения:

  Это поле может содержать следующие значения:

  • «0» — при доставке IP-пакета превышено разрешенное число ретрансляционных участков;

  • «1» — превышено время повторной сборки фрагментов.

• Поле «Не используется» ICMPv6-сообщения:

  Это поле не используется при всех значениях поля «Тип кодирования». Оно должно заполняться нулями отправителем и игнорироваться получателем.

Применение ICMPv6-сообщения «Превышение времени»:

Если маршрутизатор принял IP-пакет, в котором поле IP-заголовка «Максимальное число ретрансляционных участков» содержит значение ноль или сам маршрутизатор «обнуляет» это поле, то тогда он должен уничтожить этот принятый IP-пакет и передать ICMPv6-сообщение «Размер IP-пакета слишком большой» (со значением «0» в поле «Тип кодирования») источнику этого ошибочного IP-пакета. Это означает, что имел место «петлевой маршрут» или максимальное число ретрансляционных участков слишком мало.

Уведомление протокола вышележащего уровня:

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

3.4. Сообщение «Параметрическая проблема»

На рис.5 представлен формат сообщения «Параметрическая проблема».

• Поле «Адрес получателя» IPv6-заголовка пакета:

  Он копируется из поля «Адрес отправителя» IPv6-заголовка принятого ошибочного пакета.

• Поле «Тип ICMPv6-сообщения» ICMPv6-сообщения:

  Это поле содержит значение «4».

• Поле «Тип кодирования» ICMPv6-сообщения:

  Это поле может содержать следующие значения:

  • «0» — обнаружено ошибочное поле заголовка;

  • «1» — обнаружен неопределенный тип поля «Следующий заголовок»;

  • «2» — обнаружена неопределенная дополнительная IPv6-функция.

• Поле «Указатель» ICMPv6-сообщения:

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

Применение ICMPv6-сообщения «Параметрическая проблема»:

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

Указатель определяет октет оригинального заголовка пакета, где была вскрыта ошибка. Например, ICMPv6-сообщение «Параметрическая проблема» со значениями «4» в поле «Тип ICMPv6-сообщения», «1» в поле «Тип кодирования» и «40» в поле «Указатель» будет означать, что IPv6-заголовок расширения, следующий за IPv6-заголовком, оригинального пакета содержит неопределенное значение в поле «Следующий заголовок».

Уведомление протокола вышележащего уровня:

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

4. Информационные ICMPv6-сообщения

4.1. Сообщение «Эхо-пакет – запрос»

На рис.6 представлен формат сообщения «Эхо-пакет – запрос».

• Поле «Адрес получателя» IPv6-заголовка пакета:

  Любой допустимый IPv6-адрес.

• Поле «Тип ICMPv6-сообщения» ICMPv6-сообщения:

  Это поле содержит значение «128».

• Поле «Тип кодирования» ICMPv6-сообщения:

  Это поле содержит значение «0».

• Поле «Идентификатор» ICMPv6-сообщения:

  Это поле позволяет различать ICMPv6-сообщения «Эхо-пакет – запрос» и «Эхо-пакет – ответ». Это поле может заполняться нулями.

• Поле «Последовательный номер» ICMPv6-сообщения:

  Это поле позволяет различать ICMPv6-сообщения «Эхо-пакет – запрос» и «Эхо-пакет – ответ». Это поле может заполняться нулями.

• Поле «Данные» ICMPv6-сообщения:

  Это поле содержит произвольные данные (любое число октетов, включая ноль октетов).

Применение ICMPv6-сообщения «Превышение времени»:

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

Уведомление протокола вышележащего уровня:

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

4.2. Сообщение «Эхо-пакет – ответ»

На рис.7 представлен формат сообщения «Эхо-пакет – ответ».

• Поле «Адрес получателя» IPv6-заголовка пакета:

  Он копируется из поля «Адрес отправителя» IPv6-заголовка принятого пакета «Эхо-пакет – запрос».

• Поле «Тип ICMPv6-сообщения» ICMPv6-сообщения:

  Это поле содержит значение «129».

• Поле «Тип кодирования» ICMPv6-сообщения:

  Это поле содержит значение «0».

• Поле «Идентификатор» ICMPv6-сообщения:

  Это поле копируется из ICMPv6-сообщения «Эхо-пакет – запрос».

• Поле «Последовательный номер» ICMPv6-сообщения:

  Это поле копируется из ICMPv6-сообщения «Эхо-пакет – запрос».

• Поле «Данные» ICMPv6-сообщения:

  Это поле содержит данные из ICMPv6-сообщения «Эхо-пакет – запрос».

Применение ICMPv6-сообщения «Превышение времени»:

Каждый IPv6-узел должен выполнять функцию ответов на «Эхо-пакеты – запросы» путем передачи «Эхо-пакетов – ответов». Также целесообразно, чтобы IPv6-узлы имели специализированный прикладной интерфейс для передачи «Эхо-пакетов – запросов» и приема «Эхо-пакетов – ответов» (в диагностических целях). Адрес источника в «Эхо-пакете – ответе», направленном в ответ на «Эхо-пакет – запрос» с уникальным адресом, должен быть таким же как и адрес получателя в принятом «Эхо-пакете – запросе».

Целесообразно, чтобы «Эхо-пакет – ответ» направлялся в ответ на принятый «Эхо-пакет – запрос», который содержал групповой адрес. В этом случае адрес источника в «Эхо-пакете – ответе» должен быть адрес интерфейса на который поступил «Эхо-пакет – запрос» с групповым адресом (то есть адрес того интерфейса, который «обслуживает» пакеты с групповыми адресами).

Поле «Данные» в принятом «Эхо-пакете – запросе» должно передаваться полностью и без каких-либо изменений в ответном ICMPv6-сообщении «Эхо-пакет – ответ».

Уведомление протокола вышележащего уровня:

IP-узел, который получил ICMPv6-сообщение «Эхо-пакет – ответ», должен передать его протокольному процессу, который был источником «Эхо-пакета – запроса». Оно также может быть передано протокольному процессу, который не был источником «Эхо-пакета – запроса».

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

5.1. Аутентификация и шифрование ICMPv6-сообщений

Информационный обмен ICMPv6-сообщениями может быть аутентифицирован с использованием IPsec АН-протокола (заголовка аутентификации). Целесообразно, чтобы IPv6-узел включал АН-заголовок в передаваемые им ICMPv6-сообщения, если защищенное виртуальное соединение (SA) на основе применения АН-протокола имеет такой же адрес назначения как и в ICMPv6-сообщениях. SA могут быть сформированы с помощью «ручной» процедуры настройки или с помощью какого-либо протокола управления SA и обменом ключевой информации.

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

Целесообразно, чтобы системный администратор имел возможность настройки IP-узла таким образом, чтобы последний игнорировал любые ICMPv6-сообщения, которые не аутентифицированы с помощью АН-протокола или ESP-протокола. Целесообразно, чтобы такой коммутатор (IP-узел) не обрабатывал сообщения, которые не прошли аутентификацию.

Более подробно вопросы безопасности рассмотрены в IPsec-стандартах.

5.2. Атаки на ICMP-протокол

ICMP-сообщения могут быть объектами самых различных атак:

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

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

3. ICMP-сообщения могут быть объектами таких противоправных действий, при которых изменяются отдельные поля сообщений или поля полезной нагрузки. Защита ICMP-сообщения от такого рода действий осуществляется с помощью алгоритмов аутентификации или шифрования.

4. ICMP-сообщения могут использоваться для организации атаки «Отказ в обслуживании» путем передачи один за другим ошибочных IP-пакетов.

6. Ссылки

[IPv6]	S. Deering и R. Hinden, «Спецификация IPv6», RFC 2460, Декабрь 1998.
[IPv6-ADDR]	Hinden, R. и S. Deering, «IP Version 6 Addressing Architecture», RFC 2373, июль 1998.
[IPv6-DISC]	Narten, T., Nordmark, E. и W. Simpson, «Neighbor Discovery for IP Version 6 (IPv6)», RFC 2461, декабрь 1998.
[RFC-792]	J. Postel, «Протокол ICMP», RFC 792, Сентябрь 1981.
[RFC-1122]	Robert Braden, «Требования к хостам Internet - Коммуникационные уровни», RFC 1122, Октябрь 1989.
[PMTU]	McCann, J., Deering, S. и J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, август 1996.
[RFC-2119]	Scott Bradner, «Ключевые слова для обозначения уровня требований в RFC», RFC 2119, Март 1997.
[IPv6-SA]	Kent, S. и R. Atkinson, «Security Architecture for the Internet Protocol», RFC 2401, ноябрь 1998.
[IPv6-Auth]	Kent, S. и R. Atkinson, «IP Authentication Header», RFC 2402, ноябрь 1998.
[IPv6-ESP]	Kent, S. и R. Atkinson, «IP Encapsulating Security Protocol (ESP)», RFC 2406, ноябрь 1998.

7. Благодарности

The document is derived from previous ICMP drafts of the SIPP and IPng working group.

The IPng working group and particularly Robert Elz, Jim Bound, Bill Simpson, Thomas Narten, Charlie Lynn, Bill Fink, Scott Bradner, Dimitri Haskin, and Bob Hinden (in chronological order) provided extensive review information and feedback.