21. Протокол ІСМР: призначення та основні принципи роботи.

Введение

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

ICMP сообщения передаются внутри IP датаграмм, как показано на рисунке 6.1.

Рисунок 6.1 Инкапсуляция ICMP сообщений в IP датаграммы.

 

Официальная спецификация ICMP находится в RFC 792 [Postel 1981b].

На рисунке 6.2 показан формат ICMP сообщения. Первые 4 байта одинаковы для всех сообщений, однако остальные отличаются в зависимости от типа сообщения. Мы будем показывать точный формат каждого сообщения, по мере того как будем их описывать.

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

Поле контрольной суммы (checksum) охватывает ICMP сообщения целиком. Алгоритм, используемый при этом, такой же как тот, что был описан в разделе "IP заголовок" главы 3 при расчете контрольной суммы IP заголовка. Контрольная сумма ICMP присутствует всегда.

Рисунок 6.2 ICMP сообщение.

В этой главе мы рассмотрим ICMP сообщения в целом, некоторые из них подробно: запрос и отклик маски адреса, запрос и отклик временной марки и сообщение о недоступности порта. В главе 7 мы обсудим, с использованием программы Ping, эхо запрос и эхо отклик, а в главе 9 рассмотрим ICMP сообщения, связанные с IP маршрутизацией.

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

На рисунке 6.3 приведены возможные типы ICMP сообщений, как они определяются полями типа (type) и кода (code).

Последние две колонки на рисунке указывают, является ли ICMP сообщение запросом (query) или сообщением об ошибке (error). Подобное разделение необходимо, потому что сообщения об ошибках ICMP иногда обрабатываются специальным образом. Например, ICMP сообщение об ошибке никогда не генерируется в ответ на ICMP сообщение об ошибке. (Если не придерживаться этого правила, то ошибка будет генерироваться на ошибку до бесконечности.)

Когда посылается ICMP сообщение об ошибке, оно всегда содержит IP заголовок и первые 8 байт IP датаграммы, которая вызвала генерацию ICMP ошибки. Это позволяет принимающему ICMP модулю установить соответствие между полученным сообщением, одним из конкретных протоколов (TCP или UDP из поля протоколов в IP заголовке) и с одним из конкретных пользовательских процессов (с помощью номера порта TCP или UDP, который содержится в TCP или UDP заголовке в первых 8 байтах IP датаграммы). В разделе "ICMP ошибка недоступности порта (ICMP Port Unreachable Error)" главы 6 мы рассмотрим это более подробно.

Сообщение об ошибке ICMP никогда не генерируется в ответ на:

1. ICMP сообщение об ошибке. (ICMP сообщение об ошибке, однако, может быть сгенерировано в ответ на ICMP запрос.)
2. Датаграмму, направляющуюся на широковещательный IP адрес (рисунок 3.9) или групповой адрес IP (адрес класса D, рисунок 1.5).
3. Датаграмму, которая посылается широковещательным запросом на канальном уровне.
4. Фрагмент, который не является первым. (Мы опишем фрагментацию в разделе "Фрагментация IP" главы 11.)
5. Датаграмму, адрес источника которой не указывает на конкретный хост. Это означает, что адрес источника не может быть нулевым, loopback адресом, широковещательным или групповым адресом.

тип	код	Описание	запрос	ошибка
0	0	эхо-отклик (отклик-Ping, глава 7)	·
3		назначение недоступно:
	0	сеть недоступна - network unreachable (раздел "ICMP ошибки о недоступности хоста и сети" главы 9)		·
	1	хост недоступен - host unreachable (раздел "ICMP ошибки о недоступности хоста и сети" главы 9)		·
	2	протокол недоступен - protocol unreachable		·
	3	порт недоступен - port unreachable (раздел "ICMP ошибка недоступности порта (ICMP Port Unreachable Error)" главы 6)		·
	4	необходима фрагментация, однако установлен бит “не фрагментировать”- fragmentation needed but don’t-fragment bit set (раздел "ICMP ошибки о недоступности" главы 11)		·
	5	не работает маршрутизация от источника - source route failed (глава 8, раздел "Опция IP маршрутизации от источника")		·
	6	неизвестна сеть назначения - destination network unknown		·
	7	неизвестен хост назначения - destination host unknown		·
	8	хост источник изолирован - source host isolated		·
	9	сеть назначения закрыта администратором - destination network administrativrly prohibited		·
	10	хост назначения закрыт администратором - destination host administrativrly prohibited		·
	11	сеть недоступна для TOS - network unreachable for TOS (глава 9, раздел "ICMP ошибки о недоступности хоста и сети")		·
	12	хост недоступен для TOS - host unreachable for TOS (глава 9, раздел "ICMP ошибки о недоступности хоста и сети")		·
	13	связь административно закрыта путем фильтрации - communication administratively prohibited by filtering		·
	14	нарушено старшинство для хоста - host precedence violation		·
	15	старшинство разъединено - precedence cutoff in effect		·
4	0	подавление источника (элементарное управление потоком данных) - source quench (глава 11, раздел "ICMP ошибка подавления источника")		·
5		перенаправление - redirect (глава 11, раздел "ICMP ошибка подавления источника"):
	0	перенаправление в сеть - redirect for network		·
	1	перенаправление в хост - redirect for host		·
	2	перенаправление для типа сервиса и сети - redirect for type-of-service and network		·
	3	перенаправление для типа сервиса и хоста - redirect for type-of-service and host		·
8	0	эхо запрос - echo request (Ping запрос, глава 7)	·
9	0	объявление маршрутизатора - router advertisement (глава 9, раздел "ICMP сообщения поиска маршрутизатора")	·
10	0	запрос к маршрутизатору - router solicitation (глава 9, раздел "ICMP сообщения поиска маршрутизатора")	·
11		время истекло - time exceeded:
	0	время жизни стало равным 0 в процессе передачи - time-to-live equals 0 during transit (Traceroute, глава 8)		·
	1	время жизни стало равным 0 в процессе повторной сборки - time-to-live equals 0 during reassembly (глава 11, раздел "Фрагментация IP")		·
12		проблемы с параметрами - parameter problem:
	0	неверный IP заголовок - IP header bad		·
	1	отсутствует необходимая опция - required option missing		·
13	0	запрос временной марки - timestamp request (глава 6, раздел "ICMP запрос и отклик временной марки")	·
14	0	отклик с временной маркой - timestamp reply (глава 6, раздел "ICMP запрос и отклик временной марки")	·
15	0	информационный запрос - information request	·
16	0	информационный отклик - information reply	·
17	0	запрос маски адреса - address mask request (глава 6, раздел "ICMP запрос и отклик маски адреса")	·
18	0	отклик с маской адреса - address mask reply (глава 6, раздел "ICMP запрос и отклик маски адреса")	·

Рисунок 6.3 Типы сообщений ICMP.

 

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

 

ICMP запрос и отклик маски адреса

 

ICMP запрос маски адреса используется бездисковыми системами, чтобы получить маску подсети (глава 3, раздел "Маска подсети") во время загрузки. Система посылает широковещательный ICMP запрос. (Это напоминает то, как бездисковые системы с использованием RARP получают свои IP адреса во время загрузки.) Альтернативный метод для бездисковых систем получить маски своих подсетей - протокол BOOTP, о котором рассказано в главе 16. На рисунке 6.4 показан формат ICMP запроса и отклика маски адреса.

 

ICMP запрос и отклик временной марки

 

ICMP запрос временной марки позволяет системе запросить другую систему о текущем времени. Рекомендуемое значение, которое должно быть возвращено, это количество миллисекунд, которые прошли с полуночи в формате UTC, (Универсальное согласованное время - Coordinated Universal Time). (В старых руководствах UTC называется Среднее время по Гринвичу - Greenwich Mean Time.) Одна из основных особенностей ICMP сообщения заключается в том, что оно предоставляет время в с точностью до миллисекунд, тогда как другие методы используемые для получения времени от удаленных систем (например, команда rdate, существующая в некоторых UNIX системах) предоставляют время с точностью до секунд. Недостаток заключается в том, что сообщается только время, прошедшее с полуночи, - запрашивающая система должена знать текущую дату. На рисунке 6.6 показан формат ICMP запроса и формат ICMP отклика временной марки.

 

Рисунок 6.6 ICMP запрос и отклик временной марки.

 

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