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

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

Интернет-протокол, используемый для сообщений об ошибках в сетевых операциях

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

С IPv6 используется отдельный протокол управляющих сообщений Интернета (называемый ICMPv6 ) . ^[4]

Технические подробности

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

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

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

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

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

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

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

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

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

Формат заголовка 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	Остальная часть заголовка

Тип: 8 бит: Тип ICMP см. в § Управляющие сообщения.
Код: 8 бит: Подтип ICMP, см. § Управляющие сообщения.
Контрольная сумма: 16 бит: Контрольная сумма Интернета ^[7] для проверки ошибок, вычисляемая из заголовка ICMP и данных со значением 0, подставленных вместо этого поля.
Остальная часть заголовка: 32 бита: Четырехбайтовое поле, содержимое которого зависит от типа и кода ICMP.

Данные

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

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

Контрольные сообщения

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

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

Источник гашения

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

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

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

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

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

Где:

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

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

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

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

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

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

Где:

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

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

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

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

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

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

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

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

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

Где:

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

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

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

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

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

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

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

Где:

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

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

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

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

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

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

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

Где:

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

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

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

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

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

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

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

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

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

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

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

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

Где:

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

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

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

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

Ответить на маску адреса

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

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

Где:

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

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

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

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

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

Сообщение о недоступности пункта назначения ^[2]^{: 4}^[19]
Компенсировать	Октет	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	Тип (3)								Код								Контрольная сумма
4	32	Неиспользованный								(Длина)								(MTU следующего перехода)
8	64	Заголовок IP и первые байты данных исходной датаграммы
⋮	⋮
572	4576

Со следующим содержимым полей:

Тип: 8 бит; Тип == 3: Значение 3 указывает на «Место назначения недоступно».
Код: 8 бит: Это указывает тип ошибки и может быть любым из следующих: ^[8]

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

Неиспользуется: 8 - 32 бита; Неиспользуется == 0: Не используется, должно быть установлено на ноль. Если Длина или MTU следующего перехода не используются, они считаются частью этого поля.
Длина: 8 бит: Необязательно. Поле Длина указывает длину исходных данных датаграммы в 32-битных словах. Это позволяет расширить это сообщение ICMP дополнительной информацией. Если используется, исходные данные датаграммы должны быть дополнены нулями до ближайшей 32-битной границы.
MTU следующего перехода: 16 бит: Необязательно. Содержит MTU сети следующего перехода, если возникает ошибка кода 4.
Заголовок IP и данные: 20–568 байт: Заголовок IP (20 байт) и не более 548 байт начала исходной датаграммы (чтобы не превысить минимальный размер буфера повторной сборки IPv4). Если это сообщение расширено, то это поле должно содержать не менее 128 байт исходных данных датаграммы (при необходимости дополненных нулями).
Эти данные включены, чтобы позволить клиенту сопоставить ответ с запросом, который вызвал ответ Destination unreachable .

Расширения

Сообщения ICMP могут быть расширены дополнительной информацией. Эта информация передается в одном или нескольких объектах расширения, которым предшествует заголовок расширения ICMP. ^[19]

Заголовок расширения 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	Объекты расширения
8	64
⋮	⋮

Версия: 4 бита; Версия == 2: Версия заголовка расширения.
Зарезервировано: 12 бит; Зарезервировано == 0: Сдержанный.
Контрольная сумма: 16 бит: Контрольная сумма по этому заголовку и всем объектам расширения. Это поле само по себе включено, поэтому при выполнении расчета оно устанавливается равным нулю.

Объекты расширения имеют следующую общую структуру:

Заголовок объекта расширения
Компенсировать	Октет	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	Длина																Номер класса								C-тип
4	32	(Полезная нагрузка объекта)
8	64
⋮	⋮

Длина: 16 бит: Длина объекта в октетах, включая заголовок.
Номер класса: 8 бит: Определяет класс объекта.
C-тип: 8 бит: Определяет подтип объекта.
Полезная нагрузка объекта: переменная: Необязательная полезная нагрузка. Если непустая, содержит структуру данных, размер которой кратен 32 битам.

Смотрите также

Ссылки

