Чернега В., Платтнер Б. Компьютерные сети. Учебное пособие для вузов

Подождите немного. Документ загружается.

Раздел 4. Компьютерная сеть Интернет

319

в точечной десятичной форме, а затем через косую черту – длина маски в

битах, выраженная целым десятичным числом.

Предположим, организации выделен непрерывный блок IP-адресов в

количестве 2048, начиная с адреса 128.211.168.0. Пусть для адресации хос-

тов должно использоваться 11 младших битов этого адреса. В таблице 4.3

приведены значения первого и последнего адресов диапазона, представлен-

ные в точечной десятичной и в двоичной форме.

Таблица 4.3 – Границы IP-адресов диапазоном 2048 хостов

Граница

адреса

IP-адрес Двоичный эквивалент

Нижняя 128.211.168.0 10000000 11010011 10101000 00000000

Верхняя 128.211.175.255 10000000 11010011 10101111 11111111

Для определения блока адресов в CIDR, показанного в таблице 4.3, не-

обходимо задать 32-разрядное значение начального адреса блока и 32-

разрядную маску. В CIDR-маске рассматриваемого примера необходимо ус-

тановить в единицу первые 21 бит, т.е. 11111111 11111111 11111000

00000000. Это означает, что граница раздела между префиксом и суффиксом

будет проходить по 21 биту, префикс занимает первые 21 бит двоичного

числа, а суффикс – последние 11 битов. В сокращенной форме записи CIDR

блок адресов, приведенный в таблице 4.3, будет выглядеть так:

128.211.168.0/21. Здесь запись /21 означает, что длина маски префикса равна

21 биту.

При использовании CIDR провайдер, получивший в свое распоряже-

ние набор IP-адресов, может выделить из этого набора каждому из своих

клиентов блок адресов требуемого размера и указать им соответствующие

сетевые маски. Если провайдеру предоставлен набор адресов, CIDR-маска

которого имеет длину N битов, то он может выделить своим клиентам блок

адресов любой длины, однако CIDR-маска этого блока должна быть больше

N битов. Например, если провайдеру выделен набор адресов 128.211.0.0/16,

он вполне может предоставить одному из своих клиентов блок из 2048 адре-

сов 128.211.168.0/21, как показано в таблице 4.3. При запросе от представи-

теля малого предприятия, которому нужно два-три IP-адреса, чтобы под-

ключить несколько компьютеров к Интернету, провайдер может выделить

ему другой блок адресов 128.211.176.212/30, диапазон которых приведен в

таблице 4.4. Очевидно, что использование битовой маски переменной длины

позволяет более гибко выделять блоки IP-адресов, чем это было при исполь-

зовании классовой системы адресации.

Компьютерные сети

320

Таблица 4.4 – Границы IP-адресов диапазоном 4 хоста

Граница

адреса

IP-адрес Двоичный эквивалент

Нижняя 128.211.176.212 10000000 11010011 10110000 11010100

Верхняя 128.211.176.215 10000000 11010011 10110000 11010111

Технология CIDR в настоящее время встроена в магистральные Ин-

тернет-маршрутизаторы, работающих с протоколом BGP, а обычные хосты в

локальных сетях ее не поддерживают.

4.5. Протокол передачи управляющих сообщений ICMP

4.5.1. Назначение и формат управляющих сообщений

В процессе обмена информацией в объединенной IP-сети возможно

появление ошибок передачи, отказов аппаратного и программного обеспече-

ния, возникновение условий и ситуаций, требующих принятия определен-

ных мер. Для реализации механизма реагирования на такие ситуации разра-

ботан протокол передачи управляющих сообщений ICMP (Internet

Control Message Protocol). На данный протокол возлагаются только функции

информирования об особых случаях в сети, а не локализация и устранение

причин, которые привели к возникновению аномальных ситуаций. При об-

наружении тех или иных проблем промежуточные маршрутизаторы или ко-

нечные станции генерируют сообщения ICMP того или иного типа, указывая

