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

Протокол управляющих сообщений Интернета
Протокол связи
	Общий заголовок для ICMPv4.
Цель	Вспомогательный протокол для IPv4
Разработчик(и)	ДАРПА
Введение	1981
Уровень OSI	Сетевой уровень
RFC(ы)	RFC 792

Протокол управляющих сообщений Интернета ( ICMP ) является вспомогательным протоколом в наборе протоколов Интернета . Он используется сетевыми устройствами , включая маршрутизаторы , для отправки сообщений об ошибках и оперативной информации, указывающей на успех или неудачу связи с другим IP-адресом . Например, ошибка отображается, когда запрошенная услуга недоступна или что хост или маршрутизатор не могут быть достигнуты. ^[2] ICMP отличается от транспортных протоколов, таких как TCP и UDP, тем, что он обычно не используется для обмена данными между системами и не используется регулярно сетевыми приложениями конечных пользователей (за исключением некоторых диагностических инструментов, таких как ping и трассировка ).

ICMP для IPv4 определен в РФК 792 . отдельный ICMPv6 используется С IPv6 , определенный в RFC 4443 .

Технические детали

ICMP является частью набора интернет-протоколов, как определено в RFC 792. Сообщения ICMP обычно используются в целях диагностики или управления или генерируются в ответ на ошибки в IP операциях (как указано в RFC 1122). Ошибки ICMP направляются на исходный IP-адрес исходного пакета. ^[2]

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

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

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

ICMP — протокол сетевого уровня ; это делает его протоколом уровня 3 в семиуровневой модели OSI . Основанный на четырехуровневой модели TCP/IP, ICMP представляет собой протокол интернет-уровня , что делает его протоколом уровня 2 в четырехуровневой модели Интернет-стандарта RFC 1122 TCP/IP или протоколом уровня 3 в современной пятиуровневой модели. Определения протоколов TCP/IP (Козерок, Комер, Таненбаум, Форузан, Курозе, Столлингс). ^{[ нужна ссылка ]}

С пакетами ICMP не связан номер порта TCP или UDP, поскольку эти номера связаны с транспортным уровнем выше. ^[3]

Структура датаграммы

Пакет ICMP инкапсулируется в пакет IPv4. ^[2] Пакет состоит из разделов заголовка и данных.

Заголовок ICMP начинается после заголовка IPv4 и идентифицируется протокола номером 1 . ^[4] Все пакеты ICMP имеют восьмибайтовый заголовок и раздел данных переменного размера. Первые четыре байта заголовка имеют фиксированный формат, а последние четыре байта зависят от типа и кода ICMP-пакета. ^[2]

Формат заголовка ICMP
Смещения	Октет	0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Тип								Код								Контрольная сумма
4	32	Остальная часть заголовка

Тип: Тип ICMP см. § Управляющие сообщения .
Код: Подтип ICMP, см. § Управляющие сообщения .
Контрольная сумма: Контрольная сумма Интернета (RFC 1071) для проверки ошибок, рассчитанная на основе заголовка ICMP и данных со значением 0, подставленным в это поле.
Остальная часть заголовка: Четырехбайтовое поле, содержимое которого зависит от типа и кода ICMP.

Данные

Сообщения об ошибках ICMP содержат раздел данных, включающий копию всего заголовка IPv4, а также по крайней мере первые восемь байтов данных из пакета IPv4, вызвавшего сообщение об ошибке. Длина сообщений об ошибках ICMP не должна превышать 576 байт. ^[5] Эти данные используются хостом для сопоставления сообщения соответствующему процессу. Если протокол более высокого уровня использует номера портов, предполагается, что они находятся в первых восьми байтах данных исходной дейтаграммы. ^[6]

переменный размер раздела пакетных данных ICMP Был использован . В « Пинге смерти » большие или фрагментированные пакеты ICMP используются для атак типа «отказ в обслуживании» . Данные ICMP также можно использовать для создания скрытых каналов связи. Эти каналы известны как туннели ICMP .

Управляющие сообщения

Управляющие сообщения идентифицируются по значению в поле типа . Поле кода предоставляет дополнительную контекстную информацию для сообщения. Некоторые управляющие сообщения устарели с момента первого появления протокола.

