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

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

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

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

Набор интернет-протоколов
Уровень приложения
BGP DHCP DNS FTP HTTP HTTPS IMAP LDAP MGCP MQTT NNTP NTP Поп PTP ONC / RPC RTP RTSP РВАТЬ ГЛОТОК SMTP SNMP SSH Telnet TLS / SSL XMPP более...
Транспортный уровень
TCP UDP DCCP SCTP Просьба ответить более...
Интернет-уровень
IP IPv4 IPv6 ICMP ICMPv6 ECN IGMP IPsec более...
Связующий слой
ARP Пнр OSPF Туннели L2TP PPP MAC Ethernet Вай фай DSL ISDN FDDI более...
v т е

Технические детали [ править ]

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

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

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

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

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

Структура дейтаграммы [ править ]

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

Заголовок [ править ]

Заголовок ICMP начинается после заголовка IPv4 и идентифицируется номером протокола IP «1». ^[4] Все пакеты ICMP имеют 8-байтовый заголовок и раздел данных переменного размера. Первые 4 байта заголовка имеют фиксированный формат, а последние 4 байта зависят от типа / кода этого пакета 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}	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		Срок действия TTL истек при передаче
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 - Traceroute	0	~~устарел~~	Запрос информации
31 год		~~устарел~~	Ошибка преобразования дейтаграммы
32		~~устарел~~	Перенаправление мобильного хоста
33		~~устарел~~	Where-Are-You (изначально предназначался для IPv6 )
34		~~устарел~~	Here-I-Am (изначально предназначался для IPv6)
35 год		~~устарел~~	Запрос мобильной регистрации
36		~~устарел~~	Ответ на мобильную регистрацию
37		~~устарел~~	Запрос доменного имени
38		~~устарел~~	Ответ доменного имени
39		~~устарел~~	Протокол обнаружения алгоритмов SKIP, простое управление ключами для интернет-протокола
40			Photuris , Сбои в безопасности
41 год		Экспериментальный	ICMP для протоколов экспериментальной мобильности, таких как Seamoby [RFC4065]
42 - Расширенный запрос эхо ^[9]	0		Запросить расширенное эхо (XPing - см. Расширенный эхо-запрос (Xping) )
43 - Расширенный эхо-ответ ^[9]	0		Нет ошибок
	1		Неверный запрос
	2		Нет такого интерфейса
	3		Нет такой записи в таблице
	4		Множественные интерфейсы удовлетворяют запрос
С 44 по 252		неназначенный	Зарезервированный
253		Экспериментальный	Эксперимент 1 в стиле RFC3692 (RFC 4727)
254		Экспериментальный	RFC3692 эксперимент 2 (RFC 4727)
255		зарезервированный	Зарезервированный

Погашение источника [ править ]

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

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

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

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

Где:

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

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

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

Перенаправить [ править ]

Пример того, как работает сообщение перенаправления ICMPv4

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

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

Где:

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

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

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

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

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

Время истекло [ править ]

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

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

