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

Управление

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

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

Рис. 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].

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

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

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

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

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