Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012

Способ формирования кадра показан на рис.9.1. Здесь приве­ дены стандартный IP-пакет, один байт которого тождествен симво­ лу «END», а другой - символу «SLIP ESC»f и соответствующий ему кадр SLIP-протокола, который больше на 4 байта. SLIP-протокол не определяет максимально допустимую длину «информационного поля» передаваемого «кадра», однако, реальный размер «вклады­ ваемого в кадр» пакета IP не должен превышать 1006 байтов. Данное ограничение связано с первой реализацией SLIP-протокола в соот­ ветствующей ОС BERKLEY UNIX, и поэтому соблюдение его необ­ ходимо для обеспечения требуемой совместимости разных реализа­ ций (версий) SLIP-протокола.

Недостатки SLIP-протокола:

ово-первых, SLIP-протокол не обеспечивает обмен адресной информацией. Это ограничение не позволяет использовать SLIP-протокол для некоторых видов сетевых услуг;

•во-вторых, отсутствие индикации типа протокола, пакет кото­ рого «вкладывается» в кадр SLIP. Поэтому через последова­ тельную линию по SLIP-протоколу можно передавать трафик лишь одного сетевого протокола;

ов-третьих, в SLIP-протоколе не предусмотрены процедуры об­

наружения и коррекции ошибок. Эти функции обеспечивают протоколы вышележащих уровней.

Протокол сжатия служебной информации CSLIP (Com­ pressed SLIP). Для повышения эффективности использования про­ пускной способности линий связи применяются алгоритмы сжатия данных (например, за счет уменьшения объема служебной информа­ ции, содержащейся в заголовках IP-пакетов). Такую задачу решает протокол CSLIP. При использовании протоколов типа TELNET для доставки одного байта данных требуется переслать 20-байтовый заго­ ловок IP-пакета и 20-байтовый заголовок TCP-блока (итого 40 байт). CSLIP-протокол обеспечивает сжатие 40-байтового заголовка до 3-5 байт. Поэтому большинство реализаций протокола SLIP под­ держивают спецификацию CSLIP-протокола.

9.2. Протокол канального уровня РРР

(Point-to-Point Protocol)

РРР-протокол (RFC-1661) был разработан Инженерной про­ блемной группой Internet и пришел на смену устаревшему SLIPпротоколу.

Общая характеристика протокола. В отличие от SLIP-протокола

РРР-протокол может работать не только с интерфейсом RS-232, но и с другими интерфейсами между ООД и АКД (RS-422, RS-423 и V.35).

РРР-протокол может работать без управляющих сигналов модемов (таких, как «Request to Send», «Clear to Send», «Data Terminal Ready»). Единственное жесткое требование, предъявляемое РРР-протоколом к линии связи, - обеспечение дуплексного соединения.

РРР-протокол включает:

вспособ обрамления пакетов протоколов сетевого уровня и формирования кадров для передачи по линии связи;

опротокол Link Control Protocol (LCP, RFC-1471) для установле­ ния, конфигурирования и тестирования соединения;

©протоколы сетевого управления Network Control Protocols (NCP, RFC-1473 и RFC-1474) для установления и конфигуриро­ вания процедур передачи сообщений, поступивших из сетей, которые функционируют по различным сетевым протоколам.

Логическая характеристика протокола. Формат кадра РРРпротокола (рис. 9.2) аналогичен формату кадра HDLC и включает:

офлаг (01111110);

ополе «Адрес» (11111111)}

ополе «Управление» (00000011);

ополе «Протокол» (2 байта), значение которого определяется типом пакета, содержащегося в поле «Информация» (рис. 9.3);

ополе «Информация» (до 1500 байтов);

ополе «Контрольная сумма (проверка)» (2 байта; Cyclic Redundan­ cy Code).

Рис. 9.2. Формат кадра РРР-протокола

Если биты кадра РРР-протокола передаются последователь­ но, тогда, в случае появления между флагами последовательностей из пяти идущих подряд бит «1», после каждой такой последователь­ ности вставляется «0»-й бит, чтобы избежать имитации комбинации «флаг». На приемной стороне конце «0»-е биты отбрасываются.

Если кадр РРР-протокола передается через физический ин­ терфейс параллельно (блоками с числом битов, кратным 8, с целью обеспечения цикловой синхронизации), тогда, в случае появления между «флагами» байтов со значениями «7Е», «7D» (значения симво­ ла «ESC») и значениями «XX», меньшими 20 (значения управляю­ щих символов кода ASCII), происходят следующие замены:

байт «7Е» заменяется «7D», «5Е»; байт «7D» - «7D», «5D»;

байты «XX» со значениями, меньшими 20, - «XX», «01».

опроверка целостности данных;

оподдержка динамического обмена адресами IP;

овозможность сжатия заголовков пакетов IP и TCP с помощью алгоритмов, которые похожи на тот, который реализован в CSLIP-протоколе.

Рис. 9.4. Блок-схема алгоритма функционирования РРР-протокола

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

Вшироком смысле 1Ру4-протокол базируется на нескольких стандартах RFC и определяет:

оформат пакета IPv4 (логическая характеристика протокола);

оспособы распространения (маршрутизации) пакетов (проце­ дурная характеристика протокола);

оспособы разрешения конфликтных ситуаций (процедурная характеристика протокола).

Рис. 10.1. Формат пакета 1Ру4-протокола

10.2. Структура 1Ру4-пакета (логическая характеристика протокола)

Пакет 1Ру4-протокола состоит из заголовка и блока данных (рис. 10.1). 1Ру4-протокол «работает» только с заголовком. Рассмот­ рим более подробно кодирование полей заголовка:

°4-Битовое поле «Версия IP-протокола» используется для устране­ ния конфликтов, которые могут возникать при изменении версии IP-протокола, когда часть IP-узлов работает по одной, а часть - по другой версии протокола. Если поле «Версия» со­ держит значение, отличное от текущей версии протокола, па­ кет уничтожается. Текущей является четвертая версия IP;

0Поле «Длина заголовка» дает значение длины заголовка пакета, измеренное в 32-битовых словах. Это поле предусматривает

изменение длины заголовка в соответствии с полями «Услуги» (переменной длины) и «Дополнение (нули) поля «Услуги» до 32-битовой границы»;

вПоле «Категория обслуживания пакета» представлено на рис. 10.2. Оно включает:

-сегмент «Приоритет» (3 бита). Может принимать восемь зна­ чений: от 0 (обычный приоритет) до 7 (сетевое управление);

-биты «D», «Г», «R». Они указывают на тип транспортиров­ ки, который «запрашивает» пакет. Установка этих битов в состояние «1» требует соответственно низкой задержки при передаче пакета (delay), высокой пропускной способности (throughput) и высокой надежности (reliability). Последние два бита не используются.

Рис. 10.2. К о д и р о в а н и е п о л я « К а те го р и я о б с л у ж и в а н и я п акета»

Нужно отметить, что поле «Категория обслуживания пакета» не всегда используется маршрутизаторами, хотя может приме­ няться для оптимизации транспортной службы;

оПоле «Длина пакета в октетах вместе с заголовком» задает пол­ ную (включая заголовок и данные) длину пакета, измеренную

воктетах (байтах). Полная длина пакета IP принципиально может достигать 65535 байтов;

оIP-протоколу, обеспечивающему межсетевое взаимодействие, приходится сталкиваться с различиями в конкретных физиче­ ских сетях, одним из которых является ограничение на макси­ мальную длину кадра (MTU1). Поэтому IP-протокол также реша­ ет задачу деления (фрагментирование - fragmentation) больших пакетов на малые (и наоборот, их сборку). Это требуется делать в тех случаях, когда на вход некоторой физической сети поступает пакет, превосходящий по длине для данной сети.

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

1 M T U (m a xim u m tra n sm issio n unit) - м а к си м ал ьн о д о п у ст и м ы й разм ер пе­ редаваем ой е д и н и ц ы д а н н ы х дл я оп ре д е л ен н ой л и н и и (канала) связи (link), то есть м а к си м а л ь н ы й разм ер пакета в октетах, к о то р ы й м ож ет быть п ередан п о оп ре д е л ен н ой л и н и и (каналу) связи

заголовка не превышал размера кадра MTU для физической сети, в которую направляются фрагменты. При этом фрагмен­ ты упаковываются в пакеты, заголовки которых очень похожи на заголовок исходного пакета. Чтобы понять, что данные па­ кеты содержат фрагменты одного большого пакета, и обеспе­ чить его последующую сборку, производится установка спе­ циальных признаков в поле «Индикатор «Еще данные»; байты, по которым разрезался исходный блок данных, помещаются в по­ ле «Номер байта, на котором произведена очередная фрагментация исходного «большого» пакета»; а в поле «Идентификатор переда­ ваемого исходного «большого» пакета» записывается один, общий для всех фрагментов, идентификатор, указывающий на при­ надлежность фрагментов к одному «большому» блоку данных;

вПоле «Время «жизни» пакета в сети» указывает максимальное число ретрансляционных участков, которые может преодолеть пакет до прибытия в IP-узел/получатель. IP-узлы, обрабаты­ вающие данный пакет, уменьшают значения этого поля в пе­ риод обработки и хранения пакета на единицу. Когда послед­ ний ретрансляционный участок преодолён (значение в поле нулевое), а пакет не достиг получателя, пакет уничтожается. При этом источник сообщения уведомляется о потере пакета. Наличие конечного времени жизни (конечного числа ретрансляционных участков) пакета обеспечивает, в частно­ сти, защиту от таких нежелательных событий, как передача пакета по циклическому маршруту, перегрузка сетей;

