Протокол iPv4

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

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

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

Так как обработка дейтаграммы происходит с помощью программного обес­печения, оборудование не накладывает никаких ограничений на ее содержимое и формат. Например, первое 4-битовое поле «Версия» в дейтаграмме содержит версию протокола IP, используемую при создании дейтаграммы. Оно ис­пользуется отправителем, получателем, и всеми маршрутизаторами между ними для уверенности подтверждения того, что все они используют один и тот же формат дейтаграммы. Всему программному обеспечению IP необходимо проверять поле версии перед обработкой дейтаграммы для подтверждения того, что ее формат соответствует формату, который ожидает это обеспечение. Если стандарт меняется, машины будут отбрасывать дейтаграммы с версией про­токола, отличающейся от версии, на которой они работают, предохраняя себя от неправильной интерпретации содержимого дейтаграммы из-за устаревшего формата. В настоящее время наибольшее распространение получила версия IPv4, которую постепенно сменит более совершенная IPv6. Рассмотрим пос­ледовательно эти версии.

Поле длины заголовка «Длина» также занимает 4 бита и хранит длину заго­ловка дейтаграммы в 32-битных словах. Все поля в заголовке имеют фиксиро­ванную длину, за исключением поля «Опции IР» и соответствующего ему поля «Заполнение». Наиболее простой заголовок, без опций и заполнения, занимает 20 октетов и имеет в поле заголовка «Длина» значение 5.

Поле «Общая длина» определяет длину IP-дейтаграммы, измеренную в ок­тетах, включая октеты в заголовке и данных. Размер области данных можно вычислить путем вычитания длины заголовка «Длина» из «Общей длины». Так как поле «Общая длина» занимает 16 бит, то максимально возможный размер дейтаграммы IPv4 составляет 65535 октет.

Поле «Тип сервиса» 8 бит указывает, как следует обрабатывать дейта­грамму. Это поле разделено на пять подполей (рис.).

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

Биты D, Т и R описывают тип передачи, который нужен дейтаграмме. Уста­новка бита D запрашивает минимальные задержки при передаче, бита Т - мак­симальную пропускную способность, а бита R - максимальную надежность. Конечно, межсетевое взаимодействие не может гарантировать выполнение зап­рошенного сервиса (например, может быть так, что нет пути к назначению с запрошенными качествами). Поэтому можно рассматривать запрос сервиса как указание алгоритмам маршрутизации, а не как требование. Если маршру­тизатор знает более чем один маршрут к указанному назначению, он может использовать поле типа передачи для выбора пути с характеристиками наи­более близкими требуемым. Например, предположим, что маршрутизатор может выбирать между низкоскоростной арендованной линией или высоко­скоростной (но с большими паузами) спутниковой линией. Дейтаграммы, передающие нажатия клавиш от пользователя к удаленному компьютеру, могут иметь установленным бит D, запрашивая самую быструю доставку, в то время как дейтаграммы, используемые при передаче большого файла, мо­гут иметь установленным бит Т, запрашивая передачу по высокоскоростной спутниковой линии.

Управление фрагментацией. Три поля в заголовке дейтаграммы - Иден­тификация, Флаги и Смещение фрагмента - управляют фрагментацией и сбор­кой дейтаграмм (см. рис. 5.16). Поле «Идентификация» содержит уникальное целое число, которое идентифицирует дейтаграмму. Напомним, что когда шлюз или маршрутизатор фрагментирует дейтаграмму, он копирует большую часть полей в заголовке дейтаграммы в каждый фрагмент. Поле «Идентификация» позволяет получателю узнать, какой дейтаграмме принадлежат прибывающие фрагменты. Когда появляется фрагмент, получатель для идентификации дей­таграммы использует поле «Идентификация» вместе с полем адреса источни­ка. Компьютер, посылающий IP-дейтаграммы, должен генерировать уникаль­ное значение поля «Идентификация» для каждой отдельной дейтаграммы (в теории, повторные передачи дейтаграммы должны содержать то же самое зна­чение в поле «Идентификация», что и в исходной дейтаграмме; на практике, протоколы высокого уровня обычно выполняют повторную передачу как новую дейтаграмму со своим значением поля «Идентификация»). Один из модулей, используемых в программном обеспечении IP, хранит глобальный счетчик в памяти, инкрементирует его каждый раз, когда создается новая дейтаграмма, и копирует результат в поле «Идентификация» дейтаграммы.

Напомним, что каждый фрагмент имеет точно такой же формат, что и пол­ная дейтаграмма. Для фрагмента поле «Смещение фрагмента» указывает сме­щение в исходной дейтаграмме данных, передаваемых в фрагменте, измеряе­мое в 8 октетах (смещения измеряются в восьмерках октетов для сохранения места в заголовке), начиная со смещения ноль. Для сборки дейтаграммы это поле должно получить назначение во всех фрагментах, начиная с фрагмента со смещением 0 до фрагмента с наибольшим смещением. Фрагменты необяза­тельно прибывают по порядку, и не существует прямого взаимодействия меж­ду маршрутизатором, который фрагментирует дейтаграммы, и получателем, который пытается собирать их.

Младшие два бита из трехбитового поля «Флаги» управляют фрагментаци­ей. Обычно прикладное программное обеспечение, использующее TCP/IP, не заботится о фрагментации, так как и фрагментация, и сборка являются авто­матическими процедурами, выполняемыми на низком уровне в операционной системе незаметно для пользователя. Тем не менее, для тестирования межсе­тевого программного обеспечения или отладки рабочих программ может ока­заться важной проверка размеров дейтаграмм, для которых осуществляется фрагментация. Первый управляющий бит помогает при таком тестировании, указывая возможность фрагментации дейтаграммы. Он называется битом «не фрагментировать», так как установка его в единицу указывает, что дейтаграм­му нельзя фрагментировать. Приложение может выбрать запрет фрагмента­ции, когда нужна лишь целая дейтаграмма. Всякий раз, когда маршрутизатору нужно фрагментировать дейтаграмму с установленным битом «не фрагменти­ровать», он удаляет дейтаграмму и посылает обратно источнику сообщение об ошибке.

Младший бит в поле «Флаги» указывает, содержит ли фрагмент данные из середины дейтаграммы или из конца. Он называется битом «еще фрагменты». Поясним необходимость наличия этого бита. Программное обеспечение IP у получателя будет получать фрагменты ( возможно не по порядку), и ему нужно будет знать, когда оно получит все фрагменты дейтаграммы. Когда поступает очередной фрагмент, поле «Общая длина» в заголовке указывает размер фраг­мента, а не размер всей дейтаграммы, поэтому получатель не может исполь­зовать поле «Общая длина» для того, чтобы определить, собрало ли он все фрагменты. Бит «еще фрагменты» легко решает проблему: как только получа­тель получает фрагмент со сброшенным битом «еще фрагменты», он знает, что этот фрагмент несет в себе данные из конца исходной дейтаграммы. На основе полей «Смещение фрагмента» и «Общая длина» оно может вычислить длину исходной дейтаграммы. Проверив «Смещение фрагмента» и «Общая длина» у всех прибывших фрагментов, получатель может определить, содер­жат ли фрагменты все данные, требуемые для сборки исходной дейтаграммы.

Время жизни дейтаграммы. Поле «Время жизни» указывает, сколько секунд может оставаться дейтаграмма в межсетевой системе. Эта идея яв­ляется насколько простой, настолько и важной: всякий раз, когда машина пере­дает дейтаграмму в Интернет, она устанавливает максимальное время суще­ствования дейтаграммы. Шлюзы и маршрутизаторы, обрабатывающие дейтаграмму, должны декрементировать поле «Время жизни» по мере того, как идет время, и удалять дейтаграмму из Интернета, когда время вышло.

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

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

Значение в поле «Протокол» указывает, какой протокол высокого уровня использовался при создании сообщения, передаваемого в области «Данные» дейтаграммы. По существу, значение в «Протокол» специфицирует формат области «Данные». Соответствие между протоколом высокого уровня и целым числом, используемым в поле «Протокол», должно устанавливаться ответствен­ным центром, чтобы гарантировать действие соглашения по всему Интернету.

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

IP-адреса. Поля «Адрес отправителя IР» и «Адрес получателя IР» содержат 32-битовые IP-адреса отправителя и конечного получателя дейтаграммы IPv4. Хотя дейтаграмма может проходить через большое число промежуточных шлюзов или маршрутизаторов, поля отправителя и получателя никогда не изменяются; они указывают IP-адреса истинного источника и конечного назначения.

