Пакет IPv6

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

Рис. 3.10. Кодирование свойств опции в ее типе

В трех старших битах типа (см. рис. 3.10) закодированы неотъемлемые свойства каждой опции, и посему эти биты нельзя рассматривать как отдельное поле. Когда новой опции назначают численное значение типа, то в нем сразу же учитывают ее свойства. Например, если мы увидим опцию с десятичным кодом 95, то немедленно^{3 http://www.ripe.net/docs/ipv6policy.html#conservation} скажем о ней следующее:

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

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

Вычислите десятичное значение кода новой опции. (127)

О поле типа опции осталось сказать, что пошаговые опции и опции адресата хранятся в пакете раздельно, но получают численные коды из одного и того же реестра^{4 http://www.iana.org/assignments/ipv6-parameters} , так что один код не может означать две разных опции.

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

Первая из них, Pad1, в виде исключения займет ровно один байт, к чему и сводится вся ее функция (см. рис. 3.11). Формально тип опции Pad1 — 0, но она нарушает формат TLV: в ней нет полей, кроме поля типа.

Рис. 3.11. Опция Pad1

Вторая же опция, PadN, вполне отвечает формату TLV (см. рис. 3.12). Ее тип — 1, и она может занять от 2 до 257 байт. Если ее поле "длина" больше нуля, то пусть поле данных ради единообразия будет заполнено нулевыми байтами.

Рис. 3.12. Опция PadN

Согласно своей роли, опции Pad1 и PadN могут встречаться в заголовке опций несколько раз и располагаться в начале заголовка, в его конце, или же перемежать другие опции. Они могут возникать и среди пошаговых опций, и среди опций адресата.

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