AAA

RFC 792 — Протокол ICMP

Протокол IP (Internet Protocol) [1] используется для передачи дейтаграмм между хостами в системе связанных между собой сетей, называемой Catenet [2]. Устройства, соединяющие сети между собой, называются шлюзами (Gateway). Маршрутизаторы (шлюзы) взаимодействуют между собой с помощью протокола GGP (Gateway to Gateway Protocol) [3,4]. Иногда шлюзам или хостам-получателям требуется связаться с хостом-отправителем (например, для передачи сообщения об ошибке при обработке дейтаграммы). Для решения таких задач предназначен описываемый этой спецификацией протокол ICMP (Internet Control Message Protocol — протокол управляющих сообщений Internet). ICMP использует базовый сервис протокола IP, как это делают протоколы вышележащих уровней, однако протокол ICMP на самом деле является составной часть IP и должен быть реализован в каждом модуле IP.

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

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

Сообщения ICMP обычно содержат информацию об ошибках при обработке дейтаграмм. Для предотвращения бесконечных циклов обмена сообщениями не должно передаваться сообщений ICMP о других сообщениях ICMP. При возникновении ошибок в процессе обработки фрагментированных дейтаграмм сообщения ICMP должны передаваться только для начального (нулевого) фрагмента дейтаграммы (нулевым фрагментом считается тот, для которого значение fragment offset равно 0).

Формат сообщений

Сообщения ICMP передаются с использованием базовых заголовков IP. Первый октет данных дейтаграммы указывает тип ICMP — значение этого поля определяет формат остальной части дейтаграммы. Все поля, указанные как неиспользуемые (unused), зарезервированы для использования в будущем и должны иметь нулевые значения. Получателям не следует использовать эти поля (за исключением их учета при вычислении контрольной суммы). Если при описании конкретного формата явно не указано иное, поля заголовков IP имеют следующие значения:

Сообщение Destination Unreachable

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             unused                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Заголовок IP и 64 бита исходной дейтаграммы          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP

Поля ICMP

Описание

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

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

Когда дейтаграмма должна быть фрагментирована для пересылки шлюзу, но в ней установлен флаг DF (не фрагментировать), шлюз должен отбросить дейтаграмму и может передать ее отправителю сообщение destination unreachable.

Коды 0, 1, 4, 5 могут приходить от шлюзов, коды 2 и 3 — от хостов.

Сообщение Time Exceeded

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             unused                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Заголовок IP и 64 бита исходной дейтаграммы          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP

Поля ICMP

Описание

Если обрабатывающий дейтаграмму шлюз видит, что поле TTL содержит нулевое значение, дейтаграмма должна быть отброшена. Шлюз может уведомить отправителя дейтаграммы с помощью сообщения time exceeded.

Если хост, собирающий дейтаграмму из фрагментов, не может завершить сборку в течение заданного времени по причине нехватки фрагментов, дейтаграмма должна быть отброшена. Хост может передать отправителю дейтаграммы сообщение time exceeded.

При отсутствии нулевого фрагмента сообщение time exceeded передавать не нужно.

Код 0 может быть получен от шлюза, код 1 — от хоста.

Сообщение Parameter Problem

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Pointer    |                   unused                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Заголовок IP и 64 бита исходной дейтаграммы          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP

Поля ICMP

Описание

Если шлюз или хост, обрабатывающий дейтаграмму, встречает в заголовке параметры, которые не могут быть обработаны, такая дейтаграмма отбрасывается. Одной из причин таких ошибок являются некорректные аргументы в полях опций. Шлюз или хост может уведомить отправителя дейтаграммы о возникновении проблем с помощью сообщения parameter problem. Такие сообщения передаются только в случаях отбрасывания проблемной дейтаграммы.

Поле pointer указывает октет в заголовке исходной дейтаграммы, в котором была обнаружена ошибка (она может находиться в поле опций). Например, значение 1 показывает ошибку в поле Type of Service, а 20 (если в заголовке присутствуют опции) говорит о некорректности кода первой опции.

Код 0 может быть получен от шлюза или хоста.

Сообщение Source Quench

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             unused                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Заголовок IP и 64 бита исходной дейтаграммы          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP

Поля ICMP

Описание

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

Шлюз или хост может передать сообщение source quench, когда он может предсказать нехватку ресурсов, не дожидаясь критической ситуации. Это означает, что дейтаграмма, вызвавшая передачу сообщения source quench, вполне может быть доставлена.

Код 0 может быть получен от шлюзов и хостов.

Сообщение Redirect

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Gateway Internet Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Заголовок IP и 64 бита исходной дейтаграммы          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP

Поля ICMP

Описание

Шлюзы передают сообщения redirect в нескольких случаях. Предположим, что шлюз G1 принимает дейтаграмму от хоста, находящегося в подключенной к шлюзу сети. G1 просматривает свою таблицу маршрутизации и определяет адрес следующего шлюза G2 на пути дейтаграммы к сети получателя, X. Если шлюз G2 и хост, указанный в поле отправителя дейтаграммы, находятся в одной сети, хосту передается сообщение redirect. Такое сообщение говорит хосту что трафик для сети X следует передавать шлюзу G2, поскольку такой путь будет короче. Исходную дейтаграмму получивший ее шлюз пересылает в направлении адресата.

Для дейтаграмм IP с опцией source route и адресом шлюза в поле destination address сообщения redirect не передаются даже в тех случаях, когда к конечному получателю существует маршрут, который лучше указанного в source route.

Коды 0, 1, 2, 3 могут приниматься от шлюзов.

Сообщения Echo и Reply

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Данные ...
+-+-+-+-+-

Поля IP

Поля ICMP

Описание

Данные, принятые из сообщения echo, должны возвращаться в сообщении echo reply.

Значения идентификатора и порядкового номера могут использоваться отправителем сообщений echo в целях обеспечения соответствия между запросами и откликами. Например, значение идентификатора может использоваться по аналогии с портами TCP и UDP для обозначения сеансов, а порядковый номер может увеличиваться на единицу в каждом передаваемом запросе echo (отвечающая сторона сохраняет порядковые номера в откликах).

Код 0 может приходить от шлюзов и хостов.

Сообщения Сообщения Timestamp и Timestamp Reply

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |      Code     |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Originate Timestamp                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Receive Timestamp                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Transmit Timestamp                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP

Поля ICMP

Описание

Принятые данные (временная метка) из сообщения timestamp возвращаются в отклике вместе с дополнительной временной меткой. Метка представляет собой 32-битовое значение числа миллисекунд после полуночи по времени UT. Один из вариантов использования временных меток описан в работе Mills [5].

Поле Originate Timestamp содержит время отправителя на момент отправки дейтаграммы, Receive Timestamp — время получателя в момент приема дейтаграммы, а Transmit Timestamp — время отправителя отклика перед отправкой дейтаграммы.

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

Значения идентификатора и порядкового номера могут использоваться отправителем сообщений timestamp в целях обеспечения соответствия между запросами и откликами. Например, значение идентификатора может использоваться по аналогии с портами TCP и UDP для обозначения сеансов, а порядковый номер может увеличиваться на единицу в каждом передаваемом запросе timestamp (отвечающая сторона сохраняет порядковые номера в откликах).

Код 0 может приходить от шлюзов и хостов.

Сообщения Information Request и Information Reply

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |      Code     |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля IP

Поля ICMP

Описание

Эти сообщения могут передаваться с установленным в заголовке IP адресом отправителя и нулевым значением адреса получателя (такой вариант адресации означает "данная сеть"). Отвечающему модулю IP следует передавать отклик с заполненными полями адресов. Такие сообщения могут использоваться хостами для определения номера своей сети.

Значения идентификатора и порядкового номера могут использоваться отправителем в целях обеспечения соответствия между запросами и откликами. Например, значение идентификатора может использоваться по аналогии с портами TCP и UDP для обозначения сеансов, а порядковый номер может увеличиваться на единицу в каждом передаваемом запросе (отвечающая сторона сохраняет порядковые номера в откликах).

Код 0 может приходить от шлюзов и хостов.

Типы сообщений

0Echo Reply
3Destination Unreachable
4Source Quench
5Redirect
8Echo
11Time Exceeded
12Parameter Problem
13Timestamp
14Timestamp Reply
15Information Request
16Information Reply

Литература

  1. Postel, J. (ed.), "Internet Protocol — DARPA Internet Program Protocol Specification," RFC 791, USC/Information Sciences Institute, September 1981
  2. Cerf, V., "The Catenet Model for Internetworking," IEN 48, Information Processing Techniques Office, Defense Advanced Research Projects Agency, July 1978.
  3. Strazisar, V., "Gateway Routing: An Implementation Specification", IEN 30, Bolt Beranek and Newman, April 1979.
  4. Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and Newman, August 1979.
  5. Mills, D., "DCNET Internet Clock Service," RFC 778, COMSAT Laboratories, April 1981.

Перевод на русский язык

Николай Малых, moc.milib@hkylamn