Протокол управляющих сообщений Интернета ( ICMP ) является вспомогательным протоколом в наборе протоколов Интернета . Он используется сетевыми устройствами , включая маршрутизаторы , для отправки сообщений об ошибках и оперативной информации, указывающей успех или неудачу при обмене данными с другим IP-адресом , например, ошибка указывается, когда запрошенная услуга недоступна или что хост или маршрутизатор не могут быть достигнуто. [2] ICMP отличается от транспортных протоколов , таких как TCP и UDP, тем, что он обычно не используется для обмена данными между системами и не используется регулярно сетевыми приложениями конечных пользователей (за исключением некоторых диагностических инструментов, таких как ping и Traceroute ). .
ICMP для IPv4 определен в RFC 792. С IPv6 используется отдельный ICMPv6 , определенный в 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 содержат раздел данных, включающий копию всего заголовка IPv4, а также по крайней мере первые восемь байтов данных из пакета IPv4, вызвавшего сообщение об ошибке. Длина сообщений об ошибках ICMP не должна превышать 576 байт. [5] Эти данные используются хостом для сопоставления сообщения соответствующему процессу. Если протокол более высокого уровня использует номера портов, предполагается, что они находятся в первых восьми байтах данных исходной дейтаграммы. [6]
Был использован переменный размер раздела пакетных данных ICMP . В « Пинге смерти » большие или фрагментированные пакеты ICMP используются для атак типа «отказ в обслуживании» . Данные ICMP также можно использовать для создания скрытых каналов связи. Эти каналы известны как туннели ICMP .
Управляющие сообщения идентифицируются по значению в поле типа . Поле кода предоставляет дополнительную контекстную информацию для сообщения. Некоторые управляющие сообщения устарели с момента первого появления протокола.
Source Quench запрашивает отправителя уменьшить скорость отправки сообщений на маршрутизатор или хост. Это сообщение может быть сгенерировано, если маршрутизатор или хост не имеет достаточного буферного пространства для обработки запроса, или может возникнуть, если буфер маршрутизатора или хоста приближается к своему пределу.
Данные передаются с очень высокой скоростью от хоста или от нескольких хостов одновременно к определенному маршрутизатору в сети. Хотя маршрутизатор имеет возможности буферизации, буферизация ограничена указанным диапазоном. Маршрутизатор не может поставить в очередь больше данных, чем позволяет емкость ограниченного буферного пространства. Таким образом, если очередь заполняется, входящие данные отбрасываются до тех пор, пока очередь не перестанет заполняться. Но поскольку на сетевом уровне отсутствует механизм подтверждения, клиент не знает, успешно ли дошли данные до места назначения. Следовательно, на сетевом уровне должны быть предприняты некоторые корректирующие меры, чтобы избежать подобных ситуаций. Эти меры называются закалкой источника.
В механизме подавления источника маршрутизатор видит, что скорость входящих данных намного выше скорости исходящих данных, и отправляет клиентам ICMP-сообщение, информируя их о том, что им следует снизить скорость передачи данных или подождать определенное количество время, прежде чем пытаться отправить дополнительные данные. Когда клиент получает это сообщение, он автоматически снижает скорость исходящих данных или ждет достаточное количество времени, что позволяет маршрутизатору очистить очередь. Таким образом, ICMP-сообщение подавления источника действует как управление потоком на сетевом уровне.
Поскольку исследования показали, что «ICMP Source Quench [был] неэффективным (и несправедливым) противоядием от перегрузки», [11] создание маршрутизаторами сообщений об подавлении источника было запрещено в 1995 году RFC 1812. Более того, пересылка и любая реакция на (действия по управлению потоком) сообщения о подавлении источника устарели с 2012 года согласно RFC 6633.
Где:
Перенаправление требует отправки пакетов данных по альтернативному маршруту. ICMP Redirect — это механизм, позволяющий маршрутизаторам передавать информацию о маршрутизации хостам. Сообщение сообщает хосту о необходимости обновить информацию о маршрутизации (отправить пакеты по альтернативному маршруту). Если хост пытается отправить данные через маршрутизатор (R1), а R1 отправляет данные на другой маршрутизатор (R2) и доступен прямой путь от хоста до R2 (то есть хост и R2 находятся в одной подсети ), затем R1 отправит сообщение перенаправления, чтобы сообщить хосту, что лучший маршрут для пункта назначения — через R2. Затем хост должен изменить информацию о своем маршруте и отправить пакеты для этого места назначения непосредственно на R2. Маршрутизатор по-прежнему отправит исходную дейтаграмму в назначенный пункт назначения. [12] Однако, если дейтаграмма содержит информацию о маршрутизации, это сообщение не будет отправлено, даже если доступен лучший маршрут. В RFC 1122 указано, что перенаправления должны отправляться только шлюзами и не должны отправляться хостами Интернета.
Где:
Время превышения генерируется шлюзом для информирования источника об отброшенной дейтаграмме из-за того, что поле времени жизни достигает нуля. Сообщение о превышении времени также может быть отправлено хостом, если ему не удалось повторно собрать фрагментированную дейтаграмму в течение установленного срока.
Сообщения о превышении времени используются утилитой трассировки для идентификации шлюзов на пути между двумя хостами.
Где:
Временная метка используется для синхронизации времени. Исходная временная метка устанавливается на время (в миллисекундах с полуночи), когда отправитель последний раз касался пакета. Временные метки приема и передачи не используются.
Где:
Timestamp Reply отвечает на сообщение Timestamp . Он состоит из исходной отметки времени, отправленной отправителем отметки времени , а также отметки времени получения, указывающей, когда отметка времени была получена, и отметки времени передачи, указывающей, когда был отправлен ответ отметки времени .
Где:
Использование сообщений Timestamp и Timestamp Reply для синхронизации часов интернет-узлов в значительной степени было заменено протоколом сетевого времени на основе UDP и протоколом точного времени . [13]
Запрос маски адреса обычно отправляется хостом маршрутизатору для получения соответствующей маски подсети .
Получатели должны ответить на это сообщение ответным сообщением по маске адреса .
Где:
Запрос маски адреса ICMP может использоваться как часть разведывательной атаки для сбора информации о целевой сети, поэтому ответ по маске адреса ICMP по умолчанию отключен в Cisco IOS. [14]
Ответ по маске адреса используется для ответа на сообщение с запросом маски адреса с использованием соответствующей маски подсети.
Где:
Пункт назначения недоступен генерируется хостом или его входным шлюзом [6] , чтобы сообщить клиенту, что пункт назначения по какой-то причине недоступен. Причинами появления этого сообщения могут быть: физическое соединение с хостом не существует (расстояние бесконечно); указанный протокол или порт не активен; данные должны быть фрагментированы, но флаг «не фрагментировать» включен. Недоступные порты TCP отвечают, в частности, TCP RST , а не недоступным пунктом назначения типа 3, как можно было бы ожидать. О недоступности пункта назначения никогда не сообщается при многоадресной IP- передаче.
Где:
Он создан на основе протокола времени и сообщения временной метки ICMP и является подходящей заменой для обоих.
