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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Протокол ICMP

Протокол 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ообщений и даны комментарии к некоторым сообщениям.

Типы 3, 4, 11, 12

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

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

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

Тип 5

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

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

Типы 0,8

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

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

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

Тип 9

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

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

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

Тип 10

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

Типы 17 и 18

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

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

20.2. Протокол IPv6.

Адресация IPv6

В конце 1992 года сообщество Интернет для решения проблем адресного пространства и ряда смежных задач разработало три проекта протоколов: “TCP and UDP with Bigger Addresses (TUBA)”; “Common Architecture for the Internet (CatnIP)” и “Simple Internet Protocol Plus (SIPP) [смотри “Протоколы и ресурсы Интернет” Семенов Ю.А., Радио и связь, М 1995]. После анализа всех этих предложений был принят новый протокол IPv6 с IP-адресами в 128 бит вместо 32 для IPv4. Внедрение этого нового протокола представляет отдельную серьезную проблему, так как этот процесс не предполагает замены всего программного обеспечения во всем мире одновременно.

Адресное пространство IPv6 будет распределяться IANA(Internet Assigned Numbers Authority - комиссия по стандартным числам в Интернет [RFC-1881]). В качестве советников будут выступать IAB (internet architecture board - совет по архитектуре Интернет) и IESG (Internet Engineering Steering Group - инженерная группа управления Интернет).

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

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

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

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

Следует избегать монополизации и любых злоупотреблений при распределении IP-v6 адресов. IANA разработает план первичного распределения IPv6 адресов, включая автоматическое выделение адресов индивидуальным пользователям.

IPv6 представляет собой новую версию протокола Интернет (RFC-1883), являющуюся преемницей версии 4 (IPv4; RFC-791). Изменения IPv6 по отношению к IPv4 можно поделить на следующие группы:

· Расширение адресации

В IPv6 длина адреса расширена до 128 бит (против 32 в IPv4), что позволяет обеспечить больше уровней иерархии адресации, увеличить число адресуемых узлов, упростить авто-конфигурацию. Для расширения возможности мультикастинг-маршрутизации в адресное поле введено субполе "scope" (группа адресов). Определен новый тип адреса "anycast address" (эникастный), который используется для посылки запросов клиента любой группе серверов. Эникаст адресация предназначена для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее.

· Спецификация формата заголовков

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

· Улучшенная поддержка расширений и опций

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

· Возможность пометки потоков данных

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

· Идентификация и защита частных обменов

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

Формат и семантика адресов IPv6 описаны в документе RFC-1884. Версия ICMP IPv6 рассмотрена в RFC-1885.

Терминология

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

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

Рис. 4.4.1.1.1. Формат заголовка пакета IPv6

Поиск по сайту: