2. Протокол IP

2.1. Функции протокола IP
2.2. IP-адреса

2.2.1. Классовая модель

2.2.2. Бесклассовая модель (CIDR)

2.2.3. Запись адресов в бесклассовой модели

2.3. Маршрутизация

2.3.1. Пример маршрутизации

2.3.2. Пример подключения локальной сети организации к Интернет

2.3.3. Маршрутизатор или шлюз?

2.3.4. Таблицы маршрутов

2.3.5. Создание статических маршрутов

2.3.6. Динамическая маршрутизация

2.4. Формат заголовка IP-дейтаграммы

2.4.1. Фрагментация дейтаграмм

2.4.2. Обсуждение фрагментации

2.4.3. Опции IP

2.4.4. Опции “Loose/Strict Source Routing”

2.5. Протокол ICMP
2.6. Протокол ARP

2.6.1. ARP для дейтаграмм, направленных в другую сеть

2.6.2. Proxy ARP

Оглавление учебного пособия
Страница курса "Телекоммуникационные технологии"
Кафедра КТС

Протокол IP находится на межсетевом уровне стека протоколов TCP/IP. Функции протокола IP определены в стандарте RFC-791 следующим образом: “Протокол IP обеспечивает передачу блоков данных, называемых дейтаграммами, от отправителя к получателям, где отправители и получатели являются компьютерами, идентифицируемыми адресами фиксированной длины (IP-адресами). Протокол IP обеспечивает при необходимости также фрагментацию и сборку дейтаграмм для передачи данных через сети с малым размером пакетов”.

Протокол IP является ненадежным протоколом без установления соединения. Это означает, что протокол IP не подтверждает доставку данных, не контролирует целостность полученных данных и не производит операцию квитирования (handshaking) - обмена служебными сообщениями, подтверждающими установку соединения с узлом назначения и его готовность к приему данных. Протокол IP обрабатывает каждую дейтаграмму как независимую единицу, не имеющую связи ни с какими другими дейтаграммами в Интернет. После того, как дейтаграмма отправляется в сеть, ее дальнейшая судьба никак не контролируется отправителем (на уровне протокола IP). Если дейтаграмма не может быть доставлена, она уничтожается. Узел, уничтоживший дейтаграмму, может оправить по обратному адресу ICMP-сообщение (см. п. 2.5) о причине сбоя.

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

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

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

• с одного из интерфейсов уровня доступа к среде передачи (например, с Ethernet-интерфейса) в модуль IP поступает дейтаграмма;
• модуль IP анализирует заголовок дейтаграммы;
• если пунктом назначения дейтаграммы является данный компьютер:
  • если дейтаграмма является фрагментом большей дейтаграммы, ожидаются остальные фрагменты, после чего из них собирается исходная большая дейтаграмма;
  • из дейтаграммы извлекаются данные и направляются на обработку одному из протоколов вышележащего уровня (какому именно - указывается в заголовке дейтаграммы);
• если дейтаграмма не направлена ни на один из IP-адресов данного узла, то дальнейшие действия зависят от того, разрешена или запрещена ретрансляция (forwarding) “чужих” дейтаграмм;
• если ретрансляция разрешена, то определяются следующий узел сети, на который должна быть переправлена дейтаграмма для доставки ее по назначению, и интерфейс нижнего уровня, после чего дейтаграмма передается на нижний уровень этому интерфейсу для отправки; при необходимости может быть произведена фрагментация дейтаграммы;
• если же дейтаграмма ошибочна или по каким-либо причинам не может быть доставлена, она уничтожается; при этом, как правило, отправителю дейтаграммы отсылается ICMP-сообщение об ошибке.

При получении данных от вышестоящего для отправки их по сети IP-модуль формирует дейтаграмму с этими данными, в заголовок которой заносятся адреса отправителя и получателя (также полученные от транспортного уровня) и другая информация; после чего выполняются следующие шаги:

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

Здесь и далее узлом сети называется компьютер, подключенный к сети и поддерживающий протокол IP. Узел сети может иметь один и более IP-интерфейсов, подключенных к одной или разным сетям, каждый такой интерфейс идентифицируется уникальным IP-адресом.

IP-сетью называется множество компьютеров (IP-интерфейсов), часто, но не всегда подсоединенных к одному физическому каналу связи, способных пересылать IP-дейтаграммы друг другу непосредственно (то есть без ретрансляции через промежуточные компьютеры), при этом IP-адреса интерфейсов одной IP-сети имеют общую часть, которая называется адресом, или номером, IP-сети, и специфическую для каждого интерфейса часть, называемую адресом, или номером, данного интерфейса в данной IP-сети. В настоящем пособии речь идет преимущественно об IP-сетях, поэтому приставку “IP” мы будем как правило опускать.

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

Хостами называются узлы IP-сети, не являющиеся маршрутизаторами. Обычно хост имеет один IP-интерфейс (например, связанный с сетевой картой Ethernet или с модемом), хотя может иметь и несколько.

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

Неотъемлемой частью IP-модуля является протокол ICMP (Internet Control Message Protocol), отправляющий диагностические сообщения при невозможности доставки дейтаграммы и в других случаях. Совместно с протоколом IP работает также протокол ARP (Address Resolution Protocol), выполняющий преобразования IP-адресов в MAC-адреса (например, адреса Ethernet). Работа протоколов ICMP и ARP рассмотрена ниже в пп. 2.5 и 2.6 соответственно.

IP-адрес является уникальным 32-битным идентификатором IP-интерфейса в Интернет. Часто говорят, что IP-адрес присваивается узлу сети (например, хосту); это верно в случае, если узел является хостом с одним IP-интерфейсом, иначе следует уточнить, об адресе какого именно интерфейса данного узла идет речь. Далее для краткости там, где это не вызовет неверного толкования, вместо адреса IP-интерфейса узла сети говорится об IP-адресе хоста.

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

        10100000010100010000010110000011 

записывается как

        10100000.01010001.00000101.10000011 = 160.81.5.131.

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

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

Класс А. Старший бит адреса равен нулю. Размер сетевой части равен 8 битам. Таким образом, может существовать всего примерно 2⁷ сетей класса А, но каждая сеть обладает адресным пространством на 2²⁴ хостов. Так как старший бит адреса нулевой, то все IP-адреса этого класса имеют значение старшего октета в диапазоне 0 — 127, который является также и номером сети.

Класс В. Два старших бита адреса равны 10. Размер сетевой части равен 16 битам. Таким образом, может существовать всего примерно 2¹⁴ сетей класса В, каждая сеть обладает адресным пространством на 2¹⁶ хостов. Значения старшего октета IP-адреса лежат в диапазоне 128 — 191, при этом номером сети являются два старших октета.

Класс С. Три старших бита адреса равны 110. Размер сетевой части равен 24 битам. Количество сетей класса С примерно 2²¹, адресное пространство каждой сети рассчитано на 254 хоста. Значения старшего октета IP-адреса лежат в диапазоне 192 - 223, а номером сети являются три старших октета.

Класс D. Сети со значениями старшего октета IP-адреса 224 и выше. Зарезервированы для специальных целей. Некоторые адреса используются для мультикастинга - передачи дейтаграмм группе узлов сети, например:

224.0.0.1 - всем хостам данной сети;

224.0.0.2 - всем маршрутизаторам данной сети;

224.0.0.5 - всем OSPF-маршрутизаторам;

224.0.0.6 - всем выделенным (designated) OSPF-маршрутизаторам;

Рис. 2.2.1. Классы IP-адресов

В классе А выделены две особые сети, их номера 0 и 127. Сеть 0 используется при маршрутизации как указание на маршрут по умолчанию (см. п. 2.3) и в других особых случаях.

IP-интерфейс с адресом в сети 127 используется для адресации узлом себя самого (loopback, интерфейс обратной связи). Интерфейс обратной связи не обязательно имеет адрес в сети 127 (особенно у маршрутизаторов), но если узел имеет IP-интерфейс с адресом 127.0.0.1, то это - интерфейс обратной связи. Обращение по адресу loopback-интерфейса означает связь с самим собой (без выхода пакетов данных на уровень доступа к среде передачи); для протоколов на уровнях транспортном и выше такое соединение неотличимо от соединения с удаленным узлом, что удобно использовать, например, для тестирования сетевого программного обеспечения.

В любой сети (это справедливо и для бесклассовой модели, которую мы рассмотрим ниже) все нули в номере хоста обозначают саму сеть, все единицы - адрес широковещательной передачи (broadcast).

Например, 194.124.84.0 - сеть класса С, номер хоста в ней определяется последним октетом. При отправлении широковещательного сообщения оно отправляется по адресу 194.84.124.255. Номера, разрешенные для присваивания хостам: от 1 до 254 (194.84.124.1 — 194.84.124.254), всего 254 возможных адреса.

Другой пример: в сети 135.198.0.0 (класс В, номер хоста занимает два октета) широковещательный адрес 135.198.255.255, диапазон номеров хостов: 0.1 — 255.254 (135.198.0.1 — 135.198.255.254).

Предположим, в локальной сети, подключаемой к Интернет, находится 2000 компьютеров. Каждому из них требуется выдать IP-адрес. Для получения необходимого адресного пространства нужны либо 8 сетей класса C, либо одна сеть класса В. Сеть класса В вмещает 65534 адреса, что много больше требуемого количества. При общем дефиците IP-адресов такое использование сетей класса В расточительно. Однако если мы будем использовать 8 сетей класса С, возникнет следующая проблема: каждая такая IP-сеть должна быть представлена отдельной строкой в таблицах маршрутов на маршрутизаторах, потому что с точки зрения маршрутизаторов — это 8 абсолютно никак не связанных между собой сетей, маршрутизация дейтаграмм в которые осуществляется независимо, хотя фактически эти IP-сети и расположены в одной физической локальной сети и маршруты к ним идентичны. Таким образом, экономя адресное пространство, мы многократно увеличиваем служебный трафик в сети и затраты по поддержанию и обработке маршрутных таблиц.

С другой стороны, нет никаких формальных причин проводить границу сеть-хост в IP-адресе именно по границе октета. Это было сделано исключительно для удобства представления IP-адресов и разбиения их на классы. Если выбрать длину сетевой части в 21 бит, а на номер хоста отвести, соответственно, 11 бит, мы получим сеть, адресное пространство которой содержит 2046 IP-адресов, что максимально точно соответствует поставленному требованию. Это будет одна сеть, определяемая своим уникальным 21-битным номером, следовательно, для ее обслуживания потребуется только одна запись в таблице маршрутов.

Единственная проблема, которую осталось решить: как определить, что на сетевую часть отведен 21 бит? В случае классовой модели старшие биты IP-адреса определяли принадлежность этого адреса к тому или иному классу и, следовательно, количество бит, отведенных на номер сети.

В случае адресации вне классов, с произвольным положением границы сеть-хост внутри IP-адреса, к IP-адресу прилагается 32-битовая маска, которую называют маской сети (netmask) или маской подсети (subnet mask). Сетевая маска конструируется по следующему правилу:

• на позициях, соответствующих номеру сети, биты установлены;
• на позициях, соответствующих номеру хоста, биты сброшены.

Описанная выше модель адресации называется бесклассовой (CIDR - Classless Internet Direct Routing, прямая бесклассовая маршрутизация в Интернет). В настоящее время классовая модель считается устаревшей и маршрутизация и (большей частью) выдача блоков IP-адресов осуществляются по модели CIDR, хотя классы сетей еще прочно удерживаются в терминологии.

Для удобства записи IP-адрес в модели CIDR часто представляется в виде a.b.c.d / n, где a.b.c.d — IP адрес, n — количество бит в сетевой части.

Пример: 137.158.128.0/17.

Маска сети для этого адреса: 17 единиц (сетевая часть), за ними 15 нулей (хостовая часть), что в октетном представлении равно

11111111.11111111.10000000.00000000 = 255.255.128.0.

Представив IP-адрес в двоичном виде и побитно умножив его на маску сети, мы получим номер сети (все нули в хостовой части). Номер хоста в этой сети мы можем получить, побитно умножив IP-адрес на инвертированную маску сети.

Пример: IP = 205.37.193.134/26 или, что то же,

IP = 205.37.193.134 netmask = 255.255.255.192.

Распишем в двоичном виде:

IP  =     11001101 00100101 11000111 10000110
маска =   11111111 11111111 11111111 11000000

Умножив побитно, получаем номер сети (в хостовой части - нули):

network = 11001101 00100101 11000111 10000000

или, в октетном представлении, 205.37.193.128/26, или, что то же, 205.37.193.128 netmask 255.255.255.192.

Хостовая часть рассматриваемого IP адреса равна 000110, или 6. Таким образом, 205.37.193.134/26 адресует хост номер 6 в сети 205.37.193.128/26. В классовой модели адрес 205.37.193.134 определял бы хост 134 в сети класса С 205.37.193.0, однако указание маски сети (или количества бит в сетевой части) однозначно определяет принадлежность адреса к бесклассовой модели.

Упражнение. Покажите, что адрес 132.90.132.5 netmask 255.255.240.0 определяет хост 4.5 в сети 132.90.128.0/20 (в классовой модели это был бы хост 132.5 в сети класса В 132.90.0.0). Найдите адрес broadcast для этой сети.

Очевидно, что сети классов А, В, С в бесклассовой модели представляются при помощи масок, соответственно, 255.0.0.0 (или /8), 255.255.0.0 (или /16) и 255.255.255.0 (или /24).

Процесс маршрутизации дейтаграмм состоит в определении следующего узла (next hop) в пути следования дейтаграммы и пересылки дейтаграммы этому узлу, который является либо узлом назначения, либо промежуточным маршрутизатором, задача которого — определить следующий узел и переслать ему дейтаграмму. Ни узел-отправитель, ни любой промежуточный маршрутизатор не имеют информации о всей цепочке, по которой пересылается дейтаграмма; каждый маршрутизатор, а также узел-отправитель, основываясь на адресе назначения дейтаграммы, находит только следующий узел ее маршрута.

Маршрутизация дейтаграмм осуществляется на уровне протокола IP.

Маршрутизация выполняется на основе данных, содержащихся в таблице маршрутов. Строка в таблице маршрутов состоит из следующих полей:

• адрес сети назначения;
• адрес следующего маршрутизатора (то есть узла, который знает, куда дальше отправить дейтаграмму, адресованную в сеть назначения);
• вспомогательные поля.

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

Рассмотрим процесс маршрутизации на примере.

Допустим (см. рис. 2.3.1), хосты А и В находятся в сети 1, сеть 1 соединяется с сетью 2 с помощью маршрутизатора G1. К сети 2 подключен маршрутизатор G2, соединяющий ее с сетью 3, в которой находится хост С.

Рис. 2.3.1. Пример маршрутизации

Таблица маршрутов хоста А выглядит, например, так:

      Сеть 1          А
      Прочие сети     G1

Это означает, что дейтаграммы, адресованные узлам сети 1, отправляет сам хост А (так как это его локальная сеть), а дейтаграммы, адресованные в любую другую сеть (это называется маршрут по умолчанию), хост А отправляет маршрутизатору G1, чтобы тот занялся их дальнейшей судьбой.

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

Если хост А отправляет дейтаграмму хосту С, то он определяет по IP-адреcу C, что хост С не принадлежит к сети 1. Согласно таблице маршрутов А, все дейтаграммы с пунктами назначения, не принадлежащими сети 1, отправляются на маршрутизатор G1 (это называется маршрут по умолчанию). При этом хост А не знает, что маршрутизатор G1 будет делать с его дейтаграммой и каков будет ее дальнейший маршрут - это забота исключительно G1. G1 в свою очередь по своей таблице маршрутов определяет, что все дейтаграммы, адресованные в сеть 3, должны быть пересланы на маршрутизатор G2. Это может быть как явно указано в таблице, находящейся на G1, в виде

      Сеть 3          G2,

так и указано в виде маршрута по умолчанию.

На этом функции G1 заканчиваются, дальнейший путь дейтаграммы ему неизвестен и его не интересует. Маршрутизатор G2, получив дейтаграмму, определяет, что она адресована в одну из сетей (№3), к которым он присоединен непосредственно, и доставляет дейтаграмму на хост С.

Рассмотрим реальный пример подключения к Интернет локальной сети организации (рис. 2.3.2). IP-адрес локальной сети - 194.84.124.0/24 (сеть класса С). В эту сеть включен маршрутизатор G1. IP-интерфейс этого маршрутизатора, подключенный к локальной сети Ethernet, имеет адрес 194.84.124.1. Второй IP-интерфейс маршрутизатора подключен к выделенной линии (синхронный последовательный канал), ведущей к провайдеру Интернет. К другому концу этой линии подключен IP-интерфейс маршрутизатора G2, принадлежащего провайдеру. Эти два интерфейса образуют отдельную сеть 194.84.0.116/30. В этой сети на номер интерфейса отведено всего 2 бита — 4 варианта адресов, из которых один (00) обозначает саму сеть, один (11) — широковещательный; таким образом, в подобной сети может находиться всего 2 узла — это минимальная возможная сеть. Интерфейс маршрутизатора G1 в сети 194.84.0.116/30 имеет адрес 194.84.0.117, а маршрутизатора G2 — 194.84.0.118. Маршрутизатор G2 имеет еще некоторое количество интерфейсов, к части которых подключены выделенные линии от других клиентов, к части — локальные сети коммуникационного центра, другие маршрутизаторы и магистральные линии дальней связи.

Рис. 2.3.2. Подключение локальной сети к Интернет

Небольшое замечание о терминологии.

С точки зрения топологии соединений G2 (рис. 2.3.2) является собственно маршрутизатором (router), так как он коммутирует потоки дейтаграмм между своими многочисленными IP-интерфейсами, в то время как G1 является шлюзом (gateway) — интерфейсом между двумя разнородными средами передачи данных (локальной сетью Ethernet и выделенной линией). Все дейтаграммы, идущие вовне локальной сети, он безусловно транслирует на G2, и только G2 приступает именно к маршрутизации. Однако, с точки зрения общего подхода к задаче маршрутизации как определения следующего маршрутизатора в пути дейтаграммы на основе записей в таблице маршрутов, функции G1 и G2 не различаются, различается только сложность их маршрутных таблиц. Поэтому мы будем считать термины “маршрутизатор” (“router”) и “шлюз” (“gateway”) синонимами и будем использовать термин “шлюз”, говоря о маршрутизаторе, расположенном между локальной сетью конечного пользователя (например, сетью предприятия) и “внешним миром”.

Рассмотрим примеры маршрутных таблиц, с которыми имеет дело администратор локальной сети 194.84.124.0/24.

Таблица маршрутов рядового хоста с адресом 194.84.124.4 (хост В на рис. 2.3.2):

Таблица 2.3.1

Значения флагов: U (Up) - маршрут работает; H (Host) - пунктом назначения является отдельный узел (хост), а не сеть; G (Gateway) - маршрут к сети назначения проходит через один или несколько промежуточных маршрутизаторов. Интерфейс le0 обозначает Ethernet, lo0 - интерфейс обратной связи (loopback).

Значение первой записи очевидно, вторая запись определяет, что дейтаграммы, адресованные в локальную сеть, хост отправляет самостоятельно через свой интерфейс le0. Третья запись (маршрут по умолчанию) устанавливает, что все остальные дейтаграммы передаются на адрес 194.84.124.1, который является адресом следующего маршрутизатора (флаг G), для дальнейшей пересылки. Чтобы определить способ достижения самого маршрутизатора, следует, очевидно, обратиться ко второй строке таблицы, так как адрес маршрутизатора принадлежит сети 194.84.124.0.

Заметим, что в этой таблице для простоты опущены маски сетей.

Пример таблицы маршрутов маршрутизатора, соединяющего локальную сеть с провайдером Интернет по выделенному каналу (G1 на рис. 2.3.2):

Таблица 2.3.2

В таблице явно показаны маски сетей.

Первые две записи говорят о том, что маршрутизатор самостоятельно, через свои соответствующие IP-интерфейсы отправляет дейтаграммы, адресованные в сети, к которым он подключен непосредственно. Все остальные дейтаграммы перенаправляются к G2 (194.84.0.118). Интерфейс se0 обозначает последовательный (serial) канал - выделенную линию.

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

Для рядового хоста из рассмотренного выше примера достаточно указать только адрес шлюза (следующего маршрутизатора в маршруте по умолчанию), остальные записи в таблице очевидны, и хост, зная свой собственный IP-адрес и сетевую маску, может внести их самостоятельно. Адрес шлюза может быть указан как вручную, так и получен автоматически при конфигурировании стека TCP/IP через DHCP сервер (см. лабораторную работу “Динамическое присвоение IP-адресов” в курсе “Технологии Интернет”).

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

В зависимости от алгоритма работы различают дистанционно-векторные протоколы (distance vector protocols) и протоколы состояния связей (link state protocols).

По области применения существует разделение на протоколы внешней (exterior) и внутренней (interior) маршрутизации.

Дистанционно-векторные протоколы реализуют алгоритм Беллмана-Форда (Bellman-Ford). Общая схема их работы такова: каждый маршрутизатор периодически широковещательно рассылает информацию о расстоянии от себя до всех известных ему сетей (“вектор расстояний”). В начальный момент времени, разумеется, рассылается информация только о тех сетях, к которым маршрутизатор подключен непосредственно.

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

Дистанционно-векторные протоколы хорошо работают только в небольших сетях. Подробнее алгоритм их работы будет рассмотрен в главе 4. Развитие технологии векторов расстояний - “векторы путей”, применяющиеся в протоколе BGP.

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

Распространенный протокол такого типа, OSPF, базируется на алгоритме SPF (Shortest Path First) поиска кратчайшего пути в графе, предложенном Дейкстрой (E.W.Dijkstra).

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

Протоколы внутренней маршрутизации (например, RIP, OSPF; собирательное название IGP - Interior Gateway Protocols) применяются на маршрутизаторах, действующих внутри автономных систем. Автономная система - это наиболее крупное деление Интернет, представляющее из себя объединение сетей с одинаковой маршрутизационной политикой и общей администрацией, например, совокупность сетей компании Глобал Один и ее клиентов в России.

Область действия того или иного протокола внутренней маршрутизации может охватывать не всю автономную систему, а только некоторое объединение сетей, являющееся частью автономной системы. Такое объединение мы будем называть системой сетей, или просто системой, иногда с указанием протокола маршрутизации, действующего в этой системе, например: RIP-система, OSPF-система.

Маршрутизация между автономными системами осуществляется пограничными (border) маршрутизаторами, таблицы маршрутов которых составляются с помощью протоколов внешней маршрутизации (собирательное название EGP - Exterior Gateway Protocols). Особенность протоколов внешней маршрутизации состоит в том, что при расчете маршрутов они должны учитывать не только топологию графа сети, но и политические ограничения, вводимые администрацией автономных систем на маршрутизацию через свои сети трафика других автономных систем. В настоящее время наиболее распространенным протоколом внешней маршрутизации является BGP.

2.4. Формат заголовка IP-дейтаграммы

IP-дейтаграмма состоит из заголовка и данных.

Заголовок дейтаграммы состоит из 32-разрядных слов и имеет переменную длину, зависящую от размера поля “Options”, но всегда кратную 32 битам. За заголовком непосредственно следуют данные, передаваемые в дейтаграмме.

Формат заголовка:

Значения полей заголовка следующие.

Ver (4 бита) - версия протокола IP, в настоящий момент используется версия 4, новые разработки имеют номера версий 6-8.

IHL (Internet Header Length) (4 бита) - длина заголовка в 32-битных словах; диапазон допустимых значений от 5 (минимальная длина заголовка, поле “Options” отсутствует) до 15 (т.е. может быть максимум 40 байт опций).

TOS (Type Of Service) (8 бит) - значение поля определяет приоритет дейтаграммы и желаемый тип маршрутизации. Структура байта TOS:

Три младших бита (“Precedence”) определяют приоритет дейтаграммы:

111 - управление сетью

110 - межсетевое управление

101 - CRITIC-ECP

100 - более чем мгновенно

011 - мгновенно

010 - немедленно

001 - срочно

000 - обычно

Биты D,T,R,C определяют желаемый тип маршрутизации:

D (Delay)  - выбор маршрута с минимальной задержкой,

T (Throughput) - выбор маршрута с максимальной пропускной способностью,

R (Reliability) - выбор маршрута с максимальной надежностью,

C (Cost) - выбор маршрута с минимальной стоимостью.

В дейтаграмме может быть установлен только один из битов D,T,R,C. Старший бит байта не используется.

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

Total Length (16 бит) - длина всей дейтаграммы в октетах, включая заголовок и данные, максимальное значение 65535, минимальное - 21 (заголовок без опций и один октет в поле данных).

ID (Identification) (16 бит), Flags (3 бита), Fragment Offset (13 бит) используются для фрагментации и сборки дейтаграмм и будут подробнее рассмотрены ниже в п. 2.4.1.

TTL (Time To Live) (8 бит) - “время жизни” дейтаграммы. Устанавливается отправителем, измеряется в секундах. Каждый маршрутизатор, через который проходит дейтаграмма, переписывает значение TTL, предварительно вычтя из него время, потраченное на обработку дейтаграммы. Так как в настоящее время скорость обработки данных на маршрутизаторах велика, на одну дейтаграмму тратится обычно меньше секунды, поэтому фактически каждый маршрутизатор вычитает из TTL единицу. При достижении значения TTL=0 дейтаграмма уничтожается, при этом отправителю может быть послано соответствующее ICMP-сообщение. Контроль TTL предотвращает зацикливание дейтаграммы в сети.

Protocol (8 бит) - определяет программу (вышестоящий протокол стека), которой должны быть переданы данные дейтаграммы для дальнейшей обработки. Коды некоторых протоколов приведены в таблице 2.4.1.

Таблица 2.4.1

Коды IP-протоколов

Header Checksum (16 бит) - контрольная сумма заголовка, представляет из себя 16 бит, дополняющие биты в сумме всех 16-битовых слов заголовка. Перед вычислением контрольной суммы значение поля “Header Checksum” обнуляется. Поскольку маршрутизаторы изменяют значения некоторых полей заголовка при обработке дейтаграммы (как минимум, поля “TTL”), контрольная сумма каждым маршрутизатором пересчитывается заново. Если при проверке контрольной суммы обнаруживается ошибка, дейтаграмма уничтожается.

Source Address (32 бита) - IP-адрес отправителя.

Destination Address (32 бита) - IP-адрес получателя.

Options - опции, поле переменной длины. Опций может быть одна, несколько или ни одной. Опции определяют дополнительные услуги модуля IP по обработке дейтаграммы, в заголовок которой они включены. Подробнее опции рассматриваются в пп. 2.4.3, 2.4.4.

Padding - выравнивание заголовка по границе 32-битного слова, если список опций занимает нецелое число 32-битных слов. Поле “Padding” заполняется нулями.

Различные среды передачи имеют различный максимальный размер передаваемого блока данных (MTU - Media Transmission Unit), это число зависит от скоростных характеристик среды и вероятности возникновения ошибки при передаче. Например, размер MTU в 10Мбит/с Ethernet равен 1536 октетам, в 100 Мбит/с FDDI - 4096 октетам.

При передаче дейтаграммы из среды с большим MTU в среду c меньшим MTU может возникнуть необходимость во фрагментации дейтаграммы. Фрагментация и сборка дейтаграмм осуществляются модулем протокола IP. Для этого применяются поля “ID” (Identification), “Flags” и “Fragment Offset” заголовка дейтаграммы.

Flags -поле состоит из 3 бит, младший из которых всегда сброшен:

0

DF

MF

Значения бита DF (Don’t Fragment):

0 - фрагментация разрешена,

1 - фрагментация запрещена (если дейтаграмму нельзя передать без фрагментации, она уничтожается).

Значения бита MF (More Fragments):

0 - данный фрагмент последний (единственный),