Известные управляющие сообщения ^[7]^[8]
Тип	Код	Статус	Описание
0 – Эхо-ответ ^[6]^: 14	0		Эхо-ответ (используется для проверки связи )
1 и 2		неназначенный	Сдержанный
3 – Пункт назначения недоступен ^[6]^: 4^[9]	0		Сеть назначения недоступна
	1		Хост назначения недоступен
	2		Протокол назначения недоступен
	3		Порт назначения недоступен
	4		Требуется фрагментация и флаг DF. установлен
	5		Исходный маршрут не удался
	6		Сеть назначения неизвестна
	7		Хост назначения неизвестен
	8		Исходный хост изолирован
	9		Сеть административно запрещена
	10		Хост административно запрещен
	11		Сеть недоступна для ToS
	12		Хост недоступен для ToS
	13		Общение административно запрещено
	14		Нарушение приоритета хоста
	15		Действует ограничение приоритета
4 – Закалка источника	0	~~устарел~~	Исходное гашение (контроль перегрузки)
5 – Сообщение перенаправления	0		Перенаправление датаграммы для сети
	1		Перенаправление датаграммы для хоста
	2		Перенаправление датаграммы для ToS и сети
	3		Перенаправление датаграммы для ToS и хоста
6		~~устарел~~	Альтернативный адрес хоста
7		неназначенный	Сдержанный
8 – Эхо-запрос	0		Эхо-запрос (используется для проверки связи)
9 – Реклама маршрутизатора	0		Реклама маршрутизатора
10 – Запрос маршрутизатора	0		Обнаружение/выбор/запрос маршрутизатора
11 – Время превышено ^[6]^: 6	0		Срок жизни истек в пути
11 – Время превышено ^[6]^: 6	1		Превышено время сборки фрагмента
12 – Проблема с параметром: неправильный IP-заголовок.	0		Указатель указывает на ошибку
	1		Отсутствует обязательная опция
	2		Плохая длина
13 – Временная метка	0		Временная метка
14 – Ответ с временной меткой	0		Ответ с временной меткой
15 – Запрос информации	0	~~устарел~~	Запрос информации
16 – Информационный ответ	0	~~устарел~~	Информация Ответ
17 – Запрос маски адреса	0	~~устарел~~	Запрос маски адреса
18 – Ответ по маске адреса	0	~~устарел~~	Ответ по маске адреса
19		сдержанный	Зарезервировано для безопасности
с 20 по 29		сдержанный	Зарезервировано для эксперимента по надежности
30 – Трассировка	0	~~устарел~~	Запрос информации
31		~~устарел~~	Ошибка преобразования датаграммы
32		~~устарел~~	Перенаправление мобильного хоста
33		~~устарел~~	Где вы (изначально предназначалось для IPv6 )
34		~~устарел~~	Here-I-Am (изначально предназначался для IPv6)
35		~~устарел~~	Запрос на мобильную регистрацию
36		~~устарел~~	Ответ на мобильную регистрацию
37		~~устарел~~	Запрос доменного имени
38		~~устарел~~	Ответ на доменное имя
39		~~устарел~~	Протокол обнаружения алгоритма SKIP, простое управление ключами для интернет-протокола
40			Photuris , Сбои в системе безопасности
41		Экспериментальный	ICMP для экспериментальных протоколов мобильности, таких как Seamoby [RFC4065]
42 – Расширенный эхо-запрос ^[10]	0		Запросить расширенное эхо (XPing — см. Расширенный пинг (Xping) )
43 – Расширенный эхо-ответ ^[10]	0		Нет ошибки
	1		Неверный запрос
	2		Нет такого интерфейса
	3		Нет такой записи в таблице
	4		Несколько интерфейсов удовлетворяют запросу
с 44 по 252		неназначенный	Сдержанный
253		Экспериментальный	Эксперимент 1 в стиле RFC3692 (RFC 4727)
254		Экспериментальный	Эксперимент 2 в стиле RFC3692 (RFC 4727)
255		сдержанный	Сдержанный

Источник закалки

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

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

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

Поскольку исследования показали, что «ICMP Source Quench [был] неэффективным (и несправедливым) противоядием от перегрузки», ^[11] Создание маршрутизаторами сообщений подавления источника было объявлено устаревшим в 1995 году в RFC 1812. Кроме того, пересылка и любая реакция на (действия по управлению потоком) сообщения подавления источника были объявлены устаревшими с 2012 года в RFC 6633.