в них код ошибки, и передают отправителю исходного пакета. ICMP выпол-

няет следующие функции:

 передает отклик на пакет или эхо на отклик;

 контролирует время жизни дейтаграмм в системе;

 реализует переадресацию пакета;

 выдает сообщения о недостижимости адресата или о некорректности

параметров;

 формирует и пересылает временные метки;

 выдает запросы и отклики для адресных масок и другой информации.

Для передачи сообщений протокола ICMP по объединенной сети ис-

пользуются IP-дейтаграммы обычного формата. Сообщение ICMP в данном

случае помещается (инкапсулируется) в поле данных IP-дейтаграммы (ри-

сунок 4.25).

Раздел 4. Компьютерная сеть Интернет

321

Сообщение ICMP состоит из заголовка и собственно информационно-

управляющего сообщения (рисунок 4.26).

Заголовки всех сообщений ICMP имеют примерно одинаковый фор-

мат. Заголовок может занимать до 8 байтов (два 32-х разрядных слова). В

нем размещается идентификатор типа сообщения ICMP. Существует 255

различных значений поля "Тип сообщения", которые указывают на конкрет-

ный тип ICMP-сообщения. В настоящее время используется порядка 25 ти-

пов. Остальные зарезервированы для будущего применения. Для детализа-

ции некоторых типов сообщений введено поле "Код" сообщения. Контроль-

ная сумма вычисляется суммированием всех полей, начиная с поля "Тип".

При формировании проверочной суммы значение поля "Контрольная сумма"

полагается равным 0. Информационно-управляющая часть сообщения ICMP

не имеет фиксированной длины, поэтому размер данного поля определяется

только типом сообщения.

4.5.2. Типы управляющих сообщений

Сообщения ICMP можно условно разделить на парные и непарные.

Парные сообщения состоят из двух компонентов – запрос (Request) и ответ

(Reply). Сообщение типа "Ответ" высылается станцией назначения только в

ответ на полученное от источника сообщение типа "Запрос". К сообщениям

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

Рисунок 4.26

–

Формат ICMP

сообщения

Компьютерные сети

322

такого типа относятся "Эхо запрос/ответ". Непарные сообщения формиру-

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

дейтаграммы, и передаются в адрес источника данной дейтаграммы. К со-

общениям подобного типа относятся сообщения "Место назначения недос-

тупно" и "Подавление источника".

Следует заметить, что сообщение об ошибке ICMP никогда не генери-

руется в ответ на следующие ситуации:

1) ICMP сообщение об ошибке (однако, ICMP-сообщение об ошибке мо-

жет быть сгенерировано в ответ на ICMP-запрос);

2) дейтаграмму, направляющуюся на широковещательный IP-адрес или

групповой адрес IP;

3) дейтаграмму, посылаемую широковещательным запросом на каналь-

ном уровне;

4) фрагмент, который не является первым.

5) дейтаграмму, адрес источника которой не указывает на конкретный

хост; это означает, что адрес источника не может быть нулевым, loopback

адресом, широковещательным или групповым адресом.

Данные правила введены с целью предотвращения лавинообразного

роста количества широковещательных сообщений, который может произой-

ти, если ICMP сообщения об ошибках будут отправляться в ответ на широ-

ковещательные пакеты.

В таблице 4.5 приведены числовые значения поля "Тип ICMP" и пояс-

нение типов сообщений, соответствующих этим значениям. Поясним значе-

ния некоторых сообщений. Сообщение "Место назначения недоступно"

принадлежит к непарным сообщениям ICMP. Его формат показан на рисунке

4.27. Оно формируется в случае, если требуемый сетевой ресурс недоступен

для запрашивающей его станции. В поле "Код" сообщения "Место назначе-

ния недоступно" размещается код, который соответствует типу запрошен-

ного недоступного сетевого ресурса или конкретизирует причину, из-за ко-

торой этот ресурс недоступен в данном случае. Возможные также значения

поля "Код": 0 – сеть недоступна; 1 – хост недоступен; 3 – порт недоступен; ...

12 – хост недоступен для данного типа обслуживания.

Сообщения данного типа могут быть сформированы как станцией на-

значения ("Код"=2 и 3), так и одним из промежуточных маршрутизаторов –

шлюзов ("Код"=0,1,6 и т.д.). При этом в качестве адреса источника указыва-

ется IP-адрес узла, который обнаружил проблему. Например, сообщение

"Хост недоступен" может быть сформировано последним маршрутизатором,

который пытается доставить сообщение до хоста по непосредственно под-

ключенной сети. Для того, чтобы станция-источник смогла правильно ин-

терпретировать диагностическое сообщение, в тело сообщения "Место на-

значения недоступно" помещается заголовок и первые 8 байтов исходной

Раздел 4. Компьютерная сеть Интернет

323

дейтаграммы.

Сообщения типа 3 с кодом 3 "Порт недоступен" отправляется источ-

нику, если протокол UDP в процессе приема дейтаграммы обнаружил, что

порт назначения не соответствует порту, который обслуживается каким–

либо процессом, либо порт закрыт для доступа.

Таблица 4.5 – Сообщения протокола ICMP

Тип сообщения Сообщение

0 Эхо-отклик (Echo Reply)

3 Место назначения не достижимо (Destination Unreachable)

4 Подавление источника (Source Quench)

5 Перенаправление (Redirect)

8 Эхо-запрос (Echo Request)

9 Объявление маршрутизатора (Router Advertisement)

10 Запрос к маршрутизатору (Router Solicitation)

11 Время истекло (Time Exceeded)

12 Проблемы с параметрами (Parameter Problem)

13 Запрос временной метки (Timestamp Request)

14 Отклик с временной меткой (Timestamp Reply)

15 Информационный запрос (Information Request)

16 Информационный отклик (Information Reply)

17 Запрос маски адреса (Address Mask Request)

18 Ответ с маской адреса (Address Mask Reply)

Сообщение "Время истекло" относится к непарным сообщениям

ICMP. Оно формируется в том случае, если в процессе передачи дейтаграм-

мы истекло допустимое время её существования в сети или на хосте.

Сообщение "Проблемы с параметрами" также принадлежит к непар-

Рисунок 4.27 – Формат управляющего сообщения "Место назначения недоступно"

Компьютерные сети

324

ным сообщениям ICMP. Такое сообщение формируется в ситуации, если в

процессе обработки заголовка дейтаграммы на хосте или маршрутизаторе

были обнаружены некорректные аргументы, делающие невозможным даль-

нейшее перемещения дейтаграммы. В этом случае дейтаграмма уничтожает-

ся, а в адрес её источника передается сообщение Parameter Problem (рисунок

4.28).

Рисунок 4.28 – Вид управляющего сообщения "Проблема с параметром"

В поле "Код" данного сообщения размещается признак типа диагно-

стической информации. В том случае, если в этом поле находится код "0",

значение поля "Счетчик" (Pointer) сообщения Parameter Problem соответст-

вует номеру байта в заголовке исходного сообщения, который не может

быть адекватно интерпретирован. Например, значение Pointer=1, в данном

случае указывает на возникновение проблемы с интерпретацией поля "Тип"

исходного сообщения.

Значение поля Код=1 формируется в ситуации, когда причина, по ко-

торой данная дейтаграмма не может продолжать перемещение по сети, за-

ключается в несоответствии запрашиваемых параметров установленным

требованиям. Такими требованиями могут быть, в частности, требования по

обеспечению безопасности.

Сообщение "Сдерживание источника" принадлежит к непар-

ным сообщениям ICMP. Оно формируется в случае возникновения в процес-

се передачи дейтаграммы угрозы перегрузки. Источник, получив от станции

назначения или одной из промежуточных станций такое сообщение, должен

уменьшить скорость информационного обмена в указанном направлении.

При передаче сообщения "Сдерживание источника" в качестве адреса

назначения указывается IP-адрес источника первичного сообщения. Для того