1 - данный фрагмент не последний.

ID (Identification) - идентификатор дейтаграммы, устанавливается отправителем; используется для сборки дейтаграммы из фрагментов для определения принадлежности фрагментов одной дейтаграмме.

Fragment Offset - смещение фрагмента, значение поля указывает, на какой позиции в поле данных исходной дейтаграммы находится данный фрагмент. Смещение считается 64-битовыми порциями, т.е. минимальный размер фрагмента равен 8 октетам, а следующий фрагмент в этом случае будет иметь смещение 1. Первый фрагмент имеет смещение нуль.

Рассмотрим процесс фрагментации на примере. Допустим, дейтаграмма размером 4020 октетов (из них 20 октетов заголовка) передается из среды FDDI (MTU=4096) в среду Ethernet (MTU=1536). На границе сред производится фрагментация дейтаграммы. Заголовки в данной дейтаграмме и во всех ее фрагментах одинаковой длины - 20 октетов.

Исходная дейтаграмма:
заголовок: ID=X, Total Length=4020, DF=0, MF=0, FOffset=0
данные (4000 октетов): “А....А” (1472 октета), “В....В” (1472 октета), “С....С” (1056 октетов)

Фрагмент 1:
заголовок: ID=X, Total Length=1492, DF=0, MF=1, FOffset=0
данные: “А....А” (1472 октета)

Фрагмент 2:
заголовок: ID=X, Total Length=1492, DF=0, MF=1, FOffset=184
данные: “B....B” (1472 октета)

Фрагмент 3:
заголовок: ID=X, Total Length=1076, DF=0, MF=0, FOffset=368
данные: “C....C” (1056 октетов)

Фрагментация может быть рекурсивной, т.е., например, фрагменты 1 и 2 могут быть еще раз фрагментированы; при этом смещение (Fragment Offset) считается от начала исходной дейтаграммы.

Максимальное количество фрагментов равно 2¹³=8192 при минимальном (8 октетов) размере каждого фрагмента. При большем размере фрагмента максимальное количество фрагментов соответственно уменьшается.

При фрагментации некоторые опции копируются в заголовок фрагмента, некоторые — нет. Все остальные поля заголовка дейтаграммы в заголовке фрагмента присутствуют. Следующие поля заголовка могут менять свое значение по сравнению с первоначальной дейтаграммой: поле опций, флаг “MF”, “Fragment Offset”, “Total Length”, “IHL”, контрольная сумма. Остальные поля копируются во фрагменты без изменений.

Каждый модуль IP должен быть способен передать дейтаграмму из 68 октетов без фрагментации (максимальный размер заголовка 60 октетов [IHL=15] + минимальный фрагмент 8 октетов).

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

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

Максимальное количество идентификаторов дейтаграмм - 65536. Если использованы все идентификаторы, нужно ждать до истечения TTL, чтобы можно было вновь использовать тот же самый ID, поскольку за TTL секунд “старая” дейтаграмма будет либо доставлена и собрана, либо уничтожена.

Передача дейтаграмм с фрагментацией имеет определенные недостатки. Например, как следует из предыдущего абзаца, максимальная скорость такой передачи равна 65536/TTL дейтаграмм в секунду. Если учесть, что рекомендованная величина TTL равна 120, получаем максимальную скорость в 546 дейтаграмм в секунду. В среде FDDI MTU равен примерно 4100 октетам, откуда получаем максимальную скорость передачи данных в среде FDDI не более 18 Мбит/с, что существенно ниже возможностей этой среды.

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

Способом обойти процесс фрагментации является применение алгоритма “Path MTU Discovery” (“Выявление MTU на пути следования”), этот алгоритм поддерживается протоколом TCP. Задачей алгоритма является обнаружение минимального MTU на всем пути от отправителя к месту назначения. Для этого посылаются дейтаграммы с установленным битом DF (“фрагментация запрещена”). Если они не доходят до места назначения, размер дейтаграммы уменьшается, и так происходит до тех пор, пока передача не будет успешной. После этого при передаче полезных данных создаются дейтаграммы с размером, соответствующим обнаруженному минимальному MTU.

Опции определяют дополнительные услуги протокола IP по обработке дейтаграмм. Опция состоит, как минимум, из октета “Тип опции”, за которым могут следовать октет “Длина опции” и октеты с данными для опции.

Структура октета “Тип опции”:

Значения бита С:

1 - опция копируется во все фрагменты;

0 - опция копируется только в первый фрагмент.

Определены два класса опций: 0 - “Управление” и 2 - “Измерение и отладка”. Внутри класса опция идентифицируется номером. Ниже приведены опции, описанные в стандарте протокола IP; знак “-” в столбце “Октет длины” означает, что опция состоит только из октета “Тип опции”, число рядом с плюсом означает, что опция имеет фиксированную длину (длина указывается в октетах).

Таблица 2.4.2

Опции IP

При обнаружении в списке опции “Конец списка опций” разбор опций прекращается, даже если длина заголовка (IHL) еще не исчерпана. Опция “Нет операции” обычно используется для выравнивания между опциями по границе 32 бит.

Большинство опций в настоящее время не используются. Опции “Stream ID” и “Безопасность” применялись в ограниченном круге экспериментов, функции опций “Запись маршрута” и “Internet Timestamp” выполняет программа traceroute. Определенный интерес представляют только опции “Loose/Strict Source Routing”, они рассмотрены в следующем пункте.

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

Опции “Loose/Strict Source Routing” (класс 0, номера 3 и 9 соответственно) предназначены для указания дейтаграмме предопределенного отправителем маршрута следования.

Обе опции выглядят одинаково:

Поле “Данные” содержит список IP-адресов требуемого маршрута в порядке следования. Поле “Указатель” служит для определения очередного пункта маршрута, оно содержит номер первого октета IP-адреса этого пункта в поле “Данные”. Номера считаются от начала опции с единицы, начальное значение указателя - 4.

Опции работают следующим образом.

Предположим, дейтаграмма, посланная из A в B, должна проследовать через маршрутизаторы G1 и G2. На выходе из А поле “Destination Address” заголовка дейтаграммы содержит адрес G1, а поле данных опции - адреса G2 и В (указатель=4). По прибытии дейтаграммы в G1 из поля данных опции, начиная с октета, указанного указателем (октет 4), извлекается адрес следующего пункта (G2) и помещается в поле “Destination Address”, при этом значение указателя увеличивается на 4, а на место адреса G2 в поле данных опции помещается адрес того интерфейса маршрутизатора G1, через который дейтаграмма будет отправлена по новому месту назначения (то есть в G2). По прибытии дейтаграммы в G2 процедура повторяется и дейтаграмма отсылается в В. При обработке дейтаграммы в В обнаруживается, что значение указателя (12) превышает длину опции, это значит, что конечный пункт маршрута достигнут.

Отличия опций “Loose Source Routing” и “Strict Source Routing” друг от друга заключаются в следующем:

“Loose”: очередной пункт требуемого маршрута может быть достигнут за любое количество шагов (хопов);

“Strict”: очередной пункт требуемого маршрута должен быть достигнут за 1 шаг, то есть непосредственно.

Рассмотренные опции копируются во все фрагменты. В дейтаграмме может быть только одна такая опция.

Опции “Loose/Strict Source Routing” могут быть использованы в целях несанкционированного проникновения через контролирующий (фильтрующий) узел (в поле “Destination Address” устанавливается разрешенный адрес, дейтаграмма пропускается контролирующим узлом, далее из поля данных опции подставляется запрещенный адрес и дейтаграмма перенаправляется по этому адресу уже за пределами досягаемости контролирующего узла), поэтому в целях безопасности рекомендуется вообще запретить пропуск контролирующим узлом дейтаграмм с рассматриваемыми опциями.

Быстродействующей альтернативой использованию опции “Loose Source Routing” является IP-IP инкапсуляция: вложение IP-дейтаграммы внутрь IP-дейтаграммы (поле “Protocol” внешней дейтаграммы имеет значение 4, см. табл. 2.4.1). Например, требуется отправить некоторый TCP-сегмент из А в В через С. Из А в С отправляется дейтаграмма вида:

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

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

Применение IP-IP инкапсуляции также может вызвать описанные выше проблемы с безопасностью.

Протокол ICMP (Internet Control Message Protocol, Протокол Управляющих Сообщений Интернет) является неотъемлемой частью IP-модуля. Он обеспечивает обратную связь в виде диагностических сообщений, посылаемых отправителю при невозможности доставки его дейтаграммы и в других случаях. ICMP стандартизован в RFC-792, дополнения — в RCF-950,1256.

ICMP-сообщения не порождаются при невозможности доставки:

• дейтаграмм, содержащих ICMP-сообщения;
• не первых фрагментов дейтаграмм;
• дейтаграмм, направленных по групповому адресу (широковещание, мультикастинг);
• дейтаграмм, адрес отправителя которых нулевой или групповой.

Все ICMP-сообщения имеют IP-заголовок, значение поля “Protocol” равно 1. Данные дейтаграммы с ICMP-сообщением не передаются вверх по стеку протоколов для обработки, а обрабатываются IP-модулем.

После IP-заголовка следует 32-битное слово с полями “Тип”, “Код” и “Контрольная сумма”. Поля типа и кода определяют содержание ICMP-сообщения. Формат остальной части дейтаграммы зависит от вида сообщения. Контрольная сумма считается так же, как и в IP-заголовке, но в этом случае суммируется содержимое ICMP-сообщения, включая поля “Тип” и “Код”.

Таблица 2.5.1

Виды ICMP-сообщений

Ниже рассмотрены форматы ICMP-cообщений и даны комментарии к некоторым сообщениям.

В сообщении типа 12 в поле “хххххххххх” (1 октет) заносится номер октета заголовка, в котором обнаружена ошибка; в сообщениях типов 3, 4, 11 не используется. Все неиспользуемые поля заполняются нулями.

Сообщения типа 4 (“Замедление источника”) генерируются в случае переполнения (или опасности переполнения) буферов обработки дейтаграмм адресата или промежуточного узла на маршруте. При получении такого сообщения отправитель должен уменьшить скорость или приостановить отправку дейтаграмм до тех пор, пока он не перестанет получать сообщения этого типа.

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

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

Понятие “место назначения” конкретизируется значением поля “Код” (см. табл. 2.5.1). Информация о том, куда была направлена дейтаграмма, породившая ICMP-сообщения, извлекается из ее заголовка, присоединенного к сообщению. Отсутствие передачи сетевой маски ограничивает область применения сообщений типа 5.

Сообщения типов 0 и 8 используются для тестирования связи по протоколу IP между двумя узлами сети. Тестирующий узел генерирует сообщения типа 8 (“Эхо-запрос”), при этом “Идентификатор” определяет данный сеанс тестирования (номер последовательности отправляемых сообщений), поле “Номер по порядку” содержит номер данного сообщения внутри последовательности. В поле данных содержатся произвольные данные, размер этого поля определяется общей длиной дейтаграммы, указанной в поле “Total length” IP-заголовка.

IP-модуль, получивший эхо-запрос, отправляет эхо-ответ. Для этого он меняет местами адреса отправителя и получателя, изменяет тип ICMP-сообщения на 0 и пересчитывает контрольную сумму.

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

Сообщения типа 9 (объявление маршрутизатора) периодически рассылаются маршрутизаторами хостам сети для того, чтобы хосты могли автоматически сконфигурировать свои маршрутные таблицы. Обычно такие сообщения рассылаются по мультикастинговому адресу 224.0.0.1 (“всем хостам”) или по широковещательному адресу.

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

Поле “NumAddr” содержит количество адресов маршрутизаторов в данном сообщении; значение поля “AddrEntrySize” равно двум (размер поля, отведенного на информацию об одном маршрутизаторе, в 32-битных словах). “Время жизни” определяет срок годности информации, содержащейся в данном сообщении, в секундах.

Сообщения типа 10 (запрос объявления маршрутизатора) состоит из двух 32-битных слов, первое из которых содержит поля “Тип”, “Код” и “Контрольная сумма”, а второе зарезервировано (заполняется нулями).

Сообщения типов 17 и 18 (запрос и ответ на запрос значения маски сети) используются в случае, когда хост желает узнать маску сети, в которой он находится. Для этого в адрес маршрутизатора (или широковещательно, если адрес маршрутизатора неизвестен) отправляется запрос. Маршрутизатор отправляет в ответ сообщение с записанным в нем значением маски той сети, из которой пришел запрос. В том случае, когда отправитель запроса еще не знает своего IP-адреса, ответ отправляется широковещательно.

Поля “Идентификатор” и “Номер по порядку” могут использоваться для контроля соответствий запросов и ответов, но в большинстве случаев игнорируются.

Протокол ARP (Address Resolution Protocol, Протокол распознавания адреса) предназначен для преобразования IP-адресов в MAC-адреса, часто называемые также физическими адресами.

MAC расшифровывается как Media Access Control, контроль доступа к среде передачи. МАС-адреса идентифицируют устройства, подключенные к физическому каналу, пример MAC-адреса - адрес Ethernet.

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

Поиск по данному IP-адресу соответствующего Ethernet-адреса производится протоколом ARP, функционирующим на уровне доступа к среде передачи. Протокол поддерживает в оперативной памяти динамическую arp-таблицу в целях кэширования полученной информации. Порядок функционирования протокола следующий.

С межсетевого уровня поступает IP-дейтаграмма для передачи в физический канал (Ethernet), вместе с дейтаграммой передается, среди прочих параметров, IP-адрес узла назначения. Если в arp-таблице не содержится записи об Ethernet-адресе, соответствующем нужному IP-адресу, модуль arp ставит дейтаграмму в очередь и формирует широковещательный запрос. Запрос получают все узлы, подключенные к данной сети; узел, опознавший свой IP-адрес, отправляет arp-ответ (arp-response) со значением своего адреса Ethernet. Полученные данные заносятся в таблицу, ждущая дейтаграмма извлекается из очереди и передается на инкапсуляцию в кадр Ethernet для последующей отправки по физическому каналу.

ARP-запрос или ответ включается в кадр Ethernet непосредственно после заголовка кадра.

Форматы запроса и ответа одинаковы и отличаются только кодом операции (Operation code, 1 и 2 соответственно).

Несмотря на то, что ARP создавался специально для Ethernet, этот протокол может поддерживать различные типы физических сред (поле “Hardware type (Тип физической среды)”, значение 1 соответствует Ethernet), а также различные типы обслуживаемых протоколов (поле “Protocol type (Тип протокола)”, значение 2048 соответствует IP). Поля H-len и P-len содержат длины физического и “протокольного” адресов соответственно, в октетах. Для Ethernet H-len=6, для IP P-len=4.

Поля “Source hardware address” и “Source protocol address” содержат физический (Ethernet) и “протокольный” (IP) адреса отправителя. Поля “Target hardware address” и “Target protocol address” содержат соответствующие адреса получателя. При посылке запроса поле “Target hardware address” инициализируется нулями, а в поле “Destination (Адрес назначения)” заголовка Ethernet-кадра ставится широковещательный адрес.

Дейтаграмма, направленная во внешнюю (в другую) сеть, должна быть передана маршрутизатору. Предположим, хост А отправляет дейтаграмму хосту В через маршрутизатор G. Несмотря на то, что в заголовке дейтаграммы, отправляемой из А, в поле “Destination” указан IP-адрес В, кадр Ethernet, содержащий эту дейтаграмму, должен быть доставлен маршрутизатору. Это достигается тем, что IP-модуль при вызове ARP-модуля передает тому вместе с дейтаграммой в качестве IP-адреса узла назначения адрес маршрутизатора, извлеченный из таблицы маршрутов. Таким образом, дейтаграмма с адресом В инкапсулируется в кадр с MAC-адресом G:

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

ARP-ответ может отправляться не обязательно искомым узлом, вместо него это может сделать другой узел. Такой механизм называется proxy ARP.

Рассмотрим пример (рис. 2.6.1). Удаленный хост А подключается по коммутируемой линии к сети 194.84.124.0/24 через сервер доступа G. Сеть 194.84.124.0 на физическом уровне представляет собой Ethernet. Сервер G выдает хосту А IP-адрес 194.84.124.30, принадлежащий сети 194.84.124.0. Следовательно, любой узел этой сети, например, хост В, полагает, что может непосредственно отправить дейтаграмму хосту А, поскольку они находятся в одной IP-сети.

Рис. 2.6.1. Proxy ARP

IP-модуль хоста В вызывает ARP-модуль для определения физического адреса А. Однако вместо А (который, разумеется, откликнуться не может, потому что физически не подключен к сети Ethernet) откликается сервер G, который и возвращает свой Ethernet-адрес как физический адрес хоста А. Вслед за этим В отправляет, а G получает кадр, содержащий дейтаграмму для А, которую G отправляет адресату по коммутируемому каналу.