Сообщение «Превышено время» ^[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 . Она состоит из инициирующей временной метки , посланного отправителем Timestamp , а также отметки времени приема , указывающее , когда Отметка была получена , и передача с указанием временной метки , когда ответ Отметки был послан.

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

Где:

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

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

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

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

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

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

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

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

Запрос маски адреса [ править ]

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

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

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

Где:

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

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

Адресная маска может быть установлена на 0

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

Ответ маски адреса [ править ]

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

Ответ по адресной маске
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. ^[14]

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

См. Также [ править ]

ICMP туннель
Пробивка отверстий ICMP
Протокол обнаружения маршрутизатора ICMP
ПМТУ черная дыра
Pathping
Обнаружение MTU пути
Смурф атака

Ссылки [ править ]

↑ F. Baker (июнь 1995 г.). Бейкер, Ф (ред.). «RFC 1812, Требования к маршрутизаторам IP версии 4» : 52. doi : 10.17487 / RFC1812 . Цитировать журнал требует |journal=( помощь )
^ a b c d Форузан, Бехруз А. (2007). Передача данных и сети (Четвертое изд.). Бостон: Макгроу-Хилл. стр. 621 -630. ISBN 978-0-07-296775-3.
^ «Семь уровней модели OSI, определенные и объясненные функции» . Служба поддержки Microsoft . Проверено 28 декабря 2014 .
^ "Номера протоколов" . Управление по присвоению номеров в Интернете . Проверено 23 июня 2011 .
^ Требования к маршрутизаторам IP версии 4 . DOI : 10,17487 / RFC1812 . RFC 1812 .
^ a b c d e f g h i j k Postel, J. (сентябрь 1981 г.). Протокол управляющих сообщений Интернета . IETF . DOI : 10,17487 / RFC0792 . RFC 792 .
^ «Параметры IANA ICMP» . Iana.org. 2012-09-21 . Проверено 7 января 2013 .
^ Kurose, JF; Росс, KW (2006). Компьютерные сети: подход сверху вниз . Всемирная студенческая серия. Эддисон-Уэсли. ISBN 9780321418494.
^ a b PROBE: Утилита для проверки интерфейсов . DOI : 10,17487 / RFC8335 . RFC 8335 .
^ RFC 6633
^ "Когда отправляются перенаправления ICMP?" . Cisco Systems . 2008-06-28 . Проверено 15 августа 2013 .
↑ DL Mills (сентябрь 1985 г.). Сетевой протокол времени (NTP) . DOI : 10,17487 / RFC0958 . RFC 958 . Он произошел от протокола времени и сообщения отметки времени ICMP и является подходящей заменой для обоих.
^ «Справочник по IP-командам Cisco IOS, том 1 из 4: Адресация и службы, выпуск 12.3 - IP-адресация и команды служб: IP-маска-ответ через IP-кэш» . Cisco Systems . Архивировано из оригинала на 2013-01-02 . Проверено 7 января 2013 .
^ Расширенный ICMP для поддержки сообщений, состоящих из нескольких частей . DOI : 10,17487 / RFC4884 . RFC 4884 .

RFC [ править ]

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

Внешние ссылки [ править ]

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

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

[RFC-1] F. Baker (июнь 1995 г.). Бейкер, Ф (ред.). «RFC 1812, Требования к маршрутизаторам IP версии 4» : 52. doi : 10.17487 / RFC1812 . Цитировать журнал требует |journal=( помощь )

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

[3] «Семь уровней модели OSI, определенные и объясненные функции» . Служба поддержки Microsoft . Проверено 28 декабря 2014 .

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

[5] Требования к маршрутизаторам IP версии 4 . DOI : 10,17487 / RFC1812 . RFC 1812 .

[rfc792-6] ^ a b c d e f g h i j k Postel, J. (сентябрь 1981 г.). Протокол управляющих сообщений Интернета . IETF . DOI : 10,17487 / RFC0792 . RFC 792 .

[7] «Параметры IANA ICMP» . Iana.org. 2012-09-21 . Проверено 7 января 2013 .

[8] Kurose, JF; Росс, KW (2006). Компьютерные сети: подход сверху вниз . Всемирная студенческая серия. Эддисон-Уэсли. ISBN 9780321418494.

[RFC_8335-9] PROBE: Утилита для проверки интерфейсов . DOI : 10,17487 / RFC8335 . RFC 8335 .

[10] RFC 6633

[11] "Когда отправляются перенаправления ICMP?" . Cisco Systems . 2008-06-28 . Проверено 15 августа 2013 .

[12] DL Mills (сентябрь 1985 г.). Сетевой протокол времени (NTP) . DOI : 10,17487 / RFC0958 . RFC 958 . Он произошел от протокола времени и сообщения отметки времени ICMP и является подходящей заменой для обоих.

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

[14] Расширенный ICMP для поддержки сообщений, состоящих из нескольких частей . DOI : 10,17487 / RFC4884 . RFC 4884 .

[1]