чтобы станция-источник смогла правильно интерпретировать диагностиче-

ское сообщение, в тело сообщения Destination Unreachable помещается заго-

ловок и первые 8 байтов исходной дейтаграммы.

Сообщение "Изменение маршрута" (Redirect) относится к непар-

ным сообщениям ICMP. Оно формируется в случае, если при получении

дейтаграммы шлюз обнаруживает, что для её передачи был выбран неудач-

Раздел 4. Компьютерная сеть Интернет

325

ный маршрут. На рисунке 4.29 показан пример использования сообщения

Redirect для изменения неоптимального маршрута.

На схеме хост А (10.40.0.2) отправляет дейтаграмму в направлении

хоста В (10.10.0.2), используя для этого в качестве шлюза маршрутизатор

М2. После того, как маршрутизатор М2 получает дейтаграмму, он определя-

ет, что данная дейтаграмма адресована в направлении сети 10.10.0.0. Крат-

чайший маршрут достижения этой сети для маршрутизатора М2 проходит

через маршрутизатор М4, который в данном случае подключен к тому сег-

менту сети, из которого была получена принятая дейтаграмма.

Маршрутизатор М2 перенаправляет дейтаграмму по направлению М4,

одновременно формирует командное сообщение ICMP Redirect (штрихоая

стрелка), в котором он рекомендует хосту А впредь для передачи дейта-

грамм в направлении сети 10.10.0.0 использовать в качестве шлюза маршру-

тизатор М4. Команды переадресации маршрутизатор посылает только хосту

и никогда другим маршрутизаторам. В заголовке сообщения ICMP Redirect

размещается IP-адрес шлюза, рекомендуемый для использования с целью

достижения сетевого ресурса, указанного в исходной дейтаграмме и тип

маршрута, который должен быть изменен по предложению источника сооб-

щения ICMP.

Рисунок 4.29 – Пример использования сообщения «Изменение маршрута»

Компьютерные сети

326

Сообщения типа "Эхо" (Echo) принадлежат к парным сообщениям

ICMP. Они применяются для определения возможности достижения и стату-

са компонентов сети Интернет. Любой компонент сети, получивший адресо-

ванное ему сообщение Echo Request, формирует ответное сообщение Echo

Reply в адрес источника полученного сообщения.

Это сообщение используется в простых утилитах Ping, которые посы-

лают одно сообщение Echo Request в адрес назначения и указывают на полу-

чение ответного сообщения Echo Reply. Более сложные утилиты формируют

несколько последовательных сообщений Echo Request и измеряют значение

интервала времени, разделяющего момент передачи этих сообщений от мо-

мента приема соответствующих ответных сообщений.

Сообщения Echo Request и Echo Reply имеют одинаковый формат (ри-

сунок 4.30) и отличаются только содержимым поля "Тип".

Рисунок 4.30 – Вид управляющего сообщения "Эхо запрос"

Значение поля Тип = 0 соответствуют сообщению Echo Reply, а Тип =

8 – Echo Request. В поле "Код" сообщений Echo Request/Reply устанавлива-

ется значение 0. Поля "Идентификатор" (обычно это идентификатор процес-

са) и "Номер последовательности" (увеличивается на 1 при посылке каждого

пакета) служат для того, чтобы отправитель мог связать в пары запросы и

отклики.

Сообщения "Запрос и ответ временной метки" (Timestamp

Request/Reply) принадлежат к парным сообщениям ICMP. Они предназнача-

ются для обеспечения взаимной синхронизации счетчиков времени у раз-

личных компонентов сети Интернет.

Поскольку компоненты Интернета не имеют общего управления, зна-

чения индивидуальных датчиков времени у каждого из компонентов могут

существенно отличаться. Для обеспечения взаимной синхронизации таких

датчиков используются сообщения Timestamp Request/Reply. Сообщения "За-

прос" и "Ответ" имеют одинаковый формат и отличаются только содержи-

мым поля "Тип". Значение Тип = 14 соответствуют сообщению Timestamp

