2. Если флаг "Не фрагментировать" установлен в 0, то поле данных разделяется на отдельные части в соответствии с MTU следующего участка. Полученные части выравниваются по 8-октетной границе.
3. Каждой части присваивается заголовок IP, подобный заголовку исходной датаграммы, в частности копируются значения полей источника, назначения, протокола и идентификации. Однако следующие поля устанавливаются индивидуально для каждой из частей:
a. Длина датаграммы будет отражать текущую длину полученной датаграммы.
b. Флаг More из поля флагов устанавливается в 1 для всех частей, кроме последней.
c. Поле смещения фрагмента будет указывать позицию полученной части относительно начала исходной датаграммы. Начальная позиция принимается за 0. Смещение фрагмента равно реальному смещению, разделенному на 8.
d. Для каждого фрагмента вычисляется собственная контрольная сумма.
Теперь настало время более подробно рассмотреть поля при фрагментации датаграммы.
6.14.1 Поле идентификации
Поле идентификации содержит 16-разрядное число, помогающее хосту назначения распознать фрагмент датаграммы при сборке.
6.14.2 Поле Флагов
Поле флагов содержит три бита:
Бит 0 Бит 1 Бит 2 0=Зарезервировано 0=Можно фрагментировать 1=Нельзя фрагментировать 0=Последний фрагмент (Last) 1=Есть еще фрагменты (More)Бит 0 зарезервирован, но должен иметь значение 0. Отправитель может указать в следующем бите значение 1, и датаграмму нельзя будет фрагментировать. Если ее нельзя будет доставить без фрагментации, а бит фрагментации равен 1, то датаграмма будет отброшена с посылкой сообщения отправителю.
Бит 2 устанавливается в 0 для последней или единственной части датаграммы. Бит 2, установленный в 1, указывает, что датаграмма фрагментирована и имеет следующие далее части.
6.14.3 Поле смещения фрагмента
Блок фрагментации (fragment block) — это 8-октетная порция данных. Число в поле смещения фрагмента (Fragment Offset) указывает величину смещения данного фрагмента (относительно начала датаграммы) в единицах блоков фрагментирования. Это поле имеет длину 13 бит (т.е. смещение может быть от 0 до 8192 блоков фрагментирования — или от 0 до 65 528 октетов). Предположим, что маршрутизатор разделил датаграмму (с идентификатором 348) из 3000 байт данных на три датаграммы по 1000 байт. Каждый фрагмент будет содержать собственный заголовок и 1000 байт данных (125 блоков фрагментирования). Содержимое полей идентификации, флагов и смещений фрагментов будет следующим:
Фрагмент Идентификатор Флаги Смещение фрагмента 1 348 Можно фрагментировать, More 0 блоков от начала 2 348 Можно фрагментировать, More 125 блоков (1000 октетов) от начала 3 348 Можно фрагментировать, Last 250 блоков (2000 октетов) от началаКогда датаграмма доставляется без фрагментации, значения полей будут следующими:
Идентификатор Флаги Смещение фрагмента 348 Можно фрагментировать, Last 0 блоков от началаХост получателя, приняв датаграмму, помеченную как "Last" и имеющую смещение 0, знает, что она не фрагментирована.
6.14.4 Сборка фрагментированной датаграммы
Сборка фрагментированной датаграммы выполняется хостом-получателем. Отдельные части такой датаграммы могут прибывать в произвольном порядке. Когда в точке назначения появляется первый фрагмент, IP выделяет определенную область памяти для последующей сборки всей датаграммы. Поле смещения фрагмента указывает на байтовую границу для данных полученного фрагмента.
Совпадающие по полям идентификации, IP-адреса источника, IP-адреса назначения и протокола фрагменты составляются вместе по мере их поступления. Однако в протоколе IP имеется небольшой недостаток: хост получателя не может узнать общей длины датаграммы, пока не получит последний фрагмент. Поле общей длины (Total Length) содержит сведения только о данном фрагменте, а не об общей длине датаграммы.
Таким образом, система-получатель должна иметь возможность предвидеть, сколько именно буферного пространства нужно зарезервировать для принимаемой датаграммы. Разработчики решают эту проблему различными способами. Некоторые последовательно выделяют для буфера небольшие части памяти, другие сразу предоставляют единый большой буфер.
В любом случае при реализации необходимо обслуживать поступающую датаграмму с общей длиной, как минимум, в 576 октетов. Или, что более точно, система должна быть способна обрабатывать датаграммы с общим размером не менее чем MTU интерфейса, по которому поступают датаграммы.