Введение в Интернет

1.2.9. О размере пакетов

Как уже было замечено выше, протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов, должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.

Для каждого канала, с которым связан узел непосредственно, он должен быть способен принимать пакеты с размером MTU данного канала. В каналах, которые можно конфигурировать, например, PPP [RFC-1661], должно быть установлено MTU не менее 576 октетов; рекомендуется устанавливать максимально возможное MTU, чтобы позволить инкапсуляцию (туннелирование) без привлечения фрагментации.

Настоятельно рекомендуется, чтобы узлы IPv6 использовали механизм определения MTU пути [RFC-1191] для реализации преимущества большого значения MTU. Однако в минимальной конфигурации IPv6 (например, в BOOT ROM) может ограничивать себя в пределах 576 октетов и не применять процедуру выявления MTU пути.

Для того чтобы послать пакет длиннее, чем MTU канала, узел может задействовать заголовок фрагментации IPv6. Однако использование такой фрагментации заблокировано в приложениях, где применяется настройка по измеренному значению MTU пути.

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

В ответ на IPv6 пакет, посланный IPv4 адресату (т.e. пакет, который подвергается преобразованию из IPv6 в IPv4), узел отправитель IPv6 может получить ICMP сообщение packet too big, предупреждающее о том, что MTU следующего узла меньше 576. В этом случае узел IPv6 не должен уменьшать размер пакетов до 576 октетов, он должен включить в эти пакеты заголовок фрагментации, так, чтобы маршрутизатор, выполняющий трансляцию IPv6-IPv4, мог получить приемлемый код идентификации для использования полученных IPv4 фрагментов. Заметьте, что это означает сокращение длины поля данных до 528 октетов (576 минус 40 для IPv6-заголовка и 8 для заголовка фрагментации), и меньше, если имеются другие заголовки расширения.

Замечание. Анализ MTU пути должно проводиться даже в случае, когда узел полагает, что адресат находится на том же канале что и сам узел.

В отличие от IPv4, в IPv6 не нужно устанавливать флаг "don't fragment" (не фрагментировать) в заголовках пакетов, для того чтобы выполнить операцию определения величины MTU канала; так как это является атрибутом любого IPv6 пакета по умолчанию. Части процедур из RFC-1191, которые включают в себя использование таблиц MTU, не применимы к IPv6, так как версия сообщения IPv6 "datagram too big" всегда указывает на точное значение MTU, которое следует использовать.

1.2.10. Метки потоков

24-битовое поле метки потока в заголовке IPv6 может использоваться отправителем для выделения пакетов, для которых требуется специальная обработка в маршрутизаторе, такая, например, как нестандартная QoS или realtime сервис. Этот аспект IPv6 является пока экспериментальным и может быть изменен позднее. Для ЭВМ или маршрутизаторов, которые не поддерживают функцию пометки потоков, это поле должно быть обнулено при формировании пакета, сохраняться без изменения при переадресации и игнорироваться при получении.

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

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

Метка потока присваивается потоку узлом отправителя. Новые метки потоков должны выбираться псевдослучайным образом из диапазона чисел 1 - FFFFFF. Целью псевдослучайного выбора метки является возможность использования любого набора бит поля метки потока в качестве хэш ключа маршрутизаторами для контроля состояния соответствующего потоку.

Все пакеты, принадлежащие одному потоку, должны быть посланы одним отправителем, иметь один и тот же адрес места назначения, приоритет и метку потока. Если какой-либо из этих пакетов включает в себя заголовок опций hop-by-hop, тогда все они должны начинаться с одного и того же содержания заголовка опций hop-by-hop (исключая поле следующий заголовок заголовка опций hop-by-hop). Если любой из этих пакетов включает заголовок маршрутизации, тогда все они должны иметь идентичные заголовки расширения, включая заголовок маршрутизации, но исключая поле следующий заголовок заголовка маршрутизации. Маршрутизаторы и узлы-адресаты могут проверять эти требования (хотя это и необязательно). Если обнаружено нарушение, должно быть послано ICMP сообщение отправителю (problem message, код 0) с указателем на старший октет поля метка потока (т.e., смещение 1 в IPv6 пакете).

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

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

Время жизни режима обработки потока задается явно в процессе конфигурации, например, через протокол управления или посредством опции hop-by-hop, и может превышать 6 секунд.

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

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

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