Опубликован: 30.07.2013 | Доступ: свободный | Студентов: 1678 / 51 | Длительность: 24:05:00
Лекция 4:

Пакет IPv6

Заголовки расширения

Заголовок, которого нет

Представим себе пакет IPv6, который состоит из одного основного заголовка. Хотя нам не совсем ясно, зачем такой пакет мог бы понадобиться, формального повода запретить его у нас тоже нет.

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

Однако само существование пакета без полезной нагрузки поднимает любопытный вопрос: чему в нем должно быть равно значение поля "следующий заголовок"? Мы могли бы сказать, что оно неважно, потому что длина полезной нагрузки равна нулю; но зачем нам лишняя неоднозначность? Чтобы не провоцировать разночтения стандарта и несовместимость реализаций, давайте назначим этому случаю вполне определенный код из реестра протоколов IP. Это код 59, "следующего заголовка нет" (No Next Header) [§4.7 RFC 2460]. Таким кодом можно завершить и цепочку заголовков расширения, если за ней в пакете ничего нет, как это показано на рис. 3.7.

Пакет без полезной нагрузки

Рис. 3.7. Пакет без полезной нагрузки

Теперь представим себе, что получатель сканирует пакет и обнаруживает заголовок со значением 59 в поле "следующий заголовок", а затем еще какие-то байты (об этом скажет длина полезной нагрузки IPv6). Хотя такая ситуация неоднозначна, в ней нет явного криминала: она не ведет к осложнениям или опасным последствиям, если обработать ее правильно. А принцип Постела подсказывает, как именно следует поступить: пусть транзитные узлы сохраняют эти концевые байты, а конечный адресат игнорирует их [§4.7 RFC 2460].

Напомним себе современную трактовку принципа Постела (Postel’s principle), также известного как принцип устойчивости (robustness principle). Основоположник Internet Джонатан Постел (Jonathan Postel) сформулировал этот принцип одной лаконичной фразой: "Будь консервативен в собственных действиях и либерален к тому, что принимаешь от других" [§2.10 RFC 793]. Сегодня мы добавим к этому: "…но никогда не забывай о безопасности". Этот принцип требовательности к себе и терпимости к другим — один из главных в TCP/IP. Если сторона протокола следует ему, она не только соблюдает протокол, но также приобретает гибкость и устойчивость к неполадкам, а эти качества особенно важны, когда разработчики протокола не могут заранее предусмотреть все варианты развития событий.

Опции

Мы предварительно отметили в §3.1, что опции можно поделить на пошаговые и актуальные только для адресата. Требования к обработке этих видов опций существенно разнятся. Во-первых, маршрутизаторы в целях производительности должны сканировать только пошаговые опции. Во-вторых, когда у IP появятся собственные механизмы сквозной защиты, опции адресата можно будет шифровать. В-третьих, при фрагментации пакета пошаговые опции надо целиком копировать в каждый фрагмент, тогда как опции адресата достаточно привести один раз и даже можно разбить на части, если они окажутся слишком длинными и пересекут границы одного фрагмента.

Пока что мы лишь излагаем общие соображения, а точные правила фрагментации заголовков мы сформулируем, когда будем готовы к этому, в §3.3.4.

По всей видимости, каждый вид опций заслуживает собственного заголовка расширения. Форматы этих заголовков могут полностью совпадать, но им будут отвечать разные коды "следующий заголовок". Так, заголовок опций адресата получает код 60 [§4.6 RFC 2460].

Заголовок пошаговых опций, ввиду своей особой роли, получает отличительный код 0 [§4.3 RFC 2460] и позицию непосредственно после заголовка IPv6. Иными словами, код 0 может встретиться только в поле "следующий заголовок" основного заголовка IPv6. Если же пакет составлен правильно, но первое поле "следующий заголовок" ненулевое, то в пакете пошаговых опций нет. С помощью этой простой логики маршрутизаторы могут быстро обнаруживать пошаговые опции в транзитных пакетах.

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

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

Поле "следующий заголовок" занимает один байт. Пусть поле "длина" тоже займет один байт, и тогда действительное начало опций будет выровнено на границу 16 битного слова. Код обоих полей будет целый беззнаковый. Но не слишком ли мало 255 байт для всего списка опций? Удлинить его можно, если измерять длину не в байтах, а в больших единицах. Заодно так мы выровняем конец заголовка опций. Конец заголовка IPv6 выровнен на границу 64 битного слова, и большего выравнивания мы уже не достигнем. Поэтому пусть длина заголовка опций измеряется в 8 байтных единицах. Еще заметим, что длина такого заголовка не меньше единицы из-за обязательных полей. Эту единицу можно учесть неявно и выиграть еще 8 байт. То есть поле "длина" заголовка опций ведет учет 8 байтных отрезков, начиная со второго. Тогда длина всего заголовка в байтах может меняться от 8 до 2048 с шагом 8 байт. Окончательный формат заголовка опций показан на рис. 3.8.

Заголовок опций IPv6

Рис. 3.8. Заголовок опций IPv6

Сами опции мы станем кодировать широко известным способом TLV: поле типа, поле длины, данные, — как показано на рис. 3.9. Поля типа и длины данных занимают по одному байту. Длина данных измеряется в байтах и, по традиции IPv6, не включает фиксированные поля типа и длины.

Общий вид опции IPv6

Рис. 3.9. Общий вид опции IPv6

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

Таблица 3.1. Смысл старших битов в численном коде опции IPv6
Биты Предписания
00 "Перескочить" через незнакомую опцию и продолжить обработку заголовка
01 Уничтожить пакет; не высылать никаких извещений
10 Уничтожить пакет; выслать извещение "ICMP версии 6" (независимо от адреса назначения исходного пакета)
11 Уничтожить пакет; выслать извещение "ICMP версии 6", только если адрес назначения исходного пакета не групповой
Здесь мы вполне обоснованно предположили, что у IPv6 будет управляющий протокол, аналогичный ICMP. Над ним мы поработаем в §4.3. Он и правда будет назваться ICMPv6.
Сергей Субботин
Сергей Субботин

"Теоретически канал с адресацией EUI 64 может соединить порядка 2^63 "

запись вида 2^63  не понятна и отнимает время на попытку ее осмыслить.

ее можно заменить например на записи вида  264  или 1,8 * 1019

 

Павел Афиногенов
Павел Афиногенов

Курс IPv6, в тексте имеются ссылки на параграфы. Разбиения курса на параграфы нет.

Сергей Горбунов
Сергей Горбунов
Украина, Киев