Раздел 4. Компьютерная сеть Интернет

327

Reply, а Тип = 13 – Timestamp Request (рисунок 4.31).

Рисунок 4.31 – Управляющее сообщение для запроса и приема ответа временной метки

В полях "Идентификатор" и "Номер последовательности" помещаются

кодовые комбинации, которые позволяют станции назначения установить

соответствие между переданными и полученными сообщениями.

В поле сообщения "Исходная временная метка" (Originate Timestamp)

отправитель помещает состояние своего датчика времени в момент отправки

управляющего сообщения. В момент получения этого сообщения станция

назначения помещает в поле "Временная метка приема" (Receive Timestamp)

отсчет собственного датчика времени. Значения этих полей отвечающая

станция копирует в соответствующие поля возвращаемого сообщения

Timestamp Reply.

Поле "Временная метка передачи" (Transmit Timestamp) ответного со-

общения формируется в момент отправки этого сообщения в адрес отправи-

теля исходного запроса. Значение поля "Временная метка передачи" в дан-

ном случае будет соответствовать значению счетчика времени Timestamp

Request-сервера в момент отправки сообщения.

Получив сообщение Timestamp Request, отправитель запроса может

определить величину задержки распространения между ним и сервером и,

таким образом, сформировать поправку к своему датчику времени. Значения

временных меток, возвращаемых по соответствующим запросам, измеряется

в миллисекундах, которые прошли с полуночи в формате UTC (Универсаль-

ное согласованное время – Coordinated Universal Time. В старых руково-

дствах UTC называется Среднее время по Гринвичу – Greenwich Mean

Time.).

Использование описанного метода синхронизации датчиков времени

не может обеспечить достаточной точности в связи с тем, что задержки рас-

пространения сигналов в прямом и обратном направлениях могут сущест-

венно отличаться и изменяться во времени. Поэтому для обеспечения на-

дежной взаимной синхронизации датчиков времени должны быть использо-

ваны несколько сессий синхронизации.

Компьютерные сети

328

При подключении к сети хост может не знать адреса своего маршрути-

затора. Для получения этой информации он отправляет широковещательно

или по групповому адресу "всем маршрутизаторам" сообщение-запрос типа

10 "Запрос к маршрутизатору". В ответ на это маршрутизаторы должны от-

ветить сообщением типа 9 "Объявление маршрутизатора". Маршрутизаторы

могут также, не дожидаясь запросов, периодически рассылать объявления о

маршрутах (сообщение типа 9) по групповому адресу "всем хостам". Такие

объявления содержат адреса одного или нескольких маршрутизаторов,

снабженных значениями приоритета для каждого маршрутизатора.

4.5.3. Протокол ICMPv6

С появлением протокола IPv6 был разработан протокол передачи

управляющих сообщений 6-й версии ICMPv6, получивший номер 58. Прото-

кол ICMPv6 отличается от ICMPv4 только теми параметрами, которые на-

прямую связаны со структурой IP-пакета. В частности, изменились иденти-

фикатор ICMPv6, определяющий тип заголовка (Next Header), коды типов

сообщений ICMPv6, добавились параметры для типов сообщений, работаю-

щих с вложенными заголовками и т. д. Подробное описание ICMPv6 можно

найти в RFC-1885.

Таблица 4.6 – Сообщения об ошибках в протоколе ICMPv6

Тип

ошибки

Сообщение

1 Место назначения не достижимо (Destination

Unreachable). Более точная спецификация места назна-

чения задается кодом ошибки.

2 Пакет слишком большой (Paket to Big). Пакет является

слишком большим для сегмента сети, так как он превы-

шает максимально допустимое значение MTU. Это сооб-

щение посылается только в случае установки флага "За-

прет фрагментации".

3 Превышение времени (Time Exceeded). Лимит хопов дос-

тиг нулевого значения и дейтаграмма отброшена.

4 Проблема с параметром (Parameter Problem). В заголовке

пакета имеются ошибки и он не может быть корректно

обработан.