Базовые протоколы семейства tcp/ip. Архитектура сети и маршрутизация

Прежде чем рассматривать вопросы маршрутизации в сетях IP, познакомимся с принципами, заложенными в основные протоколы IP-технологии. Для того, чтобы было понятно, как взаимодействуют протоколы семейства TCP/IP с физической сетью, разберем принципы взаимодействия устройств в сетях Ethernet.

Технология Ethernet. Кадр Ethernet содержит адрес назначения, адрес источника, поле типа и данные. Размер адреса Ethernet - 6 байтов. Каждый сетевой адаптер имеет свой сетевой адрес. Адаптер "слушает" сеть, принимает адресованные ему кадры, широковещательные кадры с адресом FF:FF:FF:FF:FF:FF и отправляет кадры в сеть.

Технология Ethernet реализует метод множественного доступа с контролем несущей и обнаружением столкновений. Этот метод предполагает, что все устройства взаимодействуют в одной среде. В каждый момент времени передавать может только одно устройство, а все остальные - только слушать. Если два или более устройства пытаются передать кадр одновременно, то фиксируется столкновение, и каждое устройство возобновляет попытку передачи кадра через случайный промежуток времени. Одним словом, в каждый момент времени в сегменте узла сети находится только один кадр.

Понятно, что чем больше компьютеров подключено в сегменте Ethernet, тем больше столкновений будет зафиксировано и тем медленнее будет работать сеть. Кроме того, если в сети стоит сервер, к которому часто обращаются, то это также снизит общую производительность сети.

Протокол АRР (Address Resolution Protocol). Протокол используется в локальных сетях для определения соответствия (отображения) IP-адреса адресу Ethernet. Отображение осуществляется только в момент отправления IP-пакетов, так как только в этот момент создаются заголовки IР и Ethernet. Отображение адресов осуществляется путем поиска в АRР-таблице. Упрощенная АRР-таблица состоит из двух столбцов:

IP-адрес	Ethernet-адрес
223.1.2.1	08:00:39:00:2F:C3
223.1.2.3	08:00:5A:21:A7:22
223.1.2.4	08:00:10:99:AC:54

В первом столбце содержится IP-адрес, а во втором Ethernet-адрес. Наличие таблицы соответствия необходимо, так как адреса назначаются произвольно и нет какого-либо алгоритма для их вычисления. Если машина перемещается в другой сегмент сети, то ее АКР-таблица должна быть изменена.

При работе в локальной IP-сети при обращении к какому-либо ресурсу сети, например архиву FTP, его Ethernet-адрес ищется по IP-адресу в АКР-таблице, и после этого запрос отправляется на сервер.

АRР-таблица формируется автоматически. Если нужного адреса в таблице нет, то в сеть посылается широковещательный запрос типа "Чей это 1Р- адрес?". Все сетевые интерфейсы получают этот запрос, но отвечает только владелец адреса. Широковещательный запрос выглядит так:

IP-адрес отправителя 223.1.2.1

Ethernet-адрес отправителя 08:00:39:00:2F:C3

Искомый IP-адрес 223.1.2.3

Искомый Ethernet-адрес <пусто>

Ответ машины, чей адрес ищется, будет выглядеть следующим образом:

IP-адрес отправителя 222.1.2.2

Ethernet-адрес отправителя 08:00:28:00:38:A9

IP-адрес получателя 223.1.2.1

Ethernet-адрес получателя 08:00:39:00:2F:C3

Полученный таким образом адрес будет добавлен в АRР-таблицу.

Далее IР-пакет для которого ищется адрес, может быть либо поставлен в очередь на отправку, либо уничтожен. В первом случае за отправку отвечает модуль АRР, а во втором случае - модуль IР, который повторяет посылку через некоторое время. Уничтожение пакета происходит в том случае, если искомого IP-адреса нет в локальной сети и сеть не соединена с другой сетью шлюзом. Для пересылки пакетов между сетями используется модуль IР, основанный на протоколе IР.

Межсетевой протокол IР. Модуль IР является базовым элементом технологии Internet. Его центральной частью является таблица маршрутов. Таблица маршрутов заполняется администратором сети и обычно инициализируется в момент загрузки системы. Когда речь идет о простой локальной IP-сети, то протокол IР мало что добавляет к услугам Ethernet, за исключением того, что в сети будут работать все прикладные программы, реализованные для IP-тexнологии. Однако ситуация меняется, если речь идет о сетях, сопряженных шлюзом. На рисунке 8.9 представлен стек протоколов шлюзовой машины:

На схеме представлен стек протоколов для машины, которая осуществляет пересылку пакетов из одной IP-сети в другую. Из схемы видно, что АRР-модуль имеет место для каждого сетевого интерфейса, в то время как IP-модуль общий для всех интерфейсов и прикладных программ.

При обсуждении работы модуля IP будем пользоваться примером, приведенным на рисунке 8.10. Адреса при этом заменим именами машин.

Указанные пути при пересылке пакетов в локальной сети называется прямой, а при пересылке пакетов через шлюз - косвенной. При прямой маршрутизации в качестве Ethernet-адреса в Ethernet-кадре указан адрес получателя пакета:

Адрес	Отправитель	Получатель
IP-заголовок	Apollo	Polyn
Enternet-заголовок	Apollo	Polyn

При косвенной адресации в качестве Ethernet-адреса получателя будет указан адрес шлюза:

Адрес	Отправитель	Получатель
IP-заголовок	Apollo	Quest
Enternet-заголовок	Apollo	Polyn

Шлюз проверяет IP-адрес получателя, и если он не совпадает с его собственным, то пытается переслать его через другой сетевой интерфейс. Шлюз никогда не будет пытаться послать пакет через тот интерфейс, через который пакет был принят. Термин "пытается" употреблен здесь в том смысле, что к моменту присылки пакета соответствие между IР -адресом получателя и его Ethernet-адресом еще может быть не установлено.

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

Обычно таблица маршрутов выглядит как набор строк типа:

Сеть или хост	Флаг типа маршрутизации	Шлюз	Имя интерфейса
127.0.0.1	прямая	пусто	lo
144.206.160.0	прямая	пусто	ed1
default	косвенная	144.206.160.32	ed1
Рис.8.11. Пример таблицы маршрутов (узел Polyn подсети 144.206.160.0)

На рисунке 8.11 приведена таблица маршрутов компьютера Apollo из подсети 144.206.160.0, который не является шлюзом и, следовательно, все пакеты, предназначенные для других сетей, должен транслировать на шлюз. Последняя строка таблицы отражает этот факт. Первая строка таблицы определяет "петлю", которая используется "местными" прикладными сетевыми программами для доступа к "своим" же локальным ресурсам.

Таблица маршрутов шлюза, которым является компьютер Polyn, будет выглядеть следующим образом:

Сеть или хост	Флаг типа маршрутизации	Шлюз	Имя интерфейса
127.0.0.1	прямая	пусто	lo
144.206.160.0	прямая	пусто	ed1
144.206.130.0	прямая	пусто	ed2
default	косвенная	144.206.130.3	ed2
Рис.8.12. Таблица шлюза Polyn

Из рисунка 8.12 видно, что компьютеры обеих подсетей прямо адресуются со шлюза Polyn. В то же время он использует шлюз Cpuvl для ретрансляции пакетов в другие сети.

Обычно таблица маршрутов создается при запуске системы (как это происходит в Unix) или при запуске TCP/IP модулей (как это происходит в MS-DOS).

При запуске системы обычно выполняется файл с именем "гс", который имеет ссылку на файл конфигурирования сетевых интерфейсов и создания таблицы маршрутов. В разных системах они называются по-разному. В системе HP-UX он называется, например, netinitrc. В этом файле обязательно будут команды ifconfig и route.

Команда ifconfig предназначена для назначения сетевым интерфейсам IР-адресов и прописывания в таблицу маршрутов сетей, к которым есть непосредственный доступ. Например, приведенная ниже команда назначит интерфейсу ed0 IP-адрес 144.206.160.40 и пропишет в таблицу маршрутов строку прямой маршрутизации в сеть 144.206.160.0 через интерфейс ed0:

ifconfig ed0 inet 144.206.160.40 netmask 255.255.224.0

Другой важной командой, дающей возможность администратору управлять информацией в таблице разделов, является команда route. Так, по команде:

route add default 144.206.160.32

все пакеты с машины, включенной в подсеть 144.206.160.0, будут направляться на шлюз 144.206.160.32, если они не могут быть разосланы в рамках этой подсети. В некоторых системах сохранился формат команды route, в котором следует указать метрику:

route add default 144.206.160.32 1

Последняя цифра оказывает на то, что на пути от машины до сети хост 144.206.160.32 будет первым шлюзом. Собственно, метрика может быть либо 0, либо 1, т.к. указывать шлюзы с метрикой больше единицы бессмысленно - их администрирование уже не во власти администратора данной сети. Метрика 0 определяет тот факт, что шлюзом является сама машина, на которой находится таблица маршрутов. Часто в файле конфигурации можно встретить строку типа:

route add 144.206.160.40 127.0.0.1

Данная запись зацикливает пакеты, предназначенные для локального употребления, и не выпускает их в другие подсети.

Кроме параметра add команда route позволяет удалять маршруты по delete и получать информацию из таблицы по get:

route delete default

route get default

Для получения информации из таблицы маршрутов можно использовать команды, например netstat.

Важным моментом при управлении маршрутизацией являются протоколы управления маршрутизацией. Наиболее распространенным из них является протокол RIP.

Завершая обсуждение модуля IP нельзя не коснутся формата IP-пакета. Собственно протокол IР описывает три основные компоненты IP-технологии: формат IP-пакета, формат IP-адреса и способ маршрутизации IP-пакетов.

В представленном на рис. 8.13 заголовке пакета поле "версия" принимает значение версии IP-протокола. В настоящее время используется четвертая версия протокола, следовательно, поле "версия'' принимает значение "4". Сам заголовок, включая необязательные опции и символы заполнения, имеет длину, равную значению поля "длина IP-заголовка". Длина исчисляется в 32-битовых словах. Поле "тип сервиса" определяет способ обслуживания пакета в конкретных сетях и, главным образом, связано с возможностью задержки (delay) пакета в сети. Поле "общая длина'' определяет длину IP-пакета без заголовка. Длина измеряется в октетах (байтах). Поле "идентификация" предназначено для помощи при сборке'' сообщения. Поле "флаги" определяет место датаграммы в сообщении (первая, последняя и т. п.). Поле "смещение фрагмента" определяет смещение датаграммы относительно начала сообщения. Поле "время жизни'' предназначено для определения срока, после которого пакет должен быть удален из сети. Поле "протокол'' определяет тип датаграммы. Поле "контрольная сумма" служит для идентификации повреждений пакета при передаче. Контрольная сумма вычисляется только по заголовку пакета. Поле "адрес получателя" - IP-адрес места назначения. Поле "адрес отправителя" - IP-адрес отправителя. Опции могут иметь переменную длину и обычно применяются для трассировки пакетов, обеспечения безопасности. Заполнитель применяется для выравнивания заголовка на 32-битовую границу.

Протокол RIP (Routing Information Protocol). Протокол предназначен для автоматического обновления таблицы маршрутов. При этом используется информация о состоянии сети, которая рассылается маршрутизаторами (routers). В соответствии с протоколом RIP любая машина может быть маршрутизатором. При этом все маршрутизаторы делятся на активные и пассивные. Активные маршрутизаторы сообщают о маршрутах, которые они поддерживают в сети. Пассивные маршрутизаторы читают эти широковещательные соообщения и исправляют свои таблицы маршрутов, но при этом сами информации в сеть не предоставляют. Обычно в качестве активных маршрутизаторов выступают шлюзы, а в качестве пассивных - обычные машины (hosts).

В основу алгоритма маршрутизации по протоколу RIP положена простая идея: чем больше шлюзов надо пройти пакету, тем больше времени требуется для прохождения маршрута. При обмене сообщениями маршрутизаторы сообщают в сеть IP-номер сети и число "прыжков" (hops), которое надо совершить, пользуясь данным маршрутом. Надо сразу заметить, что такой алгоритм справедлив только для сетей, которые имеют одинаковую скорость передачи по любому сегменту сети. Часто в реальной жизни оказывается, что гораздо выгоднее воспользоваться оптоволокном с тремя шлюзами, чем одним медленным коммутируемым телефонным каналом.

Обычно для работы с протоколом RIP в системах типа Unix имеется программа routed - демон протокола RIP. При запуске системы она посылает запрос в сеть на предмет получения информации о маршрутах с активных маршрутизаторов - шлюзов. Шлюзы откликаются на этот запрос, и routed изменяет таблицу маршрутов. Обычно таблица маршрутов обновляется каждые 30 секунд. В таблицу не вносятся маршруты с числом "скачков" больше 1.5. Если появляется маршрут в некоторую сеть с меньшим числом "скачков", то он замещает существующий в таблице. Если с некоторого шлюза не поступаем информации о его маршрутах в течении периода обновления информация (обычно 180 секунд), то все маршруты через этот шлюз удаляются из таблица маршрутов. Существует еще один неприятный момент, связанный с routed. В большинстве систем, если через сетевые интерфейсы не прошел за определенный промежуток времени ни один пакет, шлюз может быть выведен в режим пассивного маршрутизатора. Поэтому на шлюзах лучше всего использовать другой демон - gated.