^ ab F. Baker , ed. (июнь 1995 г.). Требования к маршрутизаторам IP версии 4. Сетевая рабочая группа. doi : 10.17487/RFC1812 . RFC 1812. Предложенный стандарт. Отменяет RFC 1716 и 1009. Обновлен RFC 2644 и 6633.
^ abcdefghijkl J. Postel (сентябрь 1981 г.). ПРОТОКОЛ СООБЩЕНИЙ УПРАВЛЕНИЯ ИНТЕРНЕТОМ - СПЕЦИФИКАЦИЯ ПРОТОКОЛА ПРОГРАММЫ ИНТЕРНЕТА DARPA. Сетевая рабочая группа. doi : 10.17487/RFC0792 . STD 5. RFC 792. Интернет-стандарт 5. Обновления RFC 760, 777, IEN 109, 128. Обновлено RFC 950, 4884, 6633 и 6918.
^ abcd Фороузан, Бехруз А. (2007). Передача данных и сетевое взаимодействие (четвертое издание). Бостон: McGraw-Hill. С. 621–630. ISBN 978-0-07-296775-3.
^ A. Conta; S. Deering (март 2006 г.). M. Gupta (ред.). Протокол управляющих сообщений Интернета (ICMPv6) для спецификации протокола Интернета версии 6 (IPv6). Сетевая рабочая группа. doi : 10.17487/RFC4443 . STD 89. RFC 4443. Стандарт Интернета 89. Отменяет RFC 2463. Обновляет RFC 2780. Обновлен RFC 4884.
^ "Определение и объяснение семи уровней модели OSI". Поддержка Microsoft . Получено 28.12.2014 .
^ "Протокольные номера". Internet Assigned Numbers Authority . Получено 2011-06-23 .
^ Р. Брейден ; Д. Борман; К. Партридж (сентябрь 1988 г.). Вычисление контрольной суммы Интернета. Сетевая рабочая группа. doi : 10.17487/RFC1071 . RFC 1071. Информационное. Обновлено RFC 1141.
^ abc "Параметры IANA ICMP". Iana.org. 2012-09-21 . Получено 2013-01-07 .
^ Куроуз, Дж. Ф.; Росс, К. В. (2006). Компьютерные сети: подход сверху вниз. Всемирная студенческая серия. Addison-Wesley. ISBN 9780321418494.
^ ab F. Gont (май 2012 г.). Устаревание сообщений ICMP Source Quench. Internet Engineering Task Force . doi : 10.17487/RFC6633 . ISSN 2070-1721. RFC 6633. Предложенный стандарт. Обновления RFC 792, 1122 и 1812.
^ abcdefghijklmno F. Gont; C. Pignataro (апрель 2013 г.). Официальное прекращение поддержки некоторых типов сообщений ICMPv4. Internet Engineering Task Force . doi : 10.17487/RFC6918 . ISSN 2070-1721. RFC 6918. Предложенный стандарт. Отменяет RFC 1788. Обновляет RFC 792 и 950.
^ J. Kempf (июль 2005 г.). Инструкции по распределению IANA для Seamoby и экспериментального протокола мобильности. doi : 10.17487/RFC4065 . RFC 4065. Экспериментальный.
^ ab R. Bonica; R. Thomas; J. Linkova; C. Lenart; M. Boucadair (февраль 2018 г.). PROBE: Утилита для проверки интерфейсов. Internet Engineering Task Force . doi : 10.17487/RFC8335 . ISSN 2070-1721. RFC 8335. Предложенный стандарт. Обновления RFC 4884.
^ ab B. Fenner (ноябрь 2006 г.). Экспериментальные значения в заголовках IPv4, IPv6, ICMPv4, ICMPv6, UDP и TCP. Сетевая рабочая группа. doi : 10.17487/RFC4727 . RFC 4727. Предлагаемый стандарт.
^ "Когда отправляются перенаправления ICMP?". Cisco Systems . 2008-06-28 . Получено 2013-08-15 .
^ DL Mills (сентябрь 1985 г.). Сетевой протокол времени (NTP). doi : 10.17487/RFC0958 . RFC 958. Он является развитием протокола времени и сообщения ICMP Timestamp и является подходящей заменой для обоих.
^ "Справочник по командам Cisco IOS IP, том 1 из 4: Адресация и службы, выпуск 12.3 - Команды IP-адресации и служб: ip mask-reply через ip web-cache". Cisco Systems . Архивировано из оригинала 2013-01-02 . Получено 2013-01-07 .
^ J. Mogul; S. Deering (ноябрь 1990 г.). Path MTU Discovery. Сетевая рабочая группа. doi : 10.17487/RFC1191 . RFC 1191. Проект стандарта. Устаревший RFC 1063.
^ ab R. Bonica; D. Gan; D. Tappan; C. Pignataro (апрель 2007 г.). Расширенный ICMP для поддержки многокомпонентных сообщений. Сетевая рабочая группа. doi : 10.17487/RFC4884 . RFC 4884. Предложенный стандарт. Обновления RFC 792 и 4443. Обновлено RFC 8335.

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

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

[rfc1812-1] F. Baker , ed. (июнь 1995 г.). Требования к маршрутизаторам IP версии 4. Сетевая рабочая группа. doi : 10.17487/RFC1812 . RFC 1812. Предложенный стандарт. Отменяет RFC 1716 и 1009. Обновлен RFC 2644 и 6633.