©Поле «Тип транспортного протокола ТСР/1ГОР» (8 битов) - ука­ зывает протокол вышележащего уровня, которому предназна­ чена информация, содержащаяся в поле данных пакета IP (TCP-протокол - «6», UDP-протокол - «17»);

оПоле «Контрольной проверки заголовка пакета» (16 битов) - исполь­ зуется для контроля целостности заголовка пакета IP-протокола;

оПоле «Адрес отправителя» (32 бита) - IP-адрес отправителя пакета;

оПоле «Адрес получателя» (32 бита) - IP-адрес получателя пакета; 0 Поле «Услуги» (изменяемая длина) - применяется для указания необязательных параметров IP-протокола, связанных, напри­

мер, с режимами безопасности или маршрутизации; 0 Поле «Дополнение (нули) поля «Услуги» до 32-битовой границы»

(изменяемая длина) - дополняет заголовок пакета таким обра­ зом, чтобы он составлял целое число 32-битовых слов.

10.3. Адреса IP

Физические объекты (IP-узлы, маршрутизаторы, серверы, под­ сети) в IP-сети идентифицируются при помощи имен, называемых IP-адресами.

IP-адреса представляют собой 32-битовые идентификаторы, структура которых оптимизирована для решения основной задачи протокола IP-маршрутизации. Обычно для удобства представления IP-адресов используется так называемое цифровое написание IP-адресов, когда адрес записывается как десятичное представление четырёх байтов, разделенных точками, например 192.171.153.60.

В общем случае каждый адрес можно представить как пару идентификаторов - номер сети и номер IP-узла. Практически каж­ дый IP-адрес должен быть представлен в виде одной из первых трех показанных на рис. 10.3 битовых структур.

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

Класс А определен для сетей с огромным (от 65535 до 16777215) числом IP-узлов. В адресе этого класса 7 бит отведены под номер се­ ти, а 24 бита - под номер 1Р-узла.

Адреса класса В используются для среднемасштабных сетей, в которых содержится от 256 до 65 536 IP-узлов; под номер сети и но­ мер IP-узла отводится 14 и 16 битов соответственно.

Рис. 10.3. Структура и классы 1Ру4-адресов

Адреса класса С предназначены для сетей с числом IP-узлов ме­ нее 256, под номер IP-узла отведено 8 бит и под номер сети - 21 бит.

Структура IP-адресов ориентирована на определенное сетевое соединение, а не на IP-узел, что вызвано в первую очередь необхо­ димостью обеспечения высокой эффективности маршрутизации IP-пакетов. Следовательно, при «перемещении» IP-узла из одной подсети в другую у него должен быть обязательно изменен 1Р-адрес.

IP-адресация включает специальные адреса, обращенные к со­ вокупности IP-узлов и/или сетей. Среди таких адресов различают два класса: широковещательные (broadcast), обращенные «ко всем», и групповые (multicast), обращенные к заданному множеству объек­

тов. Сущность этого класса адресации заключается в заполнении адресных полей нулями (обращение к данному объекту) или еди­ ницами (обращение ко всем объектам).

Формируемые по этим правилам специальные 1Ру4-адреса по­ казаны на рис.10.4.

Адрес 1 может использоваться в процедуре инициализации, ко­ гда рабочая станция не знает (при согласовании) своего 1Ру4-адреса. Этот тип применяется только как адрес отправителя, но никогда как адрес получателя пакета.

Адрес 2, в котором номер сети заполнен нулями, а номер 1Р-узла имеет определенное значение, есть адрес конкретного IP-узла в сети, из которой он получил пакет. Применение такого адреса возможно в том случае, когда IP-узел/отправитель не знает номер сети, в которой работает. (Такая ситуация возможна, например, при инициализации бездисковой рабочей станции, которая при включении в сеть вообще «ничего не знает» ни о сети, ни о себе.) Этот адрес используется только как адрес получателя и никогда как адрес отправителя.

Тип ад р е с а Н о м ер сети Н о м ер ГВ М

Рис. 10.4. Специальные 1Ру4-адреса

Адрес 3, в котором номер сети имеет некоторое значение, а но­ мер IP-узла заполнен нулями, трактуется IP-протоколом как адрес некоторой сети (но, ни одного из IP-узла данной сети, поскольку со­ стоящий из нулей номер IP-узла запрещен).

Адрес 5, в котором номер сети имеет некоторое значение, а но­ мер IP-узла заполнен единицами, называется прямым широковеща­ тельным адресом (direct broadcast address), обращенным ко всем IP-узлам в данной подсети. Вместе с ним, в качестве широковеща­ тельного, может также применяться локальный или ограниченный адрес (limited, или local broadcast address), целиком заполненный единицами (адрес 4), используемый в том случае, когда номер сети по каким-либо причинам неизвестен. Использование этого адреса не рекомендуется.

Адрес 6 - адрес контрольного пакета (loopback address - «пет­ левой адрес»), в котором первый байт имеет значение «11111110», а оставшееся поле обычно заполняется единицами. Он используется