Программа gted была разработана для подключения к Internet в рамках сети NSFNET и для подключения к ней региональных сетей и коммерческих сетей в Калифорнийском университете. Gated дает возможность администратору сети управлять маршрутами и позволяет интегрировать сети, использующие разные протоколы маршрутизации.

Для работы gated требуется специальный файл конфигурации gated.conf. В этом файле прописываются все сетевые интерфейсы и правила работы с ними. Простейший файл конфигурации выглядит просто:

rip yes;

Это значит, что управление маршрутами осуществляется по протоколу RIP. Для машин с сетевыми интерфейсами типа Ethernet этого обычно достаточно. Если в системе более двух активных сетевых интерфейсов и система сконфигурирована как шлюз, то gated активно изменяет таблицу маршрутов.

Если система имеет только один интерфейс и требуется его защитить от удаления из таблицы маршрутов, то можно использовать конфигурацию типа:

interface 144.206.160.40 passive;

rip yes;

Приведем более сложный пример файла конфигурации:

rip yes;

export proto rip interface 136.66.1.2

{

proto direct

{

announce 136.66.3.0 metric 0;

};

};

export proto rip Interface 136.66.3.1

{

proto rip interface 136. 66. I. 2

{

announce all;

}

};

В данном примере через интерфейс 136.66.1.2 анонсируется вся сеть 136.66.3.0, т.е. эта сеть доступна из внешнего мира через интерфейс данной машины с номером 136.66.1.2. В свою очередь, весь мир доступен для этой сети через интерфейс 136.66.3.1, и при этом все пакеты должны ретранслироваться через интерфейс 136.66.1.2.

Протокол UDP. Этот протокол является одним из двух основных транспортных протоколов, расположенных сразу над IР. К заголовку IP-пакета UDP добавляет два поля: порт и контрольная сумма. Поле "порт" позволяет мультиплексировать информацию между разными прикладными процессами. Поле "контрольная сумма" позволяет поддерживать целостность данных.

Для взаимодействия с модулем UDP прикладные программы используют UDP-порты. Порт - это канал обмена данными между двумя или более сетевыми программами через модуль UDP. Многие приложения Internet имеют архитектуру "клиент-сервер". Прикладные программы "клиент-сервер" отправляют запросы в порт и ожидают запросов на обслуживание и в случае их появления отправляют ответы в тот же порт.

Данные, отправляемые через модуль UDP, достигают места назначения как единое целое. Это значит, что если было произведено 5 записей в порт, то прочитано из порта будет тоже 5 записей. При работе по протоколу UDP не происходит объединения сообщений и их разбиения на части.

Контрольное суммирование предназначено для проверки целостности данных. При получении датаграммы модуль UDP проверяет контрольную. Если поле контрольной суммы было равно 0, то это значит, что при отправлении суммирование не производилось и проверку контрольной суммы можно опустить.

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

Забота о проверке доставки данных, таким образом, ложится на прикладной процесс. Данный протокол называют еще протоколом ненадежной доставки.

Протокол TCP. Предоставляет другой способ доставки сообщений отличный от UDP. Вместо "ненадежной" доставки датаграмм без установления соединения TCP обеспечивает гарантированную доставку с установлением соединения в виде байтовых потоков.

Прикладные программы взаимодействуют с модулем ТСР также через порты. Существуют определенные стандартом номера портов, которые отведены под обслуживание стандартных сервисов Internet. Так, telnet обслуживается через 23 порт, почта (SMTP) - через 25 и т.п.

Когда два процесса начинают общаться через модули ТСР, то эти поддерживают информацию о состоянии соединения, которое называется виртуальным каналом. Канал является дуплексным, т.е. информация передаваться одновременно в двух направлениях.

Согласно протоколу ТСР, поток байтов разбивается на пакеты. Любые данные для модуля ТСР представляются в виде потока байтов. На другом конце виртуального канала данные снова собираются в поток. Модуль ТСР не сохраняет разделения потоков данных на записи. Так, можно записать в канал 5 записей по 80 байт, а прочитать одну в 400 байтов длиной.