[rfc792-2] J. Postel (сентябрь 1981 г.). ПРОТОКОЛ СООБЩЕНИЙ УПРАВЛЕНИЯ ИНТЕРНЕТОМ - СПЕЦИФИКАЦИЯ ПРОТОКОЛА ПРОГРАММЫ ИНТЕРНЕТА DARPA. Сетевая рабочая группа. doi : 10.17487/RFC0792 . STD 5. RFC 792. Интернет-стандарт 5. Обновления RFC 760, 777, IEN 109, 128. Обновлено RFC 950, 4884, 6633 и 6918.

[Forouzan-3] Фороузан, Бехруз А. (2007). Передача данных и сетевое взаимодействие (четвертое издание). Бостон: McGraw-Hill. С. 621–630. ISBN 978-0-07-296775-3.

[rfc4443-4] A. Conta; S. Deering (март 2006 г.). M. Gupta (ред.). Протокол управляющих сообщений Интернета (ICMPv6) для спецификации протокола Интернета версии 6 (IPv6). Сетевая рабочая группа. doi : 10.17487/RFC4443 . STD 89. RFC 4443. Стандарт Интернета 89. Отменяет RFC 2463. Обновляет RFC 2780. Обновлен RFC 4884.

[5] "Определение и объяснение семи уровней модели OSI". Поддержка Microsoft . Получено 28.12.2014 .

[6] "Протокольные номера". Internet Assigned Numbers Authority . Получено 2011-06-23 .

[rfc1071-7] Р. Брейден ; Д. Борман; К. Партридж (сентябрь 1988 г.). Вычисление контрольной суммы Интернета. Сетевая рабочая группа. doi : 10.17487/RFC1071 . RFC 1071. Информационное. Обновлено RFC 1141.

[icmp-parameters-8] "Параметры IANA ICMP". Iana.org. 2012-09-21 . Получено 2013-01-07 .

[9] Куроуз, Дж. Ф.; Росс, К. В. (2006). Компьютерные сети: подход сверху вниз. Всемирная студенческая серия. Addison-Wesley. ISBN 9780321418494.

[rfc6633-10] F. Gont (май 2012 г.). Устаревание сообщений ICMP Source Quench. Internet Engineering Task Force . doi : 10.17487/RFC6633 . ISSN 2070-1721. RFC 6633. Предложенный стандарт. Обновления RFC 792, 1122 и 1812.

[rfc6918-11] F. Gont; C. Pignataro (апрель 2013 г.). Официальное прекращение поддержки некоторых типов сообщений ICMPv4. Internet Engineering Task Force . doi : 10.17487/RFC6918 . ISSN 2070-1721. RFC 6918. Предложенный стандарт. Отменяет RFC 1788. Обновляет RFC 792 и 950.

[rfc4065-12] J. Kempf (июль 2005 г.). Инструкции по распределению IANA для Seamoby и экспериментального протокола мобильности. doi : 10.17487/RFC4065 . RFC 4065. Экспериментальный.

[rfc8335-13] R. Bonica; R. Thomas; J. Linkova; C. Lenart; M. Boucadair (февраль 2018 г.). PROBE: Утилита для проверки интерфейсов. Internet Engineering Task Force . doi : 10.17487/RFC8335 . ISSN 2070-1721. RFC 8335. Предложенный стандарт. Обновления RFC 4884.

[rfc4727-14] B. Fenner (ноябрь 2006 г.). Экспериментальные значения в заголовках IPv4, IPv6, ICMPv4, ICMPv6, UDP и TCP. Сетевая рабочая группа. doi : 10.17487/RFC4727 . RFC 4727. Предлагаемый стандарт.

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

[16] DL Mills (сентябрь 1985 г.). Сетевой протокол времени (NTP). doi : 10.17487/RFC0958 . RFC 958. Он является развитием протокола времени и сообщения ICMP Timestamp и является подходящей заменой для обоих.

[17] "Справочник по командам Cisco IOS IP, том 1 из 4: Адресация и службы, выпуск 12.3 - Команды IP-адресации и служб: ip mask-reply через ip web-cache". Cisco Systems . Архивировано из оригинала 2013-01-02 . Получено 2013-01-07 .

[rfc1191-18] J. Mogul; S. Deering (ноябрь 1990 г.). Path MTU Discovery. Сетевая рабочая группа. doi : 10.17487/RFC1191 . RFC 1191. Проект стандарта. Устаревший RFC 1063.

[rfc4884-19] R. Bonica; D. Gan; D. Tappan; C. Pignataro (апрель 2007 г.). Расширенный ICMP для поддержки многокомпонентных сообщений. Сетевая рабочая группа. doi : 10.17487/RFC4884 . RFC 4884. Предложенный стандарт. Обновления RFC 792 и 4443. Обновлено RFC 8335.