Опубликован: 30.07.2013 | Уровень: для всех | Доступ: платный
Лекция 5:

IPv6 в стеке протоколов

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >

Управление

Хотя ICMP [RFC 792] вполне можно было бы "притянуть за уши" к управлению IPv6, новая версия IP — это хороший повод пересмотреть и сопряженный с ним протокол управления. Чтобы не заботиться о совместимости с ICMP, давайте назначим новому протоколу другой номер, 58, из реестра протоколов IP. Новорожденный протокол мы назовем "ICMP версии 6", а кратко — ICMPv6 [RFC 4443], хотя заголовок ICMP и не содержит поля версии. Чтобы избежать разночтений, "старый" ICMP для IPv4 мы теперь обозначим как ICMPv4, по крайней мере, при его сравнении с ICMPv6.

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

Какие требования мы предъявим к протоколу управления IPv6? В первую очередь, он не должен отставать от IPv6 в плане гибкости и расширяемости. Это требование мы выполним, "собрав" сообщение ICMPv6 из двух частей. У первой части формат будет постоянным, а у второй — переменным, как изображено на рис. 4.7. Это не новость, потому как сообщения ICMPv4 были устроены тем же самым образом.

Общая структура сообщения ICMPv6

Рис. 4.7. Общая структура сообщения ICMPv6

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

Поскольку ICMPv6 — отдельный протокол, номера его типов никак не связаны с номерами типов ICMPv4. Номера типов ICMPv6 мы будем распределять с нуля, так что у нас есть возможность придать им определенную структуру. В ICMPv4 типы извещений об ошибках шли вперемежку с чисто справочными типами. Теперь ради удобства давайте проведем между ними границу. Пусть типы извещений об ошибках получают номера из диапазона 0–127, а справочные типы — из диапазона 128–255. Тогда, чтобы узнать характер сообщения ICMPv6, достаточно взглянуть на старший бит в его поле "тип": 0 означает произошедшую ошибку, а 1 — справочные сведения [§2.1 RFC 4443].

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

Формат переменной части также целиком зависит от типа сообщения. Эту часть мы назовем телом сообщения (message body). Она простирается до конца пакета, а длину ее можно вычислить, исходя из длины полезной нагрузки в заголовке IPv6.

Согласно принятой в IPv6 модели защиты данных от повреждения, контрольная сумма ICMPv6 должна защищать не только само сообщение, но и заголовок IPv6. Достичь этого можно, используя при вычислении контрольной суммы псевдозаголовок стандартного формата (см. §4.2). В остальном правила обычные: на время расчета контрольной суммы псевдозаголовок условно помещается перед заголовком ICMPv6, а само поле "контрольная сумма" явно или "мысленно" обнуляется [§2.3 RFC 4443].

Какое значение надо поместить в поле "следующий заголовок" такого псевдозаголовка? (Ответ: 58 — ICMPv6.)

Заметим, что ICMPv4 не использовал псевдозаголовка и вычислял только контрольную сумму собственного БДП, вложенного в пакет IPv4. Так что применение псевдозаголовка в ICMP — это новшество IPv6, вызванное отсутствием контрольной суммы в основном заголовке IPv6.

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

Напомним о двусмысленности термина "полезная нагрузка" в IPv6. В общеупотребительном смысле, это последняя секция пакета, после основного заголовка и заголовков расширения IPv6, занятая блоком данных вышестоящего протокола: дейтаграммой UDP, сегментом TCP, сообщением ICMPv6 . В узком смысле поля "длина полезной нагрузки" из основного заголовка IPv6 это весь пакет за вычетом основного заголовка. При заполнении псевдозаголовка эти два толкования встречаются, так как в заголовке IPv6 указана "длина полезной нагрузки" (смысл №2), а надо найти длину блока данных вышестоящего протокола (смысл №1). Это касается, в первую очередь, узла назначения, так как он должен разобрать и проверить входящий пакет.