Все отправленные данные должны быть подтверждены стороной. Для обеспечения надежной доставки используют таймауты и повторные передачи. Отправителю разрешается отправлять данные, не дожидаясь их подтверждения. Таким образом, при передаче образуется некоторое количество уже отправленных, но еще не подтвержденных данных. Сам факт наличия таких данных называется окном, а количество этих данных называется размером окна. Размер окна определяется в стартовых конфигурационных файлах сетевого программного обеспечения. Подтверждения и данные в канале ТСР перемешаны, и модуль ТСР должен сам в них разобраться. При использовании сервиса FTP при доступе к популярным архивам часто происходит перегрузка канала. Модуль ТСР заботится, чтобы при этом не произошло переполнение буферов и не было потери информации. Частично забота об этом лежит и на прикладных программах.

Протокол SLIP (Serial Line Internet Protocol). Технология TCP/IP позволяет организовать межсетевое взаимодействие, используя различные физические и канальные протоколы обмена данными IEEE 802.3 - ethernet, IEEE 802.5 - token ring, Х.25 п т. п.). Однако без обмена данными по телефонным линиям связи с использованием обычных модемов популярность Internet была бы значительно ниже. Большинство пользователей Сети используют свой домашний телефон в качестве окна в мир компьютерных сетей, подключая компьютер через модем к модемному пулу компании, предоставляющей IP-услуги, или к своему рабочему компьютеру. Наиболее простым способом, обеспечивающий полный IP-сервис, является подключение через последовательный порт персонального компьютера по протоколу SLIP.

Согласно RFC-1055, впервые SLIP был включен в качестве средства доступа к IP-сети в пакет фирмы ЗСОМ - UNET. В 1984 году Рик Адамс (Rick Adams) реализовал SLIP для BSD 4.2, и таким образом SLIP стал достоянием всего IP-сообщества.

Обычно этот протокол применяют как на выделенных, так и на коммутируемых линиях связи со скоростями от 1200 до 19200 бод. Следует отметить, что в условно-свободно распространяемые IP-стеки, Trumpet Winsock, например, обязательно включена поддержка SLIP коммуникаций. Такие операционные системы, как FreeBSD, Linux, NetBSD, которые можно свободно скопировать и установить на своем персональном компьютере, или HP-UX, которая поставляется вместе с рабочими станциями Hewlett Packard, имеют в своем арсенале программные средства типа sliplogin (FreeBSD) или ррl (HP-UX) обеспечивающие работу компьютера в качестве SLIP-сервера для удаленных пользователей, подключающихся к IP-сети по телефону. В протоколе SLIP нет определения понятия "SLIP-сервер", но реальная жизнь вносит коррективы в стандарты. В контексте нашего изложения ''SLIP-клиент" - это компьютер, инициирующий физическое соединение, а "SLIP-сервер" это машина, постоянно включенная в IР-сеть. В главе, посвященной организации IP-сетей и подключению удаленных компьютеров, будет подробно рассказано о различных способах подключения по SLIP-протоколу, поэтому, не останавливаясь на деталях такого подключения, перейдем к обсуждению самого протокола SLIP.

В отличие от Ethernet SLIP не "заворачивает"IP-пакет в свою обертку, а нарезает его на "кусочки". При этом делает это довольно примитивно. SLIP-пакет начинается символом ESC (восьмеричное 333 или десятичное 219) и кончается символом END (восьмеричное 300 или десятичное 192). Если внутри пакета встречаются эти символы, то они заменяются двухбайтовыми последовательностями ESC-END (333 334) и ESC-ESC (333 335). Стандарт не определяет размер SLIP-пакета, поэтому любой SLIP-интерфейс имеет специальное поле, в котором пользователь должен указать эту длину. Правда, в стандарте есть указание на то, что BSD SLIP драйвер поддерживает пакеты длиной 1006 байт, поэтому "современные" реализации SLIP-программ должны поддерживать эту длину пакетов. SLIP-модуль не анализирует поток данных и не выделяет какую-либо информацию в этом потоке. Он просто нарезает ее на "кусочки", каждый из которых начинается символом ESC, а кончается символом END. Из приведенного выше описания понятно, что SLIP не позволяет выполнять какие-либо действия, связанные с адресами, т.к. в структуре пакета не предусмотрено поле адреса и его специальная обработка. Компьютеры, взаимодействующие по SLIP, обязаны знать свои IP-адреса заранее. SLIP не позволяет различать пакеты по типу протокола, например, IP или DECnet. Вообще-то при работе по SLIP предполагается использование только IР,но простота пакета может быть соблазнительной и для других протоколов. В SLIP нет информации, позволяющей корректировать ошибки линии связи. Коррекция ошибок возлагается на протоколы транспортного уровня - ТСР, UDP. В стандартном SLIP не предусмотрена компрессия данных, но существуют варианты протокола с такой компрессией. По поводу компрессии следует заметить следующее: большинство современных модемов, поддерживающих стандарты V.42bis и MNP5, осуществляют аппаратную компрессию. При этом практика работы по нашим обычным телефонным каналам показывает, что лучше отказаться от этой компрессии и работать пример MNP4 или V.42. Вообще говоря, каждый должен подобрать тот режим, который наиболее устойчив в конкретных условиях работы телефонной сети (вплоть до времени года и частоты аварий на теплотрассах).

