TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Если у клиента завершается время использования адреса, сервер DHCPv6 удалит запись об этом клиенте в DNS.

22.10 Переход на IPv6

IP широко распространен во всем мире. Однако нельзя требовать, что бы все одновременно перешли на версию 6. Этот переход должен быть постепенным:

■ Узлы версии 6 должны взаимодействовать с узлами версии 4.

■ От организаций нельзя требовать отказа от их текущих адресов.

■ Организации должны иметь возможность модернизировать отдельные узлы, оставляя другие без изменения.

■ Переход должен быть прост и понятен.

22.10.1 Необходимость изменений

Провайдерам IPv6 необходим для более эффективной магистральной маршрутизации и увеличения количества своих подписчиков. Однако зачем переходить на версию 6 независимым организациям, у которых прекрасно работают сети на старой системе адресации? Если нет проблем с обслуживанием IP-адресов или введением новых служб (например, потоков), то переходить на новую версию необязательно.

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

22.10.2 Путь перехода на новую версию

Первым шагом на пути к версии 6 будет модернизация программного обеспечения сервера имен доменов сайта, чтобы сервер DNS смог отвечать на запросы, используя новый формат адресов.

Вероятно, первыми модернизируемыми системами станут маршрутизаторы интерфейсов с внешними сетями. Эти маршрутизаторы будут преобразованы для совместной работы как с версией 4, так и с версией 6. Постепенно на наиболее важных маршрутизаторах появится стек протоколов версии 6. В смешанном окружении трафик версии 6 будет пересылаться по тоннелям в сетях версии 4.

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

22.10.3 Изменения в DNS

Новый тип записи о ресурсе, AAAA, отображает имена доменов в адреса IP версии 6. Пример такой записи:

MICKEY IN AAAA 4321:0:1:2:3:4:567:89AB

Должен быть обеспечен и обратный просмотр. Для преобразования адресов в имена для IPv6 потребуется добавить новые домены. Обратный поиск доменов включается в дерево доменов от узла IP6.INT.

Адреса IP версии 4 рассматриваются в обратном порядке, чтобы получить свои метки в домене in-addr.arpa. Адреса версии 6 также просматриваются наоборот и переписываются как ряд шестнадцатеричных цифр, разделенных точками. Например, обратная запись элемента:

4321:0:1:2:3:4:567:89АВ

появится в дереве домена как:

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

22.10.4 Туннели через сети версии 4

В течение переходного периода датаграммы иногда будут пересекать на своем пути сети версии 4. На рис. 22.8. провайдеры А и С поддерживают версию 6, а провайдер В — нет. Граничные маршрутизаторы интерфейсов имеют адреса совместимости IPv4 с IPv6, которые легко преобразовать в адреса версии 4, удаляя нулевые префиксы. Пакеты версии 6 "обернуты" заголовком версии 4 и пересекают промежуточную сеть по туннелю.

Рис. 22.8. Трафик в туннеле сети версий 4

Формирование туннеля может происходить и в пределах сайта, который преобразовал некоторые из своих сетей в версию 6. Оно может использоваться в любом удобном для этого месте: между маршрутизаторами, между хостами или на пути от хостов к маршрутизаторам.

22.11 Резюме

Рабочие группы разработки IP следующего поколения заложили основы новой версии, которая разрешает проблему истощения пространства адресов Интернета и предлагает более эффективную маршрутизацию. Новый протокол предоставляет возможности автоматической конфигурации и сосуществования со старой версией, а также позволяет осуществлять постепенный переход на новую версию. Цепочечные заголовки обеспечивают безболезненную будущую модернизацию и удобный путь перемещения в сетях IP данных других протоколов.

22.12 Дополнительная литература

RFC 1884 описывает адреса IPv6, a RFC 1883 — основы протокола версии 6. RFC 1885 посвящен ICMPv6, a RFC 1886 имеет дело с расширениями DNS. В RFC 1887 обсуждается архитектура выделения адресов. После выхода данной книги должны появиться и другие RFC.

Глава 23 ICMPv6 и исследование соседей

23.1 Введение

Версия 6 протокола Internet Control Message Protocol (ICMPv6) сохраняет многие функции версии 4, но вводит и несколько важных изменений:

■ Сообщения ICMPv6 помогают в автоматической конфигурации адресов.

■ Новые сообщения и процедуры ICMPv6 заменяют протокол ARP.

■ Автоматизируется исследование максимального элемента пересылки (MTU) по пути. Поскольку маршрутизаторы более не фрагментируют пакеты, то в случае слишком большого размера пакетов источнику отправляется сообщение Packet Too Big (пакет слишком велик).

■ ICMPv6 не посылает сообщений Source Quench.

■ ICMPv6 принимает на себя функции отчета о членстве в многоадресной группе протокола Internet Group Management Protocol.

■ ICMPv6 помогает определить выключение маршрутизатора или партнера по коммуникации.

ICMPv6 настолько отличается от старой версии, что ему присвоен новый номер 58 в заголовке Next Header.

23.2 Базовые сообщения ICMPv6

В таблице 23.1 перечислены основные типы сообщений ICMPv6. Отметим, что сообщениям об ошибке присвоены номера от 0 до 127, а информационным сообщениям — от 128 до 255. Общий формат сообщения ICMP показан на рис. 23.1. Сначала рассмотрим сообщения ICMP, сходные с сообщениями версии 4.

Таблица 23.1 Типы сообщений ICMP

Сообщения об ошибках	Тип
Destination Unreachable (точка назначения недоступна)	1
Packet Too Big (пакет слишком велик)	2
Time Exceeded (истекло время)	3
Parameter Problem (проблема с параметрами)	4
Информационные сообщения	Тип
Echo Request (эхо-запрос)	128
Echo Reply (эхо-ответ)	129
Group Membership Query (запрос о членстве в группе)	130
Group Membership Report (отчет о членстве в группе)	131
Group Membership Reduction (исключение из членов группы)	132