Поле «Опции IР», рассматриваемое ниже, имеет переменную длину. Поле «Заполнение» зависит от выбранных опций. Оно представляет собой биты, со­держащие нули, которые могут потребоваться для дополнения заголовка дей­таграммы до длины, кратной 32 бит (напомним, что поле длины заголовка ука­зывает ее в 32-битных словах).

Межсетевые опции дейтаграммы. Поле «Опции IР», следующее за адре­сом назначения, не нужно каждой дейтаграмме; опции включаются, в основном, для тестирования или отладки сети. Обработка опций, тем не менее, является составной частью протокола IP, поэтому все стандартные реализации включа­ют ее. Длина поля «Опции 1Р» зависит от выбранных опций. Когда в дейта­грамме есть опции, они размещаются друг за другом, без специальных разде­лителей между ними. Каждая опция состоит из кода опции длиной 1 октет, за которым может следовать длина опции (тоже занимает 1 октет) и группы окте­тов данных для этой опции. Октет кода опции делится на три поля: 1-битовый флаг «Копировать», 2-битовый «Класс опции» и 5-битовый «Номер опции» (рис. 5.22). Флаг «Копировать» управляет тем, как маршрутизаторы рассмат­ривают опции при фрагментации. Когда бит «Копировать» установлен в 1, он ука­зывает, что эта опция должна копировать­ся во все фрагменты. Когда он установ­лен в 0 - опцию нужно копировать только в первый фрагмент, а не во все.

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

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

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

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

При прибытии дейтаграммы машина-получатель должна выделить и обра­ботать список IP-адресов. Если получатель обрабатывает дейтаграмму обыч­ным образом, он будет игнорировать записанный путь. Следует отметить, что отправитель должен разрешить наличие опции записи маршрута, а получатель должен быть согласен обработать полученный список; сама по себе машина не получит информацию о пройденном пути автоматически, если она включит опцию записи маршрута.

Опции пути источника. Идея, лежащая в основе маршрутизации источни­ка, заключается в том, чтобы отправитель мог определять путь в Интернете. Например, для тестирования пропускной способности конкретной физической сети N-системные администраторы могут использовать маршрутизацию ис­точника для направления IP-дейтаграмм через сеть N, даже если маршрути­заторы обычно выбирают путь, не включающий ее. Возможность делать та­кие тесты особенно важна в производственной среде, так как позволяет сетевым администраторам маршрутизировать дейтаграммы пользователей по сетям,

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

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

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

Формат опции маршрутизации источника напоминает показанный выше фор­мат опции записи маршрута. Каждый маршрутизатор проверяет поля «Указа­тель» и «Длина», чтобы обнаружить переполнение списка. Если это произошло, указатель будет больше, чем длина, и маршрутизатор будет маршрутизиро­вать дейтаграмму к ее назначению обычным образом. Если список заполнен еще не до конца, маршрутизатор на основании указателя выделяет 1Р-адрес, заменяет его на свой адрес (маршрутизатор имеет по одному адресу для каж­дого интерфейса; он записывает адрес, соответствующий сети, по которой он отправляет дейтаграмму) и маршрутизирует дейтаграмму, используя адрес, полученный из списка.

Опция временных меток. Эта опция работает аналогично опции записи маршрута в том отношении, что опция временных меток содержит вначале пустой список, а каждый шлюз на всем протяжении пути от источника к назна­чению заполняет элемент в этом списке. Каждый элемент в списке состоит из двух 32-битных частей: IP-адреса маршрутизатора, заполнившего этот элемент, и 32-биггового целого числа - временной метки. На рис. 5.25 приведен формат опции временных меток.

На этом рисунке поля «Длина» и «Указатель» исполь­зованы для указания длины зарезервированного места и местонахождения сле­дующего неиспользованного слота (как в опции записи маршрута). 4-битовое поле «Переп» содержит целое число шлюзов, которые не смоти записать вре­менные метки из-за слишком маленького размера опции. Значение в 4-бито­вом поле «Флаги» определяет точный формат опции и говорит маршрутизато­рам, как записывать временнйе метки. Допускаются следующие значения поля «Флаги»:

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

2. - указывать перед каждой временной меткой IP-адрес (формат, показан­ный на рис. 5.25);

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

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

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

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

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