Соединения типа "точка-точка" - протокол РРР (Point to Point Protocol). РРР - это более молодой протокол, нежели SLIP. Однако назначение у него то же самое - управление передачей данных по выделенным или коммутируемым линиям связи. Согласно RFC-1661, PPP обеспечивает стандартный метод взаимодействия двух узлов сети. Предполагается, что обеспечивается двунаправленная одновременная передача данных. Как и в SLIP, данные нарезаются на фрагменты, которые называются пакетами. Пакеты передаются от узла к узлу упорядоченно. В отличие от SLIP РРР позволяет одновременно передавать по линии связи пакеты различных протоколов. Кроме того, РРР предполагает процесс автоконфигурации обеих взаимодействующих сторон. Собственно говоря, РРР состоит из трех частей: механизма инкапсуляции (encapsulation), протокола управления coeдинением (link control protocol) и семейства протоколов управления сетью (network control protocols).

Термин "инкапсуляция", согласно Словарю иностранных слов, обозначает "образование оболочки (капсулы) вокруг инородного тела". При обсуждение способов транспортировки данных при межсетевом обмене этот термин применяется довольно часто, например, инкапсуляция IР в Х.25. С инкапсуляцией IР в Ethernet мы уже встречались при обсуждении технологии локальных сетей этого типа. Инкапсуляция обеспечивает мультиплексирование различные сетевых протоколов (протоколов межсетевого обмена, например IР) через один канал передачи данных. Инкапсуляция РРР устроена достаточно эффективное для передачи HDLC фрейма требуется всего 8 дополнительных байтов (8 октетов, согласно терминологии РРР). При других способах разбиения информации на фреймы число дополнительных байтов может быть сведено до 4 или даже 2. Для обеспечения быстрой обработки информации граница РРР пакета должна быть кратна 32 битам. При необходимости в конец пакета для выравнивания на 32-битовую границу добавляется "балласт". Вообще говоря, понятие инкапсуляции в терминах PPP - это не только добавление служебной информации к транспортируемой информации, но, если необходимо, и разбиение этой информации на более мелкие фрагменты. Продолжая глоссарий, который был введен при обсуждении технологии IР на базе Ethernet, следует добавить еще несколько терминов.

Под датаграммой в РРР понимают информационную единицу сетевого уровня применительно к IР - IP-пакет. Под фреймом понимают информационную единицу канального уровня (согласно модели OSI). Фрейм состоит заголовка и хвоста, между которыми содержатся данные. Датаграмма может быть инкапсулирована в один или несколько фреймов. Пакетом называют информационную единицу обмена между модулями сетевого уровня и канального уровня. Обычно каждому пакету ставится в соответствие один фрейм, за исключением тех случаев, когда канальный уровень требует еще большей фрагментации данных или, наоборот, объединяет пакеты для более эффективной передачи. Типичным случаем фрагментации являются сети АТМ. В упрощенном виде РРР фрейм выглядит следующим образом:

Протокол 8/16 битов	Информация	Хост
Рис.8.14. PPP фрейм

В поле "протокол" указывается тип инкапсулированной датаграммы. Существуют специальные правила кодирования протоколов в этом поле (см. ISO-3309 и RFC-1661). В поле "информация" записывается собственно пакет данных, а в поле "хвост" добавляется "пустышка" для выравнивания на 32-битовую границу. По умолчанию для фрейма РРР используется 1500 байтов. В это число не входит поле "протокол".

Протокол управления соединением предназначен для установки соглашения между узлами сети о параметрах инкапсуляции (размер фрейма, например). Кроме этого, протокол позволяет проводить идентификацию узлов. Первой фазой установки соединения является проверка готовности физическое уровня передачи данных. При этом такая проверка может осуществляться периодически, позволяя реализовать механизм автоматического восстановления физического соединения, как это бывает при работе через модем по коммутируемой линии. Если физическое соединение установлено, то узлы начинают обмен пакетами протокола управления соединением, настраивая параметры сессии. Любой пакет, отличный от пакета протокола управления соединением, не обрабатывается во время этого обмена. После установки параметров соединения возможен переход к идентификации. Идентификация не является обязательной. После всех этих действий происходит настройка параметров работы с протоколами межсетевого обмена (IР, IРХ и т.п.). Для каждого из них используется свой протокол управления. Для завершения работы по протоколу РРР по сети передается пакет завершения работы протокола управления соединением.

