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

Смещение фрагмента, выражаемое в 8-октетных блоках и отсчитываемое от начала фрагментируемой части оригинального пакета. Смещение первого фрагмента (самого левого) равно нулю.

Код M-флага равен нулю, если фрагмент является последним (самым правым), в противном случае флаг равен 1.

(3) Сам фрагмент.

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

Восстановленный оригинальный пакет:

Рис. 4.4.1.1.24.

В процессе восстановления должны выполняться следующие правила:

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

Не фрагментируемая часть восстанавливаемого пакета состоит из всех заголовков вплоть до (но не включая) заголовок фрагмента первого пакета-фрагмента (пакет со смещением равным нулю). При этом производятся следующие изменения:

Поле следующий заголовок последнего заголовка не фрагментируемой части берется из поля следующий заголовок заголовка первого фрагмента.

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

pl.orig = pl.first - fl.first - 8 + (8 * fo.last) + fl.last

где

pl.orig - поле длины данных восстановленного пакета.
pl.first - поле длины данных первого пакета-фрагмента.
fl.first - длина фрагмента, следующего за заголовком первого пакета-фрагмента.
fo.last - Поле смещения фрагмента в заголовке последнего пакета-фрагмента.
fl.last - длина фрагмента, следующего за заголовком фрагмента последнего пакета-фрагмента.

Фрагментируемая часть восстановленного пакета состоит из частей, следующих за заголовками в каждом из пакетов-фрагментов. Длина каждого фрагмента вычисляется путем вычитания из длины поля данных длины заголовков, размещенных между IPv6 заголовком и самим фрагментом. Их относительное положение в фрагментируемой части вычисляется на основе значения смещения фрагмента. Заголовок фрагмента отсутствует в восстановленном пакете.

В процессе сборки могут возникнуть следующие ошибки:

Если в пределах 60 секунд после прихода первого фрагмента получено недостаточно фрагментов для завершения сборки, процедура сборки должна быть прервана и все полученные фрагменты выкинуты. Если первый фрагмент (т.e., пакет с нулевым смещением) получен, посылается ICMP сообщение "Time exceeded -- Fragment reassemble time exceeded".

Если длина фрагмента, полученная из поля длины данных пакета, не является кратным 8 октетам, а M флаг фрагмента равен 1, фрагмент должен быть выброшен и должно быть послано сообщение ICMP (parameter problem, код 0) с указателем на поле длины данных пакета-фрагмента.

Если длина и смещение фрагмента таковы, что восстановленная длина поля данных фрагмента превосходит 65,535 октетов, фрагмент выбрасывается, посылается сообщение ICMP (parameter problem, код 0) с указателем на поле смещения фрагмента пакета-фрагмента.

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

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

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

Заголовок опции места назначения используется для передачи опционной информации, которая должна анализироваться только узлом (узлами) назначения. Заголовок опции места назначения идентифицируется кодом поля следующий заголовок равным 60 предшествующего заголовка и имеет формат (рис. 4.4.1.1.25):

Рис. 4.4.1.1.25. Формат заголовка опции места назначения

Следующий заголовок - 8-битовый селектор. Идентифицирует тип заголовка, который непосредственно следует за заголовком опций места назначения. Использует те же коды протокола, что и IPv4 [RFC-1700].

Hdr Ext Len - 8-битовое целое без знака. Длина заголовка опций места назначения в 8-октетных блоках, исключая первые 8 октетов.

Опции - поле переменной длины, кратное 8 октетам. Содержит одну или более TLV-закодированных опций.

Здесь определены только две опции места назначения Pad1 и padn. Обратите внимание, что существует два способа кодировки опционной информации места назначения для пакетов IPv6: в заголовке опций места назначения, или в виде отдельного заголовка расширения. Заголовок фрагмента и заголовок идентификации являются примерами последнего подхода. Какой из подходов будет применен, зависит от того, какая операция желательна в узле места назначения:

• если желательно, чтобы узел назначения уничтожил пакет и, если адрес места назначения не является мультикастинговым, отправителю посылается сообщение ICMP unrecognized type, затем информация может быть закодирована в отдельном заголовке или в опции места назначения с кодом типа опции, равным 11 в старших двух битах. Выбор может зависеть от таких факторов как число необходимых октетов, проблема выравнивания или более простой анализ пакета.
• если желательна какая-либо иная операция, информация должна быть закодирована в виде опции места назначения с типом опции 00, 01 или 10 в старших двух битах.

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

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

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

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

Для того чтобы послать пакет длиннее чем 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, которое следует использовать.

24-битовое поле метки потока в заголовке IPv6 может использоваться отправителем для выделения пакетов, для которых требуется специальная обработка в маршрутизаторе, такая например, как нестандартная QoS или "real-time " сервис. Этот аспект 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 секундам. Метки потока, которые используются для потоков, существующих более продолжительное время не должны использоваться соответственно дольше.

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

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

4-битовое поле приоритета в IPv6 заголовке позволяет отправителю идентифицировать относительный приоритет доставки пакетов. Значения приоритетов делятся на два диапазона. Коды от 0 до 7 используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки (например, снижает поток TCP в ответ на сигнал перегрузки). Значения с 8 до 15 используются для определения приоритета трафика, для которого не производится снижения потока в ответ на сигнал перегрузки, например, в случае пакетов "реального времени", посылаемых с постоянной частотой.

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

Таблица 4.4.1.1.2. Значения кодов приоритета

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

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

Любой транспортный или другой протокол верхнего уровня, который включает адреса IP-заголовка в свою контрольную сумму, должен быть модифицирован, чтобы работать с 128-битовыми IPv6адресами вместо 32-битовых IPv4. В частности, ниже показаны псевдо-заголовки для TCP и UDPв IPv6 (рис. 4.4.1.1.26):

Рис. 4.4.1.1.26. Формат псевдо-заголовков для TCP и UDP

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

• Код поля следующий заголовок в псевдо-заголовке идентифицирует протокол верхнего уровня (например, 6 для TCPили 17 для UDP). Он будет отличаться от кода поля следующий заголовок в IPv6 заголовке, если имеются заголовки расширения между заголовком IPv6 и заголовком протокола верхнего уровня.
• В качестве кода длины поля данных в псевдо-заголовке используется длина пакета протокола верхнего уровня, включая заголовок верхнего уровня. Он будет меньше длины поля данных в заголовке (или в опции Jumbo Payload), если имеются заголовки расширения между IPv6 заголовком и заголовком верхнего уровня.
• В отличие от IPv4, при формировании udp пакетов в IPv6 узле, контрольная сумма не является опционной. Поэтому при формировании UDP-пакета IPv6 узел должен вычислить контрольную UDP сумму пакета и псевдо-заголовка и, если вычисление дает в качестве результата нуль, он должен быть заменен на ffff для помещения в UDP заголовок. IPv6-получатели должны выбрасывать UDP пакеты, содержащие нулевую контрольную сумму и фиксировать при этом состояние ошибки.

IPv6 версия ICMP-пакетов [RFC-1885] включает псевдо-заголовок в вычисление контрольной суммы; это отличается от IPv4 версии ICMP, которая не включает псевдо-заголовок в контрольную сумму. Причина изменения связана с попыткой защитить ICMP от некорректной доставки или искажений важных полей в IPv6 заголовке, который в отличие от IPv4 не защищен контрольным суммированием на интернет-уровне. Поле следующий заголовок в псевдо-заголовке для ICMP содержит код 58, который идентифицирует IPv6 версию ICMP.

В отличие от IPv4, узлы IPv6 не требуют установки максимального времени жизни пакетов. По этой причине поле IPv4 "time to live" (TTL) переименовано в "hop limit" (предельное число шагов) для IPv6. На практике очень немногие IPv4 приложения, используют ограничения по TTL, так что фактически это не принципиальное изменение.

При вычислении максимального размера поля данных, доступного для протокола верхнего уровня, должен приниматься во внимание большой размер заголовка IPv6 относительно IPv4. Например, в IPv4, mss опция TCP вычисляется как максимальный размер пакета (значение по умолчанию или величина полученная из MTU) минус 40 октетов (20 октетов для минимальной длины IPv4 заголовка и 20 октетов для минимальной длины TCP заголовка). При использовании TCP поверх IPv6, MSS должно быть вычислено как максимальная длина пакета минус 60 октетов, так как минимальная длина заголовка IPv6 (т.e., IPv6 заголовок без заголовков расширения) на 20 октетов больше, чем для IPv4.

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

• Желательно, чтобы любые многооктетные поля в пределах данных опции были выровнены на их естественные границы, т.e., поля с длиной в n октетов следует помещать со смещением по отношению к началу заголовка (hop-by-hop или destination options), кратным n октетам, для n = 1, 2, 4 или 8.
• Другим желательным требованием является минимальное место, занимаемое hop-by-hop или опциями места назначения, а длина заголовка должна быть кратной 8 октетам.
• Можно предположить, что когда присутствует какой-то заголовок, содержащий опции, он несет в себе небольшое число опций, обычно одну.

Эти предположения определяют следующий подход к выкладке полей опций: порядок опций от коротких к длинным без внутреннего заполнения. Требования выравнивания границ для всей опции определяется требованием выравнивания наиболее длинного поля (до 8 октетов). Этот подход иллюстрируется на следующих примерах:

Пример 1

Если опция x требует двух полей данных, одно длиной 8 октетов, а другое длиной 4 октета, ее формат будет иметь вид (рис. 4.4.1.1.27):

Рис. 4.4.1.1.27.

Требование выравнивания соответствует 8n+2, для того чтобы гарантировать начало 8-октетного поля со смещением, кратным 8, от начала последнего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из этих опций будет иметь формат (рис. 4.4.1.1.28):

Рис. 4.4.1.1.28

Пример 2

Если опция y требует трех полей данных, одно длиной 4 октета, одно - 2 октета и одно - длиной один октет, она будет уложена следующим образом (рис. 4.4.1.1.29):

Рис. 4.4.1.1.29

Требование выравнивания выглядит как 4n+3, и призвано гарантировать, что 4-октетное поле начнется со смещением кратным 4 по отношению к началу завершающего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из указанных опций будет иметь вид (рис. 4.4.1.1.30):

Рис. 4.4.1.1.30

Пример 3

Заголовок с опциями hop-by-hop или destination options, содержащий обе опции x и y из примеров 1 и 2, будет иметь один из приведенных ниже форматов, в зависимости от того, какая из опций встречается первой (рис. 4.4.1.1.31, 4.4.1.1.32):

Рис. 4.4.1.1.31

Рис. 4.4.1.1.32

Заголовок IP идентификации [RFC-1826] и безопасная IP инкапсуляция [RFC-1827] будут использоваться в IPv6, в соответствии с безопасной архитектурой протоколов Интернет [RFC-1825].

Существующая поддержка записи адресов Интернет в DNS (Domain Name System) [1,2] не может быть легко расширена для поддержки IPv6-адресов [3], так как приложение предполагает, что адресный запрос вернет только 32-битовый IPv4-адрес.

Для того чтобы запоминать IPv6-адреса, определены следующие расширения:

• Определен новый тип ресурсной записи, для того чтобы установить соответствие между именами доменов и адресами IPv6.
• Определен новый домен, предназначенный для обработки запросов по новым адресам.
• Существующие запросы, которые выполняют выявление IPv4-адресов, переопределены для получения как IPv4, так и IPv6-адресов.

Изменения выполнены так, чтобы быть совместимыми с имеющимся программным обеспечением. Существующая поддержка IPv4-адресов сохраняется. Переходное состояние осуществования IPv4 и IPv6-адресов обсуждается в [4].

Определен новый тип ресурсной записи для хранения IPv6-адреса ЭВМ. Если ЭВМ имеет более одного IPv6-адреса, тогда используется более одной такой ресурсной записи.

Тип ресурсной записи aaaa является специфическим для класса Интернет и служит для записи одного IPv6-адреса. Код типа равен 28 (десятичное).

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

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

Текстовое представление информационной секции ресурсной записи aaaa, используемое в файле базы данных имеет формат, описанный в [3], а также в текущем разделе.

Определен специальный домен, который предназначен для установления соответствия между именами и IPv6-адресами. Домен имеет имя ip6.int.

IPv6-адрес представляется в виде имени в домене ip6.int. Это имя выглядит как последовательность символов, разделенных точками, завершающаяся суффиксом .ip6.int. Последовательность символов записывается в обратном порядке, т.е. младший по порядку символ записывается первым и т.д... Каждый из символов представляет собой шестнадцатеричную цифру. Например, запрос, соответствующий адресу

4321:0:1:2:3:4:567:89ab

будет выглядеть как

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int.

Все существующие типы запросов, которые выполняют дополнительную обработку секции a, т.е. типы запросов, относящиеся к серверу имен (ns), почтовому серверу (MX) и почтовому ящику (MB), для осуществления обработки как секции типа a, так и типа aaaa должны быть переопределены. Эти новые определения означают, что сервер имен, обрабатывая один из указанных запросов, должен добавить в соответствующую секцию запроса какие-то подходящие адреса IPv4 и какие-то адреса IPv6 доступные локально.

Протокол IPv6 является новой версией IP. IPv6использует протокол управляющих сообщений (ICMP) так, как это определено для IPv4 [RFC-792], но с некоторым количеством изменений. Протокол подключения к группам (IGMP), специфицированный для IPv4 [RFC-1112] был также пересмотрен и включен в протокол ICMP для IPv6. Результирующий протокол называется ICMPv6, и имеет код следующего заголовка 58.

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

Сообщения ICMPv6 образуют два класса: сообщения об ошибках и информационные сообщения. Сообщения об ошибках идентифицируются по нулю в старшем бите поля тип. Таким образом, сообщения об ошибках могут иметь код поля тип от 0 до 127; информационные сообщения имеют коды поля тип от 128 до 255.

В данном документе определены форматы для следующих сообщений ICMPv6:

Сообщения об ошибках ICMPv6:

1 destination unreachable (место назначения недоступно)
2 packet too big (пакет слишком велик)
3 time exceeded (время превышено)
4 parameter problem (проблема с параметрами)

Информационные сообщения ICMPv6:

128 echo request (Запрос эхо)
129 echo reply (Эхо-отклик)
130 group membership query (запрос участия в группе)
131 group membership report (отчет об участии в группе)
132 group membership reduction (сокращение числа участников в группе)

Каждое сообщение ICMPv6 начинается с заголовка IPv6, за которым следует нуль или более заголовков расширения IPv6. Заголовок ICMPv6 идентифицируется кодом следующего заголовка 58 в предыдущем заголовке. (Заметим: этот код отличается от значения, принятого для ICMP IPv4.)

Сообщения ICMPv6 имеют следующий общий формат (рис. 4.4.1.1.33):

Рис. 4.4.1.1.33. Общий формат сообщений ICMPv6

Поле тип указывает на тип сообщения. Его значение определяет формат последующих данных.

Поле код зависит от типа сообщения. Оно используется для создания дополнительного уровня структуризации сообщения. Поле контрольная сумма используется для обнаружения повреждений сообщения ICMPv6 и заголовка IPv6.

Узел отправитель сообщения ICMPv6 должен определить IPv6-адреса отправителя и получателя до вычисления контрольной суммы. Если узел имеет более одного уникастного адреса, то он должен выбрать адрес отправителя следующим образом:

1. Если сообщение является откликом на сообщение, полученное по одному из уникаст адресов, адресом отправителя должен стать именно этот адрес.
2. Если сообщение является откликом на мультикаст- или эникаст-сообщение группе, в которую входит данный узел, адресом отправителя должен стать никастный адрес интерфейса, откуда пришло сообщение-первопричина отклика.
3. Если сообщение является откликом на сообщение, посланное по адресу, который не принадлежит данному узлу, в качестве адреса отправителя следует выбрать уникаст адрес, принадлежащий узлу и обещающий наибольшую диагностическую полезность. Например, если сообщение является откликом на операцию переадресации пакета, которая не может быть завершена успешно, в качестве адреса отправителя должен быть взят уникаст-адрес интерфейса, переадресация на который не удалась.
4. В противном случае, должна быть просмотрена таблица маршрутизации узла и выяснено, какой интерфейс должен быть использован для достижения места назначения сообщения. Уникастный адрес этого интерфейса и должен быть выбран в качестве адреса отправителя.

Контрольная сумма является 16-битным дополнением по модулю 1 суммы всего сообщения ICMPv6, начиная с поля тип сообщения ICMPv6, дополненного полями псевдозаголовка IPv6. Код поля следующий заголовок для псевдозаголовка выбирается равным 58. (Заметим: включение псевдозаголовка в контрольную сумму ICMPv6 является изменением по отношению к протоколу IPv4; обоснование причин этого см. в [IPv6]). Перед вычислением контрольной суммы поле контрольная сумма обнуляется.

