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

редактировать
Интернет-протокол, используемый для сообщений об ошибках в сетевых операциях
Протокол управляющих сообщений Интернета
Протокол связи
Заголовок ICMP - General-en.svg A общий заголовок для ICMPv4.
НазначениеВспомогательный протокол для IPv4
Разработчик(s)DARPA
Представлен1981
Уровень OSI Сеть уровень
RFC (s) RFC 792

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

ICMP для IPv4 определен в RFC 792.

Содержание
  • 1 Технические детали
  • 2 Структура дейтаграммы
    • 2.1 Заголовок
    • 2.2 Данные
  • 3 Управляющие сообщения
    • 3.1 Прерывание источника
    • 3.2 Перенаправление
    • 3.3 Превышено время
    • 3.4 Временная метка
    • 3.5 Ответ временной метки
    • 3.6 Запрос маски адреса
    • 3.7 Ответ маски адреса
    • 3.8 Назначение недоступно
  • 4 См. Также
  • 5 Ссылки
  • 6 RFC
  • 7 Внешние ссылки
Технические детали

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

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

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

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

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

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

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

Заголовок

Заголовок ICMP начинается после заголовка IPv4 и идентифицируется номером протокола IP «1». Все пакеты ICMP имеют 8-байтовый заголовок и раздел данных переменного размера. Первые 4 байта заголовка имеют фиксированный формат, а последние 4 байта зависят от типа / кода этого пакета ICMP.

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

Данные

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

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

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

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

Известные управляющие сообщения
ТипКодСостояниеОписание
0 - Эхо-ответ0Эхо-ответ (используется для эхо-запроса )
1 и 2неназначеноЗарезервировано
3 - Назначение недоступно0Целевая сеть недоступна
1Целевой хост недоступен
2Целевой протокол недоступен
3Целевой порт недоступен
4Требуется фрагментация и флаг DF установлен
5Ошибка исходного маршрута
6Целевая сеть неизвестна
7Целевой хост неизвестен
8Исходный хост изолирован
9Сеть административно запрещена
10Хост административно запрещен
11Сеть недоступна для ToS
12Хост недоступен для ToS
13Связь запрещена административно
14Нарушение приоритета хоста
15Действует отсечка приоритета
4 - Source Quench0устарелоБлокировка источника (контроль перегрузки)
5 - Сообщение перенаправления0Дейтаграмма перенаправления для сети
1Дейтаграмма перенаправления для хоста
2Дейтаграмма перенаправления для ToS и сеть
3Дейтаграмма перенаправления для ToS и хост
6устарелаАльтернативный адрес хоста
7не назначенЗарезервировано
8 - Эхо-запрос0Эхо-запрос (используется для проверки связи)
9 - Объявление маршрутизатора 0Объявление маршрутизатора
10 - Запрос маршрутизатора 0Обнаружение / выбор / запрос маршрутизатора
11 - Превышено время 0TTL истекло при передаче
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не рекомендуетсяГде -Are-You (изначально предназначался для IPv6 )
34устарелHere-I-Am (изначально предназначался для IPv6)
35устарелЗапрос мобильной регистрации
36устарелОтвет мобильной регистрации
37устарелоЗапрос доменного имени
38устарелоОтвет доменного имени
39не рекомендуетсяПротокол обнаружения алгоритма SKIP, Простое управление ключами для интернет-протокола
40Photuris, Нарушения безопасности
41ЭкспериментальныйICMP для протоколов экспериментальной мобильности, таких как Seamoby [RFC4065]
42 - Расширенный запрос эхо0Запрос расширенного эхо (XPing - см. Расширенный эхо-запрос (Xping) )
43 - Расширенный эхо-ответ0Нет ошибок
1Искаженный запрос
2Нет такого интерфейса
3Нет такой записи в таблице
4Запрос соответствия нескольких интерфейсов
44 через 252una ssignedЗарезервировано
253ЭкспериментальноеЭксперимент 1 в стиле RFC3692 (RFC 4727 )
254Экспериментальныйв стиле RFC3692 Эксперимент 2 (RFC 4727 )
255зарезервированоЗарезервировано

Source quench

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

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

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

Сообщение о блокировке источника
0001020304050607080910111213141516171819202122232425262728293031
Тип = 4Код = 0Контрольная сумма
неиспользуемый
IP-заголовок и первые 8 байтов исходных данных дейтаграммы

Где:

Тип должен быть установлен на 4
Код должен быть установлен на 0
IP-заголовок, и отправитель использует дополнительные данные для сопоставления ответа со связанным запросом

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

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

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

Сообщение перенаправления
0001020304050607080910111213141516171819202122232425262728293031
Тип = 5КодКонтрольная сумма
IP-адрес
IP заголовок и первые 8 байтов исходных данных дейтаграммы

Где:

Тип должен иметь значение 5.
Код указывает причину перенаправления, может быть одним из следующих:
КодОписание
0Перенаправление для сети
1Перенаправление для хоста
2Перенаправление для типа службы и сети
3Перенаправление для типа службы и хоста
IP-адрес 32-битный адрес шлюза, на который должно быть отправлено перенаправление.
IP-заголовок и дополнительные данные включены, чтобы позволить хосту сопоставить ответ с запросом, который вызвал ответ перенаправления.

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

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

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

Сообщение о превышении времени
0001020304050607080910111213141516171819202122232425262728293031
Тип = 11КодКонтрольная сумма
неиспользуемый
IP заголовок и первые 8 байтов исходных данных дейтаграммы

Где:

Тип должен быть установлен на 11.
Код указывает причину сообщения о превышении времени, включая следующее:
КодОписание
0Превышено время жизни при передаче.
1Превышено время сборки фрагмента.
IP-заголовок и первые 64 бита исходной полезной нагрузки используются хостом-источником для сопоставления сообщения о превышении времени с отклоненной дейтаграммой. Для протоколов более высокого уровня, таких как UDP и TCP, 64-битная полезная нагрузка будет включать порты источника и назначения отброшенного пакета.

Timestamp

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

Сообщение с отметкой времени
0001020304050607080910111213141516171819202122232425262728293031
Тип = 13Код = 0Контрольная сумма
ИдентификаторПорядковый номер
Отметка времени отправления
Отметка времени получения
Отметка времени передачи

Где:

Тип должен быть установлен на 13
Код должен быть установлен на 0
Идентификатор и Порядковый номер могут использоваться клиентом для сопоставления ответа отметки времени с запросом отметки времени.
Отметка времени отправителя - количество миллисекунд с полуночи всемирное время (UT). Если ссылка UT недоступна, можно установить самый старший бит для указания нестандартного значения времени.

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

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

Ответное сообщение с отметкой времени
0001020304050607080910111213141516171819202122232425262728293031
Тип = 14Код = 0Контрольная сумма
ИдентификаторПорядковый номер
Отметка времени отправления
Отметка времени получения
Отметка времени передачи

Где:

Тип должен быть установлен на 14
Код должен быть установлен на 0
Идентификатор и Порядковый номер может использоваться клиентом для сопоставления ответа с запросом, который вызвал ответ.
Метка времени отправителя - время, когда отправитель последний раз касался перед отправкой сообщения.
Отметка времени получения - это время, когда эхо-индикатор впервые коснулся его при получении.
Временная метка передачи - это время, когда эхо-эхо последний раз коснулся сообщения при его отправке.
Все временные метки в миллисекундах с полуночи UT. Если время недоступно в миллисекундах или не может быть предоставлено относительно полуночного UT, тогда любое время может быть вставлено в метку времени при условии, что старший бит метки времени также установлен для указания этого нестандартного значения.

Маска адреса request

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

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

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

Где:

Тип должен быть установлен на 17
Код должен быть установлен на 0
Адресная маска может быть установлено значение 0

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

Ответ маски адреса

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

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

Где:

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

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

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

Сообщение о недоступности адресата
0001020304050607080910111213141516171819202122232425262728293031
Тип = 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.
Заголовок IP и дополнительные данные включены, чтобы позволить клиенту чтобы сопоставить ответ с запросом, который вызвал ответ о недоступности адресата.
См. также
Ссылки
RFC
  • RFC 792, протокол управляющих сообщений Интернета
  • RFC 950, стандартная процедура разделения подсетей Интернета
  • RFC 1016, Что-то, что хост может сделать с подавлением источника: задержка, вызванная подавлением источника (SQuID)
  • RFC 1122, Требования к хостам Интернета - Уровни связи
  • RFC 1716, Требования к IP-маршрутизаторам
  • RFC 1812, Требования к маршрутизаторам IP версии 4
Внешние ссылки
В Викиверситете есть учебные ресурсы по Протоколу управляющих сообщений Интернета
Последняя правка сделана 2021-05-24 04:58:15
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте