|
|
|
|
|||||
|
|
|||||||
|
|
|||||||
|
|
|||||||
|
Network Working Group Request for Comments:
|
792
|
J. Postel
ISI
September 1981
|
|||||
|
Updates Updates
|
RFCs 777, 760 IENs 109, 128
|
||||||
|
|
|||||||
|
INTERNET CONTROL MESSAGE PROTOCOL
|
|||||||
|
|
|||||||
|
DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION
|
|||||||
|
|
|||||||
|
Протокол ICMP Введение
Протокол IP (Internet Protocol) [1] используется для передачи дейтаграмм между хостами в системе связанных между собой сетей, называемой Catenet1 [2]. Устройства, соединяющие сети между собой, называются шлюзами2 (Gateway). Маршрутизаторы (шлюзы) взаимодействуют между собой с помощью протокола GGP3 (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 имеют следующие значения:
Version
4
IHL
Размер заголовка Internet в 32-битовых словах.
Type of Service
0
Total Length
Размер заголовка и поля данных в октетах.
|
|||||||
|
|
|||||||
|
1 Прообраз современной сети Internet. Прим. перев.
|
|
||||||
|
2 Сегодня такие устройства называют маршрутизаторами (router), а термином шлюз обозначают системы преобразования (трансляции) протоколов вышележащих уровней (например, почтовые шлюзы или шлюзы IP-телефонии). Прим. перев.
3 В современных сетях для обмена информацией между маршрутизаторами используются более изощренные протоколы маршрутизации типа BGP, RIP, OSPF. Спецификации этих протоколов вы можете найти на сайте http://rfc.com.ru. Прим. перев
|
|||||||
|
|
|||||||
|
|
||||
|
|
Перевод RFC
|
|||
|
|
||||
|
Identification, Flags, Fragment Offset
Используются при фрагментации, см. [1].
Time to Live
Время жизни дейтаграммы в секундах. Значение этого поля уменьшается по крайней мере на 1 в каждой точке обработки дейтаграммы (маршрутизаторы на пути доставки).
Protocol
ICMP = 1
Header Checksum
16-битовое поразрядное дополнение суммы поразрядных дополнений всех 16-битовых слов заголовка. При расчете контрольной суммы значение самого поля принимается равным нулю (не учитывается). Алгоритм расчета контрольной суммы может быть изменен в будущем.
Source Address
Адрес шлюза или хоста, создавшего сообщение ICMP. Если явно не задано иное, может использоваться любой из адресов шлюза.
Destination Address
Адрес хоста или шлюза, которому должно быть передано сообщение.
Сообщение 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
Не используется Заголовок IP и 64 бита исходной дейтаграммы
Поля IP Destination Address
Адрес отправителя исходной дейтаграммы.
Поля ICMP Type
3
Code
0 = сеть недоступна;
1 = хост недоступен;
2 = протокол недоступен;
3 = порт недоступен;
4 = требуется фрагментация, но установлен флаг DF (не фрагментировать);
5 = некорректно задан маршрут source route.
Checksum
Контрольная сумма представляет собой 16-битовое поразрядное дополнение суммы поразрядных дополнений сообщения ICMP, начиная с поля ICMP Type. При расчете контрольной суммы значение поля checksum принимается нулевым. Алгоритм вычисления контрольной суммы может быть изменен в будущем.
Заголовок IP и 64 бита исходной дейтаграммы
Эта информация используется хостом, чтобы связать сообщение с подходящим процессом. Если протокол вышележащего уровня использует порты, можно полагать, что номер порта присутствует в первых 64 байтах данных исходной дейтаграммы.
Описание
Если (в соответствии с данными в таблице маршрутизации шлюза) сеть, указанная в поле адреса получателя дейтаграммы, недоступна (например, дистанция до этой сети бесконечна), шлюз может передавать сообщение destination unreachable хосту, отправившему дейтаграмму. Дополнительно к этому в некоторых сетях шлюзы могут определять недоступность хоста. В таких сетях шлюзы могут передавать в этом случае сообщение destination unreachable4. Если 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
Не используется Заголовок IP и 64 бита исходной дейтаграммы
|
||||
|
|
||||
|
Code = 1. Прим. перев.
|
||||
|
|
||||
|
2
|
||||
|
|
||||
|
|
||||||||||||||||||||||||
|
Перевод RFC
|
|
|||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
Поля IP Destination Address
Адрес отправителя исходной дейтаграммы.
Поля ICMP Type
11
Code
0 = время жизни истекло в процессе доставки;
1 = время жизни истекло в процессе сборки фрагментов.
Checksum
Контрольная сумма представляет собой 16-битовое поразрядное дополнение суммы поразрядных дополнений сообщения ICMP, начиная с поля ICMP Type. При расчете контрольной суммы значение поля checksum принимается нулевым. Алгоритм вычисления контрольной суммы может быть изменен в будущем.
Заголовок IP и 64 бита исходной дейтаграммы
Эта информация используется хостом, чтобы связать сообщение с подходящим процессом. Если протокол вышележащего уровня использует порты, можно полагать, что номер порта присутствует в первых 64 байтах данных исходной дейтаграммы.
Описание
Если обрабатывающий дейтаграмму шлюз видит, что поле 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
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
Поля IP Destination Address
Адрес отправителя исходной дейтаграммы.
Поля ICMP Type
12
Code
0 – поле pointer содержит указатель на ошибку.
Checksum
Контрольная сумма представляет собой 16-битовое поразрядное дополнение суммы поразрядных дополнений сообщения ICMP, начиная с поля ICMP Type. При расчете контрольной суммы значение поля checksum принимается нулевым. Алгоритм вычисления контрольной суммы может быть изменен в будущем.
Pointer
Если code = 0, данное поле указывает октет, в котором обнаружена ошибка.
Заголовок IP и 64 бита исходной дейтаграммы
Эта информация используется хостом, чтобы связать сообщение с подходящим процессом. Если протокол вышележащего уровня использует порты, можно полагать, что номер порта присутствует в первых 64 байтах данных исходной дейтаграммы.
Описание
Если шлюз или хост, обрабатывающий дейтаграмму, встречает в заголовке параметры, которые не могут быть обработаны, такая дейтаграмма отбрасывается. Одной из причин таких ошибок являются некорректные аргументы в полях опций. Шлюз или хост может уведомить отправителя дейтаграммы о возникновении проблем с помощью сообщения parameter problem. Такие сообщения передаются только в случаях отбрасывания проблемной дейтаграммы. Поле pointer указывает октет в заголовке исходной дейтаграммы, в котором была обнаружена ошибка (она может находиться в поле опций). Например, значение 1 показывает ошибку в поле Type of Service, а 20 (если в заголовке присутствуют опции) говорит о некорректности кода первой опции. Код 0 может быть получен от шлюза или хоста.
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
3
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
|
|||
|
|
Перевод RFC
|
||
|
|
|||
|
Сообщение 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
Не используется Заголовок IP и 64 бита исходной дейтаграммы
Поля IP Destination Address
Адрес отправителя исходной дейтаграммы.
Поля ICMP Type
4
Code
0
Checksum
Контрольная сумма представляет собой 16-битовое поразрядное дополнение суммы поразрядных дополнений сообщения ICMP, начиная с поля ICMP Type. При расчете контрольной суммы значение поля checksum принимается нулевым. Алгоритм вычисления контрольной суммы может быть изменен в будущем.
Заголовок IP и 64 бита исходной дейтаграммы
Эта информация используется хостом, чтобы связать сообщение с подходящим процессом. Если протокол вышележащего уровня использует порты, можно полагать, что номер порта присутствует в первых 64 байтах данных исходной дейтаграммы.
Описание
Шлюз может отбрасывать дейтаграммы, если у него недостаточно буферного пространства для размещения дейтаграммы в очереди на передачу в следующую сеть на пути к получателю. Если шлюз отбрасывает дейтаграмму, он может передать ее отправителю сообщение source quench message. Хост-получатель также может передавать сообщения 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 Destination Address
Адрес отправителя исходной дейтаграммы.
Поля ICMP Type
5
Code
0 – перенаправление (Redirect) дейтаграмм для сети;
1 – перенаправление (Redirect) дейтаграмм для хоста;
2 – перенаправление (Redirect) дейтаграмм для типа обслуживания и сети;
3 – перенаправление (Redirect) дейтаграмм для типа обслуживания и хоста.
Checksum
Контрольная сумма представляет собой 16-битовое поразрядное дополнение суммы поразрядных дополнений сообщения ICMP, начиная с поля ICMP Type. При расчете контрольной суммы значение поля checksum принимается нулевым. Алгоритм вычисления контрольной суммы может быть изменен в будущем.
Gateway Internet Address
Адрес шлюза, которому следует направлять трафик, указанный в поле адреса получателя исходной дейтаграммы.
|
|||
|
|
|||
|
|
|||
|
|
|||||||||||||||||||||||||||||||
|
Перевод RFC
|
|
||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||
|
Заголовок IP и 64 бита исходной дейтаграммы
Эта информация используется хостом, чтобы связать сообщение с подходящим процессом. Если протокол вышележащего уровня использует порты, можно полагать, что номер порта присутствует в первых 64 байтах данных исходной дейтаграммы.
Описание
Шлюзы передают сообщения redirect в нескольких случаях. Предположим, что шлюз G1 принимает дейтаграмму от хоста, находящегося в подключенной к шлюзу сети. G1 просматривает свою таблицу маршрутизации и определяет адрес следующего шлюза G2 на пути дейтаграммы к сети получателя, X. Если шлюз G2 и хост, указанный в поле отправителя дейтаграммы, находятся в одной сети, хосту передается сообщение redirect. Такое сообщение говорит хосту что трафик для сети X следует передавать шлюзу G2, поскольку такой путь будет короче. Исходную дейтаграмму получивший ее шлюз пересылает в направлении адресата.
Для дейтаграмм IP с опцией source route и адресом шлюза в поле destination address сообщения redirect не передаются даже в тех случаях, когда к конечному получателю существует маршрут, который лучше указанного в source route. Коды 0, 1, 2, 3 могут приниматься от шлюзов.
Сообщения Echo или Echo Reply
|
|||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||
|
Сообщение 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
|
|||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
|
Данные …
|
|||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||
|
Поля IP Address
Адрес отправителя сообщения echo будет адресом получателя в сообщении echo reply. Для формирования сообщений echo reply поля адресов отправителя и получателя просто меняются местами, значение кода заменяется на 0 и заново вычисляется контрольная сумма.
Поля ICMP5 Type
8 – для сообщений echo
0 – для сообщений echo reply
Code
0
Checksum
Контрольная сумма представляет собой 16-битовое поразрядное дополнение суммы поразрядных дополнений сообщения ICMP, начиная с поля ICMP Type. При расчете контрольной суммы значение поля checksum принимается нулевым. Если общая длина имеет нечетное значение, добавляется один октет нулей. Алгоритм вычисления контрольной суммы может быть изменен в будущем.
Идентификатор
Если code = 0, идентификатор может быть нулевым для обеспечения соответствия запросов и откликов.
Порядковый номер
Если code = 0, порядковый номер может быть нулевым для обеспечения соответствия запросов и откликов
Описание
Данные, принятые в сообщении 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
|
|||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||
|
5 В оригинале ошибочно указано IP. Прим. перев.
|
|||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||
|
|
||||
|
|
Перевод RFC
|
|||
|
|
||||
|
Поля IP Address
Адрес отправителя сообщения timestamp будет адресом получателя в сообщении timestamp reply. Для формирования сообщений timestamp reply поля адресов отправителя и получателя просто меняются местами, значение кода заменяется на 14 и заново вычисляется контрольная сумма.
Поля ICMP6 Type
13 – для сообщений timestamp
14 – для сообщений timestamp reply
Code
0
Checksum
Контрольная сумма представляет собой 16-битовое поразрядное дополнение суммы поразрядных дополнений сообщения ICMP, начиная с поля ICMP Type. При расчете контрольной суммы значение поля checksum принимается нулевым. Алгоритм вычисления контрольной суммы может быть изменен в будущем.
Идентификатор
Если code = 0, идентификатор может быть нулевым для обеспечения соответствия меток и откликов.
Порядковый номер
Если code = 0, порядковый номер может быть нулевым для обеспечения соответствия меток и откликов
Описание
Принятые данные (временная метка) из сообщения 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
Идентификатор Порядковый номер
|
||||
|
|
||||
|
Поля IP Address
Адрес отправителя сообщения information request будет адресом получателя в сообщении information reply. Для формирования сообщений information reply поля адресов отправителя и получателя просто меняются местами, значение кода заменяется на 16 и заново вычисляется контрольная сумма.
Поля ICMP7 Type
15 – для сообщений information request
16 – для сообщений information reply
Code
0
Checksum
Контрольная сумма представляет собой 16-битовое поразрядное дополнение суммы поразрядных дополнений сообщения ICMP, начиная с поля ICMP Type. При расчете контрольной суммы значение поля checksum принимается нулевым. Алгоритм вычисления контрольной суммы может быть изменен в будущем.
Идентификатор
Если code = 0, идентификатор может быть нулевым для обеспечения соответствия запросов и откликов.
Порядковый номер
Если code = 0, порядковый номер может быть нулевым для обеспечения соответствия запросов и откликов
|
||||
|
|
||||
|
В оригинале ошибочно указано IP. Прим. перев. В оригинале ошибочно указано IP. Прим. перев.
|
||||
|
|
||||
|
6
|
||||
|
|
||||
|
|
|||
|
Перевод RFC
|
|
||
|
|
|||
|
Описание
Эти сообщения могут передаваться с установленным в заголовке IP адресом отправителя и нулевым значением адреса получателя (такой вариант адресации означает "данная сеть"). Отвечающему модулю IP следует передавать отклик с заполненными полями адресов. Такие сообщения могут использоваться хостами для определения номера своей сети. Значения идентификатора и порядкового номера могут использоваться отправителем в целях обеспечения соответствия между запросами и откликами. Например, значение идентификатора может использоваться по аналогии с портами TCP и UDP для обозначения сеансов, а порядковый номер может увеличиваться на единицу в каждом передаваемом запросе (отвечающая сторона сохраняет порядковые номера в откликах). Код 0 может приходить от шлюзов и хостов.
Типы сообщений
0 Echo Reply
3 Destination Unreachable
4 Source Quench
5 Redirect 8 Echo
11 Time Exceeded
12 Parameter Problem
13 Timestamp
14 Timestamp Reply
15 Information Request
16 Information Reply
Литература
[1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification," RFC 7918, 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.
Перевод на русский язык
Nikolai Malykh BiLiM Systems Ltd. Санкт-Петербург 194354, К-354, а/я 153 тел. (812) 325-2068 nmalykh@bilim.com
|
|||
|
|
|||
|
8 Перевод этого документа вы можете найти на сайте http://rfc.com.ru. Прим. перев.
|
|||
|
|
|||