Приложения должны следовать следующим правилам при обработке сообщений ICMPv6 (из [RFC-1122]):

1. Если получено сообщение о неизвестной ошибке ICMPv6, оно должно быть передано верхнему уровню.
2. Если получено информационное сообщение ICMPv6 неизвестного типа, оно должно быть выброшено.
3. Каждое ICMPv6 сообщение об ошибке (тип < 128) включает в себя целиком или частично IPv6 пакет, вызвавший ошибку, при условии, что сообщение об ошибке превысит 576 октетов.
4. В тех случаях, когда протокол интернет-уровня нуждается в передаче сообщения об ошибке ICMPv6 вышерасположенному уровню, тип протокола верхнего уровня извлекается из исходного пакета (содержащегося в теле сообщения об ошибке ICMPv6) и используется для выбора соответствующего протокола верхнего уровня при последующей обработке сообщения об ошибке.

Если исходный пакет имеет необычно большое число заголовков расширения, возможно, что тип протокола верхнего уровня может отсутствовать в сообщении ICMPv6, из-за укорочения исходного пакета до уровня 576 октетов. В этом случае сообщение об ошибке отбрасывается после обработки уровня IPv6.

5. Сообщение об ошибке ICMPv6 не должно посылаться в качестве результата получения:

(e.1) сообщения об ошибке ICMPv6, или

(e.2) пакета, направленного по IPv6 мультикаст-адресу (существует два исключения из этого правила: (1) сообщения packet too big - пакет слишком велик) - чтобы позволить скорректировать MTU прохода, и (2) сообщения parameter problem (проблема с параметрами), Код 2, оповещающий о нераспознанной опции), или

(e.3) мультикастинг-пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

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

(e.5) пакета, чей адрес отправителя не однозначно определяет какой-то узел, например, не специфицированный адрес IPv6, мультикаст-адрес IPv6 или эникаст-адрес.

(f) Наконец, узел IPv6 должен ограничить частоту посылки сообщений об ошибке, если адресат на них не реагирует. Это ограничит загрузку канала.

Существует много способов ограничения частоты посылки сообщений, например:

(f.1) Таймерный метод. Передача сообщений производится не чаще, чем раз за указанное число T миллисекунд.

(f.2) Метод полосы пропускания. Сообщения об ошибке должны занимать не более определенной доли F полосы пропускания канала.

Ограничивающие параметры (например, T или F в вышеприведенных примерах) должны задаваться узлом со значениями по умолчанию (напр., T = 1 сек, и F = 2%, не 100%!).

Рис. 4.4.1.1.34. Формат сообщения о недостижимости адресата

Поля IPv6:

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

Поля ICMPv6:

Тип = 1
Код = 0 - нет маршрута до места назначения
1 - связь с адресатом административно запрещена
2 - не сосед
3 - адрес не достижим
4 - порт не достижим

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

Описание

Сообщение адресат не достижим (destination unreachable) должно генерироваться маршрутизатором, или уровнем IPv6 узла-отправителя, в случае, когда пакет не может быть доставлен адресату не по причине перегрузки. (Сообщение ICMPv6 не должно посылаться при потере пакета из-за перегрузки).

Если причиной потери пакета является недостаток места в маршрутной таблице узла, поле код должно принять значение 0 (Заметим, что такая ошибка может произойти только при наличии в таблице маршрута по умолчанию).

Если причиной потери пакета является административный запрет, например, Firewall, поле код принимает значение 1.

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

Если имеет место какая-то другая причина недоставки пакета, в поле код заносится значение 3.

Узел места назначения может посылать сообщение "адресат не достижим" с кодом 4, когда транспортный протокол пакета (напр., UDP) не имеет получателя, а другого метода, уведомить об этом отправителя нет.

Узел, получивший сообщение ICMPv6 "адресат не достижим" должен уведомить об этом протокол вышележащего уровня.

Рис. 4.4.1.1.35. Сообщение packet too big (пакет слишком велик)

Поля IPv6:

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

Поля ICMPv6:

Тип 2
Код 0
mtu mtu следующего шага.

Описание

Сообщение packet too big (пакет слишком велик) должно посылаться маршрутизатором в ответ на получение пакета, который не может быть переадресован, из-за того, что он длиннее, чем MTU выходного канала. Информация в этом сообщении используется в качестве части процесса определения MTU прохода [RFC-1191].

Пришедшее сообщение packet too big должно быть передано протоколу верхнего уровня.

Формат сообщения о превышении времени аналогичен формату сообщения о недостижимости адресата (рис. 4.4.1.1.33).

Поля ICMPv6:

Тип 3
Код 0 - при передаче превышен лимит числа шагов
1 - превышено время восстановления сообщения из фрагментов.

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

Описание

Если маршрутизатор получает пакет с предельным значением числа шагов равным нулю (hop limit = 0), или маршрутизатор после декрементации получил нулевое значение поля hop limit, он должен выбросить такой пакет и послать отправителю пакета сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным 0. Это указывает на зацикливание маршрута или на слишком малое значение поля hop limit.

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

Пришедшее сообщение time exceeded должно быть передано протоколу верхнего уровня.

Рис. 4.4.1.1.36. Сообщение о конфликте параметров

Поля ICMPv6:

Тип 4
Код 0 - встретилась ошибка в поле заголовка
1 - встретился неопознанный код поля следующий заголовок
2 - встретилась неопознанная опция IPv6
Указатель. Идентифицирует смещение в октетах в пакете, вызвавшем ошибку.

Указатель отмечает позицию в пакете, если размер пакета ICMPv6 не позволяет поместить его в отклик полностью, а ошибочное поле в сообщение не поместилось.

Описание

Если узел IPv6, обрабатывающий пакет, обнаруживает какую-то проблему с одним из полей заголовка или заголовков расширения, такую, что дальнейшая обработка невозможна, он должен выбросить пакет и послать сообщение ICMPv6 parameter problem (проблема с параметрами) отправителю пакета с указанием типа и позиции ошибки.

Поле указатель идентифицирует октет заголовка исходного пакета, где обнаружена ошибка. Например, сообщение ICMPv6 с полем тип = 4, полем код = 1 и полем указатель = 40 указывает на то, что заголовок расширения IPv6, следующий за заголовком IPv6 исходного пакета содержит нераспознанный код следующего заголовка.

Рис. 4.4.1.1.37. Сообщение запрос эхо

Поля IPv6:

Адрес места назначения - любой легальный IPv6-адрес

Поля ICMPv6:

Тип 128
Код 0

Номер по порядку

Номер по порядку имеет целью связать друг с другом запрос эхо и эхо-отклик. Может равняться нулю.

Информация. Нуль или более октетов произвольных данных.

Описание

Каждый узел должен реализовать функцию эхо-отклика ICMPv6 при получении запроса эхо. Узлу следует также предоставить пользовательский интерфейс для посылки запросов эхо и получения эхо-откликов для целей диагностики.

Формат сообщения эхо-отклик идентичен формату запроса эхо (рис. 20.5).

Поля IPv6:

Адрес места назначения копируется из поля адрес отправителя пакета запрос эхо.

Поля ICMPv6:

Тип 129
Код 0

Описание

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

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

Эхо-отклик должен быть послан в ответ на запрос эхо, посланный по мультикастному адресу. Адрес отправителя в отклике должен быть уникастным адресом, принадлежащим интерфейсу, через который был получен мультикастный запрос эхо.

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

Оповещение верхнего уровня

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

Сообщение о членстве в группе имеет следующий формат:

Рис. 4.4.1.1.38. Сообщения участия в группе

Поля IPv6:
Адрес места назначения

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

В отчете о членстве в группе или в сообщении о сокращении членства в группе сообщается мультикаст-адрес группы.

Поле Hop Limit = 1 (предельное число шагов)
Поля ICMPv6:

Тип 130 - Запрос членства в группе
131 - Отчет о членстве в группе
132 - Сокращение членства в группе
Код 0
Максимальное время отклика

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

Не используется. Отправитель записывает нуль, получатель игнорирует.
Мультикаст-адрес

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

Описание

Сообщения ICMPv6 о членстве в группе используются для передачи информации о членстве в мультикаст-группе от узлов к их ближайшим маршрутизаторам. Подробности их использования можно найти в [RFC-1112].

Литература