Перейдем теперь к типам сообщений ICMPv6. Для начала, в Табл. 4.3, мы определим только самые необходимые из них [§2.1 RFC 4443], а для будущих назначений создадим реестр11 http://www.iana.org/assignments/icmpv6-parameters .

Таблица 4.3. Основные типы сообщений ICMPv6
Тип Название (рус.) Название (англ.) Ссылка
Извещения об ошибках
1 Адресат недоступен Destination Unreachable [§3.1 RFC 4443]
2 Пакет слишком велик Packet Too Big [§3.2 RFC 4443]
3 Время истекло Time Exceeded [§3.3 RFC 4443]
4 Проблема в параметре Parameter Problem [§3.4 RFC 4443]
100 Для частных экспериментов [§2.1 RFC 4443]
101 Для частных экспериментов [§2.1 RFC 4443]
127 Резерв для расширения [§2.1 RFC 4443]
Справочные сообщения
128 Запрос эха Echo Request [§4.1 RFC 4443]
129 Ответ эхом Echo Reply [§4.2 RFC 4443]
200 Для частных экспериментов [§2.1 RFC 4443]
201 Для частных экспериментов [§2.1 RFC 4443]
255 Резерв для расширения [§2.1 RFC 4443]

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

Что еще изменилось по сравнению с основными типами ICMPv4? Прежде всего, извещения "пакет слишком велик" и "время истекло" получили отдельные типы. Теперь "адресат недоступен" говорит только о невозможности доставить пакет из-за проблем на уровне адресации и маршрутизации, или же ввиду ограничений политики [§3.1 RFC 4443], например:

  • код 0: нет маршрута к адресу назначения, то есть неизвестно, куда продвигать пакет;
  • код 1: обмен пакетами с адресатом запрещен в административном порядке, например, политикой сетевой безопасности;
  • код 2: адресат находится за пределами зоны источника, то есть предотвращено нарушение границ зоны, такое как попытка направить пакет узлу совершенно другой сети, используя внутриканальный адрес источника;
  • прочие коды "адресат недоступен" приведены в [§3.1 RFC 4443] и реестре12 http://www.iana.org/assignments/icmpv6-parameters [ ].

Какую практическую пользу принесет то, что у сообщения "пакет слишком велик" теперь есть свой тип, а не только код в рамках типа "адресат недоступен", как это было в ICMPv4? Прежде всего, инженерам по сетевой безопасности будет легче составлять политики, которые запрещают произвольные извещения "адресат недоступен", но при этом не блокируют работу PMTUD. В IPv4 это было серьезной проблемой. Во-первых, сами инженеры часто забывали разрешить именно это сочетание типа и кода ICMPv4. А во-вторых, было много примеров сетевого программного обеспечения, которое позволяло фильтровать ICMPv4 только по значению поля "тип", но не "код", так что невозможно было избирательно разрешить PMTUD. В ICMPv6 этот опыт нельзя было не учесть, так как важность правильной работы PMTUD возросла многократно из-за новых правил фрагментации, когда решение о размере пакета принимает только его источник (см. §3.3.4).

В идеале, фильтрация ICMP не должна представлять сложности для сетевого экрана, полноценно отслеживающего прикладные сеансы. Ему достаточно пропускать сообщения ICMP, относящиеся к существующим сеансам, и блокировать "залетные" сообщения. К сожалению, не все межсетевые экраны рассматривают сигнализацию ICMP как неотъемлемую часть сеанса, но это всего лишь практическое ограничение, которое можно было бы устранить доработкой программы. Более фундаментальная проблема состоит в том, что сообщение ICMPv4 может содержать недостаточно сведений, чтобы точно отнести его к определенному прикладному сеансу. Мы устраним эту проблему в ICMPv6 еще до конца данного раздела.

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >
Сергей Субботин
Сергей Субботин

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

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

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

 

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

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

Александр Худышкин
Александр Худышкин
Россия
Константин Второв
Константин Второв
Россия, Бокситогорск, ЛГОУ им. А.С.Пушкина, 2003