Процедура конфигурации сетевых модулей операционной системы для работы по протоколу РРР - более сложное занятие, чем аналогичная процедур для протокола SLIP. Однако возможности РРР соединения гораздо более широкие. Так, при работе через модем модуль РРР обычно сам восстанавливает соединение при потере несущей частоты. Кроме того, модуль РРР сам определяет параметры своих фреймов, в то время как при SLIP их надо подбирать вручную. Правда, если настраивать оба конца, то многие проблемы не возникают из-за того, что параметры соединения известны заранее. Более подробно с протоколом РРР можно познакомиться в RFC-1661 и RFC-1548.

IPing - новое поколение протоколов IР. До сих пор при обсуждении IР-технологии основное внимание уделялось проблемам межсетевого обмена и путям их решения в рамках существующей технологии. Однако все эти задачи, вызванные необходимостью приспособления IР к новым физическим средам передачи данных, меркнут перед действительно серьезной проблемой - ростом числа пользователей Сети. Казалось бы, что тут страшного? Число пользователей увеличивается, следовательно, растет популярность сети. Такое положение дел должно только радовать. Но проблема заключается в том, что Internet стал слишком большой, он перерос заложенные в него возможности. К 1994 году ISOC опубликовало данные, из которых стало ясно, что номера сетей класса В практически все уже выбраны, а остались только сети класса А и класса С. Класс А - это слишком болящие сети. Реальные пользователи сети, такие как университеты или предприятия, не используют сети этого класса. Класс С хорош для очень небольших организаций. При современной насыщенности вычислительной техникой только мелкие конторы будут удовлетворены возможностями этого класса. Но если дело пойдет дальше такими темпами, то класс С тоже быстро иссякнет. Самое парадоксальное заключается в том, что реально не все адреса из выделенных пользователям сетей реально используются. Большое число адресов пропадает из-за различного рода просчетов при организации подсетей, например, слишком широкая маска, или, наоборот, слишком "дальновидного" планирования, когда в сеть закладывают большой запас "на вырост". Не следует думать, что эти адреса так и останутся невостребованными. Современное "железо" позволяет их утилизировать достаточно эффективно, но это стоит значительно дороже, чем простые способы, описанные выше (см. "Организация подсетей"). Одним словом, Internet, став действительно глобальной сетью, оказался зажатым в тисках своих собственных стандартов. Нужно было что-то срочно предпринимать, чтобы во время пика своей популярности не потерпеть сокрушительное фиаско.

В начале 1995 года IETF, после трех лет консультаций и дискуссий, выпустило предложения по новому стандарту протокола IР - IPv6, который еще называют Iping. К слову, следует заметить, что сейчас Internet-сообщество живет по стандарту IPv4. IPv6 призван не только решить адресную проблему, но и попутно помочь решению других задач, стоящих в настоящее время перед Internet.

Нельзя сказать, что до появления IРv6 не, делались попытки обойти адресные ограничения IPv4. Например, в протоколах BООТР (BOOTstrap Protocol) и DHCP (Dynamic Host Configuration Protocol) предлагается достаточно простой и естественный способ решения проблемы для ситуации, когда число физических подключений ограничено, или реально все пользователи не работают в сети одновременно. Типичной ситуацией такого сорта является доступ к Internet по коммутируемому каналу, например телефону. Ясно, что одновременно несколько пользователей физически не могут разговаривать по одному телефону, поэтому каждый из них при установке соединения запрашивает свою конфигурацию, в том числе и IP-адрес. Адреса выдаются из ограниченного набора адресов, который закреплен за телефонным пулом. IP-адрес пользователя может варьироваться от сессии. Фактически DHCP - это расширение ВООТР в сторону увеличения числа протоколов, для которых возможна динамическая настройка удаленных машин. Следует заметить, что DHCP используют и для облегчения администрирования больших сетей, т. к, достаточно иметь только базу данных машин на одном компьютере локальной сети и из нее загружать настройки удаленных компьютеров при их включении (под включением понимается в данном случае не подключение к локальной компьютерной сети, а включение питания у компьютера, подсоединенного к ее сети).

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

Новый заголовок IP-пакета выглядит теперь следующим образом:

В этом заголовке поле "версия" - номер версии IР, равное 6. Поле "приоритет" может принимать значения от 0 до 15. Первые 8 значений закреплены за пакетами, требующими контроля переполнения, например, 0 - несимвольная информация; 1 - информация заполнения (news); 2 - не критичная ко времени передача данных (еmail); 4 - передача данных режима on-line (FTP, НТТР, NFS и т.п.); 6 - интерактивный обмен данными (telnet, Х); 7 - системные данные или данные управления сетью (SNMP, RIP и т.п.). Поле "метка потока" предполагается использовать для оптимизации маршрутизации пакетов. В IPv6 вводится понятие потока, который состоит из пакетов. Пакеты потока имеют одинаковый адрес отправителя и одинаковый адрес получателя и ряд других одинаковых опций. Подразумевается, что маршрутизаторы будут способны обрабатывать это поле и оптимизировать процедура пересылки пакетов, принадлежащих одному потоку. В настоящее время алгоритмы и способы использования поля "метка потока" находятся на стадии обсуждения. Поле длины пакета определяет длину следующей за заголовков части пакета в байтах. Поле "следующий заголовок", определяет тип следующего за заголовком IР заголовка. Заголовок IPv6 имеет меньшее количество полей, чем заголовок IPv4. Многие необязательные поля могут быть указаны в дополнительных заголовках, если это необходимо. Поле "ограничение переходов" определяет число промежуточных шлюзов, которые ретранслируют пакет в сети. При прохождении шлюза это число уменьшается на единицу. При достижении значения "0" пакет уничтожается. После первых 8 байтов в заголовке указываются адрес отправителя пакета и адрес получателя пакета. Каждый из этих адресов имеет длину 16 байт. Таким образом, длина заголовка IPv6 составляет 48 байтов.

После 4 байтов IP-адреса стандарта IPv4 шестнадцать байт IP-адреса для IPv6 выглядят достаточными для удовлетворения любых потребностей Internet. Нe все 2**128 адресов можно использовать в качестве адреса сетевого интерфейса в сети. Предполагается выделение отдельных групп адресов, согласно специальным префиксам внутри IP-адреса, подобно тому как это делалось при определении типов сетей в IPv4. Так, двоичный префикс "0000 010" предполагается закрепить за отображением IPX-адресов в IP-адреса. В новом стандарте выделяются несколько типов адресов: unicast addresses - адреса сетевых интерфейсов, anycast addresses - адреса, не связанные с конкретным сетевым интерфейсом, но и не ассоциируются с группой интерфейсов и multicast addresses - групповые адреса. Разница между последними двумя группами адресов в том, что anycast address - это адрес конкретного получателя, но определяется адрес сетевого интерфейса только в локальной сети, где этот интерфейс подключен, а multicast-сообщение предназначено группе интерфейсов, которые имеют один multicast-адрес. Пока IPv6 не стал злобой дня, нет смысла углубляться в форматы новых IP-адресов. Отметим только, что существующие узлы Internet будут функционировать в сети без каких-либо изменений в их настройках и программном обеспечении. IPv6 предполагает две схемы включения "старых" адресов в новые. Предполагается расширять 4-байтовый адрес за счет лидирующих байтов до 16-байтового. При этом для систем, которые не поддерживают IPv6, первые 10 байтов заполняются нулями, следующие два байта состоять из двоичных единиц, а за ними следует "старый" IP-адрес. Если система в состоянии поддерживать новый стандарт, то единицы в 11-м и 12-м байтах заменяются нулями.

Маршрутизировать IРv6-пакеты предполагается также, как и IPv4-пакеты. Однако, в стандарт были добавлены три новых возможности маршрутизации: маршрутизация поставщика IP-услуг, маршрутизация мобильных узлов и автоматическая переадресация. Эти функции реализуются путем прямого указания промежуточных адресов шлюзов при маршрутизации пакета. Эти списки помещаются в дополнительных заголовках; которые можно вставлять вслед за заголовком IP-пакетам.

Кроме перечисленных возможностей новый протокол позволяет улучшить защиту IP-трафика. Для этой цели в протоколе предусмотрены специальные опции. Первая опция предназначена для защиты от подмены IP-адресов машин. При ее использовании нужно, кроме адреса, подменять и содержимое поля идентификации, что усложняет задачу злоумышленника, который маскируется под другую машину. Вторая опция связана с шифрацией трафика. Пока IPv6 не стал реально действующим стандартом, говорить о конкретных механизмах шифрации трудно.

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