Исходное сообщение о гашении ^[6]^: 9
00	08	16
Тип = 4	Код = 0	Контрольная сумма
неиспользованный
IP-заголовок и первые 8 байтов данных исходной дейтаграммы.

Где:

Тип должен быть установлен на 4.

Код должен быть установлен на 0

IP-заголовок и дополнительные данные используются отправителем для сопоставления ответа с соответствующим запросом.

Перенаправление

Перенаправление требует отправки пакетов данных по альтернативному маршруту. ICMP Redirect — это механизм, позволяющий маршрутизаторам передавать информацию о маршрутизации хостам. Сообщение сообщает хосту о необходимости обновить информацию о маршрутизации (отправить пакеты по альтернативному маршруту). Если хост пытается отправить данные через маршрутизатор (R1), а R1 отправляет данные на другой маршрутизатор (R2) и доступен прямой путь от хоста до R2 (то есть хост и R2 находятся в одной подсети ), затем R1 отправит сообщение перенаправления, чтобы сообщить хосту, что лучший маршрут для пункта назначения — через R2. Затем хост должен изменить информацию о своем маршруте и отправить пакеты для этого места назначения непосредственно на R2. Маршрутизатор по-прежнему отправит исходную дейтаграмму в назначенный пункт назначения. ^[12] Однако если дейтаграмма содержит информацию о маршрутизации, это сообщение не будет отправлено, даже если доступен лучший маршрут. В RFC 1122 указано, что перенаправления должны отправляться только шлюзами и не должны отправляться хостами Интернета.

Перенаправление сообщения ^[6]^: 11
00	08	16
Тип = 5	Код	Контрольная сумма
IP-адрес
IP-заголовок и первые 8 байтов данных исходной дейтаграммы.

Где:

Тип должен быть установлен на 5.

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

Код	Описание
0	Перенаправление для сети
1	Перенаправление для хоста
2	Перенаправление для типа службы и сети
3	Перенаправление для типа службы и хоста

IP-адрес — это 32-битный адрес шлюза, на который должно быть отправлено перенаправление.

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

Время превышено

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

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

Сообщение о превышении времени ^[6]^: 5
00	08	16
Тип = 11	Код	Контрольная сумма
неиспользованный
IP-заголовок и первые 8 байтов данных исходной дейтаграммы.

Где:

Тип должен быть установлен на 11.

Код указывает причину сообщения о превышении времени , включая следующее:

Код	Описание
0	Превышено время жизни при транспортировке.
1	Превышено время сборки фрагмента.

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

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

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

Сообщение с временной меткой ^[6]^: 15
00	08	16
Тип = 13	Код = 0	Контрольная сумма
Идентификатор		Порядковый номер
происхождения Отметка времени
Получить временную метку
передачи Временная метка

Где:

Тип должен быть установлен на 13.

Код должен быть установлен на 0

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

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

Ответ с временной меткой

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

Ответное сообщение с меткой времени ^[6]^: 15
00	08	16
Тип = 14	Код = 0	Контрольная сумма
Идентификатор		Порядковый номер
происхождения Отметка времени
Получить временную метку
передачи Временная метка

Где:

Тип должен быть установлен на 14.

Код должен быть установлен на 0

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

Временная метка отправителя — это время, когда отправитель последний раз касался сообщения перед его отправкой.

Временная метка получения — это время, когда эхо-устройство впервые коснулось его при получении.

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

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

Использование сообщений Timestamp и Timestamp Reply для синхронизации часов интернет-узлов в значительной степени было заменено протоколом сетевого времени на основе UDP и протоколом точного времени . ^[13]

Запрос маски адреса

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

Получатели должны ответить на это сообщение ответным сообщением по маске адреса .

Запрос маски адреса
00	08	16
Тип = 17	Код = 0	Контрольная сумма
Идентификатор		Порядковый номер
Маска адреса

Где:

Тип должен быть установлен на 17.

Код должен быть установлен на 0

Маску адреса можно установить на 0.

Запрос маски адреса ICMP может использоваться как часть разведывательной атаки для сбора информации о целевой сети, поэтому ответ по маске адреса ICMP по умолчанию отключен в Cisco IOS. ^[14]

Ответ по маске адреса

Ответ по маске адреса используется для ответа на сообщение с запросом маски адреса с использованием соответствующей маски подсети.

Ответ по маске адреса
00	08	16
Тип = 18	Код = 0	Контрольная сумма
Идентификатор		Порядковый номер
Маска адреса

Где:

Тип должен быть установлен на 18.

Код должен быть установлен на 0

Маска адреса должна быть равна маске подсети.

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

Пункт назначения недоступен, генерируется хостом или его входным шлюзом. ^[6] сообщить клиенту, что пункт назначения по какой-либо причине недоступен. Причинами появления этого сообщения могут быть: физическое соединение с хостом не существует (расстояние бесконечно); указанный протокол или порт не активен; данные должны быть фрагментированы, но флаг «не фрагментировать» включен. Недоступные порты TCP отвечают, в частности, TCP RST, а не недоступным пунктом назначения типа 3, как можно было бы ожидать. О недоступности пункта назначения никогда не сообщается при многоадресной IP- передаче.

Сообщение о недостижимости пункта назначения ^[6]^: 3
00	08	16
Тип = 3	Код	Контрольная сумма
неиспользованный		MTU следующего перехода
IP-заголовок и первые 8 байтов данных исходной дейтаграммы.

Где:

Поле типа (биты 0–7) должно быть установлено на 3.

Поле кода (биты 8–15) используется для указания типа ошибки и может быть любым из следующих:

Код	Описание
0	Ошибка недоступности сети.
1	Ошибка недоступности хоста.
2	Ошибка недостижимости протокола (назначенный транспортный протокол не поддерживается).
3	Ошибка недостижимости порта (назначенный протокол не может сообщить хосту о входящем сообщении).
4	Датаграмма слишком велика. Требуется фрагментация пакетов, но флаг «не фрагментировать» (DF) включен.
5	Ошибка исходного маршрута.
6	Неизвестная ошибка сети назначения.
7	Неизвестная ошибка хоста назначения.
8	Изолированная ошибка исходного хоста.
9	Сеть назначения запрещена административно.
10	Хост назначения запрещен административно.
11	Сеть недоступна для данного типа услуги.
12	Хост недоступен для данного типа услуги.
13	Связь запрещена административно (административная фильтрация предотвращает пересылку пакетов).
14	Нарушение приоритета хоста (означает, что запрошенный приоритет не разрешен для комбинации хоста или сети и порта).
15	Действует ограничение приоритета (приоритет дейтаграммы ниже уровня, установленного сетевыми администраторами).

Поле MTU следующего перехода (биты 48–63) содержит MTU сети следующего перехода в случае возникновения ошибки с кодом 4. ^[15]

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

См. также

Ссылки

^ Ф. Бейкер (июнь 1995 г.). Бейкер, Ф. (ред.). Требования к маршрутизаторам IP версии 4 . п. 52. РФК 1812 .
^ Перейти обратно: ^а ^б ^с ^д Форузан, Бехруз А. (2007). Передача данных и сети (Четвертое изд.). Бостон: МакГроу-Хилл. стр. 621–630 . ISBN 978-0-07-296775-3 .
^ «Определение семи уровней модели OSI и объяснение функций» . Поддержка Майкрософт . Проверено 28 декабря 2014 г.
^ «Номера протоколов» . Управление по присвоению номеров в Интернете . Проверено 23 июня 2011 г.
^ Требования к маршрутизаторам IP версии 4 . дои : 10.17487/RFC1812 . РФК 1812 .
^ Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к Постел, Дж. (сентябрь 1981 г.). Протокол управляющих сообщений Интернета . IETF . дои : 10.17487/RFC0792 . РФК 792 .
^ «Параметры ICMP IANA» . Яна.орг. 21 сентября 2012 г. Проверено 7 января 2013 г.
^ Куросе, Дж. Ф.; Росс, К.В. (2006). Компьютерные сети: нисходящий подход . Всемирная студенческая серия. Аддисон-Уэсли. ISBN 9780321418494 .
^ «Параметры протокола управляющих сообщений Интернета (ICMP)» . www.iana.org . Проверено 13 сентября 2023 г.
^ Перейти обратно: ^а ^б PROBE: Утилита для проверки интерфейсов . дои : 10.17487/RFC8335 . RFC 8335 .
^ RFC 6633
^ «Когда отправляются перенаправления ICMP?» . Сиско Системы . 28 июня 2008 г. Проверено 15 августа 2013 г.
^ Д. Л. Миллс (сентябрь 1985 г.). Протокол сетевого времени (NTP) . дои : 10.17487/RFC0958 . РФК 958 . Он создан на основе протокола времени и сообщения временной метки ICMP и является подходящей заменой для обоих.
^ «Справочник по IP-командам Cisco IOS, том 1 из 4: Адресация и службы, выпуск 12.3 — Команды IP-адресации и служб: ip-маска-ответ через ip web-cache» . Сиско Системы . Архивировано из оригинала 02 января 2013 г. Проверено 7 января 2013 г.
^ Расширенный протокол ICMP для поддержки сообщений, состоящих из нескольких частей . дои : 10.17487/RFC4884 . РФК 4884 .

Источники

RFC

RFC 792 , Протокол управляющих сообщений Интернета
RFC 950 , Стандартная процедура создания подсетей Интернета
RFC 1016 , Что-то, что хост может сделать с подавлением источника: задержка, вызванная подавлением источника (SQuID)
RFC 1122 , Требования к интернет-хостам – коммуникационные уровни
RFC 1716 , Требования к IP-маршрутизаторам
RFC 1812 , Требования к маршрутизаторам IP версии 4
RFC 4884 , расширенный ICMP для поддержки многочастных сообщений.

Внешние ссылки

Параметры ICMP IANA
Номера протоколов IANA
Объяснение поведения перенаправления ICMP на Wayback Machine (архивировано 10 января 2015 г.)

[RFC-1] Ф. Бейкер (июнь 1995 г.). Бейкер, Ф. (ред.). Требования к маршрутизаторам IP версии 4 . п. 52. РФК 1812 .

[Forouzan-2] Перейти обратно: ^а ^б ^с ^д Форузан, Бехруз А. (2007). Передача данных и сети (Четвертое изд.). Бостон: МакГроу-Хилл. стр. 621–630 . ISBN 978-0-07-296775-3 .

[3] «Определение семи уровней модели OSI и объяснение функций» . Поддержка Майкрософт . Проверено 28 декабря 2014 г.

[4] «Номера протоколов» . Управление по присвоению номеров в Интернете . Проверено 23 июня 2011 г.

[5] Требования к маршрутизаторам IP версии 4 . дои : 10.17487/RFC1812 . РФК 1812 .

[rfc792-6] Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к Постел, Дж. (сентябрь 1981 г.). Протокол управляющих сообщений Интернета . IETF . дои : 10.17487/RFC0792 . РФК 792 .

[7] «Параметры ICMP IANA» . Яна.орг. 21 сентября 2012 г. Проверено 7 января 2013 г.

[8] Куросе, Дж. Ф.; Росс, К.В. (2006). Компьютерные сети: нисходящий подход . Всемирная студенческая серия. Аддисон-Уэсли. ISBN 9780321418494 .

[9] «Параметры протокола управляющих сообщений Интернета (ICMP)» . www.iana.org . Проверено 13 сентября 2023 г.

[RFC_8335-10] Перейти обратно: ^а ^б PROBE: Утилита для проверки интерфейсов . дои : 10.17487/RFC8335 . RFC 8335 .

[11] RFC 6633

[12] «Когда отправляются перенаправления ICMP?» . Сиско Системы . 28 июня 2008 г. Проверено 15 августа 2013 г.

[13] Д. Л. Миллс (сентябрь 1985 г.). Протокол сетевого времени (NTP) . дои : 10.17487/RFC0958 . РФК 958 . Он создан на основе протокола времени и сообщения временной метки ICMP и является подходящей заменой для обоих.

[14] «Справочник по IP-командам Cisco IOS, том 1 из 4: Адресация и службы, выпуск 12.3 — Команды IP-адресации и служб: ip-маска-ответ через ip web-cache» . Сиско Системы . Архивировано из оригинала 02 января 2013 г. Проверено 7 января 2013 г.

[15] Расширенный протокол ICMP для поддержки сообщений, состоящих из нескольких частей . дои : 10.17487/RFC4884 